I used 237unpak.exe to decompress all of the .DAT files in the main data file, in the hopes of re-compressing the entire game with 7zip to a much smaller size. The resulting recombined GAMEDATA.G-D file is about 2.6 MB as compared to the old size of 590,932 bytes.

Is there a way to force the game to accept these uncompressed .DAT files, without using its built-in LZSS decompressor? LZSS compression is terribly inefficient, and keeping things uncompressed will also speed up the game considerably. The 52 .DAT files seemed to be perfectly decompressed by 237unpak.EXE

The game, of course does not execute with the new 2.6 mb GAMEDATA.G-D file recombined by DOOFEXT.EXE -c option. The DOOFUS.EXE is obviously looking to decompress already decompressed files, and fails and / or the pointers in the new .G-D file aren't updated in the .FAT file within the newly concatenated G-D file.

The regular version of the game compresses to ~700 kb with the LZSS-compressed .G-D file, but compresses to about ~480 kb with the uncompressed 2.6 mb .G-D file instead.

Any pointers on modifying DOOFUS.EXE and / or forcing the game to run with the uncompressed G-D. file? The DOOFUS.exe is compressed with pklite, and it decompresses to a ~580 kb .EXE file.

H!
First of all, you can't compress the game files with 7zip (the game will crash) , you need to use the game's original FAT file compressor/packer ("doofext.exe -c").
( Doofus.exe doesn't recognize a DAT file compressed with 7zip ; Doofus uses its own proprietary format )

I wrote and finished the full version of the LZSS original compressor/packer(237unpack 1.2 v6a) , it works %100 BUT I haven't published it (PRIVATE).
237unpack v1.2 v6a is a PRIVATE code and was written with a lot of effort, I don't intend to publish it .
The 237unpack v1.0 (download version) ONLY works with the - UNPACK - feature.
I provided a convenience for those who want to examine the game's code so they can UNPACK and examine these codes,
but Compressor/Packer is a different matter, all the effort is in the Compressor/Packer code 😀

The Decompressor/Unpacker code is already in the game for those who know x86 assembly language , those who look will see it, those who search will find it ..
but the Compressor/Packer code is NOT in the game it is only available to the programmers who wrote the game.
237unpack v1.2 v6a code was written from scratch by me (PRIVATE) = Compressor + Decompressor (It works without breaking/freezing or crashing the game.)

The game itself uses LZSS decompressor.
There is a way to change this , of course : adding -> 7zip decompression to the original game-source-code , but the source code is with the software company 😀
This game was made in 1994 , and the programming technologies it used were very good for that time... I think there's nothing else to say about that.

That's right, DOOFUS.exe is compressed with PKlite and extracted into a ~580 kb .EXE file.
The important thing isn't unpacking PKlite ; anyone can unpack PKlite these days , it's very easy .
BUT the critical point : x86 assembly knowledge and studying and reading machine language codes,
and developing new codes in response to those codes .. Pklite unpacking "Like walking in the park" 😀

First of all, you need to forget about using 7zip (unless you work for the doofus-company that wrote the game and you don't have the original source code of the game).
I don't understand what you'll gain ? ..by compressing the game with 7zip ?
It's 2026 and 2.5 MB is already a very small size for today.

EMX

I believe you've misunderstood. I didn't want to support 7zip archive within the game. All I wanted to use 7zip for is to archive the game into a smaller archive for storage purposes on my hard drive. The game will be decompressed from the hard drive to a RAM drive from the 7zip archive, and Doofus.exe run from there on the uncompressed 7zip files.

I wanted to know if the game might recognize the uncompressed .DAT files (the 52 .DAT files decompressed with your 237unpack.exe) when they're recombined into a new G-D file, which results in a ~2.6 mb G-D file. In other words, how might the game use these uncompressed files directly and not need to run its own internal LZSS decompressor? I undertstand your 237PAK.exe is private, I don't want to PACK files using the game's LZSS algorithm, I just wanted to UNPACK them so the game will run faster and the entire game will compress to a smaller size for my .7zip archive stored on my harddrive.

But, the UNPACKED G-D file is not recognized by DOOFUS.EXE. It seems to "expect" the .DAT files to be LZSS packed. I want to know if it's possible for the game to run directly with the unpacked files in the G-D file, which I've reassembled with your Doofext.exe utility. It seems like file offsets need to be modified in the new G-D file, or the game won't run / still thinks they're packed with LZSS. When I try to run the game, it freezes with black screen with the 2.6 MB G-D file instead of the old 590,932 byte LZSS-packed one.

Why would it?

The game has no idea what you have done to those files and will still be trying to find the original file offsets and data structures which were in the original file... which now no longer exist.

You would have to modify the code in the original .exe which seeks within those data files. Just changing the data files themselves won't achieve anything but breaking the game.

I agree with what Megatron-uk said ..
it's absolutely right
There's nothing else I can add .
If you don't have the original source code for the game , forget about the 7zip fantasy 😀

megatron-uk wrote on 2026-09-02, 06:33:

Why would it?

The game has no idea what you have done to those files and will still be trying to find the original file offsets and data structures which were in the original file... which now no longer exist.

You would have to modify the code in the original .exe which seeks within those data files. Just changing the data files themselves won't achieve anything but breaking the game.

Some games (Sierra games, for example) are robust enough to recognize if their RESOURCE.000 files are compressed (with an LZW algorithm, I believe) or not. They shipped with compressed RESOURCE.000 files, but these files may be decompressed and concatenated into a new RESOURCE.000 file via various AGI utilities. The SIERRA.EXE simply detect it, and happily runs the games with uncompressed data. The games run faster, and pack much smaller with modern archiving utilities like .7zip because of it.

A similar thing has been done with the 1988 game "Wasteland". Its data was decompressed and decompiled via a similar analysis that the OP did with DOOFUS, and the game's .EXE happily recognizes it uncompressed as well as with its (default) LZSS / LZW compressed state.

I was only trying to find out if the DOOFUS game is "smart" enough to also do this. It isn't about space savings in 2026 or 2.6 mb vs 590 kb. I just thought since the original poster had done so much work "deconstructing" and making useful utilities for this game and its data, that it'd be a cinch to know if the game's LZSS compression was mandatory or not.

There is a .FAT file in the game data files which *does* seem to have file offsets of some kind. I suppose these could somehow be modified, but it still wouldn't help if the game expects LZSS-compressed data and wasn't robust enough to also work with the uncompressed raw data.

Exactly, if the game itself doesn't have any means to detect if the game data files are packed or not, then changing their format isn't going to help - it's going to be doing blind seeks / reads into those data structures and getting gibberish in return.