Something new .... no, not really, quite old!

[gho]

One category of tough games is that of games using WinG32 library.
Personally, I never liked the fact that this silly library (it contains only 10 APIs, nothing comparable with richness and complexity of GDI) makes a self-check and pretends to be installed in the Window system folders. That requires privileges, exposes to risks and add some 32bit garbage in your 64bit clean OS. Unbearable.
So, what a surprise when I opened the Wine implementation for WinG32 and found that you can simply map each WinG call to a almost equivalent GDI call. If that is true, then who needs WinG?
Ah, sure, the linker would complain .... but that wouldn't happen if you place a fake and void WinG32.dll in the game folder and redirect all calls to GDI through DxWnd!
The whole stuff seems more complicated to tell than to implement, and as a matter of fact here it is.
It works well enough with Allied General, with some tricks also Al Unser Arcade Racing works (but it needs improvements!), and then? Will you help building a list of interesting WinG32 games? A minimal testing would assure a DxWnd release with no surprises.

[gho]

I'm making a list here, to be updated periodically:

Al Unser Arcade Racing: working
Allied General: working
Civil War Generals II: W.I.P.
Comix Zone (1995) ??
Dark Seed II (1995) no win32 exe version found so far
Dust: A Tale of the Wired West (1995) ??
Fury3 (1995) ??
Garfield - Caught in the Act (1995): working
Grand Prix Manager 2: W.I.P.
Heroes of Might & Magic II: working (with one specific game version)
Industry Giant: W.I.P.
Monopoly (Westwood Studios) (1995): working
Noir: A Shadowy Thriller (1996): ??
Sid Meier's Civilization II (1996): ??
Sid Meier's Colonization (1995): ??
SimTower: no win32 exe version found so far
The Rise & Rule of Ancient Empires (1996): ??
Titanic: Adventure Out of Time (1996): working
Warhammer: Shadow of the Horned Rat: working
Wizardry 7: W.I.P.

P.s one note: DxWnd can manage Win32 games only. It seems that some games like SimTower linked the WinG32.dll library to a Win16 executable. I'm sorry, but these are out of reach for DxWnd.

P.s.2 the status refers sometimes on WIP DxWnd releases. If anyone is interested to replicate some positive result, he'd better ask for a leaked beta version. Or wait a little more ...

[XD Gamer]

SimTower

Are there many 32-bit WinG games?

[gho]

I believe relatively few, WinG32 was meant to provide some interface for windows gaming in 32bit environment, but offered limited advantages, so after less than a coulpe of years later it was replaced (with no sorrow) by ddraw and opengl. But some WinG games were and remain high quality games!
I can count 9 of them up in the list, and probably we could reach a figure of about 20 - 30 and no more.

[XD Gamer]

Hi gho, please focus only on WinG/32 games because as 64-bit usage increases, very few will be able to run WinG/16 games without the use of a VM or emulation layer. Then you can have more time to work on Titanic. =)

[aqrit]

warhammer: shadow of the horned rat

[gho]

@aqrit: Added to the list. One more thing for you: I started with "Al Unser Arcade Racing" that is a strange game: the file IAT can't be browsed and hooked in any of the ways I implemented so far. Fortunately, some (russian?) hacker build a modded exe (called slow-down patch, or something similar) that adds some vsync-like delay to the frame rate. Inorder to do so, it had to hack the IAT adding an extra dll that dynamically loads many system calls, IMO in order to be able to reroute them somehow. You should be able to find everything easily on oldgamesru. But I don't like the idea to have to rely on some other hacker to do the hard work before DxWnd could make its own. Also, redirection is not complete, so DxWnd only works in part.
Do you see a strategy to redirect the system calls in this particular case?
To avoid confusion, here s the original and DxWnd-unfriendly executable. It can be browsed by PE explorer, but the IAT is organized in a strange way ...

[aqrit]

seems to be missing at least the original_first_thunk and ordinal hint
is this code path not working?

  if (apiproc){
    // examining by function addr
    if(ptaddr->u1.Function == (DWORD)apiproc) break;
}

and the ever popular: does it erase its own PE header on startup?

sorry not very helpful :-/

[gho]

Please, see news at bottom of this thread

[gho]

Status report:
HOM&M2: an encouraging start, there are serious ddraw blitting / mouse control problems, but this is an entirely different story.
Al Unser AR: the hacked version is lovely playable, the original one will give me headaches for a while ... and is suggesting that I need some F1 pilot training!

[gho]

Warhammer Shadow of the Horned Rat:
I had to fix a few problems in Virtual Registry in order to make it start properly, but here I have again big problems of hooking. I don't see traces of WinG and GDI calls in the log, and that means that the calls are not hooked.
But the start is encouraging, it seems that many of these old (1995-1996) games were built with the same linker options.

[gho]

Always about WSOTHR, it tries to get the proc address of the following unsopported old kernel32 calls:

GetProcAddress: hModule=75ae0000 proc=MapSL
GetProcAddress: hModule=75ae0000 proc=SMapLS
GetProcAddress: hModule=75ae0000 proc=SMapLS_IP_EBP_8
GetProcAddress: hModule=75ae0000 proc=SMapLS_IP_EBP_12
GetProcAddress: hModule=75ae0000 proc=SMapLS_IP_EBP_16
GetProcAddress: hModule=75ae0000 proc=SUnMapLS
GetProcAddress: hModule=75ae0000 proc=SUnMapLS_IP_EBP_8
GetProcAddress: hModule=75ae0000 proc=SUnMapLS_IP_EBP_12
GetProcAddress: hModule=75ae0000 proc=SUnMapLS_IP_EBP_16
GetProcAddress: hModule=75ae0000 proc=FT_Exit8
GetProcAddress: hModule=75ae0000 proc=FT_Exit12
GetProcAddress: hModule=75ae0000 proc=FT_Thunk
GetProcAddress: hModule=75ae0000 proc=ThunkConnect32

