https://bugs.winehq.org/show_bug.cgi?id=46125
--- Comment #9 from Lantizia s.maddox@lantizia.me.uk --- And cmd.exe only chooses to pass it to winevdm because it realises it can't run it right? (due to it being a 16-bit DOS executable).
Then winevdm creates the DOSBOx config file, putting into it that... whatever it got from cmd.exe? (so it's neither winevdm's or DOSBox's fault).
If so... surely cmd.exe could be programmed to choose to do this (pass to winevdm) **before** parsing it/handling the redirection. Especially if it's not even in the position to actually run executable in question! And **especially** if it's QUOTED! :D
I think that's the only way of solving this.
The idea of teaching DOSBox to redirect stdin given to it... would likely receive resistance from the DOSBox team. I'm only guessing that based on the fact that DOSBox was never been designed to run single commands in the fashion Wine is using it in. Rather, it runs whatever is in the AUTOEXEC... so (if the AUTOEXEC had more than one command) which command would receive the redirected stdin?
Going back to my first post...
This all started because the official patch setup program for 'Birth of the Federation' (I've tried to link that app as an affected app on this bug... but for some reason it's not saving it) is an InstallShield/PackageForTheWeb setup program that calls a 16-bit DOS zip.exe to update some files the game uses (which are actually zip files, just with different file endings). This basically fails because the filename containing the list of files to update (within the zip) is never actually given to DOSBox to give to zip.exe.
In short... this isn't a theoretical scenario, it's really breaking something (and possibly anything else that does something similar).