Opened 16 months ago

Last modified 10 months ago

#10613 new defect

ScummVM 2.0.0 on Windows 98

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

Description

ScummVM 2.0.0 crashes immediately on launch on Windows 98. A dialog box appears, saying:

The WINSPARKLE.DLL file expects a newer version of Windows. Upgrade your Windows version.

Running scummvm -v outputs:

A device attached to the system is not functioning.

According to the FAQ, Windows 98 is a supported platform, and nothing dropping it is mentioned in the release notes for version 2.0.0.

Attachments (1)

ScummvmWindows98.png (10.4 KB ) - added by theandrewbailey 16 months ago.
scummvm -v

Download all attachments as: .zip

Change History (23)

by theandrewbailey, 16 months ago

Attachment: ScummvmWindows98.png added

scummvm -v

comment:1 by digitall, 14 months ago

I don't think breaking compatibility was intentional.

Due to this commit in 2017-12-06: https://github.com/scummvm/scummvm/commit/be6963f9b8737b17368eb96350db529422b74446 enabling release builds now enables https://winsparkle.org/ by default.

The standard ScummVM v2.0.0 installer ships with the standard x86 prebuilt binary DLL for WinSparkle v0.5.7 which was the latest at the time:
https://github.com/vslavik/winsparkle/releases/tag/v0.5.7

This DLL does not seem to have been compiled to support Windows 98, and this was missed by the Win32 porters.

Sorry about this. For now, I would recommend using a daily build from our downloads page instead:
https://www.scummvm.org/downloads/#daily

I suspect the Win32 daily snapshot builds from our Win32 porter will have the same issue, but may not if these are debug builds without Sparkle and the buildbot should not have sparkle enabled so the autogenerated builds should work on Win98.

The other solution would be to replace the WINSPARKLE.DLL shipped with ScummVM v2.0.0 with one compiled to work on Windows 98 and upwards i.e. get the WinSparkle source code and recompile to a Win98 compatible DLL (unlike the pre-compiled binaries shipped by WinSparkle.org).

comment:2 by digitall, 13 months ago

Component: --Unset--Ports

comment:3 by digitall, 12 months ago

Component: PortsPort: Win32

comment:4 by DosFreak, 12 months ago

I doubt anyone cares except us crazy people but I can confirm as of 10-23-2018 that the Windows (32bit) development build from here launches on 95, 98 and NT4 without a Winsparkle error:
https://buildbot.scummvm.org/builds.html

but this error is then displayed:

Linked to missing export Kernel32.dll:GetUserDefaultUILanguage
https://github.com/scummvm/scummvm/commit/0f93962ef4bc43827f878d31a2c0ae3b868276f6

comment:5 by bonki, 12 months ago

Can we adapt this?

comment:6 by DosFreak, 12 months ago

Looks like the code <2000 offending code is here now:
https://github.com/scummvm/scummvm/blob/master/backends/platform/sdl/win32/win32.cpp
instead of:
https://github.com/scummvm/scummvm/blob/master/backends/platform/sdl/sdl.cpp

as of june 3 2018
WIN32: Move Windows-specific implementation of logMessage out of OSys…
https://github.com/scummvm/scummvm/commit/e1c83f8e8707abb268b3536c2993bcdd9dfee25e#diff-90c3950f9b30feb7daf25c71c61ef8ce

Looking at this example: https://github.com/Microsoft/VCSamples/blob/master/VC2008Samples/International/satdll/Main/Main.cpp#L430
It looks like that will work but wondering if it would be simpler to keep the current code an do an IF based on OS ver >2000 and else <2000 for GetThreadLocale()

comment:7 by digitall, 12 months ago

It should be possible to call GetVersionEx (which admittedly is deprecated for Win8.1 / 10) and then do a "less than Windows 2000" on the result to switch this back to GetThreadLocale() ... not sure if this will not cause a runtime export issue still, but worth a try.

comment:8 by digitall, 12 months ago

If someone wants to work up a patch or open this as a Pull Request, I will take a look at build testing and merge this.

comment:9 by criezy, 12 months ago