I don't know whether these are vital or not (the game keeps trying to load them buf doesn't stop running). Maybe the best strategy is to hide the head below the sand.

[aqrit]

games runs fine here on win8 so they must not be too vital ?

[Riitaoja]

Civil War Generals II is another WinG32 game.

[gho]

Status report:
Al Unser AR: the original exe has a IFT that follows a weird but predictable rule: first all DLL names, then all API entries in the exact number as the DLL entries. That allows to scan the IFT in search of a given API name and retrieve its address. It is a variant of the schema I already inserted in the IATPatch and DumpImportTable routines, with the only drawback of beig unable to predict which schema is suitable in a given context, hence the need of a new and "delicate" DxWnd flag.
Neverthless, paying attention to what you do (setting the flag in a wrong way means replacing API addresses at random!) now Al Unser Jr Arcade Racing in its original and unpatched version works perfectly! There are no visible differences with the russian patched version, but at least ALL cals are exposed (the parched one is UPX-ed, that is I believe compressed and so obfuscated as well) so in case of problems we have all knobs available.
I think it is time for a new release and a few export configuration files, in case anyone would like to enjoy these few but precious past gems.

@aqrit: do you see any clue to predict which schema is good for any given situation? One possibility could be to scan the IAT initially and see if it follows one scema or the other. Maybe there is something smarter?

[gho]

Wait, this was the shortest living DxWnd flag ever: telling which is the case is just too simple:

        char *fname = (PSTR)(base + pidesc->Name);
        // skip first string
        for(; *fname; fname++); for(; !*fname; fname++);
        // if second string is another DLL it is sequential, otherwise not.
        return (BOOL)stristr(fname, ".DLL");

In practice: first entry in IFT must be a DLL, just skip it and look at the second entry: if it is another DLL we have an old-fashioned IFT, if not there is an API name and we have a normal case.

[aqrit]

in theory, there is no relationship between strings

[gho]

Maybe in theory you could be right, but so far I just found two cases of IAT organization when OFT pointers are missing / overwritten, that is the most common case where API names follows their DLL name like this

KERNEL32.dll
CloseHandleSetFilePointer
...
USERS32.dll
ClientToScreen
SetFocus
...

and now (so far in "Al Unser Jr Arcade Racing" only!) this sequential organization where all DLL are listed forst and the API next, like this

KERNEL32.dll
USERS32.dll
CloseHandleSetFilePointer
...
ClientToScreen
SetFocus
...

So, since there can't be an API whose name contains a '.' dot (hopefully!), looking at the second entry should tell reliably enough which is the case. This, of course, until some other IFT organization comes out of the blue, but then we will see...

P.s. just in case things would get too scrambled to be managed this way, I still have the emergency solution of opening the executable file and navigate the IFT before it gets "ruined" by the linker that overwrites the address offsets with the API addresses.

[gho]

@aqrit: damn, you're right, here comes a first (cracked?) executable that doesn't follow the rules. Here we have a mixed order and DxWnd detects a sequenced schema likely because of these two bad boys, the DDRAW.DLL followed by DSOUND.DLL!

[gho]

Here is the necessary stuff to play with Al Unser Jr. A.R., no matter if patched or not.
The unpatched version, too fast for modern compters, needs to set a minimal delay in the FPS limitaton, something like 3 - 5 mSec).

[gho]

Progress Report:
Warhammer Shadow of the Horned Rat
This game is sadly a perfect example of how much it is still left to do! Trying to set all emulation tricks on, in effect DxWnd seems to intercept a lot of system calls, but the situation is quite complex and the hookers don't react properly.
Here is a list of problems to manage:

• The game opens several windows, but none of them is anything like a main window. That puzzles DxWnd that keeps switching main window handle without ever getting the correct one
• The game operates directly on the desktop before having appointed a window as a main one, so DxWnd rerouting of desktop references to the main window produces no effect
• The game performs a SetDIBits operation agains a mysterious HDC coming out of the blue, not of OBJ_DC type, but I can't find traces of operations performed with this handle, so the bitmap goes to screen unscaled
• There are an incredible number of DLLs spread in the game directory and subfolders, many of them referencing WING32 and GDI32

And this is just what comes from whatching the game splash screen! Definitely, a game that will probably give me headaches for a while.

[gho]

Progress report:
Civil War Generals 2
This would a perfect testbed since many operations are performed through WinG32 calls, but it needs some more interventions. To begin with, it seems that SmackW32 is needed and also it is necessary to shortcut the _SmackColorRemap@16 dll entry or the screen resolution will get updated.
With many precautions, the game starts and proceeds somehow, but it easily stops hanging forever.
It has a internal message loop, so I fear that it will be necessary to hook the message handling calls Peek/Get/DispatchMessage.

[gho]

Slow progress, but now I can enter the battle screen ...

[gho]

Progress report:
Grand Prix Manager 2
Working perfectly unscaled at 640x480 sized window, but problems come when you try to change size. Odd!