Doom 3 on Windows 98

The load at work has finally eased a bit and I can now actually get home in time! ~phew~
So I decide to try out a few game demos ("Doom 3", "Far Cry" and "Prince of Persia: Sands of Time") and finish the full version of "Uru" that had been abandoned when the mad rush to finish the project at work started.


While Far Cry and PoPSoT are gorgeous games, Doom 3 just refused to run on the Windows 98 that I have. Specifically, it needed "GlobalMemoryStatusEx" from kernel32.dll, which is available only in Windows 2000 and XP. Now I am not going to buy Windows 2000 or XP just to play the demo of a game.


Of course others have also faced the same issue but alarmingly people have just been editing the doom3.exe binary to zero out the "Ex" of "GlobalMemorysStatusEx" in the import table to match another function that is available on Windows 98. It seems to work for them, but is wrong because the former method returns a BOOL while the latter does not and the former takes in a struct of a different size altogether!


So using MinGW I wrote a simple dummy DLL named "mykrnl32.dll" which provided an implementation of GlobalMemoryStatusEx using GlobalMemoryStatus from the real kernel32.dll and forwarded all other calls to the real kernel32.dll. The forwarding bit was done by using "export forwarding" support in Windows Portable Executable files. (Interestingly, export forwarding is supported by MinGW's dllwrap tool but not by its "gcc -shared".) I then changed "kernel32.dll" in the import table of the doom3.exe binary to "mykrnl32.dll".


This got me past that particular failure, but I had to do a couple of more tweaks (none related to Windows 98 per se) to get it running. Suffice it to say that I did manage to get it running well enough in the end! So Doom 3 can run on Windows 98 (and perhaps 95 and ME), but doesn't because of some sloppy coding on iD's part - hey even libiberty in GCC knows how to do it right!

However, the game itself was a terrible letdown - it is so dark throughout the game and while the characters look detailed, their klunky contours are quite distracting! Far Cry is much better looks wise (but with terrible controls) as well as for playability (those enemies with their A.I.!) and PoPSoT is far more polished than either of these.


In any case, I enjoyed this little bit of hacking.


(Originally posted on Advogato.)

GCC 4.0

So the next version of GCC will be numbered "4.0.0" after all! I was hoping this would happen and could never quite understand why some people were so against bumping the major version number.

(Originally posted on Advogato.)

GCC and Stack Slot Coalescing

RTH does it again - GCC now has stack slot coalescing! This feature is especially important for the kernel developers.

(Originally posted on Advogato.)

GCC

The pressure at work to meet the project deadline is not letting me spend any time on GCC hacking. :-(
A quick perusal of the lists show that some very exciting things are happening with GCC and with GCJ. GCC will soon be entering Stage 3 and a lot of people are working hard to get their stuff in before that. Jan Hubicka seems to be on a mission to reduce the memory taken up by GCC after the tree-ssa merge. Sebastian Pop has actually implemented loop interchanging for code that ought to have been written properly in the first place - I am happy that GCC is becoming smarter but sad that this would let sloppy code go unpunished.

Tom and Andrew are back at hacking furiously at the BC-ABI for GCJ while Michael has finally liberated GCJ from the clutches of a hacked automake. Bryce seems have taken on the role of the GCJ PR man while triaging (and fixing) a lot of GCJ bugs.

I can't wait to get back...

(Originally posted on Advogato.)