[Bug 46125] New: DOS input redirection attempts are not passed into DOSBox temporary config file
https://bugs.winehq.org/show_bug.cgi?id=46125
Bug ID: 46125 Summary: DOS input redirection attempts are not passed into DOSBox temporary config file Product: Wine Version: 3.0.3 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dos Assignee: wine-bugs@winehq.org Reporter: s.maddox@lantizia.me.uk Distribution: ---
Created attachment 62771 --> https://bugs.winehq.org/attachment.cgi?id=62771 Screenshot of DOSBox running when prompted to by Wine
Lo,
So I basically stumbled upon this one when trying to apply a patch for a game, although the patch was an InstallShield 5 program (self-extracting with PackageForTheWeb) - the patching would actually be done by it just calling an exe->pif->bat that runs a 16-bit zip.exe program which updates a ZIP file of the games with some replacement files.
I've worked out this is a Wine issue and there is an easier way to test it (as the patch above would need you to have the game installed etc...)
# Grab an old 16-bit version of zip.exe (or anything that takes stdin using the '<' symbol) wget ftp://retronn.de/mirrors/garbo/pc/goldies/zip20x.zip unzip zip20x.zip zip.exe
# Run it wine cmd /c 'zip -@ x.zip < zip.exe'
# Witness what you will see in the screenshot I have attached.
The '< zip.exe' portion of the command just isn't written to the DOSBox temporary config file... (e.g. /home/lantizia/.wine/dosdevices/c:/users/lantizia/Temp/cfg4950.tmp )
[autoexec] mount -z y mount c /home/lantizia/.wine/dosdevices/c: mount d /home/lantizia/.wine/dosdevices/d: mount e /home/lantizia/.wine/dosdevices/e: mount z /home/lantizia/.wine/dosdevices/z: Z: cd \home\lantizia\DOWN~NTG config -securemode Z:\home\lantizia\DOWN~NTG\zip.exe -@ x.zip exit
https://bugs.winehq.org/show_bug.cgi?id=46125
s.maddox@lantizia.me.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|dos |kernel32
--- Comment #1 from s.maddox@lantizia.me.uk --- Changing component to kernel32
Reason: I have run it with a trace and can see winevdm never receives the arguments when it is called initially...
715225.825:002f:0030:Starting process L"C:\windows\system32\winevdm.exe" (entryproc=0x7effc3c0) 715225.825:002f:0030:trace:ntdll:NtQueryInformationProcess (0xffffffff,0x00000007,0x34feb8,0x00000004,(nil)) 715225.825:000c:000d:trace:heap:RtlFreeHeap (0x10000,30000062,0x73ed0): returning TRUE 715225.825:000c:000d:Ret advapi32.RegQueryValueExA() retval=00000000 ret=7fbd6ea9b0f3 715225.825:000c:000d:Call advapi32.RegCloseKey(00000068,) ret=7fbd6ea9b0ad 0030: get_process_info( handle=ffffffff ) 0030: get_process_info() = 0 { pid=002f, ppid=0008, affinity=00000fff, peb=7ffdf000, start_time=1d479e6156f2390 (-0.5820840), end_time=0, exit_code=259, priority=2, cpu=x86, debugger_present=0, debug_children=1 } 000d: close_handle( handle=0068 ) 000d: close_handle() = 0 715225.825:002f:0030:Call ntdll.RtlAllocateHeap(00110000,00000000,0000000a) ret=7effaa84 715225.825:000c:000d:Ret advapi32.RegCloseKey() retval=00000000 ret=7fbd6ea9b0ad 715225.825:000c:000d:trace:shell:HCR_GetClassNameA -- (Query file associations) 715225.825:000c:000d:trace:shell:DllGetClassObject CLSID:{a07034fd-6caa-4954-ac3f-97a27216f98a} (Query file associations),IID:{00000001-0000-0000-c000-000000000046} (IID_IClassFactory) 715225.825:000c:000d:trace:shell:DllGetClassObject index[10] 715225.825:000c:000d:Call ntdll.RtlAllocateHeap(00010000,00000000,00000030,) ret=7fbd6eae12ed 715225.825:002f:0030:trace:heap:RtlAllocateHeap (0x110000,30000062,0000000a): returning 0x18aa78 715225.825:002f:0030:Ret ntdll.RtlAllocateHeap() retval=0018aa78 ret=7effaa84 715225.825:002f:0030:Call KERNEL32.GetCommandLineA() ret=7effb35d 715225.825:002f:0030:Ret KERNEL32.GetCommandLineA() retval=001874b0 ret=7effb35d 715225.825:002f:0030:trace:winevdm:main GetCommandLine = 'winevdm.exe --app-name "Z:\home\lantizia\Downloads\zip.EXE" zip -@ x.zip ' 715225.825:002f:0030:trace:winevdm:main appname = 'Z:\home\lantizia\Downloads\zip.EXE' 715225.825:002f:0030:trace:winevdm:main cmdline = '-@ x.zip' 715225.825:002f:0030:trace:winevdm:main argv[0]: 'winevdm.exe' 715225.825:002f:0030:trace:winevdm:main argv[1]: '--app-name' 715225.825:002f:0030:trace:winevdm:main argv[2]: 'Z:\home\lantizia\Downloads\zip.EXE' 715225.825:002f:0030:trace:winevdm:main argv[3]: 'zip' 715225.825:002f:0030:trace:winevdm:main argv[4]: '-@' 715225.825:002f:0030:trace:winevdm:main argv[5]: 'x.zip'
There should be a argv[6] and possibly argv[7] (depends on if the '<' and the 'zip.exe' get separated).
I think the issue is somewhere in 'RTL_USER_PROCESS_PARAMETERS' around line 2482 of this file...
https://source.winehq.org/git/wine.git/blob/e9e12bda62fee68e9fbac5849f7ad1e1...
Also just in case if anyone is wondering, the example command of...
zip -@ x.zip < zip.exe
Basically just means update (or possibly create if non-existent) x.zip and put into the files mentioned in the text file of 'zip.exe' - but obviously 'zip.exe' is not a text file :) So it will error of course - but this is just a test to see if Wine can actually pass the '< zip.exe' part over when calling any command with winevdm/dosbox that has 'input redirect' (as I believe DOS called it).
https://bugs.winehq.org/show_bug.cgi?id=46125
s.maddox@lantizia.me.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
https://bugs.winehq.org/show_bug.cgi?id=46125
s.maddox@lantizia.me.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |ftp://retronn.de/mirrors/ga | |rbo/pc/goldies/zip20x.zip
https://bugs.winehq.org/show_bug.cgi?id=46125
Alberto Salvia Novella es20490446e@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |es20490446e@gmail.com
--- Comment #2 from Alberto Salvia Novella es20490446e@gmail.com --- Shall be fixed at the Mime level: https://bugs.winehq.org/show_bug.cgi?id=47355
https://bugs.winehq.org/show_bug.cgi?id=46125
--- Comment #3 from Lantizia s.maddox@lantizia.me.uk --- (In reply to Alberto Salvia Novella from comment #2)
Shall be fixed at the Mime level: https://bugs.winehq.org/show_bug.cgi?id=47355
I'm not sure this is relevant at all - see my comments on your bug you've linked to.
https://bugs.winehq.org/show_bug.cgi?id=46125
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #4 from Zebediah Figura z.figura12@gmail.com --- I don't think there's a Wine bug here, but rather, bash or cmd is stealing the operator. If I run:
hazel@watership$ echo 'zip.exe' > names hazel@watership$ wine zip.exe -@ x.zip < names DOSBox version 0.74-3 Copyright 2002-2019 DOSBox Team, published under GNU GPL. --- CONFIG:Loading primary settings from config file /home/hazel/.dosbox/dosbox-0.74-3.conf CONFIG:Loading additional settings from config file /home/hazel/.wine/dosdevices/c:/users/hazel/Temp/cfg87cf.tmp MIXER:Got different values from SDL: freq 44100, blocksize 512 ALSA:Can't subscribe to MIDI port (65:0) nor (17:0) MIDI:Opened device:none SHELL:Redirect input from names hazel@watership:~/Downloads/zip$ unzip -t X.ZIP Archive: X.ZIP testing: zip.exe OK No errors detected in compressed data of X.ZIP.
Similarly, if running from cmd, the < can be escaped with a preceding caret.
Unless it runs with an unescaped < in Windows (and I don't have a 32-bit machine to test with), I don't think there's a bug here.
https://bugs.winehq.org/show_bug.cgi?id=46125
--- Comment #5 from Lantizia s.maddox@lantizia.me.uk --- (In reply to Zebediah Figura from comment #4)
Unless it runs with an unescaped < in Windows (and I don't have a 32-bit machine to test with), I don't think there's a bug here.
It does.
You changed the condition of the test by removing the quotes (which I used in my example) to swap them out for an escaped operator. Which is a luxury you don't always get when it's closed source Windows software running the commands (see my original post as to how this started)... rather than the simplified example I've made with zip.exe (which is more to demonstrate the problem).
Just tried this inside Windows XP 32-bit (which still has 16-bit support)... The same command with single quotes gives 'The system cannot find the file specified', but using double quotes and it runs just fine (by fine I mean... zip.exe runs and attempts to read zip.exe as though it's a plain text file full of names and errors on the garbage)...
cmd /c "zip -@ x.zip < zip.exe"
It also worked just fine without any quotes...
cmd /c zip -@ x.zip < zip.exe
Turning to Windows 98 now... same command with single quotes gets you 'File not found' and double quotes gets you "Bad command or file name". But it's all irrelevant as it still works just fine without any quotes at all...
command /c zip -@ x.zip < zip.exe
Of course this can't be blamed on DOSBox as Wine has literally forgone actually putting the full command in the DOSBox configuration file. When looking at this DOSBox config file, it's fine that Wine removed the quotes (because if DOSBox works anything like XP/98, it doesn't need them anyway)... but it has cut off the end (and bash can't be blamed for that, as it is quoted).
https://bugs.winehq.org/show_bug.cgi?id=46125
--- Comment #6 from Alexandre Julliard julliard@winehq.org --- Without the quotes, cmd.exe handles the redirection and pipes the file into the standard input, just like on Windows. The issue is that DOSBox doesn't connect its standard input to the DOS app.
https://bugs.winehq.org/show_bug.cgi?id=46125
--- Comment #7 from Lantizia s.maddox@lantizia.me.uk --- (In reply to Alexandre Julliard from comment #6)
Without the quotes, cmd.exe handles the redirection and pipes the file into the standard input, just like on Windows. The issue is that DOSBox doesn't connect its standard input to the DOS app.
I see this as a potentially a valid argument had I not used quotes at all... but I did (see original post).
Wine is choosing (as it's a 16-bit executable) to swap out 'cmd /c' for DOSBox... but there is only really ONE argument after that (due to it being quoted)... and that is the ENTIRETY of what is quoted.
So it's that entirety that should be written out to the DOSBox config file... which Wine creates. I've even show a Wine trace (see comment #1), showing Wine iterate over the internal components of this argument... which it shouldn't need to do, as it is quoted!
I'm sure on Windows XP (when double quotes are used) it doesn't do stdin to cmd.exe but rather to zip.exe (as it's inside the quotes).
https://bugs.winehq.org/show_bug.cgi?id=46125
--- Comment #8 from Alexandre Julliard julliard@winehq.org --- I think you are confused about how Wine works. If you run cmd /c, Wine will launch cmd.exe and pass it the full (quoted) command line. Then cmd.exe will parse it, handle the redirection, and pass the rest of the command line to winevdm, which will launch DOSBox. By the time we get to winevdm, the redirection has been handled, so there's nothing to put into the DOSBox command file.
It works exactly the same on Windows. If you run cmd /c "foo.exe <bar", foo.exe never sees the "<bar" portion.
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).
https://bugs.winehq.org/show_bug.cgi?id=46125
--- Comment #10 from Alexandre Julliard julliard@winehq.org --- cmd.exe doesn't know that it's a DOS app, it just passes it to CreateProcess. The winevdm redirection is done in ntdll.
https://bugs.winehq.org/show_bug.cgi?id=46125
--- Comment #11 from Lantizia s.maddox@lantizia.me.uk --- Wherever it's done within Wine, there is no sense in Wine being involved in the redirection to a program it can't actually run... especially when the redirection wasn't given to 'wine' itself, it was done within quotes.
However it's solved, wherever the bug lies... this is still a bug as it doesn't behave like it would on an actual Windows system... and is breaking things.
Can we (after 26 months) get the status of this changed from UNCONFIRMED?
https://bugs.winehq.org/show_bug.cgi?id=46125
--- Comment #12 from Alberto Salvia Novella es20490446e@gmail.com --- I have requested the dosbox-staging developers to give feedback on this at: https://github.com/dosbox-staging/dosbox-staging/issues/834
https://bugs.winehq.org/show_bug.cgi?id=46125
Lantizia s.maddox@lantizia.me.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|3.0.3 |6.0
https://bugs.winehq.org/show_bug.cgi?id=46125
Lantizia s.maddox@lantizia.me.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|kernel32 |ntdll
https://bugs.winehq.org/show_bug.cgi?id=46125
Lantizia s.maddox@lantizia.me.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major
https://bugs.winehq.org/show_bug.cgi?id=46125
DOSFreak d0sfreak@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |d0sfreak@yahoo.com
--- Comment #13 from DOSFreak d0sfreak@yahoo.com --- The issue here is that the Windows game using the Windows Installshield executable that calls a 16bit DOS Info-Zip zip program to update files from the patch to the installed game stbof.res.
Any Windows 64bit OS will not be able to do this since the 16bit Info-Zip will not run. You can replace the 16bit Info-Zip with a 32bit one but I can't test since it seems my ISO already matches the files that exist in the patch so no change occurs. You could possibly jump through some hoops on windows to possibly get the patch to call DOSBox and then have it do the patch process but that wouldn't make any sense because DOSBox is a DOS Game emulator not a replacement for the Commmand Prompt or NTVDM. You are better off using a fixed patched, diffing a patched vs non-patched directory or patching the game and putting it on ftp somewhere ;)
For potentially fixing the badly put together patch you can acquire compiled binaries for the win32 of Info-zip here: http://gnuwin32.sourceforge.net/packages/zip.htm http://gnuwin32.sourceforge.net/packages/bzip2.htm
If you don't want to rely on the patch to update the files or want to test you can try the following in a batch run from the patch folder assuming you are using a 64bit Windows OS then you'll need the binaries from above:
echo off for /F "skip=2 tokens=1,2*" %%A in ('reg query "HKLM\SOFTWARE\WOW6432Node\Microprose\Star Trek: BOTF" /v installpath') do (zip -@ "%%~C" < patch.lst)
The above is pointless though since the unofficial XP patch already includes the 1.02 files and runs properly on Windows 10 and that package replaces Info-Zip with 7za which is a win32 CLI of 7-zip so it should work on Wine as well but I haven't tested it.
http://gaming.trekcore.com/birthofthefederation/downloads.html
https://bugs.winehq.org/show_bug.cgi?id=46125
--- Comment #14 from Lantizia s.maddox@lantizia.me.uk --- Figuring out workarounds specific to how ST-BOTF does patching wasn't the aim of filing this bug. The actual problem isn't going to be specific to just one app, but rather it's generic problem (see the title of the bug). However thanks for doing the research, but I'd already figured out a few similar workarounds like those you mentioned for ST-BOTF anyway.
Essentially you're trying to treat symptoms and not the cause (and oddly from a 64-bit Windows 10 perspective... which most Wine users won't be using).
But when you said... "DOSBox is a DOS Game emulator not a replacement for the Commmand Prompt or NTVDM".
That's interesting! It may be that the underlying bug here is the expectations Wine has on DOSBox filling this role, in the first place.
But I still think in this particular case, the fix is to just get Wine to properly write out that DOSBox temporary config file in a way which includes any '<' symbol and whatever comes after it (particularly as they were given to Wine **in quotes**). Where, whichever part of Wine is responsible, is clearly neglecting to do... for whatever reason.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla