www.digitalmars.com         C & C++   DMDScript  

D - std.file.read makes AV in Win9x

reply yaneurao sun-inet.or.jp writes:
I am reported that my game library doesn't go well in Win9x.
So I examined the reason ,
and at first,I had recoganized std.file.read is a bad code :

:    namez = std.utf.toUTF16z(name);
:    h = CreateFileW(namez,GENERIC_READ,FILE_SHARE_READ,null,OPEN_EXISTING,
:	 FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN,(HANDLE)null);
:    if (h == INVALID_HANDLE_VALUE)
:	 goto err1;
:    size = GetFileSize(h, null);
:    buf = new byte[size];

There are several miss-coding here.

1. CreateFileW is only for WinNT system(NT/2k/XP..)
so we can't assume CreateFileW always exist.

CreateFileA should be used for here ,
or to be prepared two version A and W.

2. In Win9x , CreateFileW would fail and return null,
not INVALID_HANDLE_VALUE , so it is better to be check null
or use getLastError.

getLastError return 120 if it is not implemented,
120 (ERROR_CALL_NOT_IMPLEMENTED)

3.GetFileSize returns -1 if file handle is invalid.
so it is better to be checked if it is an error or not.

4.new allcator had better to throw bad_alloc or return null
if it can't allocated.
In a foregoing case, GetFileSize returns -1 , and

buf = new byte [-1];

is executed and makes an access violation.

d_new takes a unsigned interger parameter for length like size_t.
So d_new's implementation has a problem , I traced the source code.

:	p = _gc.malloc(length * size);
:	debug(PRINTF) printf(" p = %p\n", p);
:	memset(p, 0, length * size);

Oh! My God! There is no checking for null.
when _gc.malloc can't allocate a memory and returns null,
memset would makes an access violation.

5. Many API with be suffixed W are used in phobos.

I've checked all source code on phobos ,
and found many API with be suffixed W are used.

Doesn't Phobos support Win9x?
I'm very deploring about it.

yaneurao.
Jan 04 2004
next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Phobos is buggy. It is a starter, more of a guideline to the library 
interface.

yaneurao sun-inet.or.jp wrote:


 4.new allcator had better to throw bad_alloc or return null
 if it can't allocated.
 In a foregoing case, GetFileSize returns -1 , and
 
 buf = new byte [-1];
 
 is executed and makes an access violation.


I think it may thow an assertion failure or something like wrong input 
failure. Or simply leave ir as is, since you should be able to see the 
problem in the debugger, but i'd say that giving -1 to malloc is a bug 
in your program.

To return null i would say this would be a very, very bad idea, since 
you will notice a bug in your program much later!


 d_new takes a unsigned interger parameter for length like size_t.
 So d_new's implementation has a problem , I traced the source code.
 
 :	p = _gc.malloc(length * size);
 :	debug(PRINTF) printf(" p = %p\n", p);
 :	memset(p, 0, length * size);
 
 Oh! My God! There is no checking for null.
 when _gc.malloc can't allocate a memory and returns null,
 memset would makes an access violation.


DigitalMars C++ compiler doesn't do it either. On Windows, this should 
never happen anyway. And if it does, there is *no* way your application 
can help itself. I think the malloc implementation simply has to wait 
until memory becomes available on such memory rich systems like a PC.

If the signature is changed, it would cut off the pathologic cases when 
range checking is on?


 5. Many API with be suffixed W are used in phobos.



 Doesn't Phobos support Win9x?
 I'm very deploring about it.


Wasn't there a platform update, which adds simple implementation of W 
APIs into Windows 9x? Like, if it does work, then why should we 
compromise the quality of unicode support in Windows NT derivatives? I 
know languages with different scripts (russian and german), and i'm very 
happy that NT and other operating systems can suport them properly and 
simultaneously - but only so long as software does. And it's a pity to 
see it often doesn't and spoils it all, because of ties to the old API.

-eye
Jan 04 2004
parent reply yaneurao sun-inet.or.jp writes:
In article <bt9j6q$1pr6$1 digitaldaemon.com>, Ilya Minkov says...


 Wasn't there a platform update, which adds simple implementation of W 
 APIs into Windows 9x? Like, if it does work, then why should we 
 compromise the quality of unicode support in Windows NT derivatives? I 
 know languages with different scripts (russian and german), and i'm very 
 happy that NT and other operating systems can suport them properly and 
 simultaneously - but only so long as software does. And it's a pity to 
 see it often doesn't and spoils it all, because of ties to the old API.


No need to *COMPROMISE*.

We can use Unicode *AND*
we can run our programs on Win9x ,
just coding like this:

enum { ERROR_CALL_NOT_IMPLEMENTED = 120 }

// --- std.file.read
void[] read(char[] name)
{
DWORD size;
DWORD numread;
HANDLE h;
byte[] buf;
wchar* namez = std.utf.toUTF16z(name);

h = CreateFileW(namez,GENERIC_READ,FILE_SHARE_READ,null,OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN,(HANDLE)null);
if (GetLastError()== ERROR_CALL_NOT_IMPLEMENTED){
h = CreateFileA(toMBSz(namez),GENERIC_READ,FILE_SHARE_READ,null,OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN,(HANDLE)null);
}

if (h == INVALID_HANDLE_VALUE)
goto err1;

size = GetFileSize(h, null);
buf = new byte[size];

if (ReadFile(h,buf,size,&numread,null) != 1)
goto err2;

if (numread != size)
goto err2;

if (!CloseHandle(h))
goto err;

return buf;

err2:
CloseHandle(h);
err:
delete buf;
err1:
throw new FileException(name, GetLastError());
}

