VisualStudio一覧

VisualStudio 2015 と VMwareWorkstation

Windows10 環境にしたこともあり、VisualStudio 2015 も普段使いの環境に追加していました。このときに、 VMware Workstation 12 で仮想マシンを構築・起動をしようとした際に、「64ビットのゲストOSはこのホストではサポートされていません」というエラーメッセージが出てしまいました。

このエラーは、仮想化支援の機能が BIOS で OFF にされていたり、 そもそも CPU が対応していなかったりすることでみるものなのですが、今回はそれら以外でこのエラーを見たのでここにメモしています。

Android 開発もできるようになったとのことで、 VisualStudio 2015 のインストール時に、 Visual Studio Emulator for Android という開発用のエミュレータをインストールしてしまったことにありました。

このエミュレータはクライアント Hyper-V の機能をベースとして使っているようで、これが原因となっていました。

仮想化支援の機能は基本的にはすでに使用されていると次のアプリでは使用できないため、このような症状になったというわけです。(近年は、Nested な仮想化支援環境も構築できるよう進んでいますが、Hyper-V はこのあたり非対応のままのようです)

早速、コントロールパネルから Windows の機能の部分で Hyper-V に関するところを確認してみたら、インストール済みとなっていましたので、チェックを外して無効化しました。この後再起動を要求されます。

再起動後は、 VMwareWorkstation では当初出ていたメッセージが消えました。一方で、案の定ですが VisualStudio の Android エミュレータは使用不可能となっていました。両立できないのは残念ですが、仕方のないことではありますね・・・。


INTEL の INDE 続報

あれからエラーの対処とかやってみた結果、少し進捗があったのでメモしておきます。
VisualStudio でのビルド時に以下のエラーがでてその先に進めないのが問題でした。

この内容はある意味定番で、JAVA_HOME が設定されていないとか、java.exe が見つからないとかそういう話に帰着します。
今回難航していたのは、android.bat を実行したら Android SDK Manager が起動するし、 javac とタイプしたら実行されるし、とパス情報は正しく設定されているようだったのに、上記のエラーが出てしまう、という点にありました。 続きを読む


インテル INDE インストールから難関

先日のキャンペーンによりインテルの INDE Professional を入手したので、早速試しました(うまくいきませんでしたが)。

どんな風だったかというと、インストールからうまくいかないという感じで導入も大変でした。またエラーによりビルドも正常に出来なかったりと、自分の環境では VisualStudio 2015 RC のほうが使える感じですね。その色々とあった点について書いておきます。 続きを読む


VisualStudio 2015 RC での Androidデバッグ機能

VisualStudio 2015 で Android および iOS のビルドがサポートされる話も有名です。 RC版でも Android に関してはある程度試せる状況にあるようなので、現時点ではどのくらいのことが出来るか試してみようと思います。RC版でのお話なので、正式リリース版では変更になっている可能性が十分にあります。

プロジェクトテンプレート

VS2015RC では既にプロジェクトテンプレートとして以下のように準備がされています。ここでは OpenGLES Application を用いてテストしています。 見ての通り iOS 用もありますが、手元では iOSのビルドをすると、「error : 無効な URI: ホスト名を解析できませんでした。」とエラーになってしまいその先に進めませんでした。また iOS Debugger, Simulator なるものが存在を期待されているようですが謎です。

vs2015rc-cross-platform-template

ちなみに Android 版のサンプルを実行してみた図が以下の通りです。
VS2015RC-ANDROID
見ての通り実機によるデバッグが可能で、その際の各種情報も VisualStudio で表示できています。これらについて詳しく確認していきます。 続きを読む


CRT非依存の続き

前回結構かいたつもりですが、それの補足や追加調査でわかったことを書いておきます。

C++は本当につかえない?

できることならC++のクラスとか使って開発したいですが、new/delete 使えなかった記憶があったので調べてみました。
 結果、通常のnew, delete を使用した際にはCRT依存が発生してしまいます。しかし!グローバルのnewをオーバーロードする方式で new/delete の処理を横取りすれば、この依存が発生しないことがわかりました。個人的にはすばらしい発見でした。(そもそも例外は使わない前提。前回の記事でOFFに設定していますし)

