Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Riffing on Raymond - the purpose of an operating system

Riffing on Raymond - the purpose of an operating system

  • Comments 32
 

In Raymond's post today (Adding flags to APIs to work around driver bugs doesn't scale), Raymond wrote:

Perhaps it's just me, but I don't believe that workarounds for driver issues should become contractual. I would think that one of the goals of an operating system would be to smooth out these bumps and present a uniform programming model to applications. Applications have enough trouble dealing with their own bugs; you don't want them to have to deal with driver bugs, too.

My personal take on this is that the entire PURPOSE of an operating system is to smooth out the bumps and present a uniform programming model to applications.  Applications don't need to know about the weird behavior of of the u765 floppy disk controller that only shows up when there are more than two floppy drives (I got a free 72 hour trip to France because of that particular issue).  They shouldn't need to know that a certain models of network adapter will sometimes hand the OS a packet that is half filled with garbage. Applications shouldn't have to know the low-level commands needed to drive a printer.  

IMHO, the ONLY reason for an operating system to exist is to hide the details of the hardware from the application.  Everything else is sugar.

People forget what the world was like when they would buy a word processor and it would come with a list of the two dozen or so printers that were supported by the application.  If you wanted to use the word processor but didn't own one of the listed printers, you were out-of-luck.

For those of you that are now going to say "Aha!  Larry now thinks an OS shouldn't contain a web browser", that's not at all the case.  An HTML renderer is a very high level special case of hiding the details of the hardware from the application.  In the case of an HTML renderer, it's job is to provide a uniform interface that can be used to render HTML content to the screen, just like a printer driver provides a  uniform interface that can be used to render content to a printer.  Similarly an OS should contain a TCP/IP stack and network programming layer that allows for application authors to avoid understanding the icky details of interoperability (it's HARD to write a high quality TCP/IP stack, and application authors shouldn't have to).

 

But I still stand by my original assertion: The only reason for having an operating system is to hide the details of the hardware from the applications that run on the computer.

 

