Of wchar_t and WCHAR and incompatibilities....

[Subhobroto Sinha]

As most of you might be aware, I and Robert are progressing with a Start Menu.

All the functionality is there now (except menu icons, and shell namespaces..).

However, I had to write a .lnk parser for it and till date, I made it compatible ONLY with UTF-8 and thus did not require to use glibc's Unicode functions.

Today, I was getting dirty with a full blown Unicode implementation and I noticed that GNU defines a wchar_t as an (unsigned long) - it's 4 bytes long, wheras a WCHAR (which is a typedefed wchar_t) is an (unsigned short) on Windows !

As a result, Unicode strings on Windows are unsigned long arrays and thus I had to convert them into glibc's own wchar_t format using a hack like this:

void ConvertWCHARTo_wchar_t(const WCHAR* wszIn,wchar_t* wszOut)
{
    if(wszIn) while(*wszOut++=*wszIn++);
}

and vice versa for the opposite conversion.

Believe me, it works, but not always... (any body interested in debugging with the source, please ask me for it..)

Any sugestions as to handle the situation please?
I need to use GLibc's Unicode functions and NOT WINE's implmentation of Mutibyte...(), because I want to keep the .lnk parser in pure C++

Regards

Subhobroto Sinha

[Dan Kegel]

Subhobroto Sinha wrote:
> As most of you might be aware, I and Robert are progressing with a Start Menu.

Yay!
> However, I had to write a .lnk parser for it and till date, I made it compatible ONLY with UTF-8 and thus did not require to use glibc's Unicode functions.

I'm personally a huge fan of Unicode and utf-8, but
I wonder if it's practical to not support other encodings...
> void ConvertWCHARTo_wchar_t(const WCHAR* wszIn,wchar_t* wszOut)
> {
>    if(wszIn) while(*wszOut++=*wszIn++);
> }
>
> and vice versa for the opposite conversion.
>
> Believe me, it works, but not always... (any body interested in debugging with the source, please ask me for it..)

That looks pretty ugly.  Might be a sign you want to rethink a bit.
> Any sugestions as to handle the situation please?
> I need to use GLibc's Unicode functions and NOT WINE's implmentation of Mutibyte...(), because I want to keep the .lnk parser in pure C++

I was under the impression that we were trying very hard to
make sure that most parts of Wine could compile and run on
pure Windows.  (What better way to verify correctness than
to demonstrate that a .dll or .exe obeys Win32 properly than
to run it in Win32's native environment?)
Thus it seems to me you'd want to base the Start menu program
not on glibc's unicode support, but rather on Windows' 
internationalization...
- Dan

[Steven Edwards]

--- Dan Kegel  wrote:
> Subhobroto Sinha wrote:
> > As most of you might be aware, I and Robert are progressing with a
>
> Start Menu.
>
> Yay!
> > However, I had to write a .lnk parser for it and till date, I made
>
> it compatible ONLY with UTF-8 and thus did not require to use glibc's
> Unicode functions.

You guys may be interested in a comming patch from the ReactOS team. We
have done a lot of work on shell32 as of late to handle the Start Menu
and Shell Namespace stuff. It should all get merged when Alexandre
returns from vacation.

Thanks
Steven

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

[Troy Rollo]

On Fri, 26 Dec 2003 05:50, Subhobroto Sinha wrote:
> As a result, Unicode strings on Windows are unsigned long arrays and thus I
> had to convert them into glibc's own wchar_t format using a hack like
> this:
> void ConvertWCHARTo_wchar_t(const WCHAR* wszIn,wchar_t* wszOut)
> {
>    if(wszIn) while(*wszOut++=*wszIn++);
> }
> ...
> Believe me, it works, but not always...

You haven't mentioned what your bug is, however Windows doesn't really use 
Unicode (UCS-4, a 32 bit character set), nor does it use 16 bit unicode 
(UCS-2). It uses UTF-16, in which there are a couple of ranges of characters 
used to create two-word sequences to represent a larger chunk of UCS-4. Your 
code doesn't deal with that.