| Report for: Matlab 5.2 | Report date: 1/15/2000 |
| File Creator: MATL | Data gathered by analyzer version: 1.3 |
| File Type: APPL | Data gathered on: 1/15/2000 |
Supported with ModificationsCarbon CoreMemory ManagerCarbon will support the majority of the Memory Manager programming interface. Changes will primarily affect applications that use zones, system memory, or temporary memory. For example, temporary memory allocations in Mac OS X will be allocated in the application’s address space. As a result, calling TempNewHandle will effectively be the same as calling NewHandle.
Carbon will not support current functions for accessing the system heap, but Apple will provide new routines to allocate shared and persistent memory. In addition, the virtual memory system in Mac OS X will introduce a number of changes in the addressing model.
By adhering to the following guidelines, you can increase your application’s compliance with Mac OS X memory management:
• Try to use memory only within your own application heap. Review the places where you allocate memory in the system heap.
• Do not pass pointers to data among applications through Apple events, Gestalt routines, or other means. For example, don’t share Toolbox data structures between applications, because in Mac OS X, each application will run in its own protected address space.
• Do not use inline, hard-coded addresses.
• Do not modify the zone header to increase the number of master pointer blocks allocated by each call to the MoreMasters function. You should instead call MoreMasters multiple times. Each call to More Masters allocates 128 master pointers. Apple may supply a new version of the MoreMasters function that allows you to specify the number of master pointer blocks to allocate. Note, however, that master pointer blocks do not need to be preallocated or optimized in the Mac OS X environment, so the new function will only benefit Carbon applications running on Mac OS 8.
• Don’t make assumptions about the layout of memory, such as the relative position of data stored in heaps, stacks, and other memory areas.
• Don’t use the DisposePtr or DisposeHandle functions on pointers or handles allocated by Toolbox managers. For example, don’t call the function DisposeHandle on a control allocated by the NewControl function; use DisposeControl instead.
• Because Mac OS X applications will run in a large, protected memory space, memory sizing routines such as MaxMem and FreeMem will work differently than they do now.
MoreMasters
MoreMasters will have a longint parameter for specifying the number of master pointers to allocate in the block. Specifying a number less than 32 will result in 32 master pointers in the allocated block, the current standard allocation.Time Manager
Carbon will fully support the Time Manager. However, the interface for callbacks will change because the current task record is accessible only from 68K code.
The interface for Time Manager callbacks will change, because the task record is currently available only from 68k code.Common OS Services
Process ManagerCarbon will support most of the Process Manager. The exception is the LaunchDeskAccessory function, which is not supported.
Note that some Process Manager functions access a ProcessInfoRec data structure, which contains fields that are no longer applicable in a preemptively scheduled environment (for example, the processLocation, processFreeMem, and processActiveTime fields). Your application should avoid accessing such fields. Changes to the memory model may also affect certain fields.
Some fields in the ProcessInfoRec structure may no longer be applicable.Hardware Interfaces
Device ManagerCarbon does not support the Device Manager as an interface for installing or interacting with device drivers. However, you can continue to use the PBRead and PBWrite functions (and their variants) for reading and writing to open files.
In Mac OS X, code that communicates directly with hardware devices must use the IOKit API. Other types of code that have relied on the Device Manager interface in the past (such as desk accessories) should be converted into applications.
Note: The Serial Driver will be supported through a new set of functions similar to PBOpen, PBControl, PBStatus, etc., but specific to serial communication.
This function is only supported for writing to open files.Human Interface Toolbox
Window ManagerCarbon will support the Window Manager. Be aware, however, that if you use custom window definition procedures (also known as WDEFs), you must compile them as PowerPC-native code. In addition:
• Your application must use the functions defined by the Window Manager whenever it creates and disposes of Window Manager data structures. For example, instead of directly creating and disposing of window records, applications must call such Window Manager functions as GetNewCWindow and DisposeWindow.
• You must revise your application so that it accesses Window Manager data structures only through accessor functions.
• You are encouraged to adopt the standard Mac OS 8 window definition procedures in your application. Applications that use the standard Mac OS 8 window definition procedures inherit the Mac OS 8 human interface appearance. Applications that use custom window definition procedures work correctly, but because custom definition procedures invoke their own drawing routines, Mac OS 8 can’t draw these applications with the current appearance.
Calls InvalWindowRect, which takes a window pointer as an additional parameter.
Calls InvalWindowRgn, which takes a window pointer as an additional parameter.
Calls ValidWindowRect, which takes a window pointer as an additional parameter.
Calls ValidWindowRgn, which takes a window pointer as an additional parameter.
Supported But Not RecommendedHuman Interface ToolboxMenu ManagerCarbon will support the Menu Manager, with the following changes:
• Your application must use the functions defined by the Menu Manager whenever it creates and disposes of Menu Manager data structures. Some applications, for example, create menus by using the Resource Manager function GetResource (instead of the Menu Manager function GetMenu) and dispose of them by calling ReleaseResource instead of DisposeMenu. This practice is not supported in Carbon.
• The MenuInfo structure is opaque in Carbon. You must revise your application so that it accesses Menu Manager data structures only through accessor functions.
• There are several Menu Manager functions that deal with manipulating menu color information tables. Apple recommends that you stop using them. The Appearance Manager generally disregards these color tables and instead uses the colors defined for the current appearance.
• You are strongly encouraged to adopt the standard Mac OS 8 menu definition procedures (also known as MDEFs) in your application. Your menus will then inherit the systemwide appearance and, furthermore, take advantage of other Menu Manager enhancements planned for the future. Note, however, that if you must use custom menu definition procedures, you must compile them as PowerPC-native code.
SetMCEntries
SetMCEntries does nothing, because Appearance Manager doesn’t use color tables.Text and Other International Services
Font ManagerCarbon will support most Font Manager functions. However, applications will no longer have direct access to Font Manager data structures, and you will not be able to access the list of fonts (or the data in those fonts) using the Resource Manager. You may need to modify your application to use new accessor functions when they are available.
You should instead use FMGetFontFamilyFromName.
You should instead use FMGetFontFamilyName.
Unsupported APICarbon CoreFile ManagerWhile Carbon will support most of the File Manager interface, there are a number of significant changes.
You should not access File Manager structures directly if accessor functions for the structure exist. For example, you should call PBGetFCBInfo rather than calling LMGetFCBSPtr and walking the FCB table.
Similarly, you should create file system specification (FSSpec) records using the functions PBMakeFSSpec or FSMakeFSSpec instead of filling in your own structures. File system specification records must contain a volume reference number, a parent directory, and a name. Substituting a working directory for the volume reference number or a full or partial pathname for the name is not supported.
File Manager functions that support MFS (the Macintosh file system) will not be supported in Carbon. These include
• functions, such as OpenWD and GetWDInfo, that manipulate working directories
• functions that identify a file or folder using a volume reference number and pathname but not a parent directory ID. You should use the HFS version of these calls (which use a parent directory ID) instead.
Functions that cannot be called by PowerPC applications (such as PBGetAltAccessSync and PBGetAltAccessAsync) will not be supported.
You should use only documented File Manager interfaces in your application. For example, you should use a documented API call to get low memory information rather than access undocumented low memory global variables or vectors directly.
The default volume format for Carbon will be the Mac OS Extended format; in most cases you will not need to modify your application to gain this volume support.
Carbon does not support many of the File System Manager (FSM) functions defined in the header file FSM.h. FSM plug-ins today often must make assumptions about File Manager data structures that may not be valid in Carbon. In addition, some plug-ins use 68K calling conventions when calling internal File Manager functions. Since the File System Manager was designed for a single-threaded file system, it cannot use the full threading capabilities of Mac OS X.
Create
Use FSpDelete instead.
Use FSpOpenDF (for a data fork) or FSpOpenRF (for a resource fork) instead.
Use FSpGetFInfo instead.
Working directories not supported. Use file system specification (FSSpec) records instead.
Obsolete. Use PBHGetFInfoSync instead.
Obsolete. Use PBHGetVInfoSync instead.
Working directories not supported. Use file system specification (FSSpec) records instead.
Working directories not supported. Use file system specification (FSSpec) records instead.
Obsolete. Use PBHSetFInfoSync instead.
Use FSpSetFInfo instead.
Carbon applications should use HGetVol and HSetVol to get and set the default directory. GetVol and SetVol are no longer supported and working directories are not supported.Low Memory Accessors
Carbon will support most of the accessor functions for low-memory variables. However, you should always avoid using low-memory accessors if there are direct Mac OS Toolbox calls to obtain the same information. For example:
• Use the function TickCount instead of the low-memory accessor function LMGetTicks.
• Use the function FrontWindow instead of the low-memory accessor function LMGetWindowList, when possible.
• Use the function PBGetFCBInfo instead of walking the FCB table with the low-memory accessor function LMGetFCBSPtr.
In general, don’t think of the values returned by low-memory accessor routines as residing in low memory—think of them as information, possibly associated with a specific Toolbox manager, that is returned by the Mac OS. In the future, Apple may supply new functions, distributed among the Mac OS Toolbox managers, for retrieving this information.
Some low-memory accessor functions are likely to become obsolete in Mac OS X. The following Resource Manager-related functions will not be supported:
• LMGetTopMapHndl and LMSetTopMapHndl
• LMGetSysMapHndl and LMSetSysMapHndl
• LMGetCurMapHndl and LMSetCurMapHndl
68K-specific.
You should instead use GetDoubleTime.
You should instead use the new high-level event queue functions provided by the Carbon Event Manager.
You should instead use GetGrayRgn.
Use GetMBarHeight instead. If you are using this function to hide the menu bar, use Hide/ShowMenuBar instead.
Will be replaced by a new API.
You should instead use TickCount.
You should instead use GetDateTime.
The Window Manager port is not supported in Carbon.
You should instead use GetWindowList.
The window list is read-only in Carbon. You should instead use the high-level functions provided by the Window Manager.Memory Management Utilities
While Carbon will support most of the Memory Management Utilities, there are changes to functions that assume a 68K runtime environment.
• Functions that flush caches on 68K processors (such as FlushInstructionCache, FlushDataCache, and FlushCodeCacheRange) will no longer be supported.
• Functions such as SetA5 or SetCurrentA5 will do nothing when running in Mac OS X. However, these functions should work normally when running in Mac OS 8.
• The functions GetMMUMode and SwapMMUMode will not be supported because all PowerPC applications use 32-bit addressing, even if they are not Carbon–compliant.
• The SysEnvirons function will no longer be supported since the Gestalt Manager can provide the same information. You should call the functions FindFolder and Gestalt instead.
Uses working directories. Use FindFolder and Gestalt instead.Memory Manager
Carbon will support the majority of the Memory Manager programming interface. Changes will primarily affect applications that use zones, system memory, or temporary memory. For example, temporary memory allocations in Mac OS X will be allocated in the application’s address space. As a result, calling TempNewHandle will effectively be the same as calling NewHandle.
Carbon will not support current functions for accessing the system heap, but Apple will provide new routines to allocate shared and persistent memory. In addition, the virtual memory system in Mac OS X will introduce a number of changes in the addressing model.
By adhering to the following guidelines, you can increase your application’s compliance with Mac OS X memory management:
• Try to use memory only within your own application heap. Review the places where you allocate memory in the system heap.
• Do not pass pointers to data among applications through Apple events, Gestalt routines, or other means. For example, don’t share Toolbox data structures between applications, because in Mac OS X, each application will run in its own protected address space.
• Do not use inline, hard-coded addresses.
• Do not modify the zone header to increase the number of master pointer blocks allocated by each call to the MoreMasters function. You should instead call MoreMasters multiple times. Each call to More Masters allocates 128 master pointers. Apple may supply a new version of the MoreMasters function that allows you to specify the number of master pointer blocks to allocate. Note, however, that master pointer blocks do not need to be preallocated or optimized in the Mac OS X environment, so the new function will only benefit Carbon applications running on Mac OS 8.
• Don’t make assumptions about the layout of memory, such as the relative position of data stored in heaps, stacks, and other memory areas.
• Don’t use the DisposePtr or DisposeHandle functions on pointers or handles allocated by Toolbox managers. For example, don’t call the function DisposeHandle on a control allocated by the NewControl function; use DisposeControl instead.
• Because Mac OS X applications will run in a large, protected memory space, memory sizing routines such as MaxMem and FreeMem will work differently than they do now.
Used by 68K code.
This routine is not needed by PowerPC-based applications because they can specify a stack size in the cfrg resource.
Mixed Mode Manager
Mac OS X will not run 68K code. However, Carbon will support universal procedure pointers (UPPs) transparently, so you do not have to change them or remove them from your code. You may want to keep Mixed Mode Manager calls in your application to maintain compatibility with the current version of the Mac OS. Mixed Mode Manager calls from Carbon applications running on Mac OS 8 will function normally.
Use a specific UPP disposal routine; e.g., use Dispose ControlDefinitionProc instead of the more general function DisposeRoutineDescriptor.
Applications should use ProcPtrs for their own code and plug-ins, and use the system-supplied UPP creation functions (such as NewModalFilterProc) for Toolbox callback UPPs. You still need to dispose of those UPPs using DisposeRoutineDescriptor, so that any allocated memory can be cleaned up when your application is running on Mac OS 8.Patch Manager
Carbon does not support the Patch Manager. Apple is investigating other ways to provide programmatic extensibility.
Vertical Retrace Manager
Carbon does not support the Vertical Retrace Manager. Apple will provide sample code that demonstrates how to get equivalent functionality using the Time Manager.
Common OS Services
Disk Initialization ManagerCarbon does not support the Disk Initialization Manager. Disk Initialization will be supported by the system. Mac OS X applications that need to initialize disks can do so using new APIs in the IOKit.
Graphics Services
Printing ManagerCarbon introduces substantial changes to the printing model. The original Printing Manager defined in Printing.h is replaced by a new Carbon Printing Manager defined in PMApplication.h. The Carbon Printing Manager allows applications to print on Mac OS 8 with existing printer drivers and on Mac OS X with new printer drivers.
The following is a summary of the major changes you need to be aware of. More information is available on the Carbon website:
• The Print Record (TPrint) is no longer directly accessible by applications, and has been split into two separate opaque objects: a PrintSettings object and a PageFormat object. Applications will be given references to these two privately-defined data structures. These references are then used to query the Printing Manager for information contained within the objects.
• A consequence of splitting the Print Record and making it private is there are no fixed sizes. Applications will be able to "extend" both the PrintSettings and PageFormat objects, but applications must not assume a specific size when storing and retrieving a PageFormat with documents.
• The Printing Manager will supply functions for flattening and restoring both the PrintSettings and PageFormat object. When storing printing information with documents it will suffice to store just the PageFormat object. If older versions of your application store a print record with a saved document, you may continue to do so to provide backward compatibility.
• Application developers should reduce the use of calls that append items to print dialogs. We expect to provide a new panel-based interface in the near future.
• All print records use the "draft" style, not the "deferred" style, which implies that a print driver must handle the spooling if it wants to provide spooling for the user. Many, if not all, print drivers perform their own spooling and don't require applications to call PrPicFile() to implement spooling. Because it is rarely used, we are eliminating system level spooling code from the Printing Manager.
• The Printing Manager will now enforce an order in which some routines are called. Any routine used out of scope will return an error.
• All Printing Manager routines are only valid within a PMBegin/PMEnd block.
• PrintSettings and PageFormats are automatically disposed of during a PMEnd call.
• The desktop printing functions defined in DesktopPrinting.h are not supported in Carbon.
Replace PrClose withPMEnd .
Replace PrCloseDoc withPMEndDocument .
Replace PrClosePage withPMEndPage .
Replace PrDlgMain with a call toPMPrintDialogMain for a job dialog box or a call toPMPageSetUpDialogMain
for a style dialog box.
Carbon applications must use Carbon Printing Manager functions instead.
Replace PrError withPMError
.
Replace PrJobDialog withPMPrintDialog .
Replace PrJobInit withPMPrintDialogInit .
Replace PrOpen withPMBegin.
Replace PrOpenDoc withPMBeginDocument .
Replace PrOpenPage withPMBeginPage .
This function is obsolete. Printer drivers must perform their own spooling.
Replace PrStlDialog withPMPageSetUpDialog .
Replace PrStlInit withPMPageSetUpDialogInit .
Replace PrValidate with calls toPMValidatePageFormat andPMValidatePrintSettings
.
Replace PrintDefault with calls toPMDefaultPageFormat andPMDefaultPrintSettings
.QuickDraw GX
Carbon does not support QuickDraw GX. You should use the other Mac OS imaging and typography managers such as Apple Type Services for Unicode Imaging, QuickDraw, and the Font Manager.
QuickDraw Manager
Carbon supports most of the QuickDraw programming interface.
Carbon applications should use CreateNewPort and DisposePort to open and close graphics ports, rather than OpenPort, OpenCPort, ClosePort, and CloseCPort.
Carbon adds functions to get and set port data without accessing port data structures directly. For example, you can use such functions as GetPixBounds, GetPortFillPixPat, SetPortBounds, and SetPortPenSize.
In the past, parts of QuickDraw have been documented in Inside Macintosh as the Color Manager and Cursor Utilities. Note, however, that Inside Macintosh: Imaging with QuickDraw describes animated cursor functions, such as SpinCursor, that are available in the MPW programming environment and possibly in other environments, but not in system software. These animated cursor functions, which are defined in the MPW interface file CursorCtl.h, will not be supported by Carbon.
Carbon applications should use CreateNewPort and DisposePort to open and close graphics ports.
Carbon applications should use CreateNewPort and DisposePort to open and close graphics ports.
Carbon applications should use CreateNewPort and DisposePort to open and close graphics ports.
Carbon applications should use CreateNewPort and DisposePort to open and close graphics ports.Hardware Interfaces
ADB ManagerCarbon does not support the ADB Manager, because it accesses hardware directly. As with other hardware-touching managers, you can use this manager through a non-Carbon plug-in for Mac OS 8. For Mac OS X, you should use the comparable APIs supplied with the IOKit.
Device Manager
Carbon does not support the Device Manager as an interface for installing or interacting with device drivers. However, you can continue to use the PBRead and PBWrite functions (and their variants) for reading and writing to open files.
In Mac OS X, code that communicates directly with hardware devices must use the IOKit API. Other types of code that have relied on the Device Manager interface in the past (such as desk accessories) should be converted into applications.
Note: The Serial Driver will be supported through a new set of functions similar to PBOpen, PBControl, PBStatus, etc., but specific to serial communication.
Desk accessories will not be supported in Carbon. A new mechanism will be provided for handling selections from the Apple menu.
Human Interface Toolbox
Control ManagerCarbon will fully support the Control Manager, with the following changes:
• The C-style, lowercase versions of Control Manager function names are no longer supported. If your application uses any Control Manager lowercase function names, you must replace them with their uppercase equivalents.
• Custom control definition procedures (also known as CDEFs), must be compiled as PowerPC-native code, and can not be stored as resources. See the Carbon Porting Guide for more information.
• Your application must use the functions defined by the Control Manager whenever your application needs to create and dispose of Control Manager data structures. For example, instead of directly creating and disposing of control records, applications must call the Control Manager functions GetNewControl and DisposeControl.
• Your application must use Control Manager accessor functions to accesses Control Manager data structures.
• You are encouraged to adopt the standard Mac OS control definition procedures in your application. Applications that use the standard control definition procedures inherit the Mac OS human interface appearance. Applications that use custom control definition procedures will work correctly, but because custom definition procedures invoke their own drawing routines, Mac OS 8 can’t draw these applications with the current appearance.
Custom control color tables are not supported in Carbon.Dialog Manager
Carbon supports the Dialog Manager. However, your application must access Dialog Manager data structures only through the supplied accessor functions. Furthermore, your application must use the functions provided for creating and disposing of Dialog Manager data structures.
The CloseDialog function is not supported because developers do not allocate their own memory for dialog boxes in Carbon. Use the DisposeDialog function to dismiss a dialog box instead.
InitDialogs is not supported in Carbon. There is no need to initialize the Dialog Manager because the shared library is loaded as needed.Event Manager
Carbon will support the majorify of the Event Manager.
High-level events APIs (as contained in EPPC.h) are not supported. You should use Apple events instead.
Low-level event queue functions, such as GetEvQHdr and PPostEvent, are no longer supported.
Application-defined function-key procedures are not supported in Carbon.
The High Level Event APIs (EPPC.h) are not supported in Carbon. Instead, use Apple events.
Desk accessories are not supported in Carbon.
Desk accessories are not supported in Carbon.
In Carbon, the Event Manager automatically handles all task scheduling.Help Manager
Carbon does not support the original Help Manager defined by Balloons.h. Your applications should use the Carbon Help Manager instead.
Menu Manager
Carbon will support the Menu Manager, with the following changes:
• Your application must use the functions defined by the Menu Manager whenever it creates and disposes of Menu Manager data structures. Some applications, for example, create menus by using the Resource Manager function GetResource (instead of the Menu Manager function GetMenu) and dispose of them by calling ReleaseResource instead of DisposeMenu. This practice is not supported in Carbon.
• The MenuInfo structure is opaque in Carbon. You must revise your application so that it accesses Menu Manager data structures only through accessor functions.
• There are several Menu Manager functions that deal with manipulating menu color information tables. Apple recommends that you stop using them. The Appearance Manager generally disregards these color tables and instead uses the colors defined for the current appearance.
• You are strongly encouraged to adopt the standard Mac OS 8 menu definition procedures (also known as MDEFs) in your application. Your menus will then inherit the systemwide appearance and, furthermore, take advantage of other Menu Manager enhancements planned for the future. Note, however, that if you must use custom menu definition procedures, you must compile them as PowerPC-native code.
You should instead use CheckMenuItem.
You should instead use CountMenuItems.
Replaced by DisableMenuItem.
Replaced by EnableMenuItem.
InitMenus is not supported in Carbon. There is no need to initialize the Menu Manager because the shared library is loaded as needed.
Carbon does not support desk accessories.Scrap Manager
Carbon supports only the LoadScrap and UnloadScrap functions from the original Scrap Manager. However, Carbon will supply new features, including support for "promises," to the Scrap Manager.
You should instead use the functions ScrapHasFlavor, GetScrapFlavorSize, and GetScrapFlavorData.
You should instead use the function GetScrapSeed.
You should instead use the function PutScrapFlavor.
You should instead use the function ClearScrap.Standard File Package
Carbon does not support the Standard File Package. You must use Navigation Services instead. Navigation Services 1.0 is compatible back to System 7.5.5.
To assist your transition efforts, Apple will provide source code that maps many common Standard File Package calls to their Navigation Services counterparts. Note, however, that this code provides an interim solution only—you will eventually need to adopt Navigation Services.
Window Manager
Carbon will support the Window Manager. Be aware, however, that if you use custom window definition procedures (also known as WDEFs), you must compile them as PowerPC-native code. In addition:
• Your application must use the functions defined by the Window Manager whenever it creates and disposes of Window Manager data structures. For example, instead of directly creating and disposing of window records, applications must call such Window Manager functions as GetNewCWindow and DisposeWindow.
• You must revise your application so that it accesses Window Manager data structures only through accessor functions.
• You are encouraged to adopt the standard Mac OS 8 window definition procedures in your application. Applications that use the standard Mac OS 8 window definition procedures inherit the Mac OS 8 human interface appearance. Applications that use custom window definition procedures work correctly, but because custom definition procedures invoke their own drawing routines, Mac OS 8 can’t draw these applications with the current appearance.
The CloseWindow function is not supported because developers do not allocate their own memory for windows in Carbon. Use the DisposeWindow function to remove a window instead.
Remove application reliance on AuxWinRec data structures; in the future, the information in these structures may be invalid or unavailable to applications.
Carbon does not support accessing the Window Manager port. You should draw into your own graphics port instead.
InitWindows is not supported in Carbon. There is no need to initialize the Window Manager because the shared library is loaded as needed.QuickTime
QuickDraw 3DCarbon does not support QuickDraw 3D. However, QuickDraw 3D will continue to be supported on Mac OS 8, and QuickDraw 3D applications run on Mac OS X in the Classic Environment.
Apple is concentrating on providing support for the OpenGL standard on both Mac OS 8 and Mac OS X. OpenGL is Carbon compliant and will be available to Carbon applications on both systems as an extension to the Carbon APIs.
Text and Other International Services
Date, Time, and Measurement UtilitiesCarbon fully supports the Date, Time, and Measurement Utilities. However, some obsolete functions that are prefixed with IU (such as IUDateString and IUTimeString) may not be supported in the future.
Use DateString instead.
Use DateString instead.
Use TimeString instead.
Use TimeString instead.Font Manager
Carbon will support most Font Manager functions. However, applications will no longer have direct access to Font Manager data structures, and you will not be able to access the list of fonts (or the data in those fonts) using the Resource Manager. You may need to modify your application to use new accessor functions when they are available.
Script Manager
Carbon supports nearly the entire Script Manager programming interface. Exceptions are the routines Get/SetScriptQDPatchAddress and Get/SetScriptUtilityAddress, which are rarely used by applications.
Use CharacterByteType instead.
Use CharacterType instead.Text Services Manager
Carbon will support nearly all Text Services Manager functions. The exceptions are those functions, such as NewServiceWindow and CloseServiceWindow, used to create and manage floating utility windows. If you have a TSM component that uses floating utility windows, you should replace these functions with equivalent Mac OS 8.5 Window Manager functions, which offer more complete support for creating and managing floating windows.
For example, instead of the NewServiceWindow function, you can use the Window Manager function CreateNewWindow, and specify either kFloatingWindowClass or kUtilityWindowClass.
Likewise, use DisposeWindow insteaad of CloseServiceWindow, GetFrontWindowOfClass instead of GetFrontServiceWindow, and FindWindowOfClass instead of FindServiceWindow.
In addition, it is possible that TSMEvent, TSMMenuSelect, and SetTSMCursor will no longer need to be called, and therefore may not be available. This is still under investigation.
Not needed in Mac OS X due to the new event model.
Not needed in Mac OS X due to the new event model.Text Utilities
Carbon fully supports the Text Utilities. However, some obsolete functions that are prefixed with IU (such as IUStringOrder and IUTextOrder) may not be supported in the future.
Use FindWordBreaks instead.
Use CompareString instead.
Use IdenticalString instead.
Use IdenticalText instead.
Use IdenticalText instead.
Use CompareText instead.
Use CompareText instead.
You should instead use CopyCStringToPascal.
You should instead use CopyPascalStringToC.
|
|
|
|
|
|
|
|
|
Access supported if through LMGetSysFontSize |
|
|
|
|
Access supported if through LMSetSysFontFam |
|
|
|
|
Access supported if through LMSetSysFontSize |
|
|
|
|
Access supported if through LMGetROMFont0 |
|
|
|
|
Access supported if through LMSetROMFont0 |
|
|
|
|
Access supported if through LMSetResErr |
|
|
|
|
Access supported if through LMSetMemErr |
|
|
|
|
Access not supported. (No public accessor) |
|
|
|
|
Access not supported. (No public accessor) |
|
|
|
|
Access not supported. (No public accessor) |
No resources loaded into system heap.
Copyright 1998-2000 Apple Computer, Inc. All rights reserved.
