高度な検索
Developer Connection
Member Login ログイン | ご入会 ADC連絡先

Technote 1121

Mac OS 8.1

Version 1.0

目次

Finder 8.1
HFS Plusボリューム形式
ファイルマネージャのディスクキャッシュ
スタートマネージャ
PCI Macintoshのサウンド
MathLib v3
ADBマネージャ
アピアランスマネージャ
PC Exchange
作業環境マネージャ2.0.1
仮想メモリ
ファイルシステムマネージャ
DriverGestaltの追加
Mac OS Runtime for Java 2.0
Open Transport 1.3
テキストエンコーディングコンバータマネージャ1.3
 		Mac OS 8.1では多くのテクノロジーが追加又は変更されました。このテックノートではMac OS 8.1の変更によってデベロッパが影響を受ける点を中心に解説します。

註：
このテックノートで紹介されている変更点の多くは該当するインタフェースファイルの変更を伴っています。新しいインタフェースファイルは次のUniversal Headers（3.0.1以降）で提供されます。

Finder 8.1

Finder 8.1の変更点は以下の3種類があります。

また、Finder 8.1では新たに2つのGestaltセレクタフラグが定義されています。

新しい機能

  • ボリューム形式の表示欄がディスクボリュームの情報ウインドウに追加されました。
  • フォルダのリスト表示ウインドウに項目のソート順を切り替えるためのボタンが追加されました。AppleScriptからは「container window」クラスの「sort direction」属性を変更することによって、ソート順が変えられます。
  • コマンド+シフト+Wを押すと、ポップアップウインドウも閉じることが可能です。また、コマンド+シフト+ オプション+Wを押すとポップアップウインドウを含め、すべてのウインドウが閉じられます。どちらのキー操作を行って場合でも、ポップアップウインドウは「通常のウインドウ」となります。
  • LaserWriter 8の新しい印刷機能に対応しています（Mac OS 8.1英語版のみ）。詳しくはTechnote 1112「Introducing the LaserWriter Driver Version 8.5.1」をご覧下さい。
  • GetVolParmsInfoBufferのvMAttribフィールドのbSupportsAsyncRequestsフラグが認識されます。ファイルマネージャのリクエストを非同期に処理できるファイルシステムはこのフラグをセットして下さい。
  • GetVolParmsInfoBufferのvmVolumeGradeフィールドが認識されます。ファイルシステムを開発するデベロッパはこのフィールドの値を「-1 * 転送速度（バイト／秒）」に設定して下さい。Finderは各コピー作業の開始時にこの値を見ますので、ファイルシステムは状況に応じて、動的にこの値を変更しても構いません。例えば、ネットワークの信頼性やサーバにログインされているユーザの数で転送速度が変動するような場合はvmVolumeGradeを変更します。


現存機能の改良

  • ファイルのコピー作業に要する時間は多くの場合、大幅に短縮されています。
  • ウインドウを開いた時の描画や再描画が早くなりました。


バグフィックス

AppleScript機能を含め、多くのバグが直っています。また、Finderの内部も部分的に書き換えられ、安定性が大幅に向上しています。

FinderのAppleScriptに関するバグフィックス

  • typeIconFamilyデータタイプが再びサポートされています。
  • 新規フォルダの作成や名前の変更が正しく記録されます。
  • コピーする際に「replacing conflicts」を指定するとコピーが正常に行われます。
  • 「entire contents」の処理コードは書き換えられており、安定して動作します。
  • 表示オプションダイアログでチェックされていない表示項目を指定しても、Finderは誤動作しません。
  • kAEFinderSuiteのkAESyncイベント（'fndr' 'fupd'）はFinder 7により近い動作をします。ただし、Finder 7とFinder 8の根本的な設計の違いから、まったく同等に処理することは不可能です。
  • ファイルタイプの比較は大文字や小文字も識別されます。
  • 複製や移動の「with routing suppressed」オプションが正しく動作します。
  • Finder 8.0以前の問題も含め、メモリリークがいくつか除去されました。多くは「whose」節の処理の際に、デスクリプタが残っていたものです。また、トーケンデスクリプタのトーケンハンドルが残ってしまう問題も解決されました。
  • リンク先の無いエイリアスを展開する際はエラ-5018（afpObjectNotFound）が正常に返されます。
  • プロセスについても、「whose」節が正しく処理されます。


その他のバグフィックス

  • DTSのサンプルコード通りにRAMディスクと名乗るボリュームについて、Finder 8.0はファイルメニューの「片付ける」項目を使用不可能にします。これはMac OSのRAMディスクを利用するユーザにとって親切と思われていましたが、一部のサードパーティのRAMディスクには思わぬ症状がでていました。Finder 8.1ではRAMディスクが選択されていても、「片付ける」メニュー項目が使用できるままとなります。
  • Finder 8.0はデータサイズが1024バイトを超えるドラッグフレーバの一部のみをDragReferenceに保存していました。
  • flavorNotSavedフラグがセットされていたフレーバを含むドラッグ操作の場合、Finder 8.0はクリッピングファイルを正しく作成していませんでした。クリッピングファイルに保存される項目数の値が大きすぎていました。Finder 8.1はflavorNotSavedを正しく処理するとともに、Finder 8.0によって作成された「壊れた」クリッピングファイルに対応しています。
  • Finder 8.0はまれに、必要もないのにカスタムアイコンファイルを作成してしまうことがありました。Finder 8.1ではこのようなことはありません。
  • Finder 8.1はアイコンの選択された順序を正しく認識します。アイコンの選択順序は続けて「開く」や「プリント」を実行する場合に重要となります。
  • PowerPCアプリケーションの情報ウインドウのみに表示されていた「仮想メモリを“入”に設定すると、必要メモリが...」メッセージはCFM-68Kアプリケーションの情報ウインドウにも表示されます。
  • Finder 8.0は処理中であっても、カーソルを時計アイコンに切り替えないことがありました。Finder 8.1はカーソルの切り替え頻度が改善されました。


Gestalt

Finder 8や上記の変更に伴い、Mac OS 8.1のFinderは以下のGestaltセレクタフラグを新たに定義しています。

enum
{
    gestaltFinderFloppyRootComments = 8,
    gestaltFinderLargeAndNotSavedFlavorsOK = 9
};


gestaltFinderFloppyRootCommentsフラグがセットされていると、フロッピーディスクのデスクトップデータベースのコメントはユーザが入力できるエリアです（情報ウインドウでメモなどが入力可能です）。フラグがセットされていないと、フロッピーディスクのデスクトップデータベースのコメントはFinderが内部で使用しているため、メモ欄としては使用できません。Mac OS 8以降ではFinderがコメントエリアを内部で使用しており、このフラグはセットされていませんが、Finderが将来コメントを内部で使用しなくなると、このフラグはセットされます。

gestaltFinderLargeAndNotSavedFlavorsOKフラグはクリッピングファイルに関して、上記の2つのバグが対処されているかどうかを示します。Mac OS 8.1ではこのフラグはセットされています。

上記のフラグを見る前に、必ずMac OS 8以降であることを確認して下さい。また、Mac OS 8では上記のフラグは2つともセットされません。

HFS Plusボリューム形式

Mac OS 8.1はアップルコンピュータの新しいボリューム形式HFS Plus（Mac OS拡張）をサポートします。このボリューム形式はHFSボリューム形式をサポートする32MB以上の記憶装置で利用できます。

Mac OS 8.1の利点

Mac OS拡張形式の主な利点はアロケーションブロックが小さくなったことです。実際に使用されるアロケーションブロックのサイズは以下の通りです。

ボリューム全体の容量 デフォルトアロケーションブロックサイズ

<= 256MB

512

<= 512MB

1K

<= 1GB

2K

> 1GB

4K



ボリューム全体の容量が1GBを超える場合は4Kのアロケーションブロックが使用されますが、この値は以下のような根拠に基づいて選ばれました。

  • アロケーションブロックのサイズを小さくすることによって、ブロック数が増えます。しかし、アロケーションブロックの数が増えれば増えるほど、フラグメンテーションが起きやすくなります。
  • 仮想メモリのページサイズは4Kです。アロケーションブロックが4Kの倍数であれば、仮想メモリのページがフラグメント化することはありません（ただし、仮想メモリファイル自体がフラグメント化することは避けられません）。
  • HFS形式のボリュームで一般的に使用されているファイルのフォークサイズを調査したところ、アロケーションブロックのサイズを縮小させると、ボリュームの無駄な領域が比例して減りました。しかし、アロケーションブロックのサイズを4K以下に更に小さくしても、ボリュームの無駄な領域は比例して小さくなりませんでした。2Kから8Kの間が明確に最適な値でした。
  • I/Oは小さな単位（512バイト）よりも、大きな単位（一度に4Kから16K以上の処理）で行うとパフォーマンスが向上します。


将来の利点

