Unicode

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Bonj (Bonj_at_discussions.microsoft.com)
Date: 12/06/04 

Date: Mon, 6 Dec 2004 08:53:02 -0800

Can anyone please answer me the following questions on unicode apps?

1) I'm building an application that needs to interact with BSTRs, so it is
natural to compile it as unicode. Extra work needs to be done for the
functions I'm building to accept MBCS strings, i.e. it needs to convert them
to a wide-char string using mbstowcs in order for the BSTR to be constructed.
Should I, either:

 a*) model the prototypes as accepting widechar strings, and think 'well if
I need to call them with MBCS, I'll cross that bridge when I come to it' ?
 b*) model the prototypes as accepting widechar strings, and build MBCS
wrappers because I might need to do an ASCII build, because that is the only
way of getting it to work on Win98 ?
 c*) model the prototypes as accepting generic _TCHAR*s, and put in the
extra conversion code required in an #ifdef _UNICODE...#endif block, safe in
the knowledge that when/if I do do a non-unicode build, it will be OK?

2) If I choose (a), which if any of the following compatibility problems
would I have?
  * my packaged app (exe) would refuse to work at all on windows '98
  * my app would function ok if distributed as a whole, but my libraries
(DLLs) wouldn't be callable by clients passing MBCS strings
  * my app would be fine if I only ever intended to distribute it in one
language

3) If I choose (b), would this mean that my application would work on
windows 98 whereas it otherwise wouldn't have? I'm picturing an EXE, sending
MBCS strings to DLLs, which then convert them to widechars, in order to
interact with BSTRs.
Is this necessary AND possible? (I hope I've put this question in an
understandable way...)
What I mean is, I strongly suspect that doing an MBCS build and applying
conversion code, would be *either* unnecessary because win98 can handle
unicode, *or* impossible, because it can't handle unicode *at all*.
I'm just looking to find out which it is, and to clear up my confusion about
compatibility issues with unicode and windows 98, as I suspect I have heard
garbled rumours some of which may be true some aren't, and would just like to
know what compatibility issues there are, if any.

Basically, I'm looking for *either*:
reassurance that using unicode throughout and not bothering with MBCS at all
is perfectly OK,
*OR*
a simple way of converting MBCS strings to BSTRs,
*OR*
hints on the "standard" way in which people implement any issues there might
be

Relevant Pages

  • Re: Why C#? CPU independent?
    ... my app is very UI intensive. ... such as VB and MFC. ... his program's load time became four seconds. ... WinMo only supports Unicode. ...
    (microsoft.public.pocketpc.developer)
  • Getting UNICODE characters from wcin in a Console app
    ... Can anyone explain why I can't get Unicode code points out of what I ... type into a console app? ... Clearly that's because the console I'm running the app in is in the ...
    (microsoft.public.vc.language)
  • Re: Populating CString in Win32 dll interface that accepts LPCTSTR
    ... and I want a string to be populated by calling this inside a UNICODE ... CString str; ... If your app is Unicode, and your DLL returns 8-bit characters, you would declare ...
    (microsoft.public.vc.mfc)
  • Re: Problem with GetTextMetrics and Unicode
    ... > I am in the process of converting one of my apps to Unicode and have ... > GetTextMetrics in my Paint function I get a runtime error when the ... > 'textmetrics' variable. ... If I run the app outside of the debugger I ...
    (microsoft.public.win32.programmer.gdi)
  • Re: Unicode
    ... >1) I'm building an application that needs to interact with BSTRs, ... >natural to compile it as unicode. ... >I need to call them with MBCS, I'll cross that bridge when I come to it'? ... > b*) model the prototypes as accepting widechar strings, ...
    (microsoft.public.vc.language)