http://en.wikipedia.org/wiki/MacPaint
>The original MacPaint consisted of 5,804 lines of Pascal
>source code, augmented by another 2,738 lines of 68000
>assembly language.
昔、MSX2でMacPaintみたいな感じのお絵かきツールを作ろうとして、スプラッシュスクリーン（Welcome to とかでるやつ)を作って、画面を灰色に塗潰し、メニューバーを作成して高速でドロップダウンするメニューを実装したところで、32KBの限界に近づいてしまい、あきらめたことがあります。VRAMの未使用領域にあらかじめアプリケーションのメニューをビットマップで作っておいて、画面にブロック転送とかやっていたのですが、後にMacPlusを買って勉強してみて、メニューマネージャーやらウィンドウマネージャーやらの豊富なAPIを見て「ずるいよ！」とか思いました。
誰かやってみる？ (スコア:0)
基本動作はもちろん同じで
Re:誰かやってみる？ (スコア:0)
Re:誰かやってみる？ (スコア:1)
Carbonでなんとかなるんでないかな。
もっと問題なのはPascalなんじゃないかってとこだけど。
Re:誰かやってみる？ (スコア:2, 参考になる)
>The original MacPaint consisted of 5,804 lines of Pascal
>source code, augmented by another 2,738 lines of 68000
>assembly language.
だそーですが。
Re:誰かやってみる？ (スコア:0)
当時からGUI周りのAPIは充実していたのでしょうか。
Re:誰かやってみる？ (スコア:3, 参考になる)
初代MacPaintは実はウィンドウは一枚しか開けないし、パレットも移動できないしで、いまどきのPaintソフトに比べると結構チープなところもあります。これはどっっちかというと、APIの不足によるものではなく、当初128kBしかなかったRAMのせいでしょうね。
昔、MSX2でMacPaintみたいな感じのお絵かきツールを作ろうとして、スプラッシュスクリーン（Welcome to とかでるやつ)を作って、画面を灰色に塗潰し、メニューバーを作成して高速でドロップダウンするメニューを実装したところで、32KBの限界に近づいてしまい、あきらめたことがあります。VRAMの未使用領域にあらかじめアプリケーションのメニューをビットマップで作っておいて、画面にブロック転送とかやっていたのですが、後にMacPlusを買って勉強してみて、メニューマネージャーやらウィンドウマネージャーやらの豊富なAPIを見て「ずるいよ！」とか思いました。
Re:誰かやってみる？ (スコア:3, 参考になる)
RAMの大きさもさることながら、CPUは68000の8MHz、ROM64k、OSとアプリケーションとユーザーデータを400kのFDに収容するという仕様で、今から比べると1/1000以下のパフォーマンスでしたので、一見現代風のAPIが用意されていますが、開発には構造化プログラミングの奇麗なコーディングというより、むしろ本物の実力 [genpaku.org]が必要だったと思いますよ。初期のアプリケーションはアセンブラで書かれていたとも噂されていましたがどうなんでしょう。
ToolBox関数を使って直に描画すると、ウインドウに点を打っているのがわかるような状態で、オフスクリーンビットマップを作成することを小池邦人さんの本 [ottimo.co.jp]で教えてもらって辛うじて動くプログラムになりました。タイトルバー、サイズボックスなどの作成や、ウインドウの移動などの処理も全て自分でやらなければなりませんでした。ジャンプや変数の参照に8ビット相対アドレスを使うので32kの制限がありましたが、16ビットに増すことによるコードサイズと処理時間増加を気にしなければなりませんでした。OSがガベージコレクションをするのでメモリをハンドル（ポインタのポインタ）で参照することになっていましたが、アクセスを早くするためにポインタのコピーを作ることや、OSがグローバル変数を多用していて、それをアプリケーションがさわることで簡単に暴走したとも言われています。（マッキントッシュの道具箱） [amazon.co.jp]。