"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.

"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.

"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.

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.

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

"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?

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.

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.

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

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