"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:btbis2$24p8$1@digitaldaemon.com...
> The MSLU is ok for some applications, but the necessity to ship a DLL with it disqualifies it for others.

I find the necessity of shipping a DLL with any D executable to be unacceptable.

> For example, I would want to be able to write a self-extractor or an Installer in D. That would not be possible if MSLU is required.
>
> I have quite a bit of experience in writing platform abstraction code, and I have learned that the number of string related OS functions you use is actually pretty "small" (say ~100).
>
> I think the D standard library should use its own wrappers for these functions, so that they are linked statically. The amount of work required for this is not as much as people tend to think.
>
> About the implementation of these wrappers: I think the most sensible course of action would be to have a global bool that specifies whether we're on Win9x or WinNT, and then simply call the corresponding version.
>
> Always calling the W version and in the case of an error falling back to
> the A version has 2 downsides:
> - It's slower on Win9x

It's not as big a problem as it seems. The first time you call it, you can do the check, and then set a global flag. Subsequent times, just test the flag.

> - You need quite a bit of code for the fallback. You have to check the error code of the W function before falling back to A, because even on WinNT a W function may fail while the A version might not (for example, the A implementation might need less memory).

On NT and later, all the A apis are are a shell around the W apis that convert to UTF-16 first.

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btbhrj$23j9$2@digitaldaemon.com...
> In what way is it not useful? It lists the Unicode functions that are supported by Windows 95. Any other W functions are going to be just stubs. Pretty important information, I would have thought.

They don't say what those "stubs" do.

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btbjiv$262e$2@digitaldaemon.com...
> If Walter could concoct a way to intercept references to Win32 API W functions and hook them into such translation functions, everyone could simply program to the Win32 API without ever caring about Win9x
limitations.
> The only cost is the fact that each W function will cause a small amount
of
> bloat that is unneeded on WinNT. In my experience, the bloat is a price worth paying to save us from all the programming and the distribution hassles.

I've written such an interceptor. But it is way beyond the scope of D to try to paper over deficiencies in the underlying OS.

"Walter" <walter@digitalmars.com> wrote in message news:btcah2$alb$1@digitaldaemon.com...
> > We need an equivalent to MSLU, or to use MSLU.
> But the "not implemented" goes away if MSLU is installed.

Sadly, MSLU went out of its way to be a feature of an application, not of the operating system. In other words, it will not install as an operating system upgrade. That and its documented specificity to VC++7 makes it nearly useless for D.

All it mostly does, though, is convert the unicode to the current local code page and then call the "A" function. The problem with the D library doing that is I don't have the mappings between code pages and unicode.

Walter wrote:

>>Always calling the W version and in the case of an error falling back to
>>the A version has 2 downsides:
>>- It's slower on Win9x
> 
> 
> It's not as big a problem as it seems. The first time you call it, you can
> do the check, and then set a global flag. Subsequent times, just test the
> flag.

There's no need for a decision at the first call - it can be decided when the library is initialized (just check for "NTness" with GetVersion)

Hauke

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:btcfu6$ihv$1@digitaldaemon.com...
> Walter wrote:
> >>Always calling the W version and in the case of an error falling back to
> >>the A version has 2 downsides:
> >>- It's slower on Win9x
> > It's not as big a problem as it seems. The first time you call it, you
can
> > do the check, and then set a global flag. Subsequent times, just test
the
> > flag.
> There's no need for a decision at the first call - it can be decided when the library is initialized (just check for "NTness" with GetVersion)

Now that I realize that MSLU cannot be installed as part of the OS, you're right.

"Walter" <walter@digitalmars.com> wrote in message news:btcah2$alb$1@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btbhrl$23j9$3@digitaldaemon.com...
> > > I found some info in Richter's book. I think the thing to do is to
call
> > the
> > > "W" function, and if it fails with the not implemented error, fall
back
> to
> > > calling the "A" function.
> >
> > That's a horrid method. It's inefficient, it's easy to lose last-error (although not difficult to preserve with a scoping class), and there's
no
> > reason for dynamic tests. Whether or not a function is implemented is
> fixed
> > absolutely. For example lstrcpyW() is not implemented on Windows 95, and
> is
> > implemented on Windows 98 or later. Why test for something that is immutable?
> >
> > We need an equivalent to MSLU, or to use MSLU.
>
> But the "not implemented" goes away if MSLU is installed.

It has to be linked in, and that has to be in a specific order. If we use it I think the D compiler should handle the onerous linker crud for us automatically.

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:btcfu6$ihv$1@digitaldaemon.com...
> Walter wrote:
>
> >>Always calling the W version and in the case of an error falling back to
> >>the A version has 2 downsides:
> >>- It's slower on Win9x
> >
> >
> > It's not as big a problem as it seems. The first time you call it, you
can
> > do the check, and then set a global flag. Subsequent times, just test
the
> > flag.
>
> There's no need for a decision at the first call - it can be decided when the library is initialized (just check for "NTness" with GetVersion)

Indeed!

"Walter" <walter@digitalmars.com> wrote in message news:btcdfj$f8o$2@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btbhrj$23j9$2@digitaldaemon.com...
> > In what way is it not useful? It lists the Unicode functions that are supported by Windows 95. Any other W functions are going to be just
stubs.
> > Pretty important information, I would have thought.
>
> They don't say what those "stubs" do.

The stubs do nothing, apart from set the last error to ERROR_NOT_IMPLEMENTED.

They return whatever the "null" value is, whether that be FALSE, or INVALID_HANDLE_VALUE, or whatever ...

"Walter" <walter@digitalmars.com> wrote in message news:btcdfj$f8o$3@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btbjiv$262e$2@digitaldaemon.com...
> > If Walter could concoct a way to intercept references to Win32 API W functions and hook them into such translation functions, everyone could simply program to the Win32 API without ever caring about Win9x
> limitations.
> > The only cost is the fact that each W function will cause a small amount
> of
> > bloat that is unneeded on WinNT. In my experience, the bloat is a price worth paying to save us from all the programming and the distribution hassles.
>
> I've written such an interceptor. But it is way beyond the scope of D to
try
> to paper over deficiencies in the underlying OS.

Ok, fine. But you have to decide how this is to be handled, whether that be MSLU, or DLU.dll, or DLU.lib, or we don't support 9x execution, or we leave it to the poor developer.