Win32API質問箱 Build123©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
Win32APIについての質問はこちらへどうぞ。
■注意
・質問する前にMSDNライブラリやPlatformSDK、Google等で検索しましょう。
・日本語版MSDN Online Libraryは不完全です。
英語版( http://msdn.microsoft.com/en-us/library/ )の利用推奨。
・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。
・言語特有の問題やIDE、MFCやVCLなどの質問はそれぞれの言語や開発環境スレで
■過去スレ
Win32API質問箱 Build122
http://echo.2ch.net/test/read.cgi/tech/1451988219/ ウィンドウがわかるならIsHungAppWindowってのがある >>606
動画の変換みたいに純粋に時間がかかる場合とか、ユーザーのクリック待ちとかもあるから、判断はできんだろうな 止めようとしても停まらないもの?
WindowsUpdateかな? >>609
ネットワーク切れてからのタイムアウトも異常に遅いんだよな まだ見放されてないぞ
【IT】マイクロソフト、サポート切れOS「Windows 8、Windows XP、Windows Server 2003」にも修正ソフト提供
asahi.2ch.net
test/read.cgi/newsplus/1494723803 質問ささてください
構造体AをGlobalAllocで領域を確保して値を入れた後、構造体BをGlobalAllocで確保すると、構造体Aのメンバであるポインタのアドレスが変わってしまうのですが何が原因なのでしょうか? あるプロセスのメモリ情報のリージョンサイズや属性を調べるにはどのAPIを使えばいいですか? >>612
Windowsは働き者の賢いOSだからなぁ >>612
GlobalAllocじゃなくて自分で書き換えてるんでしょ >>612
GMEM_FIXEDを指定していないGlobalAllocでロックカウントが0の場合はメモリの再配置が起きる
GlobalLockとGlobalUnlockの間なら
「構造体Aのメンバであるポインタのアドレス」は変わることがないけど
GlobalUnlockを呼び出しロックを解除した場合は再配置される可能性がある 皆様レスありがとうございます
>>612
構造体BのGlobalAllocをコメントアウトすれば問題なく動くのでこれが原因なのはたぶん間違いないです
>>617
構造体A自体のLockやFIXは試しましたがダメでした。構造体Aは領域確保後にwinAPIに渡して値を格納してもらうのですが格納後にメンバ全ての固定が必要なのでしょうか?
ともあれメモリ再配置が原因なのですね。ありがとうございました。この方向でもう少し試してみます。 ソースコードにイージーミスがある可能性の方がクッソ高いと思う >>618
そもそもの使い方が間違っているんじゃないか?
>構造体Aは領域確保後にwinAPIに渡して
そのwinAPIは何?
というかなぜ隠す必要があるのか 構造体A、もしくはその近くのメモリ確保量が足りていないような気がする
スタック破壊、または、メモリ内容破壊では? すみません。自分がC++素人でメモリ周り疎いのでよくあるトラブルかなと思い、動作確認できている部分は抽象的に書きました。イージーミスの可能性はかなりあります。
ソースが手元にないのですが、具体的にはこのような処理をしています。スマホから書いたので文法ミスあるかもしれません。
メイン処理
DWOR count=0;
LPBYTE pStructA = (LPBYTE)GlobalAlloc(GHND,sizeof(0));
GetPrinterInfo(pStructA,&count);//自作関数 pStructAに構造体格納
/*ここでブレーク張ってpStructAのpNameのアドレスが正しい文字列指してるのは確認済み*/
PStructB pStructB = (PStructB)GlobalAlloc(GHND,sizeof(StructB)*count);
/*ここで改めてpNameを取得しようとするとpNameのアドレスがpStructBを確保する前と変わっている。元の文字列データは以前として前のアドレス上に存在してることは確認済み。pStructA自体のアドレスは変わっていない
*/
for(i=0 ;i<count;i++){
LPTSTR name= (((PRINTER_INFO_1*)pStructA)+count)->pName;
}
〜〜〜
自作関数 (動作確認済み)
DWORD GetPrinterInfo(LPBYTE pStructA, LPDWORD count){
DWORD result=0;
DWORD pNeeded=0;
//必要サイズ取得
EnumPrinter(PRINTER_ENUM_LOCAL,NULL,1,NULL,pdw
&pNeeded,count);
//必要サイズ再確保
Global ReAlloc(pStructA,pNeeded,GHND);
//ここでPRINTER_INFO_1構造体をpStructAに格納
EnumPrinter(PRINTER_ENUM_LOCAL,NULL,1,pStructA,pdw
pNeeded,count);
return result;
} GlobalAllocの戻り値のハンドルを直接キャストしてポインタに代入したら駄目だろ
ハンドルを引数としてGlobalLockを呼び出して、その戻り値をキャストしてポインタに代入しろ p = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size);
HeapFree(GetProcessHeap(), 0, p);
でうまくやってるよ,GlobalAlloc は win3.1 の仕様を下敷きにしているので使いにくいよ >>625
関数の仕様ぐらい確認しろといいたい
https://msdn.microsoft.com/ja-jp/library/cc430065.aspx
GMEM_FIXEDを指定していないGlobalAllocはメモリハンドルを返す
アドレスではなくハンドルであり、このハンドルをGlobalLockに渡すことでメモリアドレスを取得できる
メイン処理
DWORD count=0;
HGLOBAL gm = GlobalAlloc(GHND,sizeof(0));
GetPrinterInfo(gm,&count);
LPBYTE pStructA = (LPBYTE)GlobalLock(gm);
for(i=0 ;i<count;i++){
LPTSTR name= ((PRINTER_INFO_1*)pStructA)[i].pName;
}
〜〜〜
DWORD GetPrinterInfo(HGLOBAL gm, LPDWORD count){
DWORD dwSize;
DWORD result=0;
DWORD pNeeded=0;
EnumPrinter(PRINTER_ENUM_LOCAL,NULL,1,NULL,0,&pNeeded,count);
Global ReAlloc(gm,pNeeded,GHND);
dwSize = GlobalSize(gm);
LPBYTE pStructA = (LPBYTE)GlobalLock(gm);
EnumPrinter(PRINTER_ENUM_LOCAL,NULL,1,pStructA,dwSize,&pNeeded,count);
GlobalUnlock(gm);
return result;
} GMEM_MOVEABLE
移動可能メモリを割り当てます。Win32 環境では、物理メモリ内でメモリブロックが移動されることは決してありませんが、既定のヒープ内で移動することは可能です。
戻り値は、メモリオブジェクトのハンドルです。このハンドルをポインタへ変換するには、GlobalLock 関数を使います。
この値を GMEM_FIXED フラグと組み合わせることはできません。
Win32では移動することがないあるよって言ってるし、GPTRフラグを使うか、メモリ確保をmallocなりに置き換えたほうが良いね
EnumPrintersに渡すバッファのポインタは別になんでも良いみたいだし GlobalAllocはクリップボード弄る時くらいでいいよ こうゆう奴がプロジェクトにいると、デバックでは動くがリリースでは動かない
プログラムとか出来上がるんだろうな。。。
(もちろん、リリース+デバック情報埋込なら動く最悪のパターン) mallocでも、newでも好きなのつかったらいいんじゃね? みなさま本当にありがとうございました。
メモリ確保の方法に関しては古いのはなんとなくわかってるのですが、意見できる程知識がないのが実情です……
ともあれ解決方法の兆しが見えたので頑張ってみます。
>>634
耳が痛いですが自分も本当にそう思います……個人的には勉強になるのでいいんですが……
リリース気をつけておきます ※未承認広告※
Win32メッセージクラッカー簡単入力。
MsgCrack
https://github.com/katahiromz/MsgCrack 皆さんは、ダイアログの HWND に対し SetWindowLongPtr, GetWindowLongPtr を使用する場合
GWLP_USERDATA と DWLP_USER をどのように使い分けていますか? 使い分けもなにも
get してから & とか | とかして set してる エディットボックスにES_MULTILINEを付けると
Ctrl+Aですべて選択ができなくなってしまうのだけど、
これはなにか技術的な理由があってのことですか?
それとも、昔から修正されていないだけのバグですか? 642の追記ですが、ES_MULTILINEだけでなく、ES_READONLYを付けたときも、
同じようにCtrl+Aが効かなくなるようです。 >>644
つまり、ES_MULTILINEやES_READONLYはCtrl+Aに対応すべき状態ではない
というような技術的な理由があるわけではなく、
単にマイクロソフトが修正していない昔からのバグで、
サブクラス化などで対応しても問題ないものなんですよね? ctrl+aが全選択という統一ルールがないとかなんとか >>646
エディットボックスが常にCtrl+Aを扱っていないなら納得するんですが、
ES_MULTILINEやES_READONLYが付いているときだけ効かなくなるんです。 >>647
挙動としては認識通り
技術的な問題ではないのでサブクラスなりインスタンスなりのKeyDownイベントでSelectAll()して構わない
普通はついでにCopy()やCut()のショートカットキー処理もつけておく >>648
解説ありがとうございます。
エディットボックスの処理を信じずに、Ctrl+Aなどの動作を載せてしまいます。 CLIP STUDIO PAINTのようにツールっぽくする為にウインドウ全体を茶色に統一するようなWin32APIと言うのがありますでしょうか?
SKINかもしれないのですがSKINの仕方が解りません。
それとMediBang Paint Proのようにウインドウ全体でなくメニューとツールウインドウだけを茶色に統一する方法も
解りましたらお願いします。 >>652
ランサムだけなら誰でもできる。ランサムウェアと呼ぶから重要なことが抜けて伝わってしまう。 警察は実績が欲しく、子供は有名になりたかったらしいので
両者の思惑が一致した最高の形なんだろう >>654
重要なのはWindowsの穴をついてプログラムを実行できたところだからね。 穴ついてたのかよw
どうせこのbat実行してね、だろうと思ってたんだが違ったか エッチなビデオ.avi .bat
とかじゃないの? そういえば歴代OSの擬人化
みんな女の子だったよな
穴あって当然だな こないだの WannaCrypt ランサムの話なら SMB の穴だけど バッチファイルを書き換えられると危険が危ないと書いてある
朝日新聞の記事を読んだだけなのでよくわからないけど、
暗号化するプログラムをコピペで作ったんでしょう?
暗号化するバッチをコピペで作っただけなの?
どっちにせよ、穴は使ってない、ただのオナニーだった感じなんだが。 >>665
じゃあどうやってファイルを書き換えたんだよ? ランサムウェアよりも前に穴をつくマルウェアが出てきて、そのマルウェアを参考にしたのが、今回のランサムウェアだと思うが。 >>666
crypt.exe c:\windows\*.*
echo 暗号化しました金払え
こんな感じ。 >>670
nimdaで中学生逮捕って情報見つからん。ソースどっかある? いい加減にしろよ
引っ込みつかなくなった奴のマウント取って喜ぶような
小学生並みの神経してんのかお前は windows10のGDI描画をXP相当にするAPIは無いものかのう >>672
誰がnimdaで中学生逮捕なんて話をしてんだ?
脳みそ湧いてんの? >>675
visual style、runa style...いわゆる ThemeAPI の話?
なら、いわゆるスキンの類だと思うので API とか GDI とかの階層の話じゃないと思う。
カスタマイズでどうにかって話になるか、
ttps://www.japan-secure.com/entry/how_to_customize_the_windows_10_to_windows_xp.html
XP から theme.dll をぶっこ抜き・・・うーんワスレタ >>675
MFCとかを使っていいのなら、そういうライブラリは売ってるけどな。 >>675
GDIのAPI自体は変わってないと思うんだけど
Direct3Dを通さないで描画するとかならもう無理じゃね 自分のアプリだけならオーナードロー
OS全部なら方法わからん OS全体ならXP時代によくやってたtheme.dllの差し替えでいける・・・はずなんだが
XP時代でしか通用しない技なのかも知れんね なあに、グローバルフックすりゃなんとななるやろ(鼻ほじ どういうつもりでみんなGDI描画という言葉を使ってるのかわけわからんな GDI 描画と言えば FillRect とかの、HDC 用いるグラフィック描画で、
Windows 10 でも Windows 3.1 でも基本的に動作同じだよね。 >>692
違うよ
ルートウィンドウの扱いとかキャプチャしてみると違いが判る ウィンドウシステムの動作は GDI では規定されていないだろ。
以上、異論は無視する。 dwm.exe というデスクトップマネージャーのプロセスがGUI描画の番人になってるからXP再現は無理でしょ。 xpからファイル持ってきてosにぶちこむのができないからって
>>675ができないというわけじゃない Win10 SDK で作ると Windows 8.1 で動かないんだっけ? Win10SDKにまだ手を出していないんだけど、ようするに
Platform SDK、Windows SDK と思っていいんだよね? ■ このスレッドは過去ログ倉庫に格納されています