議論/リソース の変更点



 #topicpath
 
 目次
 #contents
 
 * 議論/リソース
 * 議論/リソース [#cd56fbfd]
 
 -超手抜きで24bpp無圧縮BMPをサポートしました。 -- [[Tino]] SIZE(10){2004-04-21 (水) 05:52:19}
 -おぉーーー。これでリバーシのコマを画像に出来ますーー。くろひげもいけそうですね。-- [[ひげぽん]]
 -現時点ではファイルからしか読み込めないので、実際に使うとFDに画像ファイルがちらばってしまってちょっとみっともないことになってしまいます。その辺が問題だなーという気はします。
 
 #comment
 
 ** 各種対策
 ** 各種対策 [#i6f68e14]
 
 -PEではリソースに埋め込むということをしてこれを回避しますが、バイナリの中にデータを埋め込むとリソースエディタがないと自由にいじれなくなってしまって見通しが悪い気がします。 -- [[Tino]] SIZE(10){2004-04-22 (木) 00:05:12}
 --リソースエディタでバイナリをいじるというのはWindowsよりもMac OS<=9で一般的な気がします。Macなんかでは趣味でソフトの中の絵を変えたりする人をリアルでも結構見かけましたが、Windowsでは翻訳以外でリソースを書き換える人はほとんど見たことがありません。 -- [[Tino]] SIZE(10){2004-04-22 (木) 00:20:54}
 --Mac OS<=9と書いたのにはわけがあって、Mac OS XではNeXTSTEP伝統のバンドルという手法が導入されたので全然状況が違うからです。(後述) -- [[Tino]] SIZE(10){2004-04-22 (木) 00:21:45}
 -JPEGDEMOのようにデータを配列化して埋め込むという方法もありますが、これだとバイナリからデータだけを抽出するのが困難なので(ソースが必要)、リソース方式より使い勝手は悪いです。 -- [[Tino]] SIZE(10){2004-04-22 (木) 00:07:44}
 --その意味でMemoryStreamからの読み込みをサポートしても、本質的な解決にはならないということが言いたいわけです。 -- [[Tino]] SIZE(10){2004-04-22 (木) 00:15:08}
 -JavaでいうJAR見たいなのをサポートしてリソース取得という手もありますがいろいろとサポートが必要ですね。 -- [[[[ひげぽん]]]] SIZE(10){2004-04-22 (木) 00:21:22}
 --目の付け所が良いですね。実はJARのアイデアの元になったのが上で少し言及したバンドルなのです。その辺のことは後述します。 -- [[Tino]] SIZE(10){2004-04-22 (木) 00:26:00}
 -リソースで埋め込むのを避けた上でファイルがばらけるのを避ける方法としては、アプリケーションのフォルダにまとめるという方法が思い浮かびます。これはこれでDOS時代からWindows(Program Files以下)にまで受け継がれている方法です。 -- [[Tino]] SIZE(10){2004-04-22 (木) 00:40:07}
 --この方法の問題点としては、アプリケーション本体に一括してパスを通せないということが挙げられます。コマンドライン主体で使う場合には致命的です。 -- [[Tino]] SIZE(10){2004-04-22 (木) 00:41:13}
 -そのためUNIXではアプリケーションごとにフォルダをわけるということはせずに、実行ファイルはパスが通っているところ(例:/usr/local/bin/)に一括して入れて、アプリケーション固有のファイルは/usr/local/share/アプリ名/のようなフォルダに入れるという方法が採られます。 -- [[Tino]] SIZE(10){2004-04-22 (木) 00:43:25}
 --この方法の問題としては、どのファイルがあるアプリに属するものなのかが分かりにくいという点です。UNIXではパッケージの抜き差しという形でまとめられているため実用上の支障はないのですが、ファイルシステムだけを見て構造を理解するのが困難なのには変わりありません。 -- [[Tino]] SIZE(10){2004-04-22 (木) 00:44:51}
 --GNOMEやKDEではこの方針に忠実なファイル構成をしているのですが、とても凄いことになってしまっています。 -- [[Tino]] SIZE(10){2004-04-22 (木) 00:47:43}
 -これに一つの解を出したのがNeXTSTEPです。バンドルといって、フォルダをファイルとして見做すということをします。たとえばMail.app/というフォルダを作って、その中にバイナリやグラフィックのデータなどを入れておいて、Mail.app/というフォルダ自体を1個の実行可能ファイルとして見せかけるという方法です。 -- [[Tino]] SIZE(10){2004-04-22 (木) 00:46:25}
 --このバンドルはNeXTSTEPに由来するMac OS Xにも受け継がれていて、Finder上ではバンドルのフォルダは1個のファイルのように見せています。ダブルクリックするとフォルダの中身が開かれるのではなく、アプリケーションとして起動します。 -- [[Tino]] SIZE(10){2004-04-22 (木) 00:51:00}
 --バンドルをフォルダとして中身を見たいときは、コントロールキーを押しながらダブルクリックします。コンテキストメニューからでもいけたかな。Mac OS Xから遠ざかって久しいので、この辺ちょっと自信がありません。ともかくそういう操作は出来たはずです。 -- [[Tino]] SIZE(10){2004-04-22 (木) 00:53:17}
 -バンドルはOS(というかファイルマネージャ)がサポートしないと自然に扱えないため、どのOSでもホイホイ採用できるものではないという問題があります。 -- [[Tino]] SIZE(10){2004-04-22 (木) 00:54:52}
 --その辺を解決したのがJARというわけです。実体はフォルダをzip圧縮したものなので、ファイルサイズの節約も兼ねています。 -- [[Tino]] SIZE(10){2004-04-22 (木) 00:55:47}
 -実際にNeXTSTEPとJavaにはつながりがあります。NeXTSTEPを色々なOSの上に実装されるレイヤとして再構築してOpenStepとなったのですが、OpenStepはそれ自体がOSとしても、WindowsやSunOS上ではレイヤとしても実行環境を提供していました。SunOS移植の際に、一時期SunはOpenStepに肩入れしようとしていました。 -- [[Tino]] SIZE(10){2004-04-22 (木) 00:57:39}
 --バンドルの中に色々なOS用のバイナリを入れておけば、あたかも一つの実行ファイルが色々なOSの上で動くかのようなことになったわけです。OpenStepでは実際にそれが実現されていました。 -- [[Tino]] SIZE(10){2004-04-22 (木) 01:00:27}
 --これを理想的に運用するためには、バイナリのコンパイルの際には対応されるOSの数だけのバイナリを作らないといけないということが挙げられます。 -- [[Tino]] SIZE(10){2004-04-22 (木) 01:02:08}
 --それではやってられないということで、バイトコードによってバイナリを共通化させるところまで突き詰めたのがJavaなわけです。そのためSunはOpenStepからは離れました。 -- [[Tino]] SIZE(10){2004-04-22 (木) 01:02:56}
 
 #comment
 
 ** パッキング
 ** パッキング [#ub4410d2]
 
 -ちわ。こんなツール&ref(pack.lzh);が転がってたんですが。当座の間に合わせに要ります? -- [[Gaku]] SIZE(10){2004-04-22 (木) 01:18:16}
 --すみませんがどういうことが出来るものなのかよく分かりませんでした。 -- [[Tino]] SIZE(10){2004-04-22 (木) 01:23:22}
 ---1つのファイルの中に文字列とファイルを対応付けて格納するんですが。使うとすれば、InputStream とかカーネル側の fs.cpp とかどこかで↑の stream を使う。とかの用途になりますね。アプリ側で使っても良いですが、それは、それで面倒なので。 -- [[Gaku]] SIZE(10){2004-04-22 (木) 01:54:03}
 --sample フォルダの a.exe を実行してみて、test.c の main を眺めてみてください。あと、肝は stream.h とおまけで stream.c です。 -- [[Gaku]] SIZE(10){2004-04-22 (木) 01:24:21}
 --やってみました。アーカイブから特定のファイルをバッファに取り出すものということでしょうか? -- [[Tino]] SIZE(10){2004-04-22 (木) 01:26:41}
 --ですね。archive のとこの a.exe で a -o x.pak 0.bmp 1.bmp 2.bmp 。。。てな感じでパッキングできます。 -- [[Gaku]] SIZE(10){2004-04-22 (木) 01:31:00}
 -お。ディスクからサンプル探してるうちに・・・。後は zlib が使えるはずなんで、それで圧縮かなぁとか。 -- [[Gaku]] SIZE(10){2004-04-22 (木) 01:21:10}
 -FDだけの運用が続くと、いずれ付属アプリだけで溢れてしまう事態も考えられますね。そうなるとバンドルではなく圧縮パッキングの出番かもしれません。ファイルシステムが自動的にパッキングを解除してくれればアプリ側は何もしなくても対応できるかもしれません。 -- [[Tino]] SIZE(10){2004-04-23 (金) 00:53:01}
 --FD主体だと、バンドルの方が当座の間に合わせみたいになっちゃうのが面白いかも。 -- [[Tino]] SIZE(10){2004-04-23 (金) 01:13:59}
 
 #comment
 
 ** バンドル
 ** バンドル [#w4473765]
 
 -JARのように圧縮してしまうと裏での展開などが大変になってしまいますが、バンドルの真似をすれば圧縮とか埋め込みとか考えなくても簡単に整理できるのではないかと思います。 -- [[Tino]] SIZE(10){2004-04-22 (木) 01:24:18}
 --たとえば以下のようなイメージです。 -- [[Tino]] SIZE(10){2004-04-22 (木) 01:24:33}
  APPS/REVERSI.ELF
  APPS/REVERSI2.APP/REVERSI2.ELF
  APPS/REVERSI2.APP/BLACK.BMP
  APPS/REVERSI2.APP/WHITE.BMP
 --このような構成にすると決めておけば、シェルからREVERSI2と打ち込んだときに、APPがバンドルだということを認識して、その中の同名のELFを実行するというような小細工です。 -- [[Tino]] SIZE(10){2004-04-22 (木) 01:28:52}
 --プログラム的には相対パス(この場合はカレントのまま)のBMPを読み込むだけなので、特に対策は必要ないというようなイメージです。 -- [[Tino]] SIZE(10){2004-04-22 (木) 01:29:58}
 -ふむ面白そうですね。デメリットとかってありますかねぇ。 -- [[[[ひげぽん]]]] SIZE(10){2004-04-22 (木) 19:32:09}
 --特にないと思います。シェルがバンドルを認識するようにするだけで、後は特別な仕組みは要求しないと思います。 -- [[Tino]] SIZE(10){2004-04-22 (木) 22:42:45}
 -おもしろそうですね。ちょっとみためにかっこいいかなというのが正直な印象です。0.2.0の後継に搭載するか今やるか迷うところです。 -- [[[[ひげぽん]]]] SIZE(10){2004-04-22 (木) 22:49:34}
 -懸念事項メモ:アプリケーション起動ディレクトリが、アプリケーションから見たファイル読み込みのカレントディレクトリだったかどうかがあやしい>Mona -- [[[[ひげぽん]]]] SIZE(10){2004-04-22 (木) 22:54:55}
 -労力次第だと思います。ひとつ思ったのは、今のMonaでカレントディレクトリの概念がどうなっているかということです。プロセスごとに設定できるようになっていなければ色々と作業が必要になりそうですね。 -- [[Tino]] SIZE(10){2004-04-22 (木) 22:57:00}
 -すいません。かぶりましたー。 -- [[Tino]] SIZE(10){2004-04-22 (木) 22:57:59}
 -こちらこそm(__)m -- [[[[ひげぽん]]]] SIZE(10){2004-04-22 (木) 23:19:48}
 -カレントについてですが、よく考えたらファイル名を指定するときなど、シェルのカレントから見ないと意味がないので、一括して実行時にバンドルの中にカレントを移すようにするのはまずいですね。特にlsのようなものを外部コマンドにするときに致命的です。 -- [[Tino]] SIZE(10){2004-04-23 (金) 00:10:17}
 -- PIDからELFファイルのフルパスを取得するようなMonAPIを用意すれば、それを利用してバンドルのパスを返す関数も作れそうです。そうすればカレントの概念と関係なく処理できますね。 -- [[Tino]] SIZE(10){2004-04-23 (金) 00:10:17}
  System::getBinaryFileName(dword pid)
  [例] System::getBinaryFileName(System::getProcessID())
       → "/APPS/REVERSI2.APP/REVERSI2.ELF"
  
  System::getBundlePath()
  [例] "/APPS/REVERSI2.APP"
 --なるほど。 -- [[[[ひげぽん]]]] SIZE(10){2004-04-23 (金) 00:24:28}
 -今まで意識していませんでしたが、/APPSにバンドルが入っているというのはOS Xのファイル構造に似ていますね(OS Xは/Applications)。以前スレでどんなファイル構造にするのか、BeとかOS Xは参考にならないか、とか出ていましたが、こんな感じで少しずつ整理していけば形になっていきそうです。 -- [[Tino]] SIZE(10){2004-04-23 (金) 01:11:07}
 
 #comment
 
 *** 仕様調整(仕様確認)
 *** 仕様調整(仕様確認) [#u8daca0b]
 
 - リソースファイルがないアプリケーションにもフォルダ格納を義務化するか? (Y/N)
 --個人的にはNOです。上に書いたイメージではリソースがないREVERSI.ELFをわざと裸にしています。 -- [[Tino]] SIZE(10){2004-04-22 (木) 23:24:18}
 - バンドルとしてのフォルダと通常ののフォルダをシェルはどう区別するか?(ネーミングルール?, フォルダの中に特定の目印ファイルがあったら?)
 --ファイルと同じで、普通に拡張子でいいんじゃないでしょうか。そもそも拡張子の付いたフォルダという概念自体、従来はあまり使われていなかったので、混乱はあまりないのがポイントでしょう。 -- [[Tino]] SIZE(10){2004-04-23 (金) 00:03:41}
 - 「決め」の問題ですが。REVERSI.ELFとREVERSI.APP/が同一ディレクトリにあるときにREVERSIではどちらが起動される?
 --確かにこれは決めの問題ですね。DOS窓で同名の.COMと.EXEと.BATを置いて実験してみると参考になるかも。 -- [[Tino]] SIZE(10){2004-04-23 (金) 00:36:58}
 --DOSでは暗黙の了解として.COMと.EXEが混在していても名前を被らせないようにしてはいました。はっきりさせたいときは拡張子まで入力すれば区別できるので致命的ではないですが。 -- [[Tino]] SIZE(10){2004-04-23 (金) 00:40:03}
 
 #comment

リロード   新規 編集 差分 添付 複製 改名   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS

Modified by mona
PukiWiki 1.4.6 Copyright © 2001-2005 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji
Powered by PHP 5.2.17
HTML convert time to 0.025 sec.