コマンドプロンプトのエスケープは、\ と " がエスケープ処理の対象となります。
CURL のエスケープは、\ { } | がエスケープ処理の対象となります。
\ をエスケープすると、コマンドプロンプト用のエスケープとCURL用のエスケープが複合し、\\\\という形になります。
ふむふむ…
ふむふむ…
ふむふむふむふむ?…
コマンドプロンプトは \\\\ を " として取り扱います…
(`□′)╯┴┴
grayhole
三流C++プログラマによる随筆
2023年9月22日金曜日
2023年6月23日金曜日
atldbcli.h のバグを踏んだ
atldbcli.h の CCommand<CDynamicStringAccessor> を利用していたコードが null pointer exception で落ちるようになった。
ほぇ?(#^ω^)ピキピキ
デバッガでトレースしていくと、m_pAccessor のメンバが nullptr で初期化されないまま放置されていた。
で、Accessor クラスは、どこに行った?
おそらく、class template refactoring により、自分自身に継承する形になったようです。
なので、CCommand<CDynamicStringAccessor>::SetAccessor 関数を使用して自分自身を設定する必要がありました。
せっかくなので、使い方のサンプル込みで、紹介です。
ほぇ?(#^ω^)ピキピキ
デバッガでトレースしていくと、m_pAccessor のメンバが nullptr で初期化されないまま放置されていた。
で、Accessor クラスは、どこに行った?
おそらく、class template refactoring により、自分自身に継承する形になったようです。
なので、CCommand<CDynamicStringAccessor>::SetAccessor 関数を使用して自分自身を設定する必要がありました。
せっかくなので、使い方のサンプル込みで、紹介です。
#include <iostream> #include <objbase.h> #include <atldbcli.h> int main(int argc, char* argv[] ) { HRESULT hr = CoInitialize(NULL ); if(FAILED(hr)) { std::cerr << "Fail to Initialize COM:" << hr << std::endl; } CDataSource ds; // OLEDBによるODBC接続文字列 hr = ds.OpenFromInitializationString( L"Provider=MSDASQL.1;Password=password;" L"Persist Security Info=True;" L"User ID=username;" L"Data Source=odbc_data_source_name;" L"Extended Properties=\"DSN=data_source_name;UID=username;PWD=password\"" ); CSession ss; CCommand<CDynamicStringAccessor> rs; hr = ss.Open(ds ); hr = rs.Open(ss, "select * from hoge" ); // CCommand<typename T>::m_pAccessor を初期化するコードが欠落しているため // 自分自身を設定する必要がある(どこかのタイミングで混入したバグ対応) // 2023/7/13 修正されたような気がしますが、下記コードは正しくなくなった感じがします。 // 仕様がよくわかりません。 rs.SetAccessor(&rs); hr = rs.MoveNext(); if( FAILED(hr) || hr == DB_S_ENDOFROWSET ) { std::cerr << "Fail to MoveNext: " << hr << std::endl; } // Get the column information ULONG ulColumns = rs.GetColumnCount(); DBTYPE dbtype; rs.GetColumnType( 1, &dbtype ); dbtype &= 0x3FFF; // DBTYPE_BYREF を除去 if( dbtype == DBTYPE_I4 || dbtype == DBTYPE_UI4 || dbtype == DBTYPE_R8 || dbtype == DBTYPE_STR || dbtype == DBTYPE_WSTR || dbtype == DBTYPE_DECIMAL || dbtype == DBTYPE_VARNUMERIC || dbtype == DBTYPE_NUMERIC ) { // よくあるフィールド型 } else { // 対応可能か検討が必要なフィールド型 std::cerr << "Un supported dbtype: " << dbtype << std::endl; } int nMax = 10; while(nMax) { std::string strData; for( DBORDINAL col = 1; col <= ulColumns; col++ ) { DBSTATUS dStatus; DBLENGTH nLength; rs.GetStatus( col, &dStatus ); rs.GetLength( col, &nLength ); if( col > 1 ) { std::cout << ", "; } if( FAILED( dStatus ) ) { std::cout << "<<ERROR>>"; } else if( dStatus == DBSTATUS_S_ISNULL ) { std::cout << "<<NULL>>"; } else { std::cout << rs.GetString(col); } } std::cout << std::endl; hr = rs.MoveNext(); if( FAILED(hr) || hr == DB_S_ENDOFROWSET ) break; --nMax; } rs.Close(); ss.Close(); ds.Close(); CoUninitialize(); return 0; }2023/07/13 追記: バグは修正されたのか、仕様が変わったのか、よくわからない状況になりました。
2022年9月22日木曜日
C#の Properties.Settings.Default が実際にどこに保存されるか忘備録
C# の Properties.Settings.Default 言語機構として用意していただけるのは有難いのですが、ここに環境系の設定を書いておくとインストールされたマシンの環境によって設定を変えたいとか出てくるんですよ。
ところが、こいつ、一体どこのファイルの設定を見てるねん???(#^ω^)ピキピキ
ってキレそうになる仕様なわけです。
という事で、.Net の古いバージョンでは、下記コードで導き出される場所に初期値が書かれています。
いつも大変お世話になります。Stackoverflow さまによると
Where are the Properties.Settings.Default stored? によると
これも Stackoverflow にありました。
How to get hash value in user.config path?
(ノ`□´)ノ⌒┻━┻
ところが、こいつ、一体どこのファイルの設定を見てるねん???(#^ω^)ピキピキ
ってキレそうになる仕様なわけです。
という事で、.Net の古いバージョンでは、下記コードで導き出される場所に初期値が書かれています。
System.Reflection.Assembly asm =System.Reflection.Assembly.GetExecutingAssembly(); textBox1.Text = asm.GetName().Version.ToString(); // バージョン番号を取り出す // config のデフォルト値が記述されたファイルの場所 textBox2.Text = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath;.Net の仕様が変わり、現在は
// Foo.exe.config 場合によっては Foo.dll.config // ここは作成したプロジェクトの実行物の名前に依存します。 textBox2.Text = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location) + "\\Foo.exe.config";はてさて、ではコードで、これらの要素を変更した値はどこに書き込まれるのか?
いつも大変お世話になります。Stackoverflow さまによると
Where are the Properties.Settings.Default stored? によると
c:\users\USER\AppData\Local\COMPANY\APPLICATION.exe_Url_LOOKSLIKESOMEKINDOFHASH\VERSION\user.configなんだそうで、How know LOOKSLIKESOMEKINDOFHASH? とは、ごもっともな質問。私も知りたい。
これも Stackoverflow にありました。
How to get hash value in user.config path?
(ノ`□´)ノ⌒┻━┻
2022年8月24日水曜日
IISのResponse Header を無効化 忘備録
PowerShell で、IIS の Server ヘッダや、X-ASPNET-Version ヘッダを消去、TRACEメソッドの無効化がしたくて、いろいろ試してみたが、やれ、静的コンテンツではなく、Exe経由のコンテンツのヘッダが消えないとか、ひどい目にあったので忘備録。
IIS ReWrite モジュールが必要です。
管理者権限で、下記スクリプトを実行します。
スクリプトだけでは完結しないので、コメントも読んでください
IIS ReWrite モジュールが必要です。
管理者権限で、下記スクリプトを実行します。
スクリプトだけでは完結しないので、コメントも読んでください
# # PowerShell は BOM付き UTF-8 のエンコーディングで保存する事 # さもなくば、「文字列に終端記号" がありません」という # エラーに悩まされます。(BOMの仕様必要?) # # # X-ASPNET-VERSION を無効にする送信書き換えルールを # 指定された PSPath に追加する # function global:AddXASPNetVersionRule { param ( $PSPath ) echo "$PSPath の X-ASPNET-VERSION ヘッダを無効にします" $chk = Get-WebConfigurationProperty ` -Filter "//rewrite/outboundRules/rule[@name='REMOVE_X-ASPNET-VERSION']" ` -PSPath $PSPath ` -Name name if( $chk -eq $null ) { Add-WebConfigurationProperty ` -Filter "//rewrite/outboundRules" ` -PSPath $PSPath ` -Name "Collection" ` -Value @{name="REMOVE_X-ASPNET-VERSION"} Set-WebConfiguration ` -Filter "//rewrite/outboundRules/rule[@name='REMOVE_X-ASPNET-VERSION']/match" ` -PSPath $PSPath ` -Value @{serverVariable="RESPONSE_X-ASPNET-VERSION";pattern=".+"} Set-WebConfiguration ` -Filter "//rewrite/outboundRules/rule[@name='REMOVE_X-ASPNET-VERSION']/action" ` -PSPath $PSPath ` -Value @{type="Rewrite"} echo " ...処理完了..." } else { echo " ...処理済み skip..." } } # # SERVER-VERSION を無効にする送信書き換えルールを # 指定された PSPath に追加する # function global:AddServerVersionRule { param ( $PSPath ) echo "$PSPath の Server ヘッダを無効にします" $chk = Get-WebConfigurationProperty ` -Filter "//rewrite/outboundRules/rule[@name='REMOVE_SERVER-VERSION']" ` -PSPath $PSPath ` -Name name if( $chk -eq $null ) { Add-WebConfigurationProperty ` -Filter "//rewrite/outboundRules" ` -PSPath $PSPath ` -Name "Collection" ` -Value @{name="REMOVE_SERVER-VERSION"} Set-WebConfiguration ` -Filter "//rewrite/outboundRules/rule[@name='REMOVE_SERVER-VERSION']/match" ` -PSPath $PSPath ` -Value @{serverVariable="RESPONSE_SERVER";pattern=".+"} Set-WebConfiguration ` -Filter "//rewrite/outboundRules/rule[@name='REMOVE_SERVER-VERSION']/action" ` -PSPath $PSPath ` -Value @{type="Rewrite"} echo " ...処理完了..." } else { echo " ...処理済み skip..." } } # # サーバ変数 RESPONSE_X-ASPNET-VERSION を追加する # X-ASPNET-VERSION: ヘッダとして利用される変数 # $asv = Get-WebConfigurationProperty ` -filter "//rewrite/allowedServerVariables/add[@name='RESPONSE_X-ASPNET-VERSION']"` -name name if ($asv -eq $null) { echo "サーバ変数 RESPONSE_X-ASPNET-VERSION を追加します" Add-WebConfigurationProperty ` -Filter "//rewrite/allowedServerVariables" ` -PSPath "IIS:\" ` -Name "Collection" ` -Value @{name="RESPONSE_X-ASPNET-VERSION"} } # # サーバ変数 RESPONSE_SERVER を追加する # SERVER: ヘッダとして利用される変数 # $asv2 = Get-WebConfigurationProperty ` -filter "//rewrite/allowedServerVariables/add[@name='RESPONSE_SERVER']"` -name name if ($asv2 -eq $null) { echo "サーバ変数 RESPONSE_SERVER を追加します" Add-WebConfigurationProperty ` -Filter "//rewrite/allowedServerVariables" ` -PSPath "IIS:\" ` -Name "Collection" ` -Value @{name="RESPONSE_SERVER"} } # # X-ASPNET-VERSION ヘッダを無効にする # AddXASPNetVersionRule( "IIS:\" ) AddXASPNetVersionRule( "IIS:\sites\Default Web Site" ) # IIS-Admin上で手動追加するとエラーにならないが、コードで # 実行するとエラーになる不思議仕様 #AddXASPNetVersionRule( "IIS:\sites\Default Web Site\foo" ) # Application で無効化するために必要? # 仕様が不明すぎて草 AddXASPNetVersionRule( "MACHINE/WEBROOT/APPHOST" ) # # SERVER-VERSION ヘッダを無効にする # AddServerVersionRule( "IIS:\" ) AddServerVersionRule( "IIS:\sites\Default Web Site" ) # IIS-Admin上で手動追加するとエラーにならないが、コードで # 実行するとエラーになる不思議仕様 #AddServerVersionRule( "IIS:\sites\Default Web Site\foo" ) # Application で無効化するために必要? # 仕様が不明すぎて草 AddServerVersionRule( "MACHINE/WEBROOT/APPHOST" ) # # IISの Server Header を無効化します。 # 静的コンテンツだけに効果があるため気休め # echo " IIS のサーバヘッダを無効化します " echo " ※ Application に対しては効果がありません" Set-WebConfigurationProperty ` -pspath 'MACHINE/WEBROOT/APPHOST' ` -filter "system.webServer/security/requestFiltering" ` -name "removeServerHeader" ` -value "True" # # IISの TRACE を無効化します。 # 静的コンテンツだけに効果があるため気休め # echo " IIS のTRACE メソッドを無効化します " echo " ※ Application に対しては効果がありません" echo " コマンドで対応できる範囲は静的コンテンツのみです" echo " 要求フィルター>HTTP動詞>Trace;false をIIS設定から手動で行う必要があります" # # 要求フィルター HTTP動詞 TRACE をfalseにする # # エラーで動作しなくなるので、コマンドによる、このやり方はダメ # Add-WebConfigurationProperty ` # -pspath "IIS:\" ` # -filter "/system.webServer/security/requestFiltering/verbs" ` # -name '.' -value @{verb='TRACE';allowed='False'} # $colls = Get-IISConfigSection -CommitPath 'Default Web Site' -SectionPath 'system.webServer/security/requestFiltering' #echo "colls : $colls" $verbs = Get-IISConfigCollection -ConfigElement $colls -CollectionName 'verbs' #echo "verbs : $verbs" try { New-IISConfigCollectionElement -ConfigCollection $verbs -ConfigAttribute @{ 'verb'='TRACE';'allowed'=$false } Stop-IISCommitDelay } catch { # 取得して、値を設定するコードが動作しない。(関数の仕様がわからない) # echo " set trace " # $trace = Get-IISConfigCollectionElement -ConfigCollection $verbs -ConfigAttribute @{ 'verb'='TRACE' } # echo "trace : $trace.allowed $trace.verb" # Set-IISConfigAttributeValue -ConfigElement $trace -AttributeName 'allowed' -AttributeValue $false } # # Web設定を無効にしてもアプリケーションからのヘッダが無効になるとは言ってない # 気休め(無い方がまし) # #$rule3 = Get-WebConfigurationProperty ` # -filter "/system.webServer/httpProtocol/customHeaders/add[@name='X-Powerd-By']" ` # -Name name # #if ($rule2 -eq $null) #{ # echo "clear X-Powered-By" # Clear-WebConfiguration "/system.webServer/httpProtocol/customHeaders/add[@name='X-Powered-By']" #}
2022年7月29日金曜日
apache maven で Jni DLL を梱包・備忘録
肝は、resources セクションの resource に対して、filtering=false を指定する事。
この filtering を true にすると、対象リソースをテキストファイルと見なして、文字列の置換が実行されてしまう。
dll ファイルは、バイナリで、utf-8の文字コード規則に収まらないから、false にしないとエラーになってしまう。
後は、Bundle-NativeCode に dll ファイルを resource セクションで指定したディレクトリからの相対パスで ; により列挙すればOK
java のコードで、loadLibraryを記述する
この filtering を true にすると、対象リソースをテキストファイルと見なして、文字列の置換が実行されてしまう。
dll ファイルは、バイナリで、utf-8の文字コード規則に収まらないから、false にしないとエラーになってしまう。
後は、Bundle-NativeCode に dll ファイルを resource セクションで指定したディレクトリからの相対パスで ; により列挙すればOK
<build> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> <resource> <directory>src/main/extlib</directory> <filtering>false</filtering> </resource> </resources> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>${maven.compiler.plugin.version}</version> <configuration> <source>8</source> <target>8</target> </configuration> </plugin> <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <version>${maven.bundle.plugin.version}</version> <extensions>true</extensions> <configuration> <instructions> <Build-Number>${buildId}</Build-Number> <Bundle-SymbolicName>${project.groupId}.${project.artifactId}</Bundle-SymbolicName> <Bundle-ContactAddress>${sdk.contact.address}</Bundle-ContactAddress> <Bundle-Version>${project.version}</Bundle-Version> <Bundle-NativeCode>native/myJni.dll;native/libssl-1_1-x64.dll;native/zlib1.dll</Bundle-NativeCode> <Export-Package/> <Private-Package>jp.co.foo.bar</Private-Package> </instructions> </configuration> </plugin> </plugins> </build>
java のコードで、loadLibraryを記述する
private static boolean tryLoadLibrary(String libname) { try { System.loadLibrary(libname); return true; } catch(Exception err) { err.printStackTrace(); } return false; } // Bundle-NativeCode の dll を読み込む。Platformにより拡張子が異なるため // Java のコードでは、.dll .so といった名称まで指定しなくても良い。 public static void tryLoadLibraries() { tryLoadLibrary("native/libssl-1_1-x64"); tryLoadLibrary("native/zlib1"); tryLoadLibrary("native/myJni"); } // Load JNI static { // 自動でライブラリがロードされるはずなのだが、 // この初期化が行われるより先に、JNI の関数が呼ばれる事態が // 発生する事がある。よって、クリティカルな場所から重複して // tryLoadLibraries をコールしても大丈夫なように実装している。 tryLoadLibraries(); }
2022年5月18日水曜日
WIX で VCRuntime のインストール忘備録
そろそろ VCのRUNTIMEをVisual Studio 2019に移行しとかないと、コンパイルできないライブラリが増えてきたかな?と思いまして、2015 から 2019 に引き上げました。
WIXを使ったインストーラで、2019用のVC runtime のマージモジュールを探したが見つかりません。
ほぇ?と思って検索したらマージモジュールを使用したコンポーネントの再配布に書いてありました。
Visual Studio 2019 以降、Visual C++ 再頒布可能ファイルのマージ モジュールは非推奨です
Visual Studio 2019 以降、Visual C++ 再頒布可能ファイルのマージ モジュールは非推奨です
Visual Studio 2019 以降、Visual C++ 再頒布可能ファイルのマージ モジュールは非推奨です
ふぁ???
という事で、VC Runtime がインストールされているかどうかチェックが必要になりました
Wix per user installer to detect the Visual C++ 2015 Redistributableにチェック方法がありました。StackOverflowさまさまです
How to check if the Microsoft Visual C++ Runtime is installedにも詳細が記述されてましたが、こちらだとサービスパックが追加される毎に対応が必要そうで、ちょっと重たい。
という事で、
WIXを使ったインストーラで、2019用のVC runtime のマージモジュールを探したが見つかりません。
ほぇ?と思って検索したらマージモジュールを使用したコンポーネントの再配布に書いてありました。
Visual Studio 2019 以降、Visual C++ 再頒布可能ファイルのマージ モジュールは非推奨です
Visual Studio 2019 以降、Visual C++ 再頒布可能ファイルのマージ モジュールは非推奨です
Visual Studio 2019 以降、Visual C++ 再頒布可能ファイルのマージ モジュールは非推奨です
ふぁ???
という事で、VC Runtime がインストールされているかどうかチェックが必要になりました
Wix per user installer to detect the Visual C++ 2015 Redistributableにチェック方法がありました。StackOverflowさまさまです
How to check if the Microsoft Visual C++ Runtime is installedにも詳細が記述されてましたが、こちらだとサービスパックが追加される毎に対応が必要そうで、ちょっと重たい。
という事で、
<Product ...> ...vc runtime 2015 x86 のインストール状況プロパティ
<!-- C++ 2015 --> <Property Id="CPPRUNTIME2015X86" Secure="yes"> <RegistrySearch Id="mfc140x86_23026" Root="HKLM" Key="SOFTWARE\Classes\Installer\Dependencies\{74d0e5db-b326-4dae-a6b2-445b9de1836e}" Type="raw" /> <RegistrySearch Id="mfc140x86_24215" Root="HKLM" Key="SOFTWARE\Classes\Installer\Dependencies\{e2803110-78b3-4664-a479-3611a381656a}" Type="raw" /> </Property>vc runtime 2017 x86 のインストール状況プロパティ
<!-- C++ 2017 --> <Property Id="CPPRUNTIME2017X86" Secure="yes"> <RegistrySearch Id="mfc1416x86" Root="HKCR" Key="Installer\Dependencies\VC,redist.x86,x86,14.16,bundle" Type="raw" /> </Property>vc runtime 2019 x86 のインストール状況プロパティ
<!-- C++ 2019 --> <Property Id="CPPRUNTIME2019X86" Secure="yes"> <?foreach CPPRUNTIMEVERSIONPREFIX in 21;22;23;24;25;26;27;28;29;30;31;32;33;34;35;36;37;38;39;40?> <RegistrySearch Id="mfc14$(var.CPPRUNTIMEVERSIONPREFIX)x86" Root="HKCR" Key="Installer\Dependencies\VC,redist.x86,x86,14.$(var.CPPRUNTIMEVERSIONPREFIX),bundle" Type="raw" /> <?endforeach ?> </Property>vc runtime 2019 x86 がインストールされていないと、インストールを中止する条件の追加
<!-- インストール時にC++ 2019 Runtime(x86) がインストールされているかチェック --> <Condition Message="Microsoft Visual C++ 2019 (x86) Redistributable missing"> <![CDATA[Installed Or CPPRUNTIME2019X86]]> </Condition>vc runtime 2015 x64 のインストール状況プロパティ
<!-- C++ 2015 --> <Property Id="CPPRUNTIME2015X64" Secure="yes"> <RegistrySearch Id="mfc140x64_23026" Root="HKLM" Key="SOFTWARE\Classes\Installer\Dependencies\{e46eca4f-393b-40df-9f49-076faf788d83}" Type="raw" /> <RegistrySearch Id="mfc140x64_24215" Root="HKLM" Key="SOFTWARE\Classes\Installer\Dependencies\{d992c12e-cab2-426f-bde3-fb8c53950b0d}" Type="raw" /> </Property>vc runtime 2017 x64 のインストール状況プロパティ
<!-- C++ 2017 --> <Property Id="CPPRUNTIME2017X64" Secure="yes"> <RegistrySearch Id="mfc1416x64" Root="HKCR" Key="Installer\Dependencies\VC,redist.x64,amd64,14.16,bundle" Type="raw" /> </Property>vc runtime 2019 x64 のインストール状況プロパティ
<!-- C++ 2019 --> <Property Id="CPPRUNTIME2019X64" Secure="yes"> <?foreach CPPRUNTIMEVERSIONPREFIX in 21;22;23;24;25;26;27;28;29;30;31;32;33;34;35;36;37;38;39;40?> <RegistrySearch Id="mfc14$(var.CPPRUNTIMEVERSIONPREFIX)x64" Root="HKCR" Key="Installer\Dependencies\VC,redist.x64,amd64,14.$(var.CPPRUNTIMEVERSIONPREFIX),bundle" Type="raw" /> <?endforeach ?> </Property>vc runtime 2019 x64 がインストールされていないと、インストールを中止する条件の追加
<!-- インストール時にC++ 2019 Runtime(x64) がインストールされているかチェック --> <Condition Message="Microsoft Visual C++ 2019 (x64) Redistributable missing"> <![CDATA[Installed Or CPPRUNTIME2019X64]]> </Condition>vc runtime 2010 x64 のマージモジュールを追加
<Directory Id="System64Folder"> <!-- VC100 ATL Runtime --> <Merge Id="Microsoft_VC100_ATL_x64.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_ATL_x64.msm" /> <Merge Id="Microsoft_VC100_CRT_x64.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_CRT_x64.msm" /> <Merge Id="Microsoft_VC100_MFCLOC_x64.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_MFCLOC_x64.msm" /> <Merge Id="Microsoft_VC100_MFC_x64.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_MFC_x64.msm" /> <Merge Id="Microsoft_VC100_OpenMP_x64.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_OpenMP_x64.msm" /> </Directory>vc runtime 2010 x86 のマージモジュールを追加
<Directory Id="SystemFolder"> <!-- VC100 ATL Runtime --> <Merge Id="Microsoft_VC100_ATL_x86.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_ATL_x86.msm" /> <Merge Id="Microsoft_VC100_CRT_x86.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_CRT_x86.msm" /> <Merge Id="Microsoft_VC100_MFCLOC_x86.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_MFCLOC_x86.msm" /> <Merge Id="Microsoft_VC100_MFC_x86.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_MFC_x86.msm" /> <Merge Id="Microsoft_VC100_OpenMP_x86.msm" Language="0" DiskId="1" SourceFile="C:/Program Files (x86)/Common Files/Merge Modules/Microsoft_VC100_OpenMP_x86.msm" /> </Directory>vc runtime 2010 x64 と x86 のマージモジュールを参照
<Feature ...> <!-- VC10 runtime --> <MergeRef Id="Microsoft_VC100_ATL_x64.msm" /> <MergeRef Id="Microsoft_VC100_CRT_x64.msm" /> <MergeRef Id="Microsoft_VC100_MFCLOC_x64.msm" /> <MergeRef Id="Microsoft_VC100_MFC_x64.msm" /> <MergeRef Id="Microsoft_VC100_OpenMP_x64.msm" /> <!-- VC10 runtime --> <MergeRef Id="Microsoft_VC100_ATL_x86.msm" /> <MergeRef Id="Microsoft_VC100_CRT_x86.msm" /> <MergeRef Id="Microsoft_VC100_MFCLOC_x86.msm" /> <MergeRef Id="Microsoft_VC100_MFC_x86.msm" /> <MergeRef Id="Microsoft_VC100_OpenMP_x86.msm" /> </Feature>
... </Product>というように対応できそうです。
2022年5月13日金曜日
Windows DLL x86とx64で異なる関数名調整の備忘録
AESのDLLをビルドしていて、x64でビルドしたものは素直に利用できるのにx86でビルドしたものを利用しようとするとLNK2019: _aes_encrypt_key が見つからないというリンクエラーになってしまった。
test_lib.exe のソースを見ると
で、名前の定義は aestst.h に記述されており、x86 と x64 で切り替えている。
x86 と x64 でマングリングの名前が違う事に自分も苛ついてはいました。
def ファイルに alias 指定できないの???と思って調べたら、ありました。
EXPORTS
alias=function_name
としてやれば良かったようです。
という事で、リンクエラーになった x86 用のビルドだけ以下のdefファイルを適用するようにしました。
今まで、やり方がわからなくて、Delphi 用 DLL には序数で指定したりと、大変だったんですよね。
2022/06/29 追記:
bigtypes.h に
DLL_IMPORT をプリプロセッサの定義に追加しないと、コールスタックが破壊されて、よくわからないエラーになる
尚、aes.dll を使った dll を書きたい場合は、DLL_EXPORT や DLL_IMPORT といった汎用的な定義で判別していると、定義がバッティングするので、AES_DLL_EXPORT と言った定義に変更した方が良いと思う。できれば、DLL_IMPORT は定義しなくても AES_DLL_EXPORT が定義されていなかったら、利用する側のコードだと判別できるので、このマクロの書き方は改良した方が良いかな?
もうひとつ、vsyasm の -f オプションが Win32 ではなく win32 しか認識しないので、
vsyasm.props ファイルを修正する
test_lib.exe のソースを見ると
#ifdef AES_MODES fn->fn_test_align = (g_talign*)GetProcAddress(h_dll, etad_name); fn->fn_mode_reset = (g_reset*)GetProcAddress(h_dll, eres_name); fn->fn_ecb_enc = (g_enc1*)GetProcAddress(h_dll, ecbe_name); fn->fn_ecb_dec = (g_dec1*)GetProcAddress(h_dll, ecbd_name); fn->fn_cbc_enc = (g_enc2*)GetProcAddress(h_dll, cbce_name); fn->fn_cbc_dec = (g_dec2*)GetProcAddress(h_dll, cbcd_name); fn->fn_cfb_enc = (g_enc3*)GetProcAddress(h_dll, cfbe_name); fn->fn_cfb_dec = (g_enc3*)GetProcAddress(h_dll, cfbd_name); fn->fn_ofb_cry = (g_enc3*)GetProcAddress(h_dll, ofb_name); fn->fn_ctr_cry = (g_enc4*)GetProcAddress(h_dll, ctr_name); if( !fn->fn_mode_reset || !fn->fn_test_align || !fn->fn_ecb_enc || !fn->fn_ecb_dec || !fn->fn_cbc_enc || !fn->fn_cbc_dec || !fn->fn_cfb_enc || !fn->fn_cfb_dec || !fn->fn_ofb_cry || !fn->fn_ctr_cry ) ok = 0; #endifと、DLLを LoadLibrary した後で、GetProcAddress により関数のアドレスを取得し、呼び出すという事をしていた。
で、名前の定義は aestst.h に記述されており、x86 と x64 で切り替えている。
#if defined( _WIN64 ) #define gt_name "aes_init" #define ek_name128 "aes_encrypt_key128" #define ek_name192 "aes_encrypt_key192" #define ek_name256 "aes_encrypt_key256" #define ek_name "aes_encrypt_key" #define eb_name "aes_encrypt" #define dk_name128 "aes_decrypt_key128" #define dk_name192 "aes_decrypt_key192" #define dk_name256 "aes_decrypt_key256" #define dk_name "aes_decrypt_key" #define db_name "aes_decrypt" #define etad_name "aes_test_alignment_detection" #define eres_name "aes_mode_reset" #define ecbe_name "aes_ecb_encrypt" #define ecbd_name "aes_ecb_decrypt" #define cbce_name "aes_cbc_encrypt" #define cbcd_name "aes_cbc_decrypt" #define cfbe_name "aes_cfb_encrypt" #define cfbd_name "aes_cfb_decrypt" #define ofb_name "aes_ofb_crypt" #define ctr_name "aes_ctr_crypt" #else #define gt_name "_aes_init@0" #define ek_name128 "_aes_encrypt_key128@8" #define ek_name192 "_aes_encrypt_key192@8" #define ek_name256 "_aes_encrypt_key256@8" #define ek_name "_aes_encrypt_key@12" #define eb_name "_aes_encrypt@12" #define dk_name128 "_aes_decrypt_key128@8" #define dk_name192 "_aes_decrypt_key192@8" #define dk_name256 "_aes_decrypt_key256@8" #define dk_name "_aes_decrypt_key@12" #define db_name "_aes_decrypt@12" #define etad_name "_aes_test_alignment_detection@4" #define eres_name "_aes_mode_reset@4" #define ecbe_name "_aes_ecb_encrypt@16" #define ecbd_name "_aes_ecb_decrypt@16" #define cbce_name "_aes_cbc_encrypt@20" #define cbcd_name "_aes_cbc_decrypt@20" #define cfbe_name "_aes_cfb_encrypt@20" #define cfbd_name "_aes_cfb_decrypt@20" #define ofb_name "_aes_ofb_crypt@20" #define ctr_name "_aes_ctr_crypt@24" #endifなるほど、だから x64 ではリンクエラーにならず、x86ではリンクエラーになったのだ。
x86 と x64 でマングリングの名前が違う事に自分も苛ついてはいました。
def ファイルに alias 指定できないの???と思って調べたら、ありました。
EXPORTS
alias=function_name
としてやれば良かったようです。
という事で、リンクエラーになった x86 用のビルドだけ以下のdefファイルを適用するようにしました。
LIBRARY Aes EXPORTS _aes_init=_aes_init@0 _aes_encrypt_key128=_aes_encrypt_key128@8 _aes_encrypt_key192=_aes_encrypt_key192@8 _aes_encrypt_key256=_aes_encrypt_key256@8 _aes_encrypt_key=_aes_encrypt_key@12 _aes_encrypt=_aes_encrypt@12 _aes_decrypt_key128=_aes_decrypt_key128@8 _aes_decrypt_key192=_aes_decrypt_key192@8 _aes_decrypt_key256=_aes_decrypt_key256@8 _aes_decrypt_key=_aes_decrypt_key@12 _aes_decrypt=_aes_decrypt@12 _aes_test_alignment_detection=_aes_test_alignment_detection@4 _aes_mode_reset=_aes_mode_reset@4 _aes_ecb_encrypt=_aes_ecb_encrypt@16 _aes_ecb_decrypt=_aes_ecb_decrypt@16 _aes_cbc_encrypt=_aes_cbc_encrypt@20 _aes_cbc_decrypt=_aes_cbc_decrypt@20 _aes_cfb_encrypt=_aes_cfb_encrypt@20 _aes_cfb_decrypt=_aes_cfb_decrypt@20 _aes_ofb_crypt=_aes_ofb_crypt@20 _aes_ctr_crypt=_aes_ctr_crypt@24こうする事で、見事にLNK2019を回避する事ができました。
今まで、やり方がわからなくて、Delphi 用 DLL には序数で指定したりと、大変だったんですよね。
2022/06/29 追記:
bigtypes.h に
#ifndef RETURN_VALUES # define RETURN_VALUES # if defined( DLL_EXPORT ) # if defined( _MSC_VER ) || defined ( __INTEL_COMPILER ) # define VOID_RETURN __declspec( dllexport ) void __stdcall # define INT_RETURN __declspec( dllexport ) int __stdcall # elif defined( __GNUC__ ) # define VOID_RETURN __declspec( __dllexport__ ) void # define INT_RETURN __declspec( __dllexport__ ) int # else # error Use of the DLL is only available on the Microsoft, Intel and GCC compilers # endif # elif defined( DLL_IMPORT ) # if defined( _MSC_VER ) || defined ( __INTEL_COMPILER ) # define VOID_RETURN __declspec( dllimport ) void __stdcall # define INT_RETURN __declspec( dllimport ) int __stdcall # elif defined( __GNUC__ ) # define VOID_RETURN __declspec( __dllimport__ ) void # define INT_RETURN __declspec( __dllimport__ ) int # else # error Use of the DLL is only available on the Microsoft, Intel and GCC compilers # endif # elif defined( __WATCOMC__ ) # define VOID_RETURN void __cdecl # define INT_RETURN int __cdecl # else # define VOID_RETURN void # define INT_RETURN int # endif #endifと定義されていて、x64は呼び出し規約が異なるので問題なく動作するが、x86で利用する場合は利用する側で
DLL_IMPORT をプリプロセッサの定義に追加しないと、コールスタックが破壊されて、よくわからないエラーになる
尚、aes.dll を使った dll を書きたい場合は、DLL_EXPORT や DLL_IMPORT といった汎用的な定義で判別していると、定義がバッティングするので、AES_DLL_EXPORT と言った定義に変更した方が良いと思う。できれば、DLL_IMPORT は定義しなくても AES_DLL_EXPORT が定義されていなかったら、利用する側のコードだと判別できるので、このマクロの書き方は改良した方が良いかな?
もうひとつ、vsyasm の -f オプションが Win32 ではなく win32 しか認識しないので、
vsyasm.props ファイルを修正する
... <CommandLineTemplate Condition="'$(Platform)'=='Win32'">"$(YASM_PATH)"vsyasm.exe -Xvc -f win32 [AllOptions] [AdditionalOptions] [Inputs]</CommandLineTemplate> <CommandLineTemplate Condition="'$(Platform)'!='Win32'">"$(YASM_PATH)"vsyasm.exe -Xvc -f $(Platform) [AllOptions] [AdditionalOptions] [Inputs]</CommandLineTemplate> ...
登録:
投稿 (Atom)