4 ms·

There are so many layers of abstraction in the Windows API that it’s a miracle that anyone could maintain it - which probably explains the increasing le

There are so many layers of abstraction in the Windows API that it’s a miracle that anyone could maintain it - which probably explains the increasing level of bloat in new versions of Windows. Are there fewer layers of abstraction in other popular OSEs?

acdha 11y ago
Yes – it's a product of the way Windows was actually two operating systems, the Windows 3/95/98/ME lineage and the newer OS/2 / NT lineage. The NT side had the advantage of being designed at all rather than growing organically by overworked developers hacking in whatever they needed right now, and had a number of assumptions (e.g. not starting with the 16-bit API real-mode model) which avoided some gnarly hacks. The problem was compatibility: most of the apps had been developed on 16-bit Windows 3 or, later, Win95 and at the time Microsoft's dominance was far from a given so they were pathologically afraid of breaking compatibility, which meant that the Windows “platform” included a lot of weird semi-or-undocumented corners designed to avoid breaking specific apps and the NT side had to reimplement bugwards-compatible versions of most of them to avoid breaking shipped apps. (This might seem excessive – and I would generally agree – but it's important to remember that much of the damage was done in the pre-internet era when shipping updates to software meant putting a box in the main with a pile of floppies or, for the really rich people, CDs. Getting someone to upgrade to a version of an app which didn't rely on an implementation quirk could take many years.) Raymond Chen has written about this extensively at http://blogs.msdn.com/b/oldnewthing/ http://blogs.msdn.com/b/oldnewthing/ and one of my favorite examples is the Shell Folders registry key: http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532... The closest you come to this on another mainstream OS is OS X, where they maintained Carbon (i.e. the supported subset of the classic Mac OS APIs) on top of the modern core but that was both more limited and was rapidly deprecated because Apple is far less concerned with breaking backwards compatibility than Microsoft used to be.
- WalterGR 11y ago
  Thanks. I think that some backwards compatibility can be handled by more code and not necessarily more layers of abstraction, but I get your point. It seems like there are lots of layers in Linux distributions because of the Unix philosophy. For example, to put a window on a screen, aren't the layers something like this: App -> window manager -> desktop environment -> X -> graphics driver (-> hardware) Is that a good approximation? What does that look like on e.g. Windows and Mac OS? Is the situation on Linux similar for audio? From my armchair, my impression is that audio on Linux is/was... complicated.
  - KMag 11y ago
    > App -> window manager -> desktop environment -> X -> graphics driver (-> hardware) No, the window manager isn't in that chain. You can kill the window manager and your applications can keep running and drawing to the screen, but you can't move or resize windows. Also, instead of "Desktop environment" you mean GUI widget toolkit.
    - WalterGR 11y ago
      Also, instead of "Desktop environment" you mean GUI widget toolkit. By desktop environment I meant e.g. Gnome or KDE. Aren't they separate from the widget toolkits?
      - Dylan16807 11y ago
        Gnome or KDE is just a package including a window manager and a bunch of mostly-standalone programs that give you a toolbar, file browser, settings panels, etc. It's not a layer that anything goes through. You don't even have to use the window manager it comes with.
      - wldcordeiro 11y ago
        I believe so. I think Gnome has GTK and KDE uses Qt for their toolkits.
      - KMag 11y ago
        > By desktop environment I meant e.g. Gnome or KDE. Aren't they separate from the widget toolkits? I was being charitable. The desktop environment doesn't belong in the graph you drew. The GUI widgets belong in the place where you wrote "desktop environment". The charitable assumption is that you reasonably conflated the GUI widget toolkits for desktop environments, since the very popular KDE and Gnome are strongly tied to Qt and gtk, respectively.
- pjc50 11y ago
  Given that Microsoft are going to "continuous deployment" with Win10, I think they ought to have taken the opportunity to do one last breaking change, possibly behind an install-time option or compatibility layer: ditch the CP/M legacy. That is, change the path separator to '/', ditch the drive letters, and the magic file names like CON, and the 8.3 names. It sounds like a huge breaking change but code that is already using the shell path functions https://msdn.microsoft.com/en-us/library/windows/desktop/bb773559%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/bb7... would work transparently.
  - acdha 11y ago
    I'd expect that this will happen for Metro apps first – those are all modern and since most of them are supposed to run on e.g. ARM anyway legacy code compatibility matters considerably less. I'd be surprised if they changed the path separator but the device filenames and FAT-compatible short names seem worth doing for security alone.
  - WalterGR 11y ago
    change the path separator to '/' I believe that the Windows API supports '/' as a path separator and that it's user mode apps that tend not to. I can't find a good citation for that, though.
    - acdha 11y ago
      This stuff is a thicket of special cases: “File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\\?\" prefix as detailed in the following sections.” https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
      - WalterGR 11y ago
        This stuff is a thicket of special cases: Is it? That's the only special case I find on that page. Are there specific API functions that have other special cases?
- coldpie 11y ago
  > growing organically by overworked developers hacking in whatever they needed right now One of my personal favorite examples of this is the GetRandomRgn function in Windows's windowing API. https://msdn.microsoft.com/en-us/library/windows/desktop/dd144918%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/dd1... http://blogs.msdn.com/b/oldnewthing/archive/2012/06/18/10321212.aspx http://blogs.msdn.com/b/oldnewthing/archive/2012/06/18/10321...
voidlogic 11y ago
>Are there fewer layers of abstraction in other popular OSEs? This is application servers, not OSs, and its old, but is a pretty famous example: https://ma.ttias.be/system-calls-in-apache-linux-vs-iis-windows/ https://ma.ttias.be/system-calls-in-apache-linux-vs-iis-wind...
- WalterGR 11y ago
  Oh, that's right. I remember that. Good example - thanks!

