|
Report for: SCREEN.mex |
Report date: 1/15/2000 |
|
File Creator: MATL |
Data gathered by analyzer version: 1.3 |
|
File Type: MEX0 |
Data gathered on: 1/15/2000 |
|
|
 |
||||||||||||||||||||||||
Supported with ModificationsCommon OS ServicesDisplay ManagerWith the exception of certain obsolete or 68K-specific functions, Carbon will support the Display Manager. Functions that take a univeral procedure pointer may need to be modified however.Process Manager
DMGetIndexedDisplayModeFromList
Carbon 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.
Supported But Not RecommendedText and Other International ServicesFont 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.
GetFNum
You should instead use FMGetFontFamilyFromName.
You should instead use FMGetFontFamilyName.
Unsupported APICarbon CoreLow Memory AccessorsHardware InterfacesCarbon 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
Memory Management Utilities
LMGetWindowList
You should instead use GetWindowList.
Do not hide and show the menu bar by adjusting the menu bar height. Use the HideMenuBar and ShowMenuBar functions instead.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.
Memory Manager
Uses working directories. Use FindFolder and Gestalt instead.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.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.
Patch Manager
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.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.
Device ManagerText and Other International ServicesCarbon 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.
Name Registry
In Mac OS X, the IOKit will provide driver-level functionality similar to that currently provided by the Name Registry. Carbon does not provide application-level support of the Name Registry.
PCI Card Services
Carbon does not support PCI card services. In Mac OS X, all code that communicates directly with PCI cards must use the IOKit API.Slot Manager
Carbon does not support the Slot Manager, because it accesses hardware directly. 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.
Text UtilitiesCarbon 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.
You should instead use CopyCStringToPascal.
You should instead use CopyPascalStringToC.
|
|
|
|
|
|
|
|
|
Access not supported. (No public accessor) |
|
|
|
|
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.