Smack! ehm .... I'm NOT kissing you!!

[gho]

follows ...

[gho]

One of the most troublesome parts of DxWnd is the smackw32.dll hooking. Fortunately, this library uses ddraw and other hooked modules, so in most cases the best policy is simply ignore it, but that doesn't hold in all cases, as the "Galapagos" movies case showed clearly.
In this game smack was used with a flag setting that forced 16bpp color depth, and this was really bad on emulated mode over 32bpp desktop. The fix was simple (clear this hurting flag setting) but ... here starts the trouble.

smackw32 is a technology that was in continuous evolution, with many smackw32.dll versions and no concern about the producer (RAD Tools) to keep some compatibility level. More than this, the developers were encouraged to reference the dll calls by reference number rather than name, making it hard to understand who is calling what. The idea is that you develop a game, grab (buy) a smackw32.dll with a certain interface and relative private documentation, ship game and dll together. A very ugly thing for DxWnd.

This is why I decided to improve the DxWnd hooking code for this library including a heading procedure that "sniffs" the dll to be hooked trying to guess the release and relative interface and then sets the hooking table accordingly.

This was a very boring job, but revealed some interesting parts. I'm going to write something here as a tutorial (or memo for myself too). One little at a time. To be continued ...

[gho]

After many rework on the smack.cpp source, I finally realized that I was pulling a short blanket: fixing a problem for one game was bringing back another problem on another game. So, first step, let's know your enemy.
Taking advantage of a nice RAD Tools collections and using pedump.exe I got the export definition of an almost fulll set of smackw32.dll file versions. Then, comparing the exports one another, I checked the differences and found thet there were only 4 different interface definitions (phew! the dll versions are quite a lot more than this!!).
In addition, I got from some older game another dll that wasn't listed here and has the peculiarity of showinf a _cdecl interface instead of a _stdcall interface, for a total amount of 5 different interfaces.
The files output of this activity are here in attach.
Then I defined a criteria to tell one interface form another, that is looking for function calls that exist only in a given interface. This filled in this procedure:

static void InitializeSMKInterface()
{
    // select the hook table by looking at the existence of some given key function that
    // does not exists in previous interface versions

    HMODULE h;
    FARPROC fun;
    // can't use the module handle because it doesn't work for main process handle, which
    // is the most useful thing. Need opening (and closing) a new module handle, hoping
    // to load the very same dll ...
    h = (*pLoadLibraryA)("smackw32.dll");
    if(!h) return;
    while(TRUE){ // fake loop
        fun = (*pGetProcAddress)(h, "_SmackGetKeyFrame@12");
        if(fun){
            OutTraceDW("Smack interface 4.0e\n");
            Hooks = Hooks40E;
            break;
        }
        fun = (*pGetProcAddress)(h, "_SmackColorRemapWithTrans@20");
        if(fun){
            OutTraceDW("Smack interface 3.2g\n");
            Hooks = Hooks32G;
            break;
        }
        fun = (*pGetProcAddress)(h, "_SmackBufferToBufferMask@40");
        if(fun){
            OutTraceDW("Smack interface 3.1n\n");
            Hooks = Hooks31N;
            break;
        }
        fun = (*pGetProcAddress)(h, "_SmackOpen@12");
        if(fun){
            OutTraceDW("Smack interface 2.2i\n");
            Hooks = Hooks22I;
            break;
        }
        // found in S.C.A.R.A.B. but not identified. Presumably, a quite older version.
        // BEWARE: the calls here are _cdecl instead of _stdcall.
        fun = (*pGetProcAddress)(h, "_SmackOpen"); 
        if(fun){
            OutTraceDW("Smack interface 1.x\n");
            Hooks = HooksSMK;
            break;
        }
        OutTraceE("Smack interface unknown\n");
        break; // exit fake loop
    }
    FreeLibrary(h);
}

It would be interesting to have more details about very early SMACKW32.DLL interfaces, the one I got was from "S.C.A.R.A.B.", but I suppose there could be others.
To be continued ...

[huh]

I did not see this version on your list....

[gho]

Wow, thanks! At first glance this seemed a copy of the S.C.A.R.A.B release, but looking better and comparing them they are identical up to ordinal #1E (_SmackToScreen), but then they differ, at ordinal #1F _SmackVolumePan replaces _SmackVolume and in the end there are two more calls _SmackSoundUseDirectSound and _SmackSoundUseMSS. Probably your dll is a little newer than S.C.A.R.A.B.'s version.
Where did you find it? I need the name of the game to make proper testing.

[gho]

I probably ougth to mention some excellent work made on Vogons site: https://www.vogons.org/viewtopic.php?f=13&t=11330

[huh]

I found it in game folder Hellbender.
Library from Hexplore has only 59 functions, but I think all is already in your list.

Edit:
According to the downloaded libraries from Vogons site, it looks like (by functions), that version from Hellbender is 2.1c

[gho]

Interesting. Version 2.1c is the oldest clessified on Vogons, so the "S.C.A.R.A.B." one must be even older. Maybe they're interested....
In addition, your "Hellbender" dll may have the same interface as 2.1c, but it's not identical (different hash and also slightly different size), maybe it is a little older this one too!

[dippy dipper]

Based on file dates SMACKW32.DLL in Helbender is dated "1996-02-10" and this would be close to "2.0 w - 02/07/96". As seen in the version history here:
http://www.radgametools.com/smkhist.htm