// mcb <-> wcb convertion
module widestring;

private import std.string;

version(Win32){
extern(Windows) export int WideCharToMultiByte(
uint	  CodePage,
uint	 dwFlags,
char*	lpWideCharStr,
int	  cchWideChar,
char*	 lpMultiByteStr,
int	  cbMultiByte,
char*	 lpDefaultChar,
bool*	lpUsedDefaultChar);

extern(Windows) export int MultiByteToWideChar(
uint	  CodePage,
uint	 dwFlags,
char*	 lpMultiByteStr,
int	 cchMultiByte,
wchar*	 lpWideCharStr,
int		cchWideChar);

} else {
extern(C){
enum { LC_ALL = 0 }
char* setlocale(int, char*);
int mbstowcs(wchar*, char*, int);
int wcstombs(char*, wchar*, int);
}
}

char[] toMBS(wchar[] s)
{
char[] result;
version(Win32){
result.length = WideCharToMultiByte(0, 0, (char*)s, s.length,
null, 0, null, null);
WideCharToMultiByte(0, 0, (char*)s, s.length, result,
result.length, null, null);
}else{
synchronized (locale_sync_object) {
char* o = setlocale(LC_ALL, null);
setlocale(LC_ALL, "");
result.length = wcstombs(null, s, 0);
wcstombs(result, s, result.length);
setlocale(LC_ALL, o);
}
}
return result;
}

char* toMBSz(wchar* s) { return
std.string.toStringz(toMBS(s[0..std.string.wcslen(s)])); }

version(Win32){
} else {
private static Object locale_sync_object;
//	note that 'setlocale' should be used in 'synchronized'.
}
Jan 04 2004
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
Only Microsoft could turn

FILE h = OpenFile("foo");

into that mess.  ;)

In the old days, things were somewhat simpler.  Maybe once 95/98/Me die
completely, and everyone switches over to Unicode, things will get better.

Sean

<yaneurao sun-inet.or.jp> wrote in message
news:btadkb$30bl$1 digitaldaemon.com...

 In article <bt9j6q$1pr6$1 digitaldaemon.com>, Ilya Minkov says...


 Wasn't there a platform update, which adds simple implementation of W
 APIs into Windows 9x? Like, if it does work, then why should we
 compromise the quality of unicode support in Windows NT derivatives? I
 know languages with different scripts (russian and german), and i'm very
 happy that NT and other operating systems can suport them properly and
 simultaneously - but only so long as software does. And it's a pity to
 see it often doesn't and spoils it all, because of ties to the old API.


 No need to *COMPROMISE*.

 We can use Unicode *AND*
 we can run our programs on Win9x ,
 just coding like this:

 enum { ERROR_CALL_NOT_IMPLEMENTED = 120 }

 // --- std.file.read
 void[] read(char[] name)
 {
 DWORD size;
 DWORD numread;
 HANDLE h;
 byte[] buf;
 wchar* namez = std.utf.toUTF16z(name);

 h = CreateFileW(namez,GENERIC_READ,FILE_SHARE_READ,null,OPEN_EXISTING,
 FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN,(HANDLE)null);
 if (GetLastError()== ERROR_CALL_NOT_IMPLEMENTED){
 h =


CreateFileA(toMBSz(namez),GENERIC_READ,FILE_SHARE_READ,null,OPEN_EXISTING,

 FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN,(HANDLE)null);
 }

 if (h == INVALID_HANDLE_VALUE)
 goto err1;

 size = GetFileSize(h, null);
 buf = new byte[size];

 if (ReadFile(h,buf,size,&numread,null) != 1)
 goto err2;

 if (numread != size)
 goto err2;

 if (!CloseHandle(h))
 goto err;

 return buf;

 err2:
 CloseHandle(h);
 err:
 delete buf;
 err1:
 throw new FileException(name, GetLastError());
 }

 // mcb <-> wcb convertion
 module widestring;

 private import std.string;

 version(Win32){
 extern(Windows) export int WideCharToMultiByte(
 uint   CodePage,
 uint dwFlags,
 char* lpWideCharStr,
 int   cchWideChar,
 char* lpMultiByteStr,
 int   cbMultiByte,
 char* lpDefaultChar,
 bool* lpUsedDefaultChar);

 extern(Windows) export int MultiByteToWideChar(
 uint   CodePage,
 uint dwFlags,
 char* lpMultiByteStr,
 int cchMultiByte,
 wchar* lpWideCharStr,
 int cchWideChar);

 } else {
 extern(C){
 enum { LC_ALL = 0 }
 char* setlocale(int, char*);
 int mbstowcs(wchar*, char*, int);
 int wcstombs(char*, wchar*, int);
 }
 }

 char[] toMBS(wchar[] s)
 {
 char[] result;
 version(Win32){
 result.length = WideCharToMultiByte(0, 0, (char*)s, s.length,
 null, 0, null, null);
 WideCharToMultiByte(0, 0, (char*)s, s.length, result,
 result.length, null, null);
 }else{
 synchronized (locale_sync_object) {
 char* o = setlocale(LC_ALL, null);
 setlocale(LC_ALL, "");
 result.length = wcstombs(null, s, 0);
 wcstombs(result, s, result.length);
 setlocale(LC_ALL, o);
 }
 }
 return result;
 }

 char* toMBSz(wchar* s) { return
 std.string.toStringz(toMBS(s[0..std.string.wcslen(s)])); }

 version(Win32){
 } else {
 private static Object locale_sync_object;
 // note that 'setlocale' should be used in 'synchronized'.
 }
Jan 05 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
<yaneurao sun-inet.or.jp> wrote in message
news:bt9ds1$1htl$1 digitaldaemon.com...

 I am reported that my game library doesn't go well in Win9x.


I'll see if I can get this fixed for the next update. -Walter
Jan 11 2004
parent reply yaneurao sun-inet.or.jp writes:
 I am reported that my game library doesn't go well in Win9x.


I'll see if I can get this fixed for the next update. -Walter


my game library can download here:
http://www.sun-inet.or.jp/~yaneurao/dlang/english.html

in yaneSDK4D , y4d_aux/file.d is a fixed version of std.file.
I hope std.file.d will be replaced by y4d_aux/file.d

note : std.file.read should try *W version API first , and if it fails ,
convert wchar[](UTF-16) into MBS(MultiByteString) and try *A version API.
I think it is better to have a global flag indicates
what *W APIs are not implemented.
Jan 11 2004
parent reply "Walter" <walter digitalmars.com> writes:
<yaneurao sun-inet.or.jp> wrote in message
news:bttg9u$309d$1 digitaldaemon.com...

 I am reported that my game library doesn't go well in Win9x.


I'll see if I can get this fixed for the next update. -Walter


 my game library can download here:
 http://www.sun-inet.or.jp/~yaneurao/dlang/english.html

 in yaneSDK4D , y4d_aux/file.d is a fixed version of std.file.
 I hope std.file.d will be replaced by y4d_aux/file.d


Thanks!


 note : std.file.read should try *W version API first , and if it fails ,
 convert wchar[](UTF-16) into MBS(MultiByteString) and try *A version API.
 I think it is better to have a global flag indicates
 what *W APIs are not implemented.


That was my first approach. But I think it is unnecessary, one only needs to
check GetVersion() for 95, 98, and ME. This is because the lack of support
is confined to 95, 98 and ME, and since they are officially abandoned by
Microsoft, it will never get fixed.
Jan 11 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 <yaneurao sun-inet.or.jp> wrote in message
 news:bttg9u$309d$1 digitaldaemon.com...

 I am reported that my game library doesn't go well in Win9x.


I'll see if I can get this fixed for the next update. -Walter


 my game library can download here:
 http://www.sun-inet.or.jp/~yaneurao/dlang/english.html

 in yaneSDK4D , y4d_aux/file.d is a fixed version of std.file.
 I hope std.file.d will be replaced by y4d_aux/file.d


 Thanks!


 note : std.file.read should try *W version API first , and if it fails ,
 convert wchar[](UTF-16) into MBS(MultiByteString) and try *A version




API.

 I think it is better to have a global flag indicates
 what *W APIs are not implemented.


 That was my first approach. But I think it is unnecessary, one only needs


to

 check GetVersion() for 95, 98, and ME. This is because the lack of support
 is confined to 95, 98 and ME, and since they are officially abandoned by
 Microsoft, it will never get fixed.


That's true for the A vs W issue, but there are also API functions that are
added as the OSs, and even the Service Packs, progress.
Jan 12 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:btts7n$kj8$1 digitaldaemon.com...

 That was my first approach. But I think it is unnecessary, one only




needs

 to

 check GetVersion() for 95, 98, and ME. This is because the lack of




support

 is confined to 95, 98 and ME, and since they are officially abandoned by
 Microsoft, it will never get fixed.


 That's true for the A vs W issue, but there are also API functions that


are

 added as the OSs, and even the Service Packs, progress.


In general, I'd prefer to rely on failure indications rather than version
numbers to check for features. But my experience with that with the win32
API has been rather negative, the failure indications are unreliable. For
example, the 'copy-on-write' for memory mapped files is not implemented on
Win95, but the API, instead of failing, silently converts it to 'write'.
Jan 12 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 That was my first approach. But I think it is unnecessary, one only




 needs

 to

 check GetVersion() for 95, 98, and ME. This is because the lack of




 support

 is confined to 95, 98 and ME, and since they are officially abandoned






by

 Microsoft, it will never get fixed.


 That's true for the A vs W issue, but there are also API functions that


 are

 added as the OSs, and even the Service Packs, progress.


 In general, I'd prefer to rely on failure indications rather than version
 numbers to check for features. But my experience with that with the win32
 API has been rather negative, the failure indications are unreliable. For
 example, the 'copy-on-write' for memory mapped files is not implemented on
 Win95, but the API, instead of failing, silently converts it to 'write'.


