WarpBSD

2007-02-06T10:06:00.000-08:00

I now have DragonFlyBSD installed on a spare hard drive and I have verified that the VKERNEL feature works as documented. I will now examine the vmspace_xxx calls to see how I can implement a simple single-process LX binary executor which will run as userland code. This will allow me to quicky test my LX module loader code and to experiment on ways to simulate the 16bit APIs without requiring any 16bit code.
OS/2 2.0+ pretty much requires all the LDTs to be populated as 64KB aliases of the first 512MB of the memory map (8192 * 64KB) hence the 512MB limit. Some DLLs with the appropiate bit set in the LX header may be loaded above the 512MB mark but any memory allocated above there is inaccessible to the 16bit APIs. There is a DOSCALL available to do 16bit->32bit address translation and vice versa (DOSFLATTOSEL DOS32FLATTOSEL DOSSELTOFLAT DOS32SELTOFLAT) - and if people did actually use them then there wouldn't be a problem. Unfortunately most people just used the quick-and-dirty macros which IBM kindly provided like the SELTOFLAT macro in netcons,h
What I want to achieve with the userspace LX loader is to get demand page loading working. Unlike most binary loaders which map all the code into memory first, I want to only load and fixup code pages which are accessed. I will have to do basic checks at start to ensure that all external fixups can be satisfied and that there are no 16 bit segments but that is all. I will be relying on DragonFlyBSD's ability to trap page faults. Initially there will not be support for multi-threaded apps but then I may extend it with some form of thread simulation using multiple vmspaces for the threads: OS/2 needs this as each thread requires a different page mapped to the same logical address for it's per-thread data area - for reporting errors and for OS/2's thread-local storage. OS/2 only permits 64 words of thread-local storage which developers and compiler writers may use to point to an address for more space.
Phew - this was a long entry....

2007-01-31T21:03:00.000-08:00

It appears that this blog has caught the attention of the DragonFlyBSD digest... Which is all fine and good except that this project is just a bunch of non-working code so far. Sorry guys, it's vapor right now!
Right now, I am thinking of how to simulate OS/2's legacy 16bit APIs without actually needing any 16bit code - although I don't intend to support any 16bit code segments, so all IOPL stuff won't work but things which used ioctls like Holger Veit's fastio$ may be supported. (isn't it silly that IBM never followed through and introduced the 32bit clean console APIs - MOU/KBD/VIO - from their aborted OS/2 PowerPC project but they did port GRADD).
Anyways, back on topic - for anyone reading this - there is no working code yet. Once I have something to show, I'll provide a link to a website where the code will be published. I plan to use a BSD style license.

2007-01-30T14:55:00.000-08:00

I have been thinking... Now that DragonFlyBSD 1.8 was released today, if I use the MAP_VPAGETABLE facility, I have no immediate need for any in-kernel code. I could simply rely on that for an initial implementation.
Or, I can just leverage DragonFly's VKERNEL to accelerate development.

2007-01-07T21:47:00.000-08:00

Well, that has pretty much made up my mind: Matthew Dillon has nearly completed his VKERNEL for DragonflyBSD. Having that available would also be good to accelerate the development of WarpBSD.

2007-01-07T10:42:00.000-08:00

No new work done but the DragonflyBSD project has been doing some pretty interesting stuff. However, I still think I should base the work on FreeBSD 4 and develop a more OS/2-alike IFS system instead of the VFS which BSD has.

2006-12-31T15:10:00.000-08:00

I am going to make the WarpBSD project happen this new year. I want it. The goals are not unacheivable and the goalposts aren't going anywhere.

2006-12-11T14:41:00.000-08:00

It has been a while since I had any time to work on this project but I do hope to get some of it started after the new year.
To start, I plan to base the code on the latest stable version of FreeBSD 4 and the system compiler will be OpenWatcom, I intend to start by building a new in-kernel LX module loader. After that, then I may migrate the build to use owcc instead of gcc,

Start of my log

2006-07-26T02:44:00.000-07:00

Just thought I should log my work. I have been investigating in my free time various technologies as used in OS/2. There are many things which it does which other operating systems do not appear to do and in my opinion, it is pretty sophisticated.

Areas which I have been examining include:
* LX binary loading
* SOM infrastructure
* Presentation Manager -> GRADD

As part of my "WarpBSD" project, I would like to create opensource versions of various key OS/2 technologies. They are unlikely to be bit-for-bit binary compatible but I would hope to be largely source compatible. Of course, ABI compatibility would be nice to run legacy applications ... but not strictly neccessary to begin with.