Phoenix OS/4

From OS2World.Com Wiki
Revision as of 15:15, 23 February 2014 by Dbanet (talk | contribs)
Jump to navigation Jump to search

Phoenix OS/4 is a project intended to recreate the original kernel for the IBM Operating System/2 using such techniques, as reverse-engineering and disassembling. The main goal of the project is to make the system able to work on the PCs, that it is unable to work on with the original kernel.

Installation instructions

From now, we assume that you downloaded the latest OS/4 kernel distribution zip file, and it is named like this:
os2krnlSVNxxxx_unoff.zip, where xxxx is the SVN revision of the downloaded release. To unify the following installation instruction, it is assumed, that the downloaded distribution file's name is os4krnl_current.zip. Please, rename the downloaded file to os4krnl_current.zip using your favorite filemanager or the CMD.EXE's ren command like this: ren os2krnlSVNxxxx_unoff.zip os4krnl_current.zip. Also, you will need the unzip utility, which you can find on hobbes.

Okay, so everything is set up properly -- let's begin!

The OS/4 distribution package includes a powerful kernel loader, which features loading OS/4 and OS/2 kernels, kernel selection menu, custom CONFIG.SYS files for each kernel, CONFIG.SYS editor which may be invoked right before the kernel loads (available on OS/4 kernels only; although the modified version of the config is not put back on the disk, the feature is fairly useful in crash recovering), chainloading another kernel bootloaders and preloading files in the memory (better boot time).

So, the first thing to do, is to install the OS/4 kernel bootloader, because the original one is unable to load the OS/4 kernel. If you use a recent version of ACPI, original kernel, or both (you have eCS), then it is highly recommended to keep the original bootloader:

  • unset the hidden attribute of the original kernel bootloader: attrib -H \OS2LDR
  • rename OS2LDR to OS2LDR.IBM: ren \OS2LDR OS2LDR.IBM
  • extract OS2LDR from the OS/4 package to the root of the boot drive: unzip os4krnl_current.zip OS2LDR -d \

Then extract the Phoenix OS/4 kernel to the root of the boot drive (the file is named OS4KRNL for the debug version and OS4KRNLR for the release version):

  • we will use the release version, so do unzip os4krnl_current.zip OS4KRNLR -d \.

OS/4 ships also with an updated DOSCALL1.DLL library, which works fine with both kernels (highly recommended):

  • download the lxlite package from hobbes
  • extract the unLock.exe utility to your PATH, for example, to the \OS2 directory: unzip -j lxlt133.zip lxLite\unLock.exe -d \OS2
  • now unlock your current DOSCALL1.DLL file: unlock \OS2\DLL\DOSCALL1.DLL
  • rename it for a backup: ren \OS2\DLL\DOSCALL1.DLL DOSCALL1.IBM
  • and then extract the Phoenix version: unzip os4krnl_current DOSCALL1.DLL -d \OS2\DLL

Then you need to configure the OS/4 kernel bootloader to be able to load the original, and the Phoenix kernel. The configuration file's name is OS2LDR.INI. An example configuration file is present in the distribution package, and contains a comment for each line.
Create an empty OS2LDR.INI file in the root of the bootdrive and then put this in it using a text editor (or whatever you want):

[config]
default=1
timeout=15

[kernel]
OS2LDR.IBM = IBM orig. kernel ,RESTART
OS4KRNLR   = Phoenix kernel   ,PRELOAD

The default statement in the config section sets the default selection in the kernel selection menu, and the timeout statement sets the time in seconds before the default kernel will be loaded.
In the kernel section, the statements must comply with the following syntax:

<kernel or loader filename> = <kernel selection menu option text>[,option[=value][,option[=value][,option[=value][...]]]]

The possible options are:

RESTART Indicates, that the file to be loaded is an another kernel bootloader, rather than a kernel file.
LOGSIZE Defines the size of the log buffer (which you can get reading special device files) in KiB (0 < value < All memory - 16MiB).
PRELOAD Use the files preload function (a must for OS4APIC to work properly, also speeds up the loading process).
LOADSYM Load the symbol file for OS2BOOT.
CFGEXT Specifies an extension for the CONFIG.ext file to be loaded instead of the CONFIG.SYS file, where ext

is the extension specified by the CFGEXT statement (must be three characters or less).

ALTF1 Emulates a user pressing Alt-F1 in the loader menu.
ALTF2 Emulates a user pressing Alt-F2 in the loader menu.
ALTF3 Emulates a user pressing Alt-F3 in the loader menu.
ALTF4 Emulates a user pressing Alt-F4 in the loader menu.

Although the original kernel may be loaded by the OS/4 kernel bootloader directly, the most stable configuration is to use original bootloader to load the original kernel.

Notice, that the original bootloader (OS2LDR.IBM) is able to load the only kernel file, named OS2KRNL, and you have to keep the original kernel with that name to have the ability to load it with the original bootloader.

