Carbon


Open Transport

Apple has identified the Open Transport functions, structures, and constants that are most commonly used by a large number of applications and by Mac OS system software. Carbon supports this key subset of the current interface.

For more information about Open Transport, you should visit the web site

< http://devworld.apple.com/dev/opentransport/ >

which has extensive references to OT documentation and samples. Specifically, you should read Inside Macintosh: Networking with Open Transport, available in HTML and PDF format from the above site.

Carbon supports the following types of Open Transport providers:

• TCP, UDP and Raw IP Endpoints;

• TCP/IP Services Provider and TCP/IP Mapper Provider (i.e. DNR protocol);

• DDP endpoints;

• AppleTalk Services Providers and AppleTalk Mappers (i.e. ZIP and NBP protocols);

• OT/PPP endpoint.

All other types of providers are not supported by Carbon, including the following:

• ADSP, ATP, ASP and PAP Endpoints;

• Serial endpoint.

You may have to revise your code if it uses Open Transport in one of the following ways:

• Your application uses a function that directly gains access to a network port. Ports are read-only in Carbon. In Mac OS X, code that communicates directly with network interfaces must use the IOKit API.

• Your application uses the transaction-based endpoint feature of Open Transport. This feature will not be supported in Carbon. Removal of this capability should affect only users of AppleTalk protocols such as ASP. Note that the Mac OS does not currently have a native ASP implementation.

• Your application uses Open Transport’s XTI interfaces or UNIX(R) stream interfaces. Carbon will not support these interfaces. Note however that you can obtain similar functionality using supported high-level functions.

• With Carbon, one cannot assume that Open Transport deferred tasks and notifiers procedure run at deferred task level; on Mac OS X they may be preempted by the main event loop or another Mac OS thread. So it is crucial to always use atomic operations to access data shared betweeen deferredtasks and notifiers and main system task.

An important change for Carbon applications using Open Transport is the addition of client context parameters to a number of OT functions. Each client of Open Transport now has its own client context so that OT can track resources it allocates on behalf of the client. An OT client means an application or a shared library. OT resources are objects like endpoints, timer tasks, and blocks of memory. "See Understanding Open Transport Asset Tracking" at

< http://developer.apple.com/technotes/tn/tn1173.html/ >

to learn more about Open Transport resources management.

Carbon introduces a new type, OTClientContextPtr, that represents the OT client context. This new type is passed as an extra parameter to functions that allocate OT resources. Before Carbon, the determination of the OT client context was performed by the Open Transport static libraries that you linked to your application. Because the determination of the OT client context is now explicit, the same Carbon binary can run on MacOS 8 and MacOS X, and you do not have to link your application to the static libraries.

InitOpenTransportinContext replaces InitOpenTransport. It functions identically except that it also takes a client context pointer and a flags parameter indicating whether OT is being initialized for an application or a shared library. When your application or shared library is done using Open Transport you should call CloseOpenTransportInContext to dispose of the Open

Transport resources allocated for the client.

The following routines now take a client context:


CloseOpenTransportInContext

OTAllocInContext

OTAllocMemInContext

OTAsyncOpenAppleTalkServicesInContext

OTAsyncOpenEndpointInContext

OTAsyncOpenInternetServicesInContext

OTAsyncOpenMapperInContext

OTCreateDeferredTaskInContext

OTCreateTimerTaskInContext

OTOpenAppleTalkServicesInContext

OTOpenEndpointInContext

OTOpenInternetServicesInContext

OTOpenMapperInContext

As a convenience, applications may pass a null pointer to these routines and Open Transport will use the context that was passed to InitOpenTransport. However, shared libraries must always pass a valid OTClientContextPtr.

In addition, in order to keep your application source code

compatible with pre-Carbon systems, you may define the C preprocessor constant OTCARBONAPPLICATION to 1 to use the old routine names without the "InContext" suffix.

Carbon applications must pass UPPs instead of proc pointers for Open Transport callback routines. There are three new functions to create these UPPs:


OTNotifyUPP replaces OTNotifyProcPtr

OTProcessUPP replaces OTProcessProcPtr

OTListSearchUPP replaces OTListSearchProcPtr

There are corresponding routines to allocate and free those UPPs:


NewOTNotifyUPP

DisposeOTNotifyUPP

NewOTProcessUPP

DisposeOTProcessUPP

NewOTListSearchUPP

DisposeOTListSearchUPP

The following routines have been modified to take UPPs instead of proc pointers.

Routines taking an OTNotifyUPP:


OTAsyncOpenAppleTalkServicesInContext

OTAsyncOpenInternetServices InContext

OTInstallNotifier

OTAsyncOpenEndpointInContext

OTAsyncOpenMapperInContext

Routines taking an OTProcessUPP:


OTCreateTimerTaskInContext

OTCreateDeferredTaskInContext

Routines taking an OTListSearchUPP:


OTFindLink

OTFindAndRemoveLink


© 2000 Apple Computer, Inc. (Last Updated 6/29/2000)