Open Source Depot Development

The switch went well. I can pretty much do everything I did with Windows, and then some. It is especially nice to have a POSIX environment. Don't get me wrong. Cygwin is very good, but slower than Linux and subject to the arcane Microsoft ways, especially when it comes to drive mapping and security.

Once settled in, I modified the Prima build environment to include Linux. It had all the hooks in place. I just never finished the work. Now that Linux is on the laptop, it was convenient to do. Besides, the old "server" has to go anyway so I don't want to go sit in the computer room to work on it.

If there is any demand, I'll post the changes. My next step is to add some real device drivers. Again, I'll publish the work if there is any demand. After that, I'll finally attack the API. There may be some surprises.

After a long, painful WIndows experience, I finally switched to Linux for my laptop. This was partly due to continual security problems, even with the gargantuan Symantec tools, which leads to my second issue: speed. There seems to be countless services being dropped in by every little software distributor in existence. Mostly, they lurk looking for updates to download, but who knows what other purposes some of these may have in mind.

Software manufacturers, I am putting you on notice. I own the hardware, and your software is purchased for my use. The hardware is not yours to do as you please. So, you have now lost a source of revenue thanks to your disregard of my personal property.

I know Linux also has its share of daemons. A simple ps shows lots and lots of running processes on an idle system, but I can point to a specific operation of feature that each of these perform, and I can look at the source to make sure it does what its supposed to. Also, the underlying operating system is fundamentally more secure, so I don't have to worry about architectural design flaws making my system a playground for a script kiddie or other hacker. Plus, it boots faster, runs faster, and is generally much easier to use.

The switch took place about a month ago, and while I consider the switch a success, I did have to make the system dual boot because there are three programs for which I cannot find Linux equivalents. I would gladly buy an upgrade to Linux in each case, since I bought the original licenses and they were not cheap (several hundred dollars each). Unfortunately, the software developer does not yet support Linux. Until then, I occasionally will have to boot to Windows, but for that 99% of the time where I do not have to, I am much happier.

I can now say that my computing environment is pretty much Microsoft free.

I finally got back my last bit of feedback. It definitely seems that FreeDOS and DOS in general does not seem to be a worthwhile target. There simply isn't enough interest to make the effort worthwhile. I won't rule it out for some time in the future, but clearly it is not of enough interest to warrant a high enough priority to be an essential or early feature.

Having said that, what I am going to do may seem contradictory. For at least the Proof of Concept release, the native API will be DOS based. It is easy, since the code is in place and already running as of the last POC release. Keeping it going for the immediate future will certainly not hurt. Instead, it will help me get to a funtional POC much earlier than any other API would.

I have another old project I may tap into. It is "UNX" and is unix based. It was a new kernel written to take advantage of the Unix v7 and v32 open source releases. I wrote it after porting the original v32 kernel, only to find that adapting it to modern computers would require such radical changes as to be just shy of a rewrite. It was, in fact, faster to write a new kernel than it was to do the rewrite. In UNX, I have an inode based FAT files system and an API compatible with Unix v7. It may be a good resource for Prima v 0.10.

In the mean time, work on the next POC release continues. ACPI memory detection is a pain in the rump. The simple fact that the specification allows for memory holes means that I need to manage an array of memory and not just a simple model as end of kernel to top of memory for our pool of memory. Oh well ...

P.S., The project was called UNX as a nod to the old Digital Equipment Corporation facility where I worked through both Compaq and HP acquisitions. It was where VAX System V was written, as well as parts of Ultrix. Much of OSF/1 was also written there, which eventually became Digital UNIX and later Tru64 UNIX. That facility was shut down by HP in 2006.

There's an underlying theme that I have yet to write about. No, it's not the memory manager. We'll get to that shortly. What I'm talking about here is KISS. For those unfamiliar with the acronym, it stands for Keep It Simple, Stupid. While it may be taken as a slight, it's really good advice. When given choices of solutions, choose the simpler. It's easier to code and debug. It's easier to maintain. It's faster to develop, and so on. Unfortunately, we seem to forget this, and create huge, difficult to understand and maintain programs, especially in the operating system space.

A good example of this is Linux. I know this is heresy, but how many people really understand the current kernel? I haven't looked at it since 2.6.10, and I know that there have been changes, so that I can't make the claim unless I go back and spend several hours examining the changes. I'd like to avoid it here. I know that if this operating system gains any popularity whatsoever, it will be difficult to avoid bloat, but I'm going to try. Now, maybe, you'll understand the choices behind the memory management.

Prima's Memory Management Design

