How can I write an unicode string in source code

[untio]

Hello,
I have not done much code in assembly.
In C or C++ windows compilers there are a macro 'TEXT' that translate a text array to wide characters or to bytes depending on the definition of UNICODE.
With it is easy to create UNICODE aplications.
Now the question:
I can write UNICODE strings in a resource file, I can write UNICODE strings with hex codes, but is there a solution like the C's macro in MASM.
Thanks in advance for your time.

[MichaelW]

Hello untio, welcome to the forum.

Masm32 includes two macros in \masm32\macros\umacros.asm that allow you to conveniently define Unicode strings in the data section, and something like 18 Unicode-specific procedures in the Masm32 library. Beyond that you have access to the Unicode-specific functions provided by the Windows API and by MSVCRT. For the API functions that have both ANSI and Unicode versions, the Masm32 include files default to the ANSI version. For example, from user32.inc:

Code Select Expand


MessageBoxA PROTO :DWORD,:DWORD,:DWORD,:DWORD
MessageBox equ <MessageBoxA>
MessageBoxW PROTO :DWORD,:DWORD,:DWORD,:DWORD


So if you specify the function name without the suffix you get the ANSI version. To specify the Unicode version you must specify the full name of the Unicode version.

With C/C++ the ability to switch a source from ANSI to Unicode with a UNICODE define depends on support in the header files. For example, from isguids.h:

Code Select Expand


#ifdef UNICODE
#define IID_IUniformResourceLocator     IID_IUniformResourceLocatorW
#else
#define IID_IUniformResourceLocator     IID_IUniformResourceLocatorA
#endif


Masm32 has no such support in its include files.

[untio]

Thank you for your answer.
I have seen the macro WSTR. I'll put the strings in the resource file for the moment, but this macro can be very useful for me, mainly for testing purposes.

Another time, thank you very much.

[Vortex]

Hi untio,

Poasm, Pelle's Macro Assembler which is nearly compatible with Masm supports unicode strings. The Poasm syntax :

Code Select Expand

wide_string DW "a UNICODE string",0  ; must terminate string

[jj2007]

The WSTR macro is a good option, but be aware of the WSTR SIZEOF problem.

[hutch--]

There is another option for storing unicoder string data that Microsoft designed into win32 originally, store the unicode data as resource strings in the resource section, that will allow you to use it as either ANSI or UNICODE simply by the change in API used. It does not have the convenience of inline string data but if you own a resource editor, they are designed to create string data for the win32 format.

[ecube]

GoASM has built support for unicode strong, so you can switch back and forth very easily, aswell as define certain parts of the data section as unicode, and change it back. In masm be careful with the unicode macro's, I haven't played with them alot but WSTR for instance can't handle a "*" character in the string and who knows wat else. To compensate u can manually

woot WORD "H","I","*",0

[hutch--]

MASM uses a set of escape characters which have precedence over user selected characters and this makes some characters more difficult to use. They are published in MASM manuals from about 1990 onwards but finally if you want to use MASM to write specification win32, use the resource section as it was designed to be used, to store strings in unicode format that can be accessed by API as either ANSI or UNICODE.

[ecube]

You can also convert a byte string to unicode using MultiByteToWideChar, just make sure your buffer is sufficient size, which should be atleast double the string length to accomidate the extra 0's.

Code Select Expand


ToUni proc szIN:DWORD,szUnicodeBuffx:DWORD,bufsizex:DWORD
invoke MultiByteToWideChar,CP_ACP, 0, szIN, -1,szUnicodeBuffx,bufsizex
ret
ToUni endp

.data?
myunibuff byte 512 dup(?)
.code
start:
invoke ToUni,CTEXT("hello there"),addr myunibuff,512
invoke MessageBoxW,0,addr myunibuff,NULL,MB_OK


[Vortex]

This one works fine :

Code Select Expand

.386
.model flat,stdcall
option casemap:none

include     \masm32\include\windows.inc
include     \masm32\include\kernel32.inc
include     \masm32\include\user32.inc
include     \masm32\macros\ucmacros.asm

includelib  \masm32\lib\kernel32.lib
includelib  \masm32\lib\user32.lib

.data

WSTR    capt,"UNICODE test"
WSTR    msg,"Testing the WSTR macro"

.code

start:

    invoke  MessageBoxW,0,ADDR msg,ADDR capt,MB_OK
    invoke  ExitProcess,0

END start

[ecube]

This one works fine :

Code Select Expand

.386
.model flat,stdcall
option casemap:none

include     \masm32\include\windows.inc
include     \masm32\include\kernel32.inc
include     \masm32\include\user32.inc
include     \masm32\macros\ucmacros.asm

includelib  \masm32\lib\kernel32.lib
includelib  \masm32\lib\user32.lib

.data

WSTR    capt,"UNICODE test"
WSTR    msg,"Testing the WSTR macro"

.code

start:

    invoke  MessageBoxW,0,ADDR msg,ADDR capt,MB_OK
    invoke  ExitProcess,0

END start

aslong as it doesn't have "*" in it, or other escape characters. So for instance using FindFirstFileW and trying to use

WSTR   search,"*.*" 


wouldn't work

[MichaelW]

This works:

WSTR    msg, "Testing the WSTR macro a:\.\..\x?\*.* *.? {} &$;/A @%#"

The only problem characters I found were "<" and ">" (which would not assemble), and "!" (which assembled OK but was removed from the string).

[qWord]

The WSTR macro is a good option, but be aware of the WSTR SIZEOF problem.

This problem can be easily solved by first determining the size of string and then declaring a struct with this size. When writing the string, the struct is used as the data-type:

Code Select Expand

    str_size= wstr_get_size(...)
    tmpstruct_xyz struct
        db str_size dup (?)
    tmpstruct_xyz ends
    ...
    .data
        ...
        mystr LABEL tmpstruct_xyz
    ...

[ecube]

This works:

WSTR    msg, "Testing the WSTR macro a:\.\..\x?\*.* *.? {} &$;/A @%#"

The only problem characters I found were "<" and ">" (which would not assemble), and "!" (which assembled OK but was removed from the string).

thankyou for correcting me, I was so adamant about the * character because I had trouble with WSTR in the past and I could of swore that was the character, since its been awhile I should of tested to confrm, as you did.