SMACKW32.DLL in SCARAB has a file date of "1995-12-08" which would point to "2.0 r - 12/04/95".

[gho]

Good job!

[huh]

@dippy dipper
Okay, but my file in Hellbender has a date 96/08/07 so it would be a version of either 2.1 j - 96/08/10 or 2.1 i - 96/07/10.
Is your version binary same with mine?
crc32: 114F14E0
Version in Hexplore have inside text "Smacker Version: 3.1b", but it's interesting, that file is binary different (on the original CD, so the file is not definitely damaged) versus version of Vogons (but only 36 differences). Functions are the same.

[dippy dipper]

Yep, same file.
It is unfortunate that the older versions of smackw32.dll do not seem to contain any version info. File date can't be relied on too much.

[huh]

It's sometimes strange, not just Hexplore, but for example, the version of "Carmageddon Win95 add-on" looks like 2.1g from Vogons, but binary has 30 differences.

[gho]

Well, let's be pragmatic: all this doesn't matter as long as we can identify different interfaces. I like the idea of naming each interface with the version number of the first dll that exposed it, but as long as DxWnd can tell the difference and behave accordingly, we could call them in any way we like.
How about the names of the seven dwarfs of Snow White? Uhm, better not ....

[huh]

all this doesn't matter as long as we can identify different interfaces.>

Maybe not. But inside my 2.1g file (as I suppose) is MSS32.DLL string and in Vogons version there is WAIL32.DLL in the same location. Maybe it's a hack, but the changes are also in other places in file.

How about the names of the seven dwarfs of Snow White?>

Pretty idea.
But I do not know if those 7 will be enough :-)

[gho]

But inside my 2.1g file (as I suppose) is MSS32.DLL string and in Vogons version there is WAIL32.DLL in the same location

Scary finding! So far, I used the exported names to identify a set of common interfaces, but I don't like the idea of having to calculate a CRC of the dll to tell which it is.
Fortunately, we have to identify them only for DxWnd purposes, and these are usually tied to the interface only. So, at the moment and luckyly, I don't care whether we have a MSS32.DLL or a WAIL32.DLL dependency, what DxWnd has to do doesn't depend on this. At the moment ...
Be ready for Snow White and the seventy dwarfs!!

[dippy dipper]

...the version of "Carmageddon Win95 add-on" looks like 2.1g from Vogons, but binary has 30 differences.

My Carmageddon CD includes both the DOS installer and Win95 installer. The Win95 version in "\CARM95\SMACKW32.DLL" has a version string of "Smacker Version: 3.0h".

[huh]

Well, but this is "Carmageddon Win95 add-on". This SMACKW32.DLL has no version inside.
When I get home, I'll put him here. I think he has around 65KB

[gho]

Now there's another interesting issue: is there anything more relevant for DxWnd?
I mean, so far hooking these libraries is useful only for few purposes:

• redirect the movie file path in SmackOpen (still unimplemented)
• shorten the movie size to 1 single frame (NOMOVIE flag)
• intercept SmackOpen and SmackClose to suspend time stretching during movie play (SUSPENDTIMESTRETCH flag)
• process the message queue during movie play (FIXSMACKLOOP flag)
• bypass harmful operations by SmackColorRemap calls (no flags, it's forced) or SmackToBuffer (SMACKNOBUFFERDEPTH tweak)
• virtualize the desktop settings (SmackSetSystemRes)

The idea is that maybe looking at the list of function calls it could be possible to foresee some possible extension for these functions. For instance, a weird (and aborted) idea was to force either MSS or DirectSound no matter what the program asks to increase sound compatibility. The idea is aborted because it seems that switching technology is not transparent for the application that easily crashes, but there could be more.

[huh]

@dippy dipper
Here is this deviant file.

[dippy dipper]

I bet that could be the 2.1 j version of smackw32.dll.

I think Miles Sound system changed naming from WAIL32.DLL to MSS32.DLL with the 3.5b release of the library. So that would have happened 07-07-1996 according to the MSS version history.

Changes from 3.5a to 3.5b (07-07-1996):
-Renamed main libraries and header to use MSS instead of AIL.
http://www.radgametools.com/msshist.htm

Smackw32.dll “2.1 j – 08/10/96” has this change:
-Switched to new MSS for DOS and Windows.
http://www.radgametools.com/smkhist.htm

---

I am not sure if this is relevant to Dxwnd but I also found this.

Starting with 2.2b Smackw32.dll the following function names:
_MEM_alloc_lock
_MEM_free_lock

change to:
_AIL_mem_alloc_lock
_AIL_mem_free_lock

[huh]

It is possible.
2.1g-smackw32.dll from the Vogons collection is very similar (only 30 binary differences).
Unfortunately, the collection does not contain version 2.1h-2.2b for comparison.

[gho]

I did a crazy thing. I wrote RADGameTools support asking for a collection of include files and documentation. Chances to get an answer are close to 0%, but who knows?

[dippy dipper]

I doubt they support the old Smacker video anymore. However I did stumble across libsmacker which might be useful?
http://libsmacker.sourceforge.net/

[huh]

Unfortunately chances are probably small.
Some have previously tried to get versions WAIL32.dll from RAD Game Tools and they were not successful.
http://forum.galliusiv.com/viewtopic.php?f=4&t=317
(Damn, I wonder if it exists a version that works with Comix Zone and does not freeze with sound+music).