Indeed. All this argues for a win32 layer, but I think several people have
already questioned whether it is better as a separate library rather than in
the language. I'm still in two (or three) minds about the whole issue. :(
Jan 12 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:


That was my first approach. But I think it is unnecessary, one only
        




needs
    


to
      


check GetVersion() for 95, 98, and ME. This is because the lack of
        




support
    


is confined to 95, 98 and ME, and since they are officially abandoned
        






by
  


Microsoft, it will never get fixed.
        


That's true for the A vs W issue, but there are also API functions that
      


are
    


added as the OSs, and even the Service Packs, progress.
      


In general, I'd prefer to rely on failure indications rather than version
numbers to check for features. But my experience with that with the win32
API has been rather negative, the failure indications are unreliable. For
example, the 'copy-on-write' for memory mapped files is not implemented on
Win95, but the API, instead of failing, silently converts it to 'write'.
    


Indeed. All this argues for a win32 layer, but I think several people have
already questioned whether it is better as a separate library rather than in
the language. I'm still in two (or three) minds about the whole issue. :(


  


Parhaps users could specify what OS type they wish to compile for. ie

pragma (Win95)

pragma (Hibrid) //Any

pragma (WinNT)

ect...

That way they can be certain that it'll compile for that OS. Any problem 
functions would cause an error in the compiler.  Only problem is that 
you need to know which ones have the errors.
Jan 12 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
J Anderson wrote:


 Matthew wrote:


 That was my first approach. But I think it is unnecessary, one only
       




 needs
   


 to
     


 check GetVersion() for 95, 98, and ME. This is because the lack of
       




 support
   


 is confined to 95, 98 and ME, and since they are officially abandoned
       






 by
  


 Microsoft, it will never get fixed.
       


 That's true for the A vs W issue, but there are also API functions 
 that
     


 are
   


 added as the OSs, and even the Service Packs, progress.
     


 In general, I'd prefer to rely on failure indications rather than 
 version
 numbers to check for features. But my experience with that with the 
 win32
 API has been rather negative, the failure indications are 
 unreliable. For
 example, the 'copy-on-write' for memory mapped files is not 
 implemented on
 Win95, but the API, instead of failing, silently converts it to 
 'write'.
   



 Indeed. All this argues for a win32 layer, but I think several people 
 have
 already questioned whether it is better as a separate library rather 
 than in
 the language. I'm still in two (or three) minds about the whole 
 issue. :(


  


 Parhaps users could specify what OS type they wish to compile for. ie

 pragma (Win95)

 pragma (Hibrid) //Any

 pragma (WinNT)

 ect...

 That way they can be certain that it'll compile for that OS. Any 
 problem functions would cause an error in the compiler.  Only problem 
 is that you need to know which ones have the errors.


I should add that problem functions could be coded something-like-this 
to report errors.

Version (Win95)
{  
    CreateFileW(...)
    {
       static_assert("W Functions not supported in win95.");
    }

)
else if (Hybrid)
{
   //Some solution that works for both win95 and winNT
}
else
{
   export CreateFileW(...); //Normal

}

Programmers wouldn't be able to use the function in a win95 product, but 
at least they know it won't work.

Anderson
Jan 12 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:btvqnr$ql9$1 digitaldaemon.com...

 J Anderson wrote:


 Matthew wrote:


 That was my first approach. But I think it is unnecessary, one only




 needs



 to



 check GetVersion() for 95, 98, and ME. This is because the lack of




 support



 is confined to 95, 98 and ME, and since they are officially












abandoned






 by



 Microsoft, it will never get fixed.


 That's true for the A vs W issue, but there are also API functions
 that


 are



 added as the OSs, and even the Service Packs, progress.


 In general, I'd prefer to rely on failure indications rather than
 version
 numbers to check for features. But my experience with that with the
 win32
 API has been rather negative, the failure indications are
 unreliable. For
 example, the 'copy-on-write' for memory mapped files is not
 implemented on
 Win95, but the API, instead of failing, silently converts it to
 'write'.



 Indeed. All this argues for a win32 layer, but I think several people
 have
 already questioned whether it is better as a separate library rather
 than in
 the language. I'm still in two (or three) minds about the whole
 issue. :(


 Parhaps users could specify what OS type they wish to compile for. ie

 pragma (Win95)

 pragma (Hibrid) //Any

 pragma (WinNT)

 ect...

 That way they can be certain that it'll compile for that OS. Any
 problem functions would cause an error in the compiler.  Only problem
 is that you need to know which ones have the errors.


 I should add that problem functions could be coded something-like-this
 to report errors.

 Version (Win95)
 {
     CreateFileW(...)
     {
        static_assert("W Functions not supported in win95.");
     }

 )
 else if (Hybrid)
 {
    //Some solution that works for both win95 and winNT
 }
 else
 {
    export CreateFileW(...); //Normal

 }

 Programmers wouldn't be able to use the function in a win95 product, but
 at least they know it won't work.

 Anderson


I think you have the nexus of a good strategy here. The only challenge is
not to have to build in a load of Win-specific stuff to the compiler or,
heaven forfend, the language.

Still, it's a puzzle that needs to be solved. Already there are new people
who are complaining about writing Win32 code in D. I think that, even though
it's Win32's problem not D's, D will still be deemed painful if it does not
address these issues. We should remember that .NET handles all this filth,
and Java obviates the discussion by disallowing interaction with the Win32
(or any other) API. The bulk of people coming to D from that background will
be peed off to be met with all these hidden nasties.



 Jan 12 2004



 next sibling parent  J Anderson <REMOVEanderson badmama.com.au>  writes:


Matthew wrote:


"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:btvqnr$ql9$1 digitaldaemon.com...
  


J Anderson wrote:

    


Matthew wrote:

      


That was my first approach. But I think it is unnecessary, one only

              




needs


          


to


            


check GetVersion() for 95, 98, and ME. This is because the lack of

              




support


          


is confined to 95, 98 and ME, and since they are officially
              












abandoned
  


by


        


Microsoft, it will never get fixed.

              


That's true for the A vs W issue, but there are also API functions
that

            


are


          


added as the OSs, and even the Service Packs, progress.

            


In general, I'd prefer to rely on failure indications rather than
version
numbers to check for features. But my experience with that with the
win32
API has been rather negative, the failure indications are
unreliable. For
example, the 'copy-on-write' for memory mapped files is not
implemented on
Win95, but the API, instead of failing, silently converts it to
'write'.

          


Indeed. All this argues for a win32 layer, but I think several people
have
already questioned whether it is better as a separate library rather
than in
the language. I'm still in two (or three) minds about the whole
issue. :(




        


Parhaps users could specify what OS type they wish to compile for. ie

pragma (Win95)

pragma (Hibrid) //Any

pragma (WinNT)

ect...

That way they can be certain that it'll compile for that OS. Any
problem functions would cause an error in the compiler.  Only problem
is that you need to know which ones have the errors.

      


I should add that problem functions could be coded something-like-this
to report errors.

Version (Win95)
{
    CreateFileW(...)
    {
       static_assert("W Functions not supported in win95.");
    }

)
else if (Hybrid)
{
   //Some solution that works for both win95 and winNT
}
else
{
   export CreateFileW(...); //Normal

}

Programmers wouldn't be able to use the function in a win95 product, but
at least they know it won't work.

Anderson
    


I think you have the nexus of a good strategy here. The only challenge is
not to have to build in a load of Win-specific stuff to the compiler or,
heaven forfend, the language.

Still, it's a puzzle that needs to be solved. Already there are new people
who are complaining about writing Win32 code in D. I think that, even though
it's Win32's problem not D's, D will still be deemed painful if it does not
address these issues. We should remember that .NET handles all this filth,
and Java obviates the discussion by disallowing interaction with the Win32
(or any other) API. The bulk of people coming to D from that background will
be peed off to be met with all these hidden nasties.


  


I was thinking parhaps, something like the idea I present, could be used 
as an intermediate stage. Eventually when the problem is solved (this is 
in the general case, not just W functions), you would add the solution.



 Jan 12 2004



prev sibling  parent reply Ian Johnston <Ian_member pathlink.com>  writes:


In article <btvshd$t8k$1 digitaldaemon.com>, Matthew says...

[...]


I think you have the nexus of a good strategy here. The only challenge is
not to have to build in a load of Win-specific stuff to the compiler or,
heaven forfend, the language.

Still, it's a puzzle that needs to be solved. Already there are new people
who are complaining about writing Win32 code in D. I think that, even though
it's Win32's problem not D's, D will still be deemed painful if it does not
address these issues. We should remember that .NET handles all this filth,
and Java obviates the discussion by disallowing interaction with the Win32
(or any other) API. The bulk of people coming to D from that background will
be peed off to be met with all these hidden nasties.


If people want D to become a general-purpose and widely-used language, I think
it is important to move away from any focus on a particular system. Adding
win32 functionality into the language or compiler will lead to a niche language,
much like Delphi. This I think would be a sad thing, D has a lot going for it.

Perhaps those of you who mainly write for Windows should consider how you would
react if I started arguing for compiler and/or language support for Solaris
specific features and Linux specific features.

I think these issues have to be addressed at the library level. I dont see any
problem with having a layered set of D runtime libraries. After all, if you
want to use STL in the Microsoft C++ compiler world, you have to rely on more
than one runtime DLL from Microsoft, and this does not seem to prevent people
accepting applications written this way. Not to mention the huge jar files for
Java apps...

Ian



 Jan 13 2004



 next sibling parent  J Anderson <REMOVEanderson badmama.com.au>  writes:


Ian Johnston wrote:


In article <btvshd$t8k$1 digitaldaemon.com>, Matthew says...

[...]

  


I think you have the nexus of a good strategy here. The only challenge is
not to have to build in a load of Win-specific stuff to the compiler or,
heaven forfend, the language.

Still, it's a puzzle that needs to be solved. Already there are new people
who are complaining about writing Win32 code in D. I think that, even though
it's Win32's problem not D's, D will still be deemed painful if it does not
address these issues. We should remember that .NET handles all this filth,
and Java obviates the discussion by disallowing interaction with the Win32
(or any other) API. The bulk of people coming to D from that background will
be peed off to be met with all these hidden nasties.

    


If people want D to become a general-purpose and widely-used language, I think
it is important to move away from any focus on a particular system. Adding
win32 functionality into the language or compiler will lead to a niche language,
much like Delphi. This I think would be a sad thing, D has a lot going for it.

Perhaps those of you who mainly write for Windows should consider how you would
react if I started arguing for compiler and/or language support for Solaris
specific features and Linux specific features.

I think these issues have to be addressed at the library level. I dont see any
problem with having a layered set of D runtime libraries. After all, if you
want to use STL in the Microsoft C++ compiler world, you have to rely on more
than one runtime DLL from Microsoft, and this does not seem to prevent people
accepting applications written this way. Not to mention the huge jar files for
Java apps...

Ian


  


What about the SDL togglefullscreen mess?

That's why I suggest a hybrid mode. Most portable programs would be 
written in hybrid. In the beginning the hybrid mode would be highly 
restrictive, because lets face it, it's allot easier to port a single 
platform function to D then write a layer for it.  People who want to 
program to the metal still can. Using pragma's like I suggest, makes it 
easier to see which pieces of the code need to "fixed" for porting.  
You'd be able to *almost* test other platforms (within the same OS -> to 
keep size down), without actually using them.  As the cross-platform 
layer grows, most people will have less use for win95, linux86 ect... 
pragmas.  But we need to use windows functions at the moment, and D only 
works for 2 platforms ATM anyway.

Anderson



 Jan 13 2004



prev sibling  parent reply "Matthew" <matthew.hat stlsoft.dot.org>  writes:


 [...]


I think you have the nexus of a good strategy here. The only challenge is
not to have to build in a load of Win-specific stuff to the compiler or,
heaven forfend, the language.

Still, it's a puzzle that needs to be solved. Already there are new




people

who are complaining about writing Win32 code in D. I think that, even




though

it's Win32's problem not D's, D will still be deemed painful if it does




not

address these issues. We should remember that .NET handles all this




filth,

and Java obviates the discussion by disallowing interaction with the




Win32

(or any other) API. The bulk of people coming to D from that background




will

be peed off to be met with all these hidden nasties.


 If people want D to become a general-purpose and widely-used language, I


think

 it is important to move away from any focus on a particular system. Adding
 win32 functionality into the language or compiler will lead to a niche


language,

 much like Delphi.


This is all dependent on perspective. In so far as the discussion has
implied, D already has Win32 functionality in the language, as it does
Linux. I don't really grok what you mean, unless you object to Win32 (or
Linux) -specific modules in the standard library.


 This I think would be a sad thing, D has a lot going for it.


There is the potential for this to be true, but it is by no means the
certainty you imply.


 Perhaps those of you who mainly write for Windows should consider how you


would

 react if I started arguing for compiler and/or language support for


Solaris

 specific features and Linux specific features.


Frankly, this sounds to me like you're taking personal umbrage, at a
perceived unwarranted focus on Win32.

I know little about Solaris, not having programmed at the GUI level on it.
However, if:

1. Solaris, or any other Unixen, or indeed any other operating system, has
the same issues of an ostensibly compatible API with the various hidden
not-present or not-functioning functions / APIs that Win32 has, and
2. The success and/or failure of D in the short/medium term was
significantly linked to successful use on that/those platform(s)

then I would welcome it.

In fact, I'd welcome it anyway, because I'd be interested both generally and
specifically in these issues.

It's irrelevant to me or to D that you don't want to discuss the need for D
to succeed on Win32, or that you choose to see it as some slight on other
operating systems. That in itself is strange.

Win32 has all these issues because Microsoft have consistently prioritised
backwards compatibility. That has assured them, more than any other factor,
of commercial success. Because of the commercial success, we need to take
care that D is successful on this most visible of platforms. Because of the
compatibility gotchas, that only come as a result of the backwards
compatibility, that are there to provide the commercial success, that makes
us care about D on Win32, we need to be concerned. It's not an ideal world,
I didn't write the rules, it's a Catch 22, let's deal with it, eh?


 I think these issues have to be addressed at the library level. I dont see


any

 problem with having a layered set of D runtime libraries.


Isn't this what our discussion is trying to ascertain?


 After all, if you
 want to use STL in the Microsoft C++ compiler world, you have to rely on


more

 than one runtime DLL from Microsoft, and this does not seem to prevent


people

 accepting applications written this way.


This is not necessarily true. It's only so if people wish to communicate via
STL objects between link-units, which is something that is often best
reconsidered.


 Not to mention the huge jar files for
 Java apps...


Let's hear your suggestions ...

Matthew



 Jan 13 2004



 next sibling parent reply J Anderson <REMOVEanderson badmama.com.au>  writes:


Matthew wrote:


[...]

    


I think you have the nexus of a good strategy here. The only challenge is
not to have to build in a load of Win-specific stuff to the compiler or,
heaven forfend, the language.

Still, it's a puzzle that needs to be solved. Already there are new
      




people
  


who are complaining about writing Win32 code in D. I think that, even
      




though
  


it's Win32's problem not D's, D will still be deemed painful if it does
      




not
  


address these issues. We should remember that .NET handles all this
      




filth,
  


and Java obviates the discussion by disallowing interaction with the
      




Win32
  


(or any other) API. The bulk of people coming to D from that background
      




will
  


be peed off to be met with all these hidden nasties.

      


If people want D to become a general-purpose and widely-used language, I
    


think
  


it is important to move away from any focus on a particular system. Adding
win32 functionality into the language or compiler will lead to a niche
    


language,
  


much like Delphi.
    


This is all dependent on perspective. In so far as the discussion has
implied, D already has Win32 functionality in the language, as it does
Linux. I don't really grok what you mean, unless you object to Win32 (or
Linux) -specific modules in the standard library.

  


