Just Solve the File Format Problem - Recent changes [en]

Dunfield Help

Arnoudmulder — Mon, 05 Oct 2026 23:05:28 GMT

Created page with "{{FormatInfo |formattype=electronic |subcat=Help files |extensions={{ext|hlp}} }} The help files used by tools written by Dave Dunfield use a self-defined file format. == Spe..."

New page

{{FormatInfo
|formattype=electronic
|subcat=Help files
|extensions={{ext|hlp}}
}}
The help files used by tools written by Dave Dunfield use a self-defined file format.

== Specifications ==

Sources can be found in IMD.C. There is no file header. The topics are stored sequential. Each topic starts with a 16-bit little-endian integer, indicating the number of bytes of ASCII topic data to follow. The topics are addressed by zero-based index number.

The contents of the topic can contain the following special codes:
00 = new line, to be replaced by 0x0A
0E = start of link
0F = end of link, followed by a byte with the topic index number
09 = tab
12 = dos character, up/down arrow
18 = dos character, up arrow
19 = dos character, down arrow
1A = dos character, right arrow
1B = dos character, left arrow

== Identification ==
The files do not have a easy to detect signature. A way to detect is to check the 16-bit size is >128 and <1024, and not beyond the end of the file. Then scan the topic data for valid special/ASCII codes. If more then lets say 2 valid topics have been read then assume it is a Dunfield HLP file.

== Sample files ==
* IMD.HLP
* H8.HLP
* HORIZON.HLP

Help files

Arnoudmulder — Mon, 05 Oct 2026 22:52:30 GMT

User:EZPZ File

EZPZ File — Mon, 05 Oct 2026 01:49:54 GMT

EZPZ File created a user account

CorelDRAW

Tomxe — Sat, 03 Oct 2026 11:19:09 GMT

Linear Executable

Jsummers — Sat, 03 Oct 2026 00:02:23 GMT

‎See also:

EXEPACK2

Jsummers — Fri, 02 Oct 2026 23:49:09 GMT

‎See also:

Compression

Jsummers — Fri, 02 Oct 2026 23:48:29 GMT

‎Compression algorithms and compressed data formats:

EXEPACK

Jsummers — Fri, 02 Oct 2026 15:23:37 GMT

‎See also:

LX Iterated Data Page

Jsummers — Fri, 02 Oct 2026 15:21:41 GMT

Created page with "{{FormatInfo |formattype=electronic |subcat=Compression }} '''LX Iterated Data Page''' (correct name unknown) is a compression scheme sometimes used to compress parts of an [[..."

New page

{{FormatInfo
|formattype=electronic
|subcat=Compression
}}
'''LX Iterated Data Page''' (correct name unknown) is a compression scheme sometimes used to compress parts of an [[Linear Executable|LX]] (OS/2) executable file. It's usually non-executable resources that are compressed, not executable code.

The decompression is done by the OS/2 loader.

The compression may be requested via the linker option <code>/EXEPACK</code> or <code>/EXEPACK:1</code><ref>https://www.os2.kr/komh/os2books/os2tk45/toolsref/156_L4_ExepackE.html</ref>. So, it might sometimes be referred to as "EXEPACK" or "EXEPACK:1" or "EXEPACK1" compression, though it's not related to Microsoft's common [[EXEPACK]] compressor.

See also the successor [[EXEPACK2]].

== Format details ==
The compression scheme is a kind of [[Run-length encoding|RLE]]. Not just single bytes, but also multi-byte patterns can be repeated.

