At 05:22 PM 12/17/96 -0800, you wrote:
>You are correct in saying that secondary apps need to be in Unicode. But as a
>developer of such secondary apps on Win95/WinNT, I find it frustrating that
>sdk forces you to go to either MBCS or UNICODE at compile time.
I couldn't agree with you more. I'm deeply mired in attempting to build
a cross-platform product (win,mac,8 unix flavors,qnx,os/9,psos,...) written
primarily in C and consistently use UCS-2 character data throughout. The
most significant problems I face are:
1. lack of compiler support for wchar_t (and wide string literals in
particular); or if a compiler supports wchar_t, then lack of control
over whether 16-bits or 32-bits are used.
2. lack of standard runtime support for wchar_t signatures; i.e., there
needs to be a standard set of wcs entry points for string.h, ctype.h,
stdlib.h, stdio.h, etc.
3. inconsistent API support for wchar_t, here I'm thinking of WIN32 in
its three primary flavors (NT, WIN95, WIN32S), or even no support (MacOS)
or extremely little support (X Window System).
4. lack of support in IDEs for wchar_t string display (MSVC is ok, others
I don't even need to go into the problems with fonts and font technologies
(GX or TT Open? or TrueDoc or ???).
As a practical matter, I'd certainly like to find a way to put pressure
on tool and language and os vendors to get their act together in this
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:33 EDT