Re: GCC

[prev] [thread] [next] [lurker] [Date index for 2004/08/24]

From: Daniel Pittman
Subject: Re: GCC
Date: 04:55 on 24 Aug 2004
On 24 Aug 2004, Peter da Silva wrote:
> So, do all these flags really turn off the "expression ?: expression" kludge?
>
> [Secondary hate, mail clients that pay attention to charset
> interacting with mail clients that take the golden rule to an absurd
> level by ignoring charset on input and selecting some weird
> platform-specific charset on output. Why would an application on an OS
> that has Unicode built in to it at a low level send messages in
> Windows-1251 or whatever?]

I worked with that particular level of that OS, and their Unicode
"support" is a matter of hate in itself.

Aside from their insistence on having two byte-orderings for wide
characters, and their recommendation to implement the "byte order mark"
because, well, they were going to do so anyway and the rest of the world
better keep up...

...They have the Unicode specific functions available on all their
platforms, including Win31 derivatives from Win98 up, as well as the
"ANSI" versions which use an encoding like ISO-8859-* or Win1251
(because they needed the extra code points, and the rest of the world
better keep up...)

When you build your code you can either call the specific charset
version as 'MySillyNameEx2A' or 'MySillyNameEx2W', or you can use the
"unqualified" name and get the 'W' version of use specify -DUNICODE to
the compiler, or the 'A' version otherwise.

If you use a 'W' version explicitly, though, your code will never run on
Windows 95, which was a key consideration for many years, because the
exported API didn't include them, even if NT did.

If you use them on Win98 those API slots are present, so you can compile
with '-DUNICODE' and have it load on Win98 *and* WinNT.

You better not expect it to run, though. They implemented *four* 'W' API
calls -- convert this from 'W' encoding and convert this to 'W'
encoding, and IIRC, UTF8 equivalents or something similar to that.

Everything else would return an error code indicating 'NOT IMPLEMENTED'.


So, supporting Unicode means you chose between (a) NT only, (b) writing
your own wrappers that detect the platform and handle conversions to and
from Unicode at *every* API call, or (c) just pretend that Unicode
doesn't exist, except if you *have* to convert right at the edges of
your code.


Writing those wrappers, for reference, involves around 800 API calls for
a modest application, and there was *no* way that I could find of doing
it automatically without a full blown C and C++ parser.

This is, in part, because using a 'W' function routinely takes a
different C structure than the 'A' version, to account for the wider
string types stored in it.


While XP is fairly sucky in and of itself, it represents a huge step
forward in the world, because it will eventually be the death of the
Win31 derived OS branch, which is only a good thing for us all.

       Daniel

PS: It also bothers me slightly that I still have this much hate after
getting out of the Windows game some ... six years ago now, I think.

-- 
It's clear that whoever set up the font colorings for most programming
modes has seen too many Peter Max posters, or did more acid than I did
in the 60's.
        -- Charles R. Martin, _gnu.emacs.help_

Generated at 15:00 on 24 Aug 2004 by mariachi 0.52