Technical Note TN2071

Porting Command Line Unix Tools to Mac OS X

CONTENTS Finding More Information Evolution of Mac OS X General Porting Choosing a Compiler Compiler Flags Shared Libraries, Bundles and Linker Two-Level and Flat Namespace Multiply Defined Symbols Header Files and Frameworks Predefined Macros Endian Issues Thread Handling Internationalization Device Drivers Audio Video Authorization Services References

Introduction This document offers insight into Mac OS X[1] or developers bringing command line UNIX[2] based applications to Mac OS X. It is for developers who are comfortable with the details of programming in traditional UNIX development environments. It is not designed for UNIX users. It provides the background needed to understand the Mac OS X operating system. It touches on some of the design decisions, and it provides a listing and discussion of some of the main areas that you should investigate when bringing UNIX applications to Mac OS X. It also points out some of the advanced features of Mac OS X not available in traditional UNIX applications that you can add to your ported applications. This document is an overview, not a tutorial. In many regards it is a companion to the more extensive Inside Mac OS X: System Overview[3], but with a bias toward the UNIX developer. It will help answer questions about the platform as a whole, as well as specific questions pertaining to bringing a UNIX applications to Mac OS X 10.2.x. You will find a list of APIs that are not supported in Mac OS X, along with suggested alternatives. This document also gives you some tips that will make application porting process faster, easier, and more efficient. [Sep 03, 2003]

Finding More Information

Developer documentation can be found at Apple's developer web site[6]. This site contains reference, conceptual, and tutorial material related to development on Mac OS X. The Mac OS X Developer Tools[7] CD includes a snapshot of the documentation, which is installed in /Developer/Documentation. The manual pages are also included with the Mac OS X Developer Tools.

Apple hosts an extensive array of mailing lists. These are available to public for subscription and searching at lists.apple.com. The unix-porting[8] list is highly recommended. The darwin-development[9] and darwinos-users[10] lists also offer much help but are less specific to the task of porting. Archives[11] of these lists are available at the web site as well.

In addition to Apple's own resources, many external resources exist. Two recommended web sites are O'Reilly's Mac DevCenter[12], and Stepwise[13].

Evolution of Mac OS X

Berkeley Software Distribution (BSD)

Part of the history of Mac OS X goes back to Berkeley Software Distributions (BSD)[14] UNIX of the early seventies. Specifically, Mac OS X is based in part on BSD 4.4 Lite. On a system level, many of the design decisions are made to align with BSD-style UNIX systems. Most libraries and utilities are from FreeBSD[15], but some are derived from NetBSD[16]. For future development, Mac OS X has adopted FreeBSD as a reference code base for BSD technology. Work is ongoing to synchronize all BSD tools and libraries more closely with the FreeBSD-stable branch.

Mach

Although Mac OS X must credit BSD for most of the underlying levels of the operating system, Mac OS X also owes a major debt to Mach. The kernel is heavily influenced in its design philosophy by Carnegie Mellon's Mach project[17]. The kernel is not a pure micro-kernel implementation, since the address space is shared with the BSD portion of the kernel and the I/O Kit.

Mac OS X and Darwin

The word Darwin[18] is often used to refer to Mac OS X. In fact, in some circles Mac OS X itself is rarely mentioned at all. It is important to understand the distinction between the two, how they are related and how they differ.

Darwin is the core of the Mac OS X operating system. Although it can stand alone as an independent operating system, it includes only a subset of the features available in Mac OS X as a whole.

Great Extras

• Quartz Extreme[19] - Mac OS X's new 2D drawing API is based on the Postscript/PDF drawing model and provides full support for transparency and anti-aliasing, multiple color spaces, import and export of PDF, plus built-in ICC color management.
• OpenGL[20] - Mac OS X supports the industry standard OpenGL 3D graphics architecture accelerated by nVidia and ATI graphics adaptors.
• QuickTime[21] - Through Mac OS X, developers can access QuickTime's complete multimedia architecture including Flash 4 Support, Cubic VR, RTP/RTSP video streaming, MPEG support, and more.
• International Technologies[22] - Developers can localize their applications into double byte languages quickly and easily using Mac OS X's support for Unicode.
• CUPS[23] - The Common UNIX Printing System ("CUPS") is a cross-platform Open Source printing solution for UNIX environments, and will be used as a portable printing layer for Darwin and Mac OS X. CUPS is based on the Internet Printing Protocol and provides both System V and BSD command-line printing services for PostScript and raster printers.

