This article includes a list ofgeneral references, butit lacks sufficient correspondinginline citations. Please help toimprove this article byintroducing more precise citations.(July 2016) (Learn how and when to remove this message) |
| LHA | |
|---|---|
| Other names | LHarc, LHx, LH |
| Original author | Haruyasu Yoshizaki |
| Stable release | 2.13 / 20 July 1991; 34 years ago (1991-07-20) |
| Preview release | 2.55b / 24 November 1992; 33 years ago (1992-11-24) |
| Written in | Assembly language,C |
| Operating system | MS-DOS |
| Successor | LHA32 |
| License | Permissive license |
| Website | https://www.vector.co.jp/vpack/browse/person/an000224.html |
| LZH | |
|---|---|
| Filename extension | .lzh, .lha |
| Internet media type | application/x-lzh-compressed |
| Type code | "LHA␣" (L-H-A-SPACE) |
| Uniform Type Identifier (UTI) | public.archive.lha |
| Developed by | Haruyasu Yoshizaki (Yoshi) |
| Type of format | Data compression |
| Extended from | LArc |
LHA orLZH is afreewarecompression utility and associated file format. It was created in 1988 by Haruyasu Yoshizaki (吉崎栄泰,Yoshizaki Haruyasu), amedical doctor, and originally namedLHarc. A complete rewrite of LHarc, tentatively namedLHx, was eventually released asLH. It was then renamed toLHA to avoid conflicting with the then-newMS-DOS 5.0LH ("load high") command. The original LHA and itsWindows port, LHA32, are no longer in development because Yoshizaki is busy at his day job.[1]
Although no longer much used in the west, LHA remained popular inJapan until the 2000s.[2] It was used byid Software to compress installation files for their earlier games, includingDoom andQuake. Because some versions of LHA have been distributed with source code under thepermissive license, LHA has been ported to many operating systems and is still the main archiving format used on theAmiga computer, although it competed withLZX in the mid-1990s. This was due toAminet, the world's largest archive of Amiga-related software and files, standardising on Stefan Boberg's implementation of LHA for the Amiga.
Microsoft released the Microsoft Compressed (LZH) Folder Add-on, which was designed for the Japanese version ofWindows XP.[3] The Japanese version ofWindows 7 ships with the LZH folder add-on built-in.[4] Users of non-Japanese versions of Windows 7 Enterprise and Ultimate can also install the LZH folder add-on by installing the optional Japanese language pack fromWindows Update.
In an LZH archive, the compression method is stored as a five-byte text string, e.g.-lz1-. These are the third through seventh bytes of the file.
LHarc compresses files using an algorithm from Yoshizaki's earlier LZHUF product, which was modified from LZARI developed byHaruhiko Okumura (奥村晴彦,Okumura Haruhiko), but usesHuffman coding instead ofarithmetic coding. LZARI usesLempel–Ziv–Storer–Szymanski with arithmetic coding.
Joe Jared extended LZSS to use larger dictionaries.
Jared ported LZH to Atari. The fact that lh8 is the same as lh7 was an oversight. Files using larger numbered methods may as well not exist, as Jared only considers them planned features.[5]
UNLHA32.DLL uses its own method for testing purposes.
These compression methods are created by PMarc, aCP/M archiver created by Miyo. The archive usually has a .PMA extension.
LArc uses the same file format as .LZH, but was written by Kazuhiko Miki, Haruhiko Okumura and Ken Masuyama, with extension name ".LZS".[7] The program seems to have come before LZH. It uses abinary search tree in the LZ matching.[8]
Common implementations appear to only support lzs, lz5, plus the storage-only lz4.
There are copies of LHICE marked as version 1.14. According to Okumura, LHICE is not written by Yoshizaki.[9]
Because of a bug, DOS time stamps from Level 0 and 1 headers after the year 2011 will be set to 1980, meaning that some utilities need to be patched. This is caused by a bug that interprets the unsigned 7-bit year number bitfield as a 5-bit number. The maximum year should be 2107 instead.[10][11]
The newer Level 2 and 3 headers use a 32-bitUnix time instead. It suffers from theYear 2038 problem.[12]
According to Micco, the author of a popular LHA library UNLHA32.DLL, many LHA implementations do not check for the length of LHA file headers when reading the archive. Two problems could emerge from this scenario: a buffer-overrun may occur for naive implementations assuming a 4KB max size from the original specification; antivirus software may skip over files with such large headers and fail to scan for a virus. A similar problem exists withARJ. Micco reported this problem to Japanese authorities, but they do not consider it a valid vulnerability.[13]
Micco went so far to conclude the development of UNLHA32 and advise people to give up on the format. Nevertheless, they came back in 2017 to fix aDLL hijacking issue.