A Project to Replace OS2LDR Written by David C. Zimmerli

In this article I inaugurate a project aimed at replacing OS/2's "kernel loader"-- the file OS2LDR-- with a free version with source code available to all. I started this project after becoming frustrated not only with the cryptic and unhelpful output which the debug version of OS2LDR spews out on the COM port, but also with the generally undocumented and opaque nature of this important part of OS/2. Some of the obvious advantages of a source code version are the ability to customize debug output, rewrite the module to accommodate new types of hardware, and remove unneeded pieces, improving load time. Since I do not intend to charge for this code, I am calling the new module FREELDR. As I will explain later, however, it must be renamed to OS2LDR for the system to boot properly. I. The Project Plan I will start by listing some of the things this project will not do. The most important limitation is that FREELDR will not boot from a FAT partition (and therefore, unfortunately cannot boot from a floppy). This project does not encompass writing file system code, although for historical reasons, the necessary FAT file access code is included in the OS2LDR module, contrary to the OS/2 2.x boot architecture specification. This code really should have been removed and placed in a separate FAT.IFS file when OS/2 2.0 was released, but IBM apparently never got around to doing it. In any case, FREELDR is being tested on an HPFS partition, and should also work fine with any other file system written to the OS/2 2.x specs, including an eventual FAT.IFS if anyone wishes to write one. Secondly, FREELDR, unlike OS2LDR, will not be PS/2-aware, at least in its first phase. It may (or may not) run on a PS/2, but there will be no calls to ABIOS routines, nor any special support for MicroChannel expansion cards. An astonishing amount of code in OS2LDR is devoted to a PS/2 memory expansion board called the Aox MicroMaster, which apparently has different banks of memory that need to be managed and tracked. However, this is pure overhead to most users, since for ordinary AT-compatible machines the built-in BIOS routines have equivalent features. Thirdly, there will be no implementation of SYSxxxx error messages initially. Instead there will be user-customizable messages on both the debug terminal and the main machine during startup and callback operation. Thus FREELDR will not use the file OS2LDR.MSG. Fourth, FREELDR will not implement the seldom-used "system dump" facility of OS/2, which uses the file OS2DUMP. With the diagnostic abilities afforded by the source code for FREELDR, this feature should be unnecessary. Fifth, FREELDR will not support Remote IPL booting. This feature could be added later if desired. Finally, there will be no support for Compaq EISA BIOS calls. Again, this is something that could be added in the future. What will FREELDR do? It will do most of the same diagnostic and system initialization tasks performed by OS2LDR. It will implement the callback API described in my previous article, probably on a "lazy coding" basis as we see which API functions are actually getting called. And it will read in the kernel file OS2KRNL via calls to the micro-FSD, then use a set of 10 subroutines to do the necessary relocations and fixups. In the process, it will also build and pass to the kernel an "arena table" which details the system's use of memory and acts as a precursor to the GDT in protected mode. II. The Code So Far The FREELDR module is a "raw" binary file with no particular executable format (similar to a *.COM file from the DOS days). To build it, I have retrieved from my attic an old DOS compiler: Borland Turbo C++ Professional and Turbo Assembler. The source code will consist of mostly assembler for the system initialization and callback routines, and mostly C for the kernel loading routines. So far some of the assembly initialization code has been written, dealing with the timer chips, doing memory inventory, and communicating with the debug terminal. The C routine "KernelLoader" is basically just a skeleton at this point, demonstrating a call to the micro-FSD. The callback API will be left for last, when we start loading a real kernel and passing it real arena data. III. Building and Installing FREELDR To build FREELDR, simply copy all the source files to a single directory, say C:\FREELDR, and type: \tc\bin\make -ffreeldr.mak This will produce a file named FREELDR.COM, which you should then rename to OS2LDR. (If you are using something other than Borland Turbo C++, you will need to change the make file accordingly. Some of the C segment-handling code is also specific to Turbo C++.) Then, create a small, say 10 Mb or so, empty HPFS partition. Copy your new OS2LDR file to the root directory of this partition. Also copy in the standard version of OS2BOOT (this is the HPFS mini-FSD). Finally, copy in an LX-executable file called OS2KRNL. This can actually be any LX-executable-- it can be HELLO.EXE renamed to OS2KRNL-- but the micro-FSD will complain if it is not present. Now set your new partition to be a selection in Boot Manager, reboot, and select the new partition. You should see some output on the screen announcing FREELDR's presence with some diagnostic information. It should report the size of the OS2KRNL file you copied in, demonstrating that the micro-FSD "Open" routine worked properly. If you have a debug terminal hooked to COM2 (with the settings 9600,N,8,1), you will see similar output there. IV. Conclusion I hope I have whetted your appetite for the completion of this project. I welcome any and all outside assistance with this effort. Please e-mail me with offers or questions. Click here to download the source files for this article. Copyright © 1999, David C. Zimmerli. All rights reserved.