片鱗懐古のブログ: C# : 「64bitだとWindowFromPointが動かないよー」という過去の課題が見つかったのでちょいと調べる

自分用のツールを作ろうかと色々調べていたら過去の自分の投稿にたどり着きました。

過去の投稿 ...... .net framework : マウスカーソルの位置にあるウィンドウの情報を得る

「64bit環境でC#からWin32APIのWindowFromPointを呼び出すと失敗する」と書いてあります。「じゃあ今やろうとしている事できないの?」とさらに検索しようとしたら......WindowFromPointとテキストボックスに入れた時点でサジェッションに64bitとかx64とか出てくるんですよね。「もしかして未だに解決してない?」と思ったら最初の検索結果であっさり解決しました。

Stack Overflow ...... WindowFromPoint doesn't work correctly on 64bit .NET Framework

6年前のQ&Aじゃないか。曰く、「WindowFromPointの引数の型間違ってるよ。正しい型なら動きます」⇒ 確かに動きました。

最初はマーシャリングのためにこんな風に書いてたんですよね。引数をint型2つにしてました。

[DllImport("user32.dll")]
static extern IntPtr WindowFromPoint(int x, int y);

正しい引数は構造体でした。

[DllImport("user32.dll")]
static extern IntPtr WindowFromPoint(System.Drawing.Point p);

どちらも32bitの環境だと正常に動きます。でも64bitだとダメ。どうしてでしょう? 昔勉強した記憶を引っ張り出して考えてみました。

C++で関数を呼ぶとき、組み込み変数や構造体はスタック渡しなんですよね? 32bitで変数の型を間違えても動いていたのは、どちらも32bitの値x、yを同じ順番、同じ位置にスタックに積んでからコールしてるからなのでしょう。呼び出された側からしたら同じ受け取り方で引数を受け取れた。だから型を間違えても問題は無かった。でも64bitだと何かが変わったので動かなくなってしまった、と。

WindowFromPointの「問題」が出来てしまったのは昔の32bit時代の人が「動けばよかろう」とint2つで書いたコードが出回ったせいかな? 64bitのコンピュータが普及し始めたときに、過去の自分もそれを踏んで間違ったコードを書いてしまったのでしょう。

64bitでダメなのは変数のメモリ上のアライメントが原因でしょうね。確認せずにそう決め打って文章を書いて投稿しようとしたけど、思いとどまりました。簡単に確かめてみました。

用意したのはこのサンプルコード。 WindowFromPointの代わりに同じ引数を持ったfuncA、funcBを用意しました。

#include "pch.h"
#include <iostream>
#include <string>
#include <Windows.h>

int funcA(int x, int y)
{
    return x + y;
}

int funcB(POINT pt)
{
    return pt.x + pt.y;
}

int main()
{
    int x, y;

    x = funcA(1, 2);

    POINT pt;
    pt.x = 3;
    pt.y = 4;
    y = funcB(pt);

    std::cout << "x = " + std::to_string(x) + '\n';
    std::cout << "y = " + std::to_string(y) + '\n';
}

これをVisual C++で/FAオプションを付けて、x86をターゲットにしてコンパイル。 .asmのソースコードを吐かせます。もちろん最適化オプションは無しです。 C++なんて何年ぶりでしょう? プロトタイプ宣言とか忘れてました。

問題の関数呼び出し部分を抜粋すると......。

; Line 20
    push    2
    push    1
    call    ?funcA@@YAHHH@Z                ; funcA
    add    esp, 8
    mov    DWORD PTR _x$[ebp], eax
; Line 23
    mov    DWORD PTR _pt$[ebp], 3
; Line 24
    mov    DWORD PTR _pt$[ebp+4], 4
; Line 25
    mov    eax, DWORD PTR _pt$[ebp+4]
    push    eax
    mov    ecx, DWORD PTR _pt$[ebp]
    push    ecx
    call    ?funcB@@YAHUtagPOINT@@@Z        ; funcB
    add    esp, 8
    mov    DWORD PTR _y$[ebp], eax

C++の20行目に当たる部分が「; Line 20」です。 pushしているのが引数x、yにあたる数字ですね。 y、xの順に32bit値をpushしてからfuncAをcallしてます。

23行目、24行目に当たるコードで構造体に値を設定。 25行目で構造体のyに当たるメンバーをレジスタのeaxを経由してpush、xに当たるメンバーをecxを経由してpush。そしてfuncBをcall。呼び出された側から見れば、引数x、yを積んだ場合とPOINT構造体を積んだ場合に違いが無い事が分かります。ここまでは思った通り。

ではx64でも同様に。アセンブラの勉強をかじってた時に64bit環境とかありませんでした。どうなってるんでしょうね? とは言ってもアライメント違うだけでしょ……あれ? callの前にpushが無いぞ!?

; Line 20
    mov    edx, 2
    mov    ecx, 1
    call    ?funcA@@YAHHH@Z                ; funcA
    mov    DWORD PTR x$[rbp], eax
; Line 23
    mov    DWORD PTR pt$[rbp], 3
; Line 24
    mov    DWORD PTR pt$[rbp+4], 4
; Line 25
    mov    rcx, QWORD PTR pt$[rbp]
    call    ?funcB@@YAHUtagPOINT@@@Z        ; funcB
    mov    DWORD PTR y$[rbp], eax

どうやらx64だと引数がレジスタ渡しになってしまうようです。(←浦島) int型の引数2つだと32bitのレジスタ2つで値を渡しています。それに対してPOINT構造体はrcxという64bitのレジスタ1つで値を渡しています。え? 最適化オプション無しでもこんな事してくれるの?

なんだ、全然違うじゃないか。こりゃ動かんわ。そしてアライメントは全然関係ありませんでした。確認してよかった。

過去に解決できずにそのままになっていた事を解決できてスッキリしましたね。そして思い込みでものを書かない事の重要性を再認識。今回は勘違い未遂で済みました。

これで安心してWindowFromPointを使え……フリーソフトで済ませようかな?

片鱗懐古のブログ

2018年11月8日木曜日

C# : 「64bitだとWindowFromPointが動かないよー」という過去の課題が見つかったのでちょいと調べる

閲覧数が多い投稿

ラベル

広告

投稿した動画

ブログアーカイブ