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.

  • "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 cho[o]se to roll their own."

    I definitely don't envy your job, trying to define functionality that won't be mainstream for years. No matter how well you think it out, there's a good chance it won't work as you intended once it's in wide distribution. I'm not placing blame here, just expressing frustration.

    Those of us who write apps for the installed base are saddled with those 1990s APIs and techniques that didn't quite work out as intended, but they're present on every Windows system so they're the best bet for compatibility. Sure I could use some new Vista/W2003 API but I still have to roll my own for the 95% of the market that doesn't have them. So the new APIs just make the job more complex until they're mainstream.

    The same goes for .NET, I'd love to use it but I can't justify the hassle of delivering the 2.0 framework to users, who will blame *my* app for being bloated. Plus, I want to see Microsoft eating some dogfood there before I take the jump. I would prefer that Microsoft finish its compatibility with XHTML and CSS 2.1 (specs that were nailed down almost half a decade ago). That way, in about five years I will finallly be able to build standard browser-based apps that work across platforms.


  • Dave, actually CSS 2.1 still hasn't been finalized after 8 years. And that's absolutely ridiculous and why I don't trust the W3C. Not only that but 2.1 exists simply to correct the huge number of errata in 2.0.  I don't blame the IE team for being hesistent to implement the recommendation.

    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.  Indeed it can be hard convincing your boss you need to deploy a .NET application to do some trivial thing yet it uses 20 megs of RAM on every machine.
  • I agree with Dave on sometimes MS is a bit behind set standards, or sometimes their standards are different than the set standard hence forcing us to roll our own. However don't get me wrong they are getting much much better.

    Me on the other hand love .net and I think that a huge part of the it's getting better I see. I am able to do so much more and so much faster in a much more secure way with .net than ever before. The Crux is the Framework install. Yet still it is far superior. Now my question though for Larry to think about is the .net a platform. Hence it could be considered Windows actually hosts several platforms hence the scripting engines, some call Direct X and platform, etc or is .net just another part of windows. We can go right into the windows API's with unsafe codeblocks after all and a lot of the framework does that as well.
  • > Everything that the platform does that an application doesn't have to do is one less thing an application needs to worry about

    And conversely, every decision the platform makes for the application is one less thing an application can decide for itself.
  • Sweet.  Or should I say "suite."  

    This is very clean.  

    Also, the prospect of different hostings, posted by Maurits (e.g., .NET versus WinApps versus ...) is also something to sort out.  There do seem to be multiple platforms that emerge from the various stacks.  (No wonder VC++ newbies are so confused.)
  • Dave wrote:
    > XHTML and CSS 2.1 (specs that were nailed down almost half a decade ago)

    XHTML I'll give you (XHTML 1.0 became a recommendation in 2000, 1.1 in 2001), but CSS 2.1 is in fact not yet a recommendation at all.

    Jeff: my view on this is that you can build platforms on top of existing platforms. The IBM compatible PC and the x86 architecture are also platforms, on top of which the Windows platform is built. .Net is a platform that builds on the Windows platform, and occasionally such newer platforms become part of the base platform, like what happened to DirectX before and .Net with the introduction of Windows Server 2003 and now Vista.
  • Maurits, I don't follow that - applications can choose to opt-into platform features.  Firefox doesn't HAVE to use the Windows HTML renderer, it can write its own.

    Similarly, an application doesn't HAVE to use the Windows TCP/IP implementation, it can write its own and deploy it if it finds the Windows implementation insufficient.

  • > Firefox doesn't HAVE to use the Windows HTML renderer

    Indeed (and of course, it doesn't.)

    Suppose an application has some rather primitive HTML rendering needs: in particular, <b>, <i>, and <blink>.

    Windows HTML renderer made the choice not to support <blink> (by popular demand.  Neither does Firefox's.)

    Now the app has to look elsewhere for its HTML rendering needs.  It either has to license another engine (such as Gecko) or write one from scratch.

    This is unfortunate.  The platform has made a decision that is not compatible with the application's needs.

    This happens all the time, to a greater or lesser extent, in any platform.  This is an impetus to platform evolution... future versions of Windows HTML might respond to this need by allowing a "SupportBlink" option.

    But if you're the application developer, it's a bit of a pain.  It's almost enough to make you redesign your app to not make use of <blink>.
  • So what?  If there were no MSHTML you'd have to do implement it yourself anyway.
  • "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.  Indeed it can be hard convincing your boss you need to deploy a .NET application to do some trivial thing yet it uses 20 megs of RAM on every machine."

    Performance wasn't the primary issue why .Net isn't used in the shell. I believe the primary problem was in terms of shell extensions, since you can only have one version of the .net framework per process. If someone wanted to run the shell with an extension written in 1.1, and another in 2.0 (or some future version of .Net) the two wouldn't be able to run in the same process.
  • I can't agree more.

    The biggest difference in installing softwares on Linux and Windows is:

    On Windows you have a common set of libraries that you're sure you can find on it (nearly every libraries are installed by default, the Windows installation give you choice on the Applications only, not the libraries)

    On Linux, you can select what libraries you want to install on the system. While this give you a smaller installation(you don't need to install those unnecessary libraries), you can easily run into "dependence hell"(which is better managed by those package managers right now)
  • Larry Osterman is a well known and very respected developer at Microsoft. Recently he has been writing...
  • I think it is natural for an operating system to evolve over time so that it will eventually encompass other application functions.

    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.
  • Monday, April 10, 2006 7:15 PM by Maurits
    [Larry Osterman:]
    >> Firefox doesn't HAVE to use the Windows HTML renderer
    >
    > Indeed (and of course, it doesn't.)

    IE lovers will be glad to see the following parallel:

    Firefox doesn't have to use the Windows dial-up dialog.
    And of course it doesn't.
    And it doesn't come close to providing an adequate dial-up dialog for dial-up users who have two ISPs (or more).
    I had to recommend to my parents that it would be easiest for them to return from Firefox to Internet Explorer.

    Of course, that's no excuse for what Microsoft did to Netscape, or to Real, etc.
  • Maurits: I'm not sure where you're trying to get here.

    Are you sugesting that the platform shouldn't provide "extra services" because the chosen implementation might not match some developers' needs?
Page 1 of 4 (46 items) 1234