If I use ANSI Functions but Compile Unicode is my project still Unicode?
Let's say I use GetComputerNameA instead of GetComputerName and compile my project as Unicode. Will it still work on Asian OSes?
7 Replies - 375 Views - Last Post: 06 August 2011 - 09:40 AM
#1
If I use ANSI Functions but Compile Unicode is my project still Unicod
Posted 09 July 2011 - 01:01 PM
Replies To: If I use ANSI Functions but Compile Unicode is my project still Unicod
#2
Re: If I use ANSI Functions but Compile Unicode is my project still Unicod
Posted 09 July 2011 - 01:03 PM
Well I have not tested this but my bet would be no.
#3
Re: If I use ANSI Functions but Compile Unicode is my project still Unicod
Posted 06 August 2011 - 08:32 AM
#4
Re: If I use ANSI Functions but Compile Unicode is my project still Unicod
Posted 06 August 2011 - 08:40 AM
What do you think ANSI vs Unicode means when compiling?
#5
Re: If I use ANSI Functions but Compile Unicode is my project still Unicod
Posted 06 August 2011 - 08:42 AM
#6
Re: If I use ANSI Functions but Compile Unicode is my project still Unicod
Posted 06 August 2011 - 08:43 AM
He's not asking what Unicode is, rather what the compiler setting means.
The answer I would say is yes, but it would not display Asian characters.
Edit: MessageBoxW works when compiled as ASCII.
The answer I would say is yes, but it would not display Asian characters.
Edit: MessageBoxW works when compiled as ASCII.
This post has been edited by PlasticineGuy: 06 August 2011 - 08:45 AM
#7
Re: If I use ANSI Functions but Compile Unicode is my project still Unicod
Posted 06 August 2011 - 08:52 AM
OK, people need to do some significant reading about Unicode.
Start with Joel Spolsky's article on Unicode.
Then search for MSDN topics on Unicode and MBCS .
Start with Joel Spolsky's article on Unicode.
Then search for MSDN topics on Unicode and MBCS .
#8
Re: If I use ANSI Functions but Compile Unicode is my project still Unicod
Posted 06 August 2011 - 09:40 AM
Unicode in windows uses wide characters. that is it uses 16 bit values not 8bit ones. So for example if you define UNICODE before you #include windows.h and then write a line like:
MessageBoxA(NULL, TEXT("This is test"), TEXT("Did this display properly?"), MB_YESNO);
you will get an error because the TEXT macro ensures that "This is a test" is made into L"This is a test" and so the call will result in an error saying that there is no conversion from const wchar_t[13] to LPCSTR
However if you avoid using the TEXT macro and just call the ASCII version of the function with ascii strings then everything will be fine:
MessageBoxA(NULL, "This is test", "Did this display properly?", MB_YESNO);
The above will compile just fine if UNICODE is enabled or not.
Now if you try to force an ascii method to use a unicode string you will get really odd runtime errors:
MessageBoxA(NULL, (const char*)TEXT("This is test"), "Did this display properly?", MB_YESNO);
This works... but only displays T in the message box. because the wide char T is { 0x54 0x00 }
So I don't really know what you mean by " is my project still Unicode?"
If you properly called the GetComputerNameA then it would work on any windows OS that had that function available in its API. I have no idea of Asian versions of windows have the ascii versions of functions available but I would imagine so... so sure. the program will work so long as you properly called the function.
MessageBoxA(NULL, TEXT("This is test"), TEXT("Did this display properly?"), MB_YESNO);
you will get an error because the TEXT macro ensures that "This is a test" is made into L"This is a test" and so the call will result in an error saying that there is no conversion from const wchar_t[13] to LPCSTR
However if you avoid using the TEXT macro and just call the ASCII version of the function with ascii strings then everything will be fine:
MessageBoxA(NULL, "This is test", "Did this display properly?", MB_YESNO);
The above will compile just fine if UNICODE is enabled or not.
Now if you try to force an ascii method to use a unicode string you will get really odd runtime errors:
MessageBoxA(NULL, (const char*)TEXT("This is test"), "Did this display properly?", MB_YESNO);
This works... but only displays T in the message box. because the wide char T is { 0x54 0x00 }
So I don't really know what you mean by " is my project still Unicode?"
Quote
I use GetComputerNameA instead of GetComputerName and compile my project as Unicode. Will it still work on Asian OSes?
If you properly called the GetComputerNameA then it would work on any windows OS that had that function available in its API. I have no idea of Asian versions of windows have the ascii versions of functions available but I would imagine so... so sure. the program will work so long as you properly called the function.
Page 1 of 1
|
|

New Topic/Question
Reply




MultiQuote







|