[Bug 28192] New: regedit: The usage message arrives too late in the wine console
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(a)winehq.org ReportedBy: fgouget(a)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) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28192 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source Severity|normal |minor -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28192 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- OS/Version|All |other -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28192 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28192
Eric Pouech <eric.pouech(a)orange.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |eric.pouech(a)orange.fr
--- Comment #1 from Eric Pouech <eric.pouech(a)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+
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28192 Jason Edmeades <us(a)edmeades.me.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |us(a)edmeades.me.uk Component|programs |cmd -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=28192 --- Comment #2 from Jason Edmeades <us(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=28192 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |Abandoned? --- Comment #3 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- Is this still an issue in Wine 1.7.45 or later? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=28192 --- Comment #4 from François Gouget <fgouget(a)codeweavers.com> --- This bug is still present. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=28192 --- Comment #5 from François Gouget <fgouget(a)codeweavers.com> --- Note that 'regsvr32 /?' has the same issue. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=28192 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #6 from joaopa <jeremielapuree(a)yahoo.fr> --- Bug still occurs with wine-8.7. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=28192 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|Abandoned? | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=28192 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from François Gouget <fgouget(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=28192 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #8 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 9.9. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla