Why does MinGW define Win API functions as a macro?

I wonder why so many Win API functions determine only their actual implementation in MinGW.

Example:

MessageBox() , as described in the MSDN documenation :

 int WINAPI MessageBox( _In_opt_ HWND hWnd, _In_opt_ LPCTSTR lpText, _In_opt_ LPCTSTR lpCaption, _In_ UINT uType ); 

And here is the implementation of MinGW ( winuser.h ):

 #define MessageBox MessageBoxA /* ... */ WINUSERAPI int WINAPI MessageBoxA(HWND,LPCSTR,LPCSTR,UINT); 

So MessageBox not a function, it is just a definition for a real function.

Another (taken from winbase.h :

 #define GetVersionEx GetVersionExA /* ... */ WINBASEAPI BOOL WINAPI GetVersionExA(LPOSVERSIONINFOA); 

As you can see, in most cases functions are implemented as macros for their real implementation.

Is there a reason for this? And why aren't they implemented as "real" functions (using their real name)?

+4
source share
2 answers

From GetVersionEx Documentation :

Unicode and ANSI Names: GetVersionExW (Unicode) and GetVersionExA (ANSI)

From Documents for documentation on prototype functions :

The preprocessor extends the macro either on the Windows codepage or in the Unicode function name. The letter "A" (ANSI) or "W" (Unicode) is added at the end of the name of the common function, if necessary. The header file then provides two specific prototypes: one for Windows code pages and one for Unicode, as shown in the following examples.

In your case, GetVersionEx will expand to GetVersionExA , because it looks like you're using a Windows codepage .

+5
source

Using DEFINE allows you to use the same code with the difference compiler options. For example: MessageBox will use MessageBoxW if unicode used, but MessageBoxA if not. It would be painful to go through the entire code base just to change method names.

Edit: Also see the Christoph link referenced by this answer.

+2
source

Source: https://habr.com/ru/post/1485106/


All Articles