簡易ISOファイル作成コマンド

■2021年8月2日 追記


これの続きです。

自分用のツールの置き場、備忘録として記録しています😅

CDやDVDのメディアからISOファイルを作成するのは結構カンタンにできました。
これで殆どやりたいことはできたのですが、やっぱりディレクトリからISOファイルを作るにはどうするんだろう??? という素朴な考えがでてきまして・・・

————– 追記
これが 非Windows OSならば、mkisofs コマンド(genisoimage)をdnfなりaptなりのパッケージマネージャで入れれば解決するんだけど・・・いかんせん、Windowsはそういう便利なコマンドはありません。oscdimg という Windowsのインストールメディアを作成するツールを使えばできるそうです。実用性を重視する人は oscdimg を使うといいと思います😀
追記ここまで —–

ググるとこれもWindowsで標準機能でできるようで・・・具体的にはイメージマスタリングAPIとしてCD/DVD等のファイルシステム作成からメディアへの書き込みまでの機能がCOMサーバーとして提供されているようです。COMサーバーで実装ってことは、WSHやC#から簡単に使える・・・ってことです。

サンプルのコードはもうマイクロソフトのコミュニティーサイトに載ってましたので、これを適当にいじって、任意のディレクトリをISOファイルにビルドできるコードを書いてみました。一つ前に書いたDVDメディアからISOファイルを作るコードも統合してみました。

イメージマスタリングAPIは.NET Frameworkのクラスライブラリで提供されておらず、C#から使用するには、TLBIMPコマンドを使用してタイプライブラリからCLRアセンブリに変換し、コンパイルするときにこのアセンブリを参照しないといけません。Visual Studio のIDE環境を使用する場合はプロジェクトにIMAPI2FS.dllの参照を追加するだけでいいかもしれません。
僕みたいにコンソール画面でカチャカチャする場合は・・・

>> tlbimp c:\WINDOWS\System32\imapi2fs.dll

のようにすると、同名のアセンブリ(dllファイル)ができるので、ソースコードをコンパイルするときに、このDLLファイルを /r オプションで追加します。

殆どサンプルコードをコピペしただけなので、特に特筆するところはありません・・・githubにリポジトリ作ろうと思ったけど、ファイル1個だけなんでgistにした。

一応、タイプライブラリのインポートもあるので nmake用の makefileも書く。

DVDメディアのダンプ

Windows7の環境が必要になり開発用のプロダクトキー?を発行してもらい、後はHyperV環境で仮想マシンを作ってインストールするだけ。
って思ってたら、罠が・・・HyperVで稼働しているマシンにDVDを読めるドライブがねぇよ。。。
DVDメディアからISOファイルを作れば・・・と思い、Windows10のアクセサリの中にISOファイルを作るアプリを一応探してみたけど当然なく・・・、WindowsってISOファイルからメディアに焼く機能はエクスプローラから呼び出せるのに、その反対ができない・・・。

むむむ、linuxとかだと、ddコマンドで一発なのに・・・WSLからddでDVDドライブのデバイスを指定して・・・ってできないのかなぁ・・・。

仕方ないので窓の杜でフリーソフトを漁るか・・・とも思いましたが・・・、単にドライブをオープンしてダンプすればエエだけやろ? ってことで、C#で書いた。C#からWindows APIをコールするところはマイクロソフトのサイトからコピペして、適当に。

要点は、Windows APIの CreateFile から返る SafeFileHandleをFileStreamに渡してバッファを介してコピーするだけ。
FileStream.CopyToAsyncメソッドを使えば一行で済むんだけど、やっぱり途中経過(進捗状況)は必要かなー、と思って無理やり FileStream.ReadAsync/WriteAsyncメソッドを使ったけど・・・。

Vista以降では安易にスレッドを作るな!?

■2021年8月3日
gistにコードを移すとき、コピペした時に文字化けしてたところとか io_completion_port_xp.cpp/io_completion_port_vista.cppを諸々修正


LinuxやBSDなどのUNIX互換のOSと違って、Windowsではスレッドを起こすのは普通に行われてることだと思います。で、スレッドを起こすには、CreateThread API もしくは、Cランタイムライブラリの_beginthreadex関数を使うことになります。

が、一方でスレッドを生成するのではなく、スレッドプールを利用する、というケースもあり、パフォーマンス的な事を考えれば、むしろこちらの方が多いかもしれません。

Windows 2000/XPなどのNT5.x系では、QueueUserWorkItem APIというスレッドプールに関するAPIが使えます。。。けど、はっきりいって、このAPI、よほど簡単なロジックでないと使えません。いったんこのAPIでキューに入れてしまうと、もう手が出ません。外からキャンセルできないし、強制終了させようとしてもTerminateThread APIは使っちゃだめ!ですし・・・。
結局、ちょっと凝ったことさせようと思ったら、自前でI/O完了ポートを駆使してスレッドプールを実装する他なかったと思います。

しかし、Windows Vista以降のNT6.x系のWindowsでは、より進化したスレッドプールAPIが追加されています。もはや、Vista以降のWindowsで、CreateThreadや_beginthreadex関数を使ってスレッドを起こすコーディングはダサイといわざる得ません(^^;;;

というか、CPUがデュアルコアは当たり前、マルチコアがデフォルトってな状況の中で、これからはメニーコアだ! っていう時代なので、アプリケーション開発者側が、コア数のことまで考えて組む・・・とかもう無理!そんなのは限られたスーパープログラマーしかできんわ(笑) ってことです。

だから、CreateThread APIや_beginthreadex関数でスレッドを起こす前提のロジックでコーディングしちゃだめ。ってことに。

ただ・・・スレッドを作ってそこにウィンドウを作成する、というようなケースには向きません。とどのつまり、プロセス開始から終了まで生存するようなスレッドの場合、スレッドプールに処理を投げる意味はありません。あくまで、一つのスレッドの生成・削除が頻繁に行われるケースや、スレッドの生存期間が短いケース等でスレッドプールの恩恵を受けることができると思います。

ま、今更ですが(^^;;; この新たに追加されたスレッドプールなAPI群は、スレッドの生成と管理をすべてWindowsが肩代わりしてマシンに積まれているCPUの数(コア数?)と負荷状態に応じて最適な性能を発揮できるようになっているようです(・・・なっているはずです)。

例えば、ちょっとしたユーティリティアプリなんかで、単純な処理を非同期(並行)処理させる場合、TrySubmitThreadpoolCallbackもしくは、CreateThreadpoolWork/SubmitThreadpoolWorkでほとんど事足りると思います。

CreateThreadや_beginthreadexのあの引数の多さにうんざりすることが無くなり、スレッドハンドルを管理するコード、同期のためにイベントオブジェクトを作成して待機するようなコード諸々を実装する手間が大幅に軽減されます。ヒャッホーーー!

当然ですが、上記はXPでは実行できません。

他にも、タイマーオブジェクトを利用した関数の繰り返し処理、jscriptでいうところのsetTimeout / setIntervalメソッドみたいな、一定時間毎にコールバック関数を実行してくれるCreateThreadpoolTimer APIや、カーネルオブジェクトがシグナル状態になったらコールバック関数を実行してくれる CreateThreadpoolWait API、ReadFile/WriteFileなどのI/O非同期処理に利用できるCreateThreadpoolIo API。

一連のスレッドプールに関するAPIは非常に強力で、使い勝手もいい。デフォルトのスレッドプールの動作が気に入らなければ、カスタマイズしたスレッドプールを利用することもできる。

自分的に便利だと思ったのが、ReadFIle/WriteFileでI/O非同期処理に利用できる、CreateThreadpoolIo/StartThreadpoolIo。
今まではI/O完了ポートで通知を受け取って・・・というようなコードを書いてましたが、Vista以降のOSに限定すれば、これらのスレッドプールAPIを使うことでコード量が減ります。

ReadDirectoryChangesW APIを使ったディレクトリへの変更を監視するコードをスレッドプールを使ったコードに強引にリプレースしてみました。

まずは、昔作った、WindowsXPで動作する、IO完了ポートとワーカースレッドを単純に作って利用したバージョン。

要点は、スレッドを作成して監視が終了するまで待機。ReadDirectoryChangeW APIの非同期処理が完了するとIO完了ポートのキューにI/O完了パケットが追加され、ワーカースレッドのGetQueuedCompletionStatus APIが制御を戻すことでReadDirectoryChangeW APIの処理結果のデータを得て、再びReadDirectoryChangeW APIをコールし非同期処理を継続します。

続いて、上記をVista以降のスレッドプールのAPIを利用したバージョン。

あまり違いがないように思いますが、スレッドを何個作るべき?だとか細々とした調整などが不要になり、何より_beginthread関数などのプリミティブなAPIを使わなくても良くなりました。以前なら、スレッド処理をラップする、なんらかのクラスライブラリが必須だったと思いますが、ちょっとしたツールを書くときはこれらの新しいスレッドプールなAPIを使えば良くなりました。

ま、ちょっとしたツールを作るにはC#を使えば済む話で、わざわざC++を使う必要性があるとは思えませんが・・・。ま、要するに自己満です(^^;;;

_bstr_t は何気に便利だな、とか。

昔書いてたメモ帳から転記。今更感がマックスの、備忘録メモ。

ちょこっとCOMクライアントとかのテストコード書く際に、ワイド文字列(主にWindowsで言うところのUNICODE)と、マルチバイト文字列の相互変換が煩わしいときが多々ある。

まぁ、変換用に関数一個作っとけばいい話なんですが・・・。正直、Win32 APIのMultiByteToWideChar/WideCharToMultibyte は使いたくない。理由はただ一つ。コイツらの使い勝手の悪さときたらどうしようもない。ってとこ。引数が5個も6個もいるし、何より、最低限2回のAPIコールが必要。↓のような感じ。

/*
  マルチバイト文字列 ==> ワイド文字列
*/

#include <windows.h>

//ヒープを使用。
PWSTR AllocString(PCSTR& pStr)
{
  PWSTR pWStr = NULL;
  SIZE_T cchWStr = 0;

  if(pStr == NULL)
    goto cleanup;
  
  cchWStr = MultiByteToWideChar(CP_ACP,MB_PRECOMPOSED,pStr,-1,NULL,0);

  if(cchWStr <= 0)
    goto cleanup;

  if((pWStr = (PWSTR)HeapAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,cchWStr*sizeof(WCHAR))) == NULL)
    goto cleanup;

  if(!MultiByteToWideChar(CP_ACP,MB_PRECOMPOSED,pStr,-1,pWStr,cchWStr))
    FreeString(pWStr);

cleanup:
  return pWStr;
}

//ヒープ解放
BOOL FreeString(PWSTR& pWStr)
{
  BOOL bRet = FALSE;

  if(pWStr && (bRet = HeapFree(GetProcessHeap(),0,reinterpret_cast<PVOID>(pWStr))))
    pWStr = NULL;

  return bRet;
}

でも、こんな感じだと、明らかにテストしたいコードより遙かに長いコード行・・・何か腹立つ。
お金の掛からないVC++ Express Edition を使っていて贅沢は言えませんが・・・なんかで代用できないものか・・・。

で、最近MSDNのドキュメント見てて気付いた。
_bstr_t クラスって便利やないかい!、と。

もともとは、COMでの文字列表現、BSTR型のラップするスマートポインタみたいなクラス。BSTR型はちょっと特殊で簡単に言えば文字列の長さとバッファを合わせたような型。BSTR型をPWSTR型と混同しているケースを極たまに見ます。まぁ、そんなことはどうでもよく。

_bstr_t クラスは、PCWSTR,PCSTRの両方をコンストラクタで受け付けてくれます。しかも、キャスト演算子をオーバーロードしてくれてるので、引数にPCWSTRもしくはPCSTRが必要なAPIや関数にそのまま放り込めます。

※注意点
これらのキャスト演算子は内部バッファへのナマのポインタを返すので、やたらめったら使用すると、おそらくどこかでクラッシュするバグを抱えるでせう。

#pragma comment(lib,"user32.lib")
#pragma comment(lib,"comsuppw.lib")

#include <windows.h>
#include <comutil.h>
#include <tchar.h>

int APIENTRY _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)
{
  _bstr_t bStr("テストでげす");
  
  //ANSI版
  MessageBoxA(NULL,bStr,"ANSI版",MB_OK);

  //UNICODE版
  MessageBoxW(NULL,bStr,L"UNICODE版",MB_OK);
  
  return 0;
}

/*
ANSIバージョンのAPIは、内部でマルチバイト文字<==>ワイド文字の変換を行って
UNICODE版APIをコールしているだけのようなので、このコード自体無意味。
*/

スコープを抜けると自動的にSysFreeStringをコールしてくれるみたいなので、解放処理も必要なし。

万歳!

ネットワークプレースの作り方がわからん

Windows7 では、WebDAVをネットワークドライブとして割り当てることができました。
「ネットワークドライブとWebDAV over SSL」

ですが、WindowsXP(SP3)では失敗してしまいました。
XPでは、ネットワークドライブの割り当てに、WebDAVは使えないようです。

XPではWebフォルダ(ネットワークプレース?)を作成することで解決できるようです・・・が、肝心のネットワークプレースをWindowsAPIを使って作成方法がマイクロソフトからは公開されてないみたいです。

すみません、Windowsのネットワーク関係のことがよく分かってません。ので、まるでトンチンカンなことを書いてるかもしません。備忘録なので、ご注意を。)

ネットワークプレースの仕組み自体はカンタン。。。というか、ネットワークプレース自体がフォルダーリンクなので、

  1. ディレクトリを作成
  2. 作ったディレクトリの中に target という名のショートカットを作成
  3. そのショートカットにリードオンリー属性をつける。
  4. 下記内容のDesktop.ini(要システム・隠し属性)ファイルを作成
    [.ShellClassInfo]
    CLSID2={0AFACED1-E828-11D1-9187-B532F1E9575D}
    Flags=2
    
  5. ディレクトリにリードオンリー属性に。

