- 1 名前：名無し募集中。。。 [05/01/15 02:18:37]
- UNIXおよびUNIX clone環境一般のプログラミングに関する質問スレッド
前スレ
Part4 pc5.2ch.net/test/read.cgi/tech/1095843584/
Part3 pc5.2ch.net/test/read.cgi/tech/1085930894/
Part2 pc5.2ch.net/test/read.cgi/tech/1055110889/
Part1 pc2.2ch.net/tech/kako/992/992057422.html
Part3のミラー
makimo.to/2ch/pc5_tech/1085/1085930894.html
Part2のミラー
makimo.to/2ch/pc5_tech/1055/1055110889.html
関連スレ
Cygwin使っている人いますか？ その13 (UNIX板)
pc5.2ch.net/test/read.cgi/unix/1099157755/
Cygwin使っている人いますか？ 3 (Windows板)
pc5.2ch.net/test/read.cgi/win/1090131123/
関連板
pc5.2ch.net/unix/
pc5.2ch.net/linux/
- 345 名前：デフォルトの名無しさん mailto:sage [05/03/01 18:44:52 ]
- >>342
なんか最近は自作自演で回ってるみたい。
俺も眠たくなってきた。
- 346 名前：デフォルトの名無しさん mailto:sage [05/03/01 18:45:41 ]
- nkf
- 347 名前：デフォルトの名無しさん mailto:sage [05/03/01 18:49:49 ]
- ELFフォーマットってUNIX共通ですか？
実行ファイルに細工したいので
UNIXの実行ファイルのフォーマットを教えてください。
- 348 名前：デフォルトの名無しさん mailto:sage [05/03/01 18:53:34 ]
- 1年くらい前にも見たな。ウィルスでも作るのか？
- 349 名前：デフォルトの名無しさん mailto:sage [05/03/01 18:55:37 ]
- Windowsのリソースの真似事がしたいのです。
わかりますか？リソース
- 350 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:00:04 ]
- 過去ログでsharとか言ってた人がいますが、
セキュリティの減ったくれもないので使いたくありません。
WindowsでいうPEへのセクション追加ぐらいの手間で解決したいのです。
- 351 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:01:33 ]
- アーキテクチャに依存しないデータは、あまりバイナリの中には入れないよねUNIXの場合。
- 352 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:03:07 ]
- コメント領域があったと思うけど勝手に使えば
- 353 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:04:59 ]
- こたえる気がないなら答えなきゃいいのに。
- 354 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:05:58 ]
- >>349
リンカでつなげば？
- 355 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:07:58 ]
- >>354
何言ってんの？このタコは
- 356 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:11:10 ]
- リソースってようするに初期済みのデータだろ？
- 357 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:18:15 ]
- >>351
だから何ですか？
一般論を聞きたいのではなく、
入れたい場合が出てきたということです。
>>352
詳しく教えてください。
>>354
リンカでどうやって繋ぐのでしょうか？
>>356
初期済みのデータが初期化済みデータのことならその通りです。
- 358 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:31:03 ]
- そういえばX Windowってリソース管理どうなってんの？
アイコンとかって外部ファイル？
もしかしていちいちパス指定で取ってきてる？
パス管理複雑にならない？
- 359 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:31:28 ]
- Cで初期化された大域変数をリンクするのと同じということでは？
ELFの話はLinkers & Loadersていう本にそれなりに載ってる気がする。
- 360 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:31:52 ]
- X or X Window System
- 361 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:38:33 ]
- つまんねー揚げ足すんなよ
おまえ、つまんねー奴って言われるだろ
- 362 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:39:22 ]
- >>359
そういうことでしたら
既存の実行ファイルに対して追加したいので
リンカを使う方法は無理です。
- 363 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:40:35 ]
- >>357
>だから何ですか？
漏れは351じゃないけど、別に多少関連した雑談や世間話くらいしても良いと思うんだけど・・・
質問と回答以外はスレ違い、っていう立場もあるのかもしれないけど。
>リンカでどうやって繋ぐのでしょうか？
テキトーなバイナリなりXMLなり文字列なりをソースとして、
const unsigned char appResourceHoge[] = { 0x11, 0x22, .............. };
みたいなソースファイルを出力するスクリプトなんかを使う。
Xのコードとか書いたことがあればイメージできると思う。
実行ファイルに細工したい（ソース無しでリソースだけ変更したい）って用途には向かない。
なんだから偉そうな質問者様に対してこんな返事しかできなくてごめんね。
- 364 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:40:43 ]
- なあ、俺もUNIXでトロイ作りたいんだけど、
実行ファイルのフォーマット教えてくれよ
- 365 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:41:29 ]
- >>362
ん？既存の実行ファイルを弄らないなら埋め込んでも意味ないだろ？
埋め込んだ上でそれを使うように修正しないと
- 366 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:41:56 ]
- >>363
うわ、そんなことできるならはじめからやってるだよ
- 367 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:42:53 ]
- どうやらここのUNIX使い様はリソースって概念がわからんらしい
- 368 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:43:23 ]
- >>365
Windowsのリソースのように、バイナリに埋め込まれていてかつ後から
編集できるデータ格納方法は無いだろうか、という質問だと思うが。
コード自体は自分で書くのだろう。
- 369 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:44:14 ]
- >>368
そう思ってたが >>362 を読んで違うのかと思った
- 370 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:46:59 ]
- あらかじめリソース予定地とする空のゴミ領域を作っておいて、
後でマジックナンバーか何かで検索して挿げ替えるとか、かなあ。
- 371 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:50:07 ]
- ユーザに差し替えさすならもっと優しい方法にしろ。
自分で埋めるならリンカ使えるだろ
人のアプリをどうこうするなら、Winのリソース差し替えのようにはいかない。
- 372 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:52:23 ]
- だからELFの.commentに好きなフォーマットでデータ埋め込んで、
実行時にファイル開いてELFヘッダからその領域を見ればいいんじゃ。
OSのバグ踏む可能性あるけど
- 373 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:53:02 ]
- そもそもUNIXの実行ファイルはELFフォーマットなの？
それでいいの？
- 374 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:55:52 ]
- ELFが多いだろうけど全部じゃないんじゃない？
- 375 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:59:16 ]
- UNIXのOSはリソースというものを扱えるの？
もし、OSの支援が無いならば、
実行プロセスが自分自身の元になった実行ファイルの所在を
正確に把握する手段を持たなくてはいけないはず。
これって、少し前に出ていた設定ファイルの議論と重なるような気がする。
- 376 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:11:33 ]
- なんでここの連中は仮定で話したがるかね
ちゃっちゃと調べて実際をどうなのかを書けよ
- 377 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:12:56 ]
- > UNIXのOSはリソースというものを扱えるの？
リソースにもいろいろあるでしょ。
メモリとかディスクとかいったリソースならもちろん扱える。
人的リソースみたいなものは、OSの守備範囲外だから当然無理。
てゆうか、そもそも質問が意味不明。
> 実行プロセスが自分自身の元になった実行ファイルの所在を
> 正確に把握する手段を持たなくてはいけないはず。
> これって、少し前に出ていた設定ファイルの議論と重なるような気がする。
実行ファイルのディスク上の物理位置は正確に把握している。
パス名は把握しても意味がない (Windows と違い、実行ファイル
のパス名が存在しなくなっても実行を継続できる) から、そんな
ものは記録しないってのは、このスレでさんざん既出。
なんか、基本的な素養に欠けているって感じの質問だなあ。
ソースとまでは言わんから、せめて本ぐらい読めというか。
- 378 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:13:15 ]
- そうはいかんざき
- 379 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:13:46 ]
- >>376
質問スレだから。
質問だけするのが正しい態度。
- 380 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:14:10 ]
- >>377
だったら最初からこの本読めとかリンク出せよヴォケ
- 381 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:14:50 ]
- で、アイコンとかダイアログのリソースはどっから取ってきてるのかね？ん？
- 382 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:16:20 ]
- ある一人のレスが浮き上がって見える
- 383 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:16:41 ]
- >>377
>リソースにもいろいろあるでしょ。
この流れだとWindowsや(旧)Macで言うところのリソースのことではないでしょうか。
>>381
WineではPEファイルから取ってくるみたいですよ。
- 384 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:18:59 ]
- たった今、UNIXに挫折したとです。
- 385 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:20:04 ]
- UNIXで良書なんて見たことないから
どこに載ってるか書いて欲しいなあ。
- 386 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:20:41 ]
- >>384
！！！そのキーワードは、
いっちゃいかん！！
- 387 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:21:49 ]
- WindowsみたいなリソースはOSはサポートしないだろう。
- 388 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:23:21 ]
- リソースがなにを指しているか分からないと、
本の名前も出せないでしょ。
>>381みたいな質問している人にOSの本勧めても
無意味だし。
>>381
Xの場合、ダイアローグの表示はツールキットの
仕事なのでツールキットの種類によりけり。
アイコンの表示はウィンドウマネージャの仕事
なので、ウィンドウマネージャによりけり。
(ツールキットが決まると、ツールキット標準の
ウィンドウマネージャが決まる場合もある。)
知りたいツールキットとウィンドウマネージャの
種類を具体的に述べれば、もっと具体的な答も
出せるかもね。
いにしえのXtとtwmで言うなら
/usr/X11R6/include/X11/{bitmaps,pixmaps}/
と /usr/X11R6/lib/X11/app-defaults/ あたりが
標準的な場所なわけだが。(アプリケーション固有
の場所に置くこともできる。)
ツールキットは狭義ではOSの一部ではない。
>>387が言ってるのはそういう意味。
- 389 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:23:27 ]
- つか、ELFをばらして好きに弄ってもう一回固めればいいんじゃないの？
- 390 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:26:23 ]
- >>389
わかってないなあ
- 391 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:27:27 ]
- UNIXを捨てた
おれは正解を選んだ
- 392 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:28:33 ]
- 452 名前：デフォルトの名無しさん 投稿日：05/02/28 01:15:33
もうUNIXで仕事したくないのに
UNIXの仕事がきます。
どうすればよいですか？
453 名前：デフォルトの名無しさん 投稿日：05/02/28 01:18:47
仕事があるだけマシってもんよ
そうだろう？兄弟
454 名前：デフォルトの名無しさん 投稿日：05/02/28 01:26:38
もういやだ！
もういやだ！
もういやだ！
- 393 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:30:51 ]
- あほくさ
- 394 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:31:13 ]
- ELFフォーマットを採用してるOSを上げてください。
自分はLinux以外知りません。
- 395 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:34:08 ]
- >>394
商用、フリーを問わず、現役のUNIX系OS、ほぼ全て。
ELF の規格を定めたのは、AT&T と Sun じゃないかな。
linux は最初のうちはa.outしかサポートしてなかったね。
- 396 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:35:29 ]
- じゃ、とりあえずELFでトロイ作ってみるよ。
あんがと。
- 397 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:37:56 ]
- Windowsヲタは固定観念のかたまりだな...
- 398 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:38:25 ]
- >>394
Solaris, *BSD, IRIX, SVR4 等...
最近は組み込み用途の開発ツールも ELF を吐き出す.
- 399 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:40:27 ]
- BSD系は最近だな
- 400 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:42:04 ]
- CPUの種類やOSの種類が異なると、同じ elf でも
使える命令セットやシステムコールが異なるので、
同一のトロイの木馬を複数のOSに対応させるのは
面倒なんだけどね。まあやれば当然できるが。
つうか、そういうものを作るだけの知恵のある奴は、
ふつうはもう少し建設的なことに暇を使うと思うんだが。
そういう、できて当たり前で、人が困るだけのプログラム
を作るのは、そういうことの判断ができない頭弱い奴だけ
じゃない？
- 401 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:58:38 ]
- 商用UNIXだとしっかりしてるんだけどね。
- 402 名前：デフォルトの名無しさん [05/03/01 22:05:13 ]
- お前ら落ち着け
- 403 名前：デフォルトの名無しさん mailto:sage [05/03/01 22:09:20 ]
- さては藻前も釣りだな。
- 404 名前：デフォルトの名無しさん mailto:sage [05/03/01 22:25:28 ]
- UNIXにもノートンみたいな製品を進出させるには
トロイとかウィルスばらまかないとね
需要のための供給
- 405 名前：だよもん mailto:だよもん [05/03/01 22:37:03 ]
- だよもんウィルスだよもん
- 406 名前：335 mailto:sage [05/03/01 22:49:49 ]
- １文書に複数文字コードが入ってるとか，そういうややこしいのじゃなくて
１文書が１つの文字コードに限定されてるんです．
>>341
そうです．自動判別”も”したいんですけど，
どうも良いライブラリがみつかんないんですよねぇ．
>>344
>文字コードを自動判別しないといけない時点で負け。
orz.
完全に自動判別すんのが厳しいのは分かってるんですけど…
大体でよいんです．
>>346
nkfに渡すのも考えてるんですけど…
ライブラリ化されてて使いやすいのはないものかと．
- 407 名前：デフォルトの名無しさん mailto:sage [05/03/01 23:36:56 ]
- >>335
tricklib.com/cxx/ex/babel/
g++ だと多少問題があるらしいがこれはどうだ？
僅かな文字数でも高い精度で判別できるぞ。
- 408 名前：デフォルトの名無しさん mailto:sage [05/03/02 11:14:24 ]
- コードに日本語でコメントが入っているというだけで
使う気がしなくなるのは俺だけか？
- 409 名前：デフォルトの名無しさん mailto:sage [05/03/02 11:23:12 ]
- ↑ソースクレ厨
- 410 名前：デフォルトの名無しさん mailto:sage [05/03/02 13:38:21 ]
- ↑車輪を何度も再発明して貴重な人生を無駄にする香具師
- 411 名前：デフォルトの名無しさん mailto:sage [05/03/02 15:11:02 ]
- >>410
↑見ず知らずの他人の趣味を「人生の無駄」呼ばわりする香具師
- 412 名前：335 mailto:sage [05/03/02 15:50:59 ]
- >407
ありがとうございます。よさげですね。
g++だと何か問題があるんですかね？
ちょっと試してみます。
- 413 名前：デフォルトの名無しさん [05/03/03 23:45:23 ]
-
- 414 名前：デフォルトの名無しさん mailto:sage [05/03/05 05:52:29 ]
- 各種UNIXでcursesの互換性ってどの程度まであるの？
- 415 名前：デフォルトの名無しさん [05/03/05 11:28:09 ]
- 問題ないくらい
- 416 名前：デフォルトの名無しさん [05/03/07 13:17:21 ]
- linuxだとアドレス値を整数演算するときに
unsigned longに入れてるんだけど、これって
128bitCPUが出てきたときに問題にならないの？
- 417 名前：デフォルトの名無しさん mailto:sage [05/03/07 13:30:53 ]
- 問題になるかならないかは不明。
128bit CPU が実用になる時代が本当に来たとしても、
その CPU で long>=128bit なら問題にならない。
long<128bit なら問題になる。
一般論としては、そういう用途には unsigned long では
なく、uintptr_t ないし intptr_t を使うべき。
この型は C99 なら #include <stdint.h> すると定義
される。
- 418 名前：デフォルトの名無しさん [05/03/07 13:42:04 ]
- >>416
longを128bitにするから問題なし。
- 419 名前：デフォルトの名無しさん mailto:sage [05/03/07 13:42:08 ]
- 仮想メモリアドレスの時代に型の大きさなんて気にしても仕方がないと思う
ほとんどの場合unsignedにする意味なし
Linuxのプロセスメモリマップの使い方でも調べたほうが賢明
- 420 名前：デフォルトの名無しさん mailto:sage [05/03/07 14:16:30 ]
- >仮想メモリアドレスの時代に型の大きさなんて気にしても仕方がないと思う
なんだこりゃ
- 421 名前：デフォルトの名無しさん mailto:sage [05/03/07 18:18:53 ]
- >>419 さんは、>>416 さんが 「 unsigned 」 を疑問視されていると受け取られた
ようでつね。
対して、多くの方々は >>416 さんが疑問視しているのは 「 long 」 の方だと・・・
どちらにしても、>>417 さんの答えで解決でつよね？
- 422 名前：デフォルトの名無しさん mailto:sage [05/03/07 19:12:18 ]
- UNIXが採用してるLP64というCの型システムだけど、
128bitCPUが出てきたときは、LP128というものを定義して、
unsigned longはつねにポインタサイズと同じビット長になる
ことを暗に想定してるのかな？
LP128だと
short(16),int(32),long(128),long long(128)
こんな感じなのかな？
>>128
>一般論としては、そういう用途には unsigned long では
>なく、uintptr_t ないし intptr_t を使うべき。
ですよねえ
- 423 名前：デフォルトの名無しさん mailto:sage [05/03/07 19:22:13 ]
- システムによって定義されるのはたった数個の型だけど、
これがいろんな型にtypedefされて、またそれらが
インターフェイスの定義に既に使われていたりするところが
ややこしいね。
- 424 名前：デフォルトの名無しさん mailto:sage [05/03/07 19:50:19 ]
- >>422
予測できる将来に128bit CPUが実現するかどうかは
良く分からないけど、もし実現したらUNIX系は
short:int:long:long long=16:32:64:128 になるん
じゃないかなあ。だって、1/2/4/8/16 全てのサイズの
整数型が使えないと不便でしょ。
今やuintptr_tがあるから、long がポインタ変数を
保持できるとかいった仮定を設ける必要ないし。
- 425 名前：デフォルトの名無しさん mailto:sage [05/03/07 19:53:29 ]
- とりあえず、LP64, ILP64, LLP64, ILP32, LP32くらい理解してからレスしろよ、この屑。
www.opengroup.org/public/tech/aspen/lp64_wp.htm
- 426 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:19:14 ]
- LP64・・・longとポインタが64ビットに
ILP64・・・intとlongとポインタが64ビットに
LLP64・・・long longとポインタが64ビットに
ILP32・・・intとlongとポインタは32ビット(今の32bit向けCコンパイラはこれかな？)
LP32・・・longとポインタは32ビット、intは16ビット
こんな感じ？
- 427 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:23:57 ]
- TRANSITION FROM CURRENT INDUSTRY PRACTICEも読め。
- 428 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:29:51 ]
- 128bit化なんてその時になってから泥縄的に考えればいいんだよ。
もし動かなかったらIBMに金出させて力技で修正すればいいだけ。
今困っていない事を今対応するな。これがLinuxのモットーだ。
- 429 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:33:26 ]
- 128bit が主流になる頃はおいらは隠居してる.
勝手にやってくれ.
- 430 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:48:26 ]
- というか32→64の経験でスキームは固まっている。
- 431 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:52:54 ]
- ところでIPV5って64bitだったの?
- 432 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:54:59 ]
- 型同士の相対的な関係と実際のデータ長っていう
二つの視点で見るとこんなかな。
UNIXは32bit,64bitそれぞれILP32とLP64だけど、
char:short:int:longそれぞれ
ILP32 8:16:32:32 32(pointer)
LP64 8:16:32:64 64(pointer)
ILP32からLP64への移行で変わったのは、
(int,long)と(int,pointer)の相対的関係が変わったことと、
longとpointerの実際のデータ長が変わったということ。
char:short:int:long:long long
ILP128 8:16:128:128:128
LP128 8:16:32:128:128
LLP128 8:16:32:64:128
128bitCPUにおいてはこんな感じのがありえると思うけど、
今UNIXで32bit64bit両方に通用するコードとしてlong=pointerという
仮定の元にコードを書いてしまうともうLP128しかないと思うんだよね。
というかILP32から64bit化においてLP64を採用した時点で
long=pointerという想定を受け入れてるように見える。
ILP128はちょっとありえないね。LP64でせっかくintの実データ長を32で固定した意味がなくなる。
LLP128が1番よさそうに見えるけど、LP64からlongとpointerの相対的関係が異なる。
素人考えだとLP128しかなさそうに見えるけど。
- 433 名前：デフォルトの名無しさん mailto:sage [05/03/07 21:01:51 ]
- つーか128bit時代にもなってLinux使ってたとしたらソフトウェア界の敗北だな。
- 434 名前：デフォルトの名無しさん mailto:sage [05/03/07 21:02:19 ]
- > LP64からlongとpointerの相対的関係が異なる
だから intptr_t, uintptr_t を使えってばさ。
それで問題なし。
- 435 名前：デフォルトの名無しさん mailto:sage [05/03/07 21:43:35 ]
- 32bitマシンって1960年代にできて、64bitマシンって1990年頃
だよね。30年くらいかかっている。
同じような指数的ペースで発展する(1年で1bitくらい)として
128bit マシンができるのは、2050年を過ぎたぐらい…
俺は死んでるな。
- 436 名前：デフォルトの名無しさん mailto:sage [05/03/07 21:46:46 ]
- UNIX/Cを潰したいメーカーが96bitマシンとか出して来たりして。
- 437 名前：デフォルトの名無しさん mailto:sage [05/03/07 22:51:54 ]
- なぜbit数が増えるのか
という根源的な疑問は起きないのか？
- 438 名前：デフォルトの名無しさん mailto:sage [05/03/07 22:59:35 ]
- 基本的にはストレージのサイズが増えるからという要因が
一番大きいでしょ。(AS/400 みたいに、アドレス空間の
ほとんどを無駄に捨てざるをえないアーキテクチャだと
話は別だが。)
問題は、現在の指数関数的なストレージサイズの増大が、
あと50年続くかどうかと、たとえ続いたとしても、そんなに
使い道があるかどうかだな。
64ビットでも、人類ひとりひとりに、それぞれ2GB以上も
あるというのに。
- 439 名前：デフォルトの名無しさん mailto:sage [05/03/07 23:02:38 ]
- いつの時代もそういう近視眼的な発言をする奴がいたわけで
- 440 名前：デフォルトの名無しさん mailto:sage [05/03/07 23:05:37 ]
- いつの日にか、家庭向けPCで地球シミュレーションが軽く動く日がくるんだよ
- 441 名前：デフォルトの名無しさん mailto:sage [05/03/07 23:07:41 ]
- 昔、12bit マシンってのもあったぞ。
- 442 名前：429 mailto:sage [05/03/08 01:57:05 ]
- >>439
438 じゃないんだけど, そのころはおいらは隠居してるわけだ.
興味ねぇ.
>>438
> 基本的にはストレージのサイズが増えるからという要因が
> 一番大きいでしょ。
数値計算とかやってると, アドレッシングできる領域がどれだけ増
えても実際の計算速度が上がらないと, メリットは小さい.
やっと 64bit を有効に使える計算速度に達したってのが現実では?
# DB 検索なんかでもそぉだと思うぞ, エンジン作ってる連中にし
# てみれば...
- 443 名前：デフォルトの名無しさん mailto:sage [05/03/08 01:59:32 ]
- >>429
ダウト。
データベースとか情報検索とかはとっくに64bitないと話にならなくなってる。
- 444 名前：デフォルトの名無しさん mailto:sage [05/03/08 02:36:39 ]
- ファイルシステムが2G4G以上をサポートしてる時点で64bit化の恩恵を受けられるわけで。
- 445 名前：デフォルトの名無しさん mailto:sage [05/03/08 03:12:48 ]
- >>444
ブー。mmapが使えないと結構苦しい。
|
 |
