Warpっぽく -- Workplace Shell

WarpCenter -- 2001.4.27, 2001.5.23

ソレは, 導入とともにDesktop上に現れ, つねに画面の一部を占めるもの。プログラムランチャーだったりフォルダーを見やすく開けたりもするけど, ほかにも, タスクリストとかディスクスペースの状況を出してみたりなんかもする。それに時間だったりもするよね。そう, ソレは WarpCenter。

コレは環境に優しい・・・じゃなくて, Workplace Shellに優しいのだ。
たとえば, Desktopからフォルダーを開いて, 求めるファイルを探しだそーとすっと, 辿るすべてのディレクトリには拡張属性が付いたりする。んな感じで贅肉が少しずつ付いてくよーに, だんだん余分な情報で遅くなったりもするかもしれないのだ。ホントに遅くなるのかは, 時間計った訳じゃないので予想での話なんだけどね。

でも, 拡張属性だけでなく, iniファイルにもハンドルっぽいものがどんどん追加されて, そちらは確実に大きく, そして重くなっていくのら。ま, 開く度に増える訳じゃなくて, 一度開いたら登録されるってだけなので, 神経質にならなくてもよいかもだけど・・。

んで, WarpCenter。・・コレの場合, そこでフォルダーをたどる分には, 余分な情報は追加されないっぽい。てことで, 最終的に開いたフォルダーとかは別として, iniファイルを太らせない選択として, WarpCenterとコマンドラインはソレなりによいものなのだ。って, コマンドラインだけ使うのが一番よいのかも。わはは。

◇

てことで, まずはプログラムランチャーとしてのソレ・・・そのトレイの情報をアレしてみよう。

トレイの中にプログラムをドロップすると, そのプログラムのアイコンが現れて, いつでも起動できるよーになるんだけど, 一体ソレはどこに保存されているのか。そして, トレイをいくつも作ったとき, ソレらはどーゆーふーに管理されているのか, その秘密を探るのだ・・。

いつもなら, 普通のプログラムなら, iniファイルにソレらの情報が保存されるんだけど, でも, WarpCenterは違っているみたい。その情報とゆーのは, \os2\dll\dock0.cfg ～ \os2\dll\dock15.cfg の中に入ってるっぽいのだ。早速構造を見てみよー。

dockX.cfg の構造
勝手につけた名前	位置	長さ	備考
ID	0	1	識別子っつーか, dock0.cfgなら 0x00, dock15.cfgなら 0x0f が入っていたりする
FLAG	1	1	0x01なら有効な情報で, 0x00は無効なことを表してる情報っぽい
	2	3
NAME	5	32	トレイに付けた名前。トイレじゃないよ。
	37	1
CNT	38	4	件数
Handles	42	(4)	一つ当たり 4Byteの, ハンドルっぽいもの。ソレが CNT分ある。

・・このファイルの存在は, あちゃいんさんの情報から。

で, 何に使われてるのか分からないけど, コレ(↑)と同様の情報が \その他 てゆーディレクトリにも保存されているのら。ウソだと思うなら dir \ ってやってみると・・・って, 出ないね。
いや, 確かに見たんだけど・・, どこ行っちゃったかなー。あ, attrib \ って実行すると出てくるね。そーソレ, そこになぜか拡張属性として入ってる訳よ。

◇

WarpCenterの右端, 時計の隣, そこには「アシスタンス・センター」が鎮座していて, いつでも情報(？)を取り出せたりなんかする。
でも, コレって, 特別変わった機能なんかではない。てゆーのも, オブジェクトＩＤ <WP_ASSISTANCE> を使って, その該当するフォルダーを開いているだけなのら。そう, トレイにフォルダーを置いているのと少しも変わんない・・・よーな気がする。(^^)
ソース見た訳じゃないから, 自信もってアレすることはできないけどね。

てことは, デスクトップにある「アシスタンス・センター」フォルダーに, ソレっぽいファイルを入れておくだけで, いつでも WarpCenterからアクセスできるってことでもあるのだよ。ふっふっふー。

で, 似たよーなものに, オブジェクトＩＤ <WP_DESKTOP> を使うのもあるだよ。
お解りの人は解るだろーけど・・, って当たり前だね。ソレは左端の「アプリケーションの始動またはオブジェクトのオープン」てやつ。
そんなこんなで, もしかして他にも別のオブジェクトＩＤで何かアレしてる部分もあるかも。

ところで, WarpCenterでフォルダーの中身の一覧を見てみると, 実際のファイルだけでなくシャドーとかも入ってるよね。そーゆー抽象オブジェクトってのは, APIでアレするんだろーけど, 実際に格納されている部分は PM_Abstract:FldrContent のとこ。もし, そーゆープログラムを作るばやい参考にしてちょ。(^^) (←って誰にゆってんだか)

INIファイル・INIファイル -- 2000.1.31

Warpには Workplace Shellとゆー, 優れたブツが装備されている。ま, いろいろアレしてると変なとこも見かけたりするかもだけど, それは, まぁムニャ・ムニャで・・・。
たとえば便利な使い方としては, フォルダーだったら用途別に表示形式を切り換えたりできる。プロパティーで [表示(V)] を グリッドだとか, 複数カラム にしたりとかいくつか選択できる訳だね。それから, [メニュー(M)] の オープンの プロパティー(P)...で, 省略時アクションを変えたりもできる。