エントリポイントの設定について

前回エントリポイントの設定をするように書きましたが、実は他の方法があるようです。
規定のライブラリ省略をするように設定すると下記の関数がエントリポイントとできるようです。

どのみち規定のライブラリ名の省略オプションは有効にしておいた方がいいみたいですし、こっちのほうがよいのかもしれません。


CRT (C Runtime) に非依存とするために・・・

VisualStudio (Visual C++) を使って開発をしている際にちょっと厄介になってくるのが、CRTの選択についてどれにするかを決める点です。これは実行体(アプリケーション)を作っているときにはまだ軽微な話なのですが、ライブラリを作る際にはとても大変な話になってます。

というのも、デバッグ/リリース、そして、CRTのDLLリンク/スタティックリンクの組み合わせ、最近だとそれに 32bit/64bit という組み合わせを考えなくてはなりません。つまり 2x2x2 の8種類存在することになります。ライブラリの提供者になる場合、特にそのライブラリをパッケージとして納品するなどする場合には、これらの組み合わせのライブラリを1セットとする必要があると思います。

しかし!そんな8種類も納品したくない&動作テストしたくもないのが本音です。
ただ利用者にとっては自分のアプリケーションで使うために、一致するライブラリを選択できているのが望ましいです。数が多いと選択に困るかもしれませんが、ライブラリのせいで構成を縛られてしまう、という点だけは避けたいところです。またオープンソース等であればプロジェクト設定を変更して、利用状況に応じてオプションを変えることで対処することも可能です。・・・でも個人的にはこれもやりたくはない作業だと感じています。

ライブラリの個数を減らすことを考えてみる

8種類もあるのが大変なので減らすことを考えてみます。どうしても減らせないのは 32bit/64bit のケースでしょう。そもそもABIが違うのでこれはどうしようもありません。
ランタイムDLLを要求するケースはclr使う際には必要です。つまりC++/CLIを使って C#から使うようなケースでは必須となります。楽にGUIを作れるのでこれは考慮しておく必要があります。ただCランタイムのDLLについて配布先でインストールが必要になります。おなじみの再頒布ランタイムってやつですね。
スタティックリンクを使用する場合、exe単体配布で動くようにできるというのが最大のメリットでしょう。

つまりDLL/スタティックリンクどちらもメリット・デメリットがあります。つまり捨てられない・・・。

これらのランタイムは何を示しているかを考えてみます。
そう、CRT なので、Cランタイムのタイプがどれであるか、を決めているわけです。ということは、Cランタイムを使わない、CRT非依存を実現できればこれらの問題から解放される、と予想できます。
つまり、CRT非依存を実現できれば DLL/スタティックリンク の組み合わせはどちらでもよい(=最終exeをつくるプロジェクトに任せられる)ということになります。

次に Debug/Release の違いも検討してみます。DLL版においては Debug,Release で別々のランタイムDLLに依存することがわかります(Dependency Walker とか使えば簡単です)。でもやっぱり CRTに関係する実装が Debug/Release と切り替わるだけなので、CRTに非依存が実現できればこのDebug/Releaseの差異も気にしなくてよくなりそうです。

ここまでの予想をまとめると、「CRTに非依存にできれば x86用ライブラリと x64用ライブラリの2つを提供するだけでよくなる!」 となります。非常に魅力的です。
・・・現実問題としてデバッグ用ビルドは用意して提供する気がしますが。組み合わせとして4つ程度で済むというのはとても助かることじゃないでしょうか。

具体的にどう開発をするのか

CRT非依存の開発をするにあたってどうすればいいのか、ホントに実現できるのかという点で自分が調べた範囲でのメモをここに残しておこうと思います。

そもそもCRT非依存にして開発できるのか?という問題ですが、結構手間がかかりますが実現不可能ではありません。このときに使ってよいのは Windows API のみとなります。Cの標準関数は使用不可です。当然ですね。標準関数に含まれる機能が欲しいときには、自作 or Windows API で代替を探す、という感じになります。

たとえば、ファイル操作では fopen, fread, fwrite は使えません。代わりに CreateFile, ReadFile, WriteFile を使用します。printf も使えないので、自力で WriteFile にてコンソール用出力先にデータを書き込む方法で対処とかになります。これは結構大変です・・・。

もうちょっと具体的な話

基本的に C言語の範疇でコードを記述します。
またVisualC++のコンパイラが色々とデバッグ時に役立つ機能を埋め込んでくれるのですが、これらについてオフにします。だいたい以下のような設定をプロジェクトに行います。

  • デバッグ情報: プログラムデータベース(/Zi)
  • SDLチェック: いいえ (/sdl-)
  • 最小リビルドを有効にする: いいえ(/Gm-)
  • C++の例外を有効にする: いいえ
  • 基本ランタイムチェック: 規定
  • セキュリティチェック: いいえ(/GS-)
  • ランタイム型情報を有効にする: いいえ(/GR-)
  • インクリメンタルリンクを有効にする: いいえ
  • エントリポイント: (自分の決めたエントリポイント関数)

また ZeroMemory マクロも実際のところはmemset に展開されるので使用禁止ですし、配列や構造体を={0}のように記述して初期化する際にも memset が使用されてしまうようなのでこれも禁止です。

このようにしてアプリケーションを作っていく際には、慣れないうちには特にですが、ビルドしてできたexeをDependencyWalker で調査しつつ作業を進めるのがよいかと思います。そうしないとどこでCRT依存を混入してしまったのか見つけるのが大変です。


C++で UTF-8文字リテラルを使いたい

VisualStudio 2010 環境限定ではあるけれど、ソースコードがBOM付UTF-8であれ、ShiftJISであれ、文字リテラルを UTF-8 で処理させて、実行体Exeの中に格納できる方法を発見しました。

このようなコードを作成してWindows日本語版の環境下でビルドした場合、その実行体の中に含まれる文字列は、Shift JIS (MS932) となってしまいます。 これはビルド設定の「文字セット」の設定とは無関係で、元のソースコードがどの文字エンコーディングを使っているかにも関係なく、ShiftJISとなってしまうようです。
この状態がちょっと都合が悪いことがあって、出来上がった実行体の中に UTF-8 で文字列で格納しておいてほしいというのが実現したいことです。

すなわち、上記の文字列 「あああ」をエディタで(ShiftJISやUTF-8など)で通常通りに入力し、それをUTF-8化したままで exe の中に格納しておく、ということがやりたいわけです。

続きを読む


VisualStudio 2013をインストールしてみた

MSDNのほうではVisualStudio 2013がRTMになってダウンロード可能となったのでインストールしてみました。
今回はその記録です。

まず素のWindows7にインストールしようとしたら、セットアップできませんでした。
InternetExplorer10 を要求するようです。
DirectX SDKを使って開発している場合にはこれが少々問題になって、IE10インストール後はPiX for Windowsが使用できなくなるようです(詳しくはこちら)。
IE10のインストール後は、VisualStudio2012の付属のツールを使って調査して下さい、ということのようです。
・・・でもこれだとDirectX9が非対応のようで残念なのですが。時代的にもうDirectX9は積極的なサポートのほうは終了という意思の表れのように感じます。

ランタイムで気になった物のバージョンを調べてみました。

  • .NET Framework 4.5.1
  • VCランタイム 12.00.21005.1
  • Windows Kitsフォルダ内には 8.0 と 8.1 の両方のファイルが存在
    • d3dcompilerもそれぞれにあった。d3dcompiler_46/47.dll, d3dcsx_46/47.dll となっていて、これらは再配布可能フォルダにあった。

Windows8 RTMでは .NET Framework 4.5 だったのでわずかに上がってます。Windows7 SP1のころでは、.NET Frameworkは 3.5.1だったので、4がスキップされてますね。

続きを読む


現在のWindowsサイドバイサイドについて-続き-

前回は、VCランタイムをスタティックリンクして生成させるという話で終了しましたが、今回はその続きに当たるダイナミックリンク版のVCランタイムを使用しつつ前回の条件を満たす、ということを考えてみたいと思います。

前回はこちらに。 現在のWindowsサイドバイサイドについて

