UNICODE and OEM ... very few spoken words....

[xandaz]

   I decided that from now on everything i do should be in unicode. Now, i was working on an list view animated thingy and used Window enumeration to fill the control. I had some trouble getting the the window bar to show the unicode string with its name and i tried to use CharToOemW and it worked. It shows. The problem is that when i run lva the window's name shows all these japaneese characters. Why is this? and why does the window Title show all but the first character when its format is of the kind:

Code Select Expand

WndName db  'W',0,'i',0,'n',0,0 ????
   Thanks ... i'll check later to see if there was replying.

[evlncrn8]

Code Select Expand


WndName db 'W',0,'i',0,'n',0,0


is missing a terminator.. unicode.. double null termination

Code Select Expand


WndName db 'W',0,'i',0,'n',0,0,0


[WYVERN666]

Hi xandaz. Looks more easy to write:

Code Select Expand


WndName dw 'W','i','n',0


:bg

[jj2007]

Code Select Expand

include \masm32\include\masm32rt.inc
include UcInData.asm

.data
uctest uc$("This is a test", 13, 10, "with two lines", 0)

.code
start: invoke MessageBoxW, 0, addr uctest, 0, MB_OK
exit
end start

(but MasmBasic wChr$ is much easier too use  :bg)

[xandaz]

   Have you tried that for a window jj? i used WSTR with a MessageBoxW and it worked fine. The problem is that with CreateWindowExW, the Title only shows the first character. With ChartoOemW it works but WinEnum fails to present the Window's name decentelly.
   Thanks

[donkey]

   Have you tried that for a window jj? i used WSTR with a MessageBoxW and it worked fine. The problem is that with CreateWindowExW, the Title only shows the first character. With ChartoOemW it works but WinEnum fails to present the Window's name decentelly.
   Thanks

You should try the IsWindowUnicode to see if your window is actually unicode, sounds like it isn't. If it isn't then perhaps the CreateWindowExW function is being redefined at some point, who knows, somewhere there may be a CreateWindowExW equ CreateWindowExA definition. To check this get a disassembly of your program and check to make sure that the right function is called, OllyDbg will do that for you. If your window is actually Unicode then you have to take a look at the string that your generating. You can verify that by looking at a HEX dump of the string you are sending to CreateWindowExW and checking it against one that has been created using MultiByteToWideChar which will generate the proper Unicode string. Be sure to examine them using a HEX dump, simply trying to output the string will not help you to find the source of the problem, vKim's debug macros are one tool you can use for this. If there is a discrepancy between the two strings then you have found your problem. These are the only three things I can think of that might cause the problem you are describing so I would start with them.

Edgar

[sinsi]

I left out the ChartoOemW and made sure that api calls were all unicode and it works fine (I assume). You have a few SendMessage calls, changing them to SendMessageW works.

[donkey]

I left out the ChartoOemW and made sure that api calls were all unicode and it works fine (I assume). You have a few SendMessage calls, changing them to SendMessageW works.

Wouldn't have even thought to look for that, too used to GoAsm I guess, it and the headers do Unicode natively so two quick defines and everything switches over:

STRINGS UNICODE
#DEFINE UNICODE

After that every inline string and every function is unicode by default. I was looking for a much more complex problem because the simple ones would never have occured to me.

Edgar

[jj2007]

Have you tried that for a window jj?

Frequently. To make it work, you only need
invoke SetWindowTextW, handle, pString
and your edit control should be created along these lines (wChr$ is MB syntax, but you know what it means):

        if UseUnicode
         invoke CreateWindowExW, WS_EX_CLIENTEDGE, wChr$("edit"), NULL,
            WS_CHILD or WS_VISIBLE or WS_BORDER\
            or ES_LEFT or ES_AUTOHSCROLL or ES_MULTILINE, 0, 0, 0, 0,
            hWnd, IdEdit, hInstance, NULL
         mov hEdit, eax                     ; we have created an edit window
   ;      sm eax, WM_SETFONT, hButFnt, 1      ; you may choose the small font here
         invoke SetWindowLongW, hEdit,      ; we subclass the edit control
         GWL_WNDPROC, SubEdit
[/color]

[xandaz]

   What if you try this:

Code Select Expand


.data
.
.
WSTR MainWindowName,"Some Win"

.code
       start:
             inv. GetModuleHandle,0...
             .
             .
             inv. WinMain....
WinMain PROC....
   
    CreateWindowExW,0,addr MainClass,addr MainWindowName,...
...
...
endp
end start

   Will it show the full name of the window or just the first character?
   See the example

[xandaz]

   Alright. I think this new example shows better what i mean - and yes i checked with olly to see if the unicode version of the functions was being called, and also those not-wide messages where changed to wide tho it didn't seem to make a difference at that point. In this example clicking the static control will toggle both the window's title and the static text from unicode to oem(unicode) and you'll see that one is different from the other? Can someone explain this ?
   Thanks.

[dedndave]

xandaz,
just a thought, here
Hutch is working hard on the next release of the Masm32 package
it appears to have numerous improvements with regard to Unicode support
in fact, the thread in the MASM32 sub-forum has a few macros etc, like those by qWord   :U

[jj2007]

Xandaz,

__UNICODE__ equ <1>
include \masm32\include\windows.inc

... and everything works fine.

[qWord]

what version of MASM32 are you using?
The WSTR-macro in version 11beta is not correct: it switch back to code segment, thus all data declared after the call are read-only.

EDIT: you must replace DefWindowProc by DefWindowProcW

[xandaz]

   Damn... i was thinking on my way home after picking up my baby that that it was going to be some slight detail i had overlook as usual and it was. Qw... man you really master it all. Thanks a lot guys.