www.digitalmars.com         C & C++   DMDScript  

D - recls

reply Ant <duitoolkit yahoo.ca> writes:
Matthew,

Why the functions and methods name starting with a capital letter?
check the D style guide at
http://www.digitalmars.com/d/dstyle.html

Walter,

How did you allow that!?

let me check the other contribution from Matthew...

oh, no, registry.d has the same problem...

Ant
Jan 02 2004
next sibling parent "Vathix" <vathix dprogramming.com> writes:
"Ant" <duitoolkit yahoo.ca> wrote in message
news:pan.2004.01.03.05.28.35.516326 yahoo.ca...

 Matthew,

 Why the functions and methods name starting with a capital letter?
 check the D style guide at
 http://www.digitalmars.com/d/dstyle.html

 Walter,

 How did you allow that!?

 let me check the other contribution from Matthew...

 oh, no, registry.d has the same problem...

 Ant



I agree.. Matthew makes good libraries but I don't like his coding style
much.
Jan 02 2004
prev sibling next sibling parent reply Lewis <dethbomb hotmail.com> writes:
Ant wrote:

 Matthew,
 
 Why the functions and methods name starting with a capital letter?
 check the D style guide at
 http://www.digitalmars.com/d/dstyle.html
 
 Walter,
 
 How did you allow that!?
 
 let me check the other contribution from Matthew...
 
 oh, no, registry.d has the same problem...
 
 Ant
 


also note in overview it says:

  D is not a scripting language, nor an interpreted language. It doesn't come 
with a VM, <b> a religion , or an overriding philosophy. It's a practical 
language for practical programmers </b> who need to get the job done quickly, 
reliably, and leave behind maintainable, easy to understand code.

personally i like the his coding style. but im also biased towards anything
that 
looks more BASIC than C  ;)
Jan 03 2004
parent Ant <duitoolkit yahoo.ca> writes:
On Sat, 03 Jan 2004 03:00:56 -0500, Lewis wrote:


 Ant wrote:

 Matthew,
 
 Why the functions and methods name starting with a capital letter?
 check the D style guide at
 http://www.digitalmars.com/d/dstyle.html
 
 Walter,
 
 How did you allow that!?
 
 let me check the other contribution from Matthew...
 
 oh, no, registry.d has the same problem...
 
 Ant
 


 
 also note in overview it says:
 
   D is not a scripting language, nor an interpreted language. It doesn't come 
 with a VM, <b> a religion , or an overriding philosophy. It's a practical 
 language for practical programmers </b> who need to get the job done quickly, 
 reliably, and leave behind maintainable, easy to understand code.
 
 personally i like the his coding style. but im also biased towards anything
that 
 looks more BASIC than C  ;)


give me a break.
at least the 'official' digital mars D runtime library could follow
the suggested style.

Ant
Jan 02 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
Oh, so many possible answers to this question, some penitent, some
exasperated, some disinterested, some patient. I shall content myself with :

I have lots of different styles, depending on the context. It's conceivable
that my D style will evolve to fall in with the "official style", I suppose,
but there again it may not.

I think it's a little too early in the game to be prioritising this to the
degree that Walter and I, or anyone else, would spend time that is in such
short supply on it, when there are other issues that are more pressing. I
for one am more than prepared for all my D libraries to have to change
conventions, and my D client code to break, before 1.0 comes around. What's
of far more concern, surely, is that there are a raft of libraries yet to be
written, and Walter wants to release 1.0 in March! (A little recursive
search and replace is not going to be too taxing, is it, especially since we
now have a recursive search library ...)

Unless and until the picture clears around the different paradigms that will
lead D forward, in much the same way that STL, C-API and OO paradigms all
have different styles in C++, I'm going to maintain my position of
preparedness. We may all be changing ...




 Matthew,

 Why the functions and methods name starting with a capital letter?
 check the D style guide at
 http://www.digitalmars.com/d/dstyle.html

 Walter,

 How did you allow that!?

 let me check the other contribution from Matthew...

 oh, no, registry.d has the same problem...

 Ant
Jan 03 2004
next sibling parent Ant <duitoolkit yahoo.ca> writes:
On Sat, 03 Jan 2004 19:32:52 +1100, Matthew wrote:


 Oh, so many possible answers to this question, some penitent, some
 exasperated, some disinterested, some patient. I shall content myself with :


You can argue however you like, but you're still wrong. :)

Ant
Jan 03 2004
prev sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Matthew wrote:

 I have lots of different styles, depending on the context. It's conceivable
 that my D style will evolve to fall in with the "official style", I suppose,
 but there again it may not.


BTW, why do you define "alias int boolean"? I think this is a big 
mistake. What makes it in your opinion better than "alias bit bool"?

-eye
Jan 04 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bt9kcn$1rml$1 digitaldaemon.com...

 Matthew wrote:

 I have lots of different styles, depending on the context. It's




conceivable

 that my D style will evolve to fall in with the "official style", I




suppose,

 but there again it may not.


 BTW, why do you define "alias int boolean"? I think this is a big
 mistake. What makes it in your opinion better than "alias bit bool"?


why is everyone getting hung up on all this crap? I don't think boolean is
better than bool, but when I wrote the reg api the issue of bool was still
way up in the air, so I chose to avoid possible clashes at that time. I do
think int is better than bit, until such time as we have a strongly typed
boolean. But, AFAIK, the issue was never resolved, and no concensus was
reached, so I just continued in my holding pattern.

As I mentioned in the other post, I'm ready for wholesale syntactic changes
to all of my D code (lib and client) prior to 1.0, but I'm not going to
spend serious amounts of time - of which I have very little atm - on things
that are still subject to change.  recls has simply followed the reg api,
since it seems to me to be sensible that I, as their author, be consistent
so that when I have to make these changes it is simple to do.

I'd be interested to hear any feedback - -ve or +ve - on the semantics of
the libs.
Jan 04 2004
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Jan 04 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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?

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.)
Jan 04 2004
next sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
"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.)
Jan 04 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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?
Jan 04 2004
parent reply "Walter" <walter digitalmars.com> writes:
"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?
Jan 04 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
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?
Jan 04 2004
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
"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
Jan 05 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"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.
Jan 04 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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.
Jan 04 2004
parent reply "Walter" <walter digitalmars.com> writes:
"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?
Jan 04 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 "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
Jan 04 2004
parent reply "Walter" <walter digitalmars.com> writes:
"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.



have a more specific url?
Jan 05 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
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.



 have a more specific url?
Jan 05 2004
parent reply "Walter" <walter digitalmars.com> writes:
"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."
Jan 05 2004
next sibling parent reply "Walter" <walter digitalmars.com> writes:
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.
Jan 05 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 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.
Jan 05 2004
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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
Jan 05 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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.
Jan 05 2004
next sibling parent davepermen <davepermen_member pathlink.com> writes:
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.
Jan 05 2004
prev sibling next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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
Jan 05 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:btbog7$2dl0$1 digitaldaemon.com...

 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.


Ok. :)


 Another thing: from what you write it seems to me like you want to
 create a "better" Win32 API for the programmer.


Absolutely! These issues are a total PITA, and I see no reason why, at this
early stage, we cannot decide to step in and fix it for one and all.

And who's to say analogous issues are not to be had on Solatirs, or Mac, or
VMS, or whatever?


 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.


It's not a trivial job, to be sure.


 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.

But people will omit it. The single biggest problem is that most of us
developers are (i) English speakers (whether first language, or just been
forced to be good at it because it's the lingua franca of programming and
popular culture) and (ii) we use NT family boxes.


 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.


Excellent point. It is indeed a hard one


 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.


Agreed on both point. But the issue still has to be addressed.

The fact that big W was unaware of the stubbed nature of the 9x W functions
demonstrates that this is a minefield for all developers, of whatever level
of experience.

How about if we start thinking about this a little differently? Maybe rather
than concerning ourselves about Windows, we can have a general approach to
function declarations. We could have a keyword, dynamic_encoding_function in
the following example (a better name would be suggested by an imaginative
soul), that would allow us to stipulate that the compiler and/or linker must
generate the dispatching code for us. We'd need to tell it what the in and
out parameters are, how it makes the determination of which to call, and
such like - it's not trivial - but it could be done.


