osFree RoadMap
osFree development must be attacked in several major stages - From a Command Line Inteface to the full Workplace Shell. Our current status in the chain is bolded.
Component implementation status
Steps to 1.0
0.1
In this version CPI implementation must be mostly finished. 16-bit API support not required. CMD.EXE and tools must be recompiled (because only sourcelevel compatability at this stage).
| Version | Requirements | Status |
|---|---|---|
| 0.0.1 | L4 must be loaded using GRUB and Hello, world application must be executed (as L4 root task). Hello, world application is stub for osFree kernel. | Done |
| 0.0.2 | EXT2FS must be finished (in general) and boot sequence must be implemented. GRUB must be removed. MicroFSD is 16-bit (OS/2 compatible), IFS is 32-bit (not OS/2 compatible). MicroFSD must load FreeLDR and execute it. FreeLDR must load L4 kernel and root task (osFree kernel stub). LILO must not be required for EXT2FS. | Done |
| Note: MiniFSD is absent because not required for microkernel architecture. | ||
| 0.0.3 | osFree kernel must parse CONFIG.SYS using file provider server (not real device driver loading) and show config tree. | Done |
| 0.0.4 | LX loader and module linker (using file provider). osFree kernel must allow load and execute PROTSHELL application. | Done |
| 0.0.5 | Filesystem API implementation. LX loader must allow loading of MINICMD.EXE task via L4VFS and execute it. Minimal set of API must be implemented. All pointers operations must be replaced by handles (implement handle manager). OS/2 Server must be more structured. Support of OS/2 memory map. More... | In Progress |
| 0.0.6 | VIO Server implementation. VIO API implementation (32-bit version, via VIO Server). Console support instead of output to log server. Console output via nitpicker (write server like proxygon). | Not Done |
| 0.0.7 | KBD API implementation (32-bit version) | Not Done |
| 0.0.8 | Concurrent execution of many applications. Multithreaded applications. | Not Done |
| 0.0.9 | OpenWatcom and build tools must be recompiled as 32-bit version (no 16-bit API must be used). (LX format) | Not Done |
| 0.0.10 | CMD.EXE must be compiled and all required CPI for it must be implemented. (LX format, 32-bit API only) | Not Done |
| 0.0.11 | Self-compiled version of osFree. (LX format, no 16-bit API) | Not Done |
| 0.0.12 | Open Object REXX must be ported. (LX format, no 16-bit API) | Not Done |
0.2
16-bit API support must be implemented.
| Version | Requirements | Status |
|---|---|---|
| 0.1.1 | 16↔32 thinking must be implemented | Not Done |
| 0.1.2 | 16→32 calls wrappers | Not Done |
| 0.1.3 | ELF format support | Not Done |
| 0.1.4 | NE format support | Not Done |
0.3
SOM tools and environment must be implemented. (Reused of somFree, not included in osFree source tree yet)
| Version | Requirements | Status |
|---|---|---|
| 0.2.1 | SOM Compiler Watcom Linker Emitter | Done |
| 0.2.2 | SOM Compiler IDL Preprocessor | Done |
| 0.2.3 | SOM Compiler H Emitter must be implemented | Done (builtin) |
| 0.2.4 | SOM Compiler XH Emitter must be implemented | Done (builtin) |
| 0.2.5 | SOM Emitter Framework classes must be implemented | In progress |
| 0.2.6 | SOM Compiler IDL must be implemented | Done (No Emitter Framework) |
| 0.2.7 | SOM CPI Intefaces | Not Done |
| SOM Run-time Kernel | Not done | |
| SOM Event Management Framework | not done | |
| SOMObjects Interface Repository Framework | ||
| SOMObjects Utility Classes | not done | |
| Distributed SOM Frameword | not done | |
| SOM Compiler OIDL Preprocessor | Done | |
| SOM Compiler OIDL must be implemented | None | |
| SOM Compiler library must be implemented | None | |
| VisualAge Runtime subset for SOM (Win32 Host only) | None |
0.4
GPI must be implemented (NO SOM Here)
0.5
PM must be implemented (SOM Based PM???)
0.6
WPS must be implemented
0.7
Network must be implemented
Unsorted yet
- osFree toolkit Clone of OS/2 Toolkit
- Command line tools Clone of command line OS/2 tools
- DOS Command line tools Clone of DOS and dual mode tools
- DOSKRNL clone
- Win16 applications clone of Win16 GUI applications
- Win16 DLLs clone of high level Win16 DLLs
- Win16 drivers clone of base device drivers (COMM, KEYBOARD, SYSTEM, MOUSE)
- Win16 USER.DLL clone of Win16 USER.DLL
- Win16 GDI.DLL clone of Win16 GDI.DLL
- Win16 kernel clone of KRNL386.EXE
Discussion
My name is Rick C. Hodgin and I'm interested in developing an OS/2-like kernel and system. I'm looking for information regarding osFree. Specifically, how the information came about for writing freeldr, and in implementing other system components. Is there an API available which describes their interface? Was it reverse engineered? Or … something else?
Please contact me and let me know. Thank you.
Best regards, Rick C. Hodgin
Is it possible to turn the APIs you have into a WINE type service for Windows, Linux, MacOS, etc? IBM had a Ferengi type OS/2 that loaded over the Windows 3.1 system and ran OS/2 apps.
Windows NT 3.1 had both a POSIX and MS-OS/2 1.X environments to run code from other operating systems.
The EXT2 file system sounds good, make sure you support FAT12/FAT16 file systems for floppies and FAT32 and NTFS for USB drives.
2Rick C. Hodgin: OS/2 API is well documented in OS/2 toolkit. Otherwise, yes, use reverse-engineering. FreeLDR is based on GRUB source code. So, I got required info from GRUB sources + IFS.INF doc from IBM for info, how to load OS/2 (including bootos2.mdl).
2Orion Blastar: We're currently not targeted to something like WINE. We primarily implement OS/2 API on the base of microkernels. Also, support of OS/2 API on top of other kernels like Linux or FreeBSD is possible, though currently we extensively use L4 family microkernels features for implementing the OS/2 API. Note that recently we got info about 2ine project (https://www.patreon.com/posts/project-2ine-16513790) which aims at implementing WINE analogue for OS/2 API on top of Linux kernel. In the future some collaboration is possible, like ReactOS collaborates with WINE project.
Why are you not going the 64-bit route? You are putting all this energy into this, I would think that for longevity purposes, access for larger amounts of RAM, that you would go the 64 bit route and convert all 16-bit and 32-bit calls to 64-bit calls.It won't be much longer before nobody makes 32-it computers anymore.Then what?
Just curious.
PS: I was a rabid OS/2 user trying to switch the bank that I worked for from Windows to OS/2 one computer at a time. It was working up through 1997 when I left to join a different organization. I left behind computers that could run the exact same programs on OS/2 that ran up to 30% faster than Windows could on the same hardware with far less app crashes (even though they were 16-bit Windows programs) and far less OS reboots.
My dream would be a 64-bit version of OS/2 that could run OpenOffice (and Describe - I still have all my boxes with OS/2 disks (floppies and CDs) including my copies of Describe and other OS/2 applications like r:Base. A version of OS/2 that could automatically convert the commands from DOS/Win16/Win32 and “OS/2 32” APIs to 64-bit OS/2 and I would pay $150 for that. But it would have to run on computers with 64-bit processors so that I would know that I could count on it running on hardware for the rest of my life (approximately 20 years if I live to be 80). And yes, I would expect to pay a year subscription fee to keep current with FreeOS for as long as I could use computers.
2Bill Olson: Actually, 64-bit support is planned. It is not on the roadmap because we first need to provide a binary compatibility with existing OS/2 appplications, which are 32-bit and 16-bit. 64-bit apps are planned in the future, but they require a 64-bit kernel. Current kernel we use is L4/Fiasco. We still use it, though it outdated and now its successor is widely used, Fiasco.OC, which has better 64-bit support. We are currently in progress porting osFree to L4Re and Genode OS frameworks (which can be used on top of Fiasco.OC). This port is not ready yet, so we stick to a 32-bit system for now. Thunking of 32-bit and 16-bit applications to 64 bits is possible. It was shown by QSINIT bootloader/miniOS version for UEFI, which uses a 64-bit UEFI to run 32-bit and 16-bit code. So, we can do the same way.
osFree is an OpenSource project. So, it is a free software. We don't plan to charge a subscription for using it. There is ArcaNoae which sells an updated version of IBM's OS/2 for newer hardware, for a subscription. This is a commercial software. It has closed components. E.g., they provide drivers and develop an USB3 support, but they don't give the code to community. And no hope for a 64-bit version to be released, as they don't have a kernel source. And old kernel is hard to rewrite to 64-bits because it's 40% written in assembler, so it's not portable. We have a hope that someday we'll create a 64-bit version, and it's Open Source, so, it can be developed by a community and won't die. But the problem is that we have a little manpower to develop osFree, so with current resources, it will be ready in far future. So, we need help.