This I think would be a sad thing, D has a lot going for it.
    


There is the potential for this to be true, but it is by no means the
certainty you imply.

  


Perhaps those of you who mainly write for Windows should consider how you
    


would
  


react if I started arguing for compiler and/or language support for
    


Solaris
  


specific features and Linux specific features.
    


Frankly, this sounds to me like you're taking personal umbrage, at a
perceived unwarranted focus on Win32.

I know little about Solaris, not having programmed at the GUI level on it.
However, if:

1. Solaris, or any other Unixen, or indeed any other operating system, has
the same issues of an ostensibly compatible API with the various hidden
not-present or not-functioning functions / APIs that Win32 has, and
2. The success and/or failure of D in the short/medium term was
significantly linked to successful use on that/those platform(s)

then I would welcome it.

In fact, I'd welcome it anyway, because I'd be interested both generally and
specifically in these issues.

It's irrelevant to me or to D that you don't want to discuss the need for D
to succeed on Win32, or that you choose to see it as some slight on other
operating systems. That in itself is strange.

Win32 has all these issues because Microsoft have consistently prioritised
backwards compatibility. That has assured them, more than any other factor,
of commercial success. Because of the commercial success, we need to take
care that D is successful on this most visible of platforms. Because of the
compatibility gotchas, that only come as a result of the backwards
compatibility, that are there to provide the commercial success, that makes
us care about D on Win32, we need to be concerned. It's not an ideal world,
I didn't write the rules, it's a Catch 22, let's deal with it, eh?

  


