SetSysVerToWin95.exe

[TgamesFR]

Hi,

I'm currently compiling the old source with game fix and it need SetSysVerToWin95.exe to finish the compilations task.

Can you provide me that exe ?

It's to run this old version from your website on Windows 98 system with the best fixes for games.

Thanks.

[TgamesFR]

Your program was just hex editing the outputed ddraw.dll to theses values right ?

It seems to works by changing like this (original on left, edited on right).
I don't know if i'm missing any additionnal change however.

To fix ddraw.dll (aqrit) compilation for Windows 95

at 40 to E1 write that :

B8 01 4C CD 21 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50 45

and :

120 -> change 05 to 04

128 -> change 05 to 04

[aqrit]

Edited*

You should not need ddwrapper on Win9x.

SetSysVerToWin95.exe: changes the MajorOperatingSystemVersion & MajorSubsystemVersion from 5 to 4,
It also zeroes out the PE rich signature (tracking info) inserted by the MS compiler.
Also it shortens up the dos stub.

So yes, you've captured its exact behavior in the post above.

This "hack" was necessary because I was using 'Microsoft Visual C++ 2008 Express Edition', which marked all modules as requiring Windows XP. So at least -one person- was unable to install some unrelated community patch, because not being able to load the bundled ddraw.dll caused the game to crash on Windows M.E.

However, this is a not a good idea if you don't know what your doing!
It is highly dependent on your compiler and compiler setting.
If your using a new compiler it will probably still crash on Win9x.
If your using a old compiler that supports win9x then it is not needed.
I got away with it because I wasn't linking the CRT, or pulling in any fancy features, and theoretically everything should work on Win9x (AFAIK).

Here is the source:

/*
* Set some stuff in the PE header to mark the program compatible with win95 or later
* this is a post-build step for every module 
* this work-around is needed cause my linker's output only supports WinXP+ or some such non-sense
*/


#include <windows.h>

int main(int argc, char *argv[]){
	HANDLE hFile;
	HANDLE hFileMap;
	char*  pFileBuf;

	if(argc != 0){
		hFile = CreateFile(argv[1], GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
		if(hFile != INVALID_HANDLE_VALUE){
			hFileMap = CreateFileMapping(hFile, NULL, PAGE_READWRITE, 0, 0, NULL );
			if(hFileMap != NULL){ 
				pFileBuf = (char*)MapViewOfFile(hFileMap, FILE_MAP_ALL_ACCESS, 0, 0, 0);
				if(pFileBuf != NULL){

					// allow Win 95 ?
					// my linker sets the PE to require OperatingSystemVersion "5" for no reason.
					IMAGE_OPTIONAL_HEADER *ioh = (IMAGE_OPTIONAL_HEADER *)( pFileBuf + ((IMAGE_DOS_HEADER *)pFileBuf)->e_lfanew + 4 + sizeof(IMAGE_FILE_HEADER));
					ioh->MajorOperatingSystemVersion = 4;
					ioh->MinorOperatingSystemVersion = 0;
					ioh->MajorSubsystemVersion = 4;
					ioh->MinorSubsystemVersion = 0;

					// this is always zero for my linker anyways
					ioh->CheckSum = 0;

					// as long as we're here... earse all the garbage between the dos header and the pe header
					// this makes an "unsafe" assumption that there is only the dos_stub and rich_signature between the two headers.
					char *p = pFileBuf;
					unsigned char dos_stub [] = { 0xB8, 0x01, 0x4C, 0xCD, 0x21 }; // int 21; ax = 0x4C01;  DOS - QUIT WITH EXIT CODE ( 01 )
					p += sizeof( IMAGE_DOS_HEADER );
					memcpy( p, dos_stub, sizeof( dos_stub ) );
					p += sizeof( dos_stub );
					while( p < (pFileBuf + ((IMAGE_DOS_HEADER *)pFileBuf)->e_lfanew ) )
					{
						*p++ = 0;
					}

				}
				UnmapViewOfFile(pFileBuf);
				CloseHandle(hFileMap);    
			}
			CloseHandle(hFile); 
		}
	}
	return 0;
}

[aqrit]

Also it was only actually verified as working for a different project... on Windows M.E.

[TgamesFR]

Thanks for the source code of SetSysVerToWin95.exe.

I need aqrit because i'm using a 2025 modern motherboard with a VortexEX who have issues on Windows 98 when the AGP is changed to 256 colors. It's because it's not completely a x86 system so some features are not here and 256 colors on WIndows 98 works only from DOS.

We discovered that emulating the 256 colors palette in 16bits/32bits works fine and produce no glitchs.

Also only your old source code not crash WIndows 98 with "Illegal operations", it's fully stable and works great.

The only missing feature is emulating the 256 colors in Window Mode and not only Full Screen.

[aqrit]

For Starcraft / Warcraft 2 I found that a d3d9 shader was required to emulate 8-bit color without a slow down.

[TgamesFR]

Yes i've noticed on a forked project that 8-bit color in Window mode slowdown the game a bit.
However that fork is based on your updated source and it randomly crashing with "Illegal operations". I've not told the dev who did the fork as he not used your old source as base but the github one who already had the issue.

If one day you implement 8-bit color on your old source for Windowed games it will be great.
It's what i'm trying myself at the moment.