Previously, we examined the region abstraction that we'll use to encapsulate the underlying hardware details. We haven't looked at the bigger picture, which is managing the processor's memory space in general. For this, we'll fall back to DOS. While there are many people who will pooh pooh this, the methodology is a simple linked list management system. A processor page of 16 bytes is used, thanks to the relationship of segments to memory, and it can be allocated and freed with a minimal amount of code. Seems to me that it meets all the requirements of a KISS design.

DOS-C/FreeDOS isn't the only operating system to use a linked list for free memory management. There's a similar system used in Minix and others. For Prima, we'll use the original DOS-C code, with some changes. For example, the original code used paragraph offsets. This was by design, and made to match the MS-DOS design. I did not make the original design decisions, but the use of a 16 byte paragraph offset allows the os designers to perform simple increments and decrements of the segment portion of the far pointer to move about memory in a rapid fashion. For Prima, a similar choice should be a 4096 byte page. This will help keep memory manipulation in check with smaller size integers for use in computations. It also allows a simpler migration to paging for future releases. That size should also be configurable for future ports to other platforms.

Another adaptation needed to my original code is to the functions and macros designed to adjust the segment:offset addresses to C far pointers. Since we no longer work in a segmented architecture, that is no longer necessary. The reference type will take care of the physical/logical conversion and there is no far attribute in C outside real mode 8086 compilers. What is necessary is a group of support functions to move data to/from user space and between different users spaces. These functions are in assembler and reside in lowcore.asm. Between this and the free space linked list, we should have everything we need to manage our physical memory.

What will significantly differ from DOS-C is freeing of memory. In DOS, the processes are also in a linked list, and freeing process memory is as simple as acquiring that pointer and calling the correct routine to free memory. That can't happen here because of our region abstraction. Instead, we'll pass the region handle back to the region code and expect back a linked list of deallocated memory. We'll then go through the list and free each piece of the list. This is necessary because when we move to paging, the logical, linear memory space may be highly fragmented pages. We cannot assume that the pages will be consecutive. So we must ask the region management code to convert it for us so we can then manage the free space normally.

Final Notes

What I did not mention is that a rudimentary process structure will be necessary to continue this work. I need it so that I can test the region allocation and deallocation code. I also need to create a user space to move data to and from in order to test the support code. I have some ideas, but I'll reserve that design for a later discussion.

You may also be interested in the current status of the code. I just completed converting the thread code from kernel threads to a more generic threading mechanism that will work for kernel and user space. I've done some testing on the code, but without a user space I cannot test the user space aspect of it. Again, another reason to create a rudimentary process. Alas, a complication typical in many projects. However, the progress I am making is good and I'm looking forward to completing the proof of concept release. I will make full use of the early process code to test ideas for the final code.

I've been giving considerable thought to the design of Prima. There are a few design aspects that need to be considered such as processes and threads, memory management, and other details critical to an operating system before you can begin coding. While it may be fun, I want to begin testing some of the ideas I have with respect to these topics.

Adding Functionality

It makes sense to set a target in order to test these new designs. While I'm not ready to make a formal release, I do think it is prudent to set a short term target that can readily be handled as a small project. The definition of this new release is simple: it will be a new proof of concept release with a specific capability to run a single binary. I want to keep it simple so I won't select a specific file format because I am still undecided as to the final goal. I would like to use FreeDOS as a platform for development and djgpp is the best choice for that. In that case, the djgpp coff format would make a good choice. If I decide to support win32 in any way, then PE make sense. Of course, there's always elf with its large base of support in the open source community. So for now, it will be a simple stripped binary image, somewhat of a 32-bit "com" file. This is great, but not something I want to keep for the future.

The Project

I now have the beginning of a project: a defined, measurable target. I still need to do more planning, but this is a small project whose goal is to achieve a step to the final goal of a stand alone operating system. As strange as this may seem, this is my preferred way to handle roadmaps. I like to create individual projects that meet each of the roadmap targets and "phases" that create small, achievable steps along the path to the final goal. This is one of those phases. While the roadmap may not be clearly defined, I know one target and this is one of those phases. I need to have in place processes and their relationships to threads and regions. This is how I will do it.

Acknowledgement

I do want to thank Christopher Giese who runs a web site with lots of handy little snippets of code. You can find it at http://my.execpc.com/~geezer/osd/index.htm and it's worth taking a look at. I've borrowed a couple of his code snippets, such as the interrupt handling, but I have adapted the concepts to fit my generic design. For example, I have my own getvect() and setvect() functions modeled after the DOS versions. I also have newer functions that eliminate the passing of the flags. Also, while Chris looks at tasks, my design is thread based, an update of the original task based design from earlier multitasking operating systems I developed.

If you want a good reference to start your own OS coding, I definitely recommend spending some time at this site.

As you may have noticed from earlier articles, I am somewhat compulsive about portability. Of course, this can be difficult to achieve in a kernel. The kernel is where you get your hands dirty. It is where details such as pages, bits and special registers must all be dealt with.

