メモリの割り当て

[戻る]
べし 2004/09/16(木) 09:30:11
質問です。

環境:Win2000,VC++6.0,MFCです。

Virtualallocである領域を確保します。
確保した領域に一定のタイミングで決まった量のデータが入ります。

入ってきたデータを確保した領域の後ろ?のほうに退避させたいです。
退避させる理由は、ある一定のタイミングでデータが入ってくるので入っていたデータ
は問答無用で消されてしまいます。
入ってくるデータをとめることは出来ません。

Virtualallocで確保したメモリ内のデータの移動(退避)方法を教えてください。
よろしくお願いします。

REE 2004/09/16(木) 10:11:54
移動したいタイミングで、メモリをコピーして下さい。

今の情報で分かるのはこれくらいです。

Bosscat 2004/09/16(木) 10:14:46
ワザワザVirtualAllocする理由は?

普通のmallocで耐えられるなら、そちらの方が良いと思う。

メモリ割当てアルゴリズムを自分で実装するのはよっぽどのことですよ!

少なくとも以下のことがわからなければ、判断できません。
・データのサイズ
・データの流入間隔
・データ処理時間
・そのデータの処理

アルゴリズム自体はMSDNにも載ってた気がする。
アルゴリズムは↓のような物がある。名前自体はうろ覚え・・・ゴメン
・ファーストフィット
・ジャストフィット
・その他・・・

ようは、空き領域の探し方と判定法が違う。

アイススケーター 2004/09/16(木) 10:33:15
こういった場合、サイクリックファイルにすれば問題ないはずですが。
書き込み側のソフトは変更できないの?

シャノン 2004/09/16(木) 11:05:54
新しいデータが後ろに入るのでよければ…

最初に VirtualAlloc でデカい領域を予約だけしておいて
実際にデータが入ってきた段階で、後ろの方をアドレス指定してコミットするとか。

べし 2004/09/16(木) 14:17:26
返答ありがとうございます。

入ってくるデータは画像でサイズは300Mバイト程度になります。
結構でかいです。

データの流入間隔は...ごめんなさい。今ちょっと分かりません。調べてきます。

データ処理時間、そのデータの処理はこれから実装するのでまだ不明です。
データの取り込みに間に合うような処理をしなくてはならないので
出来るだけデータのコピーに時間を掛けられません。

実は、書き込み側のソフトは変更できるので上記の流入間隔はいかようにでも
変更できるんですが可能な限り早くと言われているので書き込み側のソフトは変更なし
の方向で...。

僕が考えているのは以下の方法です。
Virtualallocで元画像の2倍と余裕をみて+αのサイズの領域確保します。
確保した領域の先頭から画像が入ってくるので、その入ってきた画像の末端から
ちょいとオフセットしたところに入ったデータをそのままコピーする。
で、コピー先で処理をするって方法です。

画像のサイズは固定で可変しません。

ファーストフィット、ジャストフィット、サイクリックファイル調べてみます。

Bosscat 2004/09/16(木) 15:47:35
> データ処理時間、そのデータの処理はこれから実装するのでまだ不明です。
> データの取り込みに間に合うような処理をしなくてはならないので

間に合うならば、コピーの必要が無いように思います。


しかし、一番気になるのは、「べし」さんが、VirtualAllocを選択した理由です。
色々考えているように見受けられるのですが、、
正直、「べし」さんのスキルを測りかねてます。

仮想メモリ空間と物理メモリ空間を明確に認識していて、
旨くそのリンクを化かしてやろうとしているならば、それは無理です。

理由は、物理メモリは基本的にCPU閉じた話であり、
CPU内部キャッシュ絡みに縛られています。

仮想空間中の領域コピーに関して、性能的に有利な方法はありません。
(通常のポインタと同様に扱ってください)

通常、固定領域をmallocしておく方法で問題はありません。

ただし、仮想メモリ空間を明示的に管理したかったり、
COMIT等を明示的に行って、ワーキングセットを管理しようとしているならば
突っ込む必要はないでしょう。

アイススケーター 2004/09/16(木) 17:19:12
>入ってくるデータは画像でサイズは300Mバイト程度になります。
>結構でかいです。

ファイルが大きすぎます。
変なこと考えないで、ファイルに保存することをお薦めします。

REE 2004/09/16(木) 17:37:23
>出来るだけデータのコピーに時間を掛けられません。

>実は、書き込み側のソフトは変更できるので上記の流入間隔はいかようにでも

これらのことから考えると、始めからメモリorファイル(約300Mバイト)を2面持っておい
て、
書き込む側でも処理する側でも、交互に処理すればよいのではないですか?

PATIO 2004/09/17(金) 10:16:26
サイズが300Mもあるんでしたら素直にファイルに落としたほうが
安全だと思いますけれどねぇ。
ファイル保存にかかる時間が心配ならREEさんの案も拝借して
バッファを二つ用意しておいて交互に使用するようにして
データが載った方をファイルに落とす仕組みを作っておくのがよいと
思います。
Bosscatさんが言われているように書き込まれている内容だけで考えると
わざわざVirtualAllocを使う理由がわかりません。
単なるバッファなら普通にGlobalAlloc使っても大差は無いと思います。
もしかしてデータ引渡し上の条件にあるのかなぁ。
VirtualAllocで確保したものを引き渡し場所に用意しろとか。

画像データに加工をしたいのであれば、ファイルから読み出して
やれば、取り込みタイミングを気にする必要はありませんしね。
加工側は別スレッドにしても良いだろうし、別プロセスでも良いかも
しれませんね。

オンメモリで処理しなければいけない理由とか設計上の制約の話が
説明されていないので方法的には確実な線という事で。

2004/09/17(金) 13:12:25
VirtualAlloc() を用いる事にしたわけが書いていないのでなんとも判断がつかないのですが
仮想記憶ということに付いてあまりお分かりでないのか、十分な知識があっての上での決定
なのかで書き方も違ってくるのでその辺りが知りたいですね

データーが入ってくるという書き方も気になります。ビデオのように動画を意識しているのか
なにかのハードウエアーがあって、デバイスドライバーが特定の領域に転送するのか
転送の主体が窺い知れるようなことはさっぱり書いていません
仕事の上で秘守契約か何かで書けない事でもあるのでしょうか。それならそうと書いてくれれば
いいのですが、なんだかすっきりません

数ギガバイトのメモリーが積めるご時世なので300MBがでかすぎるとも思いませんが
実メモリーが少なければ、どのように確保しようとも物理メモリー上に存在することを
強制することはた易いことではありません(どこかにしわ寄せが来るという意味です)
しかもどのように VirtualAlloc() を使うつもりなのかも書いていないのでますます
返答が困難です。AWE(アドレスウインドウ化エクステンションというらしい)を利用して
物理空間を扱いたいということなのでしょうか
メモリーが有り余るほど積んでいる環境ならいい手かもしれません(私は薦めませんが)

たく [E-Mail] 2004/09/17(金) 13:37:09
リングバッファ

はる 2004/09/18(土) 01:30:38
「出来るだけ早く!」という要求なのですから
VirtualAllocでメモリをコミットしておくのはよい方法だと思います。

で
なるべく早くコピーせいという要求でしょ
さっさとmemcpyするのが一番早い。

早く!という要求の回答に、なんでファイルを使えなどという
言葉がでてくるのか理解に苦しみますな。

アイススケーター 2004/09/18(土) 08:36:45
>早く!という要求の回答に、なんでファイルを使えなどという
>言葉がでてくるのか理解に苦しみますな。

経験上のことです。

環境(ハード)は書いてないし、仕様は不明確、このため想像するしかないのですが、
「300MBのデータをn個操作する。」
こう書かれただけで、現状の標準的なハードでは、ファイルを使わざるをえないと考える
のは普通だと思いますが。
実際に、メモリが512MBしかない環境で、300MBのデータを2個以上管理しよう
とすれば、スワップが発生してファイル操作するよりかえって遅くなると思いますが。

技術的な話で盛り上がるのもよいとは思うのですが、現実的なフォローも必要なのでは
ないでしょうか。

2004/09/18(土) 08:39:59
Win32 では、malloc() でも GlobalAlloc() でも HeapAlloc() でも最後には
VirtualAlloc() に辿り着くので、その意味で VirtualAlloc() が他の手段より優れて
いるということが理解できません。それに、どの道仮想記憶なのだから、どのように確保
してもその領域を物理記憶上に貼り付けておくことは(AWE を除いては)保証が無いから
(十分な主記憶が積んであれば別ですが)memcpy() がファイルより速いというのは
どの程度の違いを指してのことなのか判りかねます。確かに、ファイルはOSが絡むが
memcpy() は API でさえないのでその分早そうに思えますが、例えば、300MBの領域が
全て常に物理記憶上に存在することが保証できなければ結局ページファイルと主記憶との
交換(ページイン、ページアウト)が発生するので、ファイルに出力するより速いという
主張はあまり説得力がありません

Bosscat 2004/09/19(日) 02:29:42
> Win32 では、malloc() でも GlobalAlloc() でも HeapAlloc() でも最後には
> VirtualAlloc() に辿り着くので、<略>

私の知りうる限り(1年前です)Windows2000Proにおいてその様な動作はしないハズです。
HeapAlloc()の先はシステムコールとなっていました。
(new malloc() 達はHeapAlloc()に落ちていきます、VirtualAlloc()もシステムコールに
落ちていきます。)

ページフォルトの抑止に関して:
最近、ここの掲示板に書いたと思いますが、、
これらの抑止はVirtualAlloc()及びVirtualLock()によって制御可能です。
なので、性能計算の条件はオンメモリ上として算出可能です。

もちろん、普通の環境では、他のアプリケーションも有り、
ページフォルトの抑止がパフォーマンスに好影響を与えるとは限りません(ほとんど逆)。
しかし、開発環境によってはそれが許される場合があります。

ヨタ話:
極端な話、ワーキングセット自体を管理下に置くならば
ページフォルトを起こす場合にも、その時間を計算し切ることが可能です。
(極々一部の組み込み系の仕事を除いてメリットはありませんが、、、)
私自身、ワーキングセット自体を意識しての作業となると、
(既存システムの)速度計算ならやったことはありますが、設計したことはありませ
ん。。。

はる 2004/09/19(日) 08:13:36
>実際に、メモリが512MBしかない環境で、300MBのデータを2個以上管理しよ
>うとすれば・・・

最初からVirtualallocの使用が前提の質問だよね・・・
300MBのデータの倍を確保するって言ってますしね。

メモリが512MB のPC?
300MB×2=600MB
Virtualallocは物理メモリの予約と確保を行う関数です。

確保できないじゃん。
ん〜なPC 使用想定外じゃないの?

2004/09/19(日) 10:10:05
>Virtualallocは物理メモリの予約と確保を行う関数です
"Virtual" って「仮想」ではなく「物理」だったんでしたか!
私は「物理」記憶は "Physical" だと信じていましたが改宗しなければならないようですね

>ん〜なPC 使用想定外じゃないの?
その”想定”についてどこにも何も触れていないのだから、私はそのような仮定はしません

はる 2004/09/19(日) 10:41:26
>>Virtualallocは物理メモリの予約と確保を行う関数です
>"Virtual" って「仮想」ではなく「物理」だったんでしたか!
>私は「物理」記憶は "Physical" だと信じていましたが改宗しなければならないよう
>ですね

VirtualAllocでメモリをコミットするとは
プロセスの仮想空間に物理メモリを割り当てると意味したと思うのだけど?
MSDNを読んで実際にコードかいてますか?

はる 2004/09/19(日) 10:48:48
あ 島さんごめんね
もしPhysicalAllocとか物理メモリを予約して使える関数が
別にあるなら私の勉強不足です。
おしえてくださいね。

2004/09/19(日) 11:26:39
>VirtualAllocでメモリをコミットするとは
>プロセスの仮想空間に物理メモリを割り当てると意味したと思うのだけど?
面倒なので MSDN の日本語のページから引用します
<ここから>
メモリ内またはディスクのページングファイル内に、指定されたページ領域に相当する
物理的な記憶域を割り当てます
<ここまで>
のことを指しているのだとしたら、仮想空間に実際の物理領域が対応するということを指して
いると私は読みます。これは MEM_COMMIT と MEM_RESERVE との違いについて書いていると
読みました(予約したら、参加(参与、確定?)できます)
MEM_RESERVE は番地を予約するだけなので MEM_COMMIT で実際に取るまでは仮想記憶を
操作しないから自由度が高いと彼ら(MS)は言っているのですね、欲しいときと、使いたいとき
とが違うことがあるので、そのように使えますよということでしょう
あくまで仮想記憶空間の話だと思いますが(記憶域であって、物理(実)番地が割り当る
わけではないのでそう判断します。仮想空間の番地は物理空間の番地とは別物ですから)、
”またはディスクのページングファイル内に、”があるのですから。
もっとも、物理記憶をページファイルも含めて解釈なさっているのなら別です。
 #物理記憶(空間/番地)は仮想記憶(空間/番地)と対比させて使うものだと思いますけど
 #違うのかな

>MSDNを読んで実際にコードかいてますか?
いつも MSDN は読むわけではなく、判らないことが出たときには MSDN で調べます
今回も間違ってはいけないと思い、英語の方も日本語の方も WEB 版で調べてから投稿しました
よ
実際にコード書いてるかという質問ですがこれは VirtualAlloc() 使ったことあるか
という意味なんでしょうか?
それとも口先ばかりでコード書けない(書かない)ひよこちゃんは黙ってなさいといいたいので
しょうか?

cvbnm 2004/09/19(日) 13:28:18
>もしPhysicalAllocとか物理メモリを予約して使える関数が
>別にあるなら私の勉強不足です。

VirtualLock かしら?

Pt-2000 2004/09/19(日) 14:04:43
MSDN を確認しても、仮想記憶のコミットで物理記憶ではないという島さんの認識が正しい。

仮想記憶が実際にメモリとページングファイルのどっちにわりあてられるかはWINDOWSが決
めることで物理記憶がオンメモリの保証なんてどこにも書いてない。実装メモリ256MBの環境
で256MBのコミットできるようなAPIだ。それは関数名からも明白。高級OSの動作として
も納得できる。

あまるほどメモリを積んでればオンメモリの可能性は高いが、実行状況によってディスクに落とさ
れる可能性は消えない。アプリには物理領域のコミットなど不可能な以上「可能な限り早く」動作
するためにVirtualAllocする理由はないが、他のメモリ確保に劣る根拠もない。実環
境で比較計測したらいかが?

>確保した領域の先頭から画像が入ってくるので、その入ってきた画像の末端から
>ちょいとオフセットしたところに入ったデータをそのままコピーする。
>で、コピー先で処理をするって方法です。
島さんが懸念するようなドライバの制約などがない限りコピーが無駄。「可能な限りは早く」する
には最初から確保域を2分割して交互に切り替えて使用するべき。

はる 2004/09/19(日) 16:26:43
どこを読んだのかね?

以下 MSDNからのコピー



解説
VirtualAlloc 関数


VirtualAlloc 関数は、次の操作のいずれかを実行します。

・以前に VirtualAlloc 関数を呼び出して予約したページ領域をコミットする。
・空きページ領域を予約する。
・空きページ領域を予約し、同時にコミットする。

VirtualAlloc を使って一連のブロックページを予約し、その後 VirtualAlloc を呼び出
して予約済みのページ領域を徐々にコミットできます。この結果、必要が生じるまで物
理記憶域を消費することなく、仮想アドレス空間の一定の範囲を予約できます。

プロセスの仮想アドレス空間内の各ページは、次のいずれかの状態になります。

空き 

このページは予約もコミットもされていません。プロセスはこのページにアクセスでき
ません。VirtualAlloc は、空きページの予約、または予約とコミットを同時に行うこと
ができます。 

予約済み 

このアドレス範囲は、他の割り当て関数から利用できませんが、これらのページはアク
セスできませんし、物理記憶域も関連付けられていません。VirtualAlloc 関数を使っ
て、予約ページをコミットすることができますが、2 回目の予約を行うことはできませ
ん。VirtualFree 関数を使うと、予約ページを解放し、空きページにできます。 

コミット済み 

このページには物理記憶域が割り当てられていて、アクセス保護コードによってアクセ
スは制御されています。このページの読み取りまたは書き込みを最初に試みた場合にの
み、システムは各コミット済みページを初期化し、物理メモリへロードします。プロセ
スが終了すると、システムはコミット済みページに関連付けられていた記憶域を解放し
ます。VirtualAlloc は、既にコミット済みになっているページをコミットできます。こ
れは、既にコミットされているかどうかにかかわりなく、任意のページ範囲をコミット
できること、およびその場合にこの関数が失敗しないことを意味します。VirtualFree 
はコミット済みのページをコミット解除したり、コミット解除と解放を同時に行うこと
ができます。 


コミット済み このページには物理記憶域が割り当てられていて、
コミット済み このページには物理記憶域が割り当てられていて、
コミット済み このページには物理記憶域が割り当てられていて、
コミット済み このページには物理記憶域が割り当てられていて、
コミット済み このページには物理記憶域が割り当てられていて、

みえないか? この文字が・・・・

isshi 2004/09/19(日) 16:51:16
>コミット済み このページには物理記憶域が割り当てられていて、
>
>みえないか? この文字が・・・・

島さんも指摘されていますが。
  MEM_COMMIT メモリ内またはディスクのページングファイル内に、指定されたページ
  領域に相当する物理的な記憶域を割り当てます。 
とMSDNにかいてあります。
物理的記憶域=メモリではありません。

メモリへ固定するには VirtualLock を使います。

はる 2004/09/19(日) 17:53:11
皆様はVirtualAllocを使うときに物理メモリ量を考えていないのですか?

そのとおり。
メモリへ固定するには VirtualAllocでコミットしてページにたいして
VirtualLock を使います。

isshi 2004/09/19(日) 18:17:44
ん?話がかみ合っていないような。

>コミット済み このページには物理記憶域が割り当てられていて、
>
>みえないか? この文字が・・・・
という発言は、Pt-2000さんの
>仮想記憶のコミットで物理記憶ではない・・・
に対してのものだったようですね?
何か勘違いしていました。失礼しました。

2004/09/19(日) 19:17:52
>皆様はVirtualAllocを使うときに物理メモリ量を考えていないのですか?
はい、malloc(), new(), GlobalAlloc(), HeapAlloc() いずれの場合でも
主記憶の搭載バイト数は気にしません。どちらかというとページファイルの方が
気になります(仮想記憶なんだから主記憶の搭載量は気にしなくていいよということを
目指しているというのに、なんだか変だと感じます)

>コミット済み このページには物理記憶域が割り当てられていて、
>みえないか? この文字が・・・・
あまり趣味の良くない書き方、言葉遣いですね
2004/09/19(日) 11:26:39 の投稿にそれに関して書いたのですが、どこか変でしたか?
間違いや誤解があるというのならそうはっきり書いてくださいな
頭悪いので、遠まわしな書き方ではさっぱり判りません

はる 2004/09/19(日) 19:52:07
気にしないのですね。
自分のアプリのメモリ制限も考えたことないのでしょうね。
画像処理ソフトをお願いできるスキルではないと思います。

べしさん
メモリを取得する関数にはいろいろありますが
300Mバイトという大量データを可能な限り早く処理すると言われているなら
わたしはVirtualallocという選択は正しいと思います。
なぜならVirtualallocはべしさんのような使い方をするために作られたAPIだからです。

malloc関数はAPI HeapAllocを利用しています。
ヒープは、領域が不足すると自動的に拡張を行って拡張をしますが、一度拡張されたヒ
ープは、HeapFree で領域を解放しても元には戻りません。
取得するメモリーのサイズが一定でないときには断片化が発生する可能性が高く、不必
要にヒープサイズが拡大し、システムや他のアプリケーションの動作をを圧迫したり、
システムのパフォーマンス低下を招くことになりかねません。
このため、大量にメモリーを確保して利用しなければならないときのために
VirtualAlloc が存在します。

メモリ管理関数は物理メモリをどう使うかを用途に応じて考えて作られた関数で
物理メモリを無視するためにつくられた関数ではないと思っています。

Pt-2000 2004/09/19(日) 22:52:57
>ヒープは、領域が不足すると自動的に拡張を行って拡張をしますが、一度拡張されたヒープ
>は、HeapFree で領域を解放しても元には戻りません。(中略)このため、大量にメモリーを
>確保して利用しなければならないときのためにVirtualAlloc が存在します。
たしかにその通りですが、サイズの2倍+αを確保してコピーするというべしさんの設計では
確保は起動時に一度で開放は終了時のみで断片化は考慮不要でしょう。VirtualLockで掴
みつづければ確かにオンメモリですが、他アプリの起動を禁止できないOSですから起動時にロック
に失敗した場合の想定は必要です。そして、常にロックしながら動作するのであれば他アプリの動作
の圧迫など覚悟の上でしょう。システムのパフォーマンスは環境を作っての実測を薦めます。

>メモリ管理関数は物理メモリをどう使うかを用途に応じて考えて作られた関数で
>物理メモリを無視するためにつくられた関数ではないと思っています。
同意します。ただアプリの物理メモリ操作を無制限に認めることはシステムの安定性にもかかわりま
すから制限があることは確かで、高級OS上ではできない事(OSが許可しない事)はできません。
選択肢は複数提供されてますからそれを比較検討すればいいだけで「出来る限り」早くするために出
来ない事を悩んでも仕方ありません。リアルタイムOSのように処理完了時間が保証されるわけでも
ありませんしOSの処理時間は実環境で計測するくらいしかないでしょう。

>仮想記憶なんだから主記憶の搭載量は気にしなくていいよということを
>目指しているというのに、なんだか変だと感じます)
仮想記憶の目的はこれだけではないと思いますし理想と現実も違います。トレードオフを選択できる
のがベストで、一般の小物単発アプリが気にしなくていいのは大きな利点ですが、大量消費や長時間
常駐するようなアプリはいろいろと気にするべきです。これが気にできないとそれは大きな欠点です
からVirtualAllocはこのために存在します。

