Using Unicode with plugin DLLs
Author
I''m working on a plugin system for my app. What happens if a Unicode DLL is loaded by an app compiled for ANSI, and vice versa? I''m guessing the strings can be misinterpreted if they are exchanged between the two. What sort of techniques do people use to get around this? I was thinking on insisting that a minimum portion of the interface be in ANSI to make things easier.
The second byte of more common unicode characters is zero. This will be interpretted as a null terminator when sent to a function that expects ansi.
Generally, you should pick one of the other and write for that, but in case you need to convert between the two here''s some sample code. Also look into IsTextUnicode.
"It is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of their leaders. That is easy. All you have to tell them is that they are being attacked and denounce the peacemakers for lack of patriotism and exposing the country to danger. It works the same in any country."
Hermann Goering
Generally, you should pick one of the other and write for that, but in case you need to convert between the two here''s some sample code. Also look into IsTextUnicode.
// ----------------------------------------------------------------------------////BOOL UnicodeToAnsi( LPWSTR pszwUniString, LPSTR pszAnsiBuff, DWORD dwAnsiBuffSize ){ int iRet = 0; iRet = WideCharToMultiByte( CP_ACP, 0, pszwUniString, -1, pszAnsiBuff, dwAnsiBuffSize, NULL, NULL ); return ( 0 != iRet );}// ----------------------------------------------------------------------------////BOOL AnsiToUnicode( LPSTR pszAnsiString, LPWSTR pszwUniBuff, DWORD dwUniBuffSize ){ int iRet = 0; iRet = MultiByteToWideChar( CP_ACP, 0, pszAnsiString, -1, pszwUniBuff, dwUniBuffSize ); return ( 0 != iRet );} "It is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of their leaders. That is easy. All you have to tell them is that they are being attacked and denounce the peacemakers for lack of patriotism and exposing the country to danger. It works the same in any country."
Hermann Goering
another solution is to export two entry points for all functions taking string arguments:
SomeFunctionA, which takes in ansi strings, and
SomeFunctionW, which takes in unicode strings.
this is now winapi generally works. now, for a particular product:
- if it''s a dll-exe issue, as you said, easiest thing to so is just make sure that ansi dll can''t be linked to unicode exe, or vice versa.
- if the issue is interoperability between ansi and unicode modules running concurrently at the same system, you''ll have to handle both ansi and unicode input and output on at least one of them.
SomeFunctionA, which takes in ansi strings, and
SomeFunctionW, which takes in unicode strings.
this is now winapi generally works. now, for a particular product:
- if it''s a dll-exe issue, as you said, easiest thing to so is just make sure that ansi dll can''t be linked to unicode exe, or vice versa.
- if the issue is interoperability between ansi and unicode modules running concurrently at the same system, you''ll have to handle both ansi and unicode input and output on at least one of them.
Author
The MS Layer for Unicode looks to be what I want. Anyone used it before? By using that I can just have plug-in creators only create Unicode plugins, and only maintain a Unicode version of the executable.
Unicode is native for NT/2K/XP - so I assume by "MS Layer for Unicode" you are referring to the unicode helper dll for W9x that MS recently released?
What this means is that on NT, functions that take Ansi strings, usually convert them to Unicode before passing them to a call to the Unicode version of a routine.
void somefuncA(LPSTR lpAnsi)
{
// convert to unicode
somefuncW(lpWide);
}
And on 9x the Unicode layer probably does the opposite - convert unicode to ansi and call the corresponding ansi routine.
Using Unicode on NT should make for faster code, Unicode on 9x for slower.
As niyaw pointed out - the A & W suffixes can be used to indicate what kind of string a given function expects. If you make your routines Unicode based, you should probably indicate so by appending a W to the function name.
"It is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of their leaders. That is easy. All you have to tell them is that they are being attacked and denounce the peacemakers for lack of patriotism and exposing the country to danger. It works the same in any country."
Hermann Goering
What this means is that on NT, functions that take Ansi strings, usually convert them to Unicode before passing them to a call to the Unicode version of a routine.
void somefuncA(LPSTR lpAnsi)
{
// convert to unicode
somefuncW(lpWide);
}
And on 9x the Unicode layer probably does the opposite - convert unicode to ansi and call the corresponding ansi routine.
Using Unicode on NT should make for faster code, Unicode on 9x for slower.
As niyaw pointed out - the A & W suffixes can be used to indicate what kind of string a given function expects. If you make your routines Unicode based, you should probably indicate so by appending a W to the function name.
"It is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of their leaders. That is easy. All you have to tell them is that they are being attacked and denounce the peacemakers for lack of patriotism and exposing the country to danger. It works the same in any country."
Hermann Goering
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
