D strings are meant to be in Unicode.  However, when this is done, they are incompatible with Windows unless you use wchars and the W versions of Windows API functions.

At the moment, SDWF works with char[]s and passes them as are to the Windows API.  This means that it expects strings to be in the local 8-bit character set, contrary to the rules of the D road.

I can see a few ideas:

(a) Use toMBSz to convert char[] to the system character set.  It ought to be moved from std.file to somewhere more appropriate.  And write the corresponding fromMBSz.  But this would mean that, although the programmer can work in UTF-8, the app still can't use any characters outside the local 8-bit charset.

(b) Convert UTF-8 to UTF-16 and use the W versions of WinAPI functions.  But having to convert every string might be a performance hit.

(c) Change the functions to use wchars instead of chars, and call the W versions directly.

(d) Complicate the library by adding a run-time check of whether the A or W versions should be used.  This would probably be a bit too much complication, considering the need to retain WinAPI structures in memory.


As for (b) and (c), I'm confused by information on the support for W functions in different Windows versions.  On one hand, comments in both the MSDN site and Phobos code are to the effect that Win9x doesn't support any W functions.  Yet at least one version of the Win32 reference (that which came with Borland C++Builder 1.0, apparently between Win95 being released and Win98 being conceived) mentions Unicode support for the various functions as "Yes", "WinNT" or "No".  I haven't experimented to see which is correct....

I've just discovered the Microsoft Layer for Unicode.  But is this a library that links into your program, or a run-time support package?


Recommendations?  What if anything have other GUI libraries done, for that matter?

That asked, I don't know when the transition's going to happen.  But probably when the translation of the Windows API headers is somewhere near complete.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- a->--- UB@ P+ L E@ W++@ N+++ o K- w++@ O? M V? PS- PE- Y?
PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.

> I've just discovered the Microsoft Layer for Unicode.  But is this a library that links into your program, or a run-time support package?

As far as i know it, the user downloads and installs the Microsoft Layer for Unicode, and then programs using the W functions can run.

Ciao
uwe

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:dei3vn$1j4$1@digitaldaemon.com...
> (b) Convert UTF-8 to UTF-16 and use the W versions of WinAPI functions.
>   But having to convert every string might be a performance hit.

I believe this is the best version (as implemented in std.file). It won't be a performance hit because:

1) Windows NT, 2000, XP are all internally W. The A functions are converted internally by Windows itself to W.

2) Generally speaking, API calls are not made in time critical loops, it just isn't the nature of them.


> (c) Change the functions to use wchars instead of chars, and call the W
> versions directly.

That'll work, too, but you'll still need special handling for Win9x.

> As for (b) and (c), I'm confused by information on the support for W functions in different Windows versions.  On one hand, comments in both the MSDN site and Phobos code are to the effect that Win9x doesn't support any W functions.  Yet at least one version of the Win32 reference (that which came with Borland C++Builder 1.0, apparently between Win95 being released and Win98 being conceived) mentions Unicode support for the various functions as "Yes", "WinNT" or "No".  I haven't experimented to see which is correct....

Win95 does support a handful of W functions. I'm not sure which, though.

> I've just discovered the Microsoft Layer for Unicode.  But is this a library that links into your program, or a run-time support package?

I checked in to that. It's a waste of time. It's an add-on library that is NOT a part of Win9x so you have to muck about with distributing/installing it on your customers' machines. All it does is what std.file does internally anyway. Why bother?

I recommend using the approach used by std.file. It's simple, tested, and works.

> (d) Complicate the library by adding a run-time check of whether the A or W versions should be used.  This would probably be a bit too much complication, considering the need to retain WinAPI structures in memory.

This is what DFL does by default, and there are compile-time versions for using just 'A' or 'W'.

Stewart Gordon escribió:
> D strings are meant to be in Unicode.  However, when this is done, they are incompatible with Windows unless you use wchars and the W versions of Windows API functions.
> 
> At the moment, SDWF works with char[]s and passes them as are to the Windows API.  This means that it expects strings to be in the local 8-bit character set, contrary to the rules of the D road.
> 
> I can see a few ideas:
> 
> (a) Use toMBSz to convert char[] to the system character set.  It ought to be moved from std.file to somewhere more appropriate.  And write the corresponding fromMBSz.  But this would mean that, although the programmer can work in UTF-8, the app still can't use any characters outside the local 8-bit charset.

I used this approach for Apollo.

I also asked Walter to move toMBSz (on 2004-06-30, "[request] toMBSz"), but he asked again "why move it?".

-- 
Carlos Santander Bernal

Carlos Santander wrote:
<snip>
> I also asked Walter to move toMBSz (on 2004-06-30, "[request] toMBSz"), but he asked again "why move it?".

Because it's absurd to import std.file to get functionality that has nothing to do with files.

We should move useWfuncs, toMBSz and the associated initialisation into a module under std.windows.  And write fromMBSz while we're at it.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- a->--- UB@ P+ L E@ W++@ N+++ o K- w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Walter wrote:
<snip>
>> I've just discovered the Microsoft Layer for Unicode.  But is this a
>> library that links into your program, or a run-time support package?
> 
> I checked in to that. It's a waste of time. It's an add-on library that is
> NOT a part of Win9x so you have to muck about with distributing/installing
> it on your customers' machines. All it does is what std.file does internally
> anyway. Why bother?

By your last sentence, do you mean:
(a) it doesn't contain the W functions related to GUI programming?
(b) all the GUI-related W functions are built in to Win9x anyway?
(c) contrary to the info on the website, MSLU doesn't enable apps to use the full Unicode character set (or even the portion below FFFF) under Win9x?

> I recommend using the approach used by std.file. It's simple, tested, and
> works.

Not so simple when you've got to store WinAPI structures.  Look at the common dialog classes in SDWF for example.  If this approach is used, the size of these structures will be known only at runtime.  A possibility might be to use a union or allocate it dynamically, but issues remain:

- Members of these structures can no longer be directly accessible from the app programmer's POV, so I'd have to write more getter and setter functions (not that that would be difficult).

- These classes generally allow the app to retrieve the whole structure, making it possible to call Windows API functions directly for more advanced stuff.  Part of SDWF's design is not to stop you from turning to the WinAPI for more advanced stuff.  If the size of the structure is variable at runtime, then should I convert it on the fly to ANSI and lose characters outside its range?  To UTF-16?  Or expect the app to look at useWfuncs and decide which to retrieve?

- What about where a single character is desired?  Look at EditBox.passwordChar for example.  Should I just have it take a wchar and convert it if necessary?  And if the conversion fails, throw an exception?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- a->--- UB@ P+ L E@ W++@ N+++ o K- w++@ O? M V? PS- PE- Y?
PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.

Stewart Gordon wrote:
> Walter wrote:
> <snip>
> 
>>> I've just discovered the Microsoft Layer for Unicode.  But is this a
>>> library that links into your program, or a run-time support package?

DLL's that exports funcW's as well as funcA's, to make the older
Windows versions more API comaptible with NT.

>> I checked in to that. It's a waste of time. It's an add-on library that is
>> NOT a part of Win9x so you have to muck about with distributing/installing
>> it on your customers' machines. All it does is what std.file does internally
>> anyway. Why bother?
> 
> 
> By your last sentence, do you mean:
> (a) it doesn't contain the W functions related to GUI programming?
> (b) all the GUI-related W functions are built in to Win9x anyway?
> (c) contrary to the info on the website, MSLU doesn't enable apps to use the full Unicode character set (or even the portion below FFFF) under Win9x?

(a) It does. But they are wrappers for the A funtions. Takes the W
    parameters and converts to 8-bits strings needed for the A functions
    according to the codepage settings on the customer computer. And back
    for return values.
(b) No gui related W functions are built into Win 9x/Me. (AFAIK)
(c) MSLU allows apps to be created to use WIN32 Unicode API as supported
    on NT2K/XP, and the MSLU system will supposedly handle the convertion
    to/from wchar/active codepage on client computer transparently for the
    application. How well this works in practice I cannot tell, I have never
    used it.

This depends on what you want to make. If the target is a commercially
distributed application, you can not get by without an installer anyway,
and little effort is needed to add the MSLU installation in that case.

Roald

Roald Ribe wrote:
<snip>
> (c) MSLU allows apps to be created to use WIN32 Unicode API as supported     on NT2K/XP, and the MSLU system will supposedly handle the convertion     to/from wchar/active codepage on client computer transparently for the     application. How well this works in practice I cannot tell, I have     never used it.

That doesn't answer the question of what it does with characters that don't exist in the active codepage.  Throw them out?  Generate 'invalid character' squares?  Switch to a substitute font to display these characters?

For that matter, yet another piece of supporting evidence that Win9x supports Unicode is the handful of Unicode fonts on my system.  And even some of the 'regular' ones have more than just the characters of 1252 in them.  How does this work exactly?

> This depends on what you want to make. If the target is a commercially distributed application, you can not get by without an installer anyway, and little effort is needed to add the MSLU installation in that case.

I'm hoping that my lib will work well ITLR for free and commercial apps alike.  Installed by an install program or simply copying files alike.

This in itself would be a step ahead of some apps that do have install programs.  For example, when trying to get SiSoftware Sandra to work, I found that I needed two system add-ons that were absent from the package.  One to run the install program and another to run it once it was installed.  One of them was Microsoft Data Access Components, and I forget what the other one was.

I suppose that for a program that doesn't have an installer, it isn't too bad to require such things, as long as this is made clear on the website/readme files/wherever.  But still, is it really sensible for a library, and hence all programs written using it, to require a third-party add-on?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- a->--- UB@ P+ L E@ W++@ N+++ o K- w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> That doesn't answer the question of what it does with characters that don't exist in the active codepage.  

You did not ask any such question...

> Throw them out?  Generate 'invalid character' squares?  Switch to a substitute font to display these characters?

I would venture to guess that there are no alternatives, it would
generate an invalid 8-bit character code, which would in most
cases be rendered as a "square".
But I think that if you are serious about wanting this information,
you will have to start reading the MSDN documentation/help texts.
And test.

> For that matter, yet another piece of supporting evidence that Win9x supports Unicode is the handful of Unicode fonts on my system.  And even some of the 'regular' ones have more than just the characters of 1252 in them.  How does this work exactly?

If you feel you have evidence of how things are, why not base
your decisions on that? Again, if you need information about
how ms-win works in pratice, I suspect you need to read up on
it. The fact that you seem to know very little about fonts/faces/glyphs
and rendering of text, should indicate to you that you are not
able to determine what _is_ evidence in this case. Very short:
number of glyphs in a face (commmonly called a font), and number
of diplayable characters in a renderable character set, on a given
platform, has no equality or linear releation to each other.

Roald