Re: OT, AppleTalk and Porting to Carbon
Re: OT, AppleTalk and Porting to Carbon
- Subject: Re: OT, AppleTalk and Porting to Carbon
- From: Quinn <email@hidden>
- Date: Fri, 14 Nov 2003 11:17:07 +0000
At 10:04 +0000 12/11/03, David Burgun wrote:
OTRcvUReply
OTSndURequest
PSetSelfSend
At 16:47 +0000 12/11/03, David Burgun wrote:
X anyway, and if easy or at least not too much trouble, 9 too.
Your AppleTalk code will have to be platform specific. These calls
imply that you're using the ATP protocol. There's no support for the
ATP protocol within Carbon. On traditional Mac OS you will have to
continue using the calls you mention above. You can't directly link
to the Open Transport shared libraries if you're a Carbon
application, so you'll have to use some sort of dynamic linking or
plug-in technology.
On Mac OS X things get much uglier. Let's start with the easy stuff.
You won't need to call PSetSelfSend on Mac OS X because self sending
is always enabled. However, to send ATP requests and receive their
results, you'll have to use the AppleTalk framework. This framework
is not supported by Apple. We maintain the framework for our own
internal use and encourage developers not to use it, however, for
cases like yours there may be no choice (see below). Bug fixes in
the framework are limited to those that we have to do to meet our
internal needs. There is no official documentation or headers. You
can get unsupported documentation and headers from the AppleTalk
project in Darwin.
<
http://www.opensource.apple.com/darwinsource/Current/index.html>
[This will require an APSL <
http://www.opensource.apple.com/apsl/> account.]
In addition, the framework can only be called from Mach-O. If you're
targetting just Mach OS X, this shouldn't be a problem: simply build
Mach-O. However, if you want a single binary that runs on both
platforms, you'll have to build a CFM application that dynamically
loads your Mach-O plug-in that in turn talks to the framework.
The QISA sample code is a modern example of how to build a CFM
application with a CFM plug-in for traditional Mac OS-specific code
and a Mach-O plug-in for Mac OS X-specific code.
<
http://developer.apple.com/samplecode/Sample_Code/Networking/QISA.htm>
* * *
This miserable story is the reason why our Legacy Networking
Technologies page says:
AppleTalk - New code should not support AppleTalk. Many of the
advantages of AppleTalk are now available on TCP/IP courtesy of
Rendezvous.
-- <http://developer.apple.com/networking/legacy.html>
You should investigate why you're using ATP. If you're talking to an
embedded hardware device (something like a LaserWriter), you have no
choice; you have to follow the route outlined above if you want a Mac
OS X product. OTOH, if you're talking to a software entity, you may
be better off updating the software to use TCP/IP or, if the software
already supports both AppleTalk and TCP/IP, dropping the AppleTalk
support in the Mac OS X product. This would get you using
technologies that have a future.
If you'd like to post some more details of your product, I can offer
some advice as to how best to move it to TCP/IP.
S+E
--
Quinn "The Eskimo!" <
http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.