Legacy Document
Important: This document is part of the Legacy section of the ADC Reference Library. This information should not be used for new development.
Current information on this Reference Library topic can be found here:
ADC Home > Reference Library > Technical Notes > Legacy Documents > Mac OS 9 & Earlier >
Important: This document is part of the Legacy section of the ADC Reference Library. This information should not be used for new development.
Current information on this Reference Library topic can be found here:
|
|
Finder 8.1Finder 8.1 changes fall into three categories: Finder 8.1 also defines two new bits in its Gestalt selector. New features:
Enhancements to existing features:
Bug fixes:Dozens of bugs have been fixed, including many in AppleScript support. Some internal subsystems have been redesigned and re-implemented for substantially better stability. Finder/AppleScript bug fixes:
Other specific bug fixes:
Gestalt:As a result of the above changes and changes in Finder 8, Finder's Gestalt selector response value has acquired two new defined bits under Mac OS 8.1:
Before testing for either of these bits, you should first test for the presence of Mac OS 8 or later. If Mac OS 8 is present, neither of these bits will be set. HFS Plus Volume FormatMac OS 8.1 introduces support for Apple's new volume format, HFS Plus (also known as Mac OS Extended). This format is available for use with any storage device larger than 32MB that support the HFS volume format. Benefits Provided in Mac OS 8.1The main benefit in this release of the Mac OS Extended volume format is the use of smaller allocation blocks. The size of allocation blocks used for a particular volume depend on its size.
The default allocation block size of 4K was chosen for volumes larger than 1GB. For a number of reasons:
Future BenefitsThe Mac OS Extended volume format also provides support for long Unicode file names, large files, and extended attributes. However, Mac OS 8.1 does not introduce the new APIs required to access these advanced features. The support for Mac OS Extended volumes was added in such a way that use of these volumes should be transparent to developers who use only the documented File Manager API.
Mac OS 8.1 introduces a few changes to the existing File Manager API that developers should be aware of. These changes include routines for getting extended volume information and for controlling the formatting process. These changes are described in a separate HFS Plus Technote which will be published in the near future along with another document, "Mac OS Extended Volume Format", that describes the format of an HFS Plus volume.
File Manager Disk CacheThe File Manager provides services for storage and retrieval of disk based information. The File Manager disk cache performance on multi-block I/O operations has been improved. Cached multi-block I/O operations should be noticeably faster. Start Manager ChangesThe Start Manager was changed in Mac OS 8.1 to add a mechanism for controlling the loading of extensions at system startup. During the boot process, an extension table is created before any extensions are loaded. This table is then used by the boot code to determine which extensions should be loaded and in which order. Prior to the introduction of the Extension Table Manager in Mac OS 8.1,
extensions were loaded from three folders, Extensions, Control Panels and the
System Folder, in the order they were found on the disk. On an HFS volume,
items are stored in the catalog in With the introduction of Mac OS 8.1 a new bootable disk format was introduced, HFS Plus. On an HFS Plus volume, items are stored in the catalog in a different order than a Mac OS Standard volume because of the internal use of Unicode for item names. Since extensions were loaded in the order they were found in the catalog, extensions would load in a different order when booted from an HFS vs. an HFS Plus volume.
To prevent problems for our users, and to ensure that extensions
load in the same order regardless of the volume format used, an
extension table mechanism was added to the Start Manager. The default
behavior of the extension table handler is to sort the extensions
into The Extension Table Manager also provides a mechanism that third-party products can use to watch, and optionally control, the extension loading process. A Technote covering this new mechanism is in progress and will be released in the near future. Sound for PCI SystemsThere have been a number of additions and changes to the sound software for PCI-based Macintoshes under Mac OS 8.1 that will affect developers. AdditionsA programmatic method for selecting sound sources via the Sound
Input Manager using
Four new selectors have been added to the built-in sound input driver:
These selectors allow the use of several new constants to set a particular input source or monitor source programmatically. For instance, to have the user record the CD, an application could use code like this:
where The The currently defined input source selectors are:
Changes
End User ExperienceThere have also been some minor changes, which make the sound experience more enjoyable and predictable for the user. They are:
|
extern pascal OSErr
ALMPutLocation (ConstStr255Param prompt,
ALMLocationName name,
SInt16 numTypes,
ConstALMModuleTypeListPtr typeList,
ModalFilterYDUPP filter,
void* yourDataPtr)
|
This function allows the developer to create a location using a
standardized interface. Typically, the developer will pass
kALMAddAllOff or kALMAddAllOnSimple for numTypes, and NULL for
typeList, but it is possible to pass an array of module signatures.
The filter and yourDataPtr parameters behave as in Standard File.
extern pascal OSErr
ALMMergeLocation (ConstStr255Param prompt,
ALMLocationName name,
SInt16 numTypes,
ConstALMModuleTypeListPtr typeList,
ModalFilterYDUPP filter,
void* yourDataPtr);
|
This function allow the developer to merge settings into an existing
location using a standardized interface; the parameters are as with
ALMPutLocation, though typically a module signature array is used in
this case.
extern pascal OSErr
ALMGetLocation (ConstStr255Param prompt,
ALMLocationName name,
ModalFilterYDUPP filter,
void* yourDataPtr);
|
To ask the user to choose a location by name, call this.
This function allows a user to choose a location by name.
Previously, an interested program could
receive notification that the current location had changed. In ALM
2.0.1, if bit gestaltALMHasRescanNotifiers returned from
gestaltALMAttr is set, the client code will be notified when
the locations list is changed (a location gets deleted, renamed, or
added). In this way, interested programs will know if location
data they retrieved earlier (such as through a call to
ALMGetIndLocation) might be out of date because the user has edited
the locations list.
Under ALM 1.0.x, all modules had file types of 'thng'. Under ALM
2.0.1, 'thng' files are still supported, but the preferred file types
are 'almn' and 'almb'. An 'almn' file is a preference-swapping
module, such as "Extension Set". An 'almb' file is an action module,
such as "Auto-Open Items". The distinction is that the "value" of an
action module cannot be directly determined from the system--it
requires user intervention (for example, in the case of Auto-Open
Items, the user is asked what files to open).
Developers are encouraged to adopt these new file types so that modules can be auto-routed to the Module folder in a later version of the system software.
All calls in ALM 2.0.1 are available under CFM-68K.
When a module was called with the kALMSetCurrentSelect selector,
the value of the *flags parameter was kALMNoChange under 1.0.x. Under
2.0 this value is the current "escalation" of the setting; that is, the
level to which all modules prior to the developer's module have
raised the setting. For example, if a location contains an Extension
Set that requires a restart, and subsequent modules do not want to
act if the system is restarting, the module can use the input value
to decide how to interpret the SetCurrent call.
ALMSwitchToLocation from an INIT did not work prior to
ALM 2.0.1.ALMConfirmName, the users filterproc was not called
under both dialogs presented prior to 2.0; now it is, and the
window refCons can be used to determine which dialog is up. All
dialog elements are documented constants.ALMSwitchToLocation from within a
module during a call to ALMSwitchToLocation. This tail-biting now
generates an error.Apple may, for business reasons, change the name of "Apple
Location Manager". Developers are cautioned not to rely on the names
of items such as the modules folder, and should use FindFolder.
The Apple Location Manager 2.0.1 SDK is available on the Jan 98 Mac OS SDK CDs. The necessary interface files are included in Universal Interfaces 3.0.1.
The Virtual Memory Manager provides virtual memory services for the Mac OS.
There have been a number of changes to the Virtual Memory Manager aimed at providing improved performance for applications. Some of these changes are transparent to applications, while others allow applications to actively control Virtual Memory.
kdgVMOptions DriverGestalt selector,
which allows disk drivers to tell Virtual Memory and the Memory
Control panel what Virtual Memory operations are supported by a
disk drive.The Virtual Memory Paging Control functions allow applications to help the Virtual Memory Manager optimize system performance. This is accomplished by giving the Virtual Memory Manager hints about:
You can determine when the four Virtual Memory Paging Control
functions (MakeMemoryResident,
MakeMemoryNonResident,
FlushMemory, and
ReleaseMemoryData) are available by
calling Gestalt with the gestaltVMAttr selector and checking if the
gestaltVMHasPagingControl bit (bit 4) is set in the response.
Boolean VMHasPagingControl(void)
{
long response;
if ( (Gestalt( gestaltVMAttr, &response ) == noErr) &&
((response & ( 1L << gestaltVMHasPagingControl )) != 0) )
{
return ( true );
}
else
{
return ( false );
}
}
|
Mac OS virtual memory pages can be in several states. A page's state determines what happens when it's not resident in physical memory, and is made resident, and what happens when it's resident in physical memory and is made non-resident. Understanding how the state of a page affects the Mac OS virtual memory system will help you understand the purpose of the Virtual Memory Paging Control functions.
A page can be either resident or non-resident. A page that is currently in physical memory is resident. A page that is currently not in physical memory is non-resident.
|
Note: |
A resident page has two states: clean and dirty. A clean page's data does not need to written from memory to the backing store file before the page is made non-resident. A dirty page's data must be written from memory to the backing store file before the page is made non-resident.
A non-resident page also has two states: valid on disk and invalid on disk. A non-resident page which is valid on disk must be read from the backing store file into memory when it is made resident. A non-resident page which is invalid on disk does not need to be read from the backing store file into memory when it is made resident.
|
Note: |
MakeMemoryResidentUse the MakeMemoryResident function to make a portion of the
address space resident in physical memory. MakeMemoryResident can be
used to optimize system performance by causing the Virtual Memory
Manager to read in pages that will be needed in the future.
pascal OSErr MakeMemoryResident (void *address,
unsigned long count);
address The starting address of the range of memory to be made resident.
count The size, in bytes, of the range of memory to be made resident.
|
The MakeMemoryResident function makes a portion of the address
space beginning at address and having a size of count bytes resident
in physical memory.
If the address parameter supplied to the MakeMemoryResident
function is not on a page boundary, then it is rounded down to the
nearest page boundary. Similarly, if the specified range does not end
on a page boundary, the count parameter is rounded up so that the
entire range of memory is made resident.
The MakeMemoryResident function makes the range of memory resident
as efficiently as possible. Non-resident pages that are made resident
are always marked clean.
Even though MakeMemoryResident does not move or purge memory, you
must not call it at interrupt time.
The specified range must be entirely in allocated space in main memory (the System and Process Manager memory partitions), or entirely in a single file-mapped space.
The trap macro and routine selector for the MakeMemoryResident
function are:
_MemoryDispatch $000B |
The registers on entry and exit for this routine are
D0 Selector code A0 Starting address A1 Number of bytes to make resident |
D0 Result code |
noErr 0 No error paramErr -50 The address range specified is invalid notEnoughMemoryErr -620 There is insufficient physical memory to make entire range resident |
MakeMemoryNonResidentUse the MakeMemoryNonResident function to make a portion of the
address space non-resident. MakeMemoryNonResident can be used to
optimize system performance by giving the Virtual Memory Manager
pages which can be used to handle future page faults.
pascal OSErr MakeMemoryNonResident (void *address,
unsigned long count);
address The starting address of the range of memory to be made non-resident.
count The size, in bytes, of the range of memory to be made non-resident.
|
The MakeMemoryNonResident function makes a portion of the address
space beginning at address and having a size of count bytes
non-resident.
If the address parameter supplied to the MakeMemoryResident
function is not on a page boundary, it is rounded up to the
nearest page boundary. Similarly, if the specified range does not end
on a page boundary, the count parameter is rounded down so that only
pages completely contained in the range of memory are made
non-resident (although all pages of the specified range are flushed).
This means that less memory than was specified may be made
non-resident.
All dirty pages of the specified range are first written to the backing store file and then marked valid on disk.
Any pages of the specified range that are held (with HoldMemory)
or locked (with LockMemory or LockMemoryForOutput) will not be made
non-resident, but are flushed.
Even though MakeMemoryNonResident does not move or purge memory,
you must not call it at interrupt time.
The specified range must be entirely in allocated space in main memory (the System and Process Manager memory partitions), or entirely in a single file mapped space.
The trap macro and routine selector for the MakeMemoryNonResident
function are:
_MemoryDispatch $000D |
The registers on entry and exit for this routine are
D0 Selector code A0 Starting address A1 Number of bytes to make non-resident |
D0 Result code |
noErr 0 No error paramErr -50 The address range specified is invalid |
FlushMemoryUse the FlushMemory function to make a portion of the address
space clean. This can be useful when you want to ensure the backing
store file's data matches what is in a resident page. FlushMemory can
also be used to optimize system performance by letting the Virtual
Memory Manager know what pages can be made clean because they are
unlikely to change again in the near future (making those pages
non-resident will not require I/O in the future).
pascal OSErr FlushMemory (void *address,
unsigned long count);
|
address The starting address of the range of memory to flush. count The size, in bytes, of the range of memory to flush. |
The FlushMemory function makes a portion of the address space,
beginning at address and having a size of count bytes, clean. All
dirty pages found in the specified range are written to the backing
store file. Resident pages are left resident by FlushMemory.
If the address parameter supplied to the FlushMemory function is
not on a page boundary, then it is rounded down to the nearest page
boundary. Similarly, if the specified range does not end on a page
boundary, the count parameter is rounded up so that the entire range
of memory is flushed.
Even though FlushMemory does not move or purge memory, you must
not call it at interrupt time.
The specified range must be entirely in allocated space in main memory (the System and Process Manager memory partitions), or entirely in a single file mapped space.
The trap macro and routine selector for the FlushMemory function
are:
_MemoryDispatch $000E |
The registers on entry and exit for this routine are
D0 Selector code A0 Starting address A1 Number of bytes to flush |
D0 Result code |
noErr 0 No error paramErr -50 The address range specified is invalid |
ReleaseMemoryDataUse the ReleaseMemoryData function to release the data of a
portion of the address space. ReleaseMemoryData can be used to
optimize system performance by preventing unnecessary writing to and
reading from the backing store file.
pascal OSErr ReleaseMemoryData (void *address,
unsigned long count);
|
address The starting address of the range of memory to release. count The size, in bytes, of the range of memory to release. |
The ReleaseMemoryData function informs the Virtual Memory Manager
that a portion of the address space, beginning at address and having a
size of count bytes, is no longer needed.
If the address parameter supplied to the ReleaseMemoryData
function is not on a page boundary, then it is rounded up to the
nearest page boundary. Similarly, if the specified range does not end
on a page boundary, the count parameter is rounded down so that only
pages completely contained in the range of memory are made
invalidated. This means that less memory than was specified may be
released.
All resident pages in the specified range are marked clean without
writing their contents to the backing store file; all non-resident
pages in read/write areas of the specified range are marked invalid
on disk (Note: read-only file mapped areas are not invalidated on
disk). Following a ReleaseMemoryData request with a
MakeMemoryNonResident request makes pages in the specified range
immediately available for reuse by the Virtual Memory Manager.
If the released range is subsequently accessed, the values in memory will be unpredictable.
Even though ReleaseMemoryData does not move or purge memory, you
should not call it at interrupt time.
The specified range must be entirely in allocated space in main memory (the System and Process Manager memory partitions), or entirely in a single file mapped space.
The Memory Manager calls ReleaseMemoryData for NewPtr, NewHandle,
TempNewHandle, and InitZone requests. There's no need to duplicate
the work the Memory Manager has already done.
The trap macro and routine selector for the ReleaseMemoryData
function are:
_MemoryDispatch $000C |
The registers on entry and exit for this routine are
D0 Selector code A0 Starting address A1 Number of bytes to release |
D0 Result code |
noErr 0 No error paramErr -50 The address range specified is invalid |
The File System Manager provides a general means by which foreign file systems can be installed, identified, and interfaced to the Operating System. Mac OS 8.1 includes version 2.0 of the File System Manager, which includes a number of changes:
gestaltFSMVersion will return version 2.0.UTCacheReadIP,
UTCacheWriteIP, UTVolCacheReadIP, and UTVolCacheWriteIP
now use an
XIOParam block, so foreign file systems that use 4GB block storage
or larger can be accessed.FSM's _Control patch that asks foreign file systems for
icons (via ffsGetIconMessage) so that it only looks for
synchronous requests -- ffsGetIconMessage can't be made at
interrupt time, so asynchronous requests were not safe to
handle.ffsGetIconMessage introduced in Mac OS 8 that
made it fail.ffsUnloadMessage
at a time that's safe to make other File Manager requests.
This lets you call the Code Fragment Manager to unload code fragments.
Previously, foreign file systems got the ffsUnloadMessage while
the File Manager was busy and any direct or indirect File Manager
requests would deadlock the system.HFSCIProc would be
called with a MountVol request outside of the context of a File
Manager request. This could cause a system crash if the foreign
file system made a cache I/O request while the File Manager was
busy with another request. Now all requests to foreign file
systems come from within the context of a File Manager
request.idSectors greater than or equal to
kMaximumBlocksIn4GB on foreign file system volumes.HFSCIProc
with a MountVol or a VolumeMount request while running on
another foreign file system's stack. If that stack wasn't
large enough, it could cause a crash. This was fixed.UTVolCacheWriteIP never worked correctly in Mac OS 8 due to a
disk cache bug. That bug has been fixed.fsmDrvQElChangedMessage
code.fsmGetFSIconMessage code.An updated version of the Guide to the File System Manager will be available in the near future.
|
|
IMPORTANT: |
The kdcVMOptions Driver Configure
_Control call provides the ability to change a driver's
response to kdgVMOptions Driver Gestalt requests. A
driver should return controlErr if it doesn't want to
provide the ability to change the kdgVMOptions response.
If a driver supports the kdcVMOptions Driver Configure
_Control call, but is asked to set an option bit that it
doesn't support (for example, if a read-only device is asked to set
the kAllowVMWriteBit), it should return
paramErr.
struct DriverGestaltVMOptionsResponse {
UInt32 vmOptions;
};
typedef struct DriverGestaltVMOptionsResponse DriverGestaltVMOptionsResponse;
/* Bits and masks for DriverGestaltVMOptionsResponse.vmOptions field */
enum {
kAllowVMReadBit = 0, /* Allow VM to use this drive for read access */
kAllowVMWriteBit = 1, /* Allow VM to use this drive for write access */
kAllowVMNoneMask = 0,
kAllowVMReadOnlyMask = 1 << kAllowVMReadBit,
kAllowVMReadWriteMask = (1 << kAllowVMReadBit) + (1 << kAllowVMWriteBit)
};
|
kdgMediaInfoThe kdgMediaInfo DriverGestalt selector allows a disk driver to
tell the caller about physical characteristics of the device it
supports. The disk drive for which the driver should return information
for is indicated by the value in the ioVRefNum field of
the DriverGestaltParam. This is a per-drive call, not a
per-driver call.
The response to this selector is a DriverGestaltMediaInfoResponse
structure. The fields in this structure contain the physical block
size, the number of blocks that are of that size, and the media type
for a given device.
On drives that support ejectable media, the response can change depending on what media is currently in the drive.
|
Note: |
The File Manager calls this selector and uses the values returned to help determine the value it will use for the allocation block size when formatting a volume as Mac OS Extended.
struct DriverGestaltMediaInfoResponse {
UInt32 numberBlocks; /* number of blocks */
UInt32 blockSize; /* physical size of blocks */
SInt16 mediaType; /* media type identifier */
};
typedef struct DriverGestaltMediaInfoResponse DriverGestaltMediaInfoResponse;
/* DriverGestaltMediaInfoResponse.mediaType constants */
enum {
kMediaTypeUnknown = 128, /* media type is unknown */
kMediaTypeCDROM = 129, /* media type is a CD-ROM */
kMediaTypeDVDROM = 130, /* media type is a DVD-ROM */
kMediaTypeNoMedia = -1 /* no media is present */
};
|
MRJ 2.0 supports Sun's Java version 1.1.3 specification, which has added or improved support in the following areas:
For further information, see the Mac OS Runtime for Java site.
Open Transport 1.3Mac OS 8.1 installs Open Transport v1.3, which contains a number of new features and bug fixes. An updated OT 1.3 SDK and OT 1.3 Release Notes are available. Bug fixes:General
Open Transport Debugger Preferences (for debug version only)
AppleTalk
TCP/IP
Links
API Changes
CFM-68K Support
Single Link Multi-homingOpen Transport 1.3 introduces single link multi-homing, a mechanism by which Open Transport can support multiple IP addresses on the same hardware interface. Synonyms for this feature include IP Aliasing, Secondary IP address support, IP Masquerading, "Multihoming", and IP Multinode support. This is useful for sites like Internet Service Providers (ISPs), that want to give each of their clients a distinct IP address, without requiring separate computers for each address. Web server software packages or server plug-ins that utilize this feature can offer virtual domain support that supports all web browsers. This functionality is transparent to Open Transport clients who are not specifically interested in single link multi-homing. The following information will help TCP/IP server developers implement single link multi-homing support into their products.
Single Link Multi-homing System SetupSingle link multi-homing support is only available with Open Transport 1.3 or higher. Your product will need to check that this version of Open Transport is present. See the section Checking the Open Transport Version for details on how to check for the presence of Open Transport 1.3 or higher. You configure a system to use multiple IP addresses as follows:
Each line of the IP Secondary Addresses file contains a secondary IP address to be used by the system, and an optional subnet mask and router address for the secondary IP address. If there is no subnet mask entry, then a default subnet mask for the IP address class will be used. If there is no router address entry, then the default router associated with the primary address will be used. Each secondary address entry must be prefixed by "ip=". Each subnet mask entry must be prefixed by "sm=". Each router address entry must be prefixed by "rt=". An example of the contents of the IP Secondary Addresses file follows.
The order of the entries is important. The "rt=" entry must follow the "sm=" entry if used. When Open Transport 1.3 activates TCP/IP, the primary address will be obtained from the TCP/IP Control Panel setting. Open Transport then looks for the IP Secondary Addresses file in the Preferences folder, to determine if additional addresses should also be configured. If there are duplicate IP address entries in the IP Secondary Addresses file, the duplicated addresses will be ignored. When Open Transport binds a TCP/IP connection, if there is an address conflict of the primary or any secondary addresses with another host, Open Transport will present an error message using a dialog box and will unload Open Transport TCP/IP from memory. The error dialog will display the conflicting IP address, the hardware address of the conflicting machine and note that your TCP/IP network interface has been shut down. Checking the Open Transport VersionTo check that Open Transport version 1.3 is present, use the
Gestalt function with the
InetInterfaceInfo Structure ChangeThe
You can pass this new structure to the
To distinguish this structure from earlier variants, the
|
OTInetGetSecondaryAddresses return active secondary IP addresses |
C INTERFACE
OSStatus OTInetGetSecondaryAddresses(InetHost* addr, UInt32* count, SInt32 index); |
C++ INTERFACE
None. C++ clients use the C interface to this function.
DESCRIPTION
|
Parameters |
Before Call |
After Call |
|---|---|---|
|
addr |
x |
(x) |
|
count |
(x) |
(x) |
|
index |
x |
/ |
OTInetGetSecondaryAddress is used to copy the
supported secondary addresses associated with an IP interface.
OTInetGetSecondaryAddress uses the index parameter to
specify which IP interface to obtain secondary addresses for. For the
primary IP interface, set index to kDefaultInetInterface
which is -1. OTInetGetSecondaryAddress uses the count
parameter to know how many secondary addresses to return in the
buffer pointed to by addr. The addr buffer
must be of size count * sizeof(InetAddr) to
hold all of the desired addresses. Use the
fIPSecondaryCount field of the
InetInterfaceInfstructure returned by calling
OTInetGetInterfaceInfo to determine the required size of
the buffer. OTInetGetSecondaryAddress also modifies
count to indicate the number of secondary addresses actually returned
if less than the specified number of secondary addresses are
returned.
The Text Encoding Conversion Manager provides two facilities--the Text Encoding Converter and the Unicode Converter--that your application can use to handle text encoding conversion on the Mac OS.
For further information, see Inside Macintosh: Text Encoding Conversion Manager Documentation.
Version 1.3 of the Text Encoding Converter Manager (TEC) is included with Mac OS 8.1. The HFS Plus volume format introduced with Mac OS 8.1 stores filenames using the canonical decomposition form of Unicode 2.0; several of the TEC 1.3 changes are to support HFS Plus.
Unicode.h into new file
UnicodeConverter.h to avoid confusion as other Unicode-related
functionality is added over the next few months. Unicode.h
includes UnicodeConverter.h, but is otherwise currently empty.kUnicodeCanonicalDecompVariant (TextCommon.h)
to specify a variant of Unicode using canonical decomposition
(maximal decomposition with characters in canonical order). This
constant has the same value as the constant
kUnicodeMaxDecomposedVariant (unsupported in earlier versions of
TEC). (The only other Unicode variant currently supported allows
all defined Unicode characters, and is specified by the constant
kUnicodeNoSubset).kUnicodeUseHFSPlusMapping (UnicodeConverter.h),
which can be used for the mappingVersion field of a UnicodeMapping
structure to specify the mapping version used by HFS Plus. (The
only other constant specifying a value for this field is
kUnicodeUseLatestMapping).tecUnicodeConverterFeatures field of the TECInfo structure
returned by TECGetInfo, to indicate new bug fixes/enhancements in
TEC 1.3. These bits are:
kTECTextRunBitClearFixBit
ConvertFromUnicodeToTextRun &
ConvertFromUnicodeToScriptCodeRun now function correctly if the
kUnicodeTextRunBit is clear (previously their determination of
best target encoding was incorrect).
kTECTextToUnicodeScanFixBit
ConvertFromTextToUnicode mappings can now depend on context and
saved state. There are several related changes:
kTextMalformedInputErr.ConvertFromTextToUnicode accepts the control flags
kUnicodeLooseMappingsMask, kUnicodeKeepInfoMask,
kUnicodeStringUnterminatedMask.InitializeUnicode and TerminateUnicode to
InitializeUnicodeConverter and TerminateUnicodeConverter, for the
same reasons as in (a) above. This should not be a problem, since
we have not previously released a version of the static library.
However, the old names are still exported by the static library,
just in case.TECGetAvailableSniffers which occurred
in low-memory situations.TECGetTextEncodingFromInternetName was sensitive to the case
of the Internet name passed in, even though Internet names are
supposed to be case-insensitive.TECCreateOneToManyConverter and
TECCreateOneToManyConverterFromPath should return paramError if
the numOutputEncodings is 0.kUnicodeStringUnterminatedBit control
flag to be used with ConvertFromUnicodeToText (...ToTextRun,
...ToScriptCodeRun). This control was previously documented for use
with these APIs (and the supporting code was implemented).
However, if it was used, the functions returned paramErr, due to
an error in parameter validity checking.ConvertFromUnicodeToTextRun
(...ToScriptCodeRun) when the kUnicodeTextRun control flag is clear;
in this case these functions were making bad guesses about the
best target encoding.ConvertFromUnicodeToTextRun (...ToScriptCodeRun) could enter
infinite loop when running out of buffer space after executing a
fallback handler.ConvertFromUnicodeToText
(...ToTextRun, ...ToScriptCodeRun) for Unicode in UTF-8 format: Errors
in direction resolution (and a crash when handling bidirectional text), and
errors recovering from scanning ahead too far for text element
boundaries.ConvertFromUnicodeToText (...ToTextRun, ...ToScriptCodeRun),
the kUnicodeVerticalFormBit was ignored when converting to any
Japanese variant except kJapaneseStandardVariant and
kJapanesePostScriptScreenVariant.CreateUnicodeToTextRunInfo (and the ...ByEncoding and
...ByScriptCode forms) so that if 0 is passed for number of
mappings/encodings/scripts or if NULL is passed for the array, it
only creates entries for the script variants that are installed,
instead of for all of the possible variants for each installed
script.ConvertFromTextToUnicode (previously, these were only intended for
use with ConvertFromUnicodeToText, ...ToTextRun, ...ToScriptCodeRun):
kUnicodeLooseMappingsMask, kUnicodeKeepInfoMask,
kUnicodeStringUnterminatedMask.ConvertFromTextToUnicode scanner to emit
context-dependent information that can affect the mappings, and
provided for saving scanner state in the TextToUnicodeInfo
structure if kUnicodeKeepInfoMask is set. Enhanced the mapping
table formats to permit mappings that depend on context
information from the scanner and on tolerance information (i.e.
whether loose mappings are requested).ConvertFromTextToUnicode encounters an invalid sequence
of bytes in a particular encoding--such as 0x8120 in
Shift-JIS--it now reports kTextMalformedInputErr
(previously, it attempted to look up the invalid combination and
returned kTECUnmappableElementErr).Among other things, the changes listed below ensure 100% round trip fidelity for strict mapping in either direction (non-Unicode to Unicode and back or vice versa) for both Mac OS encodings and other non-Unicode encodings.
kUnicodeCanonicalDecompVariant variant of Unicode; the mapping
version for these tables is kUnicodeUseHFSPlusMapping. These
tables are located in the Text Encoding Converter extension
itself, rather than in files in the Text Encodings folder (note
that some of these tables also support other mappings, such as
Shift-JIS, EUC-CN, Big-5, and EUC-KR). Note: This Unicode variant
is currently not supported by the high-level Text Encoding
Converter.ConvertFromTextToUnicode is called with the
kUnicodeLooseMappings bit set, then the mapping of 0x30-0x39
digits in MacArabic and MacFarsi depends on the context, in a
manner similar to how the WorldScript I display of these digits
depends on context. If the 0x30-0x90 digits are preceded by Latin
letters or other "strong European" characters, they display as
"Western" digits in WorldScript I, and they are mapped to Unicode
characters 0030-0039. Otherwise, they are displayed with the
Arabic digits forms in WorldScript I, and they are mapped to the
Unicode characters 0660-0669. |
Roman, Croatian, Icelandic, Turkish |
0xBD |
|
Greek |
0xAF |
|
Symbol |
0xE1 and 0xF1 |
|
Japanese |
0x8591, 0x85AB-AD, 0x85BF-C1, 0x865D, 0x869E, 0x86CE, 0x86D3-D6, 0x87FB-FC |
|
Hebrew |
0xC0 |
|
Farsi TrueType variant |
0xA4 |
|
Symbol |
0xE6-EE, 0xF4, 0xF6-FE |
We also changed the mapping for several Mac OS Korean characters that were using two "combining disambiguation tag transcoding hints" to just use one. This affected 0xA14F-50, 0xA16A, 0xA170, 0xA198, 0xA19F, 0xA245-46, 0xA64E, 0xA78A, 0xA78E, 0xA792.
|
Devanagari |
Deleted obsolete mappings for byte pairs 0xF0B5, 0xF0B8, 0xF0BF |
|
Gurmukhi |
Deleted mappings for byte pairs xB4E9, xB5E9, xBAE9, xBFE9, xC0E9, xC9E9. Changed the mapping for 0x91 |
|
Arabic AlBayan variant |
0x81 should be unmappable |
|
Mac OS VT100 font encoding |
Added mappings for 0xE2, 0xE3, 0xF5, 0xF6 |
|
Korean |
Added mappings for many additional characters (these are all in the Apple extensions area) |
GetTextEncodingName) to have "Shift-JIS" in romaji instead of
katakana.|
|
Acrobat version of this Note (124K). |
|
