|
Report for: TextDrawIII_FAT |
Report date: 5/26/98 |
|
File Creator: MNii |
Data gathered by analyzer version: 1.2 |
|
File Type: APPL |
Data gathered on: 5/27/98 |
|
|
 |
|||||||||||||||||||||||||||
Supported with ModificationsGraphics ServicesPrinting ManagerHuman Interface ToolboxCarbon will support the high-level programming interface defined by the Printing Manager. Carbon will, however, make the following changes to your use of this interface:
* The print (TPrint) record will no longer be directly accessible to your application. In place of a print record, the Printing Manager will provide your application with a reference to a privately defined data structure. Access to other Printing Manager data structures, such as the printing graphics port (TPrPort), will remain unchanged in Carbon.
* The private structure replacing the print record won't necessarily be 120 bytes long--your application must not assume it to be of any specific size.
* Apple will introduce new panel-based dialog boxes for printing. Your application should limit calls to the functions PrStlInit, PrJobInit, and PrDlgMain for adding items to the Page Setup and Print dialog boxes.
* Apple will make print dialog boxes movable and modal. This will require you to provide an event handler to respond to update events when your application displays these dialog boxes.
* The 68K code resource mechanism for accessing drivers will be replaced by a shared library mechanism, requiring the revision of print drivers.
* All print drivers will have to support their own spooling.
PrCloseDoc
In place of a print record, the Printing Manager uses a reference to a privately defined, variable-length data structure.
In place of a print record, the Printing Manager uses a reference to a privately defined, variable-length data structure.
In place of a print record, the Printing Manager uses a reference to a privately defined, variable-length data structure.
In place of a print record, the Printing Manager uses a reference to a privately defined, variable-length data structure.
In place of a print record, the Printing Manager uses a reference to a privately defined, variable-length data structure.
In place of a print record, the Printing Manager uses a reference to a privately defined, variable-length data structure.
In place of a print record, the Printing Manager uses a reference to a privately defined, variable-length data structure.
In place of a print record, the Printing Manager uses a reference to a privately defined, variable-length data structure.Window ManagerLow-Level Operating System ServicesCarbon will fully 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.
To ensure that your application can most easily take advantage of future enhancements to the Mac OS, Apple suggests that you also consider the following points.
* Your application should 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 should call the Window Manager functions GetNewCWindow and DisposeWindow. In Mac OS X, applications might not be allowed to create and dispose of Window Manager data structures except by calling Window Manager functions.
* You should revise your application so that it accesses the data structures defined by the Window Manager only through accessor functions. The use of these accessor functions, to be provided soon, will give your application greater threading flexibility in Mac OS X.
* 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.Memory 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.
The following Memory Manager functions are likely to change in Carbon: GZSaveHnd, MoreMasters, and TempNewHandle.
The following Memory Manager functions are still under evaluation: GetZone, HandleZone, InitZone, PtrZone, SetGrowZone, and SetZone. Please give us feedback on the importance of using subzones in your applications.
The following Memory Manager functions will not be supported in Carbon: MaxBlockSys, MaxMemSys, NewEmptyHandleSys, NewHandleSys, NewHandleSysClear, NewPtrSys, NewPtrSysClear, PurgeMemSys, PurgeSpaceSysContiguous, PurgeSpaceSysTotal, ReallocateHandleSys, RecoverHandleSys, RecoverMemSys, and SystemZone.
The following Virtual Memory functions are likely to change in Carbon: FlushMemory, MakeMemoryNonResident, MakeMemoryResident, and ReleaseMemoryData.
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 use the following Memory Manager functions: EnterSupervisorMode, StripAddress, Translate24To32.
* Do not modify a field in a zone header to specify how many master pointer blocks are allocated by each call to the function MoreMasters. The Memory Manager will 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 memory model, so the new function will provide the most benefit for applications running on previous versions of the Mac OS.
* 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 with the function NewControl--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.
Process Manager
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.Carbon will support most of the Process Manager. The exception is the LaunchDeskAccessory function, which may not be supported (or it may simply do nothing).
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 RecommendedGraphics ServicesPrinting ManagerHuman Interface ToolboxCarbon will support the high-level programming interface defined by the Printing Manager. Carbon will, however, make the following changes to your use of this interface:
* The print (TPrint) record will no longer be directly accessible to your application. In place of a print record, the Printing Manager will provide your application with a reference to a privately defined data structure. Access to other Printing Manager data structures, such as the printing graphics port (TPrPort), will remain unchanged in Carbon.
* The private structure replacing the print record won't necessarily be 120 bytes long--your application must not assume it to be of any specific size.
* Apple will introduce new panel-based dialog boxes for printing. Your application should limit calls to the functions PrStlInit, PrJobInit, and PrDlgMain for adding items to the Page Setup and Print dialog boxes.
* Apple will make print dialog boxes movable and modal. This will require you to provide an event handler to respond to update events when your application displays these dialog boxes.
* The 68K code resource mechanism for accessing drivers will be replaced by a shared library mechanism, requiring the revision of print drivers.
* All print drivers will have to support their own spooling.
PrClose
PrClose does nothing; you don't need to call it.
PrOpen performs nothing; you don't need to call it.Dialog ManagerText and Other International ServicesCarbon will fully support the Dialog Manager. However, Apple encourages you to revise your application so that it accesses the data structures defined by the Dialog Manager only through accessor functions. The use of these accessor functions, to be provided soon, will give your application greater threading flexibility in Mac OS X. Furthermore, you are encouraged to use only the functions defined by the Dialog Manager to create and dispose of data structures defined by the Dialog Manager. In Mac OS X, applications might not be allowed to create and dispose of Dialog Manager data structures except by calling Dialog Manager functions.
Menu Manager
InitDialogs does nothing. There is no need to initialize the Window Manager, because the shared library gets loaded as needed.Carbon will fully support the Menu Manager. To ensure that your application can most easily take advantage of future enhancements to the Mac OS, Apple suggests that you consider the following points:
* 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.
* Your application should 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. In Mac OS X, applications might not be allowed to create and dispose of Menu Manager data structures except by calling Menu Manager functions.
* You should revise your application so that it accesses the data structures defined by the Menu Manager only through accessor functions to be provided soon. The use of these accessor functions will give your application greater threading flexibility in Mac OS X.
* 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.
Window Manager
InitMenus does nothing. There is no need to initialize the Menu Manager, because the shared library gets loaded as needed.Carbon will fully 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.
To ensure that your application can most easily take advantage of future enhancements to the Mac OS, Apple suggests that you also consider the following points.
* Your application should 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 should call the Window Manager functions GetNewCWindow and DisposeWindow. In Mac OS X, applications might not be allowed to create and dispose of Window Manager data structures except by calling Window Manager functions.
* You should revise your application so that it accesses the data structures defined by the Window Manager only through accessor functions. The use of these accessor functions, to be provided soon, will give your application greater threading flexibility in Mac OS X.
* 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.
InitWindows does nothing. There is no need to initialize the Window Manager, because the shared library gets loaded as needed.Date, Time, and Measurement UtilitiesCarbon will fully support 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.
Text Utilities
Use DateString instead.Carbon will fully support Text Utilities. However, some obsolete functions that are prefixed with IU (such as IUStringOrder and IUTextOrder) may not be supported in the future.
Use CompareString instead.
Unsupported APIGraphics ServicesPrinting ManagerHardware InterfacesCarbon will support the high-level programming interface defined by the Printing Manager. Carbon will, however, make the following changes to your use of this interface:
* The print (TPrint) record will no longer be directly accessible to your application. In place of a print record, the Printing Manager will provide your application with a reference to a privately defined data structure. Access to other Printing Manager data structures, such as the printing graphics port (TPrPort), will remain unchanged in Carbon.
* The private structure replacing the print record won't necessarily be 120 bytes long--your application must not assume it to be of any specific size.
* Apple will introduce new panel-based dialog boxes for printing. Your application should limit calls to the functions PrStlInit, PrJobInit, and PrDlgMain for adding items to the Page Setup and Print dialog boxes.
* Apple will make print dialog boxes movable and modal. This will require you to provide an event handler to respond to update events when your application displays these dialog boxes.
* The 68K code resource mechanism for accessing drivers will be replaced by a shared library mechanism, requiring the revision of print drivers.
* All print drivers will have to support their own spooling.
PrPicFile
Device ManagerHuman Interface ToolboxCarbon will not support the Device Manager. 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.
Standard File PackageCarbon will not support the Standard File Package, so you should 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.
Under EvaluationApplication UtilitiesEdition ManagerLow-Level Operating System ServicesDue to limited customer adoption of the publish-and-subscribe feature, the Edition Manager will for the most part not be supported in Carbon. However, Apple will provide a mechanism for your application to open and read files that contain editions.
AssociateSection
Patch ManagerIt is unlikely that the Patch Manager will be supported in Carbon. It is important that you tell us why you use this manager so we can plan a suitable replacement. For example, if you currently patch ExitToShell, you can instead use a new callback mechanism that provides the same function.
|
|
|
|
|
No Invalid Access Detected
No resources loaded into system heap.
Copyright 1998 Apple Computer, Inc. All rights reserved.