Comment by rusanu | Hacker News Reader

Comment by rusanu | Hacker News Reader

Looking now at how Windows handles console application arguments, it sure looks broken. But you have to put your mindset in cca. 1990 and think what Windows applications looked like back then, and what was the model Microsoft was betting on. Arguments were passed via DDE[0], and then later all the bets were on OLE[1] and finally COM[2]. System components were all the time accessed via in-process DLLs communicating with services over LRPC[3]. In this world, the command line, the pipe philosophy and the 'less is more' mindset were not only not welcome, they were the adversary.

Even when finally it was aknowledged that the command shell needs some love too, the answer was PowerShell, which yet again defined an object interface between cmdlets[4].

[0] https://en.wikipedia.org/wiki/Dynamic_Data_Exchange [1] https://en.wikipedia.org/wiki/Object_Linking_and_Embedding [2] https://en.wikipedia.org/wiki/Component_Object_Model [3] https://en.wikipedia.org/wiki/Local_Procedure_Call [4] https://en.wikipedia.org/wiki/PowerShell#Pipeline

Since when was argument passing ever done with DDE? This structure dates back to DOS and starting programs with INT 21h: http://kipirvine.com/asm/articles/ExecChild.pdf

You know, in all these years I've never bothered to find out how DDE worked, having used COM instead, and now I find: https://msdn.microsoft.com/en-us/library/ms648774.aspx and it's a terrifying abomination built on wparam/lparam.

> In this world, the command line, the pipe philosophy and the 'less is more' mindset were not only not welcome, they were the adversary.

I agree that this is Microsoft's greatest heresy and also an effective tool against interop.

> Since when was argument passing ever done with DDE?

Umm... Windows 3.1, I think? It could use DDE to pass the path to the file opened in the File Manager to the program specified in the Registry.

That's a long way of saying that Microsoft spent many years promoting a overcomplicated bad ideas over simple correct ideas.

So true. After 25yrs using pcs/unix/macs, I've come to conclusion that it's deliberate on Microsoft side.

They create much more closed, difficult and obscure technology which needs, training, certification and lot of care (services provided by Microsoft).

Trust me: it's not deliberate. There is no conspiracy. Everyone I met on Windows is at least as well-intentioned as anyone working in the POSIX world. The reason Windows has some bad APIs is the same reason Unix has bad APIs: someone bootstraps a system quickly and doesn't see the problems that can arise from their choice of APIs; the system becomes wildly successful; and now everyone has to support these ill-conceived APIs.

Sure, Windows command-line argument passing is bad, but have you ever tried using wait/waitpid/wait4/waitid/etc.? That's a nightmare in the POSIX world; Windows has nice, clean process handles, not the garbage /proc stuff that makes it fundamentally impossible to write a safe pkill(1).

If you're writing a brand-new system, for the love of God, do a good job of designing the APIs. You will not have a chance to go back and fix the APIs later.

Uh, so much truth here. If I added music, this would be like the ballad of software. Once the cement has hardened on an application's design, reinforced with industrial strength needy customers who only want the next feature...that is game, set, match.

Nah, I'm far from consipracy theory here.

To list quickly from memory (and my game machine experiences) - all from windows 10 pro.

* new install with ms office, I run autoruns.exe and see that I have 70+ things being run on startup. Yikes. Default install.

* registry: multiple things, biggest for me: you can't easily move part (or all) of it between machines, due to being tied to specific machine: imagine in unix you can't move whole /etc between to a newly installed separate machine.

* still lack of decent package management (check chocolatey (BTW they try to do some work here): among dozens of problems they have, they still (and in fact probably never) can't tell you simple 'list all files of given package'. Don't event want to start laughing about appx microsoft newest invention: it does not return even HALF of default installed apps of new laptop.

* logging. During update 1607, process is stuck (6hrs, and still 'please wait'): no simple place (log) to analyze what's happening (and no, eventlog is not such place). All daemons and windows do not have sane logging with enough information constantly being written to logfiles to analyze problem (this is big and deliberate).

* file system mess: e.g. system drivers running with kernel permission installed in 'program files' (new dell xps from 2016) and also usual common day programs being installed in c:\windows - while windows happily allows it - again, clean new install :)

* naming of services/technologies and their (microsoft) general approach to architecture design (boundaries and namespaces): this is mess, one example among hundreds: check what is short name of background transfer service (the bits one) you need to restart if windows update (sic!) stops working - no, it's not bits or bts :)

This is only written on the phone high level things, There is on the net comprehensive listo of 500+ things could have been fixed.

So???

>promoting a overcomplicated bad ideas over simple correct ideas.

Encode the program name together with all arguments as one big string, discarding all type safety, spawn the process of your favorite shell, let that shell process the string in order to spawn one or multiple processes, in each process have the standard library process the arguments into an array called argv, and have your average process call out to yet another library to parse these string argument strings into flags and parameters, and prints a not standarized, potentially localized string if an error occurs, and if the error is fatal exits with a semi-standarized return code. The calling program tries to make sense of the output of the called program, often by fuzzy matching against known output.

That's the standard way how it's done since the beginning of Unix. Some APIs skip the shell, but that's a minor detail in all this. If this sounds simple and like the obviously best solution, then congratulations. The windows developers disagree and tried (and continue to try) to find a better way. They mostly failed so far, but I think we should thank them for at least trying to innovate.

If you use some API other than system(3) - even if you literally use a shell-script - it's:

1) serialize data structure to semi-typed array of strings 2) pass array of strings directly to target program 3) have target program parse the array of strings to flags & parameters

With no shell or C library touching the command line arguments at all.

The only way this could be more direct would be if you used JSON instead of arrays of strings, web-API style.

All applications in Windows receive a command line string, console or not.

Reply on news.ycombinator.com