Also notice, that although you have the ability to chainload kernel bootloaders with custom name using the Phoenix bootloader, the first loaded kernel bootloader is always named OS2LDR.

There are also some configuration statements you can use in the config section in the Phoenix bootloader configuration file, but those are usually only useful for debugging and troubleshooting purposes. See the example OS2LDR.INI file in the OS/4 kernel distribution package.


This is a basic installation process, but remember, that there is also a new CLOCK03B.SYS, which supersedes original TIMER0.SYS and CLOCK01.SYS drivers. It is recommend to install this driver:

  • unzip os4krnl_current.zip CLOCK03B.SYS -d \OS2\BOOT

You don't need to modify CONFIG.SYS

Attention! Since SVN revision 4166, it is mandatory to install the new SCREEN03.SYS, otherwise kernel won't boot:

  • unzip os4krnl_current.zip SCREEN03.SYS -d \OS2\BOOT

You don't need to modify CONFIG.SYS, too.


Okay, everything is set up. Now reboot your system!
You should notice the kernel selection menu with two options, where you can select to load either the original IBM kernel, or the Phoenix one. Although you may fail to boot up with the Phoenix kernel due to a bug in it, there is no doubt you will be able to fall back to the original kernel and boot your system with it (if you were able to do this before :)).

Frequently asked questions

Q: I'm getting a SYS1195: The statement "VIRTUALADDRESSLIMIT" on line *** of the CONFIG.SYS file is not recognized. Line *** is ignored.

error message while booting. What's wrong?

A: Somewhere in SVN3xxx the VIRTUALADDRESSLIMIT tuning feature was broken. Now the VAL is fixed and set to 2048.

There's nothing bad in the error message; you can REM or remove the entire VAL statement in your CONFIG.SYS file -- it will always remain fixed to 2 GiBs.

Unfortunately, there is no information whether Phoenix will fix this issue and make the VAL changeable again, or not.


Q: Can I use ACPI.PSD with the OS/4 kernel, and what version?
A: Yes, you can. The best option is to use the 3.18 version, as that's the latest officially supported version, and it has recommended itself as the most stable ACPI.PSD.


Q: I'm getting a TIMER0.SYS... initialization failed error message while booting. What's wrong?
A: The 16-bit TIMER0.SYS driver fail is okay because its function is now fully substituted by the CLOCK03B.SYS system driver written by Phoenix.


Q: What is the purpose of the CLOCK03B.SYS driver?
A: The CLOCK03B.SYS was rewritten in 32-bit and now contains two drivers: CLOCK$ and TIMER0$ (having more than one driver per module is allowed in OS/2). That was made for better performance and code cleanup.


Q: What is the purpose of the SCREEN03.SYS driver?
A: The SCREEN03.SYS was written to enable Panorama VESA BIOS Extension Video Driver to set the proper Write-Combine flags for the LFB (the linear frame buffer) without ACPI.PSD.

Now the Phoenix team provides the full alternative to the OS2KRNL + ACPI.PSD + PANOGRADD stack of technologies:

OS4KRNL + OS4APIC.PSD + ACPI4.SYS + SCREEN03.SYS + PANOGRADD


Q: How can I prevent the debug version of the kernel from jumping into KDB when some program traps?
A: Put this in KDB.INI file in the root of your boot drive:
.b 115200t
g
g
g
g
g
ln
k


Q: How can I get the kernel log if my test PC does not have a COM port? Can I use a USBCOM device?
A: No, you cannot get a kernel log using a USBCOM device. For more information on getting the kernel log, please refer to the Troubleshooting/Getting the log section.


Troubleshooting

Known problems and not-a-problems

I think there is a bug in the kernel...

Getting the log

Submitting the bugreport

Participating in testing

Getting the binary distributions

Currently, the download section on the RU/2's Core/2 is outdated (will be fixed ASAP).

The latest kernel distribution should reside on the gus.biysk.ru server in the /os4 directory.
You should find there a ZIP file in the root, starting with os2krnlSVN.

Also the first post on the OS2World thread about OS/4 should contain the direct link to the release.

Resources on the WWW

[1] is an official HTTP server, where you can get the latest OS/4 kernel releases and some useful utilities.
[2] is a section on the Russian Underground/2, fully devoted to the Phoenix project (Russian only).
[3] is an IRC channel where you can get support.
[4] is a thread on the OS2World forum about OS/4.

Contacting developers

The most easy way to contact Phoenix is to join the #os2russian IRC channel on the original EFNet network.

There is no collaborative e-mail mailbox, but you may consider writing to the SU.OS2 Fidonet area... Hrm. Well, the IRC channel is the best option.

Also there is a technical forum at the Russian Underground/2, where you can try writing to, too.

Most of the dialogs in the IRC channel, RU/2 forum, or the echo conference are performed in Russian, but if you jump there in English, you will get a conversation.


Also there is a thread in the OS2World forum (which is in English), where you can get support, too.