Mac OS拡張形式はユニコードのファイル名、長いファイル名、拡張属性などをサポートしています。ただし、Mac OS 8.1ではこれらの機能を利用するためのAPIはありません。Mac OS拡張形式はファイルマネージャを利用するデベロッパが製品を変更しなくても、そのまま対応できるように設計されています。

註：
ユニコードのファイル名を直接利用するためのAPIは用意されていませんが、Mac OS拡張形式のボリュームではファイルマネージャは内部でファイル名をユニコード形式で保存しています。ユニコードのファイル名がディスクのカタログに保存される順序はHFS形式のRelString ()の順序とは異なります。このため、ディスク上でファイルが記録されている順番に依存するアプリケーションは動作が多少変わってくることがあります。


Mac OS 8.1ではファイルマネージャのAPIが多少変更されました。具体的には拡張ボリュームの情報を得る方法や初期化のオプションを指定するAPIがあります。これらの変更は近日中にHFS Plusに関するテックノートやMac OS拡張ボリューム形式についての文献で詳しく解説されます。

註：
ファイルマネージャのドキュメンテーションに記載されていないローメモリ変数を直接アクセスするアプリケーションはMac OS 8.1では動作しない可能性が高いです。ほとんどのローメモリ変数はHFS Plusのサポートに伴い、取り除かれました。

ファイルマネージャのディスクキャッシュ

ファイルマネージャは記憶装置への情報の書き込みや読み取りを行います。

複数のブロックを一度に処理するI/Oの場合、ディスクキャッシュのパフォーマンスが大幅に向上しています。キャッシュを利用して複数のブロックを処理するI/Oは体感速度が早くなりました。

スタートマネージャの変更点

Mac OS 8.1ではコンピュータ起動時に機能拡張をロードする順番が制御できるよう、スタートマネージャが変更されました。コンピュータが起動すると、最初の機能拡張がロードされる前に機能拡張のテーブルが作成されます。ブートコードはこのテーブルを元に機能拡張のロード順を決定します。

Mac OS 8.1の機能拡張テーブルマネージャが登場するまでは、機能拡張は3つのフォルダ（機能拡張、コントロールパネル、システムフォルダ）からディスクに記録されている順序のままロードされました。HFSのボリュームでは、ファイルはRelString ()順（ファイル名がRelString ()によってソートされた場合の順序）にカタログに記録されています。この順序はファイルマネージャのGetFInfo ()を呼び出しても変わりません。

Mac OS 8.1では新たなブート可能なディスク形式（HFS Plus）が登場しました。HFS Plusのボリュームは内部でファイル名をユニコード形式で保存しているため、ファイル名が記録されている順序はMac OS標準形式と異なります。機能拡張はディスクのカタログに登場する順番でロードされていたため、HFSとHFS Plusのディスクでは機能拡張のロード順が変わってしまう事態となりました。

註：
アップルコンピュータでは、機能拡張の動作をロード順に依存させることを勧めていません。しかし、ロード順に依存する機能拡張が多くあるのが現実です。


ユーザの混乱を避けるためにも、機能拡張がボリューム形式を問わず同じ順序でロードされるための機能拡張テーブルを管理する仕組がスタートマネージャに追加されました。機能拡張はデフォルトでRelString ()順にソートされます。従って、どんなボリュームにおいても、機能拡張は同じ順序でロードされます。

機能拡張テーブルマネージャには機能拡張のロード手順を監視及び変更するための仕組が用意されています。この仕組についてはテックノートが近日中にリリースされる予定です。

PCI Macintoshのサウンド

Mac OS 8.1ではPCI Macintosh用のサウンドソフトウェアにいくつかの追加点や変更点があります。ここではデベロッパが影響される点について解説をします。

追加

サウンド入力マネージャにOSTypeのセレクタを渡すことによって、サウンドのソースが変更できるようになりました。これによって以下の設定が変更できるようになりました。

  • サウンド入力
  • 音を鳴らす

内蔵のサウンド入力ドライバには以下の4つのセレクタが追加されました。

enum
{
    siMonitorAvailable      = 'mnav',
    siMonitorSource         = 'mons',
    siOSTypeInputSource     = 'inpt',
    siOSTypeInputAvailable  = 'inav'
};



上記のセレクタと新しい定数を使うと、入力ソースなどが変更できます。例えば、内蔵CDの音源を録音するには以下のようなコードを書きます。

inline OSErr SetInputSource (long soundRefNum, OSType inputSource) {
    return SPBSetDeviceInfo (soundRefNum, siOSTypeInputSource, &inputSource);
}


inputSourceは予めkCDSourceに設定します。

従来使われていたサウンド入力番号は機種によって解釈が違っていたため、OSTypeで入力ソースを指定する仕組に切り替わりました。

現在定義されている入力ソースのセレクタは以下の通りです。

enum
{
    kNoSource         = 'none',     /*ソースなし*/
    kCDSource         = 'cd  ',     /*内蔵CD入力*/
    kExtMicSource     = 'emic',     /*外部マイク入力*/
    kRCAInSource      = 'irca',     /*RCA入力*/
    kTVFMTunerSource  = 'tvfm',
    kDAVInSource      = 'idav',     /*DAVアナログ入力*/
    kIntMicSource     = 'imic',     /*内蔵マイク入力*/
    kMediaBaySource   = 'mbay',     /*メディアベイ入力*/
    kModemSource      = 'modm',     /*モデム入力*/
    kZoomVideoSource  = 'zvpc'      /*ズームビデオ入力*/
};


変更

  • 割り込み用バッファのサイズが小さくなりました。これにより、再生や録音時の延期時間が短縮されました。新しいバッファのサイズは、仮想メモリが「切」だと割り込み時に512サンプルされます（44.1kHzのサウンドの延期時間がおよそ11.6msに短縮されます）。仮想メモリが「入」だと、バッファのサイズは4倍となります。
  • サウンドバッファのサイズはまた固定され、サンプルレートと連動していません。
  • 内蔵のサウンド入力ドライバはsiOptionsDialogをサポートしません。サポートされなくなった理由は以下の通りです。
    • ドライバはユーザインタフェースを持つべきではないと判断されました。
    • ダイアログのユーザインタフェースはMacintoshの機種によってばらつきがあり、操作性もあまり良くありませんでした。
    • QuickTimeのSequence Grabberは同じ機能をサポートしている上、見ためや安定性が高いです。

ユーザインタフェース

サウンドを利用するユーザに快適な環境を提供するため、ユーザインタフェースには以下のような改良点があります。

  • 入力ソースに対して、モニタソースが選択できるようになり、CDなどのアナログ機器の再生が可能になりました。モニタソースを選択するためのコントロールバー項目やモニタ＆サウンドコントロールパネルの項目が追加されました。
  • 内蔵スピーカとヘッドホンポートは再度一つの出力ポートとして見なされます。ヘッドホンポートに再生機器が差し込まれると内蔵スピーカはオフになります。これによって、出力用のユーザインタフェースは1セット（音量、消音など）のみ必要となりました。

MathLib v3

MathLibはC9X準拠に向けて、多くの数学計算関数を提供するライブラリです。すべての関数はIEEE-754及び浮動小数点基準に基づいており、エクセプション、NaN、+0、-0、無限大などに対応をしています。MathLibのインタフェースはfp.hとfenv.hで定義されています。

MathLib v3はMathLibに比べて、パフォーマンスと正確さの面で大幅に改善されています。

パフォーマンス

MathLib v3の関数を均等に使用したテストを行った結果、MathLib v3はMathLibに比べて30%早く処理をしました。

正確さ

MathLib v3の関数は、sinやcosの三角関数を中心に正確さが増しています。ほとんどの関数が改良されていますが、double系の三角関数の正確さはよりlong double系の関数に近くなりました。

MathLib v2の換算に使われていた円周率の値は53ビットでした。MathLib v3ではdouble系とlong double系の演算を近づけるため、円周率の値が107ビットになりました。このため、円計算の結果はMathLib v2とMathLib v3で異なることがあります。

この違いの原因はMathLib v2とMathLib v3が円周率を使って有限的な換算を行っていることにあります（無限換算ではありません）。計算結果は円周率の正確さによって左右されます。MathLib v3では107ビットある円周率がどうしてもパラメータより正確な値なので、境界的な結果がMathLib v2と異なります。例えば、cos (Pi/2)の結果は0.0ではなく、6E-17となります。ただし、この結果はIEEEのdoubleデータタイプの切り捨て範囲に十分収まります。

循環等式や不等式はMathLib v3ですべて保護されますが、正確さは向上しています。例えば、sin (x) ^ 2 + cos (x) ^ 2 = 1はより多くの場合に成立します。

6E-17ではなく、cos (±Pi/2) = 0.0を得るには二つの方法があります。

  • MathLib v2を引き続き利用する。
  • cos (±nPi/2)は特別扱いをして、MathLibを呼び出す前にIEEEの剰余関数で値を処理する。

