Hi,
I am thinking of using unicode in my program. Do I just use the api that ends with W and if so how do I go about using them, since msdn has nothing on them. Also if I am not wrong, it does not work on all os, so what do I do if the unicode verison does not exist? Thanks anyway
Regards,
Victor
I am thinking of using unicode in my program. Do I just use the api that ends with W and if so how do I go about using them, since msdn has nothing on them. Also if I am not wrong, it does not work on all os, so what do I do if the unicode verison does not exist? Thanks anyway
Regards,
Victor
It's easy using unicode if you have the right includes (I really should bugfix my protoize ;)), yes it's as simple as using the W APIs instead of the A ones. Defining unicode strings in masm can be a bit b1tchy, even with macros... I think GoAsm has better support for them.
Of course strings have to be double length, and remember that most API calls take *number of chars*, NOT *number of bytes*.
MSDN/PlatformSDK should state which functions are available where... also there's some conversion layer. Head over to the GoAsm site, I think Jeremy Gordon wrote a good deal about it.
Of course strings have to be double length, and remember that most API calls take *number of chars*, NOT *number of bytes*.
MSDN/PlatformSDK should state which functions are available where... also there's some conversion layer. Head over to the GoAsm site, I think Jeremy Gordon wrote a good deal about it.
Hi Roticv,
Here is the unicode all_api file from my GoAsm includes. It has all of the function equates for most of unicode ones in the standard API. Only those APIs that have a unicode wrapper are included in the file. Just as a BTW, GoAsm has full unicode support and has some very powerful features for unicode programs. It is in the form...
Here is the unicode all_api file from my GoAsm includes. It has all of the function equates for most of unicode ones in the standard API. Only those APIs that have a unicode wrapper are included in the file. Just as a BTW, GoAsm has full unicode support and has some very powerful features for unicode programs. It is in the form...
AbortSystemShutdown equ AbortSystemShutdownW
AccessCheckAndAuditAlarm equ AccessCheckAndAuditAlarmWwhat's the deal with unicode?
you want ppl in japan to use your app ? :D
you want ppl in japan to use your app ? :D
MS distributes 'unicows' or something like that in order to provide wrappers or fake versions of Unicode APIs. Search MSDN. AFAIK, that DLL is redistributable, so you may bundle it with your app, and install it when you detect 16 bit OS + 32 bit GUI version of Windows.
what's the deal with unicode?
you want ppl in japan to use your app ? :D
Is this a joke? If it is not a joke, you must be specialized in very narrow area of programming.
what's the deal with unicode?
you want ppl in japan to use your app ? :D
Is this a joke? If it is not a joke, you must be specialized in very narrow area of programming.
One advantage of using UNICODE on some versions of windows is to reduces overhead as the ASCII versions just convert the strings and call the wide character version of the function.
One advantage of using UNICODE on some versions of windows is to reduces overhead as the ASCII versions just convert the strings and call the wide character version of the function.
Also, some functions only have a Unicode version and no ASCII equivalent.
Unicows is very simple to use, you have only to include the /MSLU switch when you link with GoLink or in MASM include the following *before* any other includelibs.
At that point you must have the following in your code (this is not necessary in GoAsm the stub is added by the linker)
Unicows and it's accompanying libs etc.. can be obtained from Microsoft...
MSLU
And by the way. If you use Unicows there are a few welcome surprises in Win9x, like the UpdateResource family of instructions actually work :alright:
includelib unicows.libAt that point you must have the following in your code (this is not necessary in GoAsm the stub is added by the linker)
.data
szUniLib BYTE "unicows.dll",0
szNoLib BYTE "This application uses Unicode functions",13,10,
"that require Microsoft Layer for Unicode",0
.code
LoadUnicows PROC
LOCAL osvi :OSVERSIONINFO
mov osvi.dwOSVersionInfoSize,SIZEOF OSVERSIONINFO
invoke GetVersionEx,ADDR osvi
.IF osvi.dwPlatformId != VER_PLATFORM_WIN32_NT
invoke LoadLibrary,OFFSET szUniLib
.IF eax == NULL
invoke MessageBox,NULL,OFFSET szNoLib,NULL,MB_OK
invoke ExitProcess,0
.ENDIF
.ENDIF
ret
LoadUnicows ENDPUnicows and it's accompanying libs etc.. can be obtained from Microsoft...
MSLU
And by the way. If you use Unicows there are a few welcome surprises in Win9x, like the UpdateResource family of instructions actually work :alright:
from MSDN
"Unicode is a specification for supporting character sets, like Japanese and Chinese, that cannot be represented in a single byte. If you are programming for an international market,"
i don't find it a joke :) that is what unicode created for.
"Unicode is a specification for supporting character sets, like Japanese and Chinese, that cannot be represented in a single byte. If you are programming for an international market,"
i don't find it a joke :) that is what unicode created for.
Well,
as far as I know, TextOutW is preinstalled on every 32bit-Windows, so you won't have any compatibility problems.
Also preinstalled on every system is GetTextExtentPoint32W, which can help you to check the display size of the text.
Regards,
Claus
as far as I know, TextOutW is preinstalled on every 32bit-Windows, so you won't have any compatibility problems.
Also preinstalled on every system is GetTextExtentPoint32W, which can help you to check the display size of the text.
Regards,
Claus
Hi Donkey,
For support on 9x, all I need to do is to include unicows.dll and load the dll right? If it is so simple I will go straight to add support for unicode in faim asap.
Wizzra,
What I have in mind is chatting chinese, and not japanese, since I know chinese but not japanese ;)
Regards,
Victor
For support on 9x, all I need to do is to include unicows.dll and load the dll right? If it is so simple I will go straight to add support for unicode in faim asap.
Wizzra,
What I have in mind is chatting chinese, and not japanese, since I know chinese but not japanese ;)
Regards,
Victor
For support on 9x, all I need to do is to include unicows.dll and load the dll right? If it is so simple I will go straight to add support for unicode in faim asap.
Yes, you must build with the unicows.lib file as the first lib in your project then load Unicows.dll at startup, this will set up an API hook to redirect and translate the API calls for 9x, do not load Unicows.dll on NT based systems. Note that it is very important to use the Unicows lib file and that it is the first lib included, this will override the other libs in the project for the affected API calls.
Thanks Donkey,
But it seems like unicows.dll is way bigger than the application I am developing ;)
But it seems like unicows.dll is way bigger than the application I am developing ;)
Hi Roticv,
Yes, for small applications you are much better off just doing conversions in your program. Generally a check for NT and a separate execution path, but it means loading the APIs dynamically. You might think about putting some functions in a DLL and loading the proper DLL depending on the OS version, it would make it possible to do it without dynamic loading.
Yes, for small applications you are much better off just doing conversions in your program. Generally a check for NT and a separate execution path, but it means loading the APIs dynamically. You might think about putting some functions in a DLL and loading the proper DLL depending on the OS version, it would make it possible to do it without dynamic loading.