Home > Amiga, Delphi, Linux > Build your own Delphi based operative system

Build your own Delphi based operative system

October 19, 2014 Leave a comment Go to comments

Those of us that grew up in the hacker community of the 80’s and 90’s have a different mindset from kids today. It’s sort of built into us that if we put our minds to it — we can do anything. Any system can be hacked, modified, built. Why? Because we can that’s why 🙂

I still remember getting so angry at loosing in Soccer Manager that I got my drill, black & decker’ed my way through the F1 key, then soldered it shut in order to win the tournament! Yeah we Norwegians have stubbornness issues. But on the positive side — we get stuff done!

Operative systems

While games was my dream job as a teenager, another side of my aspirations were building my own programming language (sort of did that) and my own operative system. Not a system like Linux or Windows, but rather just my own desktop environment. Back then the Amiga had it’s kernel on ROM’s, so the only thing that loaded when you booted the machine were drivers and the desktop environment. So naturally everyone wanted to pimp or replace that with their own.

Xamarin rewrote Android to C#

Xamarin rewrote Android to C#

Well, the Amiga is long gone and buried (sadly) and exists now only in the virtual world of emulation. But would it be possible to create your own, pascal driven desktop environment for x86 computers?

Now if you are thinking about a fully-fledged operative system, with it’s own hardware drivers (this is really the biggest challenge, because there are so many configurations out there), kernel and software — then I would say no. Not because it’s impossible — but rather improbable that anyone would throw away the amount of time and money to do so. Having said that several operative systems have been written in freepascal, the latest endeavor being FPOS. But as you probably imagine, it takes a long time to truly build an OS from scratch.

But, creating your own environment which is 100% controlled by your code — that is more than possible. It’s already been done by several companies in the field of backup-software and embedded NAS systems.

Xamarin, the guys behind mono even took the time to re-write Android in .net a while back, called XOBOTOS. You can check that out on GitHub here: https://github.com/xamarin/XobotOS

Delphi and DOS

You probably think that Delphi is only for the desktop. Well, that’s how it was designed. But the code generator inside Delphi produces ordinary, bog standard machine code; meaning that it only does what it’s designed to do. Namely to produce machine code that the x86 processor can execute.

What we need is something which emulates the absolute bare-bone functionality of Windows. I am talking about the true low-level stuff like allocMem(), the ability to read mouse co-ordinates, keyboard input and so on.

Delphi for DOS, works like a charm

Delphi for DOS, works like a charm

Well it just so happens that such a system exists. It’s called WDOSX and was primarily adapted for Delphi 5 and 7. What it does is take your ordinary Delphi .exe file and patch it to use the WDOSX extender. This basically turns your Windows program into a DOS program. The extender emulates the windows functions (memory allocation and so on) to work with DOS rather than WinAPI — effectively fooling your application into thinking it’s running under Windows.

Limitations

The limitations are obvious: no windowing toolkit, no threading and pretty much what you would expect from a DOS program. On the positive side though – you do get a flat memory-model, so if you have 16 gigabytes of ram, you will be able to use it as normal. No “high” memory and “low” memory, or 64k segments to worry about.

You will also enjoy a very VCL like RTL, namely CLX (Kylix). DWPL patches the CLX source-code so it works under DOS. It especially patches client/server units, so when it comes to networking you will be surprised just how powerful it is.

Add full-screen access, mouse, sound and complete access to the disk and you have probably the most powerful “DOS” development platform ever created. CLX is the open-source port of VCL to Linux (read: platform independent). A variation of CLX is used by Lazarus, so it’s pretty solid stuff.

Kylix, a project years ahead of its time

Kylix, a project years ahead of its time

Applications

It wont take long before you ask “but what about applications?”. Well you are in luck, because Delphi has the best scripting engines in the world. You could use RemObjects’s script to build applications, or what about DWScript (which is much better)? I seem to remember that the latest (read: last) WDOSX extender included support for blue-threads (so there is a TThread class in there somewhere). With a bit of work you could run several DWScript based applications at once.

And the speed would be phenomenal. Because your application would in fact be the only “real” application running on the entire machine. With exception of freedos and 2-3 drivers naturally.

A NAS server written in Delphi for embedded platforms? Yes you can!

Graphics

The Delphi package to use WDOSX (DWPL) is actually very good! It maps the VESA screen buffer into a TScreen class, making it a snap to take full control of the computer’s graphics. The downside is, naturally, that you wont get access to any GPU functionality since VESA means you use the processor to draw everything. Which is much slower.

It also uses FreeType, the same font renderer used by OS X and Linux to draw text on screen. This turns your home-brew OS into a more polished looking system.

Networking

Believe it or not but that is also possible. It requires a network card with a packet driver for DOS. Those are rare today, but not as rare as you might think – because DOS is still the #1 system for offshore embedded systems and military boards. Strange as it may sound DOS is alive and kicking to this day.