でも, こーいった情報ってば, Warpではどこに保存してるんだろう。不思議に思わない？

Warpを終了させてそのあと再起動すると, ちゃんと前の情報が残ってる。まっ, 当たり前なんだけどさ。てことは, HDDのどこかにソレが保存されていることは間違いない訳だよね。ドコだ？ドコなのじゃ～？・・・ソレはゆーまでもなく, INIファイル。User INI file (\OS2\OS2.INI) とか System INI file(\OS2\OS2SYS.INI) のこと。つっても, dirとか typeとか, そんなことしても何の手がかりも得られない。まずは気を落ち着かせて RegEdit2 とキーボードを叩くのだ。さすれば, Workplace Shellの数々の情報を見ることができるであろー。

さて, ここには実体がアレな Abstract Objects, つまりシャドーやら, プログラムオブジェクトやらもごっそりと入っている。そこらへんは, 抽象オブジェクトについてのソレがあるので参照してもらうとしよう。それから, INIファイルの他にも, EA (拡張属性) にも, さまざまな情報がちりばめられていたりする。こちらは, また別の機会にでも・・・ (^^;

さて, (何らかの)INIファイルビューワーで, 早速ソレらを覗いてみよう。するってーと, 暗号のよーな数字が並んでいることに気付く。・・・気付くよねっ。でも, コレをどーやって解れとゆーんだっっ, とか思わない？だけど焦りは禁物。数字が入ってるのをひとつひとつゆっくり見ていこう・・・

USER_PROFILE の中の PM_Workplace:Location。ここには, <>で囲まれた名前と, それからデータとして４バイトの情報が入ってる, よね。これは オブジェクトIDと呼ばれるアレ。つまり, そのオブジェクトIDは何処にあるのかっつー位置情報がここにある。
それから, 関連付けの情報 (↓)・・・こちらには, 10進数の文字列として何かが記されている。
これらは, (バイナリか文字列か)形式こそ違っても, ある物を指している。そのブツとは, ハンドル(？)のよーなものなのであーる。

PMWP_ASSOC_FILTER
PMWP_ASSOC_TYPE
PMWP_ASSOC_CHECKSUM

これらの数値, その値が 16進数で０ｘ０３×××× なのなら WPFileSystem って訳で, ソレをファイル名に変換するのは簡単。んで, ソレが０ｘ０２×××× なのなら WPAbstract。こちらは, USER_PROFILE 中の PM_Abstract:Objects に, そのすべての情報が記されてるのだ。・・・じゃないや。この抽象オブジェクト(WPAbstract) ってば, ほかのとこ(↓)にも情報が含まれてただよ。ただし, コレらにアクセスするときの名前は, 先頭(？)の 0x02 を除いた部分(16進数 4桁分)を指定すること。

PM_Abstract:Objects ・・・実体とかパラメータとかの, 各種の情報
PM_Abstract:Icons ・・・そのアイコンのイメージ
PM_Abstract:FldrContent ・・・フォルダーの中に抽象オブジェクトがある場合の, その情報

この他にも, この手のハンドル(？)のよーなものは, (USER_PROFILEの中に)いくつか含まれていたりする。

PM_Workplace:Templates
PM_Workplace:FolderPos
PM_Workplace:PalettePos
PM_Workplace:Startup
PM_WorkPlace:Restart

こーいった情報ってば, 見るだけでなくて変更したりすることで, 今までできなかったことができたりすることもある, かも。ソレと同時に, 一歩間違えば再導入の憂えき目に合うことにもなりかねない。禁断の世界と言えなくもなかったりして。

なにをいまさら『WP』 -- '99.5.11, '99.5.14

WP ・・・つまり WorkPad。なーんつって。
でも, まったくの無関係ではない, のかも。てゆーのも, 白龍シリーズのインストーラーを参考にいろいろ解説しよって訳だから。ま, いまさら遅過ぎって感じもするけどね。エヘ。

◇

前にも載せたけど, もっかいインストーラーがやってることをおさらいしてみよう。

まず, 前提となる環境は, Pilot-Linkが準備されていること。
適当なディレクトリに展開された Pilot-Link。その中の makefolder.cmd によって, デスクトップに Pilot-Linkフォルダーが作られている。デスクトップの オブジェクトIDは, もちろん <WP_DESKTOP>。そして, Pilot-Linkフォルダーの オブジェクトIDは, <Pilot_Link_xxxxx_for_OS_2> (例えば <Pilot_Link_0_8_13_for_OS_2> みたいな)
その環境の中で, 白龍インストーラーが主に行うことは・・・
- Pilot-Linkフォルダーを見つけ, その中に新たに『白龍フォルダー』を作成する。
- Pilot-Linkフォルダーの中の, あるプログラムオブジェクトをから, アイコンを得る。
- Pilot-Linkの DLLが LIBPATHで通った所にあるかどうか調べ, なかったらカレントディレクトリに複写する。

◇

まずは Pilot-Linkフォルダーを見つけてみよう (もちろん, プログラムによって)。
最初に, オブジェクトIDでそれらしき物を探し出し, そこからバージョンがなるべく新しいものを選び出す。これは, なんとかなるよね。 USER_INI であるところの "\OS2\OS2.INI", この中にソレが収められている。
アプリケーションとして PM_Workplace:Locationを指定し, あとはキーの一覧を取ってくる。もちろんキーとゆーのは, オブジェクトIDのことだ。

最新バージョンの Pilot-LinkフォルダーのオブジェクトIDを見つけたら, 今度はそのパスを得てみよう。
導入したすぐは, この Pilot-Linkフォルダーは確かに「デスクトップ」にあったはず。けれど, その後もしかしてどこかに移動したかもしんない。 INIファイルでは, アプリケーションと, キーを指定することで, 値を取り出すことができる。んで, 値にはハンドルが入っている。
そーいったハンドルからパスを得るのは, 以前紹介したのでパス。 (←シャレ？)
これで, Pilot-Linkフォルダー(のオブジェクトID)から, パスを探し当てたとゆー訳だよね。

◇

では次に, このフォルダーに収められているブツを調べてみよう。
Workplace Shell上でソレを開いてみると, 結構ある。いろんなプログラムやらドキュメントらしき物やら, そりはもうゴマンとある (←そんなにない)。探し出したいターゲットは, その中の『Install File to MemoPad』ってやつ。コレのアイコンを取り込んでみよう, って訳。

しかし, もちろんさっき探し当てたパスを(コマンドラインとかから)調べても, そんなん入っちゃいねー。代わって目にする事ができるのは, いくつかのディレクトリだけ。そりゃ当然。これってプログラムオブジェクトだもの。つまり大半は, プログラムはプログラム・オブジェクトとして, ドキュメントなんかはシャドウ・オブジェクトとして, そこにある訳よ。

こーゆー項目の情報は, 同じく USER_INIの "PM_Abstract:FldrContent"に入ってるだ。これに, キーとして 16進数でハンドルを指定すると, そーゆー情報が得られる。でもキーは 16進数で 4桁。その省略されている(はずであろー)値, 0x0003の部分は WPFileSystemを表してて(のはずで), 実在するフォルダーなのだから。
で, つまり, フォルダーの中身を Workplace Shellで見た時に, そこに現れる一覧とは, 実際にそこにある物理的なヤツ (←ってどんなだ) と, "PM_Abstract:FldrContent"＆ハンドルで, 現れたものの合計ってことなのだ。

さて, "PM_Abstract:FldrContent"＆ハンドルで, 抽象オブジェクトの一体何を得たのか。そう, 実はコレもハンドル。え～～, また～～(語尾は上げて), みたいな。
この得られた値は, 4バイトずつに区切ることができ, それぞれがいつものソレ。だけど, 今度のコレは前(？)半分は 0になっていて, 後ろ(？)半分だけを使う事になる。まぁ前(？)半分が付いてたとしても, ここは 0x0002(のはず), つまり WPAbstractしか(ありえ)無い訳だろうしぃ。

さぁ, ここまでで, Pilot-Linkフォルダーに入っている抽象オブジェクトの(ハンドルの)一覧が取得できている訳だ。このなかから, 『Install File to MemoPad』ってやつを探し出してみよう。プログラム名は "Install-Memo.exe"だ。

その抽象オブジェクトに, どんな情報(プロパティー？)を持っているかは, やはり USER_INIの "PM_Abstract:Objects" を調べることになる。キーはもちろんハンドル。構造は前にも載せてるので参考にどーぞ・・・。見つけ方は今回(のプログラムは)適当に済ませてたりする。なんと "WPProgramRef"の文字を探すだけ。手抜きだね, はっきしゆって。ま, プログラムオブジェクトには, その文字列が含まれているのが確実っぽいので。で, 実体を見つけてみて, その実体のファイル名が "Install-Memo.exe" なら, それだっっ, てことだね。

アイコンを持ってくるまでは, もう少しだ, がんばんべぇ。ぜぇぜぇ。
抽象オブジェクトの一覧の中から, 該当する一つのオブジェクトを選んだ訳だけれど, アイコンはさらに別な所にある。 USER_INIの "PM_Abstract:Icons"で, キーはさっきのものと同じ。ようやくこれで, アイコンのイメージ情報を得る事ができたわけだ。 Install.cmd では, ここで得たアイコンを使って, あるファイルにアイコンを付けるために, いったんアイコンファイルを生成している。まぁ, ファイル名を指定する必要があるから, 単にファイルに書き出しているだけだけどね。

◇

んでは, 残る問題。簡単に DLLを探し出してみようとゆーアレ。これ, Workplace Shellとは関係ないやんなどとゆー意見は却下することにする。にょほほ。

このころの, Palmデバイスと OS/2(を母艦とする)環境との連係でのソフトウェアっつーと, σ(^^) が作ったソレは, pisock.dllが必要だったのら。
その pisock.dllは, Pilot-Link にもともと入っている DLLで, だからソレを探そうって訳。

DLLは config.sysの LIBPATH= でパスを指定するんだけど, これ, 環境変数ではない。環境変数だったらよかったのにねぇ～。SysSearchPath() ってゆーもので探せるから楽なはずだし。
と, ゆーことで, 環境変数をセットして, 改めて SysSearchPath()で調べてみよう。ディレクトリ探索処理作るよか, そっちのが楽じゃん, て訳で。

config.sys から, LIBPATH= の行を見つけるのには SysFileSearch()を使うことができる。大して自前でやるのと変わんないけど, 文句は言わない (←ゆってんじゃん)
後の手順は・・・見つけた内容を適当な名前の環境変数にセットする。んで, その環境変数名を指定して SysSearchPath()で探すだけ。簡単だねっ。でも, ずっとソレ(環境変数)残ったままではアレなんで, call SetLocalと call EndLocalで処理を挟むことで, 元の環境に戻している。

さて, DLLがそこに見つかったらよいけど, そうでなかったらどうしよー。どんな時かとゆーと, LIBPATH= が通っていない所に, その DLLが入っている時だ。つまり, そこは pilot-linkを最初に展開した場所なのだろうけど, でも, そんなこたー「白龍インストーラー」は知る由もない。
仕方がないから, (どこかからソレを見つけて) カレントディレクトリにでも複写しておこう。そうでもしないと配布するプログラム, 動かないからね。

幸い, (↑)で "PM_Abstract:Objects" 使って見つけたばっかだし, そこの実体のパスを利用すれば, ソレを取ってくることができるかも。ただし, LIBPATH= にカレントディレクトリである "."が含まれていないかも, ってばーいは考慮していない。 (そのときは, 複写したけれど動かないってことになるけど) ま, 構わないよね。

アイコンのある風景 -- '99.3.11

・・で, 今回ダイコン。・・・じゃなくアイコン。そう, GUIといえばアイコンってくらいだよね (そんな訳ない)。てことで, このアイコン・イメージについて色々アレしてみよう。
んなことゆってもそのファイル構造みたいな, そんなアレではない。何処にアイコン・イメージを隠し持っているのか, それをあばこうとゆーのだ。うひょひょー。 (← 少しあぶないかも)

◇

さて, GUIプログラマーな方なら御存じリソース・ファイル (そーでなくても御存じかもだけど)。 *.exe ファイルを作り出すときに指定するヤツだよね, コレ。この時にプログラムのアイコンも指定できる (できたはず)。
では, その .exeが出来たとして, アイコン・イメージは何処に保存された(/ている)のだろう。

答えは簡単 .exeファイルの中。 .exeは実行するだけの情報を持っているだけではなく, そーいった情報を持つ事ができるよーな構造になっているのである。つまり EXEヘッダーとゆー部分のことだね。
この構造はなかなかにアレなので, 一筋縄ではいかない (歴史もあるし)。そんな訳で, 詳しく知りたい方は Toolkit か何かの *.INFファイルに構造が載ってたりしたはずなので, そちらを参考にするとよいかも。
じゃ, そゆ事で (^o^)/~~ (←こら)

◇

んじゃ, EXEヘッダーを持たないファイルのばーいはどうなるのか。その場合アイコンを持つ事ができない・・・って訳じゃない。簡単な手段として, 拡張子など(ファイル名の一部)を元にしてウィンドウ・システムが勝手に付けたりなんかする方法, そーゆーのもある。でも Workplace Shell では, (拡張子/ファイル名によらず)個々にアイコンを持つこともできる, よね。

と, ゆーことは？・・・ .exe なら EXEヘッダーがあるからそこに持ってるけど, .html には HTMLヘッダーっての無いよね・・・って, たとえが悪いかも。ま, ソレはよいとして, では何処に持っているのかっつーと, EA の中に入ってたりする, その名も .ICON (そのまま)。

じゃ, 両方あったらどーなるのだろー。 *.exeでアイコンを持ってて, しかも拡張属性にもソレを持っているばーい・・・コレは試したことないから分からない。あは。 (^^;
Dr.Dialog (Dr.Rexx) では *.exe を作ることができる訳で, ソレで作ったものには, EXEヘッダーのアイコンと, EAに含まれるアイコンが合わせて二つ入っている。けど, どちらも同じイメージ。コレでいちど試してみるのもよいかもね。

◇

さらに, Workplace Shell では抽象オブジェクト－－実体がない黒い影, わっはっはー (←もういいって)。
つまり, プログラム・オブジェクトだのシャドウだのがあるよね。こーゆーのはどーなのだろう。そう, ヘッダーどころかファイルその物がない抽象オブジェクトでは。

このばーい, 抽象オブジェクトの元の実体側のファイル。そっちにアイコンを持つのだろーか？・・・そーではない。いや, 実体側で持っている場合もあんのかな？, わかんないや。てへっ (^^;;
でも通常は, INIファイルにソレを持っているのさっ。ソレが PM_Abstract:Iconsとゆーところ。

てことは, プログラム・オブジェクトで, しかもその実体の EXEヘッダーと EAにそれぞれアイコンを持ってたら, 結局どーなるのだろー。どれが有効なんだろ。・・・まぁどーでもいいや, そんなこと。(^^)＼(バキ☆)

◇

最近公開した白龍シリーズのメモパッド編集。これ, 今後も少しずつ増やしていくつもり (は, どーでもいいかも) ・・・なんだけど, そこにはアイコンに関するいくつかの試みをアレしているのだ。(プログラムその物じゃなくて, インストーラがアイコンを扱ってるってとこが, ガクッて感じだけどね)

オブジェクトID (<WP_DESKTOP>のよーな) からハンドルを得て, そのハンドルからフォルダーの実際の位置(パス)を得る
フォルダーの中に存在するプログラムオブジェクトを得る
プログラム・オブジェクトから実体のプログラム名(パスなど)を得る
プログラム・オブジェクトのアイコンを得る

(2番と 3番は合わせて一つの関数にしている)

実は, このプログラム, Pilot-Linkのプログラムオブジェクトから勝手にアイコンを拝借して使っている訳なんだな, これが。ホントはアイコンを用意したいとこなんだけど, 悲しい事に〆(^^) はそんな能力を持ち合わせてはいない。くぅーっ (T_T
(↑だからって勝手に拝借していいのか？) ・・・ごみんなさい m(__)m ＞ Pilot-Linkのアイコン作った人

そーゆーことで, プログラム・オブジェクトから実体を知るってゆー処理の, 実際のプログラム例ともいえるかも。で, 注意しておくことは, コレが手抜きだとゆー点。そしてもう一つはシャドウには対応していないって事。問題ありすぎかも。がはははは。

では, 今度こそ, バイビー。 (^o^)/~~

アイコンの位置 -- '99.1.12

あいこ～ん, ぽーっすっ。 (← アホか)
今回, 拡張属性 .ICONPOSについて, いろいろと検証してみよー。でも, その前に注意。ここらへんも, 元情報ナシの勝手な推測なので, 間違いがあるかもってゆーことで。 (^^;
それから, 〆(^^) 作のソフト Dr.EAでも, .ICONPOSを書式化して表示しているので, 参考にするとよいかも。参考にできるかどーかは別として。 (← ぉぃ)

◇

この .ICONPOSには, そのフォルダー内のアイコンの位置情報が入っている。まずは全体の構造。これは EAT_BINARYの型を持つデータ。つまり, こんな構造。

先頭は EAT_BINARY, つまり 0xFE, 0xFF
次は 2Byte分で, 以下の情報の長さ
.ICONPOS内容

んで, 次にその「.ICONPOS内容」の構造をば・・・

.ICONPOS 内容
内容	サイズ
不明。(いやー, あっはっはー)	13 Byte
画面解像度 (幅)	4 Byte
画面解像度 (高さ)	4 Byte
アイコン位置の情報(座標) の集まり

画面解像度は, 1024 768て感じで入ってるんだけど, なぜこんなところに, 「画面解像度」があるのかは不明。解像度に対する割合とでもゆーことだろーか？

そしてアイコン位置の情報の構造。ここにはアイコンの一つ一つの座標などの情報が繰り返し入っている。一つのアイコン当たりの構造は, 次のような感じ。

.ICONPOS アイコン位置情報
内容	サイズ
X 座標 (左から右へ大きくなる)	4 Byte
Y 座標 (下から上へ大きくなる)	4 Byte
クラス名？ (":"で終わる)	適当
タイプ → D(Directory?), F(File?), A(Abstract?)	1 Byte
名前またはハンドル？ (nulコードで終わる)	適当

座標は, 左下が原点 (0,0)。これらは, そのフォルダーに入っているすべてのアイコンが連続して入っていて, そしてその後に (おまけのよーに) ひとつだけ座標のような項目がくっついている。この最後の情報も訳わかんない。んーむ。

◇

あるフォルダーを「アイコン表示」にしていると, その内容(content)であるアイコン座標は, 座標情報としてそのフォルダーの拡張属性に書き込まれる訳。では, 「詳細表示」の場合は, その内容(content)は, どこに書き込まれているのか・・・それに「アイコン表示」でもシングルカラムやら, 複数カラムやらもあるし, それらはいったい・・・？

だけど, それは簡単なことなのら。アイコン位置の情報の順番が, それの順番を指してたりする。なーんだ単純じゃん。だから順番を入れ替えたければ(どんな意味があるのか分からないけど), 一度「詳細表示」にしておいて, 順番を入れ替えて, そして元の「アイコン表示」にする。・・・と, 位置的にはアレでも順番は入れ替わるって訳。

たとえば, アイコンを再配置とかする場合, この順番をアレすることで, 思う順に並べる事もできるってもんさ。わっはっはー。それに, Drag ＆ Drop の時にも, この順番が関係するみたいなのじゃ～。たぶん。

そーそー。こーゆー"(少し)危ない"ことをアレする時には, そのフォルダーの拡張属性を保存しといた方がよいかも。手順は以前にもアレした通り・・・

eautil /s /p そのフォルダー xxx.ea
 ※ xxx.ea は適当なファイル名。

書き戻すときには, 該当するフォルダーを一旦閉じ, 拡張属性を書き戻して(↓)から
eautil /j /o そのフォルダー xxx.ea
 ※ xxx.ea は先ほどのファイル名。
その後に, 開いてみる。

◇

ってなところで, バイビー (^o^)/~

続続. 抽象オブジェクト -- '98.12.11

ぞくぞくぅ・・・みたいな (^^)＼(バキ☆)
えー, 前回のは図もなしに説明だけでは分かりにくいかも。きっと。そーゆーことで, 書式化したものを公開してみるよーっ。と, その前に, 独自の方法で書式化しているので完ぺきとはいえないかも, ってことを注意しながら読んでくらさい。

んじゃまず, 図-1。これは一般的なプログラムオブジェクトで, 印が付いているのが, そのプログラムを指しているハンドルっぽいものと実行ディレクトリのハンドルっぽいもの。実行ディレクトリが 0000なので・・・えーと, 適当にってヤツだろうか？
その下の行が引数。(???)は型を表していて, 実際は 0x0004なのら。 (Str)は文字列, (Int)は 4バイト数値型だど。インテル形式なのでファイル内はもちろん逆さまに入っている・・・んだけど, 蛇足かな？

図-1

Key=1463 WPProgram
8214 8214 8214 (WPObject) 0800
WPProgramRef
 (???)000B 0xF76B0000000000000000000000000000000000001000000001000000
 (???)000A 1=ONLINE.INF
 (???)0007 0x000000000000000000000000000000000000000000000000000000000000000000000000
WPAbstract
 (Str)0001 オンライン情報の使用法^@
 (Int)0002 80000000
WPObject
 (???)000B 0x0400000000000000010000008000000000000000000000000300000002000000
 (???)000C 1=<WP_ONLINE>
 (???)0004 0xFFFFFFFFFFFFFFFF

次の例はシャドー。わっはっはー (←もういいって)
印の部分が同じ内容になっているけれど WPShadow側が信頼できるかも・・・って前にゆったっけ。試しに確認するばーい, 文字列: WPShadowを探すと 2つ見つかる事になるので注意, ってのも・・・前にゆったかも。あはは。

図-2

Key=6C0 WPShadow
8414 8414 8414 (WPObject) 0800
MMShadow
 (Str)0001 ^@
 (Int)0002 AC030300
 (Str)0003 ^@
WPShadow
 (Int)0068 AC030300
WPAbstract
 (Str)0001 README^@
 (Int)0002 00000000
WPObject
 (???)000B 0xFFFFFFFF00000000010000000000000000000000000000000300000002000000
 (???)000C 1=<WP_RDME>
 (???)0004 0xFFFFFFFFFFFFFFFF

次の例は, 少し変わったパターン。プログラム本体を指すハンドルっぽいのの値が 0とゆーヤツ (実体のないプログラム？)。この時は 000Aの所にプログラムファイル名が(引数と一緒に)入っていたりする。

それから, この実体を示すハンドルが FFFFってばーいもあったりする。「コマンドプロンプト」とかがそんな感じ。

図-3

Key=DCE9 WPProgram
8214 8214 8214 (WPObject) 0800
WPProgramRef
 (???)000B 0x00000000000000000000000003000000000000001000000001000000
 (???)000A 0=VIEW.EXE 1=\OS2\BOOK\DHCPCLNT.INF
 (???)0007 0x000000000000000000000000000000000000000000000000000000000000000000000000
WPAbstract
 (Str)0001 TCP/IP DHCP クライアント\n管理ガイド^@
 (Int)0002 80000000
WPObject
 (???)000B 0x0400000000000000010000008000000000000000000000000300000002000000
 (???)000C 1=<NP_DHCP_GUIDE>
 (???)0004 0xFFFFFFFFFFFFFFFF

図があるのと無いのとでは, やはり違う。えっ図がわかりにくい？がまんしなさい。

さーみんなも PM_Abstract:Objectsをダンプしてみよーっ。目を凝らしてみれば, このように見えるはずだ。 (← 見えるかっ)

続. 抽象オブジェクト -- '98.12.9

うぎゃー(↓)に間違いが・・・。確かめもせずに書いちっただよ。ごめんなさい m(__)m
まー, こんなこともあるわな。あははははー (^^;;＼(バキ☆)
言い訳をすると, 〆(^^) のツールでは見れるんだよー。って, 何のことかゆってなかったね。「フルパス名が入ってるだけなんで」とか書いてたけど, そうじゃなくて, やっぱハンドルが入ってるだよ。はからずも卵さ加減が露顕してしまった。くぅ～っ。 (←卵さ？)
文字列が入っているのは, ソレはタイトルっつーかそーゆーもので, 実体はハンドルがバイナリで入ってるだよ。

てことでいきなり解説。
プログラムオブジェクトの場合, WPProgramRef て文字列の後に 04 00 0B 00って入っている。 0x000B は値を識別する番号(ID)のよーなもので, 0x0004 は型を表している。実体を表すハンドル(?)は, ここの 2バイトおいてすぐに後にある。

その部分は 2バイトずつ, 実体, 0x0000, 実行ディレクトリってゆー感じで構成されている (でも, 実体のないものもある。例えばコマンドプロンプトだとか・・・)。で, 引数は 04 00 0A 00 以降に入っている (プログラム名がこの部分に組み込まれているばーいもある)。この引数部分はほとんど文字列。いや今度はホント。でも, ある種の構造を持っているので parseが必要なんだけどね。ここでそれの説明すると, また間違えて書いてしまいそうなんでトス, じゃなくてパス。

シャドゥ・・・これの場合は, MMShadowの次の 02 00 02 00の後と, WPShadowの次の 02 00 68 00の後, ソレが実体を示している。 MMShadowは, エントリーその物が無いこともあるので, 確実なのは WPShadowかも。
ここには, ふつー xx xx 03 00みたいな値が入っている。03 00は WPFileSystemっつーことを意味していて, 実体を持つもののクラス。ここが 02 00だったら WPAbstractだね。プログラムオブジェクトのシャドウとか, シャドウのシャドウとか(そんなのあるのか知らないけど) そんなアレ。先頭に WPShadowとか入っているばーいもあるけど, こーゆーときはそこをスキップしないとまずいかも。 (←分かりづらいかも)

◇

ここらあたりってば, クラスの階層構造そのままってゆー感じで, ちょいと複雑かも。でも何で「文字列そのまま」って書いちったんだろう。あー悔やまれる。(T-T)
あーそうそう。この部分, 実は何つーか, EAの.CLASSINFOと同じ構造だったりして。
今回までもバケツを, じゃない墓穴を掘ったらやなので, このへんで・・・んじゃ (^_^)/~

抽象オブジェクト -- '98.12.2

フォルダーを覗くと, ときどきみょーな感じを受けたりする。
そこにちゃんと存在するとゆーのに, コマンドラインで見ると無い。・・・シャドウ, 黒い影。
わっはっはー。

推測すると, どこかに実体があって, そしてそれを指し示すものがフォルダーの中に(だけ含まれ) 隠されている。きっとそんな感じ。ところが, 拡張属性(EA)にはそれに近いものはあるけどちょびっと違う。
ここでアレを思い出そう。開発記にも書いてるアレだ。

WPTransient
WPAbstract
WPFileSystem

Workplace Shellオブジェクトには 3つのクラス(みたいなもの？)があって, 実体を持つもの, 抽象的なヤツ, 実行時だけに使われるヤツ(？) とかがある ((↑)と順番逆だけど)。
この抽象的なヤツ(WPAbstract)が, (シャドウとか)そーゆーの類のものなのだ。

(userか systemかどちらかの(どちらだったか忘れたけど) )バイナリINIファイルに, なにかそれらしき情報がちらほらと入ってたりする。そしてそれには, アプリケーション名が PM_Abstract:～とか付いてたりする。 (INIは, アプリケーション名とキーを指定すると内容を取り出せるっちゅーアレ)

PM_Abstract:Objects
PM_Abstract:Icons
PM_Abstract:FldrContent

ま, こんな感じのものだね。
さぁー, みんなで見よー INIファイル。うひょひょひょひょ～ (←なーんかマッドな感じ)

この中の PM_Abstract:FldrContent ・・・これはキーが 16進数 4桁くらいで, その内容は 4の倍数のサイズのもの。実は, このキーはフォルダーを指し示してたりする。 Workplace Shellで扱っている以上, フォルダーにもハンドル(?)が付いている。つまり WPFileSystemとしてのそれ, ってことだね。で, その内容の (4バイトずつの) 一つ一つが示すものが PM_Abstract:Objects を指しているハンドル(?)ってゆー, そんなからくりなのだっっ。
ハンドル(?)は 2バイトで済むはずなのに, なぜ 4バイトずつなのか。それは・・・よく分かんない(^^)＼(バキ☆)
でも, その内使われているのは(little-endianだから)前半 2バイトで, 後半の 2バイトは 0になってたりする。

WPFileSystem での, ハンドル(?)から(ファイルの)実名の取り出し方は, 『進んだRexx』の予定にもあるので期待しないで待っててね。・・・ってコメントアウトしてたんだっけ, それ。あはは。 (^^;＼(バキ☆)
で, 肝心の PM_Abstract:Objects 。これの中に WPShadowとか WPProgramとかがあって, そこらへんで実体を指している。ここんとこは~~フルパス名が入ってるだけなんで, WPFileSystem を使ってアレする必要はない~~。

もっとお手軽に, あれこれ出来る方法がある。WpTools とゆー代物がそのツール。結構便利だし, サンプルも入ってて分かりやすいかも。でも問題がない訳でもない。

◇

ところで, DrEAで EAをみてると .ICONPOSに, 今回のものに似たようなのがあるのは上に書いた通り。でも, これはアイコンの位置ってだけみたい。ちなみに D), F), A) とあるのは, D は Directory, F は File, A は Abstract を表してるよーだ。たぶん。この A のときの後に続く 16進数はハンドルっぽい。(確かめてない (^^; けど)

WPFileSystem については, すでに公開済みだよね。んーむ, それなりにとゆーか, かなりとゆーかアレだったかも。 (←？)

フォルダー情報が消えてしまうこと -- '98.10.31

〆(^^) のマシンのファイルシステムには, HPFSを使ってたりする。 FAT は FDのためのもの, とはいえ順番を好きに並び変えることができる。コレは便利といえば便利。この点 HPFSでは, B-Tree のためか sortされている (内部で, そう管理されている)。これが HPFSの嫌いな点だったんだよね。 (DOS から読み書きができないという問題は iHPFSを使えば「読むこと」はできる訳で, それ程不都合じゃない)
しかし /2マガで紹介があったように, 複数カラム＆小アイコンとか詳細表示にすると, その状況は一転する。 DOSでは fd.com 等を使って書替えないと不可能だった順番の入れ替えが, WPS ではマウス一つで簡単に入れ替える事ができる。

ここまでだったら(今回書いたことって)「便利な使い方」で終わってしまう (つか「常識」でしかないよね)。けれど, ここに問題が潜んでたりする。その「並べた順番」というのが突然消失してしまう。アイコン表示が左上から隙間なく整列させられていたりすることがあるのだ。別に, マシンをリセットしなければならない事態に陥ったりして, その影響で・・・って訳でも何でもない。どういう時かというと, 他のとこにフォルダーを複写しておいて作業した後, その複写した作業領域を削除した時とか, そんな感じの作業。それから, ネットワークを介して別の場所からアクセスした時。
そう, そんなとき丁度 RmFPosを使ったかのように, その情報がきれいさっぱり・・・ (← 宣伝モードかも (^^)＼(バキ☆)

つまりその現象って, 消した訳でもないのにそのフォルダー情報が勝手に削除されている ということ。試しに, フォルダーの拡張属性(EA)を観てみると (←DrEAとかで (^^)＼(バキ☆)
.CLASSINFO に次のような文字列が入っている事がある (「文字列」でね)。

200005@1020,200005@20,240388@1020,240388@20

これがフォルダー情報へのポインターになっている(っぽい)。@の後ろの数字は, アイコン表示とかツリー表示とか詳細表示とかを表している。その前の部分はハンドル(のよーなもの)。通常はそのフォルダー自身を指している事が多い。この例の場合 200005と 240388の 2つの種類があるので, このフォルダーとは別なものも指している。これはフォルダーを複写した時などに付く事があるっぽい。意味は多分, そこから派生したとかいう事なのだろう(たぶん)。で, 別にこれはこれでオッケー (^^)v

だが, フォルダーを削除したりする時に, そのフォルダーの「フォルダー情報」を消すのは当然だけど, ついでにオリジナル側の「フォルダー情報」までをも消しに行ってしまう。(FX00505でも直っていないようだ (T_T )
ほかに, フォルダー情報を共有するパターンというのがあるのかどうか分からないけど, そういう場合にも片方を変更するともう片方の位置やサイズが変わる事があるはず。

で, 「フォルダー情報」が削除されると, そのフォルダーを開く時に新規に開くものと勘違いするのか, 順番がリセットされる。その情報がなかったことにされ, 無視されてしまう。そのフォルダーの拡張属性 .ICONPOS に, 正しい順番が入っていても!

ここが分かれば, ある程度の対応はできる(かも)。 (← 問題点が直ればベストなんだけどね)
もしフォルダーを開いてみて, そういう情報が壊れている! と分かったら, 慌てずにそのフォルダーの拡張属性(EA)を退避する (特に .ICONPOSを)。ただし, 退避する前に一度でもそのフォルダーを閉じてしまってはダメ。閉じると拡張属性(EA)には今の並びの情報が書き込まれるから, 間違った情報が書き込まれる前に退避すること。 退避しおわったら, フォルダーを閉じて, 先ほどの拡張属性(EA)を適用させるって訳。

eautil /s /p そのフォルダー xxx.ea
 ※ xxx.ea は適当なファイル名。
ここでフォルダーを一旦閉じ, 再び開いて位置や大きさを整え, 再度閉じる
eautil /j /o そのフォルダー xxx.ea
 ※ xxx.ea は先ほどのファイル名。

その後, このフォルダーを開いてみると, 正常ならば元どおりにファイルが並んでいるはず。 Desktopがそういう「失われた」状態になることもたまに聞くので, この方法で解決できるカモー。

もしも複写したフォルダーをこれから削除しようという場合は, もっと簡単な方法がある。先にオリジナルフォルダーを開いておくのだ。それも作業中ずっと。んで, 作業が終わった後にオリジナルも閉じる。拡張属性(EA)もフォルダー情報もこの時点で最新のものが登録される。

◇

このとおりやって出来なかったぞ, とかいう苦情は受付けません。あはは。 (^^; 念のため。お約束ですが・・・何らかの被害を被ったとしても責任は負いません。これらの作業を行う時には各自の責任において行って下さい。

Contents :
List #01 :	フォルダー情報が消えてしまうこと
List #02 :	抽象オブジェクト
List #03 :	続. 抽象オブジェクト
List #04 :	続続. 抽象オブジェクト
List #05 :	アイコンの位置
List #06 :	アイコンのある風景
List #07 :	なにをいまさら『WP』
List #08 :	INIファイル・INIファイル
List #09 :	WarpCenter

Warpっぽくいこう