Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

The purpose of an operating system, redux

The purpose of an operating system, redux

  • Comments 46
Something changed in the stress mix last week, and I've been swamped with stress failures, that's what caused the lack of posts last week.  But I've spent a fair amount of time while driving into work thinking about my last post (on the purpose of an operating system).  I've not actually read most of the comments (I've really been busy), so if I'm echoing comments made on the other post, forgive me for poaching your ideas, it really is a coincidence.  I'm a little surprised it's taken me this long to have this idea gel in it's current form - it's blindingly obvious, but I never put the pieces together in this way before.

I still stand by my original premise.  The purpose of an operating system is to shield the application from the hardware.

But the thing that you purchase in the store (or buy with your new computer, or download from RedHat) ISN'T an operating system.  It's a platform.  

And a platform does more than just isolate the user from the hardware, a platform is something on which you build applications.  This is a key distinction that it seems many people have a really hard time making.

Let me take Linux as an example, even though I'm far from a Linux expert.  The Linux operating system exists to isolate the user from the hardware.  It hosts drivers and presents a fundamental API layer on which to build systems.  But someone who receiving a machine with just copy of Linux would be rather upset, because it's not really very useful.  What makes Linux useful is that it's a platform on which to build applications.  In the FOSS community, the "platform" is called a "distribution", it contains a set of tools (Apache, Perl, etc).  Those tools make up the platform on which you write applications.  Btw, RMS has been saying this for years now in insisting that people call the "OS" known as Linux "GNU/Linux" - he's explicitly making the differentiation between Linux the operating system and GNU/Linux the platform.

 

Similarly, Windows isn't an operating system.  Windows is a platform.  Nowadays, the Windows platform runs on the NT operating system, in previous years, the Windows platform ran on the Windows VXD operating system, and before that it ran on the MS-DOS operating system.  OSX is also a platform, it runs on an operating system that is (I believe) a derivative of the Mach OS, running with a BSD personality layer (I may be wrong on this, I'm not enough of an OSX expert to know the subtleties of its implementation).

For convenience sake, we refer to the Windows platform as an operating system, just like people refer to OSX or Linux as operating systems, it's simply easier to present it that way to users. 

If you make the paradigm shift to considering the "operating system" as an operating system plus a development platform, it makes a heck of a lot more sense why the platform contains things like an HTML renderer, a sockets layer, a TCP/IP stack, an HTTP server, a directory service, a network filesystem, etc.  These aren't things that shield an application from the hardware, but they ARE things that provide value to applications that want to run on that platform. 

As an easy example, consider an application like the game Neverwinter Nights.  Because the developers of Neverwinter Knights knew that there was an HTML renderer built-into the platform, it meant that they could leverage that renderer in their launcher application (or their update application, I forget which of them used the MSHTML control).  Because they knew that the platform contained a multimedia stack with WAV file rendering, they didn't have to build in a WAV renderer into the game.  Because they knew the platform had support built-in for video rendering, they didn't have to include a video renderer.  They might have had to include a video codec along with their application, because the platform didn't necessarily include that, but it's orders of magnitude easier to write (or license) a video codec than it is to write or license an entire multimedia pipeline.

