6 ms·

Reversing Apple80211

18 points by 2510c39011c5 12y ago

wolfgke 12y ago
It is interesting that in the 90s there was a large shitstorm against Microsoft for having lots of private, undocumented APIs. The fact that Apple does the same thing in OS X doesn't seem to bother anybody - at least there is no such outcry.
- baldfat 12y ago
  Well - Anyone that would uses | used Linux and now the ones using OS X don't have it high on their priority list.
- msh 12y ago
  Apple dont have a Monopoly...
- th0br0 12y ago
  Don't forget that, back then, systems were small enough to be understood easily on your own. Nowadays, that's not really the case anymore. Besides, we kind of find ourselves in a situation where most people have simply accepted being beholden to closed source software providers.
  - wolfgke 12y ago
    > Don't forget that, back then, systems were small enough to be understood easily on your own. Even in the 90s, Windows (e.g. 9x family or NT family) was too complicated to be easily understandable on your own. Nevertheless, the people (IMHO rightly) complained about undocumented, private APIs in Windows.
- kelnos 12y ago
  I think part of the outrage was that MS was using those private APIs in software like Office that would allow it to do things that competing office software couldn't do. That's theoretically true of Apple as well, but either they haven't done that, or no one has looked closely enough to find out.
  - 0x0 12y ago
    Who cares about private APIs, when they won't even allow you to publish a web browser app with its own rendering engine - even if it was implemented using only public APIs? (iOS)
    - kelnos 12y ago
      It's a result of the restriction against writing code that downloads and interprets code from an external source. I don't agree with that restriction, but it's certainly not Apple saying "you can't write a browser rendering engine" specifically.
  - FireBeyond 12y ago
    I seem to recall - though I definitely can't think of any specific examples - of there being plenty of things "only Apple apps" can do, be it on OS X or iOS. Seems like anything around security, limitations on extensions and such (though many of those are policy, not API-based).
    - kelnos 12y ago
      I don't think those sorts of things are quite as objectionable, though. AFAIK, most of the things only Apple apps are allowed to do are more "system level" things that 3rd-party apps in general don't need to do. Sure, there are exceptions, but I think "Apple can bundle a wifi scanner app with the OS and I can't build a 3rd-party scanner" is a lot different from "Microsoft can sell an office suite that does things I can't do in my office suite because of private APIs". ... the key difference being that MS was using their private APIs to crush competition. Also one could argue that Apple is more of a hardware company, to a certain extent. They give away most of their software for free. Microsoft was using their OS monopoly to beat competitor's apps that run on top of Windows.
- csixty4 12y ago
  Microsoft used their private APIs in other software to give it an unfair advantage over their competitors, and they did it while they had a monopoly position in their market. That's why the DoJ went after them. Apple doesn't have a monopoly in any industry they compete in currently.
