Hi, thank you for taking the time to respond.
Re the command line arguments being a single string, this is what I'm referring to:
> For better or for worse1, Windows knows about only one command line string for each process. Because one string is not terribly useful, libraries conspire to provide the illusion of multiple command line arguments: before creating a subprocess, a program combines all argument strings into one command line string, and the newly-born subprocess, before calling main, splits this string into arguments and passes the arguments as argv. In principle, each program can parse the command line string differently, but most use the convetion that CommandLineToArgvW and the Microsoft C library understand. This convention is a good one because it provides a way to encode any command line argument as part of a command line string without losing information.
> The problem is that there is no ArgvToCommandLineW. How do we construct an argument string understood by CommandLineToArgvW?
Source https://blogs.msdn.microsoft.com/twistylittlepassagesallalik...
Having one command line string is passable if you only handle ASCII characters and consider whitespace a delimiter (as was the case in the days of DOS). But the moment you start needing to pass more complex data (as you often need to when you start writing shell scripts) then you quickly run into pain points.
Another drawback of a single string is you then limit the usefulness of writing alternative languages which are heavily exec orientated (shell languages). This is a particular pain point I've experienced with my own custom shell because I apply escaping rules to quotes and allow for other methods of quotations (such as proper support for nested quotes). However since Linux / UNIX treat all parameters as an array at all points in the stack it means I can consistently parse my own languages syntax and reliably pass that to the program I'm wishing to call. It means I can drop a variable as a parameter without having to manually escape / quote it for fear of whitespaces breaking the syntax (ie using variables like you would in "normal" language). But that simply does not translate well to Windows.
And finally there is also the painpoint that not all Windows CLI tools read from ARGV. Some don't even decode the single string parameter correctly. Theres better articles demonstrating this point so I won't waste more page space on this issue but suffice to say its a bit of a mess.
Re OOP explosion: I get the point you're making but all language paradigms have experienced a similar explosion in That time frame. Be it functional, logical, object oriented, etc. I get the need to emphasize the logic of Windows as an object oriented OS (a point I don't disagree with myself) but I just feel your example was a little overreacting - to the extent that you started undermining the crux of the point you were attempting to make.
Much like how your points about UNIX "everything is a file" was somewhat mislead. That didn't really become a thing until much later in UNIX's history (Plan 9 - UNIXs successor - really pioneered that concept and many ideas were then backported. Eg The /proc example you used isnt even available on UNIX as it's Linux specific. Plus your example was really more a reporting tool than a demonstration of file system objects. Theres better examples of your point in /proc such as the PIDs and their runtime parameters, and kernel setting that can be read and written to as a filesystem objects).
Re GUI Vs console. My point was really more about how if Microsoft were dependant on the console anyway to have made it their first GUI application then it's a great pity they did such a bodge job of it. I get that RDP was a necessity anyway - and it's fair to say the performance of RDP is really quite impressive - but back in the 90s I seem to recall most Windows shops still used to just throw a physical keyboard and mouse into their racks (usually via KVM) rather than deal with RDP. Where as "Unix" (BSD, Solaris, whatever) would be wired up via serial on the machines console port for remote access. So for the best will in the world, remote access still wasn't a popular choice on NT until it's relatively recent history where as it was the main way of interacting with UNIX-like systems from the get go. And that is my problem with how NT was designed. I can take or leave the whole GUI Vs command line debate - that's purely personal opinion. My issue was until network speeds etc all really caught up, Windows made it painful to work remotely. To an extent it still does as you have to wait for the damned RDP service to come up after a reboot (which would take half an hour after the reboot had finished on one Windows domain controller I used to manage) where as on Solaris / BSD / Linux / etc I can stream it's boot process from the moment the boot menu loads (in fact I've even installed Linux remotely via serial). Obviously we all now have OOB management tools like ilo or their respective cloud management tools so the shortcomings of the RDP service are somewhat mitigated there these days but how many years of NTs history has it taken us to get to that point where a _server_ no longer needs a physical monitor, keyboard and mouse wired up to it?
All in all it was an interesting read, even if I didn't agree with some of the specific points you were making. But then life would be dull if we all agreed on everything all of the time. :)