The microsoft documentation for GetThreadlocale() (https://docs.microsoft.com/en-us/windows/desktop/api/winnls/nf-winnls-getthreadlocale) indicates the same minimum requirements as for GetUserDefaultUILanguage(): Windows 2000.

comment:10 by digitall, 12 months ago

criezy: Hmm... Not sure as they have started purging any mention of Windows XP or earlier from docs, so might still be present.

I do have a Win98 box still which I should migrate to a VM for testing of older Win32 games so could look at kernel32.dll exports present there. There is also a slightly unofficial patch IIRC which fakes the newer kernel APIs to allow running newer software on there.

comment:11 by DosFreak, 12 months ago

MS is pretty bad with their documentation. I can confirm that the ScummVM 1.8.1 release worked on 9x which is before both the Winsparkle and GetUserDefaultUILanguage Commits.

http://winapi.freetechsecrets.com/win32/WIN32GetThreadLocale

For testing I recommend both VMware and Pcem:

PCem sinc you can test pre Pentium Pro+ and DirectX.
VMware to virtualize the cpu for speed and it's easier to work with.

comment:12 by digitall, 12 months ago

DosFreak: Thanks for confirming that. We tend to use QEMU as open source and allow emulation of CPUs unlike the native machine type i.e. http://wiki.scummvm.org/index.php/HOWTO-Debug-Endian-Issues

comment:13 by DosFreak, 12 months ago

digitall,

Kernelex works well enough for 98+ and I can see that being useful if ScummVM was SDL2 only so you could use ScummVM on Windows 98+ but if ScummVM still supports SDL 1.2.15 then it shouldn't be necessary.

Thanks for looking into this everybody. I have my hands full working on the DOSBox compilation guide...haven't tackled compiling ScummVM yet (but I will) but I'm an avid user. ;)

Yup, Qemu is nice enough but not for DOS and 9x gaming and testing probably okay for ScummVM testing but probably painful since Qemu likes to break 9x and it's painful to work with compared to VMware IMHO.

comment:14 by digitall, 11 months ago

Yes, I have used KernelEx on Win98 before to run newer Win32 executables if needs be.

I have some slightly bad news, but the nightly buildbot win32 builds are now switched over to SDL2:
https://github.com/scummvm/scummvm-sites/commit/9b09be4ac4cbd0be916a8806c29ba917a5f8eb15

Not sure if you can just replace the DLL with SDL1 and use that instead ... at least for now.

comment:15 by DosFreak, 11 months ago

Thanks. I'll look into this once done with DOSBox. This looks pretty simple so shouldn't be too much of an issue. Since no official ScummVM release working on <=2000 since 1.8 I'd at least like to get the latest snapshot that works, just a matter of setting the environment up, a couple of edits, compile and test.

comment:16 by DosFreak, 11 months ago

For anyone interested:

This stable build from 7-17-2017 should work. V1.9.1pre39 g483d123 until I find the time to remove the DefaultUI commit and compile. The last official working build was 1.8.1 from May 2016.

https://web.archive.org/web/20171012064421/https://buildbot.scummvm.org/snapshots/stable/mingw-w32-stable-latest.zip

comment:18 by digitall, 11 months ago

Keywords: has-pull-request added

comment:19 by DosFreak, 10 months ago

Nice work!

I'm thinking about opening another ticket to suggest stating Windows version to XP+ on (Since that's what SDL2 works on):
https://scummvm.org/downloads/ (states "Windows Installer")
https://buildbot.scummvm.org/builds.html (States Windows 32bit,64bit)

Think a final official version with SDL1 would be nice but for those who want it thanks to you we can compile the latest version once that's commited.

comment:20 by digitall, 10 months ago

PR 1430 has now been merged and buildbot mingw32 builder seems fine.

@DosFreak: If you could check if this works on Win98 with SDL1 with a local compilation?

comment:21 by DosFreak, 10 months ago

Good news everybody that commit fixed it.

I had some issues getting a mingw-w64 compiled executable to work on <2000. It was odd since I've compiled DOSBox with Mingw-w64 w/ GCC 8 with no issues but no luck with ScummVM. Had to go back to v.7.2.0 rev 1 which produced a working executable for Windows 95+ with ScummVM.

This is the version that worked:
https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/7.2.0/threads-win32/dwarf/i686-7.2.0-release-win32-dwarf-rt_v5-rev1.7z

The error I was receiving from ScummVM with newer versions was:

"_mb_cur_max_func in msvcrt.dll"

Possibly due to:
https://sourceforge.net/p/mingw-w64/mailman/message/36106593/

Think only thing left to do here is to possible add a final build to the download page for 95-2000 Operating Systems.

Which brings me to the next issue that I'll open a ticket for after christmas.

It looks like XP support is broken in the development builds here: https://buildbot.scummvm.org/builds.html

I receive the following error message on XP:

The procedure entry point InitializeConditionVariable could not be located in the dynamic link library KERNEL32.dll"

So possibly some issue with the compiler used by buildbot?

comment:22 by DosFreak, 10 months ago

*I had some issues getting a mingw-w64 compiled executable to work on <-2000.

Version 0, edited 10 months ago by DosFreak (next)
Note: See TracTickets for help on using tickets.