acdha 11y ago

Yes – it's a product of the way Windows was actually two operating systems, the Windows 3/95/98/ME lineage and the newer OS/2 / NT lineage. The NT side had the advantage of being designed at all rather than growing organically by overworked developers hacking in whatever they needed right now, and had a number of assumptions (e.g. not starting with the 16-bit API real-mode model) which avoided some gnarly hacks. The problem was compatibility: most of the apps had been developed on 16-bit Windows 3 or, later, Win95 and at the time Microsoft's dominance was far from a given so they were pathologically afraid of breaking compatibility, which meant that the Windows “platform” included a lot of weird semi-or-undocumented corners designed to avoid breaking specific apps and the NT side had to reimplement bugwards-compatible versions of most of them to avoid breaking shipped apps. (This might seem excessive – and I would generally agree – but it's important to remember that much of the damage was done in the pre-internet era when shipping updates to software meant putting a box in the main with a pile of floppies or, for the really rich people, CDs. Getting someone to upgrade to a version of an app which didn't rely on an implementation quirk could take many years.) Raymond Chen has written about this extensively at http://blogs.msdn.com/b/oldnewthing/ http://blogs.msdn.com/b/oldnewthing/ and one of my favorite examples is the Shell Folders registry key: http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532... The closest you come to this on another mainstream OS is OS X, where they maintained Carbon (i.e. the supported subset of the classic Mac OS APIs) on top of the modern core but that was both more limited and was rapidly deprecated because Apple is far less concerned with breaking backwards compatibility than Microsoft used to be.

WalterGR 11y ago
Thanks. I think that some backwards compatibility can be handled by more code and not necessarily more layers of abstraction, but I get your point. It seems like there are lots of layers in Linux distributions because of the Unix philosophy. For example, to put a window on a screen, aren't the layers something like this: App -> window manager -> desktop environment -> X -> graphics driver (-> hardware) Is that a good approximation? What does that look like on e.g. Windows and Mac OS? Is the situation on Linux similar for audio? From my armchair, my impression is that audio on Linux is/was... complicated.
- KMag 11y ago
  > App -> window manager -> desktop environment -> X -> graphics driver (-> hardware) No, the window manager isn't in that chain. You can kill the window manager and your applications can keep running and drawing to the screen, but you can't move or resize windows. Also, instead of "Desktop environment" you mean GUI widget toolkit.
  - WalterGR 11y ago
    Also, instead of "Desktop environment" you mean GUI widget toolkit. By desktop environment I meant e.g. Gnome or KDE. Aren't they separate from the widget toolkits?
    - Dylan16807 11y ago
      Gnome or KDE is just a package including a window manager and a bunch of mostly-standalone programs that give you a toolbar, file browser, settings panels, etc. It's not a layer that anything goes through. You don't even have to use the window manager it comes with.
    - wldcordeiro 11y ago
      I believe so. I think Gnome has GTK and KDE uses Qt for their toolkits.
    - KMag 11y ago
      > By desktop environment I meant e.g. Gnome or KDE. Aren't they separate from the widget toolkits? I was being charitable. The desktop environment doesn't belong in the graph you drew. The GUI widgets belong in the place where you wrote "desktop environment". The charitable assumption is that you reasonably conflated the GUI widget toolkits for desktop environments, since the very popular KDE and Gnome are strongly tied to Qt and gtk, respectively.
pjc50 11y ago
Given that Microsoft are going to "continuous deployment" with Win10, I think they ought to have taken the opportunity to do one last breaking change, possibly behind an install-time option or compatibility layer: ditch the CP/M legacy. That is, change the path separator to '/', ditch the drive letters, and the magic file names like CON, and the 8.3 names. It sounds like a huge breaking change but code that is already using the shell path functions https://msdn.microsoft.com/en-us/library/windows/desktop/bb773559%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/bb7... would work transparently.
- acdha 11y ago
  I'd expect that this will happen for Metro apps first – those are all modern and since most of them are supposed to run on e.g. ARM anyway legacy code compatibility matters considerably less. I'd be surprised if they changed the path separator but the device filenames and FAT-compatible short names seem worth doing for security alone.
- WalterGR 11y ago
  change the path separator to '/' I believe that the Windows API supports '/' as a path separator and that it's user mode apps that tend not to. I can't find a good citation for that, though.
  - acdha 11y ago
    This stuff is a thicket of special cases: “File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\\?\" prefix as detailed in the following sections.” https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
    - WalterGR 11y ago
      This stuff is a thicket of special cases: Is it? That's the only special case I find on that page. Are there specific API functions that have other special cases?
coldpie 11y ago
> growing organically by overworked developers hacking in whatever they needed right now One of my personal favorite examples of this is the GetRandomRgn function in Windows's windowing API. https://msdn.microsoft.com/en-us/library/windows/desktop/dd144918%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/dd1... http://blogs.msdn.com/b/oldnewthing/archive/2012/06/18/10321212.aspx http://blogs.msdn.com/b/oldnewthing/archive/2012/06/18/10321...

voidlogic 11y ago

>Are there fewer layers of abstraction in other popular OSEs? This is application servers, not OSs, and its old, but is a pretty famous example: https://ma.ttias.be/system-calls-in-apache-linux-vs-iis-windows/ https://ma.ttias.be/system-calls-in-apache-linux-vs-iis-wind...

WalterGR 11y ago
Oh, that's right. I remember that. Good example - thanks!