Macアプリ

MacAppは、 Apple Computerの廃止されたクラシックMac OS用のオブジェクト指向アプリケーションフレームワークです。1985年にリリースされ、1991年のバージョン3.0リリースでObject PascalからC++に移行し、 System 7の新機能の多くをサポートしました。MacAppは、 Adobe Photoshop [ 1 ]やSoftPress Freeway [ 2 ]など、様々な主要アプリケーションで使用されました。MicrosoftのMFCとBorlandのOWLはどちらもMacAppのコンセプトを直接ベースとしていました。

10年間にわたり、この製品は開発が停滞した時期と、その後に活発に開発が進められた時期を繰り返しました。この間、シマンテックのThink Class Library / Think Pascalは、よりシンプルなモデルをはるかに高性能な統合開発環境（IDE）で提供し、MacAppの強力な競合製品となっていました。

シマンテックは1990年代初頭のPowerPCプラットフォームへの移行への対応が遅れ、メトロワークスが1994年にCodeWarrior / PowerPlantシステムを初めて導入すると、Macの主要開発プラットフォームとしてMacAppとThinkは急速にその地位を奪われました。Appleでさえ、1990年代半ばの Copland時代にはCodeWarriorを主要開発プラットフォームとして採用していました。

MacAppは、 Mac OS XのCarbonシステムへの移行のためのシステムとして、2000年から2001年にかけて短期間使用されてきました。[ 3 ]しかし、2001年6月に世界開発者会議（WWDC）でバージョンをデモした後、同年10月にすべての開発が中止されました。

歴史

Pascalバージョン

MacAppは、ラリー・テスラーが率いたApple初のオブジェクト指向アプリケーションフレームワークであるLisa Toolkitの直系の後継です。Toolkitのエンジニアリングチームには、ラリー・ローゼンスタイン、スコット・ウォレス、ケン・ドイルが参加していました。Toolkitは、Pascal言語にオブジェクト指向技術を追加したClascalと呼ばれるカスタム言語で記述されました。[ 4 ] [ 5 ]

当初、Mac向けの開発はLisa Workshopのクロスコンパイラを用いて行われていました。Macの販売がLisaの販売を事実上終了したことから、Mac向けの新しい開発プラットフォームの構築が始まりました。Lisa Programmer's Workshopは1985年にMacintosh Programmer's Workshop （MPW）となりました。このプロセスの一環として、ClascalはObject Pascalへとアップデートされ、Lisa Toolkitは後にMacAppとなるものの設計ノートを提供しました。[ 5 ]

アプリケーションフレームワークなしでMacプログラムを書くのは容易なことではありませんが、当時オブジェクト指向プログラミングはまだ比較的新しい分野であり、多くの開発者からやや疑念を抱かれていました。初期のフレームワークは、サイズが大きく、動作が遅く、柔軟性に欠ける傾向があり、この疑念を裏付けるものでした。

MacAppは、あらゆる意味で真に実用的な最初のフレームワークと言えるでしょう。コンパイルされたアプリケーションは、サイズとメモリ使用量の点で非常に妥当なものであり、パフォーマンスも開発者が敬遠するほど悪くありませんでした。最初のリリースでは「シンプルすぎる」と評されましたが、その後のバージョンで主要な問題はすぐに解決されました。1987年頃までに、このシステムは有用なツールへと成熟し、多くの開発者が主要プロジェクトで使い始めました。

MacApp 2.0は1989年にリリースされました。改良点としては、UI要素の操作性の簡素化や、Multifinderのサポートなどが挙げられます。[ 6 ] Appleが1992年にMPW Pascalのサポートを中止すると発表したため、[ 7 ]このバージョンはSystem 7のサポートも含めて更新されず、Pascal開発者はMacApp 2.0をPowerPCに移植する作業を自力で行わなければなりませんでした。[ 7 ] [ 8 ]

C++バージョン

