Hello Fritz > You are understood: You want to learn how the high-level application and > event API works by trying to recreate (or at least explain) it using > lower-level API. > > You can't do it. At least not in general. > > To provide the high-level functionality, Apple uses the published low-level > API, but it also uses unpublished API, and adds functionality that isn't in > any API, and the whole thing relies upon undocumented interactions between > all the APIs it uses. Apple can do this because every time it revises the > high-level calls, its engineers know what the low-level and private calls in > the same OS release will do. > > You don't know what Apple knows, and the whole idea of a high-level > framework is that you do not have to know, and you should not know. You can > rely on what the documentation says the high-level API does, but you can't > rely on (or, usually, accurately reproduce) how it does it. Anything you > try, to duplicate the high-level functionality, is only a partial guess. > > The way to understand Cocoa is to use Cocoa as it comes to you. Using Cocoa > means trusting it to do its job even though you can't see inside it. That is > in the nature of any modern application framework. > > I programmed for the original Mac, in C. It had an API that could be fully > documented in well under a thousand pages. It was implemented in code that > was easy to disassemble and read. I could explain what was going on inside > every call I made. I wrote my own event loop, and handled my own interrupts. > Those days are gone, and it is horrible to think of going back to them. > > Thank you, that's really the topic i am interested in :). I am wondering, if any kind of "Mac OS Internals" books exist, except "Mac OS Internals: A system Approach" by Amit Singh? Maybe you know some blogs of the developers, or something else to read? Or is this kind of info "a top secret"?
> For your more-specific question, I found many promising leads by googling > "cocoa application modal progress bar". > Yes, i should've typed that in search bar myself before asking the question. I have found the answer. > PS: Yes, you can — when necessary — substitute notionally lower-level API > (ex: Core Foundation, Application Services, BSD) for many things that are in > Cocoa. (I say "notionally lower-level," because that API is sometimes > implemented in terms of Cocoa, and not the other way around.) In this > particular context of learning Cocoa and duplicating the core of > NSApplication, that's a bad approach. > > That is nothing more than having a good feeling about understanding how things work in real under the hood. Of course, these things may and will change with every new version/patch/whatever, but still there are people who hardly can write any highlevel line of code, without knowing what is really going on inside the system. And of course, this is insane to put such adhocs into production. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