HANDLE FindFirstFileA(char *searchSpec, WIN32_FIND_DATAW data);
HANDLE FindFirstFileA(wchar_t *searchSpec, WIN32_FIND_DATAW data);

dynamic_encoding_function HANDLE FindFirstFile(wchar_t *searchSpec,
WIN32_FIND_DATAW data);
{
  dispatch_switch = std.windows.isWinNT,
  dispatch_case =
    {
        true,                 /* When std.windows.isWinNT is true */
        FindFirstFileA,
        false,             /* Don't do anything on entry */
        false              /* Don't do anything on exit */
    },
  dispatch_default =
    {
        std.windows.opSys.winNT,
        FindFirstFileA,
        true             /* Do something on entry (in this case translate
searchSpec) - we need to work out a general way to decree what is to be done
*/
        true             /* Do something on exit (in this case translate
data) - we need to work out a general way to decree what is to be done */
     },
}


Obviously there's more to it, but I think (hope) you get my drift. This
could then be used for more than just character encoding scheme translation,
and would not necessarily only be useful for Win32.

It'd need a clear and concise form, but I'll leave it to others to suggest a
better one.
Jan 05 2004
parent Hauke Duden <H.NS.Duden gmx.net> writes:
Matthew wrote:

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


 
 
 Agreed on both point. But the issue still has to be addressed.
 
 The fact that big W was unaware of the stubbed nature of the 9x W functions
 demonstrates that this is a minefield for all developers, of whatever level
 of experience.


Yes, but changing the way an application interacts with the OS is the 
wrong way to go, IMHO. I certainly wouldn't want to have such stubs 
between me and the OS, because I already have an abstraction library. 
Unnecessary layers mean unnecessary bugs.

So there are really two issues here:

1) How are the Windows calls in the standard library implemented?
2) Is it possible to help people write better, more compatible Unicode 
application on Windows?

Number 1 is fairly easy to solve by just creating a small number of 
wrapper functions that are used internally.

Number 2 is a completely different beast. Writing a complete Unicode 
layer is a HUGE project - not even Microsoft has managed to do it up to 
now. For example, the Windows Common Controls are not supported in the 
MSLU, even though they are used in almost all applications.

Also, I think the goal of Number 2 is not inside the scope of a 
programming language like D. Improving the OS is not the job of the 
language, it is the job of either the OS creators or library developers.

So I see three options:

a) Just leave it as it is and provide good tool support for easily 
linking in the MSLU, if the developer wants to do that. The D docs could 
also feature prominent notice of the MSLU's existence and describe what 
it does.

b) Create a new wrapper library in D. As I mentioned, this is a lot of 
work. But there could be some advantages as well: for example, we could 
write the wrappers in a way so that they take D string objects (of the 
"new" kind that hides the encoding), instead of raw string data. That 
would make it even easier for newbies, since then they wouldn't be 
required to understand which encoding they need for which functions. It 
could also save some speed on Win9x (if the encoding used in the String 
objects is not UTF-16), because then we could convert directly to "ANSI" 
encoding (i.e. the system code page), instead of first converting to 
UTF16 and then to ANSI.

Solution b will probably always be incomplete and by the time it is 
reasonably usable many people might have moved on to other OSs.

c) Stick to the MSLU for the time being. And instead of slightly 
improving the Windows API, invest that work into developing platform 
independent libraries that work for multiple OSs. If you get right down 
to it, the goal of this discussion is to have newbies write code that is 
compatible with all Windows OSs. Wouldn't it be even better if that code 
also ran on Linux and MacOS? This is also a huge task, but at least 
there are already a lot of libraries one could utilize (like the Apache 
Portable Runtime, wxWindows GTK, QT, whatever). The key would be to make 
these libraries easily accessible, so that newbies use them instead of 
programming the Windows API directly.

I think if you want to protect people from the hazards of an OS then 
solution c) is the best way to go. But I wouldn't go that far and make 
this a part of the D standard library. That would mean that all those 
platform independent libs HAVE to be implemented for every OS D is 
ported to - and that could severely hamper the range of systems D is 
available for.