General Porting

Porting is a process of bringing software written for one platform to an other platform. It sometime requires rewriting portions of software and/or making slight modification to source code to make it run in the new environment.

Why Port?

A seasoned UNIX developer recognizes that no matter how similar two UNIX-based operating systems are, there are always details that sets one apart from another. There are many flavors of UNIX based systems available, and not all of them offer the same set of tools and architecture.

This section highlights some of the key areas that you should be aware of when it comes to compiling your code base for Mac OS X. It notes important details about compiler flags, as well as giving you some insight into how to link different parts of your code in Mac OS X. Many of these topics are covered more extensively in other resources as noted.

Before beginning the basic port of your code to Mac OS X, you need to make sure that you have the required tool set for the task. You also need to be aware of what is and is not available to you by default.

Choosing a Compiler

Mac OS X 10.2.x ships with two different compilers and their corresponding tool chains. The default compiler is based on gcc 3.1. A secondary compiler based on gcc 2.95.2 is also provided.

You should always try to compile your software using gcc 3.1, since future tool chains will be based on gcc version 3.1 or later.

If you run into a problem that looks like a compiler issue, the command sudo gcc_select 2 will change the default compiler to gcc 2.95.2. You can change it back at any time by typing sudo gcc_select 3. This should be treated as a last resort. If possible, you should try to get gcc 3.1 to compile your application by specifying different compiler flags.

Along with standard UNIX development tools, Apple also provides its own GUI development environment called Project Builder (PB)[24] and Interface Builder (IB)[25]. These tools make development on Mac OS X easier so you can concentrate on your code rather then issues related to development tools. It is strongly recommended that you use these tools. These tools are free and part of Mac OS X.

Compiler Flags

Here is a list of some of the common compiler flags to be aware of.

-ObjC, -ObjC++

These are similar in effect to -x objective-c and -x objective-c++, but affect only the choice of compiler for files already identified as source files.

-faltivec

Enable the AltiVec language extensions, as defined in Motorola's AltiVec PIM. This includes the recognition of vector and pixel as (context-dependent) keywords, the definition of built-in functions such as vec_add, and other extensions.

Note: Unlike the option -maltivec, the extensions do not require the inclusion of any special header files.

-fconstant-cfstrings

Enable the automatic creation of a CoreFoundation-type constant string whenever a special built in __builtin__CFStringMakeConstantString is called on a literal string.

-fpascal-strings

Allow Pascal-style string literals to be constructed.

-fcoalesce

Coalesce duplicated functions and data. The linker will discard all but one, saving space. Enabled by default.

-fweak-coalesced

Use the new OS X weak_definitions section attribute for coalesced items. A single normal definition will be chosen by the linker over any number of weakly-coalesced ones.

-fno-rtti

Disable generation of information about every class with virtual functions for use by the C++ runtime type identification features (dynamic_cast and typeid). If you don't use those parts of the language, you can save some space by using this flag. Note that exception handling uses the same information, but it will generate it as needed.

-shared

This option is not supported on Mac OS X. Instead use -dynamic option for the linker.

--dump-pch name

Dump the state of the compiler into a directory named name, after processing all the other arguments. This is useful for creating precompiled headers.

--load-pch name

Restore the state of the compiler from the directory name before processing the other arguments. The net effect is similar to -include, but it happens more quickly.
For instance if the file myprefix.c includes various headers that are useful to all files in your program, you can do

gcc --dump-pch foo -c myprefix.c gcc --load-pch foo myfile1.c gcc --load-pch foo myfile2.c gcc --load-pch foo myfile2.c ...

-findirect-virtual-calls

Do not make direct calls to virtual functions; instead, always go through the vtable.

-fapple-kext