- derefr 12y ago
  AFAICT, these aren't APIs that even Apple's own software consumes. Instead, these are the higher component-level equivalent of "private functions" in a module: there for the public functions to call (and for the public functions to be implemented in terms of), but not part of the contract. Windows, to contrast, is written in such a way that you get developers finding random things (registry entries, unexported symbols, resources in random DLLs) and writing their software to depend on those being there. These are supposed to be implementation details—they're undocumented, and are supposed to be allowed to change, but—since Microsoft allows the developers of their third-party software to convert these previously-private-APIs into public APIs with API contracts, and assumes the responsibility for maintaining those APIs from then on to prevent that software breaking—it could be said that Windows doesn't really have any private APIs. (Or didn't. This is changing, first with the CLR and now moreso with Metro app sandboxing.) OSX's public/private framework split is in large part a reaction to that, I think: Apple draws a clear boundary between "frameworks you can link against" and "frameworks we will punish you for linking against." This means that anything within the public frameworks is up for grabs—exported symbols, unexported symbols, the embedded-est of undocumented structs-in-structs-in-structs—which forces Apple to make sure that everything in them is merely flattened proxy representations, rather than something the system cares about. They're effectively following the SOA approach, with each of their public frameworks being like a service endpoint, returning self-contained resource representations rather than passing up anything from below.
  - wolfgke 12y ago
    > Windows, to contrast, is written in such a way that you get developers finding random things (registry entries, unexported symbols, resources in random DLLs) and writing their software to depend on those being there. These are supposed to be implementation details—they're undocumented, and are supposed to be allowed to change, but—since Microsoft allows the developers of their third-party software to convert these previously-private-APIs into public APIs with API contracts, and assumes the responsibility for maintaining those APIs from then on to prevent that software breaking—it could be said that Windows doesn't really have any private APIs. So you want to morally punish Microsoft for caring more about backwards compatibility than Apple did and does (even if the developer does dubious things, such as using private APIs)?

18 points by 2510c39011c5 12y ago

It is interesting that in the 90s there was a large shitstorm against Microsoft for having lots of private, undocumented APIs. The fact that Apple does the same thing in OS X doesn't seem to bother anybody - at least there is no such outcry.

baldfat 12y ago
Well - Anyone that would uses | used Linux and now the ones using OS X don't have it high on their priority list.
msh 12y ago
Apple dont have a Monopoly...
th0br0 12y ago
Don't forget that, back then, systems were small enough to be understood easily on your own. Nowadays, that's not really the case anymore. Besides, we kind of find ourselves in a situation where most people have simply accepted being beholden to closed source software providers.
- wolfgke 12y ago
  > Don't forget that, back then, systems were small enough to be understood easily on your own. Even in the 90s, Windows (e.g. 9x family or NT family) was too complicated to be easily understandable on your own. Nevertheless, the people (IMHO rightly) complained about undocumented, private APIs in Windows.
kelnos 12y ago
I think part of the outrage was that MS was using those private APIs in software like Office that would allow it to do things that competing office software couldn't do. That's theoretically true of Apple as well, but either they haven't done that, or no one has looked closely enough to find out.
- 0x0 12y ago
  Who cares about private APIs, when they won't even allow you to publish a web browser app with its own rendering engine - even if it was implemented using only public APIs? (iOS)
  - kelnos 12y ago
    It's a result of the restriction against writing code that downloads and interprets code from an external source. I don't agree with that restriction, but it's certainly not Apple saying "you can't write a browser rendering engine" specifically.
- FireBeyond 12y ago
  I seem to recall - though I definitely can't think of any specific examples - of there being plenty of things "only Apple apps" can do, be it on OS X or iOS. Seems like anything around security, limitations on extensions and such (though many of those are policy, not API-based).
  - kelnos 12y ago
    I don't think those sorts of things are quite as objectionable, though. AFAIK, most of the things only Apple apps are allowed to do are more "system level" things that 3rd-party apps in general don't need to do. Sure, there are exceptions, but I think "Apple can bundle a wifi scanner app with the OS and I can't build a 3rd-party scanner" is a lot different from "Microsoft can sell an office suite that does things I can't do in my office suite because of private APIs". ... the key difference being that MS was using their private APIs to crush competition. Also one could argue that Apple is more of a hardware company, to a certain extent. They give away most of their software for free. Microsoft was using their OS monopoly to beat competitor's apps that run on top of Windows.
csixty4 12y ago
Microsoft used their private APIs in other software to give it an unfair advantage over their competitors, and they did it while they had a monopoly position in their market. That's why the DoJ went after them. Apple doesn't have a monopoly in any industry they compete in currently.
derefr 12y ago
AFAICT, these aren't APIs that even Apple's own software consumes. Instead, these are the higher component-level equivalent of "private functions" in a module: there for the public functions to call (and for the public functions to be implemented in terms of), but not part of the contract. Windows, to contrast, is written in such a way that you get developers finding random things (registry entries, unexported symbols, resources in random DLLs) and writing their software to depend on those being there. These are supposed to be implementation details—they're undocumented, and are supposed to be allowed to change, but—since Microsoft allows the developers of their third-party software to convert these previously-private-APIs into public APIs with API contracts, and assumes the responsibility for maintaining those APIs from then on to prevent that software breaking—it could be said that Windows doesn't really have any private APIs. (Or didn't. This is changing, first with the CLR and now moreso with Metro app sandboxing.) OSX's public/private framework split is in large part a reaction to that, I think: Apple draws a clear boundary between "frameworks you can link against" and "frameworks we will punish you for linking against." This means that anything within the public frameworks is up for grabs—exported symbols, unexported symbols, the embedded-est of undocumented structs-in-structs-in-structs—which forces Apple to make sure that everything in them is merely flattened proxy representations, rather than something the system cares about. They're effectively following the SOA approach, with each of their public frameworks being like a service endpoint, returning self-contained resource representations rather than passing up anything from below.
- wolfgke 12y ago
  > Windows, to contrast, is written in such a way that you get developers finding random things (registry entries, unexported symbols, resources in random DLLs) and writing their software to depend on those being there. These are supposed to be implementation details—they're undocumented, and are supposed to be allowed to change, but—since Microsoft allows the developers of their third-party software to convert these previously-private-APIs into public APIs with API contracts, and assumes the responsibility for maintaining those APIs from then on to prevent that software breaking—it could be said that Windows doesn't really have any private APIs. So you want to morally punish Microsoft for caring more about backwards compatibility than Apple did and does (even if the developer does dubious things, such as using private APIs)?