4 ms·

Hey Laumars - Console PM and author of the post here: Fair points in part, though … Remember that things like Remote Desktop obviated the pressing need for co

Hey Laumars - Console PM and author of the post here: Fair points in part, though … Remember that things like Remote Desktop obviated the pressing need for command-line --> remote command-line access for many years. RDP quickly evolved into a very efficient way of remoting the entire desktop experience, not just Command-Line - something that was particularly necessary until PowerShell started to mature due to Windows' heavy GUI tool influence (for better and worse). Don't despair though - there's a VERY interesting post coming soon on this subject, that I think you'll enjoy! ;) I summarized 20 years of history: Simula arrived in '68, Smalltalk in '72 and then, other than research efforts, relatively little until CFront/C++ around '85. After that there was a new variant of C++ or new object oriented language almost every 8-12 months ever since - ObjectBASIC, Modula-2, ObjectPascal, Delphi, Java, Python, C#, Ruby, etc. It was practically a language explosion. And, of course NT started as a command-line OS. All new OS' start that way it's the simplest UX to get running. The Windows GUI wasn't slapped on at the end though - it arrived relatively quickly since Microsoft was able to leverage much of the experience of having build Windows 3.x/9x etc. previously. Command-line args are not all passed as a single string. In Windows, args are separated by space. If you use C/C++ and others, you get argv and argc, or in C# you get an array of space separated values. Alas, when NT came along it was seen as EXTREMELY important to make it easy to run/port MS-DOS scripts and tools to encourage migration and adoption. By this time, so many tools used so many ways of specifying args and values … / vs. \ vs. - vs. none, /o=foo, /o foo, etc. … that it was practically impossible to both support backward compat while rationalizing usage. PowerShell, though, has done much to make args MUCH more consistent, self-documenting, etc. This said, yes, it'd be AWESOME if args could be rationalized and handled in a more consistent manner. Had a fascinating discussion about just this the other day. Stay tuned to our blog ;)

laumars 8y ago
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/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/ 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. :)

laumars 8y ago

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/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/ 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. :)