That's a long way of saying that Microsoft spent many years 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.
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.
They create much more closed, difficult and obscure technology which needs, training, certification and lot of care (services provided by Microsoft).
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.
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???