OS/2 eZine - http://www.os2ezine.com
November 16, 2003
Alfredo Fernandez-Diaz was born in 1976 in Granada, SE Spain. He got into the warped world in 1996 shortly after beginning his studies in Theoretical Physics at the Granada University. He owned an Internet Cafe from 1999 to 2003, and in the meanwhile he founded a computing services company along with some other Spanish Warpers. He is currently at University again, studying Electronics Engineering while he tries to carry on with the company in the business world.
If you have a comment about the content of this article, please feel free to vent in the OS/2 e-Zine discussion forums.

There is also a Printer Friendly version of this page.

Previous Article
Next Article

Advertise with OS/2 e-Zine

Making a bootable CD

Building an OS/2 (or eComStation) Boot CD again - or: 333, the number of the beast/2.

What this is all about

We have just passed the 3rd quarter of the 3rd year of the 3rd millennium. OS/2 is still alive and kicking, and while it vanishes away (or not) its reincarnation, eComStation, gains strength. It is more certain than ever that the OS/2 community have an open future before our eyes. Certainly not an easy one but who knows the future anyway? We have a future, that many denied us.

But a lot of time has passed (again 3 years) since I wrote an article about how to boot OS/2 from a CD and things don't last forever in the computing world. My particular way of celebrating this rather special moment is to bring back to life this old project of mine.

In the next paragraphs and some following articles I'll describe the current status and issues related to the CD-boot process, the tools you'll need to make your own CDs, etc.
When we finish, you'll have the knowledge to make a great tool in your hands; a tool that can be very useful to everyone, in many many ways. A beast/2 ;-)


How to record data CDs or make ISO files will NOT be discussed here, but only which data should be on the CDs/ISO files, OS/2 boot configuration specific issues for booting and some "advanced" CD authoring issues.

Most of what I'll be explaining can be done on pretty much every platform, but for the OS/2 specific parts at least DOS compatibility should be handy to execute some configuration tools.

Although I can be contacted for help, in the article I'll assume a basic knowledge of CD authoring tools such as makeiso/cdrecord, RSJ or WinOnCD/Nero/whatever on the reader's part so I won't refer to program specific features but rather to abstract actions such as 'add the file XYZ to the CD filesystem' or 'set the boot image/method to ABC'.

The past

I intended to begin repeating what I already said in my previous article . I guess most of you already know that, but for the benefit of the newbies and for understandability and completeness sake I think we have to begin from the beginning. As an extra you'll notice that the new text has been slightly enhanced and cleaned up, not only in structure but in style as well. Er... at least I hope so.

However, due to timing issues that ended with me delaying this article for so long, I've decided to leave that boring part for my next article. Sorry for that. But this lets us concentrate on more up to date businesses :)

The present

So we begin where my former article ended and where its new incarnation will end next month: we have (or know how to build) a 'basic' CD.

Just to remember the basics, there's a 2.88+ MB boot floppy image (created dumping the info on the floppy sector by sector to a file) merged into the CD-ROM.
This image has a minimal OS/2 system on it that loads a special filter (CDBOOT.FLT) which can be found at Hobbes and after loading CDFS.IFS begins to read files from the CD-ROM filesystem itself. Then it creates a RAM disk, generates tailored INI files on it and boots a very basic OS/2 with WPS.

At this point it seemed that the hard part was done and all that was left was to add more functionality into this cd-booted system. Wrong.

The 'Floppy Emulation' problem

