4 ms·

Thank you for explaining! Please don't take my initial post as criticism of your work. There is just this visible disconnect between approximately 4 years of wo

Thank you for explaining! Please don't take my initial post as criticism of your work. There is just this visible disconnect between approximately 4 years of work and comparatively simple features that have been shown off so far. So there must be a story there. I was not aware of Windows having had different console implementations in the past. Can you elaborate on that point? How did that come to pass? Also,I am curious about one other thing: the Windows Console is notorious for having extremely bad perfomance when displaying lots of text. Last time I checked I could only get around 100 lines of text per second on Windows while Linux terminal emulations can show more than 10 times that amount. This may seem petty, but some programs are slowed down by this in practice. Can we expect improvements in that area as well?

lozenge 8y ago
As I understand it Windows 3 ran in DOS, Windows 98 had DOS integrated, Windows NT had it emulated and ME was somewhere in between. It wouldn't surprise me if parts from all four have survived til today for compatibility.
- chx 8y ago
  ME wasn't between the least. It was DOS based. There is no inbetween. It's either IO.SYS or NTOSKRNL.EXE. It made using the real mode MS DOS even worse by shipping a special MS DOS which skipped CONFIG.SYS and AUTOEXEC.BAT, hidden the files and removed DOS from the boot menu. To fix this, check http://retrosystemsrevival.blogspot.com/2018/06/dos-for-windows-me.html http://retrosystemsrevival.blogspot.com/2018/06/dos-for-wind... this -- quite new blog post, just last month, for something this old.
  - bitcrazed 8y ago
    Actually, no - Windows ME did not depend on MS-DOS. For all the bad rap it got (some of which was deserved), ME bypassed real-mode MS-DOS (and its config files) at bootup, and loaded its own protected-mode drivers, etc. in IO.SYS. It also loaded the main registry hive only once, and parallelized PnP resolution, significantly improving boot-up time. It also incorporated Windows 2000's networking stack, and added support for UPnP. In many ways, ME was a stepping stone, getting some users on less-capable hardware onto Windows 2000 class OS features, without requiring a complete hardware upgrade.
    - chx 8y ago
      Erm, nope. IFSMGR.VXD depends on IFSHLP.SYS still. Everyone's favorite error message: the Microsoft Installable File System Manager cannot find the helper driver. Please ensure that IFSHLP.SYS has been installed. This means Windows ME needs a real mode DOS helper for certain file system operations. I can't remember whether the INT 21h function 55h (Create PSP) was still called as frequently as in earlier Windows and handled in DOS but I betcha.
      - bitcrazed 8y ago
        IFSHLP.SYS was originally created during the implementation of OS/2 1.2, and later released in Windows 3.11 running on 32-bit 386 Enhanced Mode. Its job was to provide 32-bit file access (bypassing 16-bit DOS file IO mechanisms), and ensuring nothing else on the system could intercept INT 21h calls. ME didn't depend on MS-DOS (though it did provide support for running MS-DOS apps).
- TazeTSchnitzel 8y ago
  The 9x series and ME use DOS during the boot process but not once booted, except for legacy disk access (if there's no 32-bit Win9x disk driver). Microsoft went to huge pains to make Win9x act as if it was an application on top of DOS for compatibility reasons, but it very much isn't, it's a full-blown OS. This is almost true of Windows 3.x too or Windows/286 and Windows/386.
- JdeBP 8y ago
  These should help you and others. They cover some of the errors in the above, as well as the change to the console implementation in Windows NT 6.1. * https://superuser.com/a/319187/38062 https://superuser.com/a/319187/38062 * http://jdebp.info./FGA/a-command-interpreter-is-not-a-console.html http://jdebp.info./FGA/a-command-interpreter-is-not-a-consol... * http://jdebp.info./FGA/tui-console-and-terminal-paradigms.html http://jdebp.info./FGA/tui-console-and-terminal-paradigms.ht...
JdeBP 8y ago
Linux terminal emulators are by no means uniform about this. Scrolling speed, and whether to not re-render for every character, are points of contention amongst the XTerm, Alacritty, and VTE people.
- cryptonector 8y ago
  I just set the scrollback history to zero and run tmux. Scrollback speed problem solved.
zadjii 8y ago
Oh I certainly don't take it as such. It can be extra frustrating as both a developer and a user of the console to want to be able to improve everything, but know that there is only so much time to get features done, and rarely do usability features rise in priority above supporting other teams. > I was not aware of Windows having had different console implementations in the past. Can you elaborate on that point? How did that come to pass? It's not really something most developers outside the company would have even been aware of honestly. At different points in time, there have been various different teams across Microsoft who had been working on bringing up new pieces of hardware (Xbox, HoloLens, phones, etc) and they found that the existing console didn't work on those minimal Windows OS's. At the time, there was no Console team at all, so whoever was working on that device just implemented their own console that would work on that prototypical device. That prototypical console got re-used and extended for other devices as they were developed, then abandoned as the platforms matured. Then, in 2014, when the Console team was formed, we found out that not only were we responsible for the desktop console, but these other implementations as well. > Can we expect improvements in that area as well? Stay tuned :)