Better make it a semi-official set of libraries that are "recommended" 
to use, if available.

Hauke
Jan 05 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"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.
Jan 05 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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.
Jan 05 2004
parent "Walter" <walter digitalmars.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:btcm5i$s30$4 digitaldaemon.com...

 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.


At this point, I don't know what to do. I just don't understand why MS
didn't make it an update to the OS, and now they never will as they have
officially abandoned 9x.

D relies on the underlying OS for unicode to work, otherwise each executable
will have to carry around a huge bloated unicode layer. That might work for
a VM based language where customers are used to bloat <g>, but not for a
systems language.

I think the right solution is to say that unicode will not work on 9x - just
ascii - and provide some kludge for code pages.
Jan 05 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"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.
Jan 05 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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
Jan 05 2004
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"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.
Jan 05 2004
parent Ilya Minkov <minkov cs.tum.edu> writes:
Walter wrote:

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


http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx

MSLU appears to consist of a tiny loader, which binds into the 
application, and the DLL. If the DLL is not found, the loader simply 
redirects the calls to the OS. Which results in the same as if the 
loader was not there.

Thus you can call applications which use such a loder "MSLU-aware", and 
MSLU DLL is then as good as an operaing system update?

Besides, strategy can be destinguished by specifying a version at 
compile-time. Unicode with MSLU loader, lightweight Unicode (NT only and 
probably little sense), and lightweight non-Unicode (Windows 9x, good 
for many fairly language-agnostic applications). BTW, with versions and 
stuff, time would be coming to think of a better build system. Thanks 
that the language semantics makes it possible.

-eye
Jan 05 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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!
Jan 05 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"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.
Jan 05 2004
next sibling parent "Walter" <walter digitalmars.com> writes:
"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.
Jan 05 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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.
Jan 05 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:btcm5f$s30$1 digitaldaemon.com...

 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.


The more I look at it, the more it looks like the wrong solution for D.
Jan 05 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Walter" <walter digitalmars.com> wrote in message
news:btcr6g$13ge$1 digitaldaemon.com...

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:btcm5f$s30$1 digitaldaemon.com...

 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.


 The more I look at it, the more it looks like the wrong solution for D.


I can't conceive of a right solution, but I know that shipping NT-family
compiled exes to Win9x and having them fail is going to look back for D,
however unfair and unjustified that is.
Jan 05 2004
parent Lewis <dethbomb hotmail.com> writes:
Matthew wrote:

 "Walter" <walter digitalmars.com> wrote in message
 news:btcr6g$13ge$1 digitaldaemon.com...
 

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:btcm5f$s30$1 digitaldaemon.com...


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.


The more I look at it, the more it looks like the wrong solution for D.


 
 
 I can't conceive of a right solution, but I know that shipping NT-family
 compiled exes to Win9x and having them fail is going to look back for D,
 however unfair and unjustified that is.
 
 


I always use the A api's unless theres no equilavent for a W api that i need to 
use. In vb all strings (which would be equal to wchar[] or utf16) get converted 
automatically to char[] by the runtime to call the A api, and then back again. 
It seems to me that this type of way should be the solution if one wants to 
generically support both systems (9x an NT). Maybe some kind of flag for NT 
only? that would use only W api's.

As was stated though, a flag for NTness would probably be best with an: #If NT 
{use W api;} else {use A api;} might also work.

However (this could possibly get me flamed lol) i also think, because that 
windows is by far the most popular os, that a specific windows only support 
library should be built, seperate from possibly another library for unix, linux 
etc... ;) it cant hurt to wish lol

Another possible solution may be to come up with a new format for defining 
windows only api. So that the compiler can pick which one to use depending on 
the OS, dunno...

Hopefully in a year from now i can look back at some of my posts and wonder how 
i could say such useless things lol i guess leaving something unsaid that may 
helpful is useless also.

regards
Lewis
Jan 06 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
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."
Jan 05 2004
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Jan 05 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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 ...
Jan 05 2004