www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - UTFs and GUI libraries

reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Aug 24 2005
next sibling parent "Uwe Salomon" <post uwesalomon.de> writes:
 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
Aug 24 2005
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Aug 24 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Aug 25 2005
next sibling parent reply Roald Ribe <rr.nospam nospam.teikom.no> writes:
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
Aug 25 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Aug 25 2005
next sibling parent reply Roald Ribe <rr.nospam nospam.teikom.no> writes:
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
Aug 25 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Roald Ribe wrote:
 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...
I did start to, right here:
 By your last sentence, do you mean:
<snip>
 (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?
What did you interpret it as meaning?
 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.
Maybe when I've time ... and when I've a clue of which bit of the MSDN documentation you mean....
 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?
Because I don't really have evidence of _how_ things are, only of _what_ things are.
 Again, if you need information about how ms-win works in pratice, I
 suspect you need to read up on it.
If you know of a decent source, how about sharing it with the rest of us?
 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.
Do you mean a Win9x font can supply glyphs for as many characters in as many codepages as it likes? Do Office apps, web browsers and the like make them accessible by hopping between codepages, tapping into the font data directly, or what? 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.
Aug 26 2005
parent Roald Ribe <rr.nospam nospam.teikom.no> writes:
Stewart Gordon wrote:
 Roald Ribe wrote:
 
 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...
I did start to, right here:
 By your last sentence, do you mean:
<snip>
 (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?
What did you interpret it as meaning?
"Enable apps to use" and "what it does with characters that doesn't exist" has two quite distinct and different meanings to me. But the problem may be that I am not a native english speaker? ;-)
 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.
Maybe when I've time ... and when I've a clue of which bit of the MSDN documentation you mean....
Just search for MSLU, you will find it.
 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?
Because I don't really have evidence of _how_ things are, only of _what_ things are.
 Again, if you need information about how ms-win works in pratice, I
 suspect you need to read up on it.
If you know of a decent source, how about sharing it with the rest of us?
Nothing is quite that simple. And you can not do your technical reasearch on such a latge subject based on replies in a news group. The answers would be so long I would be writing all day.
 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.
Do you mean a Win9x font can supply glyphs for as many characters in as many codepages as it likes? Do Office apps, web browsers and the like make them accessible by hopping between codepages, tapping into the font data directly, or what?
It looks like a few of the 9x API's has W implementations out of the box. Partial unicode font functionality _may_ be available, but I do not have the time to wade the doc to find out. Yes, if word processors running on 9x supports more than 256 chatacters in one font/face, I expect they do so with some serious internal set/font mapping and has extensive internal libraries to handle the situation. Roald
Aug 26 2005
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:deku35$28fc$1 digitaldaemon.com...
 But still, is it really sensible for a
 library, and hence all programs written using it, to require a
 third-party add-on?
Avoid that if at all possible.
Aug 25 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:dek9pd$1778$1 digitaldaemon.com...
 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? All it does is attempt to translate UTF into the local character set on an api-by-api basis, essentially what std.file does. It does not transform Win9x into a Unicode-supporting operating system.
 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?
Do not use a variable struct size. Perhaps have two structs, one for A and one for W, and a conversion routine between them.
 - 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?
Where a single character is used, make it a dchar (not a wchar). Then, convert as necessary when calling a Windows API function. If the conversion fails, throw an exception. If, for example, you have Japanese characters in UTF and attempt to convert them to the local character set on an American version of Win95, it will fail. It won't work using MSLU, either, because MSLU does not transform Win9x into a unicode supporting operating system. All MSLU does is attempt to translate UTF to/from the local character set. I wouldn't worry *too* much about Win9x, because Win95 is 10+ years old now, and has no future. Just write the code to do a reasonable job if it can, and fail reasonably when it can't.
Aug 25 2005
parent reply "John C" <johnch_atms hotmail.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:delup9$6df$1 digitaldaemon.com...
 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
 news:dek9pd$1778$1 digitaldaemon.com...
 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? All it does is attempt to translate UTF into the local character set on an api-by-api basis, essentially what std.file does. It does not transform Win9x into a Unicode-supporting operating system.
 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?
Do not use a variable struct size. Perhaps have two structs, one for A and one for W, and a conversion routine between them.
 - 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?
Where a single character is used, make it a dchar (not a wchar). Then, convert as necessary when calling a Windows API function. If the conversion fails, throw an exception. If, for example, you have Japanese characters in UTF and attempt to convert them to the local character set on an American version of Win95, it will fail. It won't work using MSLU, either, because MSLU does not transform Win9x into a unicode supporting operating system. All MSLU does is attempt to translate UTF to/from the local character set. I wouldn't worry *too* much about Win9x, because Win95 is 10+ years old now, and has no future. Just write the code to do a reasonable job if it can, and fail reasonably when it can't.
Many sources indicate that fewer than 5% of Windows users are on versions earlier than Windows 2000. If I were weighing the options, I'd conclude that it wasn't worth the extra effort or expense to support 95/98/ME. A lot of ISVs (and Microsoft itself, most notably with Office 2003) no longer develop for those operating systems. You won't be limiting your potential market too much.
Aug 26 2005
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"John C" <johnch_atms hotmail.com> wrote in message
news:demiif$rjc$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 I wouldn't worry *too* much about Win9x, because Win95 is 10+ years old
 now,
 and has no future. Just write the code to do a reasonable job if it can,
 and
 fail reasonably when it can't.
Many sources indicate that fewer than 5% of Windows users are on versions earlier than Windows 2000. If I were weighing the options, I'd conclude
that
 it wasn't worth the extra effort or expense to support 95/98/ME. A lot of
 ISVs (and Microsoft itself, most notably with Office 2003) no longer
develop
 for those operating systems. You won't be limiting your potential market
too
 much.
There's another aspect to those users still sticking with Win9x - since they haven't upgraded to a newer Windows, what are the odds they're interested in the new software one is developing?
Aug 26 2005
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter wrote:
<snip>
 There's another aspect to those users still sticking with Win9x - 
 since they haven't upgraded to a newer Windows, what are the odds 
 they're interested in the new software one is developing?
It probably correlates with the ratio of the cost of modernising your system to the cost of the new software. 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.
Aug 26 2005
prev sibling parent reply Roald Ribe <rr.nospam nospam.teikom.no> writes:
Walter wrote:
 "John C" <johnch_atms hotmail.com> wrote in message
 news:demiif$rjc$1 digitaldaemon.com...
 
"Walter" <newshound digitalmars.com> wrote in message

I wouldn't worry *too* much about Win9x, because Win95 is 10+ years old
now,
and has no future. Just write the code to do a reasonable job if it can,
and
fail reasonably when it can't.
Many sources indicate that fewer than 5% of Windows users are on versions earlier than Windows 2000. If I were weighing the options, I'd conclude
that
it wasn't worth the extra effort or expense to support 95/98/ME. A lot of
ISVs (and Microsoft itself, most notably with Office 2003) no longer
develop
for those operating systems. You won't be limiting your potential market
too
much.
There's another aspect to those users still sticking with Win9x - since they haven't upgraded to a newer Windows, what are the odds they're interested in the new software one is developing?
This is a good point, often forgotten in the quest to support as many as possible. Users not upgrading their OS, are not likely to buy new software. Roald
Aug 26 2005
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Roald Ribe wrote:
<snip>
 This is a good point, often forgotten in the quest to support
 as many as possible. Users not upgrading their OS, are not likely
 to buy new software.
But I'm sure millions of such people download new software. 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.
Aug 31 2005
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
John C wrote:
<snip>
 Many sources indicate that fewer than 5% of Windows users are on versions 
 earlier than Windows 2000. If I were weighing the options, I'd conclude that 
 it wasn't worth the extra effort or expense to support 95/98/ME. A lot of 
 ISVs (and Microsoft itself, most notably with Office 2003) no longer develop 
 for those operating systems. You won't be limiting your potential market too 
 much. 
There are even programmers out there in that 5%. Including at least one on this 'group. Probably a handful. 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.
Aug 26 2005
prev sibling next sibling parent Vathix <chris dprogramming.com> writes:
 (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'.
Aug 24 2005
prev sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
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
Aug 24 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Aug 25 2005
parent reply Carlos Santander <csantander619 gmail.com> writes:
Stewart Gordon escribió:
 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.
Convince him of that. -- Carlos Santander Bernal
Aug 26 2005
parent Derek Parnell <derek psych.ward> writes:
On Fri, 26 Aug 2005 18:20:52 -0500, Carlos Santander wrote:

 Stewart Gordon escribió:
 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.
Convince him of that.
Of course they should be moved. They are string handling routines not file routines. -- Derek Parnell Melbourne, Australia 27/08/2005 12:58:56 PM
Aug 26 2005