I think these issues have to be addressed at the library level. I dont see
    


any
  


problem with having a layered set of D runtime libraries.
    


Isn't this what our discussion is trying to ascertain?

  


After all, if you
want to use STL in the Microsoft C++ compiler world, you have to rely on
    


more
  


than one runtime DLL from Microsoft, and this does not seem to prevent
    


people
  


accepting applications written this way.
    


This is not necessarily true. It's only so if people wish to communicate via
STL objects between link-units, which is something that is often best
reconsidered.

  


Not to mention the huge jar files for
Java apps...
    


Let's hear your suggestions ...

Matthew


  


We'll said (as always!)



 Jan 13 2004



  parent  "Matthew" <matthew.hat stlsoft.dot.org>  writes:


<snip>

 We'll said (as always!)


You're too kind.

I'm a simple man, in no need of praise. (And if you believe that ...)



 Jan 13 2004



prev sibling  parent  Ian Johnston <Ian_member pathlink.com>  writes:


In article <bu0jqf$257c$1 digitaldaemon.com>, Matthew says...

 [...]


I think you have the nexus of a good strategy here. The only challenge is
not to have to build in a load of Win-specific stuff to the compiler or,
heaven forfend, the language.

Still, it's a puzzle that needs to be solved. Already there are new




people

who are complaining about writing Win32 code in D. I think that, even