ドライバ製作も選択肢に入れればより早い手段もあるのかもしれませんが、毎回のコピーが削り所だ
と思う以外にはべしさんの設計は普通だと思います。

はる 2004/09/19(日) 23:12:35
VirtualAllocは書いたとおりですが、アプリの最低稼動環境を記述して
提供することにして VirtualLock は私も使いません。

ユーザが最低稼動環境を無視してアプリを使用して、データの取りこぼしなどが発生し
た場合。VirtualLockをしていなければシステムに大きな影響はでませんので、アプリの
最低稼動環境を守ってくださいといえばいい。
VirtualLockをしてしまった場合、システムはとても悲劇的な動作をする場合がありま
す。これは言い逃れができない。

以上、この件、私の投稿は終わりです。
言葉が悪いのは反省します。気分を害された方申し訳ない。

zxcv 2004/09/21(火) 22:15:43
>言葉が悪いのは反省します。気分を害された方申し訳ない。

そんなことより、

>メモリが512MB のPC?
>300MB×2=600MB
>Virtualallocは物理メモリの予約と確保を行う関数です。
>
>確保できないじゃん。

これは「嘘でしょ?マジで?」と自分は思ったんだけど、正しいんでしょうか?
どなたか、本当のことを教えてください。

はる 2004/09/22(水) 00:41:07
はい。ごめんなさいね。うそです。
確保できます。
これ書いてた時はオオバカです。

でも確保できても使い物にはならないです。

PATIO 2004/09/22(水) 14:41:33
思うんですが、べしさんが言われていると言うのは、
どの部分を出来る限り早くしたいのでしょう?

流れ込んでくるデータは止められないからメモリを出来る限り早くあけてほしい
と言う話なのか、そもそも受け取った後の処理は何なんでしょう。
メモリを早く開けたいだけなら、一時退避にファイルを使ってもよいような
気もしますけれど。
というか、むしろ私はそっちのつもりでした。
いずれにしても処理したデータは何らかの形で出力しないといけないのでは
無いかと思うんですが、それについても触れられていません。
メモリ上を移動しても処理後に出力してそこを空けないと次のデータを
退避できませんから。
ならば、取り敢えず出力しておいて処理はそっちでやれば、
取り込み側は独立して動けると思ったんですけれどねぇ。
まあ、状況から良くと300MBのメモリを二つも取れないわけなので
いずれにせよスワップが発生してそこで足を引っ張られますね。

ところで思うんですが、質問者の方は何処へ行かれたのでしょうね。

PATIO 2004/09/22(水) 14:54:44
あー、誤字が。

誤)
>まあ、状況から良くと300MBのメモリを二つも取れないわけなので

正)
 まあ、状況からいくと300MBのメモリを二つも取れないわけなので

あと蛇足ですが、
VirtualAllocにしろ、GlobalAllocにしろ結局そのアプリケーションの
基本スタンスが問題になると思います。
はるさんが掲げた基本スタンスを取るならVirtualAllcでもよいでしょうし、
取れないような状況ならエラーで終了するとか、メモリの状態を見て足りないと
判断できれば、起動不可能でメッセージ出して終了と言うのもスタンスでしょう。
それに関しては、スタンスの問題なのでそこまで否定的に書かなくても良いと
思います。
実際には質問者からこの辺の基本スタンスも提示はされていませんしね。
もうちょっと突っ込んだ情報提供があれば、状況が特定できたと思いますね。

Bosscat 2004/09/22(水) 16:49:47
> ところで思うんですが、質問者の方は何処へ行かれたのでしょうね。

何処行ったも何も、議論の方がどっか行っちゃった気がしますが・・・

流石にこの状況で、このスレッドに責任持てとは言い難くありません?

PATIO 2004/09/22(水) 16:58:25
それはそうかも。

難しい所ですが、肝心の質問内容に関しての説明も不十分なままなので
かなり消化不良を起こしてます。(T-T)

まあ、出来れば復帰願って調べてみます以降から話をしたいところですねぇ。
スレッド内に書き込まれている内容(言葉遣いとか枝葉はさて置き)に関しては
それなりに意味があったと思うのでこのまま閉じるのは忍びないです。
勝手に閉じるわけにも行きませんしねぇ。

古いスレッドには追加発言できません。