Alter vtables, destructors, and other implementation details to more closely resemble the GCC 2.95 ABI. This allows Darwin kernels built using older compiler to load kernel extensions.

-fcoalesce-templates

Mark instantiated templates as coalesced: the linker will discard all but one, thus saving space.

-Wpragma-once

Warn about the use of #pragma once.

-Wextra-tokens

Warn about extra tokens at the end of preprocessor directives.

-Wmost

This is equivalent to -Wall -Wno-parentheses.

-Wnewline-eof

Warn about files missing a newline at the end of the file.

-Wno-altivec-long-deprecated

Do not warn about the use of the deprecated long keyword in AltiVec data types.

-Wno-long-double

Inhibit warning if the long double type is used.

-dependency-file

When used with -M or -MM, specifies a file to write the dependencies to. If no -MF switch is given the preprocessor sends the rules to the same place it would have sent preprocessed output.

-no-c++filt

By default all linker diagnostic output is piped through c++filt. This option suppresses that behavior.

One of the standard libraries bypassed by -nostdlib and -nodefaultlibs is libgcc.a, a library of internal subroutines that GCC uses to overcome shortcomings of particular machines, or special needs for some languages.

In most cases, you need libgcc.a even when you want to avoid other standard libraries. In other words, when you specify -nostdlib or -nodefaultlibs you should usually specify -lgcc as well. This ensures that you have no unresolved references to internal GCC library subroutines. (For example, __main, used to ensure C++ constructors will be called.)

-malign-mac68k, -malign-power, -malign-natural

The option -malign-mac68k causes structure fields to be aligned on 2-byte boundaries, in order to be compatible with m68k compiler output. The option -malign-power is the standard alignment mode for the PowerPC. The option -malign-natural is an extension of PowerPC alignment that aligns larger data types such as doubles on their natural boundaries.

-mdynamic-no-pic

On Mac OS X systems, compile code so that it is not re-locatable, but its external references are re-locatable. The resulting code is suitable for applications, but not shared libraries.

-mlong-branch

On Mac OS X systems, compile calls to use a 32-bit destination address. This is to support kernel extensions, which may load anywhere within the kernel address space.

Shared Libraries, Bundles and Linker

The Mac OS X kernel supports different mechanisms than some other UNIX systems to handle shared libraries. The implementation of shared libraries and bundles, known as loadable modules in other systems, is different. You must take special steps if your application uses shared libraries. Most other UNIX systems, such as Linux[27] and Solaris[28], treat bundles and shared libraries the same, but on Mac OS X they are not same.

Many applications being ported to Mac OS X utilize APIs such as dlopen, dlgets, and dlclose these are not supported on Mac OS X. Below are listed these APIs along with some alternative APIs or suggestions that will allow port your application to Mac OS X.

If you decide to move to Apple's dyld format for dynamic libraries and bundles, here are alternatives, don't simply swap functions; make sure to appropriately adjust your code to handle the different data types.

dlopen

You can emulate the behavior of dlopen yourself, using the existing dyld API NSCreateObjectFileImageFromFile to create and return a NSObjectFileImage. This NSObjectFileImage can then be loaded into a task with _dyld_debug_task_from_core to determine what libraries were loaded and which modules were linked.

For example, if your code contains something similar to:

const char *filename = argv[1]; void *handle = dlopen(filename, RTLD_NOW);

You should replace it using the following:

const char *filename = argv[1]; NSObjectFileImage *fileImage; NSModule handle; NSObjectFileImageReturnCode *returnCode = NSCreateObjectFileImageFromFile(filename, &fileImage); if(returnCode == NSObjectFileImageSuccess) { handle = NSLinkModule(fileImage,filename, NSLINKMODULE_OPTION_RETURN_ON_ERROR | NSLINKMODULE_OPTION_PRIVATE); NSDestroyObjectFileImage(fileImage); if (handle) { /* do whatever else your code does *

dlclose

dlclose disassociates the handle made available by dlopen. In order to have the same effect in NSCreateObjectFileImageFromFile, you should use NSDestroyObjectFileImage. This API takes a NSObjectFileImage as its parameter, which is created by the API NSCreateObjectFileImageFromFile.

For example, if your code contains something similar to:

int result = dlclose(handle);

You should replace it using the following:

DYLD_BOOL result = NSUnlinkModule(handle, 0);

This is an easy transition as long as dlopen was called before dlclose is called.

dlerror

Use the option NSLINKMODULE_OPTION_RETURN_ON_ERROR in NSLinkModule to determine whether an error occurred while loading a module. Then, to get the error information, you can use the NSLinkEditError API.

For example, if your code contains something similar to:

printf("%s\n", dlerror());

You should replace it using the following:

int * null; NSLinkEditErrors* c; const char ** errorMsg; NSLinkEditError(c, null, (const char**)lpLibFileName, errorMsg); printf("%s\n", errorMsg);

dlsym

The API NSAddressOfSymbol has the same functionality as dlsym. NSAddressOfSymbol takes a NSSymbol, which is a void *, and return the address of the symbol.

Note: NSAddressOfSymbol does not take a second parameter as dlsym does.

For example, if your code contains something similar to:

void *address = dlsym(handle, symbol);

You should replace it using the following:

NSSymbol nssym = NSLookupSymbolInModule(handle, symbol); void *address = NSAddressOfSymbol(nssym);

Two-Level and Flat Namespace

Two-level and flat namespaces refer to how references to symbols in dynamic libraries are resolved to a definition in specific dynamic library.

When a program is using images built with two-level namespace there may be different global symbols with the same name being used by different images in the program (this is now the default starting with Mac OS X 10.1).

When a program is using all flat namespace images then only one global symbol for each global symbol name is used by all images of the program.

-twolevel_namespace

Specifies the output to be built as a two-level namespace image. This option can also be specified by setting the environment variable LD_TWOLEVEL_NAMESPACE.

Note: Use -multiply_defined suppress to stop the warnings regarding multiply defined symbols.

-flat_namespace

Specifies the output to be built as a flat namespace image. This was the default in MacOS X 10.0.

-force_flat_namespace

Specifies the executable output to be built and executed treating all its dynamic libraries as flat namespace images. This marks the executable so that the dynamic link editor knows to treat all dynamic libraries as flat namespace images when the program is executed.

Multiply Defined Symbols

If there are multiply defined symbols in the object files being linked into the output file being created, this always results in a multiply defined symbol error.

Header Files and Frameworks

Standard header files are located in /usr/include. Frameworks are similar to shared libraries; they combine headers, libraries, etc into a single folder; they are stored in different locations, and therefore must be searched for differently.

Apple-supplied frameworks are located in /System/Library/Frameworks/. Within each directory, you will find a directory called Headers where public header files can be found. Each header file contain several APIs.

You can install your frameworks in /Network/Library/Framework, /Library/Framework, or ~/Library/Frameworks, depending on you want to expose your frameworks.

If you wish to use an API that is declared in one of the Framework header files, you can use the flag -framework APIName -framework APIName2 -framework APIName3 ... at compilation time. Make sure to place this flag after the .o files, since Mac OS X uses a single-pass linker.

-(int)beginLoadingImageDataForClient:(id )client

#include <AddressBook/ABImageLoading.h>

Predefined Macros

As specified in Apple's developer GNU C Preprocessor documentation[43], the following macros are predefined in Mac OS X:

__OBJC__

This macro is defined when you compile Objective-C .m files or Objective-C++ .mm files, or when you override the file extension with -ObjC or -ObjC++ flags.

__ASSEMBLER__

This macro is defined when compiling .s files.

__NATURAL_ALIGNMENT__

This macro is defined on systems that use natural alignment. When using natural alignment, an int is aligned on sizeof(int) boundary, a short int is aligned on sizeof(short) boundary, and so on. It's defined by default when you're compiling code for the PowerPC, SPARC, and HPPA. It's not defined when you use the -malign-mac68k compiler switch.

__STRICT_BSD__

This macro is defined if the -bsd switch was specified when GNU C was invoked.

__MACH__

This macro is defined if Mach system calls are supported.

__APPLE__

This macro is defined in any Apple computer.

__APPLE_CC__

This macro is set to an integer that represents the version number of the compiler. This lets you distinguish, for example, between compilers based on the same version of GCC, but with different bug fixes or features. Larger values denote later compilers.

__BIG_ENDIAN__

This macro sets the target architecture to be a most significant bit. See the Endian Issues sections for more details.

Note: To define a section of code to be compiled on Mac OS X system you should define a section using __APPLE__ with __MACH__ macros. The macro __UNIX__ is not supported in Mac OS X.

Endian Issues

Multi-byte data fields can be referenced a couple of ways in memory. One is known as big-endian, which consists of field addresses pointing to the most significant byte (MSB) while the second, known as little-endian, consists field addresses pointing to the least significant byte (LSB).

Apple's PowerPC processor uses big-endian (MSB) addressing, while some other systems use little-endian (LSB). Utility functions for byte flipping can be found in the endian.h header file.

Thread Handling

UNIX applications being ported to Mac OS X will likely to use POSIX threads. Read the Mac OS X Threading Architectures[29] document to understand how threads work in Mac OS X.

Mac OS 10.2.x has increased support for POSIX APIs, which will enable an easier transition for most developers porting to Mac OS X. The supported POSIX threading APIs are included in pthread.h.

The POSIX thread functions are summarized in this section in the following groups:

• Thread Routines
• Attribute Object Routines
• Mutex Routines
• Condition Variable Routines
• Read/Write Lock Routines
• Per-Thread Context Routines
• Cleanup Routines

For those developers who have ported an UNIX application to Mac OS X 10.1.x or plan to do so, note that pthread_kill and other pthread API have been added to Mac OS X 10.2, and are included in pthread.h and signal.h. pthread_kill was not supported in Mac OS X prior to Mac OS X 10.2.

Internationalizaton

Wide-character wchar is not supported on Mac OS X, instead you should use the APIs available in the CoreFoundation's CFString.h, such as CFStringGetSystemEncoding, CFStringCreateCopy, CFStringCreateMutable, etc. See CFString.h for the entire list of supported APIs.

In Mac OS X, Internationalizaton of strings can be done using Unicode-based strings. The Unicode[30] standard is defined by the Unicode Consortium[31], an international standards organization.

kCFStringEncodingMacRoman
kCFStringEncodingWindowsLatin1
kCFStringEncodingISOLatin1
kCFStringEncodingNextStepLatin
kCFStringEncodingASCII
kCFStringEncodingUnicode
kCFStringEncodingUTF8
kCFStringEncodingNonLossyASCII

To fully understand the capability of the CoreFoundation StringServices, please read the reference documentation[32].

Device Drivers

Device Drivers in Mac OS X are implemented differently from other systems. When porting your application that uses device drivers, you must create new device drivers for Mac OS X.

To create a new device driver you must use the I/O Kit. The I/O Kit is a collection of system frameworks, libraries, tools, and other resources for creating device drivers in Mac OS X. An I/O Kit device driver is a special type of kernel extension (KEXT), which enables the kernel to handle your device.

In many cases, devices can be accessed indirectly from userland processes without a need to write kernel drivers. We encourage this because it keeps your code out of the kernel whenever possible.

See the documentation[33] that shows you step-by-step how to create device drivers using Project Builder.

Audio

In order to port your audio application, you must understand the fundamental Audio architecture used by Mac OS X, and rewrite your code using our Core Audio APIs.

If you are porting an application that uses Linux's soundcard.h or Solaris's audioio.h, you should be able to find similar APIs in CoreAudio.h. Mac OS 10.2.x has added to the Core Audio architecture so that simple functionality can easily be done by simply using the Core Audio Framework. However, if your application uses lower-level APIs that deal with hardware, input or output, you will have to understand the entire architecture, which involves several frameworks.

We highly recommend that you read the Core Audio Developer Documentation[34] before porting your application.

Video

If you are porting a video application, you should use the QuickTime APIs, which are included in the QuickTime framework. The QuickTime framework will automatically call some of the audio APIs to guarantee that the audio from the video is ported along with the video. If you are not familiar with QuickTime and its APIs, please read the QuickTime Developer Documentation[35].

Authorization Services

When porting an application that uses authorization services, you must use the APIs located in the Security Services[36] framework. When using the Authorization APIs at the commnd line level, the APIs will ignore the GUI and prompt for password at the command-line.

Authentication handles supported in Linux such as auth_destroy, authnone_create, authunix_create, authunix_create_default are supported in Mac OS X through rpc, see manual page for rpc for more information.

Read the Authorization Services[37] document to understand how to use access control in Mac OS X. Also see the sample code[38] that demonstrates how to properly use the Authorization Services APIs.

Header Files

alloc.h

This file does not exist on Mac OS X, but the functionality does exist. You can simple include stdlib.h or create own version of the file using the following code.

#ifndef _ALLOCA_H #undef __alloca /* Now define the internal interfaces. */ extern void *__alloca (size_t __size); #ifdef __GNUC__ # define __alloca(size) __builtin_alloca (size) #endif /* GCC. */ #endif

ftw.h

The API ftw traverses through the directory hierarchy and calls a function to get information about each file. In Mac OS X, use the API fts_open to get a handle on the file hierarchy, use fts_read to get information on each file, and use fts_children to get a link to a list of structures containing information about files in a directory.

Instead Mac OS X uses fts which is very similar to ftw.h. However, there isn't a function similar to ftw in fts.h. You must use fts_open,fts_children, and fts_close to implement file traverse. For example, in order to get a description of each file located in /usr/include using fts.h, then the code would be as follow:

/* assume that the path "/usr/include" has been passed through argv[3]*/ fileStruct = fts_open(&argv[3], FTS_COMFOLLOW, 0); dirList = fts_children(fileStruct, FTS_NAMEONLY); do { fileInfo = fts_read(dirList->fts_pointer); /* at this point, you would be able to extract information from the FTSENT returned by fts_read */ fileStruct = fts_open(dirList->fts_link->fts_name, FTS_PHYSICAL, (void *)result); }while (dirList->fts_link != NULL); ftsResult = fts_close(fileStruct);

See manual page for fts to understand the structures FTSENT, FTS and to understand the macros used in the code. The sample code above shows a very simplistic file traversing. For instance, it is not considering possible subdirectories existing in the directory being searched.

getopt.h

Not supoorted, use unistd.h

lcrypt.h

Not supported, use unistd.h

malloc.h

Not supported, use stdlib.h

mm.h

This header is supported in Linux for memory mapping, but not supported in Max OS X. In Mac OS X, you can use mmap for mapping files into memory. If you wish to map devices, use IOKit.

module.h

Use NSModule as the interface for working with modules and symbols. NSModule is simply a void * defined in the <mach-o/dyld.h> header file. Use the API: NSLinkModule.

msg.h

For information on how to implement message queues, see the Technical Note 1071[39]. The APIs implemented in msg.h are also not supported, such as msgget, msgsnd, msgrcv, and msgctl. The Technical Note mentioned above will help you implement the functionality from these functions.

nl_types.h

Use CoreFoundation[40] localized string[41] to access API.

ptms.h

This header file exists in Linux, but it doesn't in Mac OS X. However, pty is supported in Mac OS X. The implementation process is done very differently from Linux. See the full description of the pty implementation in manual page for pty.

stream.h

This header file is not present on the system. For file streaming use iostream.h

stropts.h

Not supported.

swapctl.h

Mac OS X does not support this header file. You can use the header file swap.h to implement swap functionalities. The swap.h header file contains a large number of APIs that can be used for swap-tuning control.

termio.h

This header file has become obsolete, and has been replaced by termios.h, which is part of the POSIX standard. These two header files are very similar, however, the termios.h does not include the same header files as termio.h. Thus, you should make sure to look directly at the termios.h to make sure it does what your application needs.

utmpx.h

Not supported, use utmp.h instead.

values.h

Not supported, use limits.h

wchar.h

Not supported, use CoreFoundation[40] localized string API.

wordexp.h

Not supported on Mac OS X.

Functions

btowc, wctob

Mac OS X does not currently support wchar, instead you deal with international strings by using CFString, which is part of the CoreFoundation[40] framework. Some of the APIs available in the CoreFoundation CFString.h are CFStringGetSystemEnconding, CFStringCreateCopy, CFStringCreateMutable, etc. See CFString.h for the entire list of supported APIs.

catopen, catgets, catclose

nl_types.h is not supported, thus, these functions are not supported. These functions gives access to localized strings. There is no direct equivalent in Mac OS X. Typically in Mac OS X programs, including command line tools, use CoreFoundation to access localized resources. For example, see CFBundleCopyLocalizedString[42].

crypt

The crypt function performs password encryption, based on the NBS Data Encryption Standard (DES). Additional code has been added to deter key search attempts.

This function takes in the same arguments, and return the same value type as the Linux crypt. Mac OS X's version of the function crypt behaves very similar to the Linux version, except that it encrypts a 64-bit constant rather than a 128-bit constant. This function is located in the unistd.h header file rather than lcrypt.h.

Note: The linker flag -lcrypt is not supported in Mac OS X.

dysize

This API is not supported in Mac OS X. Its calculation for leap year is based on:

(year) %4 == 0 && ((year) %100 != 0 || (year) % 400 == 0)

You can either use this code to implement this functionality, or you can use any of the existing APIs in time.h to do something similar.

ecvt, fcvt

Not supported in Mac OS X. Use sprintf, or snprintf instead.

fcloseall

This function is an extension to fclose. Even though Mac OS X supports fclose, fcloseall is not supported. You can use fclose to implement fcloseall: Assuming there is an array of FILE *streams, called fileNamePtr[i]:

for(i = 0; i < MAXSTREAMS; i++) fclose(fileNamePtr[i]);

getmntent, setmntent, addmntent, endmntent, hasmntopt

Mac OS X uses the POSIX standard to manage file descriptors. These functions are not supported.

poll

This API is not supported in Mac OS X, instead, the function select is used. The select function does synchronous I/O multiplexing, similar to poll. This API is located in the following header files: <sys/types.h>, <sys/time.h>, <unistd.h> The select API is defined as follow:

int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

The behavior of select is not exactly the same as poll, so you will have to alter your code. select gives you a number of macros to manipulate the file descriptor returned, which is done differently in poll

An alternative to avoid changing your code is to use a wrapper around select, such as fakepoll.h. Simply include the file fakepoll.h in your code, and the library does the rest of the work. See sealiesoftware.com/fakepoll.h for more information about fakepoll.h.

Note: fakepoll.h is a third-party library and not supported by Apple.

sbrk, brk

The brk and sbrk functions are historical curiosities left over from earlier days before the advent of virtual memory management. Even though they are present on the system, their use is not recommended.

shmget

This API is supported but its use is not recommended. shmget has a limited memory blocks allocation. When several applications use shmget, this limit may change and cause problems for the other applications. We recommend the use of mmap for file mapping into memory.

swapon, swapoff

This API is not supported in Mac OS X. The equivalent to it in Mac OS X is macx_swapon and macx_swapoff.

wordexp, wordfrees

Not supported in Mac OS X.

Utilities

ldd

The ldd command is not available in Mac OS X; however, you can use the command otool -L to get the same functionality that ldd does. The otool command displays specified parts of object files or libraries. The option -L displays the name and version numbers of the shared libraries that the object file uses. To see all the existing options, see the manual page for otool.

lsmod

lsmod is not available on Mac OS X, but other commands exist which offer similar functionality. If you simply want information, then kmodstat will be the most helpful. kmodstat prints statistics about currently loaded drivers and other kernel extensions. Other related functions are listed below:

kmodload

Loads the kernel module for a device driver or other kernel extensions.

kmodunload

Unloads the kernel module for a device driver or other kernel extensions.

kmodsyms

Creates a statically linked symbol file for remote debugging.

References

Apple's Developer Connection Documentation

• Darwin: (developer.apple.com/darwin)
• UNIX Porting: (developer.apple.com/documentation/Darwin/GettingStarted/PortingUNIX)
• Kernel Programming: (developer.apple.com/documentation/Darwin/General/KernelProgramming)
• IOKit Fundamentals: (developer.apple.com/documentation/Darwin/General/IOKitFundamentals)
• Compiler Tools: (developer.apple.com/documentation/ReleaseNotes/CompilerTools.html)
• Differences between Mac OS X and BSD: (developer.apple.com/documentation/Darwin/General/KernelProgramming/BSD/chapter_11_section_3.html)
• Moving Your Code to Mac OS X: (developer.apple.com/technotes/tn/tn2003.html)
• Threading Architectures (developer.apple.com/technotes/tn/tn2028.html)
• Key-based Authentication and Encryption: (developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/security/chapter_3_section_8.html)

Third Party Porting Documentation

• Fink Project: (fink.sourceforge.net/doc/porting)
• Darwin Porting Notes: (gnu-darwin.sourceforge.net/porting.html)

URLs

1. Mac OS X: (www.apple.com/macosx/)
2. UNIX: (www.unix.org/)
3. Inside Mac OS X: System Overview: (developer.apple.com/documentation/macosx/Essentials/devessentials.html)
4. OpenDarwin: (www.opendarwin.org)
5. Fink: (fink.sourceforge.net)
6. Apple's developer Web Site: (developer.apple.com/techpubs)
7. Mac OS X Developer Tools: (developer.apple.com/tools/macosxtools.html)
8. unix-porting: (lists.apple.com/mailman/listinfo/unix-porting)
9. darwin-development: (lists.apple.com/mailman/listinfo/darwin-development)
10. darwinos-users: (lists.apple.com/mailman/listinfo/darwinos-users)
11. Lists Archives: (search.lists.apple.com)
12. O'Reilly's Mac DevCenter: (www.macdevcenter.com)
13. Stepwise: (www.stepwise.com)
14. Berkeley Software Distributions (BSD): (www.bsd.org)
15. FreeBSD: (www.freebsd.org)
16. NetBSD: (www.netbsd.org)
17. Carnegie Mellon's Mach Project: (www-2.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/www/mach.html)
18. Darwin: (developer.apple.com/darwin)
19. Quartz Extreme: (developer.apple.com/quartz)
20. OpenGL: (developer.apple.com/opengl)
21. QuickTime: (developer.apple.com/quicktime)
22. International Technologies: (developer.apple.com/intl)
23. CUPS: (developer.apple.com/printing)
24. Project Builder: (developer.apple.com/tools/projectbuilder)
25. Interface Builder: (developer.apple.com/tools/interfacebuilder)
26. Apple Development Tools: (developer.apple.com/tools)
27. Linux: (www.kernel.org)
28. Solaris: (wwws.sun.com/software/solaris)
29. Mac OS X Threading Architectures: (developer.apple.com/technotes/tn/tn2028.html)
30. Unicode: (www.unicode.org/standard/WhatIsUnicode.html)
31. Unicode Consortium: (www.unicode.org)
32. CoreFoundation StringServices: (developer.apple.com/documentation/CoreFoundation/Reference/CFStringRef/index.html)
33. Creating a Device Driver With Project Builder: (developer.apple.com/documentation/DeviceDrivers/)
34. Core Audio Developer Documentation: (developer.apple.com/audio/coreaudio.html)
35. QuickTime Developer Documentation: (developer.apple.com/documentation/quicktime/quicktime.html)
36. Security Services: (developer.apple.com/security)
37. Authorization Services: (developer.apple.com/documentation/macosx/CoreTechnologies/securityservices/authorizationservices/authservices.html)
38. Authorization Sample Code: (developer.apple.com/samplecode/Sample_Code/Security/AuthSample.htm)
39. Working With Multiprocessing Services (TN 1071): (developer.apple.com/technotes/tn/tn1071.html)
40. CoreFoundation: (developer.apple.com/documentation/CoreFoundation/Reference/index.html)
41. CFString Reference: (developer.apple.com/documentation/CoreFoundation/Reference/CFStringRef/index.html)
42. CFBundleCopyLocalizedString: (developer.apple.com/documentation/CoreFoundation/Reference/CFBundleRef/index.html)
43. GNU C Preprocessor (developer.apple.com/documentation/DeveloperTools/gcc3/cpp/index.html)