コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

「Windows API」の版間の差分

出典: フリー百科事典『ウィキペディア(Wikipedia)』
削除された内容 追加された内容
Cewbot (会話 | 投稿記録)
m Bot作業依頼: sourceタグをsyntaxhighlightタグに置換 (Category:非推奨のsourceタグを使用しているページ) - log
171行目: 171行目:


具体的には、文字および文字列の関わる[[関数 (プログラミング)|関数]]・[[構造体]]について、マルチバイト文字(Windowsコードページに基づく、日本語環境であれば[[Microsoftコードページ932|コードページ932]])とUnicode (UTF-16) のどちらを与えることもできるように、2つの関数・構造体などが準備されている。その場合、マルチバイト文字列を与えるべき関数・構造体は末尾に「A」を付け、ワイド文字列を与えるべき関数・構造体は末尾に「W」を付けて区別している。例えば、Win16のMessageBox関数に対して、Win32ではMessageBoxAとMessageBoxWという2つの関数が用意されている。そして、プリプロセッサ識別子UNICODEの定義の有無によって切り替えが行われる。
具体的には、文字および文字列の関わる[[関数 (プログラミング)|関数]]・[[構造体]]について、マルチバイト文字(Windowsコードページに基づく、日本語環境であれば[[Microsoftコードページ932|コードページ932]])とUnicode (UTF-16) のどちらを与えることもできるように、2つの関数・構造体などが準備されている。その場合、マルチバイト文字列を与えるべき関数・構造体は末尾に「A」を付け、ワイド文字列を与えるべき関数・構造体は末尾に「W」を付けて区別している。例えば、Win16のMessageBox関数に対して、Win32ではMessageBoxAとMessageBoxWという2つの関数が用意されている。そして、プリプロセッサ識別子UNICODEの定義の有無によって切り替えが行われる。
<source lang="c">
<syntaxhighlight lang="c">
#ifdef UNICODE
#ifdef UNICODE
#define MessageBox MessageBoxW
#define MessageBox MessageBoxW
177行目: 177行目:
#define MessageBox MessageBoxA
#define MessageBox MessageBoxA
#endif
#endif
</syntaxhighlight>
</source>
さらに、文字型に対しても同様にCHAR (charのtypedef) とWCHAR (wchar_tのtypedef) をUNICODEの定義で切り替えるTCHAR型などや、ナロー文字列定数・リテラルとワイド文字列定数・リテラルを切り替えるTEXTマクロが存在する。
さらに、文字型に対しても同様にCHAR (charのtypedef) とWCHAR (wchar_tのtypedef) をUNICODEの定義で切り替えるTCHAR型などや、ナロー文字列定数・リテラルとワイド文字列定数・リテラルを切り替えるTEXTマクロが存在する。
<source lang="c">
<syntaxhighlight lang="c">
#ifdef UNICODE
#ifdef UNICODE
#define TEXT(s) L ## s
#define TEXT(s) L ## s
187行目: 187行目:
typedef CHAR TCHAR;
typedef CHAR TCHAR;
#endif
#endif
</syntaxhighlight>
</source>
これらを適切に用いると、1つのソースコードからコンパイル時のオプションによってマルチバイト文字を用いる実行プログラムとワイド文字を用いる実行プログラムの2種類が作成できる。以下はその例である。
これらを適切に用いると、1つのソースコードからコンパイル時のオプションによってマルチバイト文字を用いる実行プログラムとワイド文字を用いる実行プログラムの2種類が作成できる。以下はその例である。
<source lang="c">
<syntaxhighlight lang="c">
#include <windows.h>
#include <windows.h>
int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hInstPrev, LPSTR lpszCommandLine, int nCmdShow)
int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hInstPrev, LPSTR lpszCommandLine, int nCmdShow)
196行目: 196行目:
return 0;
return 0;
}
}
</syntaxhighlight>
</source>


なお、Windows NT系におけるA版のAPI関数は、Unicodeとの変換を行いW版を呼び出すラッパーとなっている<ref>{{Cite web|url=http://technet.microsoft.com/ja-jp/library/bb457045.aspx|title=Windows XP Professional の多言語オプションの比較|work=TechNetライブラリ|accessdate=2010-01-19}}</ref>。
なお、Windows NT系におけるA版のAPI関数は、Unicodeとの変換を行いW版を呼び出すラッパーとなっている<ref>{{Cite web|url=http://technet.microsoft.com/ja-jp/library/bb457045.aspx|title=Windows XP Professional の多言語オプションの比較|work=TechNetライブラリ|accessdate=2010-01-19}}</ref>。

2020年7月5日 (日) 22:44時点における版

Windows APIウィンドウズ エーピーアイ)とは、Microsoft WindowsシステムコールAPIのこと。特に32ビットプロセッサで動作するWindows 95以降やWindows NTで利用できるものはWin32 APIと呼ばれる。また、それらのWindowsにおけるWin32 APIの実装をWin32と呼ぶ。

概要

Windows上で動作するアプリケーションにとって、Windows APIはWindowsの各機能にアクセスするための接点である。そのため、Windows上で動作するアプリケーションを作成できる様々なプログラミング言語・開発環境においてWindows APIを使用する手段が提供されている。特にCとC++では、Windows SDKにより、<windows.h>をはじめとする多数のヘッダーファイルが公開されている。また、多くの開発環境で、Windows APIを基にしたより高水準のフレームワークが構築されている。これらを通じて、直接・間接にすべてのWindowsアプリケーションはWindows APIを使用している。

Windows APIに属する各APIは、主にDLLからの関数またはCOMインターフェイスとして機能を公開している。関数の呼出規約は原則としてstdcallを採用する (Win32の場合) など統一されたインターフェイスで多数のプログラミング言語からの使用を容易なものとしている。

分類

Windows APIの中核となる機能はKernel、User、GDIに分けられる[1]。当初は、それぞれKERNEL.EXE (モードによってはKRNL286.EXE、KRNL386.EXE)、USER.EXE、GDI.EXEに実装されていた。32ビット化されて以降は、KERNEL32.DLL、USER32.DLL、GDI32.DLLに実装されている。Windows 7の新カーネル、MinWinでは、"Virtual DLL"の仕組みが導入され、インターフェイス互換性を維持したうえで実装の整理が行なわれている[2] [3]

Kernel
ファイルシステムデバイスプロセススレッドレジストリ例外処理など基盤となる機能
User
ウィンドウの処理、ボタンやスクロールバーなどといった基本的なコントロール、マウス・キーボード入力、その他グラフィカルユーザーインターフェイス (GUI) に関わる機能。
GDI
ディスプレイ・プリンタをはじめとした出力装置への描画機能

現在では、これだけに留まらず、多数のDLLから無数の機能が公開されている。現在、マイクロソフトのドキュメントでは次のように分類している[4]

  • Administration and Management
  • Diagnostics
  • Graphics and Multimedia
  • Networking
  • Security
  • System Services
  • Windows User Interface

なお、この分類では、KernelはDiagnosticsとSystem ServicesそしてSecurityに跨って属し、UserはWindows User Interface、GDIはGraphics and Multimediaに属する。

グラフィックとマルチメディア

DirectX

マイクロソフトはWindows 95/Windows NT 4以降、全てのWindowsにDirectXを用意している。DirectXは主にゲームマルチメディアのためのAPIであるが、Windows Vista以降はDirectX GraphicsがGDIに代わってOSのグラフィックス描画の基盤として昇格されている。DirectX APIのうちのいくつかは、ゲームコンソールであるXboxXbox 360Xbox Oneと共通になっている。

Direct3D
OpenGLの置き換えとして3D グラフィックスアクセラレータの操作。
DirectDraw
2D グラフィックスアクセラレータの操作。DirectX 8.0以降、DirectDrawの機能はDirect3Dに吸収された。
DirectX Graphics
DirectX 8.0以降に導入された名称で、Direct3DおよびDirectDrawの統合を意味するものだったが[5]、DirectX 11以降はDXGI/Direct3D/Direct2D/DirectWrite/DirectCompositionの総称となっている[6]
DXGI (DirectX Graphics Infrastructure)
Direct3D 10以降、DirectX Graphicsから比較的変化の緩やかな部分はDXGIとしてDirect3Dから分離された。
Direct2D
Direct3D上に構築された高レベル2D描画用API。GDI+の置き換えとなる。
DirectWrite
テキストおよびフォント/フォントグリフを扱う。
DirectSound
低水準なハードウェア(主にサウンドカード)への操作。
DirectMusic英語版
DirectSoundの上位に位置し、音楽(メディアファイルの再生など)を扱う。
DirectX Audio
DirectX 8.0以降に導入された名称で、DirectSoundおよびDirectMusicの統合を意味するものだったが[7]、DirectX 9以降はX3DAudio/XAudio2/XACT/DirectSoundなどの総称となっている[8]
DirectInput
ジョイパッドやゲームパッドからの入力、およびフォースフィードバックを扱う。
XInput
Xbox 360コントローラーをWindows上で使えるようにするAPI。
DirectPlay英語版
ネットワークなどを介した通信。
DirectShow
汎用的なマルチメディアパイプラインシステム。

DirectX APIはWindows APIの中でも変化が激しいAPIのひとつで、Direct3D RM、DirectDraw、DirectSound、DirectInput、DirectPlay、およびDirectMusicはWindows Vista以降完全な互換機能が用意されず、一部を除いて廃止あるいは代替APIに吸収されている[9]

動画・音声

OpenGL

WGL英語版
OpenGLとWindows (GDI) との連携部分を担当するAPIである。各関数名は接頭辞wglで始まり、<wingdi.h>で宣言されている。なお、Windows SDKに付属するOpenGLヘッダーおよびライブラリにはOpenGL 1.1までの関数しか定義されておらず、したがってOpenGL 1.2以降の機能を使うためには、Khronosから最新のOpenGLヘッダーをダウンロードしたのち、WGLのwglGetProcAddress()関数を用いてハードウェアベンダーが提供するOpenGL ICD (Installable Client Driver) の関数エントリポイントをアプリケーション実行時に取得するなどの作業が必要となる[12]

ネットワーク・インターネット

コンポーネント技術

ネイティブAPI

ネイティブAPIは、Windows NT系においてWindows APIより下位層のAPIである。NT系では、NTネイティブAPI上にサブシステムとしてWin32 APIが実装されている。ただし、DirectXやGDIなどは、ネイティブAPIを介せずに、より下位に位置するカーネルと直接やり取りを行う。

.NET Frameworkとの関係

Windowsで動作する.NET Frameworkは、基本的にWin32 APIを用いて実装されている。例えばWindows FormsおよびWindows Presentation Foundation (WPF) はそれぞれGDI/GDI+あるいはDirect3Dを利用したGUIアプリケーションのフレームワークでり、Win32 APIとの相互運用性も確保されている。

かつて、「Windows Vista以降、WinFX (.NET Framework 3.0) がWindows APIに代わってネイティブAPIになる(WinFXが最も低水準なAPIとなりWindows APIはそのラッパーとなる)」とアナウンスされたことがあったが、結局撤回され、Windows Vista製品版では従来通りWindows APIがネイティブなAPIとなっている。

実装

Windows APIは名前からも類推できるとおり、主にMicrosoft Windowsに実装されている。その実装はWindowsのバージョン毎に少なからず違いが存在する。たとえばWin32の場合、Win32c、Win32sではごく一部を除きUnicodeに対応していない、セキュリティ対策のアクセス制限が実装されていないなどといった違いが挙げられる。そしてそれは大きく次のように分類することができる。

Win16

Win16は、16ビットプログラム用の実装である。ただし、Win16という語自体はWin32が登場してから用いられるようになったレトロニムである[13]。Win16は大きく2種類に分けられる。

  • Windows 1.0からWindows 3.1までおよびWindows 95/98/Me(9x系)の実装。
  • WOW (Windows on Windows): Windows NTによるWin16サブシステムによる実装。

Win32

Win32は、32ビットプログラム用の実装である。次のように分けられる。

Win32
狭義のWin32は、NT系の実装を指す。
Win32c
9x系の実装。'c'は「compatibility」(互換)の頭文字である。しかし、現在[いつ?]では9xの実装も区別なくWin32と呼ぶ[14]
Win32s
Windows 3.1用の実装。's'は「subset」(サブセット)の頭文字である。Windows 3.1には搭載されておらず、別途入手・インストールする必要がある。
Win32 for Windows CE[15]
Windows CEの実装。文字コードUnicodeのみを使用するなどの点が特徴的である。
WOW64 (Windows on Windows 64)
Win64上でWin32をエミュレーションするサブシステムによる実装。

Windows NTがx86以外のアーキテクチャに移植されたことに伴い、Win32は各種アーキテクチャ向けに移植されている[16]。また、Windows NTではないが、かつてMacintosh用のWin32も存在し、Microsoft Visual C++ 4.0 Cross-Development Edition for Macintoshとしてクロスコンパイラとともに発売されていた[17]。これらアーキテクチャの異なるWin32の間にはソースコード上での互換性がある。

Win64

Win64は、64ビットプログラム用の実装である。現在[いつ?]IA-64及びx64用の2種類の実装が存在する。Windows 10ではARM64の将来的なサポートが計画されている[18] [19]

WinRT

Windows 8で導入されたWindowsストアアプリ (Modern UIアプリケーション) を開発するためのCOM拡張による高レベルAPI。後継となるWindows 10で導入されたユニバーサルWindowsプラットフォーム (UWP) アプリケーションの開発におけるベースAPIにもなっている。

マイクロソフト以外による実装

Windows APIの仕様はWindows SDKのドキュメントやMSDN ライブラリで公開されており、それを基にしたMicrosoft Windows以外のWindows APIの実装が存在する。

詳細

Unicode対応

各Win32が実装しているAPI
Win 9x Win NT Win CE
A Yes Yes No
W 一部対応 Yes Yes

Windows NT系では当初からUnicodeが用いられている一方、Unicodeに対応していないWin16と互換性を取るために、Win32 APIから同じAPIに対してマルチバイト文字版とUnicode版の2つを用意し、C/C++のマクロを駆使してコンパイル時にどちらを使うか選択できる仕組みが採用されている[20]。なお、Unicodeの符号化には当初UCS-2、Windows 2000から正式にUTF-16が用いられている[21]

具体的には、文字および文字列の関わる関数構造体について、マルチバイト文字(Windowsコードページに基づく、日本語環境であればコードページ932)とUnicode (UTF-16) のどちらを与えることもできるように、2つの関数・構造体などが準備されている。その場合、マルチバイト文字列を与えるべき関数・構造体は末尾に「A」を付け、ワイド文字列を与えるべき関数・構造体は末尾に「W」を付けて区別している。例えば、Win16のMessageBox関数に対して、Win32ではMessageBoxAとMessageBoxWという2つの関数が用意されている。そして、プリプロセッサ識別子UNICODEの定義の有無によって切り替えが行われる。

#ifdef UNICODE
#define MessageBox MessageBoxW
#else
#define MessageBox MessageBoxA
#endif

さらに、文字型に対しても同様にCHAR (charのtypedef) とWCHAR (wchar_tのtypedef) をUNICODEの定義で切り替えるTCHAR型などや、ナロー文字列定数・リテラルとワイド文字列定数・リテラルを切り替えるTEXTマクロが存在する。

#ifdef UNICODE
#define TEXT(s) L ## s
typedef WCHAR TCHAR;
#else
#define TEXT(s) s
typedef CHAR TCHAR;
#endif

これらを適切に用いると、1つのソースコードからコンパイル時のオプションによってマルチバイト文字を用いる実行プログラムとワイド文字を用いる実行プログラムの2種類が作成できる。以下はその例である。

#include <windows.h>
int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hInstPrev, LPSTR lpszCommandLine, int nCmdShow)
{
    MessageBox(NULL, TEXT("Hello, world"), TEXT("App"), MB_OK);
    return 0;
}

なお、Windows NT系におけるA版のAPI関数は、Unicodeとの変換を行いW版を呼び出すラッパーとなっている[22]

このプレフィックスのAはANSI、WはWideを意味する[23]。ANSIは、Windowsコードページの一部がANSI規格のドラフトを元にしたことに由来する[24]ワイド文字 (wchar_t) はC/C++の用語であるが、Windows用のC/C++処理系において、ワイド文字は大抵UCS-2またはUTF-16として実装されている。また、OLE関係では、Win32ですべてUnicode化され、A/Wの区別が存在しない。

なお、Windows 9x系では、Unicode版APIは一部しか実装されていない[25]。ただし、Microsoft Layer for Unicodeを利用することにより、ほぼすべてのUnicode版APIが使用可能になる[26]。また、Windows CEでは、逆にUnicode版APIしか実装していない。NT系でも、Unicodeを前提とした仕様変更が行われたり[27]、Theme APIなど新しいAPIでA/Wの2種を用意せずUnicodeを用いるものだけを用意したりするなど、徐々にUnicodeへ傾斜する傾向にある。

歴史

Windows APIの歴史は、もちろんWindows自体の歴史と切り離せない関係にある。常に、Windowsに新機能が搭載されれば、それをアプリケーションソフトウェアから使用するための新しくAPIが追加され、新しいSDKが公開されることの繰り返しである(もちろん、デバイスドライバーらに対応を迫るものは、DDK/WDKで公開される)。

Windows APIの歴史上、最も大きな変革はWindows NTに伴うWin32の登場だった。ポインタとハンドルも32ビット化されたこと、Unicodeへの対応が図られたことが大きな変化である。

なお、現在[いつ?]は緩やかに64ビットへの移行が進んでいる。Win64では、ポインタおよびハンドルは64ビット化されているが、それ以外では16ビットから32ビットへの移行時のような大きな変化はない。なお、64ビット版Windowsでは32ビットアプリケーションとの相互運用性を確保するため、ハンドルの上位32ビットを使用する仕組みとなっており、ウィンドウ (HWND) などのユーザーオブジェクトハンドル、ブラシ (HBRUSH) やペン (HPEN) などのGDIオブジェクトハンドル、そしてミューテックス、セマフォ、ファイルなどの名前付きオブジェクトハンドルを32ビット/64ビットアプリケーション間で共有し、プロセス間通信に利用することができる[28]。また、64ビット版WindowsではWOW64により32ビットアプリケーションを実行できるが、16ビットアプリケーションを実行することはできない[29] [30]

批判

Windows APIはWin16を拡張して32ビット、64ビット化されたという歴史がある。そのため度重なる機能の追加により、高度に複雑化しその習得が困難と化しているという問題がある[31]

また、度重なるバージョンアップによりコンポーネントの互換性を失ってしまうことによるDLL地獄 (DLL Hell) の発生を招いている。

ラッパーライブラリ

Windows APIは比較的低水準であるため、高水準なインターフェイスを持たせるための様々なラッパーが数多く存在する。主なものは次のとおり。

マイクロソフト

Microsoft Foundation Class (MFC)
C++クラスによるWindows APIのラッパー。
Active Template Library (ATL)
C++テンプレートによるCOMのラッパー。
Windows Template Library (WTL)
ATLの拡張として作られた軽量のWindows APIのラッパー。現在[いつ?]CPLに基づくオープンソースとなっている。

ボーランド

Object Windows Library (OWL)
MFCと同時期に公開され、よりオブジェクト指向に作られたラッパー。
Visual Component Library (VCL)
ボーランドがその後に作ったDelphiによるラッパー。

.NET FrameworkにもWindows APIをラップした部分が存在する。

脚注

  1. ^ チャールズ・ペゾルド『プログラミングWindows第5版』 〈上〉、アスキー、2000年10月。ISBN 978-4756136008 
  2. ^ ASCII.jp:MinWinとVirtual DLLで変わるWindowsカーネル (1/2)|あなたの知らないWindows
  3. ^ ASCII.jp:ARM版Windows 8実現の布石となったWindows 7の「MinWin」 (3/4)|基礎から覚える 最新OSのアーキテクチャー
  4. ^ Overview of the Windows API” (英語) (2009年5月7日). 2009年7月8日閲覧。
  5. ^ DirectX 8.0 の紹介
  6. ^ Getting Started with DirectX Graphics (Windows)
  7. ^ DirectX 8.0 の紹介
  8. ^ オーディオのリファレンス
  9. ^ DirectX に関してよく寄せられる質問
  10. ^ Windows マルチメディア
  11. ^ Windows Multimedia (Windows)
  12. ^ OpenGL - Win32 apps | Microsoft Docs
  13. ^ Petzold, Charles 著、株式会社ロングテール/長尾高弘 訳『プログラミングWindows』 〈上〉(第5版)、アスキー、2000年10月、33ページ頁。ISBN 978-4756136008 
  14. ^ Petzold, Charles 著、株式会社ロングテール/長尾高弘 訳『プログラミングWindows』 〈上〉(第5版)、アスキー、2000年10月、34ページ頁。ISBN 978-4756136008 
  15. ^ Microsoft Announces Visual C++ for Windows CE” (英語). マイクロソフト (1997年4月1日). 2009年1月30日閲覧。
  16. ^ Cross-Platform Application Development in Windows NT” (英語) (2003年12月1日). 2007年7月26日閲覧。
  17. ^ Microsoft Visual C++ 4.0 Cross-Development Edition for Macintosh (Archived Visual C++ Technical Articles)” (英語) (1995年7月). 2007年7月26日閲覧。
  18. ^ Microsoft、ARM64対応のデスクトップ版Windows 10を計画か - エキサイトニュース
  19. ^ Windows SDK 10にはARM64用のインポートライブラリファイルなどが含まれている。
  20. ^ Working with Strings (Windows)” (英語). MSDNライブラリ. マイクロソフト (2010年10月5日). 2011年8月27日閲覧。
  21. ^ Surrogates and Supplementary Characters”. MSDNライブラリ (2009年1月12日). 2010年1月19日閲覧。
  22. ^ Windows XP Professional の多言語オプションの比較”. TechNetライブラリ. 2010年1月19日閲覧。
  23. ^ Unicode in the Windows API”. MSDNライブラリ (2010年1月12日). 2010年1月19日閲覧。
  24. ^ Chen, Raymond (2004年5月31日). “Why is the default 8-bit codepage called "ANSI"?” (英語). The Old New Thing. 2008年1月30日閲覧。
  25. ^ Other Existing Unicode Support” (英語). MSDNライブラリ. 2010年1月19日閲覧。
  26. ^ Microsoft Layer for Unicode Reference” (英語). MSDNライブラリ. 2009年7月31日閲覧。
  27. ^ [WinXP] Common Control 6.0 の EM_LIMITTEXT による入力制限”. サポート技術情報 (2009年9月16日). 2010年1月19日閲覧。
  28. ^ Interprocess Communication Between 32-bit and 64-bit Applications (Windows)
  29. ^ 32 ビット アプリケーションの実行 (Windows)
  30. ^ 64bit Windows時代到来:第3回 アプリケーションの互換性 (1/3) - @IT
  31. ^ .NET「本音」相談室(第1回)Q3:どうしていま、.NETなのか?”. @IT. 2009年7月12日閲覧。

関連項目

参考文献

  • Charles Petzold著 『プログラミングWindows第5版〈上〉』 アスキー、2000年。ISBN 4756136001
  • Charles Petzold著 『プログラミングWindows第5版〈下〉』 アスキー、2000年。ISBN 475613601X
  • Jeffrey Richter著 『Advanced Windows 改訂第4版』 アスキー、2001年。ISBN 4756138055

外部リンク