4 ms·

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 p

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...

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...