アセンブラでWindowsAPI

質問

アセンブラだけでWindowsAPIを叩いてウインドウを表示させることはできるのでしょうか。C言語で普通にできるので、相当複雑になるとは思いますが、当然アセンブラでもできると思います。C言語だと変数の型の名前なども変な名前がいろいろ付いていて裏で何をやっているのかさっぱりわかりません。普通に使う分には問題ないのですが、ブラックボックスのような感じで気持ち悪いのです。どのような命令でAPIが呼び出されているのかCPUレベルで知りたいです。C言語の呼び出し規約ということで、MS-DOSのシステムコールみたいなものとは違うと思うのですが、どうなのでしょうか。

回答No.6

MrBan · ベストアンサー

> アセンブラだけでWindowsAPIを叩いてウインドウを表示させることはできるのでしょうか。

可能です。MS-DOSでは直接int命令を発行しますが、
Windowsはstdcall規約で関数をcallするだけですから他の関数と大差ありません。

コンパイラでCソースのアセンブリリストが出せると思いますので、ご覧になってみればいかがでしょうか。

> C言語だと変数の型の名前なども変な名前がいろいろ付いていて
> 裏で何をやっているのかさっぱりわかりません。

補足等読んでいる限り、アセンブリ云々では多分解決しないと思いますが。
型名を独自に定義しているのは裏で何をやっているかをブラックボックスにして、
もっと抽象度を上げようとしているのであって、わざわざ隠そうとしているものです。
C言語より抽象度が下がれば理解できるという考えはずれているように思います。(後述)

> __stdcall → WINAPI
例えばこの記述は、「呼び出し規約」ではなく「意味役割」に抽象度をあげています。
つまり、Windowsでのコールバックされる関数を示すのがWINAPIであって、
単に__stdcallと書くこととは意味的に等価ではありませんし、可読性や検索性も違います。
# ついでに書けば、__stdcall自体もコンパイラ独自であって、C/C++の言語仕様では規定してませんので、常に動く保証がありません。

> char* → LPSTR
これも、(ゼロ終端の)文字列を示すことを暗示しており、char*より抽象度があがります。
例えばLPBYTEとは意味的に区別して使われていますし、また、
LPTSTRになると、UNICODE(WCS)とMBCSの切り替えにも意味を持ちます。

> unsigned int → UINT
Win16時代のintとWin32時代のintの差異吸収という意味での抽象度上げでしょう。
C言語の仕様上、マルチプラットフォームを意識した開発ではよく見る手法です。

他の型も、抽象度アップや統一感維持のためにそうなっています。
「わざわざブラックボックスにする」ために定義されているものですから、
本来はあまり気にしなくていいお話ですが、知りたい局面も確かにあります。
ただ、それはアセンブリよりもwindows.h中の(C言語の)定義を見るべきでは？

> WinMainの宣言も、

「Windowsの規約」を無視すれば、HINSTANCEもvoid*と書けなくはないです。
# 但し、これはSTRICTの有無で実際の型が変わって通らなくなりますし、普通はそんなことしませんが。

> 単なる書き方の好みの問題とは考えづらいです。

型名に意味/付加情報を与えて抽象度を上げるためであって、好みではないでしょう。

> このような何バイトの情報なのかもよくわからない型名が余計に処理をブラックボックス化させている気もします。

ブラックボックスにするためのものなので、多分そうだと思いますが、
それは意図的なものですし、別に混乱を誘っているわけでもありません。

Windowsの規約に従う処理は、Windowsの型を使うべきであり、
C/C++ネイティブの型と安易に混ぜて使うべきではありません。
Win16⇒Win32や⇒Win64の移行などをやってみれば分かります。

補足

ありがとうございました。わざわざブラックボックスにしている訳ですね。
確かにUnicodeの切り替えなどでは必要なものだとは思います。
でもやはりMS-DOSのプログラミングをやっていた人がいきなりWindowsをやると混乱しそうです。

回答No.5

iriyak

こんにちは。

私も、先達の残してくれたドキュメントを手がかりに、ブラックボックスにぶつかっていっています。後は msdn library でしょうか。

光成さん
x86アセンブリ言語入門
http://homepage1.nifty.com/herumi/prog/prog.html
x64 アセンブリ言語プログラミング
http://homepage1.nifty.com/herumi/prog/x64.html

Jun Mizutaniさん
Linux でアセンブリプログラミング
http://www.nk.rim.or.jp/~jun/lxasm/asm00.html

msdn library
http://msdn.microsoft.com/en-us/library/default.aspx
ご参考まで。

お礼

ありがとうございます。参考になりました。

回答No.4

lv4u

>>いえ、ハンガリー記法ではなく、
Windowsプログラミングでは、
__stdcall → WINAPI
char* → LPSTR
unsigned int → UINT
というように普通の型名を別の(Windowsプログラム用？)型名で置き換えていますよね。

それのことですか？そういうコーディングは、Windowsに限らずUnixのソースでも目にしますね。できるだけソースコードの抽象度を上げて、32,64Bitのビット数の違いとかコンパイラ間での相違を受けず、移植性を高めるためみたいです。

たとえば、共通のinclude file内で

#ifdef A_CPU
typedef unsigned int UINT;
#else
typedef unsigned long UINT;
#endif

なんて記述をするとか、最初からinclude fileを環境ごとに切り替えるってことをするようです。
以前読んだ１００以上もの環境に移植されているという商用データベースのソースコードも、そういう書き方になっていました。

お礼

ありがとうございます。移植性を上げたり、わざとブラックボックス化(抽象化)しているのですね。

回答No.3

64ema

直接な回答ではありませんが、下記のHPの書籍に掲載されています。
http://book.mycom.co.jp/book/4-8399-1718-3/4-8399-1718-3.shtml

お礼

ありがとうございます。詳しく調べるにはよさそうで、なかなか興味深そうな内容でした。

回答No.2

lv4u

>>C言語のWindowsプログラムでは、やたらと大文字の長い型名やトークンを使用しますが、構造体の名前でもないただの unsigned intやvoid *などの一般的な型名や__stdcallなどをあんなにわかりにくいものに置き換えてしまうのでしょうか。

タイプ型のハンガリアン記法のことでしょうか？以下にあるように、現時点では、それは「誤った有害な命名方法」と評価されてマイクロソフトでも使用を禁止しているようですよ。

http://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%B3%E3%82%AC%E3%83%AA%E3%82%A2%E3%83%B3%E8%A8%98%E6%B3%95

でも、「過去の遺産」のソースを引きついで利用するとき、それまでの命名法を崩すのも、それはそれで問題になるので、現時点で禁止されていても、そのままの流儀でいっているのでしょうね。

補足

いえ、ハンガリー記法ではなく、
Windowsプログラミングでは、
__stdcall → WINAPI
char* → LPSTR
unsigned int → UINT
というように普通の型名を別の(Windowsプログラム用？)型名で置き換えていますよね。
WinMainの宣言も、
int __stdcall WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance, char* lpCmdLine, int nShowCmd)
という風に、LPSTRやWINAPIを使わなくても書けるならこう書けばいいと思うのですが、なぜ実際はLPSTRやWINAPIといったキーワードを使用するのでしょうか。単なる書き方の好みの問題とは考えづらいです。このような何バイトの情報なのかもよくわからない型名が余計に処理をブラックボックス化させている気もします。

回答No.1

aigaion

かな～りコアなお話ですね

本気でやるとすごく長くなるのでこのあたりの記事を読んで雰囲気をつかんでみては？
http://codezine.jp/a/article/aid/420.aspx

補足

ありがとうございます。そもそもWindowsAPIはDLLを呼び出してると思うのですが、アセンブラからDLLを読み込みその関数を呼び出すという操作が特に気になります。
もうひとつ聞きたいこととして、C言語のWindowsプログラムでは、やたらと大文字の長い型名やトークンを使用しますが、構造体の名前でもないただのunsigned intやvoid *などの一般的な型名や__stdcallなどをあんなにわかりにくいものに置き換えてしまうのでしょうか。新しい型が出てくるたびに正体が何なのか気になって仕方がありません。