A rich platform means that applications can depend on that platform, which, in turn makes the platform more attractive to the applications.  Everything that the platform does that an application doesn't have to do is one less thing an application needs to worry about.  Of course, the challenge when enhancing the platform is to ensure that the platform provides the right level of capabilities, and the right ease of use for those capabilities, otherwise applications won't use the platform's implementation, but will chose to roll their own.

  • Great blogpost. Although you were indeed a bit off on the OSX thing. It has a hybrid kernel. Basicly it has huge parts of mach 3.0 and huge parts of (Free)BSD. All of the VM code for example is mach code while other parts like the TCP/IP stack are (Free)BSD code. Both the mach and (Free)BSD system calls are available for OSX (alsthough for some all the functionality got hacked out and a call to the other (be it mach or BSD) syscall is made).
  • Though people claim you are an OS expert, you still don't seem to realize that the whole platform need not be built into the kernel to provide a developer a platform to work on.

    With people like you developing Windows no wonder the security is at the level it is and the product delays and feature sets are so part of Windows and you need to steal ideas from OSX.
  • Dave, did I EVER say the platform was in kernel mode?  Please show me where I said that and I'll fix it.

    Parts of the platform need to run in kernel mode, other parts (the vast majority of them) don't.

  • "I agree about the .NET framework though. The fact that the Windows shell team gave up on it halfway through makes it clear that it didn't deliver the performance it was supposed to in terms of runtime overhead."

    Yes, early versions of Longhorn (prior to the "reset") did use Avalon (now WPF; part of WinFX and based on .NET 2.0) for their user interfaces.  However I'd guess that the choice to stop using it was based less on performance than it was on trying to get the OS shipped before 2010.

    .NET 2.0 did not ship until November 2005.  Up until that time, developing WinFX on top of it was like trying to shoot a moving target.  And building Explorer on WinFX?  That must have been a nightmare--two moving targets.  The decision to not build Vista on WinFX was undoubtably a difficult one, but a wise one from an engineering perspective, both in terms of schedule and quality.  (I believe there are some smaller parts of Vista, such as some MMC components, that are written on .NET 2.0; I know that Media Center on XP is at least partly written on .NET 1.0 or 1.1 so I'd imagine Vista's is too).

    A similar situation occurred in the past when COM was introduced back in the early 90's; I believe it shipped with Windows NT 3.1.  But how much did NT 3.1 use COM?  Well I never used NT 3.1 so I can't say for sure, but I wouldn't be surprised if it didn't use it at all.  But since then?  Windows 95 and NT 4.0 saw an explosion in COM usage, especially in the shell.  Then, IE, IIS, DirectX -- all built on COM.

    It would've been unwise for NT 3.1 to try to make huge use of COM -- both in order for the product to ship on time, and because COM had pretty hefty hardware requirements at the time (another parallel to today's WinFX situation).  In fact, from what I wager, the infamous Cairo would've been a hugely-revamped OS based largely on COM--just like the original Longhorn vision.  So I think it's definitely a good thing that the OS's dependencies on WinFX were cut.  For now--I'm sure the next version of Windows will make good use of WinFX.
  • >Let me take Linux as an example, even though I'm far from a Linux expert.  
    Me neither, but, let me correct you: Linux is just a KERNEL. Nothing less, nothing more.
    In order to become POSIX-conformant operating system, it needs a lot of stuff: C runtime library (glibc), shell (bash), and a number of utility packages just to make it usable (i.e. UNIX-like).

    When it comes to "platform", as a "thing where applications are running" both Linux and Windows look miserable. Say, I want to run Eclipse (Java app). In both Windows and Linux it's neccessary to install JRE from Sun. The same thing is for BitTorrent, which is Python application. Or, Source Navigatgor (TCL app). The same thing is for Perl, Ruby, LUA, whatever apps.

    So, I think, a term platform better matches "a thing which isolates application from operating system differences". Namely, these Pythons, Javas, Rubys and .NETs are platforms. Windows is still operating system or, even better, "Windows distribution" in Linux terms :-))).
  • "This is an impetus to platform evolution... future versions of Windows HTML might respond to this need by allowing a "SupportBlink" option."

    Actually, I think that the Microsoft WebBrowser object already provides all the hooks to add a blink tag (shudder):

    http://msdn.net/workshop/author/dhtml/overview/customtags.asp

    That's a good example of the way a platform should work. It lets you take advantage of all the good infrastructure but still build and integrate the minor missing pieces you need to finish the job. (For the blink example in particular, you could easily implement some Javascript and CSS to make the tag blink without creating any custom tags at all--that's the approach I'd take.)

    OTOH, I understand why Mozilla doesn't use a lot of the Windows infrastructure. They are writing a browser that needs to run on multiple platforms that don't offer equivalent functionality. They chose a roll-your-own approach to solve that problem. It simplifies debugging (fewer divergent code paths) and makes the user experience consistent across platforms, but may not give the best experience on a particular platform.
  • > Are you sugesting that the platform shouldn't provide "extra services" because the chosen implementation might not match some developers' needs?

    I'm saying that bundling any particular implementation of a given platform feature with a given operating system has an opportunity cost associated with it.
  • It's no longer a platform or OS but a turnkey system. I'm more likely to use OE as a word processor than MS Word. Real, Winamp, Netscape, Flash, et al have no chance of getting installed on my computer.

    It's about time MS realised that. You made it a turnkey system. So make it work properly as one.
  • > I'm saying that bundling any particular implementation of a given platform feature with a given operating system has an opportunity cost associated with it.

    From the point of view of someone building an application on the platform, I'm not clear on what that opportunity cost is.

    Case 1: Platform provides an HTML renderer.  In the best case, it does what I need and I can put it to use.  In the worst case, it doesn't do what I need and I have to roll my own (or include someone else's HTML renderer with my distribution).

    Case 2: Platform doesn't provide an HTML renderer.  In the best case, I have to roll my own (or include someone else's).  The best case is now the same as the worst case.

    So how is Case 2 better for me the developer?
  • Vassili: "Linux is just a KERNEL. Nothing less, nothing more."

    Yeah - what part of "[...] just copy of Linux [is] not really very useful.  What makes Linux useful is that it's a platform on which to build applications.  In the FOSS community, the "platform" is called a "distribution"" did you not understand?

    "When it comes to "platform", as a "thing where applications are running" both Linux and Windows look miserable."

    Really? My preferred distribution (platform) - Debian GNU/Linux - comes with Python[0], TCL[1], Perl[2], Ruby[3], LUA[4], etc... (Java support is still a bit iffy due to proprietary Java's non-freeness, free Java's non-maturity, and the DFSG[5], but the DFSG is what attracts me to Debian). As far as I'm aware, all the other Linux distros are similarly featureful. Which distro have you been using that doesn't have any of this?

    Adam

    [0] http://packages.debian.org/testing/python/python
    [1] http://packages.debian.org/testing/interpreters/tcl8.4
    [2] http://packages.debian.org/testing/perl/perl
    [3] http://packages.debian.org/testing/interpreters/ruby
    [4] http://packages.debian.org/testing/interpreters/lua5.1
    [5] http://www.debian.org/social_contract#guidelines
  • Vassili: "Linux is just a KERNEL. Nothing less, nothing more."

    What part of "[just Linux is] not really very useful. What makes Linux useful is that it's a platform on which to build applications.  In the FOSS community, the "platform" is called a "distribution" [...]" did you not understand? Read that whole paragraph again - I think Larry gets what Linux is and is not.

    And, while I'd have to agree with you that a platform is a particular environment/set of libraries, I wouldn't make the distinction that POSIX and Win32 aren't platforms. Both abstract away the kernel to enough of a degree that they are both implementable on each other (see Cygwin/Wine).

    So, while some platforms are more easily implementable in terms of other platforms (e.g. dotnet is being implemented on POSIX (as mono) for Linux, but on Win32 for MSs version), I see no reason why that's a requirement. Mono could be written call directly into the Linux kernel if the developers wanted to, but why bother?

    As for how miserable Linux is, my distro (Debian Etch) comes with at least the following platforms: POSIX, Win32 (wine), dotNet (mono), Python, Perl, Ruby, TCL, Lua, PHP, etc, etc, etc... Most do these days. What distro are you using that doesn't have these platforms included?
  • "The OS is really just a big toolkit for applications to take advantage of. Once an application gains wide acceptance it seems natural to add it to the toolkit."

    Indeed. Just as a naive developer might find it natural to keep adding public methods to an object. It's not such a big deal when you do it just once or twice, but if that's how you do everything then yer cruisin' fer a bruisin'.

    That's not to say that MS is being naive or anything, but their business model means that Windows has dependancies that other platforms might not have. The business model that drives Windows development will have to change when (not if) Moore's Law ceases to apply to hardware development, for instance. Under such a circumstance, slim'n'sassy will be the norm, and the rebels will probably be the ones packing in the extra features.
  • Maurits, I'm not quite sure I follow the logic of your criticism:

    Scenario 1:  The OS provides certain HTML rendering capabilities -> apps that require functions it does not provide must source their own, but apps that only require the functionality provided can use it.

    Scenario 2:  The OS provide *no* HTML rendering capabilities.  *All* apps must now source their own HTML libraries.


    Your seem to be arguing that because Scenario 1 disadvantages a small proportion of applications, that it is inferior to Scenario 2 and should not be pursued.  I'm not quite sure I follow...
  • Maurits: The problem with your example as written is that if the platform does not provide any services, then the application MUST bundle everything with it (e.g. it must license an HTML engine or write one from scratch). The platform has still made a decision that is not compatible with the application's needs.

    I do think it would be preferable for services to be added to the OS with clear APIs and a mechanism to allow applications to choose alternate service implementations. I disagree that Windows components be required to support alternate implementations, given the user interface and other support difficulties this would cause.
  • The cost to the application developers who can't use the features of the platform never changes.  Before Windows provided a renderer without blink support, the application would have to include its own renderer.  After Windows provided a renderer without blink support, the application still would have to include its own.  There's no trade-off here if the application absolutely must have blink support.

    However the cost to developers who can live without blink support decreases dramatically.
Page 2 of 4 (46 items) 1234