We’re talking the first Microsoft drives, not the first drives that ever existed. Windows inherits from DOS. DOS was a competitor with CP/M mostly, iirc, and got to invent various standard and quirks all of its own, which passed on to Windows (which was originally a simple shell on top of dos until 95).
command.com was just the shell (like bash, zsh, Windows Terminal), not the kernel. Pre-NT Windows would use API calls to talk to the DOS kernel, bypassing command.com.
the Windows GUI win.exe would probably be launched by command.com, though, because it was specified in autoexec.bat, the batch of startup tasks designed to be read by command.com.
command.com could be closed after autoexec.bat had run.
the DOS kernel would generally only be used for 16-bit programs, 32-bit programs were managed by a newer kernel more towards the NT kernel.
the whole situation was a horrible mess and never worked very reliably.
We’re talking the first Microsoft drives, not the first drives that ever existed. Windows inherits from DOS. DOS was a competitor with CP/M mostly, iirc, and got to invent various standard and quirks all of its own, which passed on to Windows (which was originally a simple shell on top of dos until 95).
even 95 is still running dos at it’s core. NT4, 2000 finally moved away from loading shit on top of command.com
command.com was just the shell (like bash, zsh, Windows Terminal), not the kernel. Pre-NT Windows would use API calls to talk to the DOS kernel, bypassing command.com.
the Windows GUI win.exe would probably be launched by command.com, though, because it was specified in autoexec.bat, the batch of startup tasks designed to be read by command.com. command.com could be closed after autoexec.bat had run.
the DOS kernel would generally only be used for 16-bit programs, 32-bit programs were managed by a newer kernel more towards the NT kernel.
the whole situation was a horrible mess and never worked very reliably.