 VOICE Home Page: http://www.os2voice.org |
[Previous Page] [Next Page] [Features Index] |
|
VOICE Home Page: http://www.os2voice.org |
[Previous Page] [Next Page] [Features Index] |
By Alfredo
Fernández Díaz ©July
2000Team OS/2 España : http://www.caballe.com/teamos2 |
In the first place I'd like to make it clear that I have learned
everything in this article by the ancient method of trial and error. Therefore,
following these instructions could lead to totally unforeseen and absolutely destructive
results on your particular system, for which I am in no way responsible. Having
given this common sense warning, let's begin.
Though the instructions accompanying an essential filter by
Allen Dermody in cdboot.zip
(available at Hobbes) are quite clear and explicit, I'd like to make a few points:
They were in English (a problem I could solve just for Spanish users but isn't
that really a point here :) ).
There are several little mistakes made by someone at IBM that were not covered in
Mr. Dermody's instructions and may cause any non-English (and many English) OS/2
systems not to be able to boot from a CD. Why? I suspect compilation problems, but
please direct any complains on this to IBM ;). For more information on this, see
below.
I've just heard of a competitor :) who has acheived a text mode boot system after
working for a long time on it. We go far beyond that in this article, with the hope
that it will be useful for people out there and save them a lot of time.
In this article we do things that Mr. Dermody (without whom this article wouldn't
have been possible) just dreamt of ;)
To reach our goal we need three tools. The first is the filter that allows OS/2
to boot OS/2 from the CD. It is on Hobbes, along with Allen Dermody's documentation
in Hobbes, at ftp://hobbes.nmsu.edu/pub/os2/system/drivers/cdrom/cdboot.zip.
Without this, we can do NOTHING. The second and third are LoadDskF and SaveDskF
are two IBM disk utilities that allow to copy entire floppy images to hard disk
and viceversa. As with almost everything we need, we can find them at ftp://hobbes.nmsu.edu/pub/os2/util/disk/loaddf.zip.
Patience in huge quantities, a CD recorder and RE-writable CDs. Unfortunately, we
can NOT find this in Hobbes ;-)
Some additional tools that we don't really need but are VERY helpful are:
Note: We are using a hard disk partition instead of a floppy drive for space
reasons: the minimum required files get easily beyond 1.44 MB in size and I have
no idea about how to *manually* split the OS/2 boot into two floppies (please if
anyone has an idea on this contact me).
To do this, we have to type SYSINSTX
X:, where "X" is the drive letter we want to boot. The program
SYSINSTX.COM is in the OS/2 boot floppies if we don't already have it (I always
add it manually to my system). This will create a file called OS2BOOT in the drive
we are using to experiment with. As you may know, this alone won't allow us to do
anything, since it is just the system boot record. Then we need to add, (using
the copy command),the following files: OS2LDR, OS2LDR.MSG and OS2KRNL, which
are the OS/2 kernel and loader.
Now it's time to use WarpBoot so the kernel we are going to
experiment with always shows the files it loads. If not, we'd have to press Alt+F2
each time we boot the system, which can get tiring.
An important thing to keep in mind is that the first IFS loaded
in config.sys has to match the partition type of the drive we boot. For example,
if we boot an HPFS partition, the first IFS line has to be IFS=HPFS.IFS or OS/2
won't boot at all. As OS/2 FAT support is -unfortunately- hard-coded in the OS/2
kernel, there's no need of an IFS for FAT drives. So if we boot a FAT drive the
order in which IFS are loaded is not relevant to the boot process. Incidentally,
the OS/2 boot from a CD is made emulating a floppy. Under OS/2 a CD can only be
FAT formatted. So it is not necessary to load HPFS.IFS first when booting the CD.
The immediate consequence of all this is that the first IFS we'll load will be the
CDFS to read the rest of the programs from the CD. But we'll get to this later.
After many boot-ups in which a new OS/2 system complains about
a new file (I strongly recommend all these tests on a maintenance partition; it's
faster than a floppy) after adding all, we obtain a list of files like this.
This is a list of the ***minimum*** files we need to boot an OS/2 system. Keep in
mind the following considerations:
The idea was to obtain the smallest possible OS/2 system that
allows us to reach every corner of our system and run some simple text-mode applications.
This system has to be as small as posible because we can't assume we have more than
2.88MB of space available, due to some CD-booting issues. But it's not logical to
save space getting rid of floppy of hard disk drivers either, is it?
The minimum system we have built accomplishes these two goals:
it allow us access all the filesystems and it's pretty small. What is more, we can
execute text-mode apps.
Unlike for example Windows 98, the graphical environment in
OS/2 has nothing to do with multitasking and memory protection, so even from a command
line we can do some things at the same time (perhaps winusers still have some things
to learn ;) ), e.g. editing the C: config.sys while CHKDSKing D: and so on. Here
comes BootOS2. At a cost of just 9604 bytes it brings a protected mode interface,
BOS2SHL.EXE, that can switch between sessions. So, we can choose to specify PROTSHELL=CMD.EXE
in config.sys and have a real minimum system or PROTSHELL=BOS2SHL.EXE to
have something "somewhat" better. What is more, we can
add REXX support to this minimum system just by copying BOS2REXX.EXE, 3 DLLs and
a new line to config.sys. Everything at a cost of just 320 kilobytes.
We can even add the most basic tools to work: ATTRIB.EXE, CHKDKS.COM and the other
files commented in the file list without reaching the
2.88 MB limit.
Theoretically, we already have a system that boots, eats up
little space and allows us to have a look at any part of our system except for now,
serial and parallel ports and some other things. As I said, the system we have right
now works. At least mine does. If someone is having difficulties this early he/she
should contact me.
It's time to transfer this system to a CD and see what happens.
I had to do a lot of testing, and disturb a lot of people during the making and
testing of this system, so I'd recommend to use RE-writeble CDs and have a CD drive
able to read them. Needless to say, before transferring the system, add the line
BASEDEV=CD_BOOT.FLT to the CONFIG.SYS and add the appropriate file which
must be put in their right place.
If someone has managed to get a *complete* bootable system
on a single 1.44 MB floppy or split it in two 1.44 floppies, may he speak now or
shut up forever ;). In order to boot an OS/2 CD, it has to contain a 1.44 or 2.88
floppy sector-by-sector image. How can we make such an image of our system?
If the mini system were on a floppy, it's enough to execute SAVEDSKF X: IMAGE.144
/D /A, where X: is the floppy drive we're using and IMAGE.144 the image file.
We perform a similar procedure if we are working with a 2.88 MB floppy. If it were
on two floppies I have no idea about how to do it. (EXPERIMENTAL PROCEDURE, NOT
TESTED: it should be as easy as modifying the CONFIG.SYS line to
say BASEDEV=CD_BOOT.FLT /2, creating an image of each of the two floppies
and appending them typing COPY /B IMAGE_1.144 + IMAGE_2.144 ALLINEED.288,
and we'd have the file ALLINEED.288 ready to go on.) If we're working in a hard
disk partition, then we'll have to use Super Virtual Disk, in four easy steps:
-Once installed, we cfg it to simulate a 2.88MB floppy as drive X:.
-Execute SYSINSTX X: to put a system boot record on it.
-Copy to X:\ all of the boot system files *EXCEPT* OS2BOOT.
-Create an image of X: executing SAVEDSKF X: IMAGE.288 /D /A
Once we have created an image file of our system, we mount
it on a CD and mark it as bootable. In the Windows world there are several that
allow us to do this, but we're not going to comment on them ;-). In OS/2 we can
do this with RSJ, MakeIsoFS + CDRecord or Unite CD Maker.
After this first hit, as always, came the second one. During my original experiments
I followed Al Dermody's instructions exactly, so in the middle of the boot process
the system tried to read things from the CD in the N: drive. Tha main disadvantage
of this was that I had to test 5 differet versions of the CD-ROM driver OS2CDROM.DMD
before I found one that worked. The others simply didn't load in memory. Although
the CDFS.IFS loaded, there were no CD-ROM drives to access and the boot ended abruptly.
The funniest thing is that during the previous tests, when everything was loaded
from HD, none of the OS2CDROM.DMDs I tested complained about anything. Funny.
The solution I found is what we have done here a priori to avoid problems:
the entire system we have built is self-contained, that is, there are no references
nor we need external files. The advantage is quite clear: if OS2CDROM.DMD does not
load during the boot process, this won't force the system to stop booting because
it cannot acces this or that file, but will end up at a command prompt. What we
have then is something like the utility disks, but mounted on a much faster disk
(but we won't be able to access the CD-ROM drives). From here, if the system boots
from CD and we can access the drive letter N:, everything is OK, we can go on. If
not, there are more versions of OS2CDROM.DMD to test. The one I'm using (see the
list) seems to be quite reliable, but who knows.
From now on we are going to detail a bit less on the necessary steps, in part
because this is a very free field and anyone can find his/her own way to do everything
as he/she likes the bestwhich has always been a fundamental part of OS2 users'
philosophy, in part because I promised to translate this article a month ago.
As always, if someone has any question, please contact me.
The first thing to do is add PM support. How to do it? Obviously, by adding the
appropriate files. What are the appropriate files? The author of BootOS2 has the
answer. This little wonder of modern technique allows to generate a "mantenance
system" for every known version of OS/2, with as many components as we want,
like WPS, DOS support, system editor... You can use some other shells for the system,
such as MShell, Roman Stanglier's Program Commander/2, etc, but the BootOS2 method
has the advantage of not introducing 'external' files. The idea now is to create
a system as complex as we want using BootOS2 and then adapt this system what we
have learnt while creating our 'poor' command line from the CD.
Once such a system has been generated, there are several considerations to make
before getting it onto a CD. The first is that the system on the CD will be frozen,
since CDs are read-only media. But we can store several 'system snapshots' in the
CD to boot the one we like most. The second is the Desktop. The Desktop uses intensively
a special feature of OS/2: the Extended Attributes, which are not supported by the
CDFS.IFS. The solution I found is to use a RAM disk to store the system Desktop.
If we store the system in the CD in such a way that the Extended Attributes are
not altered (for example in a ZIP archive) and then we pass it to the RAM disk before
the WPS starts everything is done, right? A baby could do that with one hand tied
to his back. Well, it's not that easy, but almost.
The first thing we need is an adequate RAM disk; Super Virtual Disk has several
disadvantages: it's not free, though it may block the allocated memory it's not
dynamically allocated, and it isn't resizable. RAMFS64,
on the other hand works quite well and I can't see any inconvenience. Let's add
it to the WPS system created by BootOS2, and modify CONFIG.SYS so that during the
boot the drive O: is created, just after N:, which is reserved for the CD drive.
All the details are covered later, along with some other things.
Now we have to isolate what is to be stored in the RAM disk. Namely, only the
INI files USER_INI, SYSTEM_INI and the Desktop directory tree. The initial INI files
generated by BootOS2 are programmed to live in the destination drive, along with
the Desktop. Changing this is very easy. As we already know what to do with the
RAM disk, we are going to create a BootOS2 system from scratch and program it in
such a way that these files live in the RAM disk from the beginning. Once we execute
BootOS2, we must disassemble BOS2SYS.INI with INITools (now with INI2Rexx) and change
the destination letter for the Desktop to "O:\", our RAM disk. (For
non English users, this is a perfect moment to translate the whole system , since
BootOS2 creates an English WPS.) We change the INI statements in CONFIG.SYS and
we're ready to go. Before booting the BootOS2 system we have to create a ZIP archive
to store the INI files and add a line to CONFIG.SYS to decompress them to O:\. Once
done, our system should boot perfectly from its partition, copy the INI files to
O:\ and create a new Desktop in the RAM disk we have prepared for it. Mine does
it. Now, to "freeze" a snapshot of this system once it is configured as
you like, all you have to do is a ZIP file form O:\ (it just contains the INI files
and the Desktop: 100 Kb at most), overwrite the previous ZIP, et voilà. Next
step.
So much work... what's up now? Fortunately, common sense helps us quickly: if
everything works when this boots from HD and everything on the CD is read ok, what
is going on? Of course: read-only media. Now the task is quite simple: isolate the
files that can't be on the CD. I developed a program (for working, not software)
that consisted in copying all the files from the CD to the RAM disk and work from
there. Each time a one more file was copied to isolate the cause(s) of this new
disaster. After *hundreds* of restarts, CD-burnings, etc (it was very funny, I'd
recommend it as anti-stress therapy) I could finally isolate the three files that
have to be copied to the RAM disk so everything works. As a detail, I'll say they
can't be on the CD AND the RAM disk, or if they are, LIBPATH must point first
to the RAM disk. Whatever you like. So, with 2 MB less free memory (I'd love to
know why these files can't be in a read-only media; someone at IBM has something
to say?), the system is as described here (I hope it is detailed enough):
CONFIG.SYS System files list.
Where, as can be seen, there's a *long* series of add-ons made by me. In short,
they are:
Things I've added myself to the system generated by Bootos2:
- Zip / UnZip and RAMFS:
CDFS\OS2\ZIP.EXE- BldLevel and RXQueue:
CDFS\OS2\UNZIP.EXE
CDFS\OS2\RAMFS\*
CDFS\OS2\BLDLEVEL.EXE
CDFS\OS2\RXQUEUE.EXE
- Gradd 0.80 - I didn't write down a list for these ;-). Anyway I planned to changed this and use SDD 7.01SE. After the preliminary test of the version 2.0 of this CD system I found SDD failed with around 95% of the systems tested (cfg'ed as GENGRADD), systems where the GENGRADD 0.80 worked fine, so I'm afraid unless the SciTech people do something we're stuck with GRADD 0.80
- XFolder:
CDFS\OS2\XFOLDER\*
- INF viewer:
CDFS\OS2\VIEW.EXE- WPS Background bitmaps:
CDFS\OS2\VIEWDOC.EXE
CDFS\OS2\BITMAP\*
- Additional support for DOS sessions:
BOOT\AUTOEXEC.BAT- Support to [de]register Plug&Play classes and so on:
CDFS\OS2\MDOS\APPEND.EXE
CDFS\OS2\DLL\PNP.DLL
CDFS\OS2\DLL\EZPLAY2.DLL
- This is to allow XFolder to reboot the computer:
BOOT\CONFIG.SYS\'DEVICE=N:\OS2\BOOT\DOS.SYS'
CDFS\OS2\BOOT\DOS.SYS
- More things to get a decent help:
CDFS\OS2\HELP.CMD
CDFS\OS2\HELPMGR.EXE
- To make OS/2 drives bootable:
CDFS\OS2\SYSINSTX.COM
- Partition Magic 3.0, now it's dead:
CDFS\OS2\PQMAGIC\*
- Icon editor:
CDFS\OS2\ICONEDIT.EXE
- SysBar/2 0.17:
CDFS\OS2\SYSBAR\*
- Advanced Power Management:
BOOT\CONFIG.SYS\'DEVICE=N:\OS2\BOOT\APM.SYS'
BOOT\CONFIG.SYS\'DEVICE=N:\OS2\MDOS\VAPM.SYS'
CDFS\OS2\BOOT\APM.SYS
CDFS\OS2\MDOS\VAPM.SYS
- To allow type x|more:
CDFS\OS2\MORE.COM
- Initial support for FAT32.IFS:
BOOT\OS2\BOOT\PARTFILT.FLT
BOOT\CONFIG.SYS\'BASEDEV=PARTFILT.FLT /W /P 0B,0C,1B,1C'
BOOT\CONFIG.SYS\'IFS=N:\OS2\BOOT\FAT32.IFS /EAS /CACHE:2048'
BOOT\CONFIG.SYS\'CALL=N:\OS2\BOOT\CACHEF32.EXE'
CDFS\OS2\CACHEF32.EXE
CDFS\OS2\DISKINFO.EXE
CDFS\OS2\F32STAT.EXE
CDFS\OS2\MONITOR.EXE
CDFS\OS2\BOOT\FAT32.IFS
CDFS\OS2\DLL\UFAT32.DLL
- UniCode support for FAT32.IFS:
BOOT\CONFIG.SYS\'SET ULSPATH=N:\LANGUAGE'
CDFS\LANGUAGE\CODEPAGE\*
CDFS\OS2\DLL\UCONV.DLL
- 3 button mice support:
BOOT\CONFIG.SYS\'DEVICE=N:\OS2\BOOT\PCLOGIC.SYS'
BOOT\CONFIG.SYS\'DEVICE=N:\OS2\BOOT\MOUSE.SYS TYPE=PCLOGIC$'
CDFS\OS2\BOOT\PCLOGIC.SYS
Before going on, it is possible that such a complex system begins to face compatibility
problems... the best thing to do would be to create the files AltF1.CMD, AltF1*.SCR
in the boot image, copying those on the hard disk and a CONFIG.X that could be a
slightly modified version of the one we used to get a command prompt (but this time
it would load files from N: instead of being self-contained). So, we'd have a "safe
boot" just in case things too much complicated with the macro-system. Now,
let's go on with the decoration.
By now we have a pretty complicated thing, and maybe we don't need everything
every time we boot. Wouldn't it be wonderful if we could choose what to load? Of
course it would. It can be done. Veit Kaneggieser has developed a little program
that added to the OS2LDR (BTW, there are no compatibility issues related to Daniela
Engert's patch for this file) will allow us to create a complete menu with as many
choices as we want, or almost.
A photograph (my old Spanish menu):
It's not the goal of this article to explain how this program works, so the changes
needed in config.sys and the script to assign variables and so on are here.
Obviously, the red options WERE pending things. More on this later.
After all this, I imagine that there will be lots of ideas on what to add to
the system and how to do that. We should begin with the items in red. So I want
all the suggestions that all you great thinkers can come up with.
By now, before going on to the to-do list, projects and go on, we're going to
perform a last acrobatic trick that will allow anyone to use this incredible and
wonderful system we've just created by not sleeping for a few months. Just in case
someone can't boot from CD (I have solved this in some machines by telling the floppy
driver to load anyway), or OS2CDROM.DMD won't load on a certain system, or whatever,
we're going to create an OS/2 boot floppy. Nothing new? It is new. Because this
is A SINGLE 1.44 FLOPPY that will allow us to boot whatever we have loaded on the
CD, and thus being infinitely superior to any 'Utility disks' set.
The method to use is rather simple: from the load of OS2CDROM.DMD and CDFS.IFS
on, there's free access to the CD-ROM drive. So, it's useless to have lots of files
in the boot image if we can get them from the CD file-system. This allows to free
space in the boot system, get below the 1.44 MB barrier and put everything in a
1.44 MB floppy that we can use at any friend's home, in any machine capable of running
OS/2. And the best part: it's the complete system, boot menu included. What changes
do we need? Floppy files list. Floppy
CONFIG.SYS.
Now it's time to convert some people ;-)
There's a limit to the sound cards we can support, because there's nothing like
the GENGRADD for video cards, but there is much more freedom for network cards.
By now I can only ping any host from a CD booted in a few systems but (and I
need some help on this)perhaps soon we'll be able to boot a CD in any networked
computer and start a small text-mode FTP client. Perhaps Netscape is too complex,
but this FTP client would already be something no one else has anywhere I know of.
I have always thought the main handicap for OS/2 nowadays is the lack of a mechanism
that allows to install the system, fixpacks and so on, all-in-one. Someone has already
done this and put it at Hobbes. And if we can study the Aurora installer -which
boots off a CD- and adapt it to install warp 4...
I'm already studying the way to do it, but I think these are VERY interesting
projects...
If IBM can do it, I can do it, and if not, it can't be done.
Just in case it was not clear, or I didn't say it: I want to receive feedback,
opinions, suggestions and comments. OK?
The author of this:
Alfredo Fernández Díaz studies
Thorical Physics and Electronical Engineering at the Granada University, and owns
an internet cafe where everything that can't fail is based on OS/2 warp. Perhaps
some day in Aurora :-)