ただし、MathLib v2を利用することで、MathLib v3のパフォーマンスと正確さの利点が失われます。

ADBマネージャ

Power Macintosh 4400とPower Macintosh 4400ベースのMacintosh互換機では、PS/2の入力装置が接続されていないにも関わらず、あるように見えてしまうバグがありました。ADBマネージャはPS/2の入力装置を正しく認識して、存在しないものを内部テーブルから外すように変更されました。この問題はGame SprocketsやGame Sprocketsを利用するアプリケーションを影響していました。

アピアランスマネージャ

Mac OS 8.1はアピアランスマネージャ1.0.1を含んでいます。ただし、アピアランス1.0.1は単独のSDKとして配付されていないので、開発の際はアピアランス1.0.2 SDKをご利用下さい。SDKにはMac OS 8.1より新しいアピアランスマネージャが含まれていますが、APIの変更はありませんので、そのまま利用しても構いません。

PC Exchange

PC ExchangeはMacintoshのデスクトップにMS-DOSやWindowsのディスクをマウントするためのソフトウェアです。

Mac OS 8.1はPC Exchangeバージョン2.2を含んでおり、以下のような新しい機能をサポートします。

  • Windows 95の長いファイル名（LFN）への対応。
  • FAT32ディスク形式（FAT12やFAT16に加えて）への対応。

長いファイル名のサポート（VFAT）

PC Exchange 2.2はWindows 95の長いファイル名をサポートしており、31文字までのユニコードのファイル名にも対応しています。31文字以上のファイル名は31文字に切り捨てられますが、ユーザがファイル名を編集しない限り、ディスク上では31文字以上のファイル名が保たれます。PC Exchangeはまた、31文字までのWindows 95の長いファイル名を作成することもできます。

Language Kitユーザ

アップルコンピュータのLanguage Kit製品を使っているユーザは、Language Kitで利用されるローマ文字以外の文字をPC Exchange経由でファイル名に使用することが可能です。しかし、このようなローマ文字以外の文字はWindows側で不正な文字として捉えられる場合があります。この場合Windows 95のScanDiskユティリティを走らせると、「Illegal character」などのエラーが表示されますが、「Ignore」を選ばないとファイル名が変更されてしまいます。

ファイル名の保存方式の変更

PC Exchangeの以前のバージョンは今と異なった方式でファイル名を保存していました。PC Exchange 2.2はMicrosoftと同じ方式を取り入れています。例えば、いままでのPC Exchangeでは「helloworld.doc」のようなファイル名はPC上で「!HELLOWO.DOC」として保存されていました。しかし、PC Exchange 2.2では「helloworld.doc」は長いファイル名として「helloworld.doc」、PC上では「HELLOW~1.DOC」として保存されます。いままでのPC Exchangeで作成されたファイルは、ユーザがファイル名を変更をしない限り、変わることはありません。

FAT32のサポート

Windows 95 OSR 2で登場したFAT32ディスク形式はPC Exchange 2.2でサポートされています。

PCディスクの初期化

フロッピーディスクはMac OS、PC、ProDOS形式で初期化することが可能です。また、ボリュームはMacintoshでPC形式として初期化できますが、ハードディスクやリムーバブルメディアの形式を変更することはできません。形式の変更を可能にすると、警告なしにデータを失う可能性があります。

バグフィックス

PC Exchange 2.2ではいくつかのバグが解決されました。なかでも2バイトシステムでの文字列の切り捨てに伴うバグやローレベルなバグが直っております。

作業環境マネージャ2.0.1

作業環境マネージャは一つの名前に複数のコンピュータの設定（作業環境）を保存するためのツールボックスの機能拡張です。例えば、ユーザは良く使う作業環境のプリンタ、ネットワーク設定、機能拡張のセットを登録して、瞬時に切り替えることが可能です。

作業環境マネージャ2.0.1は以下の変更がされています。

  • 動作条件がPowerBookに限定されていない
  • 新しいユーザインタフェース
  • APIの追加
  • 新しい通知
  • 新しいモジュール
  • CFM-68Kのサポート
  • 再起動レベルのエスカレーション
  • バグフィックス
  • 名前
  • SDK


APIの追加

Gestalt ()のgestaltALMAttrセレクタがgestaltALMHasSFLocationを返した場合は、以下のAPIがサポートされています。

extern pascal OSErr
ALMPutLocation (ConstStr255Param            prompt,
                ALMLocationName             name,
                SInt16                      numTypes,
                ConstALMModuleTypeListPtr   typeList,
                ModalFilterYDUPP            filter,
                void*                       yourDataPtr)


ALMPutLocation ()は標準的なインタフェースを使って、作業環境を作成します。通常はnumTypesにkALMAddAllOff又はkALMAddAllOnSimpleを指定し、typeListはNULLとしますが、モジュールタイプの配列を渡すことも可能です。filterとyourDataPtrパラメータはStandard Fileと同様の動きをします。

extern pascal OSErr
ALMMergeLocation (ConstStr255Param            prompt,
                  ALMLocationName             name,
                  SInt16                      numTypes,
                  ConstALMModuleTypeListPtr   typeList,
                  ModalFilterYDUPP            filter,
                  void*                       yourDataPtr);


ALMMergeLocation ()は標準的なインタフェースを使って、既に存在する作業環境に特定の設定を追加します。パラメータはALMPutLocation ()と同様ですが、ALMMergeLocation ()の場合は一般的にモジュールタイプの配列を使用します。

extern pascal OSErr
ALMGetLocation (ConstStr255Param    prompt,
                ALMLocationName     name,
                ModalFilterYDUPP    filter,
                void*               yourDataPtr);


ALMGetLocation ()は作業環境選択ダイアログを表示します。

新しい通知

いままでは、作業環境が変更されるとアプリケーション側で通知を受けることができました。作業環境マネージャ2.0.1からはgestaltALMAttrのgestaltALMHasRescanNotifiersフラグがセットされています。これは新たに作業環境リストの変更（作業環境の削除、名称変更、追加）に伴う通知の受信が可能になったことを意味します。これによって、ユーザが作業環境を変更したために、ALMGetIndLocation ()などで受け取った作業環境の情報が無効になっているかどうかが判ります。

新しいモジュール

作業環境マネージャ1.0.xでは、すべてのモジュールのファイルタイプが'thng'でした。作業環境マネージャ2.0.1では'thng'ファイルは依然サポートされますが、'almn'及び'almb'のファイルタイプが望ましいです。'almn'ファイルは「機能拡張マネージャセット」などの初期設定切り替えモジュールです。一方、'almb'ファイルは「自動オープン項目」などのアクションモジュールです。'almn'と'almb'ファイルの区別は、設定内容がシステム内で判別できるかにあります。アクションモジュールの設定内容を確認するにはユーザに問い合わせる必要があります（例えば、「自動オープン項目」はユーザにファイルの指定を求めます）。

作業環境マネージャを開発するデベロッパは新しいファイルタイプを採用することを勧めます。今後のシステムソフトウェアに作業環境モジュール用のフォルダが追加された場合は、新しいファイルタイプを採用していないと、モジュールは自動的に指定のフォルダに移動されません。

CFM-68Kのサポート

作業環境マネージャ2.0.1ではすべてのAPIがCFM-68Kから利用できます。

再起動レベルのエスカレーション

作業環境マネージャ1.0.xでは、モジュールがkALMSetCurrentSelectセレクタで呼び出されると* flagsは必ずkALMNoChangeとなっていました。作業環境マネージャ2.0では、この値は現在の設定のエスカレーションレベルとなっています。具体的には、いままでに呼び出されたすべてのモジュールが指定した設定のエスカレーションレベルです。例えば、特定の作業環境が「機能拡張マネージャセット」を含んでいて再起動を必要としている場合は、モジュールは再起動が終わるまでアクションをとる必要がないと判断することが可能です。

バグフィックス

  • 作業環境マネージャ2.0.1以前では、機能拡張（'INIT'）からALMSwitchToLocation ()を呼び出すことが出来ませんでした。
  • 作業環境マネージャ2.0以前では、ALMConfirmName ()のusers filterProcは両方のダイアログで呼び出されていませんでした。作業環境マネージャ2.0からは両ダイアログで呼び出されます。現在表示されているダイアログの識別はウインドウのrefConを参照します。すべてのダイアログ項目は定数として定義されています。
  • ALMSwitchToLocation ()実行中に、モジュールから再びALMSwitchToLocation ()を呼び出すことが可能でした。この行為はエラーを返すように変更されました。
  • モジュールのオープン時はエラーを返すことができませんでしたが、これが可能になりました（必要なハードウェアが存在しない場合などはモジュールを表示しないことが可能です）。

名前

アップルコンピュータは「作業環境マネージャ」と言う名称を変更する可能性があります。モジュールフォルダなどの項目名に頼らず、必ずFindFolder ()を使用して下さい。

SDK

