このページでは最新のシステムソフトウェアに関する話題を扱っていきます。
仮想記憶がオフのとき、Shared Libraryの"private copy"をロードする際に、テンポラリメモリ・システムヒープに空きがない場合はこれをアプリケーションヒープ中の空き領域にロードする。このアクションでもsizeリソースで指定したminimumメモリパーティションサイズとactualメモリパーティションサイズの差以上にメモリを使うことはない。この機能によって、今までであれば起動できなかった条件でアプリケーションを起動できるようになった。
コードフラグメントをメモリにロードするときはFile Systemのキャッシュをバイパスしている。またBlockMoveDataルーチンを多用することも行っている。これらによってアプリケーションの起動が速くなっている。
内部のローカル変数をsigned longからunsigned longに変更した。このため、アプリケーションが負の数でメモリをアロケートしようとするとModern Memory ManagerはType11エラーを出すようになった。
以前のシステムでは２つ以上のバックグラウンドオンリーアプリケーションが共にMaxApplZoneルーチンを呼ぶとProcess Managerはこれらのプロセスの状態を正しくセーブできず、システムがハングしてしまっていた。このバグはバックグラウンドオンリーアプリケーションの概念が導入されてからこの方ずっと存在していたが、System 7.5.5でようやく除去された。
PowerMac 6100/7100/8100のROMにはフロッピーディスクが入った状態で非同期ファイル動作があるとマシンがハングするバグがあった。これはこのROMがFile Systemについての実験中にFinalizeされたため、内部にいくつかの不適切なルーチンがあったのが原因である。System 7.5.5ではROMの当該ルーチンにパッチを当てることでこの問題を回避している。
以前「System 7.5.3の問題点」としてこの問題にふれた際、PCI Bridgeチップの初期化不良が原因と書いたが、実際は別の原因であった。Macintoshがフロッピーを初期化する際にはフロッピー初期化ルーチンによって作業を行っているが、180MHz超マシンではこのコードが速く実行されすぎるために、フロッピーの表面から裏面へ移る時の待ち時間が足りず、裏面がフォーマットされないまま終了してしまっていた。
System 7.5.5では、この待ち時間タイミングを調整することでフロッピー初期化の不具合を解消している。
存在しない領域のメモリをフラッシュしようとしていた。この状態になると、エミュレータは無限ループに陥ってしまった。System 7.5.5ではレンジチェックを行い、不当な領域をフラッシュしようとした際には動作をキャンセルし、呼び出し元へ抜けられるようにした。
File Managerでも存在しないメモリ領域のフラッシュを試みていた。このため前項と同様にエミュレータが無限ループに陥っていた。
内部で特定のパケットに高すぎるプライオリティを与えていたため、プライオリティの低いパケットのパケット落ちが発生し、低速な通信しかできなかった。System 7.5.5ではこの問題を解決している。
クロックが180MHzを越えるPCI PowerMacで起動時にPCI Bridge Chipの初期化に失敗することがあった。この状態になるとPCIバスは起動中からアクセス不能になり、最終的にはマシン全体がハングする結果になった。System7.5.5では起動時のPCI Bridge Chipの初期化方法を一層信頼性のある方法に変更したため、この問題は解消した。
コントロールパネル（以下cdevと呼称）はFinderのアプリケーションヒープ内にロードされる。MathLibをリンクしたcdevがロードされると、Finderのヒープにはcdev本体の他にMathLibによって生成されたMathLib globals (22Kバイト)もロードされる。FinderヒープにはROM内のMathLibによって生成されたMathLib globalが既に置かれているが、以前のマシンであれば、こちらのMathLib globalsは2Kと小さかったので、全てを合計してもFinderのパージ可能なヒープ領域サイズに収まっていた。
ところがPowerMac 7500/8500/9500ではROM内MathLibによってアロケートされるMathLib globsも22Kバイトの大きさを持っているので、cdevによってもたらされたMathLib globsと合わさるとFinderのヒープをほとんど全て使い切ってしまう。このような状況に陥ると、Finderは度々メモリ不足の警告を表示することになる。
解決策は、Finderのsizeリソースに手を加えて、Finderの使用メモリを増やすことである。
新しいMathLibでは若干数学関数のパフォーマンスが向上しているという。
これらの機種で一度もOpenTransportをインストールしたことがなければ、1.1.1b7のインストーラはインストール不可なる表示をしてインストールしようとしない。
1.1.1b6のインストーラはb6をカスタムリムーブしてから再びインストールしようとした際に、一旦1.1をインストールしてからでないとb6がインストールできないというバグを持っていたが、これをb7インストーラで修正したところ、新たに52xx等の機種で簡単にインストールできないというバグを持たせてしまった。
これは単純にインストーラのスクリプトのバグで、OpenTransport自体がこれらの機種に適合しないわけではない。
解決策：52xx等の機種に1.1.1b7をインストールするにはひとまず1.1.1b6をインストールし、その上に1.1.1b7をインストールするという手順を踏めばよい。
これらのマシンでNSSを使うと、古いマシンリストでOpenTransportの利用の可否を判定するので、事実に反して使用不可の表示が出る。問題は実はこれから後である。NSSはOpenTransportの利用が不可と判定すると、AppleTalkPreferencesにOpenTransportが利用できない旨を書き込んでしまう。このため、NSSを動かしてしまった後は以下の修復作業を行わなければならない。
手順：
FreePPP2.5rfでは次のような不具合があった。
これらを解消するためにOpenTransportチームはMDEVコンパチビリティーモジュール内の"DoLapClose"ルーチンを修正したが、1は実はFreePPP内部の問題に起因しており、FreePPPグループはv2で修正を行った。結果としてOpenTransportチームの行った変更によってFreePPP2.5v2はOT1.1.1b7下で２分から10分程度で回線断を起こすようになってしまった。
解決策：
全てのTCP/IPアプリケーションがQuitすると、TCP/IPスタックは２分間TCP/IPストリームを監視し、その間TCP/IPストリームがなければこのモジュールはメモリ上からUnloadされる。
古いバージョンのOpenTransportでは、このときモジュール全体が完全にUnloadされず、メモリリークを発生していた。これは1.1.1b6以降ある程度改善されている。
TCP/IPコントロールパネルでユーザーモードを"Advanced"以上に設定すると、コントロールパネルウィンドウに"Options..."というボタンが現れるが、ここで"Load only when needed"というチェックボックスをアンチェックしておくと、TCP/IPスタックは起動時にアプリケーションヒープに読み込まれ、TCP/IPアプリケーションの起動とは無関係にメモリ内に常駐する。この方法にしておくと何度もTCP/IPスタックが異なったアドレスにロードされることがないので、メモリリークの被害を局所的な領域に封じ込めることができる。完全にメモリリークの問題が解決するまでこの設定を用いることをお薦めする。