Click here to Skip to main content
13,199,026 members (43,095 online)
Click here to Skip to main content
Add your own
alternative version

Tagged as


1 bookmarked
Posted 26 Feb 2013

Building an Operating System? Time to Drop the Objects!

, 26 Feb 2013
Rate this:
Please Sign up or sign in to vote.
By using a procedural based approach using such a three tiered system, I strongly believe that operating systems could be designed to be simpler, faster and smaller, which is exactly what we need today for our mobile platforms.

Having been writing software since the days of CPM (and before), I can appreciate how far computers have come. If anyone thinks an Atom CPU is slow, try writing software for the Commodore 64 with a CPU which was only 1 mhz in speed. Yet despite all the changes in computers over the years, to me, it is still just a matter of working with bits and bytes. ASCII text are just bytes. Numbers are just bytes. Graphics is simply moving a lot of bytes around really fast. I know, that sounds a bit over simplistic, but it leads to a point.

In the old days, operating systems were simply a set of APIs which encapsulated basic functionality one could build upon. They provided access to the hardware (i.e., keyboard, mouse, screen). They provided basic user interface elements (anyone remember Geos for the Commodore 64). They were the building blocks of which software was based. Even Windows from the days of 16 bit Windows was simply a set of APIs which you could build upon.

Something changed though over the years. Object oriented programming took over and it wasn’t enough to just use it to build higher level abstractions on top of the operating system, but it began to take the place of simple APIs in the core of operating systems. I believe that object oriented programming may be at the core of what makes operating systems and software too complex so that each new generation requires more and more powerful hardware just to keep up.

While I appreciate the goals of OOP, such as code reuse, I am not so sure that it really accomplishes what it was intended to solve. What can make software and even an operating system powerful is simplicity, not complexity. Just for a moment, consider the inherent complexity of OOP. Just ask someone to explain the meaning of common terms of OOP and you quickly find that which was supposed to be simple is actually an overly complex concept. For example, was it abstraction?

Just do a Google search to find the answer and rather than a clear cut answer, one finds that there really isn’t a clear definition. Here is one discussion where someone asks this question and just take a look at the variety of answers he gets.

Now, define something like subroutine or function. Not too difficult, is it. Subroutines and functions are the simplest constructs of reusable code. Early APIs were simply a set of prewritten subroutines or functions of which software could build upon. Need a font ? Call a simple operating system API like CreateFont and you get an index (or handle) to an available font. What could be simpler ?

Now, some may feel the objects are the necessary higher level constructs of which modern software must be built upon, but is this true? I don’t think so. Why do I say that? Because as a developer of tools for programmers, my job is to design higher level constructs to make programming easier for other programmers and after spending ten years building a GUI engine (in its fifth generation now), I have come to the conclusion that one can build high level GUI libraries without object oriented programming and guess what happens when you do? You get smaller, less resource hungry software.

Yes, with so much emphasis today on mobile platforms, we need smaller, less resource hungry software. So how can one provide the higher level functionality that programmers require, without using object oriented programming?

The Three Tiered Building Block Approach

Have you ever played with Lego blocks? The amazing thing about Legos is that with a good assortment of different blocks, one can build an almost unlimited variety of models. The blocks come in different degrees of complexity from just rectangular blocks to wheels, windows, etc. Most blocks are totally reusable too.

Building software, even an operating system, can be done in a similar fashion. The difference with software though is that the less complex building blocks can be used to build the more complex blocks for the ultimate in code reusability. I will refer to this as a “three tiered” design. What is that?

Basically the three tiers are:

  • Low level functions (or subroutines)
  • Medium level functions (or subroutines)
  • High level functions (or subroutines)

All operating systems must have some low level functionality to build upon and one can build an API to provide the lowest level of functionality available to all software that runs on it. Some may feel that one must build this functionality upon objects, but it need not be so. True, data types which the core operating system (even higher level apps too) will use to track tasks may need some structure, but simple types or structures which most programming languages provide is sufficient for this. The core set of APIs can be very low level. Low level functions should be of a single task nature, for example, create me a font or a drawing brush.

The next step is to build the medium level APIs, which are built upon the low level APIs. Medium level APIs will combine multiple tasks together to provide more complex user interface features. For example in Windows, if I wanted to prepare a drawing surface (a memory DC with a bitmap selected into it), it requires multiple steps (create a DC, create a bitmap, select a bitmap into the DC). Yet, the Windows API doesn’t provide this functionality in a simple API. It should have though (and that is the kind of thing I write into my GUI libraries). It is this medium design which may be lacking in operating systems. By building even more complex user interface features into this medium level, it provides programmers with even more choices and makes software development faster.

Lastly, with an extensive medium level set of APIs (which builds upon the low level), now we can start building the higher level APIs. High level APIs should provide functionality which would have taken hundreds of lines of low level or dozens of lines of medium level code. The more extensive the low level and medium level APIs are, the more high level APIs can be created.

By using a procedural based approach using such a three tiered system, I strongly believe that operating systems could be designed to be simpler, faster and smaller, which is exactly what we need today for our mobile platforms.

Does this approach work?

Yes it does. While I don’t develop operating systems, I do develop GUI engines that sit on top of the operating system. To me, the WIN32 APIs are the low level functions I build upon and my job is to build the medium level and high level constructs on top. By using this three tiered approach with purely procedural style coding (APIs upon APIs) and avoiding the use of objects, I find I can software with an amazingly small footprint which requires minimal hardware resources. I design software with the mindset of “write it so it can fit on a floppy disk”. Ok, we don’t use floppies anymore, but you can get the picture. Small is beautiful and efficient!

There are a number of open source operating systems in development and likely more coming. But has anyone ever considered this more simplistic approach? If they did, I would not be surprised to someday see small tablets which are super thin and with multiple days of battery life, but are full blown computers rather than simply an ebook. The three tiered approach lends itself to the “smaller, faster” goal which Bob Zale (creator of TurboBasic and PowerBasic) always encouraged. Maybe those old timers knew something which today's programmers haven’t learned yet. While I am not saying that OOP should never be used, the above three tier approach could lead to faster, smaller operating systems and software.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Chris Boss
Software Developer Computer Workshop
United States United States
Chris Boss is the owner (and programmer) of a small software development business in rural Virginia, called the Computer Workshop. For the last ten years or so he has been developing tools for use by Powerbasic programmers (see: ). His main product called EZGUI (Easy GUI) is a high level GUI engine with Visual Designer and code generator. It is in its fifth generation now. He is an experienced Windows API programmer (more low level) and has experience in writing GUI engines (forms/controls), drag and drop Visual Designers, Graphics engines (printing and to the screen) and one of his favorites is a Sprite engine (2D animated movable images). His current project is version 5.0 of his main product EZGUI, adding such features as multi-monitor support, component engine, custom control engine, superclass engine and the latest project a 3D OpenGL based custom control. One of the goals he has is to push the limits of Windows software development, while making it easy, fast execution speed, small footprint (size of executables) and code reusability while providing a more graphic experience in user interfaces, while still being able to write software which can fit on a floppy disk (small footprint), use minimal amount of memory and able to run on multiple versions of Windows from 95 to Win8.

You may also be interested in...


Comments and Discussions

Question3-tier OOP Pin
Member 95922222-Mar-13 17:32
memberMember 95922222-Mar-13 17:32 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.171020.1 | Last Updated 26 Feb 2013
Article Copyright 2013 by Chris Boss
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid