Another victim of the unrealized collateral damage from the alarmist urge to "get off outdated sdl1.2 its out of date you must sdl2 by order of downstream from <insert certain authority-complex linux distro here>"
It looks like snapshots do not include Winsparkle (which makes sense).
Winsparkle included with official Scummvm releases doesn't support 9x and NT4 and a commit added back in June of 2017 broke <2000 support. So theoretically snapshots before June 2017 with no Winsparkle supported 9x whereas snapshots after June 2017 do not.
I think when I tested 1.9.0 it was with SDL2 so the 11-7-2018 (SDL1) snapshot should work fine with Windows 2000.
I'll see if I can get around to compiling ScummVM. Currently working on DOSBox which is more important. 😀
Anyone know how to find old snapshots on ScummVM buildbot? Internet Archive not much help and https://buildbot.scummvm.org/snapshots/ doesn't go back very far.
Switching to SDL2 is important. Mostly because SDL2 does many things better and most importantly SDL1.2x is no longer really maintained. It is breaking right and left on today's operating systems and fixes are slow to come or never...
Agreed but they've supported SDL 1.2.15 until today so would be nice to have a final working release especially since it was broke back with 1.9.0 (WinSparkle) and never acknowledged. Absolute bare minimum that has to be done is provide a snapshot before the offending June 2017 commit or release the older 1.9.0 build without Winsparkle for 9x,NT4 and a 11-7-2018 build for 2000 and call it a day. No code changes required.
This stable build from 7-17-2017 should work. V1.9.1pre39 g483d123 until I find the time to remove the offending commit and compile. The last official working build was 1.8.1 from May 2016. https://web.archive.org/web/20171012064421/ht … able-latest.zip
Isn’t ScummVM more about getting old games working on new machines, and less about getting them to work on period machines with Windows shoehorned onto them?
Yey, yes, I think so. Though I can also understand the OP's point of view.
SDL2 apps increase minimum requirements for little benefit, so it would be cool to be warned about a switch and to get a last good release of the old line.
In contrast, SDL 1.x and plain Win32 programs will run on almost anything, providing lots of freedom in choice of the OS.
From pure DOS with HX-Extender, over ReactOS to beloved Windows releases (98, XP; anything pre Win10).
DOSBox can do the first one, which is kinda cool.
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
Ah, interesting point. I can't say the same about most of the software I still maintain, since:
1) It's all compiled with UNICODE/_UNICODE defined, so it won't run on Win9x unless you've shoehorned some sort of Unicode supporting kernel and userspace onto it.
2) It's all compiled with MSVC 2017 Community, so the bare minimum I can actually support is Windows XP. I still compile with the extended instruction set option at strictly IA32, not the default of SSE2, so it should still work on XP SP2, or SP3 if you somehow blacklist the SSE2-requiring updates. I can't say the same for every other software developer who uses 2017 with the v141_xp SDK.
Yeah SDL1 takes care that and Mingw and Mingw-W64 still support less than 2000. There's only two things preventing ScummVM working. WinSparkle which is only used in official releases and the commit added back in June of 2017 that is one line of code that dropped support for less than 2000. That's it (as of 11-7-2018. ). It's ridiculous to have kept SDL 1.2.15 support all this time but to have dropped <2000 support but that was not intentional.
It looks like anything newer than 11-7-2018 won't work on 2000 since SDL2.dll is included instead of SDL.dll. Deleting SDL2 and replacing with SDL1 doesn't work. So 2000 support definetly dropped. ScummVM is XP+ only now.
The use case of ScummVM on an old OS is if you have an old gaming machine and want to run games on it.
I'm glad that I came across your post. I'll be working on a Windows NT 4.0 Workstation build in the near future and was planning on installing ScummVM. Sucks that they're going this route, though I understand why. Thanks for the heads up!
I'm glad that I came across your post. I'll be working on a Windows NT 4.0 Workstation build in the near future and was planning on installing ScummVM. Sucks that they're going this route, though I understand why. Thanks for the heads up!
I second that. I was using ScummVM since the old PocketPC days (PPC 2000/2002) and I am glad that DOSfreak reported this issue. 😀
kode54 wrote:
Ah, interesting point. I can't say the same about most of the software I still maintain, since:
1) It's all compiled with UNICODE/_UNICODE defined, so it won't run on Win9x unless you've shoehorned some sort of Unicode supporting kernel and userspace onto it.
Ah, I see. Makes sense to me. Win98 can run modern Unicode programs through unicows library (and KernelEx), though.
It's truely a bit shoehorned, though, I admit. Siimilary, it is possible to retrofit Win32s/Win95 programs to support modern styles (no need for GDI+).
All it needs, -at the core-, is a manifest file. This makes old programs appear much cleaner on new NT OSes without breaking support
for Windows 3.1 or Win98SE. It also works with VB5/6 or MS VC++ 6.0 programs. An old sample program I clashed together can be found here.
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
Still plan on:
Building compilation environment for ScummVM and uploading to Google Drive.
Test building regular ScummVM without Winsparkle (Just like as provided by ScummVM buildbot)
Reverting dll:GetUserDefaultUILanguage commit from 6-9-2017 in 11-6-2018 build (Last date for SDL1)
This should give us a working ScummVM for 9x,NT4,2000.
If I'm bored then possibly 3.50,3.51 support as well: Re: ScummVM 1.8.1 on Windows NT 3.51 (For 3,50: SDL: Disable OGL and fullscreen support, For 3.51 SDL: disable OpenGL support)
1Changed 5 months ago by theandrewbailey 2Attachment: ScummvmWindows98.png added 3scummvm -v 4comment:1 Changed 3 months ago by digitall 5I don't think breaking compatibility was intentional. 6Due to this commit in 2017-12-06: https://github.com/scummvm/scummvm/commit/be6963f9b8737b17368eb96350db529422b74446 enabling release builds now enables https://winsparkle.org/ by default. 7The 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: 8https://github.com/vslavik/winsparkle/releases/tag/v0.5.7 9This DLL does not seem to have been compiled to support Windows 98, and this was missed by the Win32 porters. 10Sorry about this. For now, I would recommend using a daily build from our downloads page instead: 11https://www.scummvm.org/downloads/#daily 12I 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. 13The 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). 14comment:2 Changed 2 months ago by digitall 15Component: --Unset-- → Ports 16comment:3 Changed 6 weeks ago by digitall 17Component: Ports → Port: Win32 18comment:4 Changed 6 weeks ago by DosFreak 19I 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: 20https://buildbot.scummvm.org/builds.html 21but this error is then displayed: 22Linked to missing export Kernel32.dll:GetUserDefaultUILanguage 23https://github.com/scummvm/scummvm/commit/0f93962ef4bc43827f878d31a2c0ae3b868276f6 24comment:5 Changed 6 weeks ago by bonki 25Can we adapt this? 26comment:6 Changed 5 weeks ago by DosFreak 27Looks like the code <2000 offending code is here now: 28https://github.com/scummvm/scummvm/blob/master/backends/platform/sdl/win32/win32.cpp 29instead of: 30https://github.com/scummvm/scummvm/blob/master/backends/platform/sdl/sdl.cpp 31as of june 3 2018 32WIN32: Move Windows-specific implementation of logMessage out of OSys… 33https://github.com/scummvm/scummvm/commit/e1c83f8e8707abb268b3536c2993bcdd9dfee25e#diff-90c3950f9b30feb7daf25c71c61ef8ce 34Looking at this example: https://github.com/Microsoft/VCSamples/blob/master/VC2008Samples/International/satdll/Main/Main.cpp#L430 35It 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() 36comment:7 Changed 5 weeks ago by digitall 37It 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. 38comment:8 Changed 5 weeks ago by digitall 39If 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. 40comment:9 Changed 5 weeks ago by criezy 41The 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. 42comment:10 Changed 5 weeks ago by digitall 43criezy: Hmm... Not sure as they have started purging any mention of Windows XP or earlier from docs, so might still be present. 44I 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. 45comment:11 Changed 5 weeks ago by DosFreak 46MS 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. 47http://winapi.freetechsecrets.com/win32/WIN32GetThreadLocale 48For testing I recommend both VMware and Pcem: 49PCem sinc you can test pre Pentium Pro+ and DirectX. 50VMware to virtualize the cpu for speed and it's easier to work with. 51comment:12 Changed 5 weeks ago by digitall 52DosFreak: 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 53comment:13 Changed 5 weeks ago by DosFreak 54digitall, 55Kernelex 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. 56Thanks 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. ;) 57Yup, 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. 58comment:14 Changed 3 weeks ago by digitall 59Yes, I have used KernelEx on Win98 before to run newer Win32 executables if needs be. 60I have some slightly bad news, but the nightly buildbot win32 builds are now switched over to SDL2:
…Show last 13 lines
61https://github.com/scummvm/scummvm-sites/commit/9b09be4ac4cbd0be916a8806c29ba917a5f8eb15 62Not sure if you can just replace the DLL with SDL1 and use that instead ... at least for now. 63comment:15 Changed 3 weeks ago by DosFreak 64Thanks. 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. 65comment:16 Changed 3 weeks ago by DosFreak 66For anyone interested: 67This 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. 68https://web.archive.org/web/20171012064421/https://buildbot.scummvm.org/snapshots/stable/mingw-w32-stable-latest.zip 69comment:17 Changed 3 weeks ago by DosFreak 70OP, 71Until I have time to compile a 11-7-2018 build for <2000 use these: 729x (7-17-2017) stable: https://web.archive.org/web/20171012064421/https://buildbot.scummvm.org/snapshots/stable/mingw-w32-stable-latest.zip 732000 (11-7-2018) Development: https://buildbot.scummvm.org/snapshots/master/mingw-w32-master-1de6335b.zip
Yup, check my compilation guides. As long as you use the latest MSVCRT provided in a Windows 2000 KB update then I had no issues with NT 3.50+,95+ with mingw-w64 as of May 2018 with the latest ver of Mingw-w64 at least as far as DOSBox is concerned. oh and of course you have to use Dwarf with GCC instead of Posix. MSYS2 and repos probably only provide Posix builds. Also mingw-w64 only works for Pentium Pro+ haven't bothered to figure out how to recompile it to support less than that.
Not knowing much about this issue, how hard would it be to build an SDL2 environment for Win9x? The source is available... It seems most of the software that people are upset about "dropping support" is because of this issue. Even some sort of wrapper would be better than nothing.
twitch.tv/oldskooljay - playing the obscure, forgotten & weird - most Tuesdays & Thursdays @ 6:30 PM PDT. Bonus streams elsewhen!
Another issue that is now making us at Exult drop support for Win9x and W2k is c++11 or rather c++14.
To battle memory stuff we are going to rely on these in the future...
Not knowing much about this issue, how hard would it be to build an SDL2 environment for Win9x? The source is available... It seems most of the software that people are upset about "dropping support" is because of this issue. Even some sort of wrapper would be better than nothing.
Well there is an unofficial SDL 2.0.5 for Windows 2000 to work around the no raw input support in Windows 2000 but possibly BlackWingCat kernelex (2000) and the kernelex for 98,ME should enable SDL2 programs to work in 98,ME and 2000.
I believe raw input, unicode and no software render (Think SDL2 is D3D9 and OGL3?) were the issues last I looked into it.
That's for another day though, I just want a working final ScummVM build even if no one else cares which appear to be the case (Okay two people). Just gotta find the time. 😀
The buildbot and daily snapshots are built with SDL2 but according to the ticket when ScummVM is compiled with SDL1 then it works.
So as soon as this is commited even if there is no official release supporting <=2000 we'll be able to compile a working build with the latest code as of that commit.