So essentially Windows 1.0 - Windows ME were all DOS based
That's
not quite accurate.
[...]
MS-DOS served two purposes in Windows 95.
- It served as the boot loader.
- It acted as the 16-bit legacy device driver layer.
[...]
Once in protected mode, the virtual device drivers did their magic. Among other things those drivers did was “
suck the brains out of MS-DOS,” transfer all that state to the 32-bit file system manager, and then shut off MS-DOS. All future file system operations would get routed to the 32-bit file system manager. If a program issued an int 21h, the 32-bit file system manager would be responsible for handling it.
And that’s where the second role of MS-DOS comes into play. For you see, MS-DOS programs and device drivers loved to mess with the operating system itself. They would replace the int 21h service vector, they would patch the operating system, they would patch the low-level disk I/O services int 25h and int 26h. They would also do crazy things to the BIOS interrupts such as int 13h, the low-level disk I/O interrupt.
[...]
In other words, MS-DOS was just an extremely elaborate
decoy. Any 16-bit drivers and programs would patch or hook what they thought was the real MS-DOS, but which was in reality just a decoy. If the 32-bit file system manager detected that somebody bought the decoy, it told the decoy to quack.
[...]
(The idea being "If they didn't care about compatibility with legacy hardware, they'd have bought Windows NT".)
Speaking of which, the mixed opinions on Windows ME are down to a similar compatibility hack that didn't go as well.
Windows ME supports two different generations of driver APIs but, if you mix drivers from both generations, you're likely to get instability. People who tried it with earlier hardware (eg. upgraders) remember it as instability hell. People who bought hardware that was new enough to be entirely on the newer model remember it fondly.
[doublepost=1567326984,1567326082][/doublepost]
But a DOS like terminal is still part of NT based windowses, with their drive letters and backslashes that came from CP/M
The drive letters came from CP/M and DOS didn't gain the concept of folders until 2.0.
The backslash as a path separator came about because,
for DOS 1.0, IBM supplied various utilities and chose to follow DEC convention in using
/ to signal a command-line switch, rather than the UNIX convention of
-. Then, for DOS 2.0, they couldn't break backwards compatibility when they introduced folders, so they went with the next-best thing.
Here's a little known secret about MS-DOS. The DOS developers weren't particularly happy about this state of affairs - heck, they all used Xenix machines for email and stuff, so they were familiar with the *nix command semantics. So they coded the OS to accept either "/" or "\" character as the path character (this continues today, btw - try typing "notepad c:/boot.ini" on an XP machine (if you're an admin)). And they went one step further. They added an undocumented system call to change the switch character. And updated the utilities to respect this flag.
And then they went and finished out the scenario: They added a config.sys option, SWITCHAR= that would let you set the switch character to "-".
Which flipped MS-DOS into a *nix style system where command lines used "-switch", and paths were / delimited.
I don't know the fate of the switchar API, it's been long gone for many years now.
but the intentions prior to this shift was to be OS/2 compatible.
That's an understatement. the NT kernel has a concept of "subsystems", with things like drive letters being part of the Win32 subsystem. It was originally intended to have OS/2, Win32, and POSIX subsystems and Windows 10's WSL is the latest incarnation of the POSIX subsystem. Internally, it uses a singly-rooted hierarchy that outdoes UNIX on the "
everything has a path on the same tree" front.
NTFS is also set up that way, with both Win32 and POSIX personalities. That's why WSL can have case-insensitive files with special characters that Win32 tools have trouble with and why, if you mount an NTFS drive on Linux, you can confuse Windows tools with names that differ only in case. (eg. If you try to delete one, you're likely to delete all of them.)
Heck, internally, the NT kernel's object manager actually
allows a wider range of characters in filenames than POSIX because it uses counted strings rather than NULL-terminated ones, so it can use NULL as a character in object paths, leaving the path separator as the only character that cannot be used in names.
...though Linux still beats Windows NT for path length. Both impose a 255-character limit on filename lengths, but, even if you opt out of the legacy 260-character path-length limit on Win32 APIs (Chosen because
C:\<256 chars>NUL for
historical reasons), the NT kernel's counted strings impose a hard limit of 32,767 characters in a path. Linux, on the other hand, does have path APIs in the C standard library which are limited to 4096 characters, but it's possible to
work around them and then there's literally
no hard-coded limit to how long a path can be on Linux.
(And on several other Linux handhelds but those are no longer used regularly)
