I don't like ANSI version.
For a start you can use conditional compilation features of MASM:
ifdef _UNICODE
... unicode cod ehere
else
... ANSI code here
endif
Also please note than many API's have a suffix letter of "A" for ANSII or "W" for WIDE or UNICODE. An text EQU can be placed in above conditional blocks to define MassageBox as either MesaggeBoxA or MessageBoxW as you "prefer". This way you can use a single API name in your application and switch in between ANSI or UNICODE at any build / time.
For example:
ifdef _UNICODE
MessageBox equ <MessageBoxA>
else
MessageBox equ <MessageBoxW>
endif
Of course do not forget to define or undefine the _UNICODE symbol somewhere. This can be done in build command line or in source. Ah... and o course you will have to use UNICODE parameters for unicode API.
Alternatively I have heard that GoASM (with forums also hosted here) has interesting Unicode support inside that you might want to test/ride.
:bg thx, I see, but it's not easy
1. MASM's include files don't support _UNICODE conditional compilation features
MessageBox ALWAYS equ <MessageBoxA>
I have to do so much ...
2. How to define Unicode string readily?
str db "U", 0, "M", 0, "U", 0, 0, 0
? that's crazy.
UMU,
I wanted Unicode support with MASM so I build the include files for that and a string macro. It does all Bogdan said, in the same way.
But there is some functions problem like the one that don't have a trailing A for the ANSI version. For example Process32First from kernel32.dll which is Process32First for ANSI and Process32FirstW for Unicode. I'm working on a new set of include files to solve that problem.
I don't like to sell my stuff but for Unicode support, I can't glorify MASM32 as I do usually.
Azimut Project...
http://www.masm32.com/board/index.php?topic=7866.0
A little example...
.486
.MODEL FLAT,STDCALL
OPTION CASEMAP:NONE
UNICODE EQU 1
INCLUDE \AZIMUT\INCLUDE\AZIMUT.INC
INCLUDE \AZIMUT\INC32\kernel32.inc
INCLUDE \AZIMUT\INC32\user32.inc
INCLUDELIB \AZIMUT\LIB32\kernel32.lib
INCLUDELIB \AZIMUT\LIB32\user32.lib
.DATA
ALIGN 4
AzmtStr szText, TCHAR, <MessageBox text/0>
ALIGN 4
AzmtStr szTitle, TCHAR, <MessageBox title/0>
.CODE
Main:
invoke MessageBox, 0, addr szText, addr szTitle, 0
invoke ExitProcess, 0
END Main
jdoe,
good job!
Regards!
Quote from: UMU on November 06, 2008, 05:19:28 AM
MessageBox ALWAYS equ <MessageBoxA>
But note that there is also a prototype for MessageBoxW:
MessageBoxW PROTO :DWORD,:DWORD,:DWORD,:DWORD
So if you specify MessageBox or MessageBoxA you get the ANSI version, and if you specify MessageBoxW you ge the Unicode version.
that's what i was wondering, thx for clearing it up
I realized that I could misleading peoples when I it comes to Unicode and MASM32. Thanks to Michael for having wrote what I should have, in the first place. MASM32 include files have always defined the Unicode version of functions... just the UNICODE definition is missing.
Sorry for my mistake.
:red
GoAsm supports unicode strings natively, i.e.
http://www.jorgon.freeserve.co.uk/GoasmHelp/Unicode.htm
I wonder what the noise is about, for YEARS the MASM32 include files have had prototypes for UNICODE Windows API functions and the distinction is this simple, IF the API has BOTH and ANSI and UNICODE function avaiable,
MessageBoxA
MessageBoxW
The ANSI version is equated to the normal name and the unicode version is not.
If anyone actually bothered to look in the appropriate include file "user32.inc" they would find this.
MessageBoxA PROTO :DWORD,:DWORD,:DWORD,:DWORD
MessageBox equ <MessageBoxA>
MessageBoxExA PROTO :DWORD,:DWORD,:DWORD,:DWORD,:DWORD
MessageBoxEx equ <MessageBoxExA>
MessageBoxExW PROTO :DWORD,:DWORD,:DWORD,:DWORD,:DWORD
MessageBoxIndirectA PROTO :DWORD
MessageBoxIndirect equ <MessageBoxIndirectA>
MessageBoxIndirectW PROTO :DWORD
MessageBoxW PROTO :DWORD,:DWORD,:DWORD,:DWORD
mutter etc ....
Hi Hutch,
I guess the idea is about conditional compilation :P
It's more like a global declaration, where if you specify a symbol to your code say _UNICODE, then automatically the compilation process gets affected. In this case, all normal names will follow unicode version of API function:
Something like:
ifdef _UNICODE
MessageBox equ <MessageBoxW>
else
MessageBox equ <MessageBoxA>
endif
So then in your program, all you have to do is define the symbol:
_UNICODE equ 1
.code
invoke MessageBox, NULL, addr text, addr text2, MB_OK ; <-- automatically invoking MessageBoxW
But I'm not sure whether there is a macro to undefine a symbol (#undef equivalent) to put it back to ANSI version.
EDIT: Sorry, Bordan already said the same :bg
Cheers,
-chris
Chris,
The virtue of not treating MASM like a C compiler is you can routinely mix ANSI and UNICODE Windows API functions without the limitations of a C compiler. The method used in the MASM32 project is intentional so you can use either by using the correct name of the function, it is by convention that the ANSI functions get the shortened name by using an equate.
The problem the user posted here is just one of the problems of aping a C compiler when an assembler never needed to do so.
Quote from: hutch-- on November 10, 2008, 09:02:27 PM
The method used in the MASM32 project is intentional so you can use either by using the correct name of the function, it is by convention that the ANSI functions get the shortened name by using an equate.
The problem is that you always need to know if a function is exported for ANSI and Unicode, while conditional compilation with Unicode aware include files, gives you more flexibility... and when you need the ANSI and the Unicode version it's still possible to mix both using the correct name.
At the end, it's just about writing code easier.
Quote from: hutch-- on November 10, 2008, 09:02:27 PM
The virtue of not treating MASM like a C compiler is you can routinely mix ANSI and UNICODE Windows API functions without the limitations of a C compiler.
That's a lame excuse. The high level directives of MASM and the huge macro system of MASM32 are there for that... writing code like HLL.
:bg
Both of these views have the same problem, it treats the programmer like an idiot, having the actual choice of either ansi or unicode is something that a programmer can routinely decide, being strangled with a predefined either/or approach generates more problems than it solves.
> writing code like HLL.
This does not mean write MASM like a C compiler, the language does not need C based assumption to work, it is a language in its own right.
Quote from: hutch-- on November 11, 2008, 03:05:02 AM
Both of these views have the same problem, it treats the programmer like an idiot, having the actual choice of either ansi or unicode is something that a programmer can routinely decide, being strangled with a predefined either/or approach generates more problems than it solves.
It's not fair to say that I'm treating programmers as idiots but since I'm one of the most fervent of that way of handling Unicode (using a predefined value), I can assume your critics because for me, it did "solves more problems that it generates".
If my convictions make me looks like an idiot, I can live with it. It's not the first time and it won't be the last time... I'm used to :bg
:U
:bg
JD,
I think something was lost in translation.
> If my convictions make me looks like an idiot, I can live with it. It's not the first time and it won't be the last time... I'm used to
We all suffer that one from time to time.
I was actually referring to the way the code/library/compiler designer(s) treat programmers with their assumptions, "users are idiots so we will patronise them". While I well understand a conditional assembly, following a C compiler with an either/or choice is not one that I see as a good choice as it is easy enough for the programmer to pick either form directly from the API name.
Quote from: hutch-- on November 11, 2008, 05:38:22 AM
I think something was lost in translation.
This is so me :red
Quote from: hutch-- on November 10, 2008, 09:02:27 PM
Chris,
The virtue of not treating MASM like a C compiler is you can routinely mix ANSI and UNICODE Windows API functions without the limitations of a C compiler. The method used in the MASM32 project is intentional so you can use either by using the correct name of the function, it is by convention that the ANSI functions get the shortened name by using an equate.
The problem the user posted here is just one of the problems of aping a C compiler when an assembler never needed to do so.
I'd like to use MessageBoxW instead of MessageBox, but tell me how can I define a Unicode string in a stylish way. I need to use Simplified Chinese unicode string. thx!
UMA,
While I don't have the specific chinese language experience, fortunately the resource string system in Windows will store the data in the form you need. What you need is a way to compose big 5 or whatever character set you use in a resource file script. Then you use the LoadStringW API function and display it as you choose.