Re: How does OSX talk to Cocoa?

FROM : Andy Satori
DATE : Mon Oct 18 18:00:09 2004

You are incorrect.

AppKit *is* the equivalent of the Windows API calls, eg,
Windows.System.Forms doesn't reimplement CreateWindow() in managed
code, it calls the S.W.F object that wraps up the CreateWindow() and
corresponding Messages into a nice neat little object (at least until
Avalon is more than a PipeDream (tm)).  AppKit is the Application UI
implementation of Cocoa.  The C++ equivalent would be Carbon on OS X. 
Cocoa is just the API library that makes the foundation Core Graphics
Aqua magic happen, and is no different than the Windows world (where
SWF dllimports things you don't even want to know about).

Anyways, the short version is that you are worrying about a non issue,
for two reasons.

(a)  the 'glue' dylib is a very thin Objective C layer to handle
objc_msgSend() to make Objective C and C# coexist peacefully.

(b)  if you check the Cocoa# information you'll find that one of the
major goals of 0.2 is to remove the glue with a C# native
implementation that removes the glue and uses libappkit directly.

Now, I'm loosely associated with the effort to make Cocoa# a reality,
but it is currently a 0.1 release.  0.2 *will* bring major changes, and
this is just the surface.  I do watch this list fairly casually, but if
you really want to talk Cocoa#, you might want to check out the wiki
(www.lormyr.com/cocoasharp) or hit the guys up at #cocoa# on
irc.gimp.net.

Andy

On Oct 18, 2004, at 11:05 AM, Oliver Donald wrote:

> We've had firewall trouble, apologies if this makes it to the list
> twice...
>
> Its hard to explain ... btw, I have searched on the Mono website for
> this information, but with little luck :(
>
> Looking through the Cocoa# source code, specifically the C# 'wrapper'
> for NSButton, numerous methods have [DLLImport] attributes
> ([DllImport("myDll.dll")] is an attribute, which, placed above a
> method, allows you to define that method of your class to be
> 'imported' from an unmanaged dll, in this case 'myDll.dll'). We are
> trying to work out what the purpose of these are.
>
> In Window's case with .NET, there is only one layer of abstraction
> between C# and the OS; you use System.Windows.Forms.Button (a wrapper
> in a managed DLL), which in turn calls User32.dll via methods with
> appropriate [DllImport] attributes.
>
>  In Cocoa#'s case, it seems that Cocoa# takes the place of
> System.Windows.Forms, which calls 'libappkitglue.dylib' (again via
> [DllImport]), which I presume in turn calls onto the AppKit framework.
>
>  What we are trying to work out is, if there is a way to bypass the
> call to AppKitGlue (whatever it is, Google searches havent provided
> any info on precisely what it does). Or, how could we get the C# code
> to instantiate ObjC/Cocoa classes itself? Why can't they [DllImport]
> Apple's libraries?
>
> Phew :)
>
> Thanks,
> Oli
>
> -----Original Message-----
> From: Finlay Dobbie [mailto:finlay.<email_removed>]
> Sent: 18 October 2004 14:45
> To: Oliver Donald
> Cc: <email_removed>
> Subject: Re: How does OSX talk to Cocoa?
>
>
>
> On Mon, 18 Oct 2004 14:26:44 +0100, Oliver Donald
> <<email_removed>> wrote:
> > 
> > Hi,
> >  
> > I am doing some research into Cocoa# in an effort to get my company
> to
> > develop software for OSX. One question I have not been able to find
> the
> > answer to is; how exactly are Cocoa objects instantiated by the OS?
> Through
> > what mechanisms does OSX communicate with my objects and vice versa?
>
>  That question doesn't really make any sense. Cocoa objects are
> insantiated by allocating a block of memory to hold them ([<class>
> alloc]) and then calling the designated initializer of that class
> (often [<object> init]).
>
> The implementation of various classes will use various mechanisms to
> deal with the lower-levels of the OS, including syscalls, IPC, maybe
> IOUserClients... But those are implementation details you don't need
> to concern yourself with.
>
> What are you trying to do?
>
>  -- Finlay
>
>
>
> DISCLAIMER: The information contained in this e-mail is confidential
> and may be privileged. It is intended for the addressee only. If you
> are not the intended recipient, please delete this e-mail immediately.
> The contents of this email must not be disclosed or copied without the
> sender's consent. We cannot accept any responsibility for viruses, so
> please scan all attachments. The statements and opinions expressed in
> this message are those of the author and do not necessarily reflect
> those of the company. The company does not take any responsibility for
> the views of the author.
>  _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list      (<email_removed>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>