1980年代後半のこの時点では、市場はC++へと移行しつつあり、Apple C++ コンパイラのベータ版は1989年のMacApp 2.0リリース頃に登場した。[ 6 ]同時に、Appleは多くの主要な新機能を含んだSystem 7 のリリースに力を入れていた。そこで、Object Pascalの代わりにC++を使用する、MacAppの完全に新しいバージョンである3.0に移行することが決定された。[ 9 ]この動きは、 Usenetやその他のフォーラムでObject PascalとC++の支持者の間で長く白熱した議論の対象となった。それでも、開発スイートMPWが時代遅れになりつつあったにもかかわらず、3.0は1991年のリリース後、かなりの支持を集めることができた。その後、Appleは開発ツールグループ全体を縮小し、MacAppとMPWは両方とも人員不足に陥った。

この人員削減の理由の一つは、Appleが開発のための「次世代の偉大なプラットフォーム」を導入しようと長年試みてきたことであり、ほとんどの場合、何らかのクロスプラットフォームシステムの形で行われてきた。最初の試みは、Symantecとの提携で作成されたMacとWindowsで動作するクラスライブラリであるBedrockだったが、最終的に両社がお互いに協力することを諦めたため、長く続かなかった。問題の原因の一つは、 Bedrockと直接競合するクロスプラットフォームシステムに開発されたOpenDocの作成であった。BedrockをOpenDocプラットフォームとして位置付けようとする試みがいくつかあったが[ 10 ] [ 11 ]、これは実現しなかった。

これらの開発が進む中、MPWとMacAppはほとんど無視されていました。開発リソースをこれらの新しいプロジェクトに投入し、より早く市場に投入することの方が重要だったのです。しかし、Bedrockが失敗し、OpenDocが冷ややかな反応に終わったことで、Macには10年近くも前のツールが残され、サードパーティの新しい製品に太刀打ちできなくなりました。1990年代初頭には、競合するフレームワークがMacAppの真の競合相手へと成長しました。最初はSymantecのTCLが支持を集めましたが、その後MetrowerksのPowerPlantが市場全体を席巻しました。

長引く死

MacAppのコア開発者たちは、1990年代を通して、活動レベルは低調ながらもシステムの開発を続けました。Appleの「公式」クロスプラットフォームプロジェクトがすべて崩壊した1996年後半、チームはMacAppのクロスプラットフォーム版を提供すると発表しました。

その後まもなく、AppleはNeXTを買収し、OpenStepを今後のAppleの主要開発プラットフォームとしてCocoaの名称で採用すると発表しました。Cocoaは既にクロスプラットフォームであり、当時既に6つのプラットフォームに移植されており、MacAppよりもはるかに先進的でした。しかし、既存のMacプログラマーからは、自分たちのプログラムが「ペナルティボックス」に送られ、事実上放棄されているとして、強い抗議の声が上がりました。

WWDC'98で、スティーブ・ジョブズはCocoaへの移行に関する否定的なフィードバックに対処するため、Carbonシステムの導入を発表しました。Carbonは、既存のMacプログラムをある程度の変換を行えば、新しいオペレーティングシステム上でネイティブに実行できるようにするものです。メトロワークスはPowerPlantフレームワークをCarbonに移植すると発表しましたが、AppleはMacAppに関して同様の発表をしませんでした。

この間も、Appleの態度に不満を募らせるMacAppユーザーの中心は存在し続けました。1990年代後半、Cocoaの導入期には、この不満は製品への完全な拒絶へと発展しました。事態は悪化し、MacAppユーザーの一部は、Appleのスタッフに会議の場を与えられないように、偽名を使ってWWDC '98で独自の会合を開くほどでした。

この継続的なサポートはApple社内でも注目され、1999年後半には、これまでMacAppの開発に携わってきたメンバーで構成された「新しい」MacAppチームが新バージョンのリリースを任されました。新バージョンには、OpenStepから導入された多くの新しいMac OS機能に対応するC++ラッパーのより薄いレイヤーである新しいApple Class Suites（ACS）と、Project Builderでのビルドサポートが含まれていました。MacApp 3.0 Release XVは2001年8月28日にリリースされ[ 12 ]、多くの人々を喜ばせました。しかし、10月に製品は再び、今度は永久に廃止され、MacAppの既存バージョンのサポートは正式に終了しました。