これだけ。ショートカットはIShellLink/IPersistFile インターフェイスで作れます。

だだ、この方法では WebDAV(https/http)のネットワークプレースは作れません。
理由は至極当然で、上記(2)のWebDAVのアドレスへのショートカットが原因で、具体的には、https/http などのURIリンク先を単純にIShellLink::SetPath()に渡しても、ショートカットファイル自体は作れても、エクスプローラからWebフォルダとしては認識されません。

リンク先が、HTTP/HTTPSのURLではなく、FTP(ftp://server_name/directory/)や共有フォルダ(\\server_name\folder)のURIならうまくいきます。

このHTTP/HTTPSへのショートカットファイルは、普通のショートカットファイルではなく、どうやら特殊な(非公開の)方法で作られる必要があるようです。
もしかしたら公式のMSDNドキュメントに記述されているのかもしれません。が、結構検索かけて探してみたけどわかりませんでした。ご存じの方は教えて欲しいです (--;;;
WebDAV APIというのがあって、DavAddConnectionなどのようなAPIはありますが、Vista以降用のもののようですし、そもそも DavAddConnectionなどのAPIはSSL接続用、というようなことが書かれてますので、ちょっと違うみたいです。

で、もうちょっとグーグル先生に粘って聞いてみると・・・マイクロソフトのユーザーフォーラム?でそれらしき情報がありました。
【How to create web folders programmatically using Windows Script Host】

英文を要約すると、target.lnk そのもののバイト配列を用意してファイルに書き込むという、かなり力技で強引な(^^;;解決方法が提示されてます。
エクスプローラシェルでWebフォルダを作った後、そのtarget.lnkを解析したみたいですね。

この情報を元に、整理してC/C++で書き直して見ました。

#pragma comment(lib,"shell32.lib")

#define URI_LIMIT_SIZE 1024

#include <windows.h>
#include <strsafe.h>
#include <shlobj.h>
/*
 pURI : WebDAVへのhttp/httpsから始まるURLアドレス
 pDir : ネットワークプレースを作成するディレクトリ
 pName : ネットワークプレースの名前
*/
HRESULT CreateURILinkByEmbedByteArray(PCTSTR pURI,PCTSTR pDir,PCTSTR pName)
{
  HRESULT hres = S_OK;

  TCHAR szPath[MAX_PATH] = {0};
  TCHAR szDir[MAX_PATH] = {0};

  WCHAR szName[URI_LIMIT_SIZE] = {0};
  WCHAR szURI[URI_LIMIT_SIZE] = {0};
  
  HANDLE hFile = NULL;
  DWORD dwLen = 0;
  
  BYTE part1[] = 
    { 0x4c,0x00,0x00,0x00,0x01,0x14,0x02,0x00,0x00,0x00,0x00,0x00,0xC0,0x00,0x00,0x00,
      0x00,0x00,0x00,0x46,0x81,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
      0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
      0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x00,0x00,0x00,
      0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xff,0x00,0x14,0x00,
      0x1f,0x50,0xe0,0x4f,0xd0,0x20,0xea,0x3a,0x69,0x10,0xa2,0xd8,0x08,0x00,0x2b,0x30,
      0x30,0x9d,0x14,0x00,0x2e,0x00,0x00,0xdf,0xea,0xbd,0x65,0xc2,0xd0,0x11,0xbc,0xed,
      0x00,0xa0,0xc9,0x0a,0xb5,0x0f,0xa4,0x00,0x4c,0x50,0x00,0x01,0x42,0x57,0x00,0x00,
      0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x10,0x00,
      0x00,0x00};
  BYTE part2[] = { 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 };
  BYTE nameLen[] = {0x00, 0x00};
  BYTE uriLen[] = {0x00, 0x00};

  int cbLen = lstrlen(pName);

  part1[0x4d] = part1[0x77] = (cbLen <= 44) ? 0x00 : 0x01;

  nameLen[0] = cbLen % 0x100;
  nameLen[1] = cbLen / 0x100;

//ワイド文字に変換。ユニコードでビルドする場合は、単にコピーするだけ。
#ifdef UNICODE
  StringCchCopy(szURI,URI_LIMIT_SIZE,pURI);
  StringCchCopy(szName,MAX_PATH,pName);
#else
  MultiByteToWideChar(CP_ACP,0,pURI,-1,szURI,URI_LIMIT_SIZE);
  MultiByteToWideChar(CP_ACP,0,pName,-1,szName,MAX_PATH);
#endif

  cbLen = lstrlen(pURI);
  uriLen[0] = cbLen % 0x100;
  uriLen[1] = cbLen / 0x100;
  
  //ディレクトリの作成
  StringCchPrintf(szDir,
                  MAX_PATH,
                  TEXT("%s%s%s"),
                  pDir,
                  (szDir[lstrlen(szDir) - 1] != TEXT('\\')) ? TEXT("\\") : TEXT(""),
                  pName);
  SHCreateDirectoryEx(NULL,szDir,NULL);

  //target.lnkのパスを生成  
  StringCchPrintf(szPath,MAX_PATH,TEXT("%s\\%s"),szDir,TEXT("target.lnk"));

  //シェルリンク・ファイルへの書込み
  hFile = CreateFile(szPath,
                     GENERIC_WRITE,
                     0,
                     NULL,
                     CREATE_NEW,
                     FILE_ATTRIBUTE_NORMAL,
                     NULL);

  if(hFile == INVALID_HANDLE_VALUE || GetLastError() == ERROR_ALREADY_EXISTS)
    {
      hres = E_FAIL;
      goto cleanup;
    }

  //埋め込み
  WriteFile(hFile,reinterpret_cast<PVOID>(part1),sizeof(part1),&dwLen,NULL);
  WriteFile(hFile,reinterpret_cast<PVOID>(nameLen),2,&dwLen,NULL);
  WriteFile(hFile,reinterpret_cast<PVOID>(szName),sizeof(WCHAR) * (lstrlenW(szName) + 1),&dwLen,NULL);
  WriteFile(hFile,reinterpret_cast<PVOID>(uriLen),2,&dwLen,NULL);
  WriteFile(hFile,reinterpret_cast<PVOID>(szURI),sizeof(WCHAR) * (lstrlenW(szURI) + 1),&dwLen,NULL);
  WriteFile(hFile,reinterpret_cast<PVOID>(part2),sizeof(part2),&dwLen,NULL);

  CloseHandle(hFile);
  
  //ファイルにRO属性を設定
  SetFileAttributes(szPath,FILE_ATTRIBUTE_READONLY);

  //ディレクトリにRO属性
  SetFileAttributes(szDir,FILE_ATTRIBUTE_READONLY);

cleanup:
  return hres;
}

一応、会社で使っているWindows XP SP3ではネットワークプレースをプログラムから作成できました。
が!、当然ながら、Windows7では、うまくいきません(笑)
Windows7/Vista から仕様が変わったようです。当たり前か(^^;;;

う~ん・・・なんかこう、すんなり旨い方法がないものだろうか・・・。