"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btab2s$2snm$1@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:bta4uc$2jo2$1@digitaldaemon.com...
> >
> > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bta0ik$2des$1@digitaldaemon.com...
> > > I'd be interested to hear any feedback - -ve or +ve - on the semantics
> of
> > > the libs.
> >
> > Should think about upgrading it from the "A" api's to the "W" api's.
>
> 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. ;-)

> Or has a D-standard mechanism been established for dynamically determining which APIs to use, depending on the current OS? If so, I missed it.
>
> (FTR, I am not of the opinion that its current form is *the* form, merely that AFAIK the issue is yet to be resolved.)

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:btad31$2vi5$1@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btab2s$2snm$1@digitaldaemon.com...
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:bta4uc$2jo2$1@digitaldaemon.com...
> > >
> > > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bta0ik$2des$1@digitaldaemon.com...
> > > > I'd be interested to hear any feedback - -ve or +ve - on the
semantics
> > of
> > > > the libs.
> > >
> > > Should think about upgrading it from the "A" api's to the "W" api's.
> >
> > 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. ;-)

That would be very fine afaiac, but I guess it's Walter's call.

I'd also be happy with the intermediate position that D would require MSLU.

Walter?

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btab2s$2snm$1@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:bta4uc$2jo2$1@digitaldaemon.com...
> >
> > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bta0ik$2des$1@digitaldaemon.com...
> > > I'd be interested to hear any feedback - -ve or +ve - on the semantics
> of
> > > the libs.
> >
> > Should think about upgrading it from the "A" api's to the "W" api's.
>
> So it will not work on Win9x?

Sure it will. Win9x supports the "W" api's. What 95 does not support is UTF-8, but that's irrelevant because the UTF-8 to UTF-16 translation is handled by the D library, not 95. 95 also does not support UTF-16 surrogate pairs, but again, that's an issue for the high level D programmer, the runtime library need not care.

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btadev$3052$1@digitaldaemon.com...
> I'd also be happy with the intermediate position that D would require
MSLU.
>
> Walter?

What's MSLU?

"Walter" <walter@digitalmars.com> wrote in message news:btaecp$31k4$1@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btab2s$2snm$1@digitaldaemon.com...
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:bta4uc$2jo2$1@digitaldaemon.com...
> > >
> > > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bta0ik$2des$1@digitaldaemon.com...
> > > > I'd be interested to hear any feedback - -ve or +ve - on the
semantics
> > of
> > > > the libs.
> > >
> > > Should think about upgrading it from the "A" api's to the "W" api's.
> >
> > So it will not work on Win9x?
>
> Sure it will. Win9x supports the "W" api's.

Whatever do you mean? Are you saying that Windows 95/98 have functioning implementations of FindFirstFileW, CopyFileW, etc. etc.? I can assure you that they do not.

From the MSDN:

"
Windows 95/98/Me: FindFirstFileW is supported by the Microsoft Layer for
Unicode. To use this, you must add certain files to your application, as
outlined in Microsoft Layer for Unicode on Windows 95/98/Me Systems.

"

"
Windows 95/98/Me: CopyFileW is supported by the Microsoft Layer for Unicode.
To use this, you must add certain files to your application, as outlined in
Microsoft Layer for Unicode on Windows 95/98/Me Systems.

"

etc. etc. The vast majority of W functions are not supported. The exceptions are a *very* few UpperCase functions and the lstr???W ones.

Microsoft Layer for Unicode.

Dude, download the December issue of WDN (http://www.windevnet.com/) and
read my article. ;)

"Walter" <walter@digitalmars.com> wrote in message news:btaecq$31k4$2@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btadev$3052$1@digitaldaemon.com...
> > I'd also be happy with the intermediate position that D would require
> MSLU.
> >
> > Walter?
>
> What's MSLU?
>
>

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btag8d$369$1@digitaldaemon.com...
> Whatever do you mean? Are you saying that Windows 95/98 have functioning implementations of FindFirstFileW, CopyFileW, etc. etc.? I can assure you that they do not.
>
> From the MSDN:
>
> "
> Windows 95/98/Me: FindFirstFileW is supported by the Microsoft Layer for
> Unicode. To use this, you must add certain files to your application, as
> outlined in Microsoft Layer for Unicode on Windows 95/98/Me Systems.

What happens if you call FindFirstFileW on 95 without MSLU?

> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btag8d$369$1@digitaldaemon.com...
> > Whatever do you mean? Are you saying that Windows 95/98 have functioning implementations of FindFirstFileW, CopyFileW, etc. etc.? I can assure
you
> > that they do not.
> >
> > From the MSDN:
> >
> > "
> > Windows 95/98/Me: FindFirstFileW is supported by the Microsoft Layer for
> > Unicode. To use this, you must add certain files to your application, as
> > outlined in Microsoft Layer for Unicode on Windows 95/98/Me Systems.
>
> What happens if you call FindFirstFileW on 95 without MSLU?

It'll return INVALID_HANDLE_VALUE, and GetLastError() will return ERROR_NOT_IMPLEMENTED. I don't have refs, but there're several sections in MSDN that list the miserly number of supported 9x Unicode functions and the vast number of unsupported ones.

This is how MS got Windows 95 to fix on all those crusty old boxes, and was a deliberate design decision motivated by allowing people to upgrade from 3.x without having to change machines. Smart marketing, but terrible technology. They junked almost the entire Unicode API, security, and several other bits. I guess it worked, but it sure left us all a lot of shit to shovel.

You need to decide how you want to play this Walter, as it's extremely important.

Personally, I'd like a D or DMC equivalent to MSLU, and the D compiler hides the searching and loading (of the D9xUL.dll) in the exe, without troubling the users. One possible nice thing would be that if D9xUL.dll was not present, the exe could download and install it seamlessly, but I guess connectivity, exe-size and security will auger against that.

However it's done, it's a lot of work, and this little puppy's got no interest in doing it.

But either someone does it, or we all do it. There's no escaping the problem, except by saying D is not for 9x. But since one can compile and test a PE exe built on D in NT, there's nothing to stop someone trying it on 9x, especially given the likely amount of "free" software available from this excellent group of code studs over the next c/o years. Given that, it seems impossible to take the stance that D will not support Win9x. It'll quickly get the reputation of producing buggy software.

btw, did you read the article. It describes several potential strategies we can take. Given that we (i.e you) control the Win32 compiler, there is a lot of potential to take some of the simpler, but more restrictive, techniques I describe, by having it do a bit of custom linking smarts.

Cheers

Matthew

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btb09n$10l5$1@digitaldaemon.com...
> btw, did you read the article. It describes several potential strategies
we
> can take. Given that we (i.e you) control the Win32 compiler, there is a
lot
> of potential to take some of the simpler, but more restrictive, techniques
I
> describe, by having it do a bit of custom linking smarts.

No, I didn't find it. The only link I found was your article on C#. Do you have a more specific url?

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



"Walter" <walter@digitalmars.com> wrote in message news:btb6e3$1g93$1@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:btb09n$10l5$1@digitaldaemon.com...
> > btw, did you read the article. It describes several potential strategies
> we
> > can take. Given that we (i.e you) control the Win32 compiler, there is a
> lot
> > of potential to take some of the simpler, but more restrictive,
techniques
> I
> > describe, by having it do a bit of custom linking smarts.
>
> No, I didn't find it. The only link I found was your article on C#. Do you have a more specific url?
>
>