though

it's Win32's problem not D's, D will still be deemed painful if it does




not

address these issues. We should remember that .NET handles all this




filth,

and Java obviates the discussion by disallowing interaction with the




Win32

(or any other) API. The bulk of people coming to D from that background




will

be peed off to be met with all these hidden nasties.


 If people want D to become a general-purpose and widely-used language, I


think

 it is important to move away from any focus on a particular system. Adding
 win32 functionality into the language or compiler will lead to a niche


language,

 much like Delphi.


This is all dependent on perspective. In so far as the discussion has
implied, D already has Win32 functionality in the language, as it does
Linux. I don't really grok what you mean, unless you object to Win32 (or
Linux) -specific modules in the standard library.


No, I dont object at all to system-specific modules in the standard library,
quite the opposite; I just thought I understood part of the discussion to be
about adding system-specific features to the language. Maybe I just lost it
somewhere :-)


 This I think would be a sad thing, D has a lot going for it.


There is the potential for this to be true, but it is by no means the
certainty you imply.


Yes, indeed success on Windows platforms is very important, but it would be
nice if it were not just Windows platforms, wouldn't it?


 Perhaps those of you who mainly write for Windows should consider how you


would

 react if I started arguing for compiler and/or language support for


Solaris

 specific features and Linux specific features.


Frankly, this sounds to me like you're taking personal umbrage, at a
perceived unwarranted focus on Win32.


Sorry, I certainly didn't mean to come across that way, and even now I am
not sure I understand how I created that impression :-))

I wasn't driving at that, I was just thinking, if you step back from any
particular system's details, maybe it is easier to see that adding stuff to
the language (see above) is limiting.


I know little about Solaris, not having programmed at the GUI level on it.
However, if:

1. Solaris, or any other Unixen, or indeed any other operating system, has
the same issues of an ostensibly compatible API with the various hidden
not-present or not-functioning functions / APIs that Win32 has, and
2. The success and/or failure of D in the short/medium term was
significantly linked to successful use on that/those platform(s)

then I would welcome it.


Not at the GUI level, but in other system calls, this can arise, particularly
the difference between BSD-derivates and System V derivates.

On the GUI front, it is possibly an even bigger challenge, as there are
various toolkits around these days, at least in the open source world.


In fact, I'd welcome it anyway, because I'd be interested both generally and
specifically in these issues.

It's irrelevant to me or to D that you don't want to discuss the need for D
to succeed on Win32, or that you choose to see it as some slight on other
operating systems. That in itself is strange.


I do see a need to succeed on Win32. It would just be a pity if tons of D code
had to be rewritten to succeed on Win64 or whatever.


Win32 has all these issues because Microsoft have consistently prioritised
backwards compatibility. That has assured them, more than any other factor,
of commercial success. Because of the commercial success, we need to take
care that D is successful on this most visible of platforms. Because of the
compatibility gotchas, that only come as a result of the backwards
compatibility, that are there to provide the commercial success, that makes
us care about D on Win32, we need to be concerned. It's not an ideal world,
I didn't write the rules, it's a Catch 22, let's deal with it, eh?


Yes, understood. Didn't think I was criticising that, is my English so bad? :-))


 I think these issues have to be addressed at the library level. I dont see


any

 problem with having a layered set of D runtime libraries.


Isn't this what our discussion is trying to ascertain?


Was it limited to libraries? Sorry, I thought there was a language element too.


 After all, if you
 want to use STL in the Microsoft C++ compiler world, you have to rely on


more

 than one runtime DLL from Microsoft, and this does not seem to prevent


people

 accepting applications written this way.


This is not necessarily true. It's only so if people wish to communicate via
STL objects between link-units, which is something that is often best
reconsidered.


 Not to mention the huge jar files for
 Java apps...


Let's hear your suggestions ...

Matthew


Well, as implied, a core set of libraries with OS-independent functionality,
plus a layer for OS-specific-non-GUI functionality (get contents of a
directory, for example), then a GUI library. In the Windows case, there would
be different instances of modules for A/W etc items; I would expect these
however not to perform any runtime checks. If you tried to use a W library
where the OS does not support the functions, it won't load. This should be
a packaging issue, it seems to me.

I don't see this as anything new really; it is standard library packaging stuff.

Ian



 Jan 13 2004



prev sibling  parent reply Mark T <Mark_member pathlink.com>  writes:


That was my first approach. But I think it is unnecessary, one only needs to
check GetVersion() for 95, 98, and ME. This is because the lack of support
is confined to 95, 98 and ME, and since they are officially abandoned by
Microsoft, it will never get fixed.


True but millions of people are still using these at home, it will take years
before XP and follow-on displace these, only gamers upgrade all the time. I have
2 PCs at home both running Win98 and don't expect a new machine until around
2005 sometime.



 Jan 16 2004



  parent reply "Matthew" <matthew.hat stlsoft.dot.org>  writes:


That was my first approach. But I think it is unnecessary, one only needs




to

check GetVersion() for 95, 98, and ME. This is because the lack of




support

is confined to 95, 98 and ME, and since they are officially abandoned by
Microsoft, it will never get fixed.


 True but millions of people are still using these at home, it will take


years

 before XP and follow-on displace these, only gamers upgrade all the time.


I have

 2 PCs at home both running Win98 and don't expect a new machine until


around

 2005 sometime.


Exactly!

It's all very well for developers, who develop and test on modern OSs, to
proclaim that there is no problem. The reality is that *many* users, and
quite a lot of developers (such as yourself) still use Win9x, and to ignore
it will be folly for D.



 Jan 16 2004



  parent  Georg Wrede <Georg_member pathlink.com>  writes:


 2 PCs at home both running Win98 and don't expect a new machine until
 around 2005 sometime.


Exactly!

It's all very well for developers, who develop and test on modern OSs, to
proclaim that there is no problem. The reality is that *many* users, and
quite a lot of developers (such as yourself) still use Win9x, and to ignore
it will be folly for D.


Most of my relatives and neighbors have the newest version of Windows.
And that's because it just is there when you buy a new computer. There's
no end of grievances with the new Nice Features. New updates come almost
every day by the wire, your games stop mysteriously working, you get the
feeling Big Bill is spying on you, you don't dare to change any hardware
on any machine with important files (because at home nobody has any
backups). And the worst thing is that the new Windowses pretend to be
alive, like Real OSs. That is, they do things on their own, and the user
just hears the hard disk rattling, with no idea of what's going on. Is
it a hacker on the machine, has it become a junk mail server, or is it
just Windows pondering over its own existence.

I have W2k on one, and W95 and W98 on other machines. And I sure as 
hell need some serious reasons for not removing any new Windows that
comes with new hardware. Today I only use Windows when I have to use
a Windows-only program (like the Ecco PIM, accounting, and Word and
Excel, which still feel smoother and have daily used features that
I can't find in Open Office). The Office-97 versions are good enough
for me.



 Jan 17 2004