BeDevTalk(&BeCodeTalk)[以下、Be*Talkと省略させて頂きます^^;)]は、デベロッパ諸氏の気さくな会話が飛び交うML(=Mailing Listの略)であるため、よく分からない略語や、辞書で引けない表現が出てきて立ち往生してしまう事が頻繁にあります。しかし、例えデベロッパぢゃなくても、BeOSフリークにとってBe*Talkはいろんな情報の宝庫であり、出来ればこまめにチェックしておきたいもの。
そこで、ここでは過去のBe*Talkで出現頻度の高かった略語や、特殊な表現、スラング等を解説します。これと翻訳ソフト、辞書ソフトがあれば、あなたのBe*Talkライフも楽になる事請け合い!?
このページでは、Be*Talkでしばしば登場し、読み手を悩ませる
勢い込んで作ってみたはいいものの、私がよく見かける略語としては、今のところこれくらいしか思い付きません^^;)。Be*Talkに出入りしていらっしゃる方、出入りしていらっしゃらない方を問わず、BeOSコミュニティに関連ありそうな表現・略語等でしばしば顔を出すものにお気付きの方、あるいは『こんな表現・略語を載せて欲しい』というご要望のある方、是非私まで教えて下さい。勿論、激励やご叱責、間違いのご指摘もお待ちしておりますので、どんどんお寄せ下さい^^)。
Advanced Access Preview Releaseの略。1997年5月にリリースされた、BeOS Preview Release(DR9)の早期配布版の意。AAPRとも書きます。
このAA:PRから、Dockが無くなりTrackerに変わった、Unicodeが正式にサポートされる様になった、システム標準のデータベースが無くなり、一時的にe-mailが使えなくなった等、大幅な変化の入ったリリースでした。
Analog Digital Converterの略。元はCDプレイヤーに搭載されている、アナログ信号をデジタル信号に変換する回路/チップの事です。
********* ここからちょっと脱線 *********
音というのは、空気の粗密が時間的・空間的に変化する事により発生するものなので、縦波として定式化出来ます。つまり、音情報というのは(かなり大まかな説明ですが)周波数(振動数)と音圧(振幅)で規定出来るので、音声をデジタル信号として扱う場合、音声の波形情報を時間軸方向と音圧方向に量子化してやる事により、ビット列に変換します。現行CD(Compact Disc)規格の場合、サンプリング・レート44.1kHzで16ビットの量子化を行う訳ですが、これは時間軸方向を44,100/秒に分割、音圧方向を65,536/100dB?に分割した方眼紙を用意し、波がどこの升目にあるのかという情報に置き換えてやる事に相当します。こうする事により、可聴周波数帯域(大体20Hz〜20kHz位だと言われています)をカバーする数Hz〜22.05kHzの音声を再現する事が可能になっています。
しかし、現実の世界で発生する音には、一般に倍音(波形の骨格を形成する音波−基音−のn倍の周波数の音波のこと)が含まれており、音色の違いにはこの倍音がどんなふうに載っかっているかが大きく影響すると言われています。そして、こうした倍音成分の処理まで考えると、上記周波数帯域は、こうした倍音情報を再現するために十分ではないという説もあります(倍音成分まで考えると、人間の耳には40〜50kHzの音まで聞こえているという説もある)。よく、同一アルバムのアナログオリジナル版とCDリマスタリング版を聴き比べて、アナログ版の方が良いという話をする人がいますが、これはあながち懐古趣味とは片づけられない訳です。
また、量子化の上限は上に書いた通りですが、下限は理論上1HzまでOKです。しかし、ちょっと絵を描いてみると分かるのですが、数十Hzの周波数域になると、量子化した波形は矩形波に近づいていってしまいます。つまり、最終的に音波に戻す時に、誤差が大きくなり易くなる訳なんですが、低音というのは、耳で聴く以上に、振動として体感するという要素が大きいため、こうした低周波がうまく再現出来ないと、臨場感に欠けた音になってしまう訳です(とはいえ、一般的な再生装置−スピーカーでは、100Hz以下の帯域はまともに再生出来ていないので、実生活の中では事実上問題ないという話もあるんですけど)。
ちなみに、オーバー・サンプリングというのは、時間軸方向に升目を細分化する事に相当し、これを行う場合、細分化する升目の両側の値などをもとに、間がどういった点で繋がるのかを計算によって補間してやる訳ですが、この補間が上手に行えれば、元のアナログ波形に近い波形を再現出来る事になる訳です。ビットマップファイルの拡大・縮小をする時にも、同じ様な事をしてますね。
************** 脱線終わり **************
逆にデジタル信号をアナログ信号に変換する回路/チップはDACとなります。MIDIキット内の変数として定義されているBADCStreamの真ん中の部分はこの意味です。
ADMINistrationの略。管理の意。Be*Talk管理者(List Guy)のMichael A. Aldereteさんが、ML管理者のお知らせとして発言をする場合に、標題に
[ADMIN]○○○○○○○○
Audio Elementsの略。Adam(ちょっと困ったちゃんな作りになってしまっているところもありますが、個人的にはとても好きなメールクライアントです:-)等の販売でも知られるAdamation社が発売する、オーディオ/サウンド処理プログラムのこと。ミュージシャンやサウンドデザイナーが使うことを想定して開発されている様です。
このAEは、IEの作者として有名なAttila Mezei氏の手によるものです。ヴィジュアルにオーディオプロセッシングアプリケーションの開発が出来るので、デモに使うにはもってこいです。また、プラグイン形式に対応していて、SDKなんかも公開されているので、こっち方面に興味のある方は、使ってみると良いかもです。
As Far As I Knowの略。「私の知る限りにおいては」の意。
辞書的には、不可知論(者)の、という意。Be流の言葉として、
CPU agnostism(CPU不可知論)
というのがあるのですが、これはBeOSはCPUにこだわらないという事です。BeOSの歴史をひもとくと、使用されるCPUは、AT&T Hobbit(こいつは試作段階のBeBoxマザーに搭載されていて、日の目を見る事なく消えてしまいました。念のため)→PowerPC→Intel Pentiumと来ていますが、お次は日立SH(SH4?)辺りなのでしょうか?
SH4は、一足お先にセガのDreamcastに搭載されましたね。
文脈依存ですが、BeOSにおいてこのAという文字が単独で登場する場合、Alpha Channel(アルファチャネル)を表す事があります。このアルファチャネル、確か用途が厳密に規定されている訳では無いと思うのですが、一般的には画像の透明度等を表すパラメターとして使われています。
BeOSでも、RGBのところで述べた色深度情報に加え、透明度を指定するための変数として、AA:PRからAlpha値が用意されました。このアルファ値は、rgb_color構造体において、
typedef struct {と定義されています。
uint8 red;
uint8 green;
uint8 blue;
uint8 alpha;
} rgb_color
ここでややこしいのは、PR1までは、32bit colorにおけるアルファチャネルのデフォルト値は"0"だったのですが、PR2からこいつが"255"に変更になった事です(個人的には、PR1までの定義の方があとあと楽じゃないかと思うのですが。先々48ビットカラーをサポートするなんて事になった場合、Aは12ビットに拡張される事になるので、デフォルト値は4095に変えなくちゃなんですが...)。また、PR2の時点では、色深度変数の指定時にRGBAを全部指定しても、Aの部分は無視されるのでどっちでも良くなってしまっているのですが、今後(Release3から?)アルファ値もきちんと渡される様になるため、ビットマップ等をコード中に埋め込みたいといった様な理由で、色深度の情報をハードコードしている場合には、Aの指定に気を付ける必要があります。
なお、BeOSにおいては、ビットマップファイルはlittle endian形式で格納されます。つまりビットマップファイルの各ピクセル情報は、RGBAではなくて、ABGRの順になる訳ですね。これに絡んで、AA:PRでは、Magnifyを使った場合に、拡大されたデスクトップの色が変になるというバグがありました。何か紛らわしくて、扱いにくそうなのですが、いちおうrgb_colorの定数としては、
B_BIG_RGB_16_BITというのが用意してあって、一時的にbig endian配列のビットマップを扱いたい場合は、これを使って変数を定義して、そこにbig endian形式のビットマップを読み込み、little endian形式への変換を行えばよいようです。
B_BIG_RGB_32_BIT
それからrgb_colorの定義においては、上記の通り、red,green,blue,alphaともuint8になっており、等価なのですが、16ビットの色空間においては、R,G,Bが各5ビット、アルファ値が1ビットになっている様です。
こことRGBの項は間違いがあったのと、記述内容が不正確だったのとで、修正を加えました。Yuuichi Makinoさん、ご指摘をどうもありがとうございました。
ANNounceの略。要は「お知らせ」の意ですね。Be社からの告知事項や、デベロッパの方々がBeWareの新作やバージョンアップのお知らせをする時に、標題に
Application Programming Interfaceの略。対応する日本語ってあるんでしょうか?
As Soon As Possibleの略。「可能な限り早く」の意。
Application Specific Integrated Circuitsの略。正確な訳語は知らないのですが、特定用途応用型ICとでも訳せば良いのでしょうか^^;)。
PCにおいては、周辺機器のコントロール用の回路を集積化して、基板占有面積の削減や回路品質の向上のために使われるようです。
どこで読んだか忘れてしまった(確かBeDevTalk/BeCodeTalkのどちらかでした)のですが、Be社がBeOS/Intelに関連して、CPUのすっぴんの性能ではPowerPCが整数演算性能、浮動小数点演算性能ともPentium(II/Pro)よりも優れているのに、何故システムとしてのスループットはIntel版の方が良いのか?という疑問に答えています。Macで使われているPCIコントローラ用ASICの出来がよろしくないためだそうな。
Be社の公式APIリファレンスであるBe Advanced Topicの略。
Be社の公式APIリファレンスであるBe Developer's Guideの略。
BeWareデベロッパ必読のプログラマーズリファレンスの事。現時点では、
オフラインドキュメント(/boot/beos/document/BeBook/)の3種類で提供されています。
オンラインドキュメント(http://www.be.com/documentation/be_book/index.html)
製本版(http://www.ora.com/catalog/bedev/)
製本版については、DR8の頃に一時Be社自身がバインダー形式の製本版を販売していましたが、PR用のものからO'Reillyが出版する様になり、"Be Developer's Guide"と"Be Advanced Topics(こちらは1998年3月に発売予定)"に2分される事になりました。
BeOSの世界もDog Yearというか、R4/IntelではついにCWは必要なくなってしまいましたね。
モトローラのCPUファミリーは、すべてビッグ・エンディアンだそうです(endian/endiannessのところで書いた通り、PowerPCは例外なんですが)。"The New Hacker's Dictionary" によれば、IBM 370ファミリー(大型汎用機ですね)やPDP-10、1995年以降の殆どのRISC CPUは、すべてビッグ・エンディアンだそうです。
例えばBeOSという文字列が、そのまま
bit per pixelの略。ピクセル当たりの色深度の意。通常ディスプレイの同時発色数の説明に使われ、
- 8bpp= 256色
- 15bpp= 32,767色
- 16bpp= 65,536色
- 24bpp= 16,777,216色
になります。
今後ここに"distributed","fully Java compatible","CORBA compliance"なんていうのが入って来るのかなあ?
可変長で多数の高度な命令セットを備えたCPUの事を言います。代表的なのはIntelのx86系プロセッサなんですが、Pentium等は、RISCチップで演算性能の向上のために取り入れられたスーパースカラー、パイプライン処理や分岐予測といった技術がどんどん取り入れられてしまっていますし、RISC側でも命令セットはどんどん複雑化してきているため、今や両社の区別は曖昧です。
ちなみに、Pentiumチップの発表当時、Intelの関係者はこれをCRISCであると言ってました^^)。
ELFやPEFと同じく、binary executable formatの一つだそうです。出自や具体的な適用事例は調べきれなかったのですが、UNIXやDOS/Windows(???)等でも採用されている、かなりメジャーなフォーマットらしいです。BeOS for Intelでは、このCOFFの拡張仕様?であるPE-COFFがサポートされるそうです。
ちなみにXCOFFというのもあるんですが、これは"eXtended COFF"の略ではないかと推測しております。どうやらPowerPCのOFWというのが絡んでるみたいなんですが、今度はこのOFWがよく分からない^^;)。
Concurrent Versioning Systemの略。Cyclic Software社により提供されている、ソースコードの履歴管理などを行うための、かなりメジャーなプログラム。Linux,FreeBSD,MacOS,Win95/98/NTなど、多くのプラットフォームに移植されていますが、最近になって漸くBeOS上でも使える様になりました。UNIXに標準インストールされている(らしい...)RCSと比べると、グループでの開発作業に適しているそうです。CVS Manualなんてページがあるので、知っておくととても便利かもです。
その他のバージョン管理システムとしては、MERANT社(旧Intersolv社)の開発したPVCSや、SCCSなんてのもあるそうです。
個人的には、Be社がMetrowerks社から得た最も大きな財産はJon Watte氏だと思ふ。
逆にアナログ信号をデジタル信号に変換する回路/チップはADCとなります。MIDIキット内の変数として定義されているBDACStreamの真ん中の部分はこの意味です。
...それにしても、EGCSって一体何の略なんだろーオフィシャルページにも出てないんだよね^^;)
これも難しくて全く分からんのですが、COFF/XCOFFやPEFと同様のbinary executable formatらしいです。もともとはUSL(UNIX System Laboratories)で開発されたフォーマットだそうでして、現在はSun microsystems, Inc.のSolarisやUNIX System V Release 4といったOS、更に実行時性能はやや劣るらしいのですが、
例えば
リトル・エンディアンの方は直感的でないので、何故こんな並びで扱うの?と疑問に持たれる方もいらっしゃると思いますが、確かこれはこれでコンピュータ君にとっては扱い易いという話があった様に記憶しています。当然ミドル・エンディアン(middle endian)なんていうのもありまして、この方法だと、
歴史的に見ると、MotorolaのCPUはビッグ・エンディアンをずっと採用してきており、一方IntelのCPUはリトル・エンディアンを採用してきています。
ややこしいのはPowerPCでして、こいつはもともとCHRPプラットフォームにおけるマルチOSのブートが可能なCPUとして開発されたという経緯があるため、リトル・エンディアンも受け付けられる様になっています(Bi-Endianだそうな^^))。但し、デフォルトはビッグエンディアンなので、BeOS/PowerPCがビッグエンディアンを採用しているのは、当たり前の話ではあるのですが。
この辺りの詳しい情報をお知りになりたい方は、モトローラ社から出版されている「PowerPCプログラマーズリファレンス」の第3章をご覧になって下さい。
OS自体が何故バイ・エンディアン化してしまったかという理由の憶測はさておき、こうした状況ですので、何もしなければ、両プラットフォーム間でバイナリーレベルでの互換性がなくなってしまう危険性があります。
これはアプリケーションのみならず、アプリケーションの生成するファイルやオブジェクトのポータビリティーに多大なる影響を及ぼします。そのため、Be社は、PR2から、その次のリリースとなるRelease3で実現されるIntel CPUのサポートを先取りして、開発用のヘッダファイル(/boot/develop/headers/Be/)の中に、byteorder.hというのを新たに用意して、バイトオーダー変換用マクロを定義しました。これを上手に使って、エンディアン非依存のアプリケーションを書いてくれ、というのがBe社の解答な訳ですね。
なお、一般的に異なるエンディアンのシステム間でデータ交換を行う場合は、相手方のエンディアンに合うように変換をかけてやる必要が生じますが、これをbyte-swappingと言います。
余談ですが、(可能かどうかはよく分かりませんが)Intel CPUにBeOSを無理矢理ビッグ・エンディアン形式を維持しつつ実装した場合には、アプリケーション側でバイト・オーダーに気を使わなくてもよいのですが、OSレベルで見てみると、CPUの命令が実行される毎にバイト・スワッピングを行う必要が生じてしまうでしょう。これではBeOS/Intelの実行時性能は極端に落ちてしまう事が避けられないと思われますし、BeOS/PPC←→BeOS/Intelに閉じた話ならまだしも、ネットワークを通じて外に出ていく場合や、FAT/NTFS/HPFS等の読み書きを出来る様にするためには結局byte-swappingが不可欠になってくるので、Be社の選択は当然と言えるかも知れません。
Frequently Asked Questionの略。文字通り訳せば、「頻繁に訊ねられる質問」となります。疑問に思う事があったら、自分で一通り調べてみましょう。案外近くに回答は転がっているものです(って半分自戒込みf^^;)。
皆さんはFAQって何と読みますか。私は特に気にせず「ふぁっく」と読んでしまうのですが、同じ読みで全然別の意味があるので、「えふえーきゅー」と読む人も多いみたいです。でも私ゃSQLを「しーける」と読んだり、CMDを「こむど」と読んだりする人に違和感を感じてしまいます。
Be*Talkの管理者であるMichael A. Alderete氏の事。またの名をList Fanaticとも言う。
Field-Upgraded Three Letter Acronym(s)の略。MIME,SNMP,NNTP,DBCS,...などなど、あまたある4文字略語の事。
NIHの欄で述べた一連の略語議論の中であった、「TLAが3文字熟語だという事は分かったけど、4文字熟語もたくさんあるよ」という発言に対しての返答。私ゃ思いきり笑いました。
なお、"The New Hacker's Dictionary" によると、4文字略語を表す略語^^;)としては、この他にETLA (Extended Three-Letter Acronym)だとか、SFLA (Stupid Four-Letter Acronym)なんてのもあるそうです。前者は上のBeDevTalkにおける定義づけと似てますね^^)。
ちなみにBeOS Release3から、遂にPPC750ドータカードにも対応する事が、BeDevTalkでBe社のDominic Giampaolo氏によって明らかにされました。但し、Appleが技術仕様を開示してくれないという理由から、Power Macintosh G3には対応していない(&今後もAppleの協力姿勢が無い限り対応しない)そうなので、BeOSを動かしたい人は注意しましょう。
GNU C Compilerの略。おそらく世界中で最も利用者の多いCコンパイラなんぢゃないでしょうか?
ちなみにGNU C++ Compilerはg++というらしいです。
ヲタクな人の事をさす言葉の様です。同じ様な言葉にnerd、hackerなんてのもあるんですが、geekの方がハードウェアまでいぢっている感じが含まれているそうな。
この言葉は、BeBoxで提供された謎の汎用ポートであるGeekPortに使われています。
ちと余談です。BeTalk-Jでお馴染みの方ですが、豊田中央研究所の谷 昌明さんは、GeekPortで本業(化学者さんだそうです)に使う様々な測定機器等を集中制御出来るかも知れない、という可能性に魅力を感じてBeBoxオーナーになられたという話が、Be Newsletter Issue46のBE DEVELOPER TALKに載っています。
Graphic Interchange Formatの略。ビットマップ画像を圧縮するための規格の一つで、UNISYS社がライセンスを持っている、ライセンス・フリーぢゃない規格の事。
JPEGに比べると圧縮効率が余り高くない事、扱える色深度が256色までに限定されている事などもあり、写真等自然画像の圧縮には向いていませんが、JPEGで圧縮率を高めた時に発生するブロック歪みが出ない事から、スクリーン・ショットやテキスト入りビットマップ等の圧縮は、こちらで行った方が綺麗になりますし、フォーマット自体にかなり拡張性があるため、ウェブブラウザでもサポートされているAnimated GIFによる簡易アニメーションが可能です。
もともとはJLGもこよなく愛するCompuServe内で画像を扱うために開発された様に記憶しているのですが、ライセンス・フィーが結構高いらしいので、資本力の無い弱小デベロッパがサポートするのは難しいみたいです。
GIFのフルスペルについては、田代邦幸さんに教えていただきました。田代さんどうもありがとうございました。
Be Inc.の頭脳(と私が勝手に呼んでいる)であるJohn Watte氏の事。でもこの意見に反論を唱える人はたぶんいないでしょう。それ位凄い人。知識の塊。Dominic Gianpaolo氏と並び、BeOSを隅から隅まで知り尽くしているんぢゃないか、という人であります。
皆様の目にとまる部分では、Translation Kit(かつてはDatatypesという名のBeWareで、R3から正式にBeOSの一部になりました)を開発した人でもあります。
氏はMetrowerks在籍時代に、幾つかのアドレスから「この人、一体いつ仕事してるんだろう/寝てるんだろう/勉強してるんだろう?」と思う位素早く、殆ど24時間体制でBeDevTalkに出されるデベロッパからの質問に返事を出しまくっていたという剛の者なんですが、このうちの一つのハンドルネームがh+だった事は、古くからBeOSに関わっている人には有名な事実です。
Watte氏のウェブページに行った事ある人はいますか?まぁJoseph Palmerと並ぶ位に日本でも知名度ダントツなんで、行った事のある人は多いんだろうと思いますが、そこで氏の住んでいた家が売りに出されているのを見てちょっとみゅるみゅるしてしまいました。そりゃWatte氏位の実力がある人なら、収入も相当あるんでしょうが、それにしても凄い家に住んでたんだなぁ、と。日米の住宅事情の歴然とした違いに暫し考え込んでしまったのでした。
ところで、最近めっきり氏の発言をBe*Talkで見かけなくなった気がするのですが、まだいますよね?事情通の方^^;)。たぶん次のリリースに向けて、開発作業にどっぷりはまっているんだろうと思ってはいるのですが...私がBe*Talkのチェックをろくにやっていないせいもあるとは思うんですけどf^^;)。
HEY BE
読んで字の如く、Beに対する呼びかけ。"Hey Be!"も同じ意。ANNと同様に、Be社に対する種々の要望事項(○○を早くサポートしてくれ、××のバグがまだ直ってないぞ、△△はどうして◇◇が出来ないのだ?などなど)を発言する時に、標題に
というふうに使います。
Intel Architectureの事。Be Newsletter Vol II, Issue31におけるJLGのコラムで"IA BeOS"と使われています。
[HEY BE]○○○○○○○○
[Hey Be!]○○○○○○○○
IA
IDE
Code Warrior for Beにおいては、BeIDEというアプリケーションが開発の中心になります。
ちなみに、Code Warrior for Beの事はCW4Beなんて書かれたりもします。
IBM PC/AT互換機で採用され、Macintoshでも使われる用になったデバイス接続のための規格。標準ではストーレジしか繋がらない、最高で4台までのデバイスしか繋げない(Macintoshの場合、何故か1台のみ)、マスターとスレーブの設定が必要など、SCSIに比べるとちと面倒な規格であり、CPUリソースを喰うため、ディスクアクセスをがんがん行うタスクには向かないと言われているが、接続デバイスがSCSI対応のものより安いのは皆さんご存じの通り。
IEIEと言うと、世間一般では何かとお騒がせ?なInternet Explorerの略として使わている様ですが、Beの世界ではIEといったらこれです。
HungaryのプログラマーであるAttila Mezei氏の作るこのプログラム、Adamation社の発売するElementsシリーズの一つでして、名前からも分かる様に、BeOS用のGUIリソース作成ツールです。なお、Attila氏は、このほかにもBooという面白い作品をリリースしています。
今気づいたんですが、Elementsシリーズにはもう一つ、Image Elementsというのがあります。これもIEぢゃないの...
If I Remember Correctlyの略。「Be遠鏡(BeScope)」でおなじみのひろまささんも最近BeDevTalkで使っていた略語。
文字通り訳せば、「私が正確に記憶していれば」となるわけですが、「料理の鉄人」が好きな人は、「私の記憶が確かならば...」と解釈すると雰囲気?が出るでしょう;-)。
In My Humble Opinionの略。「卑見では」「私の意見では」の意(謙譲表現)。
jargon
専門語だとか、訳の分からないたわごとといった意味を持ちます。BeOSの場合、将来的にどうなるかはさておき、ユーザはデベロッパでもある事が求められていますので、ここで暮らしていくためには、沢山出てくるjargonに慣れる必要があるでしょう。
ただし、jargonというのは分からないものは分からない訳で、それを解説する事を意図したページというのはやはりここの他にも存在しています。コンピュータ業界に特有のjargonを集めたページとして "The New Hacker's Dictionary" なんてのがありまして、私もおおいに参考にさせて頂いてます。
もう一つ、最近になってとても便利なページを知りました。名前をwhatis.comと言いまして、コンピュータ関連のオンライン用語辞書になっております。この中にWhat Is...chat acronyms (chat/IRC/BBS abbreviations and acronyms) (a definition)という、略語のフルスペル解読ページがあり、ここが特にお奨めです。
Java Development Kitの略。Sun Microsystems, Inc.の子会社であるJavasoft社が開発・提供している、Javaのリファレンス開発環境の事。BeOSは現在C++とJavaを公式にサポートしておりますが、PR2に対応したCWのアップデートにより、JDK1.1.4相当のJava開発環境が提供される様になっています。
というのはもはや過去の話。R3からCWはBe社のものになりましたが、それに伴い、Javaサポートは打ち切られて現在に至っておりますT_T)。何故かと言うと、Javaのソースコードライセンスを持っているのはMetrowerks社であり、Be社はそこまで賄うための資金面(&開発面)での余裕が無いからだそうです。このままJavaは捨てられてしまうのかなぁ...
Just In Time (compiler)の略。Java VMは、Javaのbyte codeの実行時に、これを各プラットフォーム固有のマシン語に翻訳して実行するのですが、毎回byte codeを翻訳→実行していたのでは実行性能が上がらないため、Javaの最大のデメリットとして問題視されてきました。これを緩和するために、VMに実装されたのがJITコンパイラであり、ダウンロードしたアプレットの実行時にバイトコードを一気に翻訳してやる事により、以降の実行時の性能向上を図ったものです。
JDK1.2からは、このJIT(c)の考えを更に発展させたHot Spotという技術が実装されるようになり、Java環境における実行時性能の改善は更に進む事が期待されています。
言わずと知れた、Be Inc. のChairman & CEOである Jean Louis Gassée 氏の略。かつてAppleにいた時に、Macintosh IIfxという当時のフラッグシップマシンを生み出して賞賛を集めたが、Macintosh Portableではボロクソにけなされた人。Appleの時代には、MacOSのオープン化路線否定派だったが、最近改宗した事は昨今のBe社の動きを見ていても明らか。さすがフランス人というか、色気のある話が好きな人のようである。
このJLG、「アップル(上、下)」(早川書房刊、ISBN-XXXXXX)という本を読むと、ソフトウェア軽視派で、高マージンの販売体制にとことんこだわり、ライセンス供与には烈火の如く怒り倒した等々、アップルを傾かせた張本人・極悪人のごとく書かれていますが、今ではあそこに書かれている事がちょっと信じられない位に穏和な人になっている様に思います。といっても、まぁ表の顔しか知らないんですけど。本人曰く「ハイテク機械大好きのオタク」だそうですし、1998年11月12日に東京はKDDビルにて催された「BeOS R4J記者発表会(ぷらっとホーム主催)」の席においても、舞台上から客席をバシバシ撮り倒していた程のカメラ好きである事は、公然の秘密です。
Joint Picture Expert Groupの略。名前からして、もともとは規格制定のためのグループに付けられた名前だと思うのですが、何故か圧縮方法そのものを指す言葉になっています(違うのかなぁ?)。ビットマップ画像(静止画)を圧縮するためのライセンスフリーな規格の一つで、写真等の自然画像を高品質・高効率で圧縮するのに適した手法であり、現在最もポピュラーな圧縮方法です。
Kit(s)
BeOSが提供するAPI群の事。BeOSを構成する各種サーバに対応してグルーピングされており、詳細が未だきちんとドキュメント化されていないものも含めると、現在以下の様なキットが提供されています。
little endian
リトル・エンディアンです。そのままなんですけど...
インテル社のCPUが、これを採用していますが、歴史的には、DECのVAXというコンピュータやPDP-11(C言語が開発されたマシンです)がリトル・エンディアンだったために、市民権を得たみたいですし、ネットワーク関連機器も大体リトル・エンディアンなんだそうです。
big endianのとこで書いた例を使うと、BeOSという文字列が、ひっくり返って
S O e B
とLSB(Least Significant Byte;最下位バイト)からMSB(Most Significant Byte;最上位バイト)に向かって並べられる(というか、アドレスを振られる)形式の事で、Be社のいうnatural orderとは逆の並びになっています。
リトル・エンディアンなんて直感的じゃないし、何故そんな構造を?とお考えの方、実は身近に実用例があるんですよ。はがきや手紙に住所を書くときの事を考えてみて下さい。日本はビッグ・エンディアン、米国はリトル・エンディアンなんですよ^_^)。それから、インターネットのドメイン・ネーム、あれもリトル・エンディアンですね。リトル・エンディアンを採用している事例って案外多い...かも知れない^^;)です、周囲を見渡してみると。
上の文章で、「リトル・エンディアンを採用している事例って案外多いです、周囲を見渡してみると。」が「リトル・エンディアンを採用している事例って案外多い...かも知れない^^;)です、周囲を見渡してみると。」にこっそり変わってます^^;)。いや、これを書いた頃はいろいろ思いついた筈...なんですが、どうやっても他の例を思い出せなくなってしまったもので...
などが必要になります。
BeOSにハマっている人って、少なからずDTM(DeskTop Music)に興味があるでしょうから、あえて説明の必要も無いでしょうけど^^)。
Multi-purpose Internet Mail Extensionの略。直訳すれば多目的インターネットメール拡張?になりますか。本来は、文字情報しか送る事の出来ないインターネット・メールの仕様を拡張するために提案されたもの(RFC1521,1522,2045-2049,2231,MIMEの解説ページなんかを見るとよいでしょう)なんですが、BeOSにおいては、AA:PRからアプリケーションとデータファイルの関係付けを行う方式として、従来のシグネチャ方式を止めて、MIME準拠形式(MIMEタイプを指定する方式)になりました。
今のところ、MIMEタイプの付け方については、厳格なルールが規定されていませんが、最近BeWareも増えてきた事だし、ここらでBe社がきちんと登録・管理する様にしないと大変な事になってしまわないか、とちと心配です。
ちなみに、もともとのMIMEに関するRFCは上記1521,1522なんだそうですが、これは現在2045-2049にとって代わられているようです。
Be社のbuild engineer(どういうお仕事をする人か知りたい人は、「闘うプログラマー 上/下」(日経BP出版センター;ISBN4-8227-4016-1)を読んで下さい)であるMing Low氏が、BeOS for Intel用にUnited Microsystems, Inc.から調達したPCに付けられた名前の事。このMing Special、はじめて公表された時には、スペックの低いものから順に
の3つのコンフィギュレーションが用意されていました(最後のDoubletimeは300MHz PentiumIIx2という構成です。おそらくこいつがR3/Intelの発売前後に、デモで使われていたフルタワーのマシンなんでしょう)。初代Ming Specialのうち、Midtownは既にリストから消えており、1998年12月15日時点では、
JDK
JIT(c)
JLG
JPEG
K [1語収録]
L [1語収録]
M [7語収録]
Ming Specials
の4モデルが提供されています。DoubletimeとTwinturbo Rexは、名前からも想像が付く通り、PentiumIIを2発積んだモデルです。どうやらDoubletimeは初代と同一構成の様で、440LXマザーです。最上位スペックのTwinturbo Rexは440BXですね。どうせBeOSを使うなら、2CPU以上は欲しいところです。それにしても、上位機種の"***** Rex"という名前は、恐竜を意識しているんでしょうかねぇ?
ちなみに、このMing Specialについては、"各マシン(パッケージ)の名前はBe社のFAQ Guyが勝手に付けたものだから、United Microsystems, Inc.にこの名前でマシンのオーダーをかけてもダメだよ"と書かれていますので、ご注意を。一応現在は登録デベロッパの特典の一つとして、Ming Specialをオーダー可能になっているみたいなんですけど。
MPMulti Processingの略。BeOSは、BeBoxと共に登場した時からPowerPCによるMP(より正確にはSMP)に対応したOSで、これはBeOS for Intelにも受け継がれる予定です。
BeeVTalkにおいても、Jon Watte氏とDr. Peter Kittel氏の間で"Be and the BeBox"という標題の下、Beが何故PPC750を使ったMPシステムへの対応に注力しないのか?という問答を繰り広げられました。他にも延々終わらない(ちと横道逸れ系の)話題がいろいろと出て、メーリングリストのS/N比が下がっていた事に業を煮やしたBe*Talk管理人であるMichael A. Aldereteさんが、横道に逸れた議題を減らすために運用ポリシーを徹底し始めた事もあって、白熱しつつも程なく収束し、その後MacintouchでSamerset Design Centerの某氏が語ったとされる記事において、PPC750対応版BeOSの存在をほのめかしたため、今度はBeDevTalkの方で"PPC750&BeOS"として再燃しました。
この議論の後暫く経ってから、BeOS/PPCはPPC750を積んだサードパーティーのプロセッサ・アップグレードカードで動作するようになりました。但し、周辺のコントロールチップ等の情報が開示されていないため、R4の時点では、PowerMacintosh G3シリーズでは動作しないのは、皆さんご存じの通り。
Motion Picture Expert Groupの略。JPEGと同様に、カラー動画像を高品質・高効率で圧縮するために開発された圧縮方法の事。MPEG-1,2,3とあるらしいですが、勉強不足で詳細は不明f^^;)。
Code Warriorシリーズでお馴染み、テキサス州オースチン在の会社Metrowerksの略。MEと略して、標題に
というふうに使った人もいます。
N+
geekと似た意味を持つ単語で、ある種ヲタク的な人の事を指す言葉です。隠れキャラや裏技をとことん追求するゲーマー等に対して使う事が多いようです。BeWareの中でも比較的人気の高いNerdkillというゲームにもこの言葉が使われています。
Not Invented Hereの略。文字通り「ここ(自分たちのところ)で作られたものではない」という意味で、"NIH Syndrome"などとも使われる。如何に優れたものであろうと、自社開発の技術でないからという理由で採用しない、という頑固な姿勢を表す。
かつて、Appleが業界標準を無視して、何でも独自に作り上げ採用していく体制を揶揄するのによく使われていました。独自規格が絶対悪であるなんて事を言うデベロッパは一人もいないのですが、既にこの世に存在しており、なおかつ仕様や性能の面でも優れており、多くの人が使っているものを、敢えて独自規格で潰す様な行為は忌むべきものと考える人が多い訳です。
[例]
Be NewsletterにおいてWilliam Adams氏のコラム"News from the Front"が連載されていた当時の話です。
Be Newsletter Issue 77の"News from the Front"において、William Adams氏が既に広くcodecが公開されていてデファクトスタンダードであり、機能的に断然フレキシブルなDatatypesライブラリを使わずに、Adams氏自身のサンプルコード的なRrasterを使って記事を書いた事に対し、Chris Herborth氏が「何故datatypesを使わないのか?」と疑問を投げかけたことが発端でちょっとした議論になりました。
この議論の過程で、Datatypesの作者であるJon Watte氏(現在はBe社にいますが、当時はまだMetrowerks社でCW for Beの開発陣を率いていました)が寄せた投稿において、
> It's really sad to see NIH start creeping into the company we're all putting our hopes on.
というように、Be社においてNIH症候群が芽生え始めていると糾弾しました。
これに対して、Issue 78の"BeDevTalk Summary"という、過去1週間におけるBeDevTalkの主な話題をピックアップし、それに対するBe社としてのコメントを述べるコーナーで、早速Be社としての方針(この方針の事を"Be Line"と言います)、すなわち「Be社は決してDatatypesをないがしろにする気は無い」という事が説明されました。
とどめに次のIssue 79の"News from the Front"でWilliam Adams氏自身がAA:PRでDatatypesがバンドルされる事、そして今後はDatatypesがより深くBeOSに取り込まれて行くであろう事、つまり氏としても決してDatatypesを排除しようなんて考えていないという事を述べたため、まるく収まりました。
以下はNIHにまつわる面白いやりとりです^^)。
************* (TLAとNIHを組み合わせた応用例) Be*Talk試験2級レベル *************
> やはり、NIHの意味が分からない方もいるわけで、その人が質問しました。
********************************************************************************
(ひろまささん、ありがとうございます)
OO
Object Orientedの略。オブジェクト指向の意。これに更にP(Programming)やDB(DataBase)やD(Design,Development)なんかが付いたりします。
Siricon Graphics, Inc.が開発した、3次元グラフィックを記述するためのAPI群の事。GLはGraphics Libraryの略ですね。
もともとは、同社のグラフィック・ワークステーションに搭載されているOSであるIRIX(flavored UNIXです)向けに書かれたライブラリだったものを、他のプラットフォームでも使えるべくオープンな仕様にしたものだと記憶しています。
BeOSでは、簡易に3Dグラフィックを作成したいデベロッパのために独自ライブラリである3D Kitを用意していますが、本格的な3Dアプリケーションを開発したい人のためにこのOpenGLを移植しつつあります(R3の時点では、opengl.hを見ると、まだコメントアウトされているマクロが沢山ありますね^^))。
ちなみに、SGIやBeOS以外では、マイクロソフトのWindowsNTがOpenGLを採用している事で有名ですし、QuickDraw3Dを捨ててしまうのではないかと噂されていた(様に私は記憶している)MacOSも、とうとうOpenGLのライセンスを取得しました。
[自己フォロー]
O'Reilly & Associates, Inc.の略。言わずとしれた、Be社の公式開発者向けドキュメントを手がけている出版社の意。動物を表紙にあしらった"Nut Shell"シリーズという本でもお馴染みですね。以前BeDevTalkでも大脱線ネタとして「BeBook(=Be Developer's Guide)の表紙はどんな動物になるんだろう?」という事で話題&予想競争になりました。
何故ORAなの?と思う方も多いのでしょうが、同社のウェブページのURLがhttp://www.ora.com/となっているため、こう略されている様です...って書きながら、ようやく出た"Be Developer's Guide"の巻末見てたら、http://www.oreilly.com/になってますねぇ?
これについて確認してみたところ、oreillyの方でアクセスしても、oraの方につながりますね。
なお、「Be Developer's Guide」や「Be Advanced Topics」等の書籍は、直接O'Reillyから購入する事も可能ですが、Amazon.comから買った方が安上がりになる様です。
On The Other Handの略。「逆に」「一方」といった意をあらわす。
PE
"Patently Extraneous Format"の略。
Apple Computer, Inc.が開発した、proprietaryなPowerPCプロセッサ用の"(binary) executable format"?の事だそうです。BeOS for PowerPCでは、R4になっても、このPEFがサポートされています。
Be Newsletter Issue29の"BE ENGINEERING INSIGHTS"において、Erich Ringewald氏が"PEF -- The Patently Extraneous Format"という記事の中で、BeOSは何故PEFを採用したのか?、Be社はPEFに固執しているのか?といったを説明しています。
これはNIHのところで述べたのと同様に、BeDevTalkにおいて、何故BeOSではポピュラーなELFフォーマットやXCOFFフォーマットではなく、アップル独自のPEFが採用されたのかについて議論が巻き起こったため、それに対する回答として出されたものでした。
この辺の話になると、ディープすぎて私にはついていけないです。どなたかこの辺りの事情に詳しい方、教えて下さい...m(_ _)m
PowerPCの略。Apple,IBM,Motorolaの3社(これもかつてはAIMなんて略されてました)により開発された、RISC CPUの事。
Preview Releaseの略。初のPRとなったPR1は、1997年7月にリリースされました。無理して訳すと「予告リリース」ってな感じになるのかなぁ?
DR8.xまでのBeOSは、バージョンアップ毎にけっこう大幅なAPIの変更がなされていましたが、DR8.3→AA:PRにおける変更以降は、正式版のリリースを睨んで、既存APIの大幅な変更はされなくなりました。そのためにDR→PRと名前を変えたものと思われます。
QT
Quick Timeの略。
今さら言うまでも無いですが、Apple Computer, Inc.が開発した、多様なメディア・フォーマットを扱うための規格およびAPI群の事。BeOSでは標準でQTムービーをサポートしているのですが、最近はTranslation Kit(Datatypes)のおかげで、多様なフォーマットのファイルが扱えるようになってきました。
しっかしQT3 for Mac/Winのあのうざったいダイアログ、何とかならんのでしょうか?Pro登録しても出てくる事があるし...(-_-)。
R3
1998年12月にリリースされる(た)、BeOS Relase4のこと。OS標準で日本語入力環境が提供された、一つの金字塔的なリリース。
1999年4月に催されたBeDCに合わせてリリースされる予定だった、BeOS Relase4のマイナーバージョンアップ版のこと。
マイナーバージョンアップとは言いつつ、デバイスドライバの増加やコーデックの増加など、結構重要なアップデートになる予定でしたが、1999年6月にR4.5というアップデート版を出すという方針に変更されてしまい、結局一部のデベロッパに開発者向けベータ版が提供されただけの、幻のリリースとなってしまいました。
1998年3月にリリースされた、最新版のBeOSのこと。はじめてPC/AT互換機に対応したバージョンである。PC/AT互換機が対応プラットフォームとして加わった以外にも、色々と機能強化が図られており、中でもJohn Watte氏のDatatypesがTranslation Kitとして正式にサポートされるようになった点が注目されます。
Request For Commentの略。「意見を欲しい要望事項」という事なんですが、MIMEなどはRFCとして提唱されているものです。RFCは様々な議論を経て、インターネット上の各種規約として正式に規定されていきます。
Red,Green,Blueの略。ビットマップやグラフィックファイルでカラーを使う時に指定する3つの色(光の3原色でしたっけ?)の事。色空間(Color Space)を指定する定数として、現在
の7つの定数が用意されているのですが、PR2時点ではまだB_RGB_16_BITは使えません。
また、PR2時点では実際に使われてはいませんが、BeOSでは16ビット以上の色深度を持つビットマップ等の定義時に、RGBに加え、A(アルファ値)も指定出来るようになっています。従って、色深度定数を定義する際には、RGBだけでなく、A(アルファ値)もあるという事は覚えておいた方がよいでしょう。
上記定数について、間違いがある事をYuuichi Makinoさんから教えて頂きました。ご指摘いただき、どうもありがとうございました。
余談ですが、色の指定方法としては、この他にCMYKなんていうのもありまして、こちらはCyan(シアン)、Magenta(マゼンダ)、Yellow(イエロー)、そしてKuro(黒)の略です(最後のKが黒だというのは本当だよ^_^))...といいながら、最近BeCodeTalkで"Extended bitmap format"というスレッドが展開されているのですが、ここでJon Watte氏がこのKの事をKoverと書いています。でも私の身の回りにある辞書にはこんな単語無いんだよね...。あとはYUVだとか、いろいろとあるみたいですが、この辺りの調査は後日...
Reduced Instruction Set Computerの略。
もともとは固定長の少数でかつ単純な命令セットを備えたCPUの事を言います。
単純な命令を複数回「素早く」行う事により、CISCの複雑で高度な命令と同等の機能を果たせば、チップの設計は単純化する事が可能になり、結果的に高速化が可能になる、というのがRISC陣営の当初の目論見でして、高速化のために、スーパースカラー、パイプライン処理、分岐予測等の手法をどんどん確立し、採り入れていきました。これらの高速化技術は、現在の高速CPUではもはや当たり前の機能となる位に大いに活かされています。
しかし、PowerPCに代表される昨今のRISCはCISC並みに命令セットが複雑化し、数も多くなっていますから、CISCとの違いがますます不明瞭になりつつあります。
Real Soon Nowの略。もう、本っ当にすぐにやります!と言う意思を表すために使われる。
[例]
> [INFO RSN]Re: Not getting mouse/keyboard events
とした上で、その発言中でも、
> ...
と書いています。
(ひろまささん、ありがとうございます)
Read The "Fine" Manualの略。「あの"素晴らしい"マニュアルを読みなさい」の意。
BeDevTalkでは上記解釈を付けた方がいらっしゃるのですが、一般的には、マニュアルをきちんと読めば載っている様な事をぬけぬけと質問する人に対して批判を込めて使う"Read The Fuckin' Manual!(マニュアルくらい読まんかい、ボケ!)"の略であるとした方が通りがよいでしょう。
RunTime Type Information(実行時型情報)の略。詳しくは、「プログラミング言語C++ 第3版(ISBN:4-7561-1895-X)」をご覧あれ。
SDK
Software Development Kitの略。何らかのシステム/アプリケーションに対応したプログラムを開発するために、そのシステム/アプリケーションの開発元などから提供されるツール群(ヘッダファイル、サンプルソース、ドキュメント、ユーティリティー等)のこと。
早い話、BeOSのアプリケーション・フレームワークも、BeWare開発者のためのSDKな訳ですね。
Symmetric Multi Processingの略。日本語にすると、対称型マルチプロセッシングとなります。複数のCPUにより構成されるシステムにおいて、各CPU毎に独立したメモリを持たず、共有メモリを使って、常に複数のCPUを同等に使って計算処理を行う事。BeOSはSMP対応であるとアナウンスされています。
ApproachingBeにも書いてあった事ですが、BeOSは8CPUまでのSMPに対応可能なようです。ただし現実的にはCPUが4つ以上になると、ハードウェアにボトルネックが生じてしまうため、実行性能が余り上がらなくなるそうな。
Standard Template Library(標準テンプレートライブラリ)の略。C++でサポートされるようになった、Cで言うところの標準ライブラリ関数に相当するもので、よーく実装する処理を一からクラスとして書き起こすのでなく、テンプレートを使って多少でもラクしましょう、という思想のもとに、最近になって規定されたものです。詳しくは、「プログラミング言語C++ 第3版(ISBN:4-7561-1895-X)」をご覧あれ。
TLA(s)
Three Letter Acronym(s)の略。つまりこういった3文字略語の事。
"The New Hacker's Dictionary" によると、この定義は結構いいかげんらしくて、FLA(s)の項で書いた様な4文字略語も含めて"TLA"であると定義づける人もいるらしいです。
(ひろまささん、ありがとうございます)
TYPOgraphical errorの略。つまりキーボード入力ミスの意。
本来はコーディングをしている時に、functionと入れるべきところをfanctionと入れてしまった、といった様な些末なバグ要因の事を指して言う表現らしいのですが、一般的には、メールのやりとりやMLでの発言において、書き方が不適切である表現を訂正する場合に使ったりもするみたいです。
Unicode
Xerox,Apple Computer,Microsoft等により提唱された文字コード体系の事。ひと言で言うと、
「16bit(=1byte)で世界中の文字を表現するためのコード体系」
なんだそうです。現在はユニコード委員会という中立組織が中心になって、規格の制定やバージョンアップを行っています。
BeOSにおいては、AA:PRから正式採用されましたが、既にWindows95/NTでも使われており、MacOSも8.5よりユニコードに対応しました。
Unicodeマッピングされたフォントを取り扱うために、BeOSではUTF-8という形式を採用しています。これは先頭の1バイトで以降のコードが1バイト文字なのか、2バイト文字なのかを指定してやるという方式です。
ここでユニコードの是非についてとやかくは言いませんが、Be社がBeOSにユニコードを採用した事は紛れもない事実であり、今後BeOSと付き合っていくためには、避けて通れないものなので、どんなものかは知っておく必要があるでしょう。というより、コンピュータによる多国語処理という問題を考える上で、格好の素材であるとも言えます。
(※)ユニコードについては、多国語情報処理の決め手とは成り得ないため、賛否両論あります(以前BeTalk-Jでもかなりの議論になりました)。何が問題なのかについては、太田 昌孝 氏の「いま日本語が危ない 文字コードの誤った国際化」(丸山学芸図書;ISBN4-89542-146-5)に詳しいので、是非ご一読をお奨めします。
月刊ASCII(1998/12月号)の特集記事を読むと、どうやらUnicodeのコードマッピングを台無しにしているのは、日本以外のアジア圏の各国(台湾、中華人民共和国、韓国などなど)の様ですね。
どうやら「康煕字典(説明省略)に収録されている漢字に、丸ごとコードポイントを振ってしまえ」などと「ごむたいな」主張をなさっているそうな。あと合字(偏や旁など、漢字の構成要素それぞれにコードポイントを与え、実際の表示/印刷は、それらを合成すればよいだろうという発想)についても根強く主張しているようです。
非アジア圏の人々の大半(Unicode委員会の委員長やISOの委員長なんかはそうらしいです)は、非ローマン文字文化の特異性についてそれほど理解が進んでいないので、アジア圏の人々(しかも検討委員会のメンバー)がこういう無茶な事を主張すると、「それでOKなら入れちゃいましょう」となってしまうので、日本のメンバーがそうした無茶な主張を崩す事にかなり努力している様です。
UCS Transformation FormatもしくはUnicode Transformation Formatの略。16ビット固定長というユニコードを実装する場合の表現形式の事です。BeOSではUTF-8という方式を採用していますが、他にUTF-7や、ISO-10646絡みでUTF-16なんてのもある様です。
なお、UTF-8に関しては、Be Newsletterの"BE ENGINEERING INSIGHTS"に以下の2つの記事がありますので、参考になさって下さい。
vinyl
これは言うまでもなくビニールの事なんですが、Be Newsletter, Issue #104に掲載されたBe社のDave Johnson氏の記事"Some Thoughts for the New Year"おいては、CDとの対比でアナログレコードの意味で使われています。
Virtual Machineの略。古くはSmalltalkなんかでもお馴染みの言葉なのですが、BeOSにおいては、標準でサポートしている言語の一つであるJavaで書かれたプログラムの実行に利用される仮想マシンの事を言います。仮想マシンとは、ソフトウェアで実装された仮想的なコンピュータの事で、Java VMに関して言えば、Javaコンパイラを使ってコンパイルされたbyte codeは、このVM上で実行されます。
このJava VM、現在はCodeWarriorを提供しているMetrowerksの提供するものを実装します。標準サポートといいながら、今まではCodeWarriorのフル・パッケージを購入しないとJavaの実行環境が導入出来なかったのですが、BeOS Release3からは、BeOS標準(&現時点で唯一)のウェブブラウザであるNet Positive(N+)がJava対応になるため、漸くシステム標準でVMが提供される事になるようです。
Javaのスローガンである"write once, run anywhere"は、このVMが各種プラットフォームに移植されてはじめて可能になるのですが、現在の移植方法だと、プラットフォーム毎に実行可能なJavaのバージョンがバラバラになってしまっており、これが大問題になっています。例えばRelease3のN+は、おそらくver. 1.1.4ベースのVMになると予想されますが、巷には未だver. 1.0.xベースのVMしか動かないブラウザのインストールされたコンピュータが山ほど存在しているし、本家のjavasoftからはもうすぐJDK1.2の正式版が出そうだし、という訳で、一種イタチごっこの様相を呈しており、実情はとてもスローガン通りには行っていません。
これを解決するために、javasoft社は、プラグイン形式でNetscape Communicator(NC)とMicrosoft Internet Explorer(IE)にJava VM機能を提供するJava Activatorを提唱し、既にIE向けにβ版を配布しています。当面望み薄ではありますが、N+向けのJava Activatorも出してくれると嬉しいですね。
WYSIWYG
"What You See Is What You Get"の略。「見たまんまが得られまっせ」という意味で、ビットマップディスプレイ+GUIの組み合わせで、画面上で表示されたそのままのイメージを印刷出力したりする事が可能になった事から出てきた言葉。
その昔、Macintosh Plus+ImageWriterの組み合わせでは、ImageWriterがまんま72dpiで出力してくれたために、本っ当に「見たまんま」の出力が得られ、とても美し...くなくて大変?だったようです^^;)。これに対して、ImageWriterLQという、初代ImageWriterの倍となる144dpiの出力解像度を誇る後継機も出たのですが、こいつの余りのうるささに「LQは"Lousy Quality"の略だ」などと皮肉られたりもしました。
***
Nerd
NIH
> しかし、それではくやしいので、こんな風に、
>
> > What does "NIH" mean ?
> > Another TLA that I don't know, yet.
>
> そして今度は別の方が
>
> > Not Invented Here. A term describing the unwillingness of a (software)
> > company to include other's work in their products.
> > Counter-productive. HW companies do it all the time.
>
> > > Another TLA that I don't know, yet.
>
> > Which stands for...? ;)
>
> と、質問は続く続く、、、、
O [4語収録]
OpenGL
ORA
今回の改訂前まで、「MacOSはQD3Dを捨ててしまった」と断言してたんですが、これは私の完璧な誤解でした。でもこれを書いた頃に、確かそんな話が出てたんだよー...m(_ _)m。
OTOH
P [5語収録]
PE-COFF
PEF
PPC
PR
Q [1語収録]
R [10語収録]
R4.1
Release3
RFC
RGB
B_MONOCHROME_1_BIT
B_GRAYSCALE_8_BIT
B_COLOR_8_BIT
B_RGB_16_BIT
B_RGB_32_BIT
(B_BIG_RGB_16_BIT)
(B_BIG_RGB_32_BIT)
RSN
Brian Morris氏がB_MOUSE_UPメッセージのインターセプトをBMessageFilterでシンプルに行う事に成功したとき、急いでソースにコメントを入れて公開するよという意で、タイトルも
> I'll document it RSN once I have a chance to reboot out of BIOS
> (had to check mail with eudora)...
> Should send it out sometime tonight.
RTTI
S [3語収録]
SMP
STL
T [2語収録]
U [2語収録]
UTF
V [2語収録]
VM
W[1語収録]
X [1語収録]