3 ms·
No, it wasn't and no, it shouldn't be read as sarcastic. Microsoft should be praised for the backwards compatibility they enabled. That is a feat rare in operat
by nullindividual 2y ago
No, it wasn't and no, it shouldn't be read as sarcastic. Microsoft should be praised for the backwards compatibility they enabled. That is a feat rare in operating systems today.
- lproven 2y agoAll right, but in that case, I must ask you to explain the comment, because it make no sense to me at all. Firstly, the choice of backslash in DOS 2 didn't enable backwards compatibility with anything because nothing prior to DOS 2 used the backslash character for this. Secondly, I do not see any basis to say that somehow MS looked forward in time, at the future, and chose a character unused by any other OS. As early-1980s MS did not have a time machine and thus was not looking forwards, then how did that choice help future compatibility? How was the use of backslash better for Windows for Workgroups 3.11 (because that was the first one with its own VFAT filesystem that didn't just call DOS) and subsequent releases? How was a backslash preferable to anything else? How would using any other character be worse? Would choosing a character used by other OSes not have been _better_ for long term compatibility, aiding source code conversion and porting? I really do not see what you are trying to get at. Incidentally, I entirely agree that its compatibility record is astonishingly good, but I can't see any link from that to the choice of directory delimiter.
- nullindividual 2y agoWhen one speaks of Microsoft's backwards compatibility, they are referring to within the Microsoft domain of operating systems and APIs. If I can run an application from 1985 on modern day Windows, that is what backwards compat refers to and is quite unrivaled -- remember, the most stable ABI on Linux is Win32. > How was a backslash preferable to anything else? Because it existed prior to Windows 1.0 and beyond application compatibility, you also had to work with user familiarity. Heck, it is annoying enough to swap between macOS and Windows for Ctrl/Cmd-C and Ctrl/Cmd-V, or even within macOS between Mac applications and the Terminal. Or my worst personal enemy, Ctrl-H/Cmd-H (browser History vs. hide window) in a browser. Arg! > Would choosing a character used by other OSes not have been _better_ for long term compatibility, aiding source code conversion and porting? Which OS should they have chosen from? [0] Apple SOS [and all future versions of macOS]? VMS/OpenVMS? RiscOS? Domain/OS? TOPS/20? Stratus VOS? What made SysV or BSD special or 'a clear choice' in path separators in the '80s? > How would using any other character be worse? I don't believe any other character would be better or worse at the time backwards compatibility was ruled supreme at Microsoft. Since their operating systems already used the backslash character, and the preceding mention of user familiarity, and of course the code base is DOS which they probably didn't want to re-write due to effort and cost, they stuck with it. I certainly see a point in changing the path separator if you pulled a Mac OS Classic to Mac OS X style switch, but Microsoft never really did that. Yes, they had NT, but that needed to have compatibility with it's DOS-based sibling as it could also run DOS applications. Oh imagine the threads if they did switch to the forwardslash in Windows... "What else from Linux will Microsoft copy?!" "Did Microsoft switch to the Linux kernel?!". It would make for an exciting day in tech! I'm certainly not against Microsoft changing the path separator to the forwardslash. [0] https://en.wikipedia.org/wiki/Path_(computing) https://en.wikipedia.org/wiki/Path_(computing)