Re: How does OSX talk to Cocoa?
Re: How does OSX talk to Cocoa?
- Subject: Re: How does OSX talk to Cocoa?
- From: Andy Satori <email@hidden>
- Date: Mon, 18 Oct 2004 12:00:09 -0400
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:email@hidden]
Sent: 18 October 2004 14:45
To: Oliver Donald
Cc: email@hidden
Subject: Re: How does OSX talk to Cocoa?
On Mon, 18 Oct 2004 14:26:44 +0100, Oliver Donald
<email@hidden> 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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden