Opened 5 years ago

Closed 4 years ago

#10809 closed defect (invalid)

WIN32: Command line is parsed but nothing prints

Reported by: Vhati Owned by: sluicebox
Priority: normal Component: Port: Win32
Version: Keywords: has-pull-request
Cc: Game:

Description

ScummVM 2.1.0git3879-gb203b61b38 (Nov 13 2018 04:24:02)
Windows 7 64bit

Args *are* getting parsed. I can launch a specific game or set debug flags, for example.

But running scummvm.exe with --help or --list-targets doesn't print anything.


Running a port of the linux 'file' command tells me the dev build was compiled as a GUI executable (as opposed to console).

PE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows



IIRC GUI executables can't use stdout?

https://stackoverflow.com/questions/54536/win32-gui-app-that-writes-usage-text-to-stdout-when-invoked-as-app-exe-help

Change History (19)

comment:1 by Vhati, 5 years ago

ResidualVM is a console executable, and it can print.

PE32 executable (console) Intel 80386 (stripped to external PDB), for MS Windows



ResidualVM 0.4.0git351-g0f3cf3e5 (Aug 29 2018 09:56:24)

comment:2 by digitall, 5 years ago

Can you link to the specific download executable causing the issue?

comment:3 by digitall, 5 years ago

We have had a number of reports of similar issues before.

There are two issues open on this currently, #9804 and #10174

This is probably an option missing from cross compilation builds on buildbot...

comment:4 by Vhati, 5 years ago

Can you link to the specific download executable causing the issue?

Buildbot nightly dev.

https://buildbot.scummvm.org/snapshots/master/mingw-w32-master-latest.zip

comment:5 by digitall, 5 years ago

Thanks. Have downloaded for testing.

Update: UGH. We appear to have broken nightly builds for WindowsXP. I get an error box:
"The procedure entry point AcquireSRWLockExclusive could not be located in the dynamic link library KERNEL32.dll"

This is probably associated with switching over to SDL2.dll. That relevant API is only present on Windows Vista or newer i.e. Vista/8/10 :
https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-acquiresrwlockexclusive

comment:6 by digitall, 5 years ago

Summary: Command line is parsed but nothing printsWIN32: Command line is parsed but nothing prints

comment:7 by digitall, 5 years ago

Hmm. Have checked buildbot. The symbol is present in fluidsynth:
"Binary file x86_64-w64-mingw32/lib/libfluidsynth.a matches"

comment:8 by digitall, 5 years ago

Hmm. Not exactly sure how that was done, but it was cross compiled on the buildbot from v1.0.9, but the tree for that does not have that symbol so might be due to another function which pulls that in to implement :/

comment:9 by criezy, 5 years ago

This is not a new issue. See bugs #9804 and #10174.

comment:10 by digitall, 5 years ago

@criezy: *cough* duplicate of the duplicates! Seriously, I already linked those in comment:3

comment:11 by criezy, 5 years ago

Ha right sorry. I missed comment 3. Reading those bugs on a phone is not ideal :p
But I am wondering if we should close some of those as duplicate and report interesting comments from those on the one that remains open. I might do that once I get access to a computer.

comment:12 by bgK, 5 years ago

Regarding the loss of compatibility with Windows XP, that was my fault. I've added FluidSynth to the win32 toolchains recently using fluidsynth-lite. I did dot notice it had increased the required windows version between the version used for the 2.0.0 release build and the version I compiled for buildbot. I've compiled an older version of fluidsynth-lite on buildbot that should fix the issue.

Last edited 5 years ago by bgK (previous) (diff)

comment:13 by digitall, 5 years ago

@bgK: Thanks for sorting that. I had thought that it was my fault as I thought that fluidsynth compilation was from when I last updated the libraries! :)

Will wait for next nightly to run and then retest with that to confirm WinXP compatibility, and then see if I can replicate the reported issue with console output.

comment:14 by digitall, 5 years ago

OK. Have downloaded last nightly. This now works fine again on WinXP and I can replicate the issue which Vhati is describing i.e. the command line is parsed as --no-console works, but any command line calls to ScummVM produce no output in the original window nor in a console status window. :|

comment:15 by digitall, 5 years ago

Keywords: has-pull-request added

@bgK has provided a PR to fix this:
https://github.com/scummvm/scummvm/pull/1405

comment:16 by Vhati, 5 years ago

Last release binary that could print was 1.8.1.


ScummVM 1.8.1 (May 22 2016 15:57:02)

comment:17 by digitall, 5 years ago

Hmm. There is no clear commit between v1.8.1 and v1.9.0 which likely caused this, but it could be due to whether sdl-config (or pkg-config) returns the -mwindows and other flags in it's output.

This previously caused the same bug, but these were resolved in various ways. These are bugs #2928, #9461, #5576 and #6907 ... and of course, #9804 and #10174.

comment:18 by Vhati, 5 years ago

@digitall:

it could be due to whether sdl-config (or pkg-config) returns the -mwindows and other flags in it's output.

Editing out the two mentions of "-mwindows" in "MinGW/bin/sdl-config" fixed it for my own MSYS environment.

comment:19 by sluicebox, 4 years ago

Owner: set to sluicebox
Resolution: invalid
Status: newclosed

This ticket is a trainwreck. Windows GUI executables cannot use stdout.

Note: See TracTickets for help on using tickets.