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