Going through my virtual attic: ILAS

If you haven't read my posting on Ulsop you should probably read it first. Ilas is my second attempt to make a graphical OS. The name ILAS means something like "Integrated, Little And Simple (operating system)". Might sound better, but certainly way less clever than Ulsop. I came up with the name because a character's name in a book I read sounded similar. Now, if only I would remember which book it was .... Here we also have a date code. One of the applications was written in 2003, so I must have been 15 to 16 years old when I started developing this system.

Like Ulsop, ILAS is still based on DOS, but it does more things "on its own". For example, upon startup it tries to grab all the memory from DOS and then manages it itself, correctly assigning it to applications (processes) that use it. It has its own filesystem layer - which just forwards everything to DOS, but it would be possible to implement "real" filesystem and block device drivers on top of it. It uses only two interrupts, passing arguments in registers and not some structure in memory:

0xF0    Main API entrypoint
0xF1    Function, programs can call to yield CPU time, aka. yield()

Also the multitasking has much improved, instead of just polling each process, it stores a task state and actually makes CPU idle calls when no process needs CPU time. But it's still cooperative multitasking, not pre-emptive. There is true interprocess communication based on messages similar to Windows' SendMessage and GetMessage, which is also used for the windowing toolkit. Unlike Windows, messages are sent to a process, not to a window. The toolkit also has way more features such as listboxes, dropdown lists and more. It also doesn't split the main kernel and multitasker into two DOS executables, so this one runs nicely in DosBox if you want to try it out :) I got around the limits of the C compiler by encoding the machine code as a binary array.

But even if you run it in a VM the mousepointer is now drawn properly because it's managed by the graphical subsystem instead of the (DOS) driver itself. This means it should also run correctly in SVGA modes. 

Unfortunately the 640x480x4 driver which was also used in Ulsop was way to slow during development. I just couldn't get how the weird memory layout with the color planes in the 16 color modes work ....

So if you try it out, you will be greeted with a blocky, but much faster 320x200 screen which makes it look very retro ;)

 

When you start KERNEL.EXE it will first initialize some interrupt vectors and grab all the memory from DOS. Then it mounts the current DOS directory as /init, devfs as /dev and the DOS temp-directory as /tmp.

The kernel gets PID 0 in the task table, then /init/osinit gets PID 1. The kernel then enters an infinite loop processing messages via getmessage() and performing some background maintainance tasks. The first call to getmessage() however will switch the CPU over to /init/osinit which performs the rest of the initialization process in "user mode":

• It opens /init/drivers.cfg and loads all the drivers from the textfile using the "insmod" syscall
• It loads two hardcoded default fonts: /init/8x8.fnt and /init/8x16.fnt. They can be in the ULSOP format or in a "vector" format consisting solely of horizontal, vertical and diagonal 45 degree lines. The 8x8 "vector" font yield in the funny text rendering seen below
• It opens /init/startup.cfg and loads all programs specified in this file (for now just /init/progman)
• Finally it looks for a keyboard, mouse and initializes the /dev/ulsopwm "window manager" provided by the kernel and terminates itself.

Let's just go through some screenshots and explain the rest of the architecture while doing that.

If you haven't raised the CPU cycles in DosBox you'll briefly notice the black program manager window as it's loading everything ...

 

This is the Program Manager, Ilas' "Desktop". Now complete with clickable Icons. Also programs running in the taskbar are now clickable, no more weird F12 task switching like in Ulsop. All things are still fullscreen-only but it would have been possible to implement a windowing system.

 

 

Here's the dice roller from Ulsop. It's actually the same binary! At some point I thought, wouldn't it be great if Ulsop applications would also run on this new system as well? (not that there were any useful ones). The architecture is similar enough so after implementing the Ulsop main API was pretty straight forward. Running Ulsop applications has some drawbacks however. Because of Ulsops weird task-switching Ulsop programs will simply burn all the available CPU time, even when not doing anything. Once you terminate the last running Ulsop application, idle calls are made again. This means ILAS supports all the interrupts used by Ulsop as well, although the driver-chain is not used and just points to an IRET.

It was a great learning exercise for me to develop this compatibility layer.

 

Sorry, Snake doesn't work. Must be a problem with the compatibility layer. I can't remember whether I ever got it running or if something just broke.

 

Ilas has a task manager to kill processes should they ever become unresponsive - unless they take down the whole system, which is very likely in real-mode software. PIDs are not displayed but you can clearly see the kernel as the first slot (PID 0) and is performing some housekeeping tasks. Unlike UNIX, the init process doesn't stick around.

 

This is the only application I ever used on Ilas. It was basically a randomizer to generate Age Of Empires teams for a LAN party. Not really necessary to write an entire system to do this, but I had Ilas (mostly) up and running and wanted to show it off.

For this I had to implement listboxes and dropdown lists.

 

 

After clicking "GO", we are "randomizing", to make sure the teams turn out fair and well mixed. Everyone just punches in some numbers which mix stuff through. The C librarys random number generator is not used. Oh, and don't worry about the Comic Sans MS, that's just a bitmap.

 

 

 

And the result. I don't remember if we really used this though. If you see your name on the list, let me know ;)

 

 

All those bitmaps sure use up a lot of conventional memory! Good thing Ilas can swap out graphics to disk as well. XMS support was planned but never finished. The functions are there, but never called.

And - Yay, no crashes while making the screenshots! So why did I abandon this? No idea, actually, I guess I just got tired of DOS-based stuff.

This is one of my "ancient" projects I'm actually thinking about reviving. You know, when I have some spare time .... which is probably gonna mean: never.

 

If you want to give it a spin, grab the ZIP file: ILAS.ZIP, unpack it and run it in DosBOX. Source code is included along with a lot off mess left behind during development. No warranty given!

 

My next OS attempt left the shackles of DOS behind and moved into the 32 Bit world. I will write about this in my next blog post.