Btw: This is MY opinion.  I want to repeat that.  MY OPINION.  Others undoubtedly feel otherwise.

 

  • "IMHO, the ONLY reason for an operating system to exist is to hide the details of the hardware from the application."

    So what bit of hardware does an HTML renderer hide from applications?

    Oh, it doesn't. It just hides lower-level libraries, (which hide lower-level libraries, ...) which talk to the kernel (or to a video driver with an interface defined by the kernel/core OS lib), which hides the details of the hardware.

    And how do other applications talk to the "web browser"? Oh - they don't? No, they talk to the HTML renderer. Nice of you to switch between "HTML renderer" and "Web browser" as if the two were interchangable when one is a useful library that can be used by other applications to render HTML content, while the other is an end-user application.

    "We decided to include a useful shared rendering library for everyone to use." is a _completely_ different statement than "We decided to include a web browser, place it on the desktop, and raise the costs (directly or indirectly) for OEMs who ship Navigator at least as visibly as IE so they won't do it."

    (See http://www.groklaw.net/article.php?story=20060404153340949 in particular quoted paras 158-159, 167, 171-172)

    You're trying to justify the second of those statements by saying it's really the same as the first, which is *really* insulting.

    Stick to the technical stuff, you're much better at it.
  • Larry wrote:
    > But I still stand by my original assertion: The only reason for
    > having an operating system is to hide the details of the
    > hardware from the applications that run on the computer.

    But surely that statement is meaningless without defining the level of abstraction that you think an OS should provide? Otherwise any piece of software from a kernel-mode device driver that reads/writes hardware registers all the way up to a user-mode HTML renderer (or PDF renderer or word processor or whatever) can be defined as a hardware abstraction and should therefore belong in an OS.

    Mike wrote:
    > You _could_ have an OS that would be only category a) but I
    > don't think you'd find too many takers.

    Sure you would, just not from desktop PC users. The realtime/embedded world has no need for HTML renders and whatnot so the operating systems that sell well into that market, like WindRiver's VxWorks (which is widely used in the telecoms business and also runs on the Mars rovers), would fit your definition of a 'traditional' operating system I think.
  • Wednesday, April 05, 2006 1:47 PM by Stuart Rowan
    > BSD's high quality one.

    BSD's high quality one was accomplished after fixing their low quality one.  Once upon a time the manual pages even mentioned which game it was that exposed bugs in BSD's original implementation of sockets.

    Up to a point it the occurence of bugs isn't the real problem, the real problem is whether the bug maker will provide customers with fixes for serious bugs.
  • >> Microsoft, of course, gave up on their own TCP/IP stack and switched to using BSD's high quality one.


    Care to see a video?
    http://channel9.msdn.com/ShowPost.aspx?PostID=116349#116349
  • The ie/wmp problem is that of modularity...microsoft is free to provide anything with the os, but the user should be able to not install/remove them without leaving any trace and install his own modules to provide those services...so that for example all the html-based help (vstudio comes to mind) would use firefox/opera and multimedia decoding would be provided by winamp/vlc...etc

    Of course that would require open apis and collaboration with the community, and the day microsoft starts to pursue such goals will probably have us sporting long white beards :)
  • Something changed in the stress mix last week, and I've been swamped with stress failures, that's what...
  • Coleman: I'm struggling to understand what it is you need that the recvfrom() function does not give you, unless you want a way to find out the address _before_ you handle the packet. Even then I think you can use MSG_PEEK with recvfrom().

    Andrew: that's why Microsoft has Windows CE. If you really do need to minimise the size of your device's firmware image, but still want to employ Windows development expertise, it can be a good choice. I don't know if you can configure Windows XP Embedded so that it doesn't include the HTML renderer, although I suspect you can. But this is a highly specialised market, for situations, in general, where you know the complete set of applications which will run on the platform, and can therefore select exactly which development libraries and supplied applications you're going to include.

    I mostly work on devices that run either Windows Mobile - which is a Microsoft-specified set of OS components, development libraries and applications married to a specific OEM's drivers and any extension libraries and applications they care to add - or an OEM's selection of components from the Windows CE box, again plus their own additions. In both cases you live with what Microsoft and/or the OEM supplied.
  • Mike, I need to know the address that the packet is destined for.  Where does recvfrom give me that information, even using MSG_PEEK?  Yes, I need it before I process the packet (or at least, readily available as I process the packet).   Is that information part of the raw buffer or something?

    Another example, specific to Windows CE.  How does one reliably obtain the subnet mask?  I've used the trick where you look in the registry (HKLM\Comm\adaptername, etc.), but that's simply not always reliable.  The information doesn't show up there when it's changed, for example.  The registry path is different at times, relying on HKLM\Comm\PCI\adaptername.  Huh?

  • "The ie/wmp problem is that of modularity...microsoft is free to provide anything with the os, but the user should be able to not install/remove them without leaving any trace and install his own modules to provide those services...so that for example all the html-based help (vstudio comes to mind) would use firefox/opera and multimedia decoding would be provided by winamp/vlc...etc"

    Oh man.  Can you really imagine if this were the case?  Think of the test matrices!  Not only do you have to test your apps against all the various Windows/IE combinations, you also need to test against Firefox versions, Opera versions, etc.  And the *slightest* difference between them could hose your application.

    If every component of Windows were designed such that it could be swapped out by a third-party implentation, we'd be seeing Vista in about 2050 or so.  Development and support costs would go through the roof, not just for MS but for all ISVs.  During the remedy phase of the MS-DOJ trial, MS explains this in more detail.
  • I'm aware of that explanation, but I still think that with a clear api and maybe a process to certify that the modules render the content as intended, there wouldn't be that many problems...after all, it would be the user's responsibility to install the alternative modules and a lot of users don't want to deal with that or won't be allowed. And as for thesting, it would be actually easier both for microsoft and the isvs. Modularity _is_ good...
  • "The ie/wmp problem is that of modularity...microsoft is free to provide anything with the os, but the user should be able to not install/remove them without leaving any trace and install his own modules to provide those services...so that for example all the html-based help (vstudio comes to mind) would use firefox/opera and multimedia decoding would be provided by winamp/vlc...etc"

    And then Windows users and programmers would find themselves in the GNU/Linux nightmare world of non-standardisation. (Is that a word?)
    No thanks...
  • @coleman:

    IP_HDRINCL with raw sockets is what you need. I use it all the time (for custom IPSec and related implementations)

  • Ok, I did some googling and digging in the MSDN and to retrieve the subnet mask on WinCE 5.0 you should use the GetAdaptersInfo IP helper function.  That's great for that version of CE, but what about older versions?  Am I stuck with the registry hack?
  • BTW, the MSDN link for GetAdaptersInfo is:
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iphlp/iphlp/getadaptersinfo.asp
  • Here's GetAdaptersInfo for CE 4.2:
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcetcpip/html/_wcesdk_win32_GetAdaptersInfo.asp?frame=true

    The page says the minimum CE version is 3.0.

    I used it in computing a guess of a subnet mask because I couldn't find any method that is documented to be reliable.
Page 2 of 3 (32 items) 123