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.
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.
so many ages have passed since then…