[OSASK 2098] Re: for adarrel3.

["Solid" <kimura !Atmark! mb.meidensoftware.co.jp>]

  こんにちは、Solidです。

川合 さんは 2001/09/11 11:20 の「[OSASK 2097] Re: for adarre
l3.」で書きました：

>  これはよほど致命的な問題がない限りはやりません（設計ミスが原因
>のバグがあるとか）。僕はソースレベルでの互換を互換だとは思ってい
>ないのです（笑）。

私もソースレベルでの互換というのは互換では無いと思っていますけど、
古い APIを使ったバイナリの実行を保証するのはもちろんなのですが、
再コンパイルで 新しい APIに対応できれば良いかもと思ったので・・・
(新機能的 APIに対応ではなく、APIの改善や APIの拡張との互換という意味で)

例えば DirectXですが、既にバージョン８になっています・・・
もちろんバージョン１のバイナリも動けば、バージョン８の SDKで
バージョン１のバイナリを作る事もできます。でも速度や機能は
旧来のままです・・・もちろん DLLの改善によりバージョン１の
バイナリでも速度アップされていますが、本格的に速度を改善したい
と思ったら新しいバージョン用に書き直さねばなりません・・・
(DirectDraw2→DirectDraw3とか・・・)
DirectXは年に一度か二度更新されてきたため、「追加された新機能を
使うわけではなくても」、新しいインターフェースに適応させたいと
思っただけで、毎回単純作業を強いられました。
新機能を覚えるだけで、１年が終わってしまう日曜プログラマーには
実に無駄な作業でした。
再コンパイルで最新の(機能は使えなくても)パフォーマンスが
得られる道があったら、それはそれでうれしいと思いますし、
自動的に機能拡張がされれば理想的でしょう・・・
例えばレンダリングの APIにフィルタリングの機能があったとして、
再コンパイルにより高精度なフィルターが使えるようになるとか
(ゲーム機のソフトがエミュレーターを通す事により、美麗になるのと同じ効果)
が再コンパイルで実現できれば、おもしろいと思いました。
(加えて新機能が新機能の APIの追加だけで使えれば、より理想的です)

Linuxのようにソースレベル「でしか」互換を取れないというのではなく、
バイナリレベルの互換を取ったうえで、ソースレベル「まで」互換性の敷居を
下げるとバイナリ互換以上にアグレッシブなパフォーマンスアップが期待
できという道があるならば、ソースレベル互換も私は大歓迎です。

>  よくありません。僕はこの手の仕組みが失敗の始まりになると信じて
>います。僕がこういうAPIを設計することはありません。誰かが設計す
>る分にはとがめたりはしませんが、川合秀実推奨は付けないでしょう。
>
>  API自身は互換性を維持する義務を負わないし、アプリがAPIのバージ
>ョンを区別する手段すら提供すべきではない、というのが僕の主張です
。

私には、そんな魔法のような仕組みを考案する事は無理だと思ったので、
川合さんなら何か考えがあるのかも？と思って聞いてみました。

昨今の OSの肥大化のひとつに似たような APIの乱立があると思います。
OSASKのサイズの小ささは言うまでもありませんが、他の開発中 OSの多くも
最初は小さく、機能が増えて大きくなり、OSとしてひとつの形になった後、
バージョンアップの度に肥大化していきました。
OSASKの優位を疑うものではありませんが、一通りの機能のみに限定
して比較すれば、他の OSもかなり小さいのでは？というのが私の意見です。
(絶対値ではなく Windowsや Linuxとの相対比です・・・、基準が大き過ぎますが)

多くの傍観者は OSASKのサイズのコンパクトさを、機能の実装が少ないから
当然と思っているでしょうし、パフォーマンスについても同様だと
考えていると思います。今後 OSASKの実装が増えどこまでアドバンテージを
維持できるかが、その答えになるかと思いますので、今後とも開発への
変わらぬ意欲をお願い致します。

>  たとえば5年くらい先には、今のぐいぐい00仕様はそのいい加減な設
>計方針のせいですたれるでしょう（笑）。その頃にはぐいぐい01仕様が
>提唱されているかもしれません。しかしこの時代になってもぐいぐい00
>仕様のアプリは全て無修正で動きます。それは、ぐいぐい00仕様-ぐい
>ぐい01仕様ブリッジがシェルの責任で提供されるからです。このブリッ
>ジの実態は、アプリケーションからは「GUIGUI00」そのものに見えるDL
>Lで、内部は「GUIGUI01」のファンクションを呼び出す関数の集まりで
>しかありません。

このブリッジが私の心配を杞憂に終わらせてくれるような気がします。

＊ 小柳さんが賛同してくれましたシンボル定義ですが・・・、
私は変数名ひとつにも頭を悩ます方なので、どなたかお願い致します。
(小柳さんどうですか？)

それでは