ここでは2005,2008と2010,2012での谷間によって、大きく違います。
2010以降で生成されたアプリケーションでは、VCランタイムに関する埋め込みマニフェストがないため、そのまま必要なDLLをexeと同じ場所にコピーしておくことで対処できます。
一方で、2005,2008はカレントに決められた名前でフォルダを作成してその中にDLLを配置する手法をとります。
これはプライベートアセンブリというものに該当します。

図示するとこんな感じです

-- Application.exe
      + Microsoft.VC90.CRT
          + msvc***.dll
          + Microsoft.VC90.CRT.manifest

Microsoft.VC90.CRT というフォルダはVCインストールフォルダでredistというフォルダの中で見つけることが出来ます。

このように配置してアプリケーションを動かしたいということは、その環境ではランタイムが入っていないわけですので、
Application.exe が要求するバージョンの Microsoft.VC90.CRT を配置しなくてはなりません。
ここがくせ者でして、VisualStudio2005,2008にはそれぞれで違った挙動を示してくれます(涙

  • 2005の場合
    • ビルド環境の最新状態のVCランタイムバージョンにバインドされる
  • 2008の場合
    • ビルド環境の最新状態のVCランタイムバージョンではなく、2008RTM版のランタイムバージョンにバインドされる

つまり、2005のこの挙動であれば、ビルド環境のredistフォルダからコピーして配置で問題なく動くようになるわけです。
一方、2008のこの挙動ではビルド環境のVCインストールフォルダのredistも最新状態のランタイムに更新されているため、redistフォルダからのコピーではバージョン違いにより動作させることが出来ない状態となります。

これらの挙動を修正するのに、exeが要求するランタイムバージョンを変更するという方法が1つあげられます。それが外部マニフェストです。
exeと同じ場所に、exe名(拡張子含む).manifestというファイルを作成することで、処理されるマニフェストを上書きする形で制御できます。ここにredist内で見つかったバージョンを要求するように書き換えてしまえばうまく動くという考えです。

この方法はXPまでであれば考え通りに動きますが、2003以降マニフェストの処理優先順が変わりました。そのため現在主流となっているWindows7周辺のバージョンでは埋め込みマニフェストが優先されてしまうため、動かない状態となります。

この状態でとれる案として以下のものが考えられます。

  1. 2008の場合において、ビルド時に
    _BIND_TO_VCLIBS_CURRENT_VERSION=1 (プリプロセッサ定義で指定する)
  2. 生成されたexeの埋め込みマニフェストを編集する

(1)の場合、ビルド時のVCランタイムバージョンにバインドされるようになります。
依存するライブラリ全てにおいてこのプリプロセッサ定義を行いexeを生成できれば、ビルド環境のredistからランタイムをコピーだけで動くようになります。
(2)の場合、mt.exe というツールを用いて、manifest取り出し → 編集 → 再度埋め込み という手順を行います。

具体的には、下記のような感じになります。

取り出し
mt.exe -inputresource:Application.exe;#1 -out:result.manifest

取り出したマニフェストファイルを開き、要求しているバージョンを変更します。

埋め込み
mt.exe -manifest result.manifest -outputresource:Application.exe;#1

以上で、exe単体で動かす場合の話は終了です。
しかし、オープンソースのライブラリや自作の他ライブラリを用いており、それがDLL版だったりすると話はまだ続きます。
これについてはまた次回に。


WindowsとVisualStudioの動作環境

Windows8 と VisualStudio 2005 の組み合わせキーワードで当ページに来る人もそれなりにいて、
ちょっと気になったので調べてみました。

参考 http://www.microsoft.com/ja-jp/dev/support/tools.aspx

この情報をまとめると、

開発PCが Windows7 なら VisualStudio 2005から2012まで使えるけれど、
開発PCが Windows8 なら VisualStudio 2010以降でなければならない。

ということでしょう。長らくVisualStudio 2008を使っていましたが、そろそろ 2012 に切り替えた方が良さそうに感じました。

VisualStudio 2012はWindows7以降だし、幅広くこれ1本と決めるなら 2010 を使えってことなのかもしれません。
しかし、2010以降は使用するツールチェインを切り替えられたはずなのですが、これを使って Windows8上でVS2008のツールチェインを使用するということもサポートされないのか?とちょっと疑問に思いました。