hmm not sure what's the "best" solution here: * either we fix start.exe to parse args from command line as cmd.exe does * or we move start.exe as a cmd.exe builtin command (as it should) if the former, IMO we'd better clone cmd.exe builtin commands args parsing code as the parsing is quite convoluted as it is, so one implementation is likely simpler to maintain - and review -; and agreed that cmd.exe's implementation is kinda ugly as it is) if the later, that looks like a better long term solution, would remove some duplication between start & cmd (esp in shell32 invocation....) but likely requires much more work. Started thinking of it, and the list grew rapidly (and I likely missed a couple of items \<g\>) * first start.exe has some Wine only code (see ntdll/unix/env.c) that should be kept functional if moved to cmd.exe * we likely need to keep the start.exe as: * ctrl-c handling in start.exe cannot be moved to cmd.exe (as the implemented behavior is different) * ctrl-c hit when start.exe is run from unix command line kills both start.exe and it's child; that needs to be preserved (and need killing grand child; quite sure cmd.exe doesn't do it properly) * we may have some external dependancies (potentially unix scripts, but not only) that depend on start.exe (not start): * redirect start.exe invocations to cmd.exe start ... for compatibility (and ensure it never creates a recursion - it shouldn't, as cmd shall recognize 'cmd start' as builtin start, whereas 'cmd start.exe' shall lookup for an external executable) * change some Wine internal code to call cmd.exe start instead of start.exe * fix the tests results in cmd.exe that should now pass so unless you're ready to explore all of this, I'd rather suggest to go for duplicating cmd.exe arg parsing in start.exe (and anyway that's the first step if we ever want to move start.exe as an builtin cmd.exe command) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10008#note_128512