From: Satchmo on
Nobody wrote:
> Satchmo wrote:
>> What I have been doing lately is checking for the high-order bit from the
>> GetVersion() function. Only Windows NT, 2000, and above have this bit set
>> to 0. I use that to determine whether I call the "A" or the "W" version.
>> Of course that is to write code that is compatible with old Windows
>> (95/98/Me). Although, I'm wondering if all that is worth the trouble,
>> since I personally do not know anyone who still uses those old OSs.
>>
> I think you can use the "Microsoft Layer for Unicode", but for each function
> that it supports, you have to replace the DLL name in the Declare from
> something like "Kernel32" to "UnicoWS.dll", and put "UnicoWS.dll" in the
> same folder as the EXE. It's actually easier to use this DLL in VB rather
> than C++. C++ developer have to do things to fool the linker so they can use
> that DLL instead of Kernel32.dll, User32.dll, etc.
>
> When using "UnicoWS.dll", you always call the W function with the same name
> in "UnicoWS.dll" and use "ByVal StrPtr(s)", or "ByVal 0&" to pass the
> parameters, and in turn, "UnicoWS.dll" would call the OS version of the
> function directly(In NT), or after doing the necessary Unicode to ANSI
> conversion when running under Windows 9x.

Nobody, this is great news! Thanks for the info! I did not know about
this. I searched MSDN and found this great article about MSLU here:

http://msdn.microsoft.com/en-us/goglobal/bb688166.aspx
http://msdn.microsoft.com/en-us/magazine/cc301794.aspx

As you said, with MSLU I can just write a single Unicode version of my
application and have it run properly on all platforms! The best of all:
using it won't slow down the app on Windows NT/2000/XP, because it will
not load the MSLU unless the app runs on a Win95/98/ME machine!
From: Nobody on
"Satchmo" <don.tspa.m(a)dontdo.spam.not> wrote in message
news:i3vqt6$839$1(a)news.eternal-september.org...
> The best of all: using it won't slow down the app on Windows NT/2000/XP,
> because it will not load the MSLU unless the app runs on a Win95/98/ME
> machine!

It will always load the MSLU, which is just a simple wrapper DLL, about 233
KB, which is not a big deal, but under NT, there is no need to do ANSI to
Unicode conversion, so there is very small overhead in terms of speed when
running under NT.


From: Mayayana on
This is an interesting discussion, but I wonder how
much it matters. Are there cases where the difference
in speed between unicode calls and VBs normal ANSI
conversions is actually notable? I'd be curious to see
a demo if anyone has created such a thing.


| > The best of all: using it won't slow down the app on Windows NT/2000/XP,
| > because it will not load the MSLU unless the app runs on a Win95/98/ME
| > machine!
|
| It will always load the MSLU, which is just a simple wrapper DLL, about
233
| KB, which is not a big deal, but under NT, there is no need to do ANSI to
| Unicode conversion, so there is very small overhead in terms of speed when
| running under NT.
|
|


From: ralph on
On Thu, 12 Aug 2010 09:51:48 -0400, "Mayayana"
<mayayana(a)invalid.nospam> wrote:


>| > The best of all: using it won't slow down the app on Windows NT/2000/XP,
>| > because it will not load the MSLU unless the app runs on a Win95/98/ME
>| > machine!
>|
>| It will always load the MSLU, which is just a simple wrapper DLL, about
>233
>| KB, which is not a big deal, but under NT, there is no need to do ANSI to
>| Unicode conversion, so there is very small overhead in terms of speed when
>| running under NT.
>|
>
> This is an interesting discussion, but I wonder how
>much it matters. Are there cases where the difference
>in speed between unicode calls and VBs normal ANSI
>conversions is actually notable? I'd be curious to see
>a demo if anyone has created such a thing.
>
>

"How much does it matter" is a common question and just as commonly
has a range of answers - all dependent on the comfort level of the
programmer, the service requirements of an application, or the system
as a whole.

There is the simple fact that anything that adds 'clicks' to a running
process has a scalar impact on performance, thus it always "matters".
"Noticeably" however, always depends on scope and frequency.

For example, the programming of a text editor.
It spends most of its total time waiting for keystrokes. The actual
time to process a keystroke is often but a fraction of the time the
program takes to process it, making less than optimal routines
"unnoticeable' on a low load desktop. But every click added is one
less click available to a system to do something else. So running the
same program on a desktop with a ton of running background processes,
or with a hundred users from a terminal server - wasted clicks may
become quite noticeable.

Whenever the subject of performance or optimization comes up I'm
reminded to two adages - "It doesn't matter how fast it is, if it
doesn't work", and "If it has to work, it doesn't matter how long it
takes".

The OP due to his requirements has to adopt the latter.

-ralph
From: Nando on
Nobody wrote:
> Satchmo wrote:
>> The best of all: using it won't slow down the app on Windows NT/2000/XP,
>> because it will not load the MSLU unless the app runs on a Win95/98/ME
>> machine!
>
> It will always load the MSLU, which is just a simple wrapper DLL, about 233
> KB, which is not a big deal, but under NT, there is no need to do ANSI to
> Unicode conversion, so there is very small overhead in terms of speed when
> running under NT.

I just realized the following scenario and I'm worried now: what if the
app uses controls on forms. MSLU will have nothing to with their
operation right? Are Microsoft's standard controls (Common Controls 6.0
SP6) Unicode-ready? Can they display Unicode text on forms? And what if
they make their own internal calls to Unicode functions "W" and "A"
versions, how would they accomplish the same distinction than MSLU? I'm
just trying to understand functionality and limitations. I'm quite
confused now.