FW: How does OSX talk to Cocoa?

FROM : Oliver Donald
DATE : Mon Oct 18 17:05:15 2004

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.