Fortunately, a microkernel-like design, if not a true microkernel, allows a significant advantage because we can partition our code so that only the kernel itself is aware of these details. The rest of the operating system can access these dirty bits and bytes through abstractions. That's where regions come in.

For Prima, I've decided to model core as regions. Each region has a property of size, virtual start address, and granularity. We can allocate and dispose of regions, and resize them. We will also be able to assign some sort of signaling to each regions so that whenever some sort of need arises to signal a process or thread, the kernel can do so. What we get back is an identifier or "handle" that we can pass to the kernel to allow it to operate on that piece of memory.

There will also be system calls that allow you to transfer data into and out of any region. This is to allow me to avoid one of the costly operations seen in some microkernels, the copying of data in to and/or out of messages. I would much rather hand off a region handle and virtual address to read from or write to in a message than copy the data itself into and out of the message.

Of course, the devil is in the details, and I'm not sure of all those details. But, the design makes sense from an architecture standpoint, regardless of whether or not the design becomes a hypevisor or just a typical, more mundane microkernel.

Of course, this is just one of many design decisions that must be made during the design of an operating system, so don't be surprised if you see something detailed later on that doesn't entirely agree with this. Any complex software architecture will need to be adjusted here and there as the whole design solidifies.

Expect to see some aspect of regions in the next proof of concept release.

Funny Story

When I first wrote the operating system that was to become FreeDOS, I really didn’t know what to call it. The commercial software that spawned it was known as DOS/NT, but I wanted to call this version something different. I couldn’t decide what I wanted to call it, so it went unnamed for a very long time. I did promote it as the shareware version of DOS/NT, so in that respect it is part of the old DOS/NT family, but it had no official name.

Along comes James Hall. I’m reading usenet and I see his PD DOS posting. At first, I shrugged it off, but I later changed my mind. I wanted this piece of code to have some purpose. I then contacted Jim, and offered him that operating system. The remainder of this story is well known and is documented on Wikipedia and other sites.

What About Now

Well, I recently became restless. I had not done any operating system work for a few years, either personally or professionally, and while VoIP is interesting, it’s not the same as a kernel. I thought of ways to advance FreeDOS by extending the kernel to 32- and 64-bit. In what I had in mind, the kernel is a new one in which the user would not know the difference. The user would run all his/her applications as always, but new applications would take advantage of newer features. The user would also gain the ability to run new devices through new device drivers.

So I went back and tried to gauge interest on the FreeDOS mailing list. I published a little poll, and what I got back didn’t really match up with what I wanted to do. I wanted to move the DOS paradigm forward. Most of the responders questioned the need to do this. They’re satisfied with running FreeDOS under some sort of virtualization, not as their primary operating system.

What they’d like:

• Better device driver support
• Better connectivity via TCP/IP
• Better support for modern platforms, such as ACPI and other power management functionality available on modern motherboards
• Some support for new file systems.

Another FreeDOS developer list question asked whether or not FreeDOS could run on ARM. The responses, of course, indicated that you couldn’t. While this is true of the current distribution, the original source code was portable and the new kernel would certainly allow such a port. Even the last release of DOS-C is relatively portable, although some small changes are necessary. Surprisingly, this was the only embedded reference I got back.

Announcing Prima

Prima is the new operating system I am putting together. It is an extension of my original DOS-C, so in some respects it is a branch of the current FreeDOS project. Funny thing is, I have not totally defined the project. I may or may not want to support 16-bit applications. If current DOS users are content with what they have and use other operating systems for their day to day activities, this certainly won’t be something they want to do. I may or may not want to support a POSIX API. There are many very good POSIX based operating systems around, free such as *BSD and Linux, and commercial such as MacOSX and Solaris. I may or may not want to support win32. This would be a huge undertaking.

What this is a proof of concept release. I am taking the original DOS-C code and putting it into a stand alone application that allows me to boot it up and test it. It is a test of the compatibility of the old code with modern compilers. It is also a launching point for the new project.

If you examine the code, you’ll notice some code that was never before released. I am placing a messaging system into this project. I am contemplating a design somewhere between microkernel and virtualization. I like the concept of a microkernel and want to take advantage of the design principals in this project. You’ll also notice a minor shift from the current DOS device driver design. Since there are very few new DOS device drivers these days, I don’t see any advantage in trying to access real mode drivers. I may want to reconsider this at a future date if there is a need to run old device drivers.

For now, here is the proof of concept. Next, I’ll implement a set of coding guidelines, followed by new portability guidelines. By that time, I’ll have decided on a direction and defined the first project for Prima. In the mean time, you can get the source code from ftp://opensourcedepot.com/Prima/Prima-POC-071202.zip.

Enjoy.