ホイール欲しい ハンドル欲しい

Vista 使っていて Program Files にあるはずのファイルが見つからなくて焦る
ことがあります。アプリケーションのファイルダイアログからはちゃんと
Program Files の下にファイルあるように見えるのに、直接 explorer で開くと
そこには何もありません。

そんなときは C: の「ユーザー」フォルダ以下
「 ＜ユーザー名＞\AppData\Local\VirtualStore\Program Files 」
を探すとみつかります。AppData は隠し属性のフォルダです。

アプリケーションによっては、直接インストールされたフォルダにデータを書き込む
ものがあります。これだとユーザー間で共有されてしまうし、Program Files の書き
換えを禁止して保護したいのにできないしと、UAC のもとではいろいろと不都合が
あるのでしょう。

なので Program Files 以下への書き込みは、ユーザー毎のプロファイルフォルダに
格納されるようです。

http://ch09144.kitaguni.tv/e310975.html の続き
GPU でもプログラミング言語が走るようになって怒涛の勢いで進化しています。
ですが、PC でいう x86 や組み込み機器でいう ARM やゲームコンソールでいう
PowerPC のようにバイナリレベルで何らかの共通化が行われているわけではありません。
(もちろん ARM や PowerPC は結果そうなっただけなのですが)

nVIDIA の GPU や ATI(AMD) の GPU では、ほぼ同じシェーダーの機能を使うことが
できるものの、内部のバイトコードは全く別物だと考えられます。

HLSL で書かれたシェーダープログラムは、vsa, psa, fxc や D3DX によって
Direct3D の仕様として決められた仮想 GPU のバイトコードに変換されます。

このバイトコードは D3D のアセンブラ命令とそのまま対応しており、D3D の仕様
そのものでもありました。

ビデオカードのドライバは、D3D のバイトコードを受け取ってから実行前にそれぞれ
のネイティブのバイトコードへ変換が行われます。

もしかしたらほとんど D3D の仕様とそのまま同一なのかもしれませんし、メーカー
ごとにもっと大胆な最適化が行われていて非常に異なったコードに変換されている
のかもしれません。

ですが HLSL のコンパイラは D3D の命令への変換だけ考えればよく、最適化もこの
共通コードに対して行われます。


この仕様のおかげでドライバは独自の最適化を行うことができて、かつ命令セット
アーキテクチャ ISA にとらわれずに機能の向上が図れるのだと考えられます。


そう考えると .NET Framework に搭載されている CLR はいわば、CPU のための
デバイスドライバなのかもしれません。

CLI という統一された仕様の MSIL のバイトコード上ですべての処理を考えておけ
ばよく、実際にプログラムが走るときはデバイスドライバが勝手にネイティブのコード
に最適化を行います。CPU 毎の差を吸収できるので、GPU のように ISA レベルの
互換性にとらわれずに性能の強化を図れる・・のかもしれません。

http://ch09144.kitaguni.tv/e310974.html の続き
CPU 依存の無い共通のバイトコードといえば昔 WindowsCE にもありました。
WindowsCE は小規模な組み込み向けに使われる OS でプラットフォームを選びません。
HandheldPC や PocketPC など、PDA でも当初は SH3, SH4, MIPS などさまざまな
CPU が使われていました。プログラムを作る側も使う側も、同じ OS だけど CPU の
違いを意識しなければならずたいへんです。

そのため一時期 CEF と呼ばれる共通のバイナリ形式が登場しました。やはり仮想の
バイトコードの形にコンパイルされて、実行前にネイティブなコードに変換されます。
一度変換すると以後はネイティブコードのアプリケーションとして振舞います。

しかしながらあんまり使われることは無く、その後のバージョンで PocketPC は
ARM アーキテクチャに統一されてしまったので、CEF の意味もなくなってしまい
ました。ZERO3 も HTC の WindowsMobile 機も全部 ARM です。