On July 29th, 2000 I got an email from Kim Cheung (in case you don't know he is one of the first visible Serenity Systems heads) stating he had read my article as it appeared on the VOICE newsletter July 2000 issue, and requesting help with one thing I had deliberately left in obscurity just to find out if people were really interested. Obviously Kim was interested enough to ask ;-)

This was the beginning of a somewhat sparse exchange of emails about this and that aspect of the process with the people from Serenity that has lasted until these days. I was doing this for fun and they weren't offering me a job, so though I was willing to help they simply asked for what they needed and worked on their won. This led to them facing a lot more test scenarios than me while I almost dropped the project, so they soon discovered there were a lot of problems out there for the CD boot process...

In the first days of November, 2000, I got a new email from Glenn Hudson, another SSI'er, requesting help to get eComStation boot from CD but using the 'hard disk emulation' method instead of the floppy emulation that we had been using. An increasing number of PC systems weren't able to boot OS/2 from a CD any more and displayed the deadly "OS/2 cannot operate the floppy or hard disk drive" message.

The 'No Emulation' method

For a variety of reasons I couldn't help them with that. Seeing how things have developed I'd say the other people they contacted had a limited success in the best case.

Fortunately for all of us there was still one method left, which has turned out to be the most efficient of what has been tried. It is called the no emulation method.

This method consists essentially in loading a small program from the CD (as allowed by the El Torito CD boot specification) and give it control inmediately. I think this is the most successful method because (s)he who developes such a program must be extremely careful on what (s)he's doing and must not rely on a manufacturer provided floppy/hard disk emulation, which turned out to be faulty in a lot of cases. Now let's have a look at the solution Serenity found for the problem, in hands of another well known OS/2 developer, Veit Kannegieser.


This excellent program can be found at Veit's homepage, and it works as I have already mentioned, plus it does a number of extra things. The details are in the program docs (though I have always thought that Veit should stop being so productive one day and sit down to write good docs ;) ), so I'll give just a quick explanation and a fast how-to.

The first part of the program is the loader, which used to be called memboot.bin but has been split lately into a true loader called cdloader.bin and the memdisk program itself due to some BIOS problems.
So when creating a bootable CD or ISO image file using this program to boot, you have to make sure the boot catalog points to cdloader.bin and establish the 'no emulation' boot mode. When cdloader.bin is loaded and executed, it looks for memboot.bin and loads it.

When memboot.bin is loaded it creates a RAM drive according to its configuration parameters that must be established in a response file and integrated into the program with the corresponding utility (that is you need to do this before getting a non-default memboot.bin). After that it creates LVM information for this RAM drive, applies boot code to its first track, unpacks the operating system files (OS2KRNL, CONFIG.SYS, etc.) onto the RAM drive, loads them and gives control.
When creating a memdisk-booted CD you have to pack the OS/2 boot files before including them in the CD/ISO file, the procedure is detailed in the memdisk docs. The packer is included with MemDisk. These files are the same you would use when booting in floppy emulation mode, with two exceptions: CDBOOT.FLT is not needed any more, and a new driver called MEMDISK.ADD must be included so OS/2 can access the RAM drive. Remember it was created by the loader, a program that was in memory, alive and kicking even before the Kernel was loaded.

Although the no emulation method seems the way to go, MemDisk is just one possible solution (and though it's still the only viable one there may be others). This program has several PROs and CONs I'm detailing next:

The PRO's

  • The most important pro is a practical one: it works and keeps us going. Now we can boot from CD in 99% of the cases, even most of those picky SCSI systems (with adequate drivers of course).
  • Being a RAM drive, the boot drive is now writable, which solves some minor problems that arise when booting in floppy emulation mode.

The CON's

  • Legacy (non-LVM) systems boot capability seems to be lost. This is being worked and should be solved sooner or later, but until new notice if you're trying to make a non-LVM OS/2 boot cd you're stuck with the floppy emulation mode.
  • MemDisk is a FAT drive.
  • Fixed size. The size of the RAM drive is fixed so you should calculate first the amount of space you'll need to copy files to it, although you can delete unused files (e.g. OS2KRNL) from the drive once they're loaded to make room for the new or dynamically growing ones (system INI files).
  • Bad RAM usage. I don't think RAM should be used to copy files that could be read directly from the CD in a better world.

Of course none of these is Veit's fault; I'm sure he has done his very best and MemDisk is a great tool. It's just I feel some aspects can still be improved. OTOH I'm dealing with OS/2 boot issues here, while Veit's MemDisk can be used to boot pretty much everything from the RAM drive.

We keep going

All in all, this superb program allows us to keep happily booting our favorite OS form CD without worrying any more. BTW and despite the mentioned CONs, MemDisk renders RAMFS pretty much unnecesary (not useless) to do the boot part.
We can therefore redirect all the write operations that take place during the boot process to the MemDisk drive: make INI files, build the desktop, etc.

Note (warning): the MemDisk drive is FAT so it should work OK for the WPS EAs stuff just like RAMFS, but simply be aware not to do something involving long file names...

So once again we're in a position where we should be definitely better off adding useful stuff to our CD i.e studying more OS/2 anatomy.

LANGUAGE and Unicode support, a step into modern times...

... And a little step back.
Beginning with some FixPak (I think it is 35 for W3 and 6 for W4), IBM decided to provide OS/2 with modern language support.
They also provided unicode support and some facilities to let these two magnificent add-ons be used with relative easiness by modern programs.
These facilities roughly consist of a LANGUAGE directory containing subdirs for all the supported languages and codepage definitions, the UNICODE.SYS support driver, the UCONV library and the environment variable ULSPATH that points to that LANGUAGE directory.

While I only know of one program that uses OS/2 LANGUAGE facilities currently (the OS/2 system editor E.EXE, instead of _all the system applets_ to begin with), it is true that NLS is getting more and more popular, though it is hand-made in most cases. However, there's something into which it's almost impossible not to step for what respects to language support: codepage conversion and unicode handling.
In fact, recent filesystems like FAT32 or JFS store filenames in unicode, so we better add this to our custom hand-made system before doing anything else.

So it seems LANGUAGE and UNICODE are a must. Fortunately we already had them when we were about to need them. Almost. Well, this project was indeed good intended, but the developers did a poor job.

UNICODE.SYS: When you want to do things your way...

...you usually get hit against a wall, didnt' you know?
As we have a ULSPATH environment variable that points to the right place, I moved the files to \OS2\LANGUAGE inside the CD filesystem, not to clutter excesively the CD-ROM root directory. Everything worked perfectly. Then I tried the next thing and errors started to arise. But let's proceed in logical steps. We have LANGUAGE ready, next stop: UNICODE.

It seems that the UNICODE.SYS developers thought: "Why use the ULSPATH variable that should point us to the right directory?" Instead, UNICODE.SYS is hard-coded to look for the codepage translation files it needs in \LANGUAGE\CODEPAGE on the 'current' drive (i.e. the boot drive because this happens during the boot process). I don't think this deserves by itself more comments other than how to face and solve the problems that this fact arises.
As you can imagine this harcoded search path renders useless %ULSPATH% and your fine file and directory placementes. Of course there seemed to be solutions:

  • Solution A: re-build UNICODE.SYS. Great.
  • Solution B: have the needed files in the forced \LANGUAGE\CODEPAGE directory of the boot drive. This looks easier, isn't it?

Well no, it's not easier. Perhaps it should not be that hard when booting in floppy emulation mode. However it's impossible when using MemDisk, because its pack method does not allow directories and the files can't be copied to the RAM drive with commands until all the DEVICE= statements (one of which loads UNICODE.SYS), in CONFIG.SYS are processed.


Fortunately, once again Veit Kannegieser comes to help us. This time he developed a device driver (LOCATECD.SYS) that you can get from his homepage and allows the current drive letter to be changed during the boot process. So all we need is the \LANGUAGE directory structure on N:. Then while booting from the MemDisk, Veit's device driver LOCATECD.SYS makes us switch to drive N: just before UNICODE.SYS is loaded in the next line.

For floppy emulated boot systems I also recommend following this method that avoids wasting boot image room to add the LANGUAGE files, and also lets you set up a more generic CD boot build environment to easily switch back and forth between emulated and non-emulated boot methods. In either case, I'd leave the ULSPATH environment variable set to this default location, so well-behaved programs and drivers can use it just like the others.

And one can hardly think of even more obstacles to get a useful boot CD. Luckily it seems that the universe ran out of bad ideas too, so we can get back to fill the CD...

Adding filesystems support

One of the main purposes of OSs is access data stored in disks, etc. so it seems a good idea to add some filesystem drivers to the CD.


As of today, I'd say 90% of the people out there are using one or other version of Windows, so more likely than not you'll probably face the convenience of being able to access FAT32 partitions. In fact I needed this myself so bad that I got involved in the development of the driver, but that's another story. How to add it to the CD?

This one was easy, so there's not much to say.
Files added to the CD:

  • N:\OS2\IFS\FAT32\FAT32.IFS

Note: from now on "N:" denotes the drive letter I use for the bootable CD; of course you can choose whatever you like.

CONFIG.SYS statements:

SET PATH=[...;]N:\OS2\IFSFAT32[;...]


This has to be the favourite of children and grown-ups. The brand new filesystem everyone is installing on their ACP/MCP and eCS machines. Is it worth? I'll let you judge it for yourselves, and I'll simply tell you how to get it onto the CD:

Files on the CD:

  • N:\OS2\JFS.IFS
  • N:\OS2\JFS.MSG
  • N:\OS2\JFS.SYM

CONFIG.SYS statements:


Note: You should locate this after the CDFS statement so the JFS can be accesed within the CD-ROM filesystem.

Anything else?

After that we have an OS that should be able to bot on pretty much every PC and acces pretty much every file on its harddisks. If you want to loop the loop, it's not too difficult to add NTFS support; but keep in mind the driver is available for eCS users only, for some reason. TVFS and even CDWFS from RSJ software can be added (with some limitations though)! But I'll leave those as an exercise to the advanced students.

As the base OS is quite complete now, at this point I'd recommend you to begin to think which "normal" applications you would need to have on a boot CD and add them yourselves. Think of it as yet another exercise. Just some suggestions: 'survival' tools for emergencies like File Commander/2, perhaps the Graham utilities, or an .INI file disassembler to perform forensic operations on a dead system .INI profiles...

Last words: I'll be back

Yes, this looks like a fairly long reading by now (or so I've been told), but I still have a couple more things to say about this, at least a complete backgroud review and a future implementations overview. And of course a credits section where I'll mention all the people who supported me one way or another, so stay tuned.

BTW, if someone tried to contact me using the e-mail address that appears on my first article, it's not valid anymore although you won't receive your emails bounced back. Use alfredo at netropolis-si dot com instead.

As said, I'll be back.

Previous Article
Next Article

Copyright (C) 2003. All Rights Reserved.