2014年7月16日水曜日

リモートデスクトップでコンソールセッションに接続


Windows2003Serverへリモートデスクトップでアクセスし起動中のアプリを停止させようとしたら動いているはずのアプリがいない!
タスクマネージャのプロセスではちゃんと動いているのに~なんて事無いですか?


これはリモートデスクトップで接続した時に違うセッションに接続しているためだそうです。
その場合、コマンドプロンプトから以下のコマンドで接続するとコンソール・セッションに接続できます。

c:\>mstsc.exe /console /V:xxx.xxx.xxx.xxx


/Vは接続先のIPアドレスを入れます。
IPアドレスをしてしないとリモートデスクトップ接続画面で接続先を指定する事になります。

接続するときは毎回コンソールセッションに繋ぎたい場合などは上記の一行をメモ帳などに書き込んでmstsc-aaa.batなんてバッチファイルにしておけば便利ですね。



Windows7にてhostsファイルを編集するには


hostsファイルってご存じですか?

ネットワークのIPアドレスとホスト名(マシン名)を紐付けてくれるファイルです。
最近は使うことがあまりないと思うのですが古いシステムなどでは使用していたりするんです。

昔のシステムってアプリケーションとかに直接IPアドレスとか持っていたりするのでこれをホスト名にしておけばhostsファイルの修正だけで済むわけです。

が、今となってはこのファイルを簡単に変更できてしまうと悪意のあるサイトに簡単に誘導できてしまうためセキュリティが強化され編集出来ないんですよね。

ちょっと古いシステムを動かしたいのでhostsファイルを編集したいんですが…

秀丸エディタで開くとアクセス制限がかかっていて開くことは出来ても保存が出来ません。
プロパティとか見ても権限変更出来ないし…
まだ、Windows7を使い始めて半月なので正直どうすりゃいいんじゃ?って感じ



ネットでいろいろ調べて見ると管理者権限で実行すればよいなんて見つかる。
ふむふむ、秀丸エディタのアイコンを右クリックして「管理者として実行」すると編集することが出来ました!こんなメニューがあるなんて知らなかったよ。
※メモ帳でも同じように管理者で実行すれば問題なく編集できるはずです。


注意!
hostsファイルをドラッグ&ドロップで秀丸、メモ帳に渡しても表示すらしないです。
エディタのメニューでファイルを開くから開かないと編集出来ません。
(一体どんな理由なんだろうか?)


今回はhostsファイルを例にしましたが「ファイルが編集できない~!」なんて時はメモ帳やエディタを「管理者として実行」してみましょう!


2014年3月22日土曜日

Windows2008ServerでVC++6.0で作成したプログラムを動かす


Windows2003ServerからWindows2008R2へのサーバリプレース作業がありました。
DBもSQLServer2000からSQLServer2008へアップグレード。

このWindows2003サーバ本来持っている機能は作成しなおしここまでは問題なく作業終了。

ところが現地で問題が発覚
本来、別サーバで動いているべきアプリがいつの間にかリプレース対象のサーバで動いていたことが発覚!
当然、仕様落ちだし作業範囲外。とは、言ってもその動いていたアプリをWindows2008で動かさねば。


このアプリVC6.0++ で作成されていてすんなり動くことはなく多々、問題がありそう。

機能
コンソールアプリで通信を行い受信したデータを別サーバのDBへ書き込む。
書き込む先はWindows2000サーバでDB接続はODBC。
実行ファイルの他にdllが2つある。


問題となりそうなところ

1.64bitOSで32bitで作成されたアプリが動くのか?
  
2.DLLが動作するのか?

3.ODBC接続でうまく接続できるのか?


早々に対応しないといけないのでVMにWindows2008R2の試用版を入れて動作確認。

まず、アプリをそのままコピーして起動してみる。
起動した時点で、DLLが見つかりませんとメッセージが表示される。
そのためDLLを”Windows\System32”へコピーしてみるが状況は変わらず。
次に別に作成した”c:\work”へコピーし環境変数のPATHにこのフォルダを追加して実行すると起動は出来る。

PATHを追加しなくても動作出来ないのか調べたところ、WOW64で32Bit 版のアプリを検出すると、CPUを32bitプログラムが動く「Compatibility Mode」に変更するそうで、その際参照するシステムフォルダは”Windows\SysWOW64”になるとのこと。
それならと、DLLをコピーしてみる。(当然System32、PATHは元に戻して)
実行すると何とか起動が出来るようになった。

さすがにマイクロソフトも考えてくれて傷んだね。

これで1,2の問題は解決出来そう。

次が3.のODBC接続。
現地と同じようにODBC接続を設定する。
ODBC設定の動作確認で接続完了まで行っているので設定自体は問題無いと思うが残念ながらアプリはエラーメッセージを吐き出し接続できない。
こちらも調べてみると32Bit版のODBC接続を設定すれば良いそうです。
32bit版のODBC設定画面は”Windows\SysWOW64\odbcad32.exe”を起動して同じ設定にすれば良いらしい。
設定後再起動すると確かにDBへ接続できている様子。
通信用のデータを流してDBへ書き込むところまでひと通り確認できた。
※但しこの時点で接続しているDBはWindowsXP+SQLServer2005で現地とは異なる


ODBCドライバの説明で下位のSQLServerへの互換性は保証しているなんて記載を見つける。
裏切られることの多いマイクロソフトを信じて現地のサーバへセットアップに。

嬉しいことに一発でうまく行きました。


まとめ、Windows7、Windows2008R2など64bitOSで32bit版を動作させるにはSysWOW64を使用すればうまく行きます。