Carbon 準拠の PowerPlant X は 2004 年まで出荷されませんでしたが、今日では Cocoa は MacOS と iOS プログラミングの両方でほぼ普遍的になっています。

今日のMacApp

MacAppは、Appleが2001年にサポートを終了して以来、フレームワークの保守と拡張に尽力してきた熱心な開発者グループによって維持されてきました。MacAppはアップデートされ、Carbonイベント、ユニバーサルバイナリ、Unicodeテキスト、MLTEコントロール、DataBrowserコントロール、FSRef、XML解析、カスタムコントロール、コンポジットウィンドウ、ドロワーウィンドウ、HIViewウィンドウ、カスタムウィンドウを完全にサポートしています。また、MacAppにはHIObjectとHIView用のC++ラッパークラスも用意されています。また、主にMacApp-2をベースにしたPascalバージョンもMac OS XとXcodeに移植されています。長いUnicodeファイル名と、自動バイトスワップ機能を備えたストリーミングドキュメントを特徴としています。

MacAppはXcode IDEをサポートしています。実際、 AppleがIntel CPUへの移行を発表した2005年のWWDCでは、開発者1人がMacAppとMacAppサンプルアプリをUniversal Binary対応にアップデートするのに48時間もかかりました。

説明

この説明は、以前の 2.0 よりも高度な基盤モデルを備え、多くの重要な点で異なる MacApp 3.0 に基づいています。

Mac OS自体は非常にシンプルなイベント処理システムを備えています。オペレーティングシステムからアプリケーションに渡されるイベント構造体には、「キー押下」や「マウスクリック」といったイベントの種類と、その発生場所、そして押下された修飾キーの情報のみが含まれます。このシンプルな情報を、例えばメニューコマンドのクリックといったユーザーが実行したアクションへとデコードするのは、アプリケーションの役割です。画面上のオブジェクトのリストを順に確認し、イベントがそれぞれの境界内で発生したかどうかを確認する必要があるため、このデコードは困難な場合があります。

MacAppは、コマンドパターンを用いてこの問題の解決策を提供しました。コマンドパターンでは、ユーザーアクションはイベントの詳細を含むオブジェクトにカプセル化され、適切なオブジェクトに送信されて実行されます。イベントを「適切なオブジェクト」にマッピングするロジックは、フレームワークとそのランタイム内で完全に処理されるため、このタスクの複雑さは大幅に軽減されます。MacAppの内部機構の役割は、基本的なOSイベントを取得し、それを意味的に高レベルのコマンドに変換し、適切なオブジェクトにルーティングすることです。

MacAppは、すべてのプログラムに必要なこのコードを書く手間を作者から解放しただけでなく、副作用として、コードをコマンド（ユーザー操作）と、そのハンドラー（処理を実行する内部コード）に明確に分離しました。例えば、「青に変える」と「赤に変える」というコマンドは、どちらも単一の関数で処理されますChangeColor()。コマンドとハンドラーを明確に分離したプログラムは、Appleの用語で「ファクタリング」と呼ばれていました。

プログラムのファクタリングは、 System 7以降の Mac OS のバージョンで特に重要でした。System 7 ではApple Eventsシステムが導入され、オリジナルの Mac OS のイベント システムが、OS から特定のアプリケーションだけでなく、アプリケーション間で送信できる、より豊富なイベント システムに拡張されました。これは、これらのイベントをスクリプト コードから生成できるAppleScriptシステムと組み合わされました。MacApp 3.0 では、Apple Events は、直接のユーザー操作によって開始された場合と同じコマンドにデコードされたため、開発者は Apple Events を直接処理するためにコードをほとんど、あるいはまったく書く必要がありませんでした。これは、このような分離がなく、Apple Event のサポートが省略されることが多かった MacApp 2.0 などの初期のシステムを使用していた開発者にとっては大きな問題でした。