== Specifications ==
* [https://www.edm2.com/index.php/LX_-_Linear_eXecutable_Module_Format_Description#Iterated_Data_Pages LX Module Format Description], "Iterated Data Pages"

== Sample files ==
(LX files that have some compressed pages)
* {{CdTextfiles|hobbesos2/2_X/GAMES/DCHESS.ZIP|DCHESS.ZIP}} → *.EXE
* {{CdTextfiles|nightowl/nopv17/044A/PGMG035.ZIP|PGMG035.ZIP}} → *.EXE
* {{DiscMasterLink|view/41006/devcon-05-cd1.iso/os2se21/disk_10/sysmono.bmp/OS2/DLL/SYSMONO.FON|SYSMONO.FON}}

== References ==
<references />

[[Category:Executable compression]]
[[Category:OS/2]]

X-Face

St. GIGA — Fri, 02 Oct 2026 10:24:15 GMT

Add info on Heraldry hatching

ZIP

Jsummers — Thu, 01 Oct 2026 17:51:10 GMT

‎Software:

PKLITE

Jsummers — Thu, 01 Oct 2026 17:49:57 GMT

‎Software:

X-Face

St. GIGA — Thu, 01 Oct 2026 16:12:22 GMT

Add info about perceptual RGB574 support

PKLITE

Jsummers — Thu, 01 Oct 2026 11:51:16 GMT

‎Software:

User:Polluks

Polluks — Tue, 29 Sep 2026 11:05:19 GMT

CHP

DBase III

Ross-spencer — Tue, 29 Sep 2026 08:36:37 GMT

Add reference to Redabas

Template:PRONOM

Ross-spencer — Tue, 29 Sep 2026 08:30:09 GMT

Update template to use new PRONOM

@@ Line 11: / Line 11: @@
 * [[CHM]] (Microsoft Compiled HTML Help)
 * [[CZ Help]]
 * [[Help Librarian]]
 * [[HLP (WinHelp)]]

@@ Line 119: / Line 119: @@
 * [https://github.com/unoconv/unoconv unoconv]
 * [https://github.com/kaitai-io/coreldraw_cdr.ksy/blob/master/bin/cdr-unpk coreldraw_cdr.ksy KaiTai structure]
 == Sample files ==

@@ Line 32: / Line 32: @@
 == See also ==
 * [[Dynamic-link library (Windows)]]
 * [[EXEPACK2]]
 == Links ==

@@ Line 12: / Line 12: @@
 == See also ==
 * [[EXEPACK]]
 * [[OS/2 Boot Logo]]

@@ Line 36: / Line 36: @@
 * [[InstaCompOne]]
 * [[Lempel–Ziv–Stac]] (LZS)
 * [[LZ77]]
 * [[LZ77 with Huffman coding]]

@@ Line 42: / Line 42: @@
 == See also ==
-* [[EXEPACK2]]
+* [[EXEPACK2]] (OS/2 EXEPACK:2)
 == Software ==

@@ Line 43: / Line 43: @@
 Note that having 24 headers for a static 48x48 Datula RGB header bloats in size by the time one adds multi and animation, and FaceMake asks users if they are really sure that they want to go all the way to 24-bit multi because the header size starts to add up very fast.
-Oh and another factor is that in theory you COULD do HDR and image sizes beyond what some formats support. If you, say, did X-Face-0 and X-Face-8 through X-Face-9, you could go beyond 10bpc HDR, and maybe hit 12bpc. Though you could go higher. Also a construct like X-Face-A: through X-Face-A9: could be used for an alpha channel for APNG parity. And if you wanted to do distance fades like can be done in the Source Engine with VTF/[[Valve_Texture_Format]] sprays, you could in theory do that too with extra fields. Since X-Face-el doesn't see the 7 least significant bits in a 48x48 TrueColor X-Face but sees a version of the image that is recognizable (albeit only in 48x48 mode), a decoder could just ignore the HDR and alpha components if it only does Datula mode at best. On the topic of Datula, DFaceEx by Saku works (the Datula X-Face plugin credits this person as SAKUDA Yasunori) has the unfortunate nature of supporting 3-bit RGB, multi, and animation, but not grayscale or TrueColor mode. The 24-bit version that came after, but only in Datula, not the other apps, had added it as a bonus feature over the X-Face-el parity addition of grayscale, and the readme warns that X-Face-el apps like Gnus will not display it properly and so interchange of it was marred, but at least SAKUDA Yasunori saw this avenue for improvement and did so in the simplest way that by sheer chance is easy to replicate even after the source code has become lost media and only FaceMake and the plugin as binaries survive, and even then only on the Wayback Machine, and it's hard to get to even then. Also the source code for X-Face-el is interesting in that it stores the 8 colors possible for 3-bit RGB as sections with full-on RGB hex codes. So hypothetically 3-bit could be tinted, or the colors redefined, such as if you're using a grayscale monitor, or you're outputting to terminal. Mapped colors would work to resolve such situations without inherently forcing 1-bit. Viewers could just assign the codes to a shade of gray or to a certain color in the terminal's palette. This could also help on low-spec video hardware. You can almost treat 3-bit RGB as indexed color. But far from the number of colors, the other thing to consider when optimizing Datula X-Faces is what bits in a scene's colors are set. In general, this is where the computation gets interesting, because of how everything is bit-by-bit.
+Oh and another factor is that in theory you COULD do HDR and image sizes beyond what some formats support. If you, say, did X-Face-0 and X-Face-8 through X-Face-9, you could go beyond 10bpc HDR, and maybe hit 12bpc. Though you could go higher. Also a construct like X-Face-A: through X-Face-A9: could be used for an alpha channel for APNG parity. And if you wanted to do distance fades like can be done in the Source Engine with VTF/[[Valve_Texture_Format]] sprays, you could in theory do that too with extra fields. Since X-Face-el doesn't see the 7 least significant bits in a 48x48 TrueColor X-Face but sees a version of the image that is recognizable (albeit only in 48x48 mode), a decoder could just ignore the HDR and alpha components if it only does Datula mode at best. On the topic of Datula, DFaceEx by Saku works (the Datula X-Face plugin credits this person as SAKUDA Yasunori) has the unfortunate nature of supporting 3-bit RGB, multi, and animation, but not grayscale or TrueColor mode. The 24-bit version that came after, but only in Datula, not the other apps, had added it as a bonus feature over the X-Face-el parity addition of grayscale, and the readme warns that X-Face-el apps like Gnus will not display it properly and so interchange of it was marred, but at least SAKUDA Yasunori saw this avenue for improvement and did so in the simplest way that by sheer chance is easy to replicate even after the source code has become lost media and only FaceMake and the plugin as binaries survive, and even then only on the Wayback Machine, and it's hard to get to even then. Also the source code for X-Face-el is interesting in that it stores the 8 colors possible for 3-bit RGB as sections with full-on RGB hex codes. So hypothetically 3-bit could be tinted, or the colors redefined, such as if you're using a grayscale monitor, fully monochrome monitor if you use Heraldry Hatching, or you're outputting to terminal. Mapped colors would work to resolve such situations without inherently forcing 1-bit. Viewers could just assign the codes to a shade of gray, a Heraldry hatch pattern, or to a certain color in the terminal's palette. This could also help on low-spec video hardware. You can almost treat 3-bit RGB as indexed color. But far from the number of colors, the other thing to consider when optimizing Datula X-Faces is what bits in a scene's colors are set. In general, this is where the computation gets interesting, because of how everything is bit-by-bit.
 Also for what it's worth, it should be noted that X-Face: headers that use extensions relentlessly tend to in their pieces in, say, a very least significant bit, be quite a lot like the worst-cases X-Face: itself has. As such the compression ratio of the most complex X-Faces gets worse the higher you go. Even if you're doing optimizations. Cartoon/drawn/anime content most likely will compress better than a photorealistic video taken by a camera. But this isn't guaranteed, of course. That being said, if making an X-Face: or Face: header, regardless of what mode is used, it should preferably made using exclusively-lossless source material, which on top of preserving as much quality as possible, will also cut down on file size inflation, because anything like [[JPEG]] noise is going to bottleneck the efficacy of the bit-by-bit operations going on. This is '''especially''' bad on non-photographic images, but of course the efficacy on photographic images will be even worse than it already is. Extended X-Face: is probably the least-efficient compressed video codec other than RLE-only methods. Another factor to consider in X-Face's hyper-extended cases is whether or not one can still open a .xface or .face wrapper in a text editor. If you get Datula's FaceMake to output its maximum of 240x240px 24-bit, that exceeds 100KiB, and this is for static images. If you throw in moving pictures, 10 frames can result in getting the file to a megabyte+. Some text editors REALLY dislike opening files in the megabytes range. So that's another factor, namely that doing anything like proper video out of extended X-Face will have issues being able to be copied in a way creepily similar to [[BWTC32Key]]'s text output after being fed a file that compresses to around a megabyte of text and especially larger. Basically, while X-Face videos CAN exist (ignoring the fact that Datula crashes on 48x48px animated Bad Apple!) they are a bit hard to come by in terms of software support, and even the operating system can suffer if something too excessive is mishandled. Pixel art behaves the best, so long as you respect what is and isn't doable.

@@ Line 281: / Line 281: @@
 * {{XAD}}
 * [[Xelitan Zip]]
 == Sample files ==

@@ Line 197: / Line 197: @@
 * {{CdTextfiles|simtel/simtel20/MSDOS/EXECOMP/LOWFIX.ZIP|LOWFIX}} - Patches v1.00-1.05 to fix bugs, and changes the version number to 1.06.
 * [https://github.com/jsummers/pkla pkla] - Analyzer utility
 * See also [[MEGALITE]]
 * See also [[PKTINY]]

@@ Line 22: / Line 22: @@
 Another factor is that unequal channel depths in a TrueColor X-Face have been found to work even though the relevant X-Face-Type: header (which contains, separated by semicolons, geometry=NxN for multi, animate=N for animation, status="experimental" in X-Face-el's oldest versions that in effect is like X-Face-Version:, and MONO for 1-bit B&W, and RGB or GRAY for color and grayscale, the latter two with a depth=N field with a value from 1-to-8 and these do not have to be in this order (for instance something like "X-Face-Type: geometry=2x1; GRAY" is valid, and only the flags you need can be used, and superfluous fields like geometry=1x1 on a 48x48px X-Face are relatively safe) only has one depth value. More-consistently is that because grayscale (and by extension Datula color components) features X-Face-1: through X-Face-7: headers, it is also at least plausible to change bit depth per frame too, even potentially in conjunction with this, which is quite helpful for usage in situations where excessive size is a problem, such as, say, the Internet speeds of the format's early days, 1989 through the 1990s, and up until Face: headers. Dial-up's slow speed was the issue, though later dial-up standards can handle even the best X-Faces that Datula can '''send''', given that Datula has a limit somewhere near 24KiB for custom headers. It's the 1989-era dial-up speeds where this is a problem, but given that X-Face-el started in 1996, and Datula TrueColor only happened in 2002, by the time X-Face was actually extended, the modem speeds on the market could handle even one-of-every-extension headers, especially given that those headers were not a monolithic single header but instead multiple separate ones, and the monochrome one could load the earliest on a slower dial-up connection (assuming loading is done in order) even as the rest of the full header suite is still loading in, so on paper even non-landline dial-up could handle one. Now a 240x240 animated TrueColor header on the other hand would struggle even on 56K or ISDN. Now, of note is that Datula has a dial-up option (and for modern users wishing to send X-Faces even on dial-up, so does Hidemaru Mail), so this could explain why sending beyond ~24KiB is disallowed, because even V.92 dial-up could only send at 48kbps, and so 24KiB over that speed would be about 4 seconds to send, not to mention that e-mail servers were another factor.
-So in theory it is possible when converting color animations to optimize the headers for size as needed based on colors usage. So if a scene favors Red, Green, or Blue (or multiple), you can allocate the most-used relevant channel(s) more bits (assuming you are skipping out on full 24-bit to save space, fit a limit, send faster on weak dial-up, and/or accounting for the human eye being more sensitive to green), and do this per-frame. And FaceMake allows one to set the bit depth of the color components to uncommon sizes not possible in [[PNG]], and that's without the unequal component ones in which manual assembly is needed to utilize it, let alone the per-frame depth changes. There's really no limits here. Of course, encoding this type of fancy optimized X-Face is a tall order, given this complexity.
+So in theory it is possible when converting color animations to optimize the headers for size as needed based on colors usage. So if a scene favors Red, Green, or Blue (or multiple), you can allocate the most-used relevant channel(s) more bits (assuming you are skipping out on full 24-bit to save space, fit a limit, send faster on weak dial-up, and/or accounting for the human eye being more sensitive to green, and blue being a color that the human eye isn't all that sensitive to, so an RGB574 scheme where Red is 5 bits, Green is 7 bits, and Blue is 4 bits for a 16-bit scheme like the "common" RGB565 that exploits humans being most sensitive to green by giving it an extra bit. RGB574 is basically RGB565 but accounting for the human eye ALSO being less sensitive to blue, and THIS is a type of color that no existing image format supports, but because extended X-Face is built the way it is, bit-by-bit, you can do stuff like this to compensate for its weak compression), and do this per-frame. And FaceMake allows one to set the bit depth of the color components to uncommon sizes not possible in [[PNG]], and that's without the unequal component ones in which manual assembly is needed to utilize it, let alone the per-frame depth changes. There's really no limits here. Of course, encoding this type of fancy optimized X-Face is a tall order, given this complexity.
 Modern encoders would be able to handle this significantly easier, given how many modern codecs rely on perceptual tricks and fast PCs.

@@ Line 167: / Line 167: @@
 ** {{CdTextfiles|swinnund/disk3/FILEUTIL/PKLITE.ZIP|v1.00β/1990-05-29}} (leaked private beta[http://cd.textfiles.com/simtel/simtel20/MSDOS/INFO/PKLITE.WRN])
 ** v1.00β/1990-07-17: {{DiscMasterLink|browse/33121/ibm0000-0009/ibm0009.tar/ibm0009/PKLITE1B.ZIP|PKLITE1B.ZIP}} (apparently another leaked private beta)
 ** fake v1.20 (1992-08-20): [{{CdTextfilesURL|thegreatunsorted/old_apps/dosutils/pklite.zip}}], [http://www.dcee.net/Files/Archiver/pklt120r.arj], [http://pub.agrarix.net/DOS/COMPRESS/PKLT120R.ARJ]
 ** Hacked "XADi" version of PKLITE 2.01-shareware. Claims to support the <code>-e</code> option, but it only does a little of what the real software does.

@@ Line 14: / Line 14: @@
 * [[MZF]]
 * [[Chipmon]] II
 == Reggae ==

@@ Line 42: / Line 42: @@
 * [http://www.textfiles.com/programming/FORMATS/dbasefil.inf dBase III file structure]
 * [http://stackoverflow.com/questions/14008534/opening-and-searching-dbase-iii-dbf-databases-in-python Opening and searching dBase III (DBF) databases in Python]
 See [[DBF#Links]] for more links related to DBF format.

← Older revision		Revision as of 08:30, 29 September 2026
Line 1:		Line 1:
−	[https://~~www~~.nationalarchives.gov.uk~~/PRONOM~~/{{{1}}} {{{1}}}]	+	[https://pronom.nationalarchives.gov.uk/{{{1}}} {{{1}}}]