作業環境マネージャ2.0.1のSDK（Apple Location Manager 2.0.1 SDK）は1998年1月のMac OS SDK CDに入っています。また、必要となるインタフェースファイルはUniversal Interfaces 3.0.1に含まれています。

仮想メモリ

仮想メモリマネージャはMac OSの仮想メモリを管理します。

Mac OS 8.1の仮想メモリマネージャはパフォーマンスの向上を目的に改良されています。多くの改良点は目に見えないところでされていますが、アプリケーションが直接仮想メモリを制御するための変更点もあります。

システムレベルの変更点

  • コードフラグメントマネージャが利用している仮想メモリのファイルマッピングコードが大幅に書き換えられました。仮想メモリが「入」の状態では、コードフラグメントの初期処理に要する時間が大幅に短縮されました。
  • 仮想メモリはDriverGestaltのkdgVMOptionsセレクタをサポートしています。仮想メモリマネージャやメモリコントロールパネルはこのセレクタでディスクドライブが仮想メモリのどの機能に対応しているかを見分けます。

仮想メモリのページ制御API

アプリケーションは仮想メモリのページ制御APIを利用することで、仮想メモリを最大限に有効活用できます。仮想メモリのページ制御APIを利用すると、以下のヒントを仮想メモリマネージャに伝えることができます。

  • 今後予想されるメモリページの利用状況。
  • 今後利用されないページの指定。
  • 今後変更される可能性の低いページの指定。
  • 二度と利用しないデータを含むページの指定。

仮想メモリページ制御APIが存在するかどうかを確認する

仮想メモリページ制御の4つのAPI（MakeMemoryResident ()、MakeMemoryNonResident ()、FlushMemory ()、ReleaseMemoryData ()）が存在する場合はgestaltVMAttrセレクタのgestaltVMHasPagingControlフラグ（4ビット目）がセットされます。

Boolean VMHasPagingControl (void)
{
    long response;
        if ((Gestalt (gestaltVMAttr, &response) == noErr) &&
            ((response & (1L << gestaltVMHasPagingControl)) != 0))
        return true;
    else
        return false;
}



仮想メモリページの属性

Mac OSの仮想メモリページは属性を持つことができます。ページの属性によっては、ページがメモリにロードされたり、取り除かれたりする際のふるまいが変わってきます。Mac OSの仮想メモリマネージャがどのようにページの属性を解釈しているかを理解することで、仮想メモリのページ制御APIの使い方が明らかになるはずです。

ページはロードされている場合（物理的にメモリに存在する場合）とロードされていない場合（物理的にメモリに存在しない場合）があります。

註：
HoldMemory ()で保護されているページやLockMemory ()、LockMemoryContiguous ()、LockMemoryForOutput ()でロックされているページは常にロードされています。


ロードされているページはcleanとdirtyのどちらかの属性を持つことが可能です。cleanページはメモリから取り除かれる際に内容が保存されません。一方、dirtyページはメモリから取り除かれる際に内容が仮想メモリのファイルに保存されます。

ロードされていないページはディスク上で有効とディスク上で無効のどちらかの属性を持つことが可能です。ディスク上で有効なページがメモリにロードされる場合はページの内容が実際に読み込まれます。一方、ディスク上で無効なページはメモリにロードされても、内容は読み込まれません。

註：
データフォーク内のCFMコンテナのファイルマッピングに使用される仮想メモリページは常にclean（ロードされている時）とディスク上で有効（ロードされていない時）です。


MakeMemoryResident

アドレス空間の一部をメモリにロードさせるにはMakeMemoryResident ()を利用します。MakeMemoryResident ()を利用することで、仮想メモリマネージャは今後利用されそうなページを予めロードすることができます。

pascal OSErr MakeMemoryResident (void *address,
                                 unsigned long count);

address   ロードするメモリの開始アドレス
count     ロードするメモリのバイト数


解説

MakeMemoryResident ()はaddressアドレスからcountバイトをメモリにロードします。

ddressがページの境界に位置しない場合は直前のページ境界が使用されます。また、指定された範囲がページの境界に終わらない場合は最後のページの境界が使用され、指定領域を含むすべてのページがロードされます。

MakeMemoryResidentはできるだけ効率良くページをロードします。また、ロードされたページの属性はすべてcleanとなります。

特記事項

MakeMemoryResidentはメモリの移動やパージをしませんが、割り込み時は使えません。

指定されたアドレス空間はメインメモリの特定メモリ空間の一部（システムやプロセスマネージャのメモリ空間）又はファイルマップ空間の一部でなければなりません。

アセンブリ言語情報

MakeMemoryResident関数に対するトラップマクロおよびルーチンセレクタは次のように定義されています。

トラップマクロ セレクタ

_MemoryDispatch   $000B

ルーチン開始時のレジスタの内容

D0    セレクタコード
A0    ロードするメモリの開始アドレス
A1    ロードするメモリのバイト数

ルーチン終了時のレジスタの内容

D0    リザルトコード

リザルトコード

noErr                  0  エラーなし
paramErr             -50  指定されたアドレス領域が不正です
notEnoughMemoryErr  -620  指定空間をロードするための空領域がありません


MakeMemoryNonResident

アドレス空間の一部をメモリから取り除くにはMakeMemoryNonResident ()を利用します。MakeMemoryResident ()を利用することで、仮想メモリマネージャは今後利用されないページを予めメモリから取り除き、他のページをロードするための空領域を準備することができます。

pascal OSErr MakeMemoryNonResident (void *address,
                                    unsigned long count);

address   取り除くメモリの開始アドレス
count     取り除くメモリのバイト数


解説

MakeMemoryNonResident ()はaddressアドレスからcountバイトをメモリから取り除きます。

addressがページの境界に位置しない場合は直前のページ境界が使用されます。また、指定された範囲がページの境界に終わらない場合は最後のページの境界が使用され、指定領域を含むすべてのページがメモリから取り除きます。

指定領域内のdirtyページの内容は一度ディスクに保存され、ディスク上で無効の属性となります。

HoldMemory ()で保護されているページや、LockMemory ()、LockMemoryForOutput ()でロックされているページはメモリから取り除かれず、フラッシュのみされます。

特記事項

MakeMemoryNonResidentはメモリの移動やパージをしませんが、割り込み時は使えません。

指定されたアドレス空間はメインメモリの特定メモリ空間の一部（システムやプロセスマネージャのメモリ空間）又はファイルマップ空間の一部でなければなりません。

アセンブリ言語情報

MakeMemoryNonResident関数に対するトラップマクロおよびルーチンセレクタは次のように定義されています。

トラップマクロ　セレクタ

_MemoryDispatch   $000D

ルーチン開始時のレジスタの内容

D0    セレクタコード
A0    取り除くメモリの開始アドレス
A1    取り除くメモリのバイト数

ルーチン終了時のレジスタの内容

D0    リザルトコード

リザルトコード

noErr                  0  エラーなし
paramErr             -50  指定されたアドレス領域が不正です


FlushMemory

アドレス空間の一部をcleanにするにはFlushMemory ()を利用します。メモリにロードされているページがディスクの内容と一致する保証が必要な時に便利です。また、今後変更されないページをcleanにすることで、メモリから取り除かれた際のI/Oの負担を下げることが可能です。

pascal OSErr FlushMemory (void *address,
                          unsigned long count);

address  フラッシュするメモリの開始アドレス
count    フラッシュするメモリのバイト数


解説

FlushMemoryはaddressアドレスからcountバイトをcleanにします。指定領域内のdirtyページはすべてディスクに保存されます。メモリにロードされているページはそのままメモリに残ります。

addressがページの境界に位置しない場合は直前のページ境界が使用されます。また、指定された範囲がページの境界に終わらない場合は最後のページの境界が使用され、指定領域を含むすべてのページがフラッシュされます。

特記事項

FlushMemoryはメモリの移動やパージをしませんが、割り込み時は使えません。

指定されたアドレス空間はメインメモリの特定メモリ空間の一部（システムやプロセスマネージャのメモリ空間）又はファイルマップ空間の一部でなければなりません。

アセンブリ言語情報

FlushMemory関数に対するトラップマクロおよびルーチンセレクタは次のように定義されています。

トラップマクロ　セレクタ

_MemoryDispatch   $000E

ルーチン開始時のレジスタの内容

D0    セレクタコード
A0    フラッシュするメモリの開始アドレス
A1    フラッシュするメモリのバイト数

ルーチン終了時のレジスタの内容

D0    リザルトコード

リザルトコード

noErr                  0  エラーなし
paramErr             -50  指定されたアドレス領域が不正です


ReleaseMemoryData

アドレス空間の一部の内容を解放します。メモリの内容を解放することによって、ページの無駄な読み込みや書きだしを減らすことが可能です。

pascal OSErr ReleaseMemoryData (void *address,
                                unsigned long count);

address  解放するメモリの開始アドレス
count    解放するメモリのバイト数


解説

ReleaseMemoryDataは指定された領域内のデータが不必要になったことを仮想メモリマネージャに伝えます。

