hi all,
I am one of osFree developers.
Actually, we uploaded an unofficial demo, and showed it to several people, but did not announced it. Martin Iturbide wrote us a readme, but it need some more documentetion and bugfixing before we announce it. But if the info is leaked, we must do something sooner ;-)
Actually, what is on Sigurd's screenshot is a l4 'run' program. It is intended to show some system information, start/kill tasks, reboot, etc. You can see some help if you press 'h' key. It is not what we wrote, but it is a helper program from l4 environment.
The main screen is that of a 'l4con' server which provides several virtual screens. It waits untill a client connects to it, and shows its screen in a separate tab. On the lower screen line, you can see 9 digits from the right, three of which are marked with green. -- That are those tabs for virtual screens. You can switch virtual consoles by pressing Shift-left/Shift-right or Shift-F1/Shift-F2/... Each virtual desktop can be browsed back/forth by Shift-PgUp/Shift-PgDn or Shift-UpArrow/Shift-DownArrow (to scroll by line). The 'l4con' server shows on the screen the window of that application which is first connected to it. When a new app is connected to it, it shows it's screen
Actually, there are three virtual screens here. The 3rd one is 'run' program, it is started last, so it's window is showed on a screen. though, the main for us is 'minicmd' and OS/2 personality window. -- It is on the second tab. And the 1st tab is the 'logcon' server window. It shows the system log. The logcon server is a version of log server which shows system log on a screen -- the debug of all l4 servers. The 'run' program shows some system info, can start/kill tasks and reboot the system (you can see the help screen if you press 'h' key).
But the main for us is osFree OS/2 personality, it is showed on the 2nd tab. Actually, you can see here the minicmd screen and nothing more. c:\minicmd.exe is a small minishell program -- the 10 kilobyte LX executable started as protshell=. It is a minimal shell-like application which uses a minimal subset of OS/2 API. (It uses about a dozen API's)
In this demo, minicmd can start a second (third, ..., N-th) copy of itself, if you enter 'c:\minicmd.exe' at its prompt. The 2nd copy is started, its Process ID is showed. You can exit from Nth copy to n-1-th by entering 'exit' command.
For external commands, in this setup there is also 'mini33.exe' -- the most minimal LX executable. It does not contain the C startup code and uses only one DosPutMessage API from msg.dll. All -i't does, writes a 'I'm really small!' message to the screen.
You can see that only after starting an external program a command prompt is shown, so here a synchronous DosExecPgm API is implemented.
Also, so far, we implemented a minimal API for starting simple C written programs (a minimal set of API's needed by libc functions of Watcom). (it is in a newer versions, not yet uploaded to the web site). We have a small test program working, which uses 'printf' C function to output its command line args and environment variables. So, args and environment passing is implemented too, though some bugs still present. Also, there is a test for DosScanEnv API which shows a PATH variable.
Now we have a 'os2srv' server -- the OS/2 Server -- the main OS/2 personality server. It parses config.sys, spawns other servers and finally, calls run=/call= programs and starts a protshell=c:\minicmd.exe program. There is two more servers, execsrv and os2fs. The 1st one mainatins all executable modules in the system (EXE/DLL ones). For that, it loads lx.ixf and ne.ixf -- IXF drivers. IXF stands for Installable eXecutable Format driver -- an ELF shared library supporting LX/NE/ELF/etc format executables loading. So, each executable format support is separated to a separate module. They are analogous to IFS for file systems. So, execsrv loads all neeeded executables/libraries on demand. Libraries are loaded to a shared arena. Also, I want to move all shared-memory related API's support to execsrv, so it also will maintain all the shared memory and shared sepaphores etc.
The os2fs server is a filesystem server. It maintains all the FS-related API's. In the future, I plan to implement IFS support in os2fs server, so it will provide IFS'es with FSH_* helpers through FSHELPER virtual DLL and mount filesystems, end export these filesystems to other personalities. In l4env there already exists some FS support in l4vfs subsystem. Ihe idea is to have the central 'name_server' which implements a root of a hierarchical namespace,
in which other servers are mounted. In our setup, there are two more l4vfs servers, 'simple_file_server' which mounts to the '/file/system' mountpoint, and terminals server, 'term_con', which mounts to '/dev'. Each terminal, /dev/vc0, /dev/vc1,... corresponds to each client's stdin/stdout/stderr. So, it implements stdin/stdout/stderr for programs. the 'simple_file_server' exports GRUB or FreeLDR loaded modules as a flat filesytem, mounted to /file/system dir. Also, other file-alike entities, like pipes, registry keys can be added to the same namespace.
I plan to make os2fs server as one of a l4vfs servers, so, it will export OS/2 filesystem to other personalities. I plan to port ramfs.ifs to osFree, so it will be the 1st IFS. The IFS drivers are planned to be LX executables (DLL's), called by os2fs server, which will implement a FS router. For ramfs.ifs, no block device drivers or os2dasd/os2lvm analogues are needed (it is a 'remote' filesystem). And it uses only 5 FSH_*-helpers, so it will be the simpliest case to implement

I plan to make API's needed for unzip.exe, and instead of using 'simple_file_server', I will pack all needed files to a zip file, and unpack them to a ramdisk ;-)
Beside the servers, the important part for OS/2 executables support is 'os2app' l4env program. It is 'OS/2 application container'. It is started by l4 'loader' server as 'os2app --stdin /dev/vc0 --stdout /dev/vc0 --stderr /dev/vc0 c:\minicmd.exe'. So, the 'os2app' program is started, it is passed a terminal name which will be used as stdin/stdout/stderr, and an OS/2 app to load. It starts as a separate l4 task, in the separate address space, prepares the needed OS/2 app address space layout, loads an OS/2 application and all needed DLL's (they are loaded by execsrv server, and then are passed to 'os2app' task.). Then 'os2app' prepares OS/2 application info blocks (TIB and PIB), gets OS/2 app command line parameters and environment, etc, and then starts the OS/2 app by calling its entry point.
After all, 'os2app' contains a kal.dll virtual library, which contain the calls to L4 and OS/2 personality servers to implement OS/2 API's. OS/2 API's are in doscalls.dll. Unlike the 'classic' OS/2 but like in OS/2 Warp (PowerPC edition), it is a real disk file. DOSCALLS.DLL functions are implemented on top of KAL.DLL functions. So, the border between KAL and DOSCALLS is the border between 'L4 world' and 'OS/2 world'

So, we'll trying to make additional progress. The main problem now is that at the moment only me is making something for osFree, other team members are busy now ;( So, any help is welcomed, especially if someone will help me with programming

PS: I am trying to post this for the 2nd time, the previous time I tried, the message is dissappeared and I was log out from forum, so I needed to type thsi message again ;(
WBR,
valery