Mohan Build 22.5.03

[João Garcia]

Hi,

fernando@lozano.eti.br wrote:
> 
> Actually many of the Win32 API has two versions,
> one using unicode and the other using Latin-1 or some other encoding for
> japanase and arabic Windows.
> 

There are two versions for each function. The 'A'-version (8-bit codes) 
and the 'W'-version (16-bit codes). But I think that the 'W'-version 
uses some sort of UTF-16. Win9x supports only 'A' versions. The NT 
branch supports both versions.


Some references about Unicode:
http://www.cl.cam.ac.uk/~mgk25/unicode.html
http://www.unicode.org/standard/WhatIsUnicode.html

And quoting from the 2nd URI:
"UCS and Unicode are first of all just code tables that assign integer 
numbers to characters. There exist several alternatives for how a 
sequence of such characters or their respective integer values can be 
represented as a sequence of bytes."



> Java by the spec uses unicode all the time internally, so libcj should do
> different conversions depending on the OS it's running. 

It seems an interesting ideia. But I am not sure that it'll get any 
faster (you might have to convert from one 16-bit encoding to another). 
You will always need the 'A'-versions anyway, if you want to have 
applications compatible with Win9x. And the NT branch has 'A'-versions.

The patch addresses *only* 'A'-versions (supporting Win9x and NT/2000/XP).

If I can get the diffs right, I will be sending the patch in a short 
while. That is if I don't go to sleep before that... ;-)


On the other hand, if we follow, has suggested, the 'W'-versions path, 
we can always use "Microsoft Layer for Unicode on Windows 95/98/Me 
Systems". You can read more about it here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mslu/winprog/microsoft_layer_for_unicode_on_windows_95_98_me_systems.asp

But that doesn't seem a good idea for this project... ;-)


João