An interesting case has arisen on the tuts4you forum (https://forum.tuts4you.com/topic/44698-how-to-run-an-app-without-showing-the-main-window/page/2/#comment-219355) regarding why the masm32.lib doesnt have a wrapper around the unicode versions of functions similar to how all other .inc files seems to, for example AddAtom from kernel32.inc:
AddAtomA PROTO STDCALL :DWORD
IFNDEF __UNICODE__
AddAtom equ <AddAtomA>
ENDIF
AddAtomW PROTO STDCALL :DWORD
IFDEF __UNICODE__
AddAtom equ <AddAtomW>
ENDIF
It seems some the Unicode/Wide versions of masm32.lib functions are appended with 'W' as seems appropriate, but the Ansi versions are not appended with 'A', thus even if we do follow a similar way of defining the unicode version using IFDEF IFNDEF etc it should look like this (taking GetAppPath as an example):
GetAppPath PROTO STDCALL :DWORD
IFNDEF __UNICODE__
GetAppPath equ <GetAppPath>
ENDIF
GetAppPathW PROTO STDCALL :DWORD
IFDEF __UNICODE__
GetAppPath equ <GetAppPathW>
ENDIF
But when using the __UNICODE__ EQU 1 define, that will cause an error: A2005: symbol redefinition : GetAppPath as the GetAppPath is already the Ansi version and so we cant use that name to redirect to the Unicode/Wide version.
I guess changing the Ansi function versions so that they do have the appended 'A' and recompiling will allow us to properly define in the masm32.inc as follows:
GetAppPathA PROTO STDCALL :DWORD
IFNDEF __UNICODE__
GetAppPath equ <GetAppPathA>
ENDIF
GetAppPathW PROTO STDCALL :DWORD
IFDEF __UNICODE__
GetAppPath equ <GetAppPathW>
ENDIF
And thus code calling GetAppPath will properly direct to whichever version it should use: GetAppPathA or GetAppPathW
Interesting :rolleyes:
Here is a testbed:
; __UNICODE__ EQU 1
include \masm32\include\masm32rt.inc
.data?
buffer db MAX_PATH dup(?)
.code
start:
ifdef __UNICODE__
invoke GetAppPathW ; no second arg addr buffer
invoke MessageBoxW, 0, eax, chr$("Where's da problem?"), MB_OK
else
invoke GetAppPath, addr buffer
invoke MessageBox, 0, addr buffer, chr$("Where's da problem?"), MB_OK
endif
exit
end start
Note the inconsistency of requested arguments. I've never used the __UNICODE__ EQU 1 equate. In most of my sources, I need both the Ansi (90%) and the Unicode (10%) versions, and that equate is incompatible with that mixture. Instead, I use Print and wPrint as needed.