addressがページの境界に位置しない場合は一つ繰り上がったページの境界が使用されます。また、指定された範囲がページの境界に終わらない場合は一つ繰り下がったページの境界が使用されます。従って、実際に解放されるバイト数は指定バイト数より少ない場合があります。

指定領域内でメモリにロードされているページの属性はすべてcleanとなり、内容も破棄されます（ディスクに保存されません）。また、メモリにロードされていないページの属性はディスク上で無効となります（註：読み込み専用のファイルマップ領域はディスク上で無効となりません）。ReleaseMemoryDataに引き続きMakeMemoryNonResidentを呼び出すと、指定された領域内のページはすぐに他の目的に再利用できる状態となります。

特記事項

特定の領域を解放した後同じ領域内をアクセスした場合、領域の内容は保証されません。

ReleaseMemoryDataはメモリの移動やパージをしませんが、割り込み時は使えません。

指定されたアドレス空間はメインメモリの特定メモリ空間の一部（システムやプロセスマネージャのメモリ空間）又はファイルマップ空間の一部でなければなりません。

メモリマネージャはNewPtr ()、NewHandle ()、TempNewHandle ()、InitZone ()後にReleaseMemoryData ()を呼び出しますので、これらの関数を利用した後はReleaseMemoryData ()を使う必要はありません。

アセンブリ言語情報

FlushMemory関数に対するトラップマクロおよびルーチンセレクタは次のように定義されています。

トラップマクロ	セレクタ

_MemoryDispatch   $000C

ルーチン開始時のレジスタの内容

D0    セレクタコード
A0    解放するメモリの開始アドレス
A1    解放するメモリのバイト数

ルーチン終了時のレジスタの内容

D0    リザルトコード

リザルトコード

noErr                  0  エラーなし
paramErr             -50  指定されたアドレス領域が不正です

ファイルシステムマネージャ

ファイルシステムマネージャは外部のファイルシステムをOSでインストール、認識、制御するための標準的なインタフェースを提供します。Mac OS 8.1にはファイルシステムマネージャ2.0が含まれています。ファイルシステムマネージャ2.0の主な変更点は以下の通りです。

  • gestaltFSMVersionは2.0を返します。
  • 一度に複数のブロックのI/Oを行うUTCacheReadIP、UTCacheWriteIP、UTVolCacheReadIP、UTVolCacheWriteIPはすべてXIOParamブロックを使用するように変更されました。これによって、4GB以上の記憶装置が使えるようになりました。
  • ファイルシステムマネージャの_Controlパッチはアイコンの要求（ffsGetIconMessage経由）に対して、同期的な要求のみに対応します。ffsGetIconMessageは割り込み時に使えないので、非同期的な要求は安全に処理されていませんでした。
  • Mac OS 8で把握したffsGetIconMessageのバグが直っています。
  • ffsUnloadMessageが呼び出されるのは、ファイルマネージャが利用できるタイミングに変更されました。これにより、コードフラグメントマネージャを使ってコードフラグメントを解放することが可能になりました。これまで、ffsUnloadMessageはファイルマネージャが使用中に呼び出されたため、ファイルマネージャを直接的又は間接的に利用するとシステムがデッドロック状態となってしまっていました。
  • まれに、ファイルマネージャの処理枠外でファイルシステムのHFSCIProcを通してMountVolのリクエストがされていました。この時、ファイルマネージャが他の処理を行っている最中にファイルシステムがキャッシュI/Oを開始した場合、システムがクラッシュしていました。ファイルシステムマネージャ2.0からは、ファイルシステムに対するすべてのリクエストはファイルマネージャのコンテキスト内で起こるようになりました。
  • ファイルシステムマネージャはkMaximumBlocksIn4GB以上のidSectorsをサポートしています。
  • ファイルシステムのHFSCIProcを通して行われるMountVolやVolumeMountのリクエストは他のファイルシステムのスタックを利用していた場合があり、スタック容量が足りないとシステムがクラッシュすることがありました。この問題は解決されました。
  • Mac OS 8のディスクキャッシュのバグのため、UTVolCacheWriteIPは正しく動作していませんでした。このバグはMac OS 8.1で直っています。
  • fsmDrvQElChangedMessageでメモリリークの原因となる可能性のあるコードが修正されました。
  • fsmGetFSIconMessageがまれにクラッシュする問題を解決しました。

「Guide to the File System Manager」の改良版は近日中に公開予定です。

DriverGestaltの追加

ドライバのDriverGestaltステータスとコントロールコールはドライバがクライエントに対して提供しているサービス内容を伝えるものです。

Mac OS 8.1では新たに二つのDriverGestaltセレクタが追加されました。新しいセレクタは仮想メモリへの対応や、ドライバがサポートするメディアの属性について情報を伝えるものです。

新しいセレクタは以下の通りです。

kdgVMOptions 仮想メモリへの対応
kdgMediaInfo サポートするメディアの属性

kdgVMOptions

ディスクドライバは仮想メモリへの対応情報をDriverGestaltのkdgVMOptionsセレクタで返します。仮想メモリへの対応情報が求められているディスクドライブはDriverGestaltParamのioVRefNumフィールドで指定されています。このセレクタはドライバではなく、具体的なディスクドライブに対して行われます。

kdgVMOptionsセレクタの結果はDriverGestaltVMOptionsResponse構造体です。その中のvmOptionsフラグを用意されているマスクと比較すると、特定の仮想メモリ動作の組み合わせに対応しているかどうかがわかります。

kdgVMOptionsの有効な結果は現在kAllowVMNoneMask、kAllowVMReadOnlyMask、kAllowVMReadWriteMaskのみです（例えば、kAllowVMWriteBitのみの設定は有効な結果ではありません）。

  • kAllowVMNoneMask: ページフォルトパス（仮想メモリファイルの保存先）にあってはならないドライブを意味します。ソフトウェアでイジェクトの阻止が出来ない手動イジェクト型のメディア、非常に遅い転送レートのドライブ、ネットワークに依存するドライブなどは仮想メモリファイルの保存先には向いていません。
  • kAllowVMReadOnlyMask: 仮想メモリファイルへの書き込みには対応していないが、ファイルマッピングには対応している。WORMドライブ（書き込むごとにディスクの領域を永久的に使用する）やCD-ROMドライブはこの分類に入ります。
  • kAllowVMReadWriteMask: 仮想メモリファイルに対応している。読み書き可能で、手動イジェクトが出来なくて、ネットワークに依存しない高速ドライブがこの分類に入ります。

重要：
ここで定義されていないフラグは将来定義されるまで、すべてゼロに設定して下さい。


kdcVMOptionsの_Controlコールでは、kdcVMOptionsのDriverGestaltリクエストに対する結果を変更することができます。kdcVMOptionsの変更をサポートしないドライバはcontrolErrを返します。また、サポートしていないkdcVMOptionsフラグを要求された場合（例えば、読み込み専用ドライブでkAllowVMWriteBitの要求があった場合）、ドライバはparamErrを返します。

struct DriverGestaltVMOptionsResponse {
    UInt32      vmOptions;
};
typedef struct DriverGestaltVMOptionsResponse DriverGestaltVMOptionsResponse;

/* DriverGestaltVMOptionsResponse.vmOptionsフィールドのビットとマスク */
enum {
    kAllowVMReadBit         = 0,        /* 仮想メモリの読み込み許可 */
    kAllowVMWriteBit        = 1,        /* 仮想メモリの書き込み許可 */
    kAllowVMNoneMask        = 0,
    kAllowVMReadOnlyMask    = 1 << kAllowVMReadBit,
    kAllowVMReadWriteMask   = (1 << kAllowVMReadBit) + (1 << kAllowVMWriteBit)
};


kdgMediaInfo

ディスクドライバはメディアの属性をDriverGestaltのkdgMediaInfoセレクタで返します。メディアの属性が求められているディスクドライブはDriverGestaltParamのioVRefNumフィールドで指定されています。このセレクタはドライバではなく、具体的なディスクドライブに対して行われます。

kdgMediaInfoセレクタの結果はDriverGestaltMediaInfoResponse構造体です。その中のフィールドには物理的なブロックサイズ、ブロック数、メディア種別などの情報があります。

イジェクト可能なメディアについては、現在挿入されているメディアによって、結果値が変わることがあります。

註：
現在定義されているメディア種別はCD-ROMとDVD-ROMしかありません。これはkdgMediaInfoセレクタを利用しているコードがこの二つのメディア種別しかサポートしていないからです。当分の間、他のメディア種別はすべてkMediaTypeUnknownとして下さい。


ファイルマネージャはこのセレクタが返す値を元に、Mac OS拡張形式でドライブを初期化する際のアロケーションブロックサイズを決定します。