アプリケーションフレームワークとしての役割にふさわしく、MacAppにはMacの基本的なGUIの大部分をカバーする多数の既成オブジェクトも含まれていました。ウィンドウ、メニュー、ダイアログ、そして類似のウィジェットはすべてシステム内で表現されていました。しかし残念ながら、Appleは「現実世界」で使用可能なシステムを提供するのではなく、既存のMac OS内部コードに軽量なラッパーを提供することが多かったのです。例えば、このTTEViewクラスは標準のテキストエディタウィジェットとして提供されていましたが、基盤となるTextEditの実装には大きな制限があり、Apple自身もプロフェッショナルアプリケーションには使用すべきではないとしばしば明言していました。その結果、開発者はこうしたニーズに対応するためにアドオンオブジェクトを購入するか、独自に開発せざるを得ませんでした。プロフェッショナル品質のGUIオブジェクトの不足は、MacAppの最大の問題点の一つと言えるでしょう。

これらの問題はMacApp R16のリリースで解決されました。MacApp R16では、すべてのMacApp GUIオブジェクトに標準のCarbonコントロールを使用しています。例えば、CarbonではUnicodeテキストと長文ドキュメントをフルサポートするために、 Multilingual Text Engine（MLTE）が導入されました。R16では、元のクラスはMLTEコントロールを使用する に置き換えられました。TTEViewTMLTEView

注目ユーザー

Adobe Photoshopは、もともとMacApp 1.1.1のObject Pascalで開発され、後にPhotoshop 2.5でC++およびMacApp 3.0に移植されました。AppleによるMacAppの開発中止後、メンテナンスはPhotoshop開発チームによって社内的に引き継がれ、PowerPCに移植され、Windowsプラットフォームへの移植版と共有できるように変換されました。[ 1 ] 2025年現在でも、Photoshop UIのコードにはレガシー要素が残っています。[ 13 ]

参考文献

  1. ^ a bマーク・デイブ（1997年12月）「ショーン・ペアレント：Photoshop開発プロセス」 MacTech第13巻第12号、  42～ 44頁。
  2. ^ 「MacAppの終了により、主要なMac3D/CADソフトウェアに影響が及ぶ」 Architosh 、 2001年10月9日。 2025年12月30日閲覧。
  3. ^ Turner, Mark (2001年3月). 「Carbon: Mac OS Xの必須要素」 . MacTech . 第17巻第3号. pp.  58– 61.
  4. ^ Williams, Gregg (1984年12月). 「ソフトウェアフレームワーク」 . Byte . 第9巻第13号. pp.  124– 127, 394– 410.
  5. ^ a b Loeb, Laurence H. (1988年12月). 「プログラムエクステンダー」 . Byte . 第13巻第13号. pp. MAC 53-MAC 60.
  6. ^ a b Poole, Lon (1989年4月). 「C++とMacApp 2.0」 . Macworld . 第5巻第4号. 91ページ.
  7. ^ a bブライアン・アーノルド、ガイ・マッカーシー（1995年11月）「MacApp Pascalが再び登場」 MacTech第11巻第11号 30～ 31ページ
  8. ^ Arnold, Brian (1996年2月). 「Object Pascalで書かれたPowerPC用MacApp 2」 . MacTech . 第12巻第2号. pp.  25– 32.
  9. ^ Knepper, Chris (1991年2月). 「MacApp 3.0へのアプローチ」 . MacTech . 第5巻第2号.
  10. ^ダモア・ケリー、クインラン・トム（1993年12月6日）「BedrockはAppleが当初計画していたほど強固ではない」 InfoWorld 、第15巻第49号、8ページ。
  11. ^ Daly, James (1993年12月20日). 「AppleとSymantec、Bedrockの役割を再考」 Computerworld .第27巻第51号. 69ページ.
  12. ^ 「新しいMac OS X関連リリース」 MacTech 、第17巻第2号、2001年2月、24ページ。MacApp 15d3 とその機能の一部を紹介します。
  13. ^ Gruber, John (2025-12-19)、「Adobe Photoshop 1.0 Code」、Daring Fireball 、2025年12月19日閲覧。。
「 https://en.wikipedia.org/w/index.php?title=MacApp&oldid=1330327633」から取得