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