lozenge 8y ago

As I understand it Windows 3 ran in DOS, Windows 98 had DOS integrated, Windows NT had it emulated and ME was somewhere in between. It wouldn't surprise me if parts from all four have survived til today for compatibility.

chx 8y ago
ME wasn't between the least. It was DOS based. There is no inbetween. It's either IO.SYS or NTOSKRNL.EXE. It made using the real mode MS DOS even worse by shipping a special MS DOS which skipped CONFIG.SYS and AUTOEXEC.BAT, hidden the files and removed DOS from the boot menu. To fix this, check http://retrosystemsrevival.blogspot.com/2018/06/dos-for-windows-me.html http://retrosystemsrevival.blogspot.com/2018/06/dos-for-wind... this -- quite new blog post, just last month, for something this old.
- bitcrazed 8y ago
  Actually, no - Windows ME did not depend on MS-DOS. For all the bad rap it got (some of which was deserved), ME bypassed real-mode MS-DOS (and its config files) at bootup, and loaded its own protected-mode drivers, etc. in IO.SYS. It also loaded the main registry hive only once, and parallelized PnP resolution, significantly improving boot-up time. It also incorporated Windows 2000's networking stack, and added support for UPnP. In many ways, ME was a stepping stone, getting some users on less-capable hardware onto Windows 2000 class OS features, without requiring a complete hardware upgrade.
  - chx 8y ago
    Erm, nope. IFSMGR.VXD depends on IFSHLP.SYS still. Everyone's favorite error message: the Microsoft Installable File System Manager cannot find the helper driver. Please ensure that IFSHLP.SYS has been installed. This means Windows ME needs a real mode DOS helper for certain file system operations. I can't remember whether the INT 21h function 55h (Create PSP) was still called as frequently as in earlier Windows and handled in DOS but I betcha.
    - bitcrazed 8y ago
      IFSHLP.SYS was originally created during the implementation of OS/2 1.2, and later released in Windows 3.11 running on 32-bit 386 Enhanced Mode. Its job was to provide 32-bit file access (bypassing 16-bit DOS file IO mechanisms), and ensuring nothing else on the system could intercept INT 21h calls. ME didn't depend on MS-DOS (though it did provide support for running MS-DOS apps).
TazeTSchnitzel 8y ago
The 9x series and ME use DOS during the boot process but not once booted, except for legacy disk access (if there's no 32-bit Win9x disk driver). Microsoft went to huge pains to make Win9x act as if it was an application on top of DOS for compatibility reasons, but it very much isn't, it's a full-blown OS. This is almost true of Windows 3.x too or Windows/286 and Windows/386.
JdeBP 8y ago
These should help you and others. They cover some of the errors in the above, as well as the change to the console implementation in Windows NT 6.1. * https://superuser.com/a/319187/38062 https://superuser.com/a/319187/38062 * http://jdebp.info./FGA/a-command-interpreter-is-not-a-console.html http://jdebp.info./FGA/a-command-interpreter-is-not-a-consol... * http://jdebp.info./FGA/tui-console-and-terminal-paradigms.html http://jdebp.info./FGA/tui-console-and-terminal-paradigms.ht...

JdeBP 8y ago

Linux terminal emulators are by no means uniform about this. Scrolling speed, and whether to not re-render for every character, are points of contention amongst the XTerm, Alacritty, and VTE people.

cryptonector 8y ago
I just set the scrollback history to zero and run tmux. Scrollback speed problem solved.

zadjii 8y ago

Oh I certainly don't take it as such. It can be extra frustrating as both a developer and a user of the console to want to be able to improve everything, but know that there is only so much time to get features done, and rarely do usability features rise in priority above supporting other teams. > I was not aware of Windows having had different console implementations in the past. Can you elaborate on that point? How did that come to pass? It's not really something most developers outside the company would have even been aware of honestly. At different points in time, there have been various different teams across Microsoft who had been working on bringing up new pieces of hardware (Xbox, HoloLens, phones, etc) and they found that the existing console didn't work on those minimal Windows OS's. At the time, there was no Console team at all, so whoever was working on that device just implemented their own console that would work on that prototypical device. That prototypical console got re-used and extended for other devices as they were developed, then abandoned as the platforms matured. Then, in 2014, when the Console team was formed, we found out that not only were we responsible for the desktop console, but these other implementations as well. > Can we expect improvements in that area as well? Stay tuned :)