X
Win32API質問箱 Build127
0001デフォルトの名無しさん
垢版 |
2021/12/09(木) 21:32:56.60ID:sYLpmj89
Win32APIについての質問はこちらへどうぞ。

■注意
・質問する前にMSDNライブラリやPlatformSDK、Google等で検索しましょう。
・日本語版MSDN Online Libraryは不完全です。
　英語版( http://msdn.microsoft.com/en-us/library/ )の利用推奨。
・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。
・言語特有の問題やIDE、MFCやVCLなどの質問はそれぞれの言語や開発環境スレで

■過去スレ
Win32API質問箱 Build126
https://mevius.5ch.net/test/read.cgi/tech/1588339011/
Win32API質問箱 Build125
https://mevius.5ch.net/test/read.cgi/tech/1551247748/
Win32API質問箱 Build124
https://mevius.5ch.net/test/read.cgi/tech/1510395780/

■関連スレ
Visual Studio 2020 Part1 https://mevius.5ch.net/test/read.cgi/tech/1634166667/
Visual Studio 2019 Part7 https://mevius.5ch.net/test/read.cgi/tech/1634178709/
Visual Studio 2017 Part7 https://mevius.5ch.net/test/read.cgi/tech/1558179898/
【C++】 DirectX初心者質問ｽﾚ Part41 【C】 https://mevius.5ch.net/test/read.cgi/tech/1521786252/
0552デフォルトの名無しさん
垢版 |
2023/03/14(火) 15:55:53.14ID:+K74J7cv
＞ミューテックスを使うとなると、事前にミューテックスの名前も決める必要が出てくるのですが。

別にそんな必要はないでしょ
ユニーク名＋ファイル名でミューテックスを使えばいい
（※ユニーク名ってのは自分しか使わない名前のことね、例えばGUIDとかだけどそこまでがっちりやる必要もないとは思う）
0553デフォルトの名無しさん
垢版 |
2023/03/14(火) 16:03:43.56ID:+K74J7cv
>>551
指定できる最大値を設定しておけばいい

＞ ファイルの現在の終了位置を超える領域をロックすることは、エラーではありません。
とあるから事実上ファイルそのものをロックしたのと同じ
0554デフォルトの名無しさん
垢版 |
2023/03/14(火) 16:27:54.12ID:gMQMDZBf
>プロセス間で同じファイルを読んだり書いたりしたい
問題を無闇に複雑にしてると思わないか
0555蟻人間 ◆T6xkBnTXz7B0
垢版 |
2023/03/14(火) 17:01:38.94ID:iLShrRcK
クライアント・サーバーモデルで、
サーバーだけが書き込めるとか言った制約があった方が良いかも知れません。
0556549
垢版 |
2023/03/14(火) 18:23:18.32ID:5+uIhtUh
アドバイスありがとうございます。
あるアプリから別のアプリを起動する際、
コマンドラインでは収まらないような長い情報を渡す必要があり、
ファイルに必要な情報を書いてやりとりするようにしています。
(コマンドラインにはそのファイルのパス名を渡している)

なので、ファイルを作成するアプリと、そのファイルを読み込むアプリがあり、
多重起動などのタイミングによってはアクセスがぶつかる可能性があるので、
このファイルに対する同時アクセスを制御したいという質問でした。
ミューテックスとLockFileExとどちらで実装するか、検討させていただきます。
0557デフォルトの名無しさん
垢版 |
2023/03/14(火) 18:25:17.73ID:xPBygAZk
>>554
コンパイラとリンカで同じファイルを読んだり書いたりするのも
問題を無闇に複雑にしているのか？
0560デフォルトの名無しさん
垢版 |
2023/03/14(火) 19:54:35.88ID:5+uIhtUh
>>559
それもやってみたのですが、多重起動などのタイミングによっては、
どうやっても、読み込まれずに放置されるゴミファイルができてしまいます。
テンポラリフォルダなんて気にしなければよいといえばよいのですが。
0561デフォルトの名無しさん
垢版 |
2023/03/14(火) 21:32:45.60ID:M7rmtaeA
Tempなんか使わずとも末尾PIDの名前でファイルなりを作れば重複起動その時においては名前は被らないし
引数の受け渡しとか程度の話ならオープン失敗したら数秒待って開き直せばいつか開けるだろ
書いてる間はどうせ読めても無意味なんだし
0564デフォルトの名無しさん
垢版 |
2023/03/15(水) 00:41:23.71ID:q5LCzWGQ
>>560
いや、ゴミファイルが出来る事があり得ないけどね…
その多重起動というのがどういうものか知らんけど、GetTempFileNameで上手く行かないのは、プログラムが悪いと断言できる
ま、これで駄目なら何やっても上手く行かないだろうね
0566デフォルトの名無しさん
垢版 |
2023/03/15(水) 01:02:47.82ID:fvrt0a3X
>>565
それで遊んでみようと思ったのだけど何を使用していたのかわからないなら遊べないな残念
0567デフォルトの名無しさん
垢版 |
2023/03/23(木) 01:09:16.30ID:Ao+X9Xng
>>490
正確にはMFCはMS-DOSの開発ライブラリ

だからGUIのWindowsとうまく噛み合わなかった
0568デフォルトの名無しさん
垢版 |
2023/03/23(木) 06:12:16.80ID:5IP8ya+9
Ruby では普通、外部コマンド・子プロセスの終了を待つから、実行順序は書いた順。
Process.#wait

一方、Kernel.#spawn は、終了を待たない。起動しっ放し

IO にはパイプ、ブロッキング/ノンブロッキング、同期/非同期もある
0570デフォルトの名無しさん
垢版 |
2023/03/23(木) 08:33:51.91ID:ffpb/acK
>>567
コマンドベースの開発ライブラリならSDKだろ
MFCはGUIが前提のクラスライブラリとアプリケーション構築のプラットフォームをセットにしてWin32APIをラップしたもの
0571デフォルトの名無しさん
垢版 |
2023/03/23(木) 11:05:08.93ID:AQHpwrnP
>>567
これはひどい

そんなの関係ねぇ
GUIのWindowsとうまく噛み合わなかったのは
MSVCの開発陣がC++への理解が足りなかったから
0574デフォルトの名無しさん
垢版 |
2023/03/24(金) 01:24:11.23ID:gu0zjHdj
インストーラーの無い野良EXEのAUMID(Application User Model ID)をOSに登録する方法教えてください
0575デフォルトの名無しさん
垢版 |
2023/04/03(月) 14:17:49.75ID:ZOqVhNfC
>>570
Microsoft Cがいつからあるのか知らないのか。

MFCにはGUI限定などという定義はない。

そもそもMFCはCUIのライブラリから始まっている。
0576デフォルトの名無しさん
垢版 |
2023/04/03(月) 14:20:45.40ID:ZOqVhNfC
>>570
SDKの意味すらわかってねえのか？

あんたのいうMFCは、Windows SDKが扱うWin32APIをさらにラッピングしたMFCのことだ。

あんたの言っていることは滅茶苦茶だ。
0577デフォルトの名無しさん
垢版 |
2023/04/03(月) 14:34:38.52ID:ZOqVhNfC
>>571
どうでもいいけど、マイクロソフト内でC言語とC++の混在そのものに悩んでいたのも知らないようだな

マイクロソフトはC言語派、C++派、Windowsを普及させるためにVB流用派と、試行錯誤を繰り返していた時代にMFCが誕生したと思っているなら、時期がずれていてリアルタイムでは知らなかったと言っているようなもの
0578デフォルトの名無しさん
垢版 |
2023/04/03(月) 15:01:56.44ID:amgtJnTb
MS-DOS の頃ってMSのコンパイラは統合環境だった？
C++ どころか Cコンパイラで コマンドライン上から nmake 叩いてわ
0580デフォルトの名無しさん
垢版 |
2023/04/03(月) 15:10:57.50ID:ZOqVhNfC
ウィキペディアの説明が、Microsoft C 7.0以前の話がないせいで、Microsoft CとVisual C++の区別がついていないのね。

Windows 95、98の時代は、MS-DOS 6.2とWindows 95・98(内部MS-DOS 7.0・7.1)の併存期間で、MFCはMS-DOS 6.2をターゲットとしたものと、Windows 95をターゲットとしたものがある。

まず俗称「MSVC」と呼ばれるものは、Windows 95アプリケーションの開発を意識したもので、マイクロソフト「VC」と言っているあたりからわかるようにC言語でのWindows 95アプリケーションの開発を主としている。

ここでC言語からC++の移行をマイクロソフトはやろうとして、Windows APIがオブジェクト指向ではないところで無理が生じた。

そこでMFCを大幅に強化することでC++でのアプリケーション開発をしてもらおうとしたが、すでにWindows SDKの開発の知識がある開発者は、Windows SDKでのCでもC++よいというのに慣れていて、MFCを使えというのは、それまでの知識と違っており、無駄なクラスライブラリとしか思えなかった。

MFCはWindows 3.1でも影が薄い。マルチタスクではないと言えてしまうWindowsでは、MFCのメリットなどなく、無駄にサイズが大きくて重いコードが作られるため、性能、スペックの低いパソコンではMFCを使う理由がなかった。

MFCはGUIだけで使われるものではないため、CUI環境の開発でも使われている。

MFCどころかWindows 32APIでも、画面がある前提になっているコードを書かないといけないが、実際には画面がないものを作るのにも使われる。

MFC、Visual C++、Windows SDKの話がごっちゃになって、MFCを使うにはVisual C++でMFCを利用して、MFCがWindows SDKとセットだと認識できない点は理解できる。

まあ、ウィキペディアの記事は、根拠不明の創作が多いとわかってないとだまされるよな。
0581デフォルトの名無しさん
垢版 |
2023/04/03(月) 15:18:50.66ID:lsCbs8KW
Win32がオブジェクト指向ではないって？
ハンドルを使う関数（つまり大半）はオブジェクト指向だと思うが

もしかしてオブジェクト指向とはC++やSmalltalkを使うことだと思ってるのか？
0582デフォルトの名無しさん
垢版 |
2023/04/03(月) 15:19:55.66ID:ZOqVhNfC
>>578
統合開発環境と何の関係があるのか？

Windows 95アプリケーションでも、統合開発環境は必須ではない。

画面のデザインのときだけ利用するという使い方が多かった。

Direct Xが普通に使われるようになってからは、統合開発環境は画面ごと吹っ飛ぶので、統合開発環境そのものも動かないこともあるし、統合開発環境を自分が作ったもので壊すことがあるから、Windows 95、98系では、Visual製品に期待しても、Visual統合開発環境とWindows OSのポンコツコンボは、いま思っているより意味をなしていなかったんだよ。
0583デフォルトの名無しさん
垢版 |
2023/04/03(月) 15:25:54.31ID:amgtJnTb
>>582
MFC=マクロ出力とセットになった統合環境前提って印象だったものでね
リソース周辺のアレ
0584デフォルトの名無しさん
垢版 |
2023/04/03(月) 15:26:39.12ID:p7oapVPk
>>581
そこで使われるオブジェクトとオブジェクト指向とは関係ない
アセンブラのオブジェクトファイルと同様だ
0585デフォルトの名無しさん
垢版 |
2023/04/03(月) 15:28:25.60ID:ZOqVhNfC
>>581
オブジェクト指向設計ではなかったんだよ。

C言語とC++は書き方が少し異なるだけだったので、Windows SDKではC++で書くとオブジェクト指向っぽくなり、C言語で書くとこれでいいのかという書き方で、Windows 95のアプリケーションが作れた。

ここはWindows SDKがオブジェクト指向ではないという理由がある。

APIそのものはオブジェクト指向ではなかったので、オブジェクト指向にするにはMFCを挟むという変なことをすることをしていた人間もいる。

たった数年で変わった話なので、過渡期を知らないと誤解が生じるのはわかる。　
0587デフォルトの名無しさん
垢版 |
2023/04/03(月) 15:39:17.90ID:lsCbs8KW
すまん関数名間違えた
SelectObject()だ

GetObject()はオブジェクト指向と手続き型の切り替えだね
0588デフォルトの名無しさん
垢版 |
2023/04/03(月) 15:56:54.48ID:ORXHufFt
Win32APIの基本構造そのものがイベントドリブンのメッセージ駆動なのでオブジェクト指向を土台にしている
Windowsのマルチタスクはオブジェクト指向で成り立っているだろ
0590デフォルトの名無しさん
垢版 |
2023/04/03(月) 16:48:57.33ID:WoF7SnyS
>>575
>そもそもMFCはCUIのライブラリから始まっている。

doubt
0594デフォルトの名無しさん
垢版 |
2023/04/03(月) 16:58:53.51ID:WoF7SnyS
>>585
むしろ Win(32以前も)API / Win32API がオブジェクト指向で
MFC の方がオブジェクト指向出来ていなかったんだよ
だから判ってる香具師はみんな MFC は使わなかった
使ってたのは馬鹿だけ
0595デフォルトの名無しさん
垢版 |
2023/04/03(月) 17:23:19.13ID:aHgelLEB
>>594
APIについてはその通りだが
MFCがOOPでないという主張には
賛成しかねる

下手なところがあるのは俺も認めるが
原理主義者の言いなりである必要はない
0596デフォルトの名無しさん
垢版 |
2023/04/03(月) 18:20:11.47ID:6F7Nd+C2
MFCとかけて、C＋＋と解きます
その心は、オブジェクト指向ではあるけど、なりきれていない

これでどうでっしゃろ
0599デフォルトの名無しさん
垢版 |
2023/04/03(月) 21:57:09.76ID:pspdaLIR
GUIの無い単純なアプリならまだしも、それなりのGUIを持つアプリは
MFCを使ったほうが楽にアプリを作れるし、出来たコードも読み易い

確かに最初はMFCは取っ付き難いから、そこで挫折した人が
>>590-594みたいな事を言い出すんだろうなあ
0600デフォルトの名無しさん
垢版 |
2023/04/03(月) 23:21:42.85ID:6c3bFFXO
>>599
そんなことは無いと思うが
Win32APIをちゃんと知っていればMFCなんて使う理由が全く無いし
MFC関連のDLL何かも入れないといけないし単に開発効率がおちるだけ
実際当時Windowsアプリの仕事を結構やったけどMFCを採用していた所は少なかった
たまたまそういう場所ばかり行ってた可能性はあるがMFC何て使うなよって当時から思ってたよｗ
0601デフォルトの名無しさん
垢版 |
2023/04/03(月) 23:43:57.61ID:hWVK11qf
でも世の中的に勝利したのはMFCだよね
俺もATL/WTLでいいじゃんとは思ったけど
でかいライブラリも整備されてりゃそれなりに便利だからね仕方ないね

>>578
PersonalWorkBenchってのでFortranやったような気がするんだが
今ググっても全然出てこないな
0603デフォルトの名無しさん
垢版 |
2023/04/04(火) 06:32:29.81ID:sHU2LbpJ
>>600
＞Win32APIをちゃんと知っていればMFCなんて使う理由が全く無いし
WindowProcに case WM_… をだらだら書かなくても済むだけでも大きな利点
＞MFC関連のDLL何かも入れないといけない
ユーザー層やアプリの配布形態に応じて、必要ならMFCをStaticLibraryでリンクしてしまえば良い

>>602
＞VB→.NET の流れ
社内ツールとかならともかく、それこそユーザーにVＢ入れさせるなんて問題外でしょ
大量のデータ処置を行うようなアプリでは処理速度も遅いし
一般販売されてるアプリでVBで作られてるものなんてある？
0605デフォルトの名無しさん
垢版 |
2023/04/04(火) 07:35:33.06ID:GxsMOWHT
>>600
>MFC関連のDLL何かも入れないといけないし単に開発効率がおちるだけ

昔Win32+CだけでDLLの追加が要らないよう頑張ってみたこともあるけど辛かったね。
C++の機能使ってしまうと結局CランタイムDLLが必要になるし。
0606デフォルトの名無しさん
垢版 |
2023/04/04(火) 10:14:15.35ID:OZYsYc62
>>601
だよな
8086しかりwindowsしかりMFCしかり
技術的に劣っていてもデファクトになると
好むと好まざるに依らずそれ関係の仕事が来る

元々BSD使いだった俺がwindowsに転向したのもメシのため
0612デフォルトの名無しさん
垢版 |
2023/04/18(火) 08:15:18.90ID:F395+kgU
Windows API インデックス
https://learn.microsoft.com/ja-jp/windows/win32/apiindex/windows-api-list

Windows API を使用すると、各バージョンに固有の機能を利用しながら、すべてのバージョンの Windows で正常に実行されるアプリケーションを開発できます。
(これは以前は Win32 API と呼ばれていたことに注意してください。
Windows API という名前は、16 ビット Windows でのルートと 64 ビット Windows でのサポートをより正確に反映しています)。
0614デフォルトの名無しさん
垢版 |
2023/04/26(水) 20:51:37.42ID:A/LukVPn
Windows11でPrintDlg使って印刷すると1度目は印刷できるけど
2度目はPrintDlg()呼ぶと反応無しになるのはなんか間違ってるのかな
レジストリ弄ってLegacyなダイアログにしとくと印刷できる、あと管理者権限でプログラム実行して
印刷も勝手にLegacyなダイアログになるので印刷できるんだけど

試しに、VC2022で新規プロジェクトで雛形ちょっと弄って試してもやっぱり
2度目のPrintDlg()呼び出しで無反応になっちゃうんだっけど
debuggerで見てもPrintDlg()呼び出しでエラーも何も出てこなくてわからない
0616デフォルトの名無しさん
垢版 |
2023/04/28(金) 10:51:05.85ID:pksuSfee
閉じてから印刷
0618蟻人間 ◆T6xkBnTXz7B0
垢版 |
2023/04/30(日) 19:59:15.10ID:Aup++SJD
Microsoftの直接的な関係者ではなく、TSF (Text Services Framework)の仕組みを知り尽くしている人を募集中。成功報酬あり。
katayama.hirofumi.mz@gmail.com
0619デフォルトの名無しさん
垢版 |
2023/04/30(日) 20:06:36.85ID:/hwg+Moy
Firefoxのにゃるるにコンタクトすれば？
あと成功報酬ではなく労働報酬あるいはコンサルタント報酬であるべきだよ
0621デフォルトの名無しさん
垢版 |
2023/04/30(日) 21:19:58.80ID:8kv4t+8E
書き込めなかった、ローマ字で検索して
にゃるる が地球にいたころ

って言うか自分で勉強検索してたら最も頻繁に出てくる
0625デフォルトの名無しさん
垢版 |
2023/05/02(火) 21:18:50.29ID:koHs32mY
WaitOnAddressってアドレスの値が比較対象と違う値に変化したら自動的に起きるっていう魔法みたいなものではないんだね
呼んだ瞬間に比較対象と違ったら即返る、同じだったら後ほど変わったとしてもWakeByAddress系で通知しなきゃ起きないっていう原始的なイベントと言うほど変わらない感じか
0627デフォルトの名無しさん
垢版 |
2023/05/03(水) 20:05:13.46ID:v7V26Uwz
>>626
その挙動は既にWaitOnAddressに組み込まれてる訳だけど
対象アドレスの値が変わったら通知とか無しに自動的に戻ることを期待していた
そうじゃなくてマニュアルでWakeByAddress呼ばなきゃいけないからイベントとそこまで変わらんなぁと
まあハンドル作らずに済む点で手軽ではあるけど
0631デフォルトの名無しさん
垢版 |
2023/05/03(水) 21:36:14.09ID:+bgC2i5O
>>630
ウィンドウ表示するコードはこれだけ

#include <windows.h>
#include <winrt/Microsoft.UI.Xaml.h>

using namespace winrt;
using namespace Microsoft::UI::Xaml;

int WINAPI wWinMain(HINSTANCE, HINSTANCE, LPWSTR, int)
{
init_apartment();
Application::Start([](auto&&) { Application(); Window window; window.Activate(); });
return 0;
}
0632デフォルトの名無しさん
垢版 |
2023/05/04(木) 00:16:09.16ID:4Uvo6CUb
ラッパー系は手をつけにくいなあ、MFCやOWLの悪夢が蘇る
便利そうに見えて、覚えることが増えるだけだったり
見えざる制約が足枷になったり、バージョン管理が面倒だったりと
やむを得ない場合は仕方ないけど
0633デフォルトの名無しさん
垢版 |
2023/05/04(木) 00:34:52.44ID:qlZGMdPb
WinRTってMS的にはWin32と同列の扱いだけど、WinRTは内部でWin32を使ってるのだろうか？
0634デフォルトの名無しさん
垢版 |
2023/05/04(木) 05:10:21.07ID:P5ZkmciJ
COMを焼き直して名前変えただけと言えばいいのか
ただCOMの利点だったIDispatchで適当な言語から扱うみたいな事ができないうんこです
0636デフォルトの名無しさん
垢版 |
2023/05/04(木) 07:33:59.15ID:Nm4VxhU5
WinRTはC#の情報ばかりでC++の情報が少ないから苦労するかも
その点Win32は情報が多いからいいね
0637デフォルトの名無しさん
垢版 |
2023/05/06(土) 10:58:22.01ID:SadRj80b
>>628
WaitOnAddressは利便性目的ではなく手軽さ+パフォーマンスが要点だからそうとも言えない
Thread立ち上げて立ち上げたスレッドがある地点まで到達するまで待ちたいみたいなちょっとしたシーンでは結構便利
パフォーマンス的にもイベント待ちに比べて1000倍近く早かったはず
0638デフォルトの名無しさん
垢版 |
2023/05/11(木) 18:47:03.56ID:FTM2vWjW
Chromeのタイトルバーに「^」の文字を上下反転させたボタンがあって押すとミニウィンドウ的なのが開くのですが、このボタンを実装したいのですがどうしたらできますか？
Chromiumのソースコード見てもどこに該当コードがあるかわかりませんでした
c言語で実装したいです
0640デフォルトの名無しさん
垢版 |
2023/05/11(木) 19:52:12.33ID:FTM2vWjW
検索してみました
ttps://github.com/search?q=repo%3Achromium%2Fchromium%20tab%20search&type=code
タブを開いた時の挙動などはTypescriptで書かれているようでした
ttps://github.com/chromium/chromium/blob/cd5fe35a69d697dd48ad34d5670d090afcdc57be/chrome/browser/resources/tab_search/app.ts#L560
既存のアプリにc/c++で手軽にタイトルバーにボタンをつけてポップアップウィンドウが開けてそこでボタンなどを選択できるような方法を知っていますか？
0642デフォルトの名無しさん
垢版 |
2023/05/16(火) 23:21:04.68ID:bBMeTJtZ
LoadLibraryに渡されたlpLibFileName引数をどうにか呼ばれたdllmainから取得する事って出来ないかな
32bitならスタックフレーム遡ってLdrLoadDllを呼んだところの第3引数のスタックのUNICODE_STRINGから手に入れる事に成功したが
64bitだとfastcallになっちゃって第4引数まではレジスタ渡しされるからこの手法も通用しなくて詰んだ
kernel32やntdllのアセンブラ決め打って取得することは出来るだろうけどそこまではしたくない
0643デフォルトの名無しさん
垢版 |
2023/05/16(火) 23:26:32.45ID:bBMeTJtZ
ちなみになぜGetModuleFileNameではダメかというとハードリンクやシンボリックリンクのときにある条件下においてlpLibFileNameとGetModuleFileNameで一致しないケースが出てくるため
0644デフォルトの名無しさん
垢版 |
2023/05/17(水) 01:27:34.09ID:LUtEOwg/
>>643
その >ある条件下 で

TCHAR PathBuffer[BUFFSIZE];
GetMappedFileName (GetCurrentProcess(), (void *)hModule_DLL, PathBuffer, BUFFSIZE);
で、lpLibFileNameと同じパス(NT形式)が返ってくる？それともエラー？

試してないので結果を教えて
0645デフォルトの名無しさん
垢版 |
2023/05/17(水) 09:18:00.69ID:J+vPZ/2W
>>644
GetMappedFileNameだとリンク先の実体ファイル名が返ってきた
ある条件下というのは既に同じリンク先のdllがロード済みの場合に違う名前のリンクからロードしようとすると同一の物と判定され先客の方のhModuleが帰ってくるためGetModuleFileNameも先にロードしたほうの名前になる
C:\mod.dll ← 実体
C:\link0.dll ← シンボリックリンク
C:\link1.dll ← シンボリックリンク

最初にC:\link0.dllをLoadLibraryした場合、以降C:\link1.dllをロードしGetModuleFileNameをしてもC:\link0.dllが帰ってくる
GetMappedFileNameだと常にC:\mod.dllだった
0646644
垢版 |
2023/05/17(水) 10:25:43.22ID:fHvb3D7j
>>645
確認ありがとう、参考になった
こみ入った環境なんだね
所望の動作でなくて残念だけど、他の手段に心当たりがない...
0648デフォルトの名無しさん
垢版 |
2023/05/18(木) 12:21:08.02ID:Wn2vmhFl
load されたときの名前からパラメータ参照ファイルな .ini ファイルの名を変えたいって感じなのかな？

>>645 のケースだと
C:\link0.dll　でロードした場合には C:\link0.ini を参照し
以降 C:\link1.dllをロードした場合には C:\link1.ini を参照したい　と
この場合　単に同じ実体でリンクカウントが１増えるだけであっても区別したい　ということか
0649デフォルトの名無しさん
垢版 |
2023/05/18(木) 12:49:23.99ID:gc1pBp/r
DLLはメモリに直接ロードする方法もあるから
不正を正したいって意図なら無力だよ
0650デフォルトの名無しさん
垢版 |
2023/05/18(木) 23:43:11.96ID:qdON7ber
1. FindFirstFileでリンクか実体かを判定
2. VirtualAllocExで実行可領域のメモリを確保
3. ReadFileでDLLを読み込む
4. PEヘッダのIMAGE_OPTIONAL_HEADER64.ImageBase+IMAGE_SECTION_HEADER.VirtualAddressに各セクションをコピー
5. DLL内のImportLibraryを同じ手順で再帰的にロード
6. DLL_PROCESS_ATTACHとDLL_THREAD_ATTACHでDllMain呼び出し
0651デフォルトの名無しさん
垢版 |
2023/05/19(金) 14:28:26.73ID:FHSnxikS
Win32APIのGUIに著作権ってある？
自分用ならまぁ好きにしたらって程度だと思うけど
ボタンとか目コピで丸パクリしてアプリケーションとして配布したらダメなのかな
0652デフォルトの名無しさん
垢版 |
2023/05/19(金) 14:50:21.97ID:D8eITJ2Q
腐ったバナナの皮ですらアートとして認められるからな
許諾なしなら著作持ってる奴次第
新着レスの表示
レスを投稿する

ニューススポーツなんでも実況