WindowsCE 向けにも .NET Compact Framework が登場しています。やはり PC 版と
同じように共通のバイトコード MSIL を使うので、今だったら CPU の種類が多くて
もそんなに困らなかったのかも、、しれません。
(続く)

http://ch09144.kitaguni.tv/e310960.html の続き
CLI の仕様に沿っていれば、.NET Framework 用アプリケーション開発は特に言語を
選びません。C# だろうが VB だろうが。この辺が Java とは少々趣が違うところで
しょうか。

そしてもちろん C++ での開発もできます。C++ といえど CLI に従うので MSIL に
コンパイルされます。C++ なのにネイティブコードにならないのは何となく不思議
な感じがします。

CLI にさえ従っていれば他の言語でもかまわないし、さらにアセンブラを使って直接
MSIL のコードを書くこともできます。


C++/CLI で非常にユニークなのはネイティブコードとの共存ができることです。

言語仕様も拡張されており、C++ のルールにのっとりつつも C# のような言語拡張が
使えて管理された安全なコードを書くことができます。これはマネージドコードと
呼ばれるものです。MSIL です。

同時に従来の C系統のコードがそのままコンパイルできて、従来のライブラリも
リンクできます。こちらはネイティブな x86 等のバイトコードになります。

この両者が1つのバイナリに共存していることになります。

ネイティブコードの部分は .NET Framework 管理下に無いのでアンマネージドコード
と呼ばれます。


ちなみに C# でも、DLL など Win32 API 呼び出しができたりポインタを使った
メモリアクセスができるので、C++/CLI と同じように意図してアンマネージドな
プログラムを呼び出したり書いたりできるようになっています。ネイティブコード
に変換されるわけではないのですが。
(続く)

C# は C言語系の新しい言語の一種です。C# を使ってアプリを作るのは簡単だし
便利だよとよく話を聞くのですが、この場合 .NET Framework まで含まれるので
少々混乱します。


まず .NET Framework というのは Windows の新しい API セット＆ライブラリの
ことです。ツールキットであってクラスライブラリです。OS のさまざまなサービス
を提供しつつ、ユーザーインターフェースやらなにやら便利な機能をたくさん
取り揃えています。

.NET Framework を利用できるのは、MSIL と呼ばれる仮想コンピュータ用の
プログラムだけです。直接ネイティブな x86 等のバイトコードではありません。
これは .NET Framework に含まれる CLR と呼ばれるランタイムが、プログラムの
実行直前にネイティブなコードに変換します。

つまり、JIT コンパイラによって MSIL から x86 へのコンパイルが行われてから
プログラムが走るので、実行時はネイティブコードとしてのパフォーマンスが期待
できます。

このように面倒なのですが

・プログラムは仮想マシンのバイトコードなので完全に管理下に置くことができる。
　不正なコードやバグを除外できる。セキュリティ強化。

・仮想コードなのでプラットフォーム依存を無くすことができる。

等のメリットが考えられます。


仮想マシンや JIT コンパイラなど、動作の流れも特徴もほとんど Java と同じです。

ただし Java は完全に言語仕様と動作環境やクラスライブラリが一体化しているの
に対して、.NET Framework はオープンです。仮想マシンのバイトコード MSIL レベル
で仕様が統一されているので、そこから上のプログラミング言語は特に限定されて
いません。この仕様が CLI になります。


プログラミング言語としての「Java 言語」に相当するのが C# です。C/C++ 言語
における、バグの原因となりやすい部分を言語仕様として改良＆拡張しています。

そのため C# による開発を語る場合は、言語としての便利さと、.NET Framework
における管理された安全性やライブラリの使いやすさとしての便利さと、開発環境
として整っているツールの便利さが含まれているようです。


今後 Vista にあわせて .NET Framework 3.0 としてさらに幅広いサービスが提供
されるらしく、ワークフローにまで及んでくるそうです。今後はネイティブコードが
消滅して Windows 自体、アプリケーションも全部 MSIL で動くようになるので
しょうか。
(続く)