http://bugs.winehq.org/show_bug.cgi?id=28192
Summary: regedit: The usage message arrives too late in the wine console Product: Wine Version: 1.3.26 Platform: x86 OS/Version: All Status: NEW Severity: normal Priority: P2 Component: programs AssignedTo: wine-bugs@winehq.org ReportedBy: fgouget@codeweavers.com
To reproduce this start the console with 'wine wineconsole cmd' and then type 'regedit /?' in the wine console.
You will get something like this:
c:>regedit /?
c:>Usage: regedit filename regedit /E filename [regpath] regedit /D regpath [...]
Notice how the second wineconsole prompt appears before the regedit usage? I believe this happens because regedit uses msvcrt's stdio functions: it uses the '$(top_srcdir)/include/msvcrt' headers and that seems to be enough for it to link with msvcrt. So there are probably two things here:
* This looks like a bug in the MSVCRT stdio functions.
* regedit should probably use the WriteConsole() / WriteFile() functions anyway like all the other Wine tools. See the XCOPY_wprintf() function in programs/xcopy/xcopy.c or the output_*() functions in programs/net/net.c for a model on how to do this. And if making the switch to WriteConsole(), verify that running 'regedit /?' still works fine in a regular xterm or equivalent.
(split off from bug 13861)
http://bugs.winehq.org/show_bug.cgi?id=28192
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source Severity|normal |minor
http://bugs.winehq.org/show_bug.cgi?id=28192
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|All |other
http://bugs.winehq.org/show_bug.cgi?id=28192
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
http://bugs.winehq.org/show_bug.cgi?id=28192
Eric Pouech eric.pouech@orange.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@orange.fr
--- Comment #1 from Eric Pouech eric.pouech@orange.fr 2011-10-23 03:05:10 CDT --- The reason of this bug is rather different from what's explained in #1. Basically, regedit is compiled as a GUI program, but wants to use the console.
What cmd does is: - if the child program (to be spawned from command line) is a CUI, then cmd launches it, and waits for its termination - if the child program (to be spawned from command line) is a GUI, then cmd launches it, and prompts the user for the next command without waiting for its termination
This what happens here (and explains the arrival of the child output after the prompt)
From various testings (in comparaison to windows):
- cmd behavior is correct - there is no such a beast as regedit on windows (ie a program that could be both used as a CUI and GUI program) - windows' regedit is a GUI program (as wine's regedit) - a GUI program, when launched from cmd, is no longer attached to cmd's console (didn't test yet whether it's cmd implementation, or Kernel32.CreateProcess's implementation) ; even if the output is redirected to a file, nothing is written to it (so I"d rather think it's cmd that doesn't ask for console & handle inheritance in case of a GUI child) (to be confirmed by further testings)
From the possible fixes:
A/ change regedit so that it no longer output to console (even if we keep the commands) B/ in cmd, when launching a GUI program, call WaitForInputIdle (in case it's a used as a CUI program)
B/ is the simplest fix, but is rather different from windows behavior (as we need to inherit console in child process) A/ seems closer to windows behavior, but we'll miss all the outputs from regedit, which is a pain.
Better ideas welcomed.
A+
http://bugs.winehq.org/show_bug.cgi?id=28192
Jason Edmeades us@edmeades.me.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |us@edmeades.me.uk Component|programs |cmd
http://bugs.winehq.org/show_bug.cgi?id=28192
--- Comment #2 from Jason Edmeades us@edmeades.me.uk 2012-11-27 15:48:37 CST --- Looking into this I would say there's a two problems here:
[This bug] - Under windows, a GUI program is not attached (by default) to a console But you can redirect stdout / stderr to a file, so I think its more that the program is launched without the stdout/stderr being attached to anything - Under wine, anything you launch can write to the console, which is the launching window
[Bug 17124] - Under windows, createprocess for an application flagged as a CUI app will spawn a new console, if one is not attached to the process - even if the CreateProcess call does not specify CREATE_NEW_CONSOLE - Under wine, if you do not specify create new console, you run in the existing console meaning it interleaves with the spawning application
Note that a GUI app can call AllocConsole to allocate itself a console (a new one) if the application does not have one. In my limited testing it appears to pop up a DOS type window (on windows). It would appear that a GUI app which has called AllocConsole, which subsequently spawns a CUI application, passes the allocated console to the spawned CUI app.
I think (A) in Eric's comment#1 is the only option, and we also need to do the reverse (bug#17124). Simple testing implies if a command app running in cmd.exe spawns a gui app using createprocess, then the created process has no stdout capability to the console, ie its createprocess not cmd which does it.
https://bugs.winehq.org/show_bug.cgi?id=28192
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |Abandoned?
--- Comment #3 from Ken Sharp imwellcushtymelike@gmail.com --- Is this still an issue in Wine 1.7.45 or later?
https://bugs.winehq.org/show_bug.cgi?id=28192
--- Comment #4 from François Gouget fgouget@codeweavers.com --- This bug is still present.
https://bugs.winehq.org/show_bug.cgi?id=28192
--- Comment #5 from François Gouget fgouget@codeweavers.com --- Note that 'regsvr32 /?' has the same issue.
https://bugs.winehq.org/show_bug.cgi?id=28192
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #6 from joaopa jeremielapuree@yahoo.fr --- Bug still occurs with wine-8.7.
https://bugs.winehq.org/show_bug.cgi?id=28192
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|Abandoned? |
https://bugs.winehq.org/show_bug.cgi?id=28192
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #7 from François Gouget fgouget@codeweavers.com --- * On Windows 11 regedit has no usage message (it ignores /? and /h, exits right away with /help and many others like /hell). In Wine regedit now shows the usage message in a window. So that side-steps this issue. * On Windows 11 regsvr32 shows a usage error message for /?, /h and /help. In Wine regsvr32 does the same.
So this issue is no longer present.
https://bugs.winehq.org/show_bug.cgi?id=28192
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 9.9.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla