The EXE checksum field

EXE is a family of executable file formats used on MS-DOS, Windows, and some other operating systems. Every EXE file has a two-byte "checksum" field at offset 18. Here's a hex dump of a sample file: 0000000 4d 5a d8 00 2b 00 11 00 20 00 30 0f ff ff 1d 14 >MZ..+... .0.....< …

How DIET compression works

DIET is an old compression utility for DOS. It was developed by Teddy Matsumoto, starting in 1990. Its main feature is executable compression, but it can compress arbitrary data files as well. As an executable compression utility, it was not as widely used as PKLITE, LZEXE, or EXEPACK, but it might have been a contender …

Compiling lzhuf.c on a modern computer

There's an old data compression computer program named lzhuf.c ("Lzhuf"). It was written in the late 1980s by Haruyasu Yoshizaki. Even today, it is potential useful, if you want to support LHarc format, or certain other compression formats. But it doesn't work correctly when compiled by a modern C compiler. In this post, I'll investigate …

Notes on PKLITE format, Supplement 3: Checksum

This post is part of a series on PKLITE format. It assumes you have some knowledge of PKLITE-compressed files, and of DOS EXE files in general. For a list of all the posts in the series, see the first post. PKLITE versions 1.50 through 2.01 have a feature, invoked by the "-c" option, that does …

Fixing a hidden bug in PKZIP 2.04c

The non-clickbait title of this post is Notes on PKLITE format, Supplement 2: Not enough memory. This post is part of a series on PKLITE format. For a list of all the posts, see the first post. See the end of this post for links to most of the software mentioned in it. If you …

Notes on PKLITE format, Part 7: v1.20 compression

This is a continuation of my series on PKLITE executable compression format for DOS. For a list of other posts, see the first post. In particular, Part 3 is an important prerequisite. In a previous post, I named a then-unknown compression scheme "PKLC-U". In this post, I'll call it "v1.20 compression". I'll refer to all …

ColoRIX compressed 16-color format

This is a follow-up to my previous post on ColoRIX compressed 256-color images. Here I'll explain how to decode (at least some) compressed 16-color images. The short answer: The compression for 16-color images is the same as for 256-color images, except that the "XOR filter" step doesn't happen. The documentation for "RIX3" format (or "new" …

ColoRIX compressed image format

[Update: See also the follow-up post about the 16-color format.] There's an old DOS program named ColoRIX VGA Paint. It was developed by RIX Softworks in the 1980s. Its native graphics file format, which I'll call "RIX" format or "ColoRIX" format, can be read by a fair number of old DOS graphics utilities, and even …

Win32 I/O character encoding supplement 3: UTF-8 manifest

For a list of other posts in this series, refer to the first post. A relatively recent Windows software development feature, affecting character encoding, is the ability to request a specific "ANSI" character encoding (or "code page"), presumably UTF-8, using a manifest. I decided to investigate what this really does. This "manifest method" is independent …

Updated survey of LHarc and LHA

Since my first post on DOS versions of LHarc/LHA, I've found a few more versions of the software. Six of them appear to be original/official, and all of those are Japanese-language: 1.13d, 2.05b, 2.13, 2.52, 2.54, and 2.55. And I found quite a few new modified or hacked versions, two of which I'll discuss: "v1.14a" …