"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btb78f$1iea$1@digitaldaemon.com...
> Here's one to be going on with:
>
>
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com: 80/support/kb/articles/Q210/3/41.ASP&NoWebContent=1

Thanks, but it doesn't say anything useful. It just references a paper "Differences in Win32 API Implementations Among Windows Operating Systems by Noel Nyman" that google can't find.

Sadly, searching for "CreateFileW" on MSDN returns "Content that matches your query is not available at this time."

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.

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.


"Walter" <walter@digitalmars.com> wrote in message news:btbbts$1q9h$1@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btb78f$1iea$1@digitaldaemon.com...
> > Here's one to be going on with:
> >
> >
>
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:
> 80/support/kb/articles/Q210/3/41.ASP&NoWebContent=1
>
> Thanks, but it doesn't say anything useful. It just references a paper "Differences in Win32 API Implementations Among Windows Operating Systems
by
> Noel Nyman" that google can't find.
>
> Sadly, searching for "CreateFileW" on MSDN returns "Content that matches your query is not available at this time."
>
>

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

Matthew wrote:
>>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.

The MSLU is ok for some applications, but the necessity to ship a DLL with it disqualifies it for others.

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

With a boolean and some good string conversion routines its simple:

if(isWinNT())
	return SomeFuncW(myString);
else
	return SomeFuncA(toAnsi(myString));



Hauke

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

Acknowledged.

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

Indeed. In my own work I use a statically linked layer that contains only the needed functions.

> 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
> - 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).
>
> With a boolean and some good string conversion routines its simple:
>
> if(isWinNT())
> return SomeFuncW(myString);
> else
> return SomeFuncA(toAnsi(myString));

Your philosophy is right, but the implementation is wrong. There should be a single function that library code calls. The last thing we'd want is people testing the boolean themselves. Something along the lines of

HANDLE FindFirstFile(
  LPCTSTR lpFileName,               // file name
  LPWIN32_FIND_DATA lpFindFileData  // data buffer
);

HANDLE _DLU_FindFirstFileW(wchar_t *searchSpecW, WIN32_FIND_DATAW *dataW)
{
  if(bWinNT)
  {
    return FindFirstFileW(searchSpec, data);
  }
  else
  {
    char *searchSpecA . . . // translate searchSpecW to searchSpecA
    WIN32_FIND_DATAA dataA;
    HANDLE hFind = FindFirstFile(
    if(INVALID_HANDLE_VALUE != hFind)
    {
      . . . // translate dataA to dataW
    }
  }
}

What I was referring to in an earlier post about our using the compiler to good effect would be for it to translate use of FindFirstFileW to _DLU_FindFirstFileW without troubling the user. Of course, this'd need a lot of thought before it was accepted.

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.

>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 don't want to pay that price to support a proprietary os that is unsuported today, and known to be replaced by by-far bether os' since years.

i know some weren't able to switch. but only for those, we shouldn't all pay. bether let the ones that have an old, bad os pay. a.k.a. make an os-wrapper for those (with dll's you make downloadable and addable to your programs folder, that wrap your W to A functions, for example)

thats more the way i think it should go.

Matthew wrote:
>>With a boolean and some good string conversion routines its simple:
>>
>>if(isWinNT())
>>return SomeFuncW(myString);
>>else
>>return SomeFuncA(toAnsi(myString));
> 
> 
> Your philosophy is right, but the implementation is wrong. There should be a
> single function that library code calls. The last thing we'd want is people
> testing the boolean themselves. Something along the lines of
> 
> HANDLE FindFirstFile(
>   LPCTSTR lpFileName,               // file name
>   LPWIN32_FIND_DATA lpFindFileData  // data buffer
> );
> 
> HANDLE _DLU_FindFirstFileW(wchar_t *searchSpecW, WIN32_FIND_DATAW *dataW)

I was referring to the way the wrapper functions are implemented. This should be done once for each function, not every time the function is called.

Another thing: from what you write it seems to me like you want to create a "better" Win32 API for the programmer. I was just referring to the way the standard library is implemented. I do not think that such an API should be exposed by the standard library, since it will be very incomplete. Something like a full Unicode Layer for Windows should not be integrated into the D core library - this has nothing to do with the language itself and should be a separate library if someone wants to do it.

Also, a "true" Unicode layer is pretty difficult to implement, as this would include having to wrap the message queue and converting all messages before they are handled by the application (MSLU does this to some degree). For the standard library we won't have that problem, since we do not not access the message queue there.

And another thing: the MSLU does still exist, even if it is not required by the core D library. If developers want to have a reasonably complete Unicode layer they may still link to MSLU (if their application type allows it).

I guess my point is that a full Unicode layer is too much work and has nothing to do with the core D language.

Hauke

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:btad31$2vi5$1@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message

> > So it will not work on Win9x?
>
> After January 16, 2004 MS is dropping support for Win98. If I read it
right
> ME is already dropped (check out http://support.microsoft.com/default.aspx?scid=fh;[LN];Lifeneom). Personally I wouldn't worry about Win9x - it's sooo last millennium. ;-)

WOOHOO!!!

Sean

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