How can I write Unicode version program?

[UMU]

I don't like ANSI version.

[BogdanOntanu]

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:

Code Select Expand


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.

[UMU]

 :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.

[jdoe]

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

[jdoe]

A little example...

Code Select Expand



.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



[UMU]

jdoe,

good job!

Regards!

[MichaelW]

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.

[Rainstorm]

that's what i was wondering, thx for clearing it up

[jdoe]

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

[Mark Jones]

GoAsm supports unicode strings natively, i.e.

http://www.jorgon.freeserve.co.uk/GoasmHelp/Unicode.htm

[hutch--]

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.

Code Select Expand


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 ....

[gwapo]

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:

Code Select Expand


ifdef _UNICODE
   MessageBox equ <MessageBoxW>
else
   MessageBox equ <MessageBoxA>
endif


So then in your program, all you have to do is define the symbol:

Code Select Expand


_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

[hutch--]

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.

[jdoe]

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.

[jdoe]

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.