Libraries

Believe it or not but WDOSX supports the loadlibrary() api. Meaning that you can load and use DLL files (as long as these libraries dont collide with the limitations). That is pretty cool. You could in effect isolate common functionality in libraries for easier maintenance — or define your .exe format as DLL’s (so any applications for your desktop would ship in the form of DLL files, since that is the way to get executable code loaded).

FreeDOS

You still need a system that does all the dirty-work, talking to hardware interrupts and taking care of device IO. Well this is where freeDOS, the open-source and free DOS clone comes in.

So your system would in effect look like this:

  • FreeDOS
  • Mouse driver
  • Graphics driver
  • Network packet driver
  • WDOSX
  • Your application

Desktop environment

Creating your own desktop is, well, not hard but time-consuming. A window is basically just a graphical region with various options for how it’s displayed, positioned and drawn. It’s more complex but once you have the basics implemented, it’s quite fun to program 🙂

Possible markets

The only viable, economic market i can think of is that of backup and disk-utilities. In fact, most of the recovery software that boots off a USB or cd-rom is based on DOS. People use freeDOS for a lot of things, but very few have used Delphi for this. It’s primarily the domain of the now discontinued C++ Builder.

But yes, you could with some effort create a fully independent desktop environment written completely in Delphi. I have also seen full kick-start (boot code) written in freepascal (believe it or not).

But for sake of sanity I would stick to creating a desktop-system designed for a specific task, like back/restore of a disk (you have raw access to sectors so it’s a perfect situation).

A possibly second market is embedded systems dealing with server’s. Dedicated NAS servers are cheap these days, but you can actually build your own. It completely depends on your motivation (fun, money or hobby).

Either way — if someone took the time to work on this for a few months, Delphi would have a pretty good setup for creating embedded applications. The embedded market is very lucrative, especially the companies that target the oil industry.

FreePascal

I actually havent tested WDOSX with freepascal, but I suspect it will work. I did a quick google and found that WDOSX is indeed mentioned under supported systems (Ubuntu man pages).

If the idea of writing your own desktop-environment for embedded systems tickle’s your fancy, then why not investigate 🙂

Advertisements
  1. October 20, 2014 at 9:10 am

    Reminds me of when I first got my hand on Turbo Vision in BP 7.0! 😀

  2. abouchez
    October 20, 2014 at 6:46 pm

    “A variation of CLX is used by Lazarus”? Not at all, AFAIK.
    “DWPL patches the CLX source-code so it works under DOS” – but only for the non GUI part, AFAIK. So no magic bullet for the UI!

    I used DWPL from Delphi, with great success, some years ago. I remember that I needed to enhance the Open Source IP layer to support UDP in pascal. AFAIR there was (is?) no free stable TCP/IP dos implementation in pascal for DWPL. You would need to use one TCP/IP stack at DOS level. But it… works, and is (more or less) stable. But I switched back to Turbo Pascal and static memory allocation, at the end, for the project… It was a nightmare to debug DWPL apps, whereas TP7 did allow to perform some remote debugging.

    There are also pure pascal OS – see http://wiki.freepascal.org/Operating_Systems_written_in_FPC – but the main issue is the hardware support. Writing drivers is very difficult, and modern hardware stuff are not obvious. AFAIR no pascal OS do support true DMA. So you would have to implement your networking in blocking/pooling mode – just damn slow.

    There is a HUGE step from a Proof Of Concept Operating System to a fluent, stable, and hardware-friendly like modern Linux. And if you compile your own Linux kernel for a particular hardware, its size can be small, and maximize the HW resources it runs on.

    • Jon Lennart Aasenden
      October 20, 2014 at 10:02 pm

      Yes, like I wrote you have to write your own UI manager. Which is fun and rewarding.

      No CLX in FPC? Hm. Well perhaps I remember wrong, I seem to remember that it was used. Perhaps it was crossCLX, which uses FPC now.

      And yes, writing a fully working OS is one tough job. Hence i focused on “desktop environment”. Like AROS for instance, which is loaded by Linux – and starts fullscreen when X starts. which is a nice solution for embedded, single application, boards

      • abouchez
        October 21, 2014 at 1:13 pm

        Use the source, Luke – oups…. Use the source, Jon!
        There is no common source code in CLX – or OpenCLX – and FPC. Even the most basic units for linux (like Libc.pas) are not the same.

        “Desktop environment” does perfectly make sense, indeed. And we may think even at HTML5 as the new “runtime environement”, available in almost all platforms – but not yet for embedded HW.
        In fact, writing for embedded devices is something sometimes diverse than desktop application writing. Even if some OS for the Internet Of Objects start to be announced, a lot of embedded devices do not even have a true OS, and even no heap… I was able to run a DOS program for years without startup, for a critical app, since it was written in TP7 without any heap, but all memory statically allocated. 🙂

  1. No trackbacks yet.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: