I use LZ-DOS all the time and it works perfectly as a replacement. I have not totally reverse engineer it, but I made a little "change to it" from this instruction.
""""Now, clip everything up to 0x205 in IO.SYS, since "mov si, 0205h" refers there.
Clip everything after ~04FFh bytes. You should now have a small file around 1300 bytes.
Save it as "DATA". Assemble this [edit: with TASM] and run it.
Omg, look, it "decrypted" into the exact same 1279 bytes that are at 0x202 in MS-DOS 7.10 IO.SYS.
What was the point of the LZ-DOS code? There wasn't. It just obfuscated it.
If you take 1279 bytes from MS-DOS' IO.SYS at 0x202, and paste it into LZ-DOS at 0x202,
over top of the 1279 bytes there...LZ-DOS will boot just fine. Why? LZ-DOS 7.10 is a hacked copy of MS-DOS 7.10.""""
I have removed the encryption code from my version, that´s about it.
Really like to disassemble or recreate that compression thing, but I have not exactly figured out how.
But I will get to it, I have even found an instruction:
Windows 95 and 98 IO.SYS/WINBOOT.SYS consists of three parts: the initial loader, the payload and the device configuration manager executable.
The initial loader (MSLOAD) comprises the first three or four0 512-byte sectors of the file; the first sector begins with the signature MZ,
the second starts with the signature BJ and the last ends with the signature MS.
The FAT boot sector puts the initial loader at real mode address 0070:0000, checks the first two of these signatures,
then starts execution at address 0070:0200. The job of MSLOAD is to copy boot sector variables into its data area (the first sector),
relocate itself to a higher memory address, load the rest of the file starting at segment 0x70 again and then transfer control to 0070:0000.
MSLOAD is immediately followed by the payload, which is the DOS kernel proper, loaded as described above.
Although it is loaded into a single contiguous region of memory, it is too large to fit into a single 64 KiB real-mode segment,
and so the DOS kernel is further split into regions addressed using different segment bases; discovering those will be up to you.
The length of this part can be determined by reading the word at offset 8 of the file, multiplying it by 16 and subtracting the length of MSLOAD.
The device configuration manager (MSDCM1) is a small executable whose purpose is to read the Registry and prompt the user to pick a hardware
configuration if there are multiple configurations defined. As it turns out, it is no accident that IO.SYS begins with the signature MZ,
just like DOS executables; the file is simultaneously a regular EXEPACK-compressed DOS executable,
and the values in the MZ header at the beginning of the file allow it to be executed using interrupt 0x21 service 0x4b,
which will load the third part of the file. If the real-mode kernel detects that it is booting a Windows installation,
the kernel will do just that early in the boot process, before even CONFIG.SYS is processed.2 The word at offset 8 is simply the
‘header length’ field of the MZ header, used both by MSLOAD to determine the length of the payload,
and by the MZ loader to skip over the payload when loading MSDCM.
To recap:
MSLOAD can be disassembled by loading the first four sectors of IO.SYS as a raw binary at address 0070:0000 and placing the entry point at 0070:0200;
The payload can be disassembled by cutting it out of the file, decompressing it (if compressed), loading it starting at segment 0x70,
placing the entry point at the beginning of that segment (i.e. at 0070:0000), and discovering other segments by trial and error;
MSDCM (before Millenium) can be disassembled by using an EXEPACK decompressor and disassembling the output as an MZ executable.
I am aroused about any X86 motherboard that has full functional ISA slot. I think i have problem. Not really into that original (Turbo) XT,286,386 and CGA/EGA stuff. So just a DOS nut.
PS. If I upload RAR, it is a 16-bit DOS RAR Version 2.50.