struct DriverGestaltMediaInfoResponse {
    UInt32          numberBlocks;   /* ブロック数 */
    UInt32          blockSize;      /* ブロックサイズ */
    SInt16          mediaType;      /* メディア種別 */
};
typedef struct DriverGestaltMediaInfoResponse DriverGestaltMediaInfoResponse;

/* DriverGestaltMediaInfoResponse.mediaType定数 */
enum {
    kMediaTypeUnknown    = 128,   /* メディア種別不明 */
    kMediaTypeCDROM      = 129,   /* メディア種別はCD-ROM */
    kMediaTypeDVDROM     = 130,   /* メディア種別はDVD-ROM */
    kMediaTypeNoMedia    = -1     /* メディアは存在しない */
};


Mac OS Runtime for Java 2.0

MRJ 2.0はサン・マイクロシステムズのJavaバージョン1.1.3に準拠しており、以下の点が新しくなっています（Mac OS 8.1日本語版にはMRJ 2.0の英語版が含まれています）。

  • 国際化
  • セキュリティとアプレットの署名
  • AWTの改良
  • JavaBeansTM
  • JARファイル形式
  • ネットワークの改良
  • I/Oの改良
  • 算術パッケージ
  • リモートメソッドインボケーション
  • オブジェクトシリアリゼーション
  • リフレクション
  • JDBCTM - Javaとデータベースの相互接続
  • インナークラス
  • Java Native Interface
  • パフォーマンスの向上
  • デモ用アプレットのアップデート

詳しくはMac OS Runtime for Javaのホームページをご覧下さい。

Open Transport 1.3

Mac OS 8.1はOpen Transport 1.3をインストールします。Open Transport 1.3はいくつかの新機能とバグフィックスを含みます。

Open Transport 1.3 SDKとOpen Transport 1.3リリースノートもアップデートされています。

バグフィックス

一般

  • Appleリモートアクセス3.0はPPP接続をする度に256バイトのメモリリークを起こしていました。このメモリリークは他の接続プロトコルでも発生していた可能性がありますが、バグは解決されました。
  • 機能拡張マネージャ4.0以降に対応するための'CCITM'リソースを必要に応じて修正または追加しました。
  • Open Transportのデバッグ用バージョンから不必要なデバッガブレークを取り除きました。取り除かれたデバッガブレークはPCI PowerBookや非PCI Power Macintoshの起動時に毎回起こっていたブレークを含みます。
  • シリアルポートが正常に登録されない場合がありましたが、Open TransportのCRMInstall ()のパッチを修正して対応しました。この問題は特にGlobal VillageのPlatinum Pro PCカードを影響しており、PPP接続の際に「シリアルポートは使用中です」と言うメッセージが表示されてしまう問題でした。
  • ADSPやATPエンドポイントでDDPオプションが使えない問題を解決しました。
  • 68KやCFM-68KのクライエントがPowerPC上で走るとOTUseSyncIdleEvents ()がクラッシュする問題を解決しました。
  • OTOpenEndpoint ()とOTAsyncOpenEndpoint ()はエラーの際に無効なEndpointRefを返すことがありました。エラーの際は必ずNULLを返すように変更しました。
  • InitOpenTransport ()がASLMのライブラリから呼び出された際のメモリリークを直しました。
  • 待機専用エンドポイントが着信できなくなるtilistenモジュールのバグを解決しました。Open Transportイベント発生の際に待機中のエンドポイントがkOTStateChangeErrを返してしまうのが症状でした。
  • tilistenモジュールのメモリリークを修正しました。
  • OTConnect ()が同期的に呼ばれると、定期的にkOTSyncIdleEventイベントをnotifierに送信するように修正しました。
  • OTSndDisconnect ()がまれにT_MEMORYRELEASEDイベントで渡されたcookieパラメータを壊すことがありました。この問題はOTSnd ()などのAckSends要求付きの送信イベントがタイミング悪くOTSndDisconnect ()処理中に発生した場合に起こる問題でした。

Open Transport Debugger Preferences（Open Transportのデバッグ用バージョンのみ）

  • OT Debugger PreferencesはMacsBug Preferencesフォルダに保存されます。
  • OTErrorsの内容を更新しました。
  • putnextを呼び出したモジュール名と次のメッセージブロックを受け取るモジュール名を表示するためのマクロ（modnameとmodnext）を追加しました。上記のマクロを正しく使用するためには、R3レジスタがモジュールのキューエレメントを指していなければなりません（putnextの先頭でブレークをかけた状態です）。
  • qnameとdmsgマクロを追加しました。
  • MSGTypesテンプレートにあるM_CTLの値を修正しました。
  • module_infoをPowerPCでも正常表示するように修正しました。
  • 68Kコンピュータでmodule_infoを表示するためのmodule_info68kを追加しました。
  • メッセージチェーンのメッセージブロックが一覧できるようにmsgb::fNextの定義をmsgbに変更しました。

AppleTalk

  • Appleリモートアクセス3.0がデフォルトゾーン（セレクタで選択されているゾーン）を設定できなくなるバグを解決しました。
  • メモリ残量が少ない状態でLocalTalkを利用した時にクラッシュする問題を解決しました。
  • セレクタでデバイスを選択する度に、デバイスファイル（例えばLaserWriter 8）に'STR ' -4090リソースが重複して追加される問題を解決しました。この問題はゾーンが存在しない場合のみ起きていました。また、放っておくとデバイスのファイルが壊れることがありました。
  • 新しいIRTalkのリソースを採用することで、一部のデスクトップ機でIRTalkが正常に動作しない問題を解決しました。
  • PAP接続が閉じられたあとに、待機用のエンドポイントからSendDataのリクエストが送信されてしまう問題を解決しました。
  • PAPサーバが一度に複数のセッションを持った時に起こる問題を解決しました。PAPサーバは複数のセッションを開いていたものの、実際には一度に一つのセッションしか処理していませんでした。複数のセッションを並列処理するように修正されました。
  • PAPが64K以上のトランザクション（240MB以上のファイル）に対応できるようにしました。いままでは64Kを超えた時点でカウンタがリセットされていました。
  • LocalTalk経由のデータ送信を伴うOT関数がPower MacintoshでD3レジスタの内容を変更してしまう問題を解決しました。このバグは68KコードがOpen Transportの送信関数（例えばOTSnd ()）を含むPowerPCコードを呼び出した際によく発生していました。68Kコードに帰ってきた時点でD3レジスタの内容は変更されてしまっていました。
  • ATALK_IOC_FULLSELFSENDマクロを直しました。
  • Appleリモートアクセス3.0がARAPプロトコルで接続中にサーバが手動で再起動されると、サーバへの接続がすぐに切られてしまうのに、クライエント側は「あと1分でサーバが停止します」メッセージを表示していました。

TCP/IP

  • サーバが二つ目のパケットを送信するまでの時間を短縮しました。これにより、HTTPのパフォーマンスが向上します。

リンク

  • オプションマネージメントによって、Ethernetエンドポイントをプロミスキュアスモードに設定する場合、無限ループとなるバグがありましたが、tpi8022xモジュールを直しました。
  • Ethernetエンドポイントのローモードで1500バイトのパケットが1486バイト分しか送信できないバグがありましたが、tpi8022xモジュールを直しました。

APIの変更

  • シングルリンクマルチホーミングが新たな機能として加わったため、kInetInterfaceInfoVersionを3にしました。詳しくはシングルリンクマルチホーミングの記述をご覧下さい。
  • OTCreatePCMCIAPortRefをOTCreatePCCardRefに変更し、参照バス名もkOTPCCardBusに変更しました。
  • ローモードのデータを含むNetbufsの定数（kOTNetbufIsRawMode）を追加しました。
  • mi_open_detachedを追加しました。"OpenTptModule.h"では定義されていましたが、Open Transportのライブラリでは正しくエキスポートされていませんでした。mi_open_detachedはmi_open_commと良く似ていますが、モジュールが実際に開かれる前に使用できます。これは、上下のキューで別々のq_ptrデータを使っていて、下のキューのq_ptrデータをI_LINKの受信前に確保したい場合に便利です。
  • CFMのコードフラグメント内で複数の'ndrv'に対応している8.0.1のDriverLoaderLibをサポートしています。
  • CFMのポートスキャナと設定ルーチンがサポートされています。PowerPCの場合はこれらのルーチンをASLMで用意する必要がなくなりました。これはOpen Transport 1.1.1でもできましたが、ライブラリを（CFMのプライベートSPI経由で）CFMに登録する必要がありました。Open Transport 1.3は起動の際に拡張'cfrg'リソースを含む機能拡張フォルダのすべての'shlb'と'libr'ファイルを参照して、拡張'cfrg'リソースの内容を元にポートスキャナと設定ライブラリを検索します。拡張'cfrg'リソースは以下のように構成にして下さい。 

