Opened 3 months ago

Last modified 3 months ago

#10809 new defect

WIN32: Command line is parsed but nothing prints

Reported by: Vhati Owned by:
Priority: normal Component: Port: Win32
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 (18)

comment:1 Changed 3 months ago by Vhati

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 Changed 3 months ago by digitall

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

comment:3 Changed 3 months ago by digitall

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 Changed 3 months ago by Vhati

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 Changed 3 months ago by digitall

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 Changed 3 months ago by digitall

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

comment:7 Changed 3 months ago by digitall

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

comment:8 Changed 3 months ago by digitall

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 Changed 3 months ago by criezy

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

comment:10 Changed 3 months ago by digitall

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

comment:11 Changed 3 months ago by criezy

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 Changed 3 months ago by bgK

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 3 months ago by bgK (previous) (diff)

comment:13 Changed 3 months ago by digitall

@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 Changed 3 months ago by digitall

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 Changed 3 months ago by digitall

Keywords: has-pull-request added

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

comment:16 Changed 3 months ago by Vhati

Last release binary that could print was 1.8.1.


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

comment:17 Changed 3 months ago by digitall

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 Changed 3 months ago by Vhati

@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.

Note: See TracTickets for help on using tickets.