#define UseExtendedCFRGTemplate 1
#include "OpenTransport.r"
#include "CodeFragmentTypes.r"
resource 'cfrg' (0)
{
  {
    extendedEntry {
    kPowerPC,
    kFullLib,
    kNoVersionNum,      /* 現在のバージョン*/
    kNoVersionNum,      /* 古いバージョン */
    kDefaultStackSize,
    kNoAppSubFolder,
    kIsLib,
    kOnDiskFlat,
    kZeroOffset,
    kWholeFork,
    "XYZProtocolRS_ConfiguratorLib",    /* 'cfrg'の拡張情報 */
    kOTCFMClass,
    kOTConfiguratorCFMTag,
    "",
    "",
    "XYZProtocol"       /* ユーザに見えるプロトコル名 */
    }
  }
};


ポートスキャナの場合はkOTPortConfiguratorCFMTagのかわりにkOTPortScannerCFMTagを指定します。

CFM-68Kのサポート

  • CFM-68Kが正式にサポートされています。詳しくはOpen Transport CFM-68K Developer Note（OT SDKの一部）をご覧下さい。Open Transport 1.3は自動的にCFM-68Kのサポートに必要なファイルをインストールします。

シングルリンクマルチホーミング

Open Transport 1.3は新たにシングルリンクマルチホーミング（一つのハードウェアインタフェースで複数のIPアドレスのサポート）に対応しています。シングルリンクマルチホーミングは他ではIPエイリアス、セカンダリIPアドレスサポート、IPマスカレード、マルチホーミング、IPマルチノードサポートなどの名称があります。この機能はインターネットサービスプロバイダ（ISP）などで一つのコンピュータに複数のクライエントを管理して、各々に独自のIPアドレスを割り当てる場合に便利です。この機能を利用すれば、ウェブサーバやサーバプラグインはすべてのウェブブラウザに対応できるようなバーチュアルドメインを作成することが可能です。

シングルリンクマルチホーミングは通常のOpen Transportクライエントを影響しません。以下の説明はTCP/IPサーバをシングルリンクマルチホーミングに対応するための情報です。

重要：
以下でも記述されていますが、マルチホーミングの環境では特定のIPアドレスにバインドすると、そのIPアドレスに対する接続のみを受けることになります。IPアドレスごとに異なるサービスを提供する場合は良いのですが、IPアドレスを特定したくない場合が多いでしょう。このため、特にシングルリンクマルチホーミングに対応しない場合は受信側のエンドポイントにバインドする際にkOTAnyInetAddressを指定して下さい。アップルコンピュータではエンドポイントのバインド先をkOTAnyInetAddressと指定することを勧めてきました。OTInetGetInterfaceInfo ()が返すIPアドレスを指定してしまうとそのIPアドレスの接続しか受けられませんので、ご注意下さい。


シングルリンクマルチホーミングの設定方法

シングルリンクマルチホーミングはOpen Transport 1.3以降でサポートされています。シングルリンクマルチホーミングを利用する場合は必ずOpen Transportのバージョンを確認して下さい。詳しくはOpen Transportのバージョンの確認方法をご覧下さい。

複数のIPアドレスを指定する手順は以下の通りです。

  • TCP/IPコントロールパネルを「手入力」に設定します。
  • システムフォルダの初期設定フォルダ内に「IP Secondary Addresses」と言う名称のテキストファイルを作成します。

IP Secondary Addressesファイルの各行には一つのIPアドレスとオプションのサブネットマスクとルータアドレスを記入します。サブネットマスクが記入されていない場合はデフォルトのサブネットマスクが使われます。また、ルータアドレスが記入されていない場合は主要IPアドレスのルータアドレスが使われます。

IPアドレスを指定する行は"ip="で始まらなければなりません。また、サブネットマスクは"sm="、ルータアドレスは"rt="を先頭に記述します。以下はIP Secondary Addressesファイルの例です。

; 'ip=' IPアドレス, 'sm=' サブネットマスク, 'rt=' ルータアドレス
;  註：'ip=192.168.22.200'はスペースがありません。
;
; IPアドレス              サブネットマスク        ルータアドレス
;-----------             -----------          ----------------
ip=192.168.22.200        sm=255.255.255.0     rt=192.168.20.1
ip=192.168.22.201                             rt=192.168.20.1
ip=192.168.22.202


IPアドレスの登場順は重要です。また、"rt="を指定する場合は必ず"sm="の後に指定して下さい。

Open Transport 1.3でTCP/IPが立ち上がると、主要IPアドレスはTCP/IPコントロールパネルの設定となります。次にIP Secondary Addressesファイルが読み込まれます。IP Secondary Addressesファイルの重複したIPアドレスはすべて無視されます。また、ネットワーク上に既に使われているIPアドレスがあると、Open Transportはエラーダイアログを表示して、TCP/IPを「切」にします。エラーダイアログには問題となったIPアドレスとIPアドレスを所有する機器のハードウェアアドレスが表示されます。

Open Transportのバージョンの確認方法

Open Transport 1.3以降の存在を確認するには、gestaltOpenTptVersionsセレクタ（'otvr'）でGestalt ()を呼び出します。結果値がkOTIPSingleLinkMultihomingVersion以上であることを確認して下さい。

enum
{
        kOTIPSingleLinkMultihomingVersion = 0x01300000 // OT 1.3
};


InetInterfaceInfo構造体の変更

OTInetGetInterfaceInfoはローカルホストについて情報を返します。Open Transport 1.3ではInetInterfaceInfoが拡張されて、複数のIPアドレスを返すようになりました。新しい構造体は以下のように定義されています。

struct InetInterfaceInfo
{
    InetHost          fAddress;
    InetHost          fNetmask;
    InetHost          fBroadcastAddr;
    InetHost          fDefaultGatewayAddr;
    InetHost          fDNSAddr;
    UInt16            fVersion;
    UInt16            fHWAddrLen;
    UInt8*            fHWAddr;
    UInt32            fIfMTU;
    UInt8*            fReservedPtrs[2];
    InetDomainName    fDomainName;
    UInt32            fIPSecondaryCount; // 追加IPアドレスの数
    UInt8             fReserved[252];
};


上記の構造体をOTInetGetInterfaceInfo ()に渡すと、fIPSecondaryCountには主要IPアドレス以外の追加IPアドレスの数が入ります。複数のIPアドレスが存在する場合はOTInetGetSecondaryAddresses ()でアドレスが取得できます。

いままでのInetInterfaceInfoと区別するために、OTInetGetInterfaceInfo ()はfVersionに3を返します。

OTInetGetSecondaryAddresses

関数

OTInetGetSecondaryAddressesは追加IPアドレスを返します。

Cインタフェース

OSStatus OTInetGetSecondaryAddresses (InetHost *addr, UInt32 *count, SInt32 index);


C++インタフェース

なし。C++のクライエントはCインタフェースを使用します。

解説

パラメータ

呼びだし前

呼びだし後

addr

x

(x)

count

(x)

(x)

index

x

/



OTInetGetSecondaryAddressesはIPインタフェースの追加IPアドレスを取得します。取得するIPアドレスはindexパラメータで指定します。主要IPアドレスを得るにはindexを-1（kDefaultInetInterface）とします。addrにコピーするIPアドレスの数はcountで指定します。addrバッファのサイズはcount * sizeof (InetAddr)以上必要です。すべてのIPアドレスを取得する場合は、OTInetGetInterfaceInfoが返すInetInterfaceInfo構造体のfIPSecondaryCount値に応じてバッファを割り当てます。OTInetGetSecondaryAddressesは実際に返した追加アドレスの数をcountにコピーします。

テキストエンコーディングコンバータマネージャ1.3

テキストエンコーディングコンバータマネージャはMac OSでテキストエンコーディングを変更するための設備（テキストエンコーディングコンバータとユニコードコンバータ）を提供します。

詳しくはInside Macintosh: Programming with the Text Encoding Conversion Managerをご覧下さい。

Mac OS 8.1にはテキストエンコーディングコンバータマネージャ（TEC）1.3が含まれています。Mac OS 8.1のHFS Plusボリューム形式はユニコードの分解モードでファイル名を保存しています。TEC 1.3の変更点の多くはHFS Plusへの対応です。

インタフェースファイルの変更

  • Unicode.hの内容をUnicodeConverter.hに移動しました。この変更は今後数ヵ月の間に登場するユニコード機能がUnicode.hに入るため、混乱を防ぐ狙いがあります。Unicode.hはUnicodeConverter.hを含みますが、それ以外は空です。
  • 分解モード形式を指定するための定数（kUnicodeCanonicalDecompVariant）をTextCommon.hに追加しました。この定数はkUnicodeMaxDecomposedVariant（TECの以前のバージョンでは未サポート）と同じ値です。（もう一つサポートされているユニコード形式はkUnicodeNoSubsetですが、この形式は全文字に適応します）。
  • kUnicodeUseHFSPlusMappingをUnicodeConverter.hに追加しました。HFS Plusのマッピングを指定する場合、UnicodeMappingのmappingVersionフィールドをこの定数にセットします。
  • TECGetInfo ()が返すTECInfoのtecUnicodeConverterFeatures値は以下のようなフラグが追加又は変更されています。

    kUnicodeTextRunBitがセットされていない場合でも、kTECTextRunBitClearFixBit、ConvertFromUnicodeToTextRun、ConvertFromUnicodeToScriptCodeRunは正常に動作します。以前は最適なターゲットエンコーディングが実際とは異なっていました。

    kTECTextToUnicodeScanFixBitとConvertFromTextToUnicodeマッピングはコンテキストや保存内容に依存させることが可能です。これに伴い、以下のような変更点があります。

    • 不正入力はkTextMalformedInputErrとなります。
    • ConvertFromTextToUnicodeはkUnicodeLooseMappingsMask、kUnicodeKeepInfoMask、kUnicodeStringUnterminatedMaskのコントロールフラグを受け付けます。
    • Mac OS ArabicとHebrewをユニコードに変換する場合はライティングディレクションのオーバライドが重複していましたが、これは無くなりました。
    • Mac OS Arabicでルーズマッピングを指定した場合の0x30-0x39の数字のマッピングが改善されました。
    • Mac OS Indicではコンテキストに依存するマッピングが改善されています。
  • インタフェースファイルの名称変更と同じ理由から、ライブラリの初期化関数と終了関数InitializeUnicodeとTerminateUnicodeをInitializeUnicodeConverterとTerminateUnicodeConverterに変更しました。スタティックライブラリをリリースしていないのでデベロッパには影響がないはずです。しかし、万が一のために、古い名称は引き続きエキスポートされています。

バグフィックス

メモリ残量が少ない場合にTECGetAvailableSniffersがクラッシュする問題を解決しました。
インターネットの名称は大文字と小文字を識別しないのに、TECGetTextEncodingFromInternetNameは大文字と小文字を識別していました。このバグを直しました。
TECCreateOneToManyConverterとTECCreateOneToManyConverterFromPathでnumOutputEncodingsに0を指定するとparamErrorを返すように変更しました。
ConvertFromUnicodeToText（...ToTextRun、...ToScriptRun）でkUnicodeStringUnterminatedBitコントロールフラグが使えるようになりました。このコントロールフラグはパラメータチェックの段階でparamErrを返して実質的には使えませんでしたが、この問題は解決しました。
kUnicodeTextRunコントロールフラグがセットされていない状態でConvertFromUnicodeToTextRun（...ToScriptRun）を呼びだすと、最適なターゲットエンコーディングが選ばれないことがありました。この問題は解決しました。
UTF-8形式のユニコードフォーマットでConvertFromUnicodeToText（...ToTextRun、...ToScriptCodeRun）を利用すると、ライティングディレクションやテキストエレメントの境界検索が失敗して、エラーを返していました。また、複数のライティングディレクションを含むテキストの場合はクラッシュする問題がありましたが、これらは解決されました。
ConvertFromUnicodeToText（...ToTextRun、...ToScriptCodeRun）でkJapaneseStandardVariantとkJapanesePostScriptScreenVariant以外の日本語形式に変換を行うとkUnicodeVerticalFormBitは無視されていました。
CreateUnicodeToTextRunInfo（...ByEncodingと...ByScript形式）はマッピング、エンコーディング、スクリプト数がゼロ、又は文字列がNULLの場合、インストールされているスクリプトvariantの項目のみが作成されます。以前はインストールされているスクリプトに対して、すべてのvariantの項目が作成されていました。

改良点

  • ConvertFromTextToUnicodeでkUnicodeLooseMappingsMask、kUnicodeKeepInfoMask、kUnicodeStringUnterminatedMaskコントロールフラグが利用できるようになりました。以前はConvertFromUnicodeToText（...ToTextRun、...ToScriptCodeRun）のみで利用可能でした。
  • ConvertFromUnicodeToTextスキャナはマッピング変更用のコンテキスト情報を出力するようにしました。また、kUnicodeKeepInfoMaskフラグがセットされていると、TextToUnicodeInfoにスキャナの状態を保存できるようにしました。マッピングテーブルもこのようなコンテキスト情報や属性に対応できるように変更しました。
  • ConvertFromTextToUnicodeは不正エンコーディング（例えばシフトJISの0x8120）に対してkTextMalformedInputErrを返すようにしました（以前はエンコーディングをマップしようとして、kTECUnmappableElementErrを返していました）。
  • 今回のリリースはUnicode Converter & Text Commonスタティックライブラリを含んでいます。ただし、使用するにはTEC 1.3の機能拡張とテキストエンコーディングフォルダが存在しなければなりません。

マッピングの変更

ユニコード／非ユニコード間を往復して変換しても、テキストの内容が完全に保たれるようにマッピングが改良されました。これはMac OSエンコーディングとMac OS以外の非ユニコードエンコーディングにおいて、厳密にマッピングをした場合に適応します。

  • Mac OSエンコーディングとユニコードのkUnicodeCanonicalDecompVariant形式用のマッピングテーブルが追加されました（マッピングによってはシフトJIS、EUC-CN、Big-5、EUC-KRサポートも含まれています）。このマッピングテーブルはkUnicodeUseHFSPlusMappingで参照します。また、このマッピングテーブルはテキストエンコーディングコンバータ機能拡張自体に含まれており、テキストエンコーディングフォルダのエンコーディングファイルとしては保存されていません。
  • Mac OS Arabic、Farsi、Hebrewをユニコードに変換するとライティングディレクションのオーバライドが重複していましたが、これは無くなりました。
  • Mac OS Arabic、Farsiをユニコードに変換する時にkUnicodeLooseMappingsフラグがセットされた状態でConvertFromTextToUnicodeを呼び出すと、0x30-0x39の数字のマッピングはWorldScript Iと同じようにコンテキストによって左右されます。0x30-0x39の数字の先頭にローマ字があると、西洋系の数字（ユニコード0030-0039）にマップされます。一方、先頭にローマ字がないと、アラブ系の数字（ユニコード0660-0669）にマップされます。
  • EUC-CNとBig-5のスキャナが正しいバイト範囲を利用するよう修正しました。
  • 分解モード値が1文字のユニコードにマップされた文字の場合は、分解モードを利用するマッピングに切り替わります。この変更は以下のマッピングを影響します。

    Roman、Croatian、Icelandic、Turkish 0xBD
    Greek 0xAF
    Symbol 0xE1、0xF1


  • Mac OS Romanianのマッピングの一部（0xAF、0xBF、0xDE、0xDF）はCOMBINING COMMA BELOWを利用するようにしました。
  • MacJapaneseとシフトJISのユーザ定義範囲をマッピングに追加しました。
  • アップルコンピュータで利用している文字をグループトランスコーディングヒントとして定義しました。これらの文字が2、3、4の標準的なユニコード文字の先頭にあると、そのグループがトランスコーディングの対象となります。こうすることによって、ユニコードには含まれていないが、アップルコンピュータで利用している文字はユニコードの文字列とトランスコーディングヒントで表わすことができます。以前は一文字にマップされていたMac OSエンコーディングの以下の文字が変更されました。

    Japanese 0x8591、0x85AB-AD、0x85BF-C1、0x865D、0x869E、0x86CE、0x86D3-D6、0x87FB-FC
    Hebrew 0xC0
    Farsi TrueType形式 0xA4
    Symbol 0xE6-EE、0xF4、0xF6-FE
    また、トランスコーディングヒントを二つ利用していたMac OS Koreanの文字（0xA14F-50、0xA16A、0xA170、0xA198、0xA19F、0xA245-46、0xA64E、0xA78A、0xA78E）をすべて一つ利用するように変更しました。
  • Mac OSエンコーディングは他に以下の変更がされました。

    Devanagari 0xF0B5、0xF0B8、0xF0BFのマッピングはもう使用されないので、削除しました。
    Gurmukhi 0xB4E9、0xB5E9、0xBAE9、0xBFE9、0xC0E9、0xC9E9のマッピングは削除しました。また、0x91のマッピングを変更しました。
    Arabic AlBayan形式 0x81はマップができないようにしました。
    Mac OS VT100
    フォントエンコーディング    		 0xE2、0xE3、0xF5、0xF6のマッピングを追加しました。
    Korean 新たにマッピングを追加しました（アップルコンピュータの拡張文字）。


  • Mac OSエンコーディングのkUnicodeLooseMappingsではLINE SEPARATORをRETURN（以前はLINE FEED）に変更しました。


ユーザインタフェースの変更

  • Mac OS 8.1ではテキストエンコーディングコンバータの機能拡張は必須です。機能拡張マネージャでテキストエンコーディングコンバータの機能拡張を「切」にすることはできません。また、機能拡張フォルダから手動で外したり、ブート時に見つからないとFinderは注意のアラートを表示します。
  • シフトJISの日本語の名称（GetTextEncodingName ()が返す文字列）をカタカナの「シフトJIS」からローマ字の「Shift-JIS」に変更しました。