www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Yet another effort at translating the Win32 API headers

reply Stewart Gordon <smjg_1998 yahoo.com> writes:
I know there have been a number of efforts already, but none of them 
seem to be perfect.  As such, I've decided to start a project to tidy 
them up.

This work is based on Y. Tomino's translation of the Win32 headers into D:

http://tinyurl.com/s66xg

(Granted, Google doesn't exactly generate English as we know it from 
Japanese, but still....)

At the moment I've done only commctrl.d.  Yes, this is a rather long 
file, but it's given me a chance to draw up a decent list of 
improvements to be implemented.  I've also tweaked two of the other 
files to get it to compile, but not gone through improving them.  Notice 
that commctrl.d has been reduced from two files adding to 15200 lines, 
412K to a single file of 6320 lines, 166K.

Download the work so far:

http://pr.stewartsplace.org.uk/d/win32.zip

(Only the files that have actually been modified are in the download - 
see the above URL for those pending.)

See the readme.txt file for a description of the improvements that have 
been made.  Anybody is more than welcome to take another of the files 
and implement these improvements.  Please announce which file you are 
taking in a followup to this post, to avoid duplication of effort.  When 
you've done it, you may post it as an attachment here or send it to me 
by email.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-  C++  a->--- UB  P+ L E  W++  N+++ o K-  w++  O? M V? PS- 
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Mar 20 2006
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Stewart,

Please consider using the mingw W32API headers, instead of the official 
Microsoft ones.

http://cvs.sourceforge.net/viewcvs.py/mingw/w32api/#dirlist

There are legal issues surrounding the Microsoft headers (AFAIK, you are 
not permitted to redistribute them). If the W32API headers are used 
instead, we'll be able to include them in the DMD/GDC downloads.
Fortunately, the W32API is extremely similar to the Microsoft ones, so 
it shouldn't be hard to use them instead.

Any improvement over std.c.windows would be *greatly* appreciated.

-Don.



Stewart Gordon wrote:
 I know there have been a number of efforts already, but none of them 
 seem to be perfect.  As such, I've decided to start a project to tidy 
 them up.
 
 This work is based on Y. Tomino's translation of the Win32 headers into D:
 
 http://tinyurl.com/s66xg
 
 (Granted, Google doesn't exactly generate English as we know it from 
 Japanese, but still....)
 
 At the moment I've done only commctrl.d.  Yes, this is a rather long 
 file, but it's given me a chance to draw up a decent list of 
 improvements to be implemented.  I've also tweaked two of the other 
 files to get it to compile, but not gone through improving them.  Notice 
 that commctrl.d has been reduced from two files adding to 15200 lines, 
 412K to a single file of 6320 lines, 166K.
 
 Download the work so far:
 
 http://pr.stewartsplace.org.uk/d/win32.zip
 
 (Only the files that have actually been modified are in the download - 
 see the above URL for those pending.)
 
 See the readme.txt file for a description of the improvements that have 
 been made.  Anybody is more than welcome to take another of the files 
 and implement these improvements.  Please announce which file you are 
 taking in a followup to this post, to avoid duplication of effort.  When 
 you've done it, you may post it as an attachment here or send it to me 
 by email.
 
 Stewart.
 
Mar 20 2006
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Don Clugston wrote:
 Stewart,
 
 Please consider using the mingw W32API headers, instead of the official 
 Microsoft ones.
 
 http://cvs.sourceforge.net/viewcvs.py/mingw/w32api/#dirlist
Anybody who wants to write files for this project from MinGW instead is more than welcome. It doesn't really matter what we start from
 There are legal issues surrounding the Microsoft headers (AFAIK, you are 
 not permitted to redistribute them). If the W32API headers are used 
 instead, we'll be able to include them in the DMD/GDC downloads.
 Fortunately, the W32API is extremely similar to the Microsoft ones, so 
 it shouldn't be hard to use them instead.
<snip> I basically chose to start from Tomino's work because it's a fairly comprehensive set of headers for which the first step (translating into D) has already been done. But you're right to mention it insofar as that project claims to be derived from M$'s own. Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 20 2006
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
This project is now officially based on the public domain MinGW headers. 
  I've translated a few more of the files on this basis, and rewritten 
the instructions to make more sense to a translation from C headers.

I've also set up a page on Wiki4D to coordinate the project:

http://www.prowiki.org/wiki4d/wiki.cgi?WindowsAPI

Now, who's going to contribute?

In line with comments from various people including Walter, my plan is 
for the work to be public domain.  Is this OK with everyone?


The main open issue I can think of at the moment is what to do with the 
Windows version CC stuff.

We could get rid of the CC and just compile everything in, but this'll 
make it easy to lose track of the minimum Windows version an application 
supports.  We probably don't really need to distinguish between 
Win95/NT4 and earlier Win32 (Win32s, whatever else) anymore, but it 
might still be worth doing it with some or all Windows versions since then.

Defining a set of version identifiers for the supported Windows versions 
along the Win9x and WinNT lines is another possibility, but it'll take a 
bit of work to determine how the #ifs should be converted.

This has also brought out my wish for a version import facility once 
again....

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/11981

Meanwhile, can we get away with supplying a set of command line files 
for various Windows versions?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-  C++  a->--- UB  P+ L E  W++  N+++ o K-  w++  O? M V? PS- 
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Mar 28 2006
next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Stewart Gordon wrote:
 This project is now officially based on the public domain MinGW headers. 
  I've translated a few more of the files on this basis, and rewritten 
 the instructions to make more sense to a translation from C headers.
 
 I've also set up a page on Wiki4D to coordinate the project:
 
 http://www.prowiki.org/wiki4d/wiki.cgi?WindowsAPI
 
 Now, who's going to contribute?
 
 In line with comments from various people including Walter, my plan is 
 for the work to be public domain.  Is this OK with everyone?
 
 
 The main open issue I can think of at the moment is what to do with the 
 Windows version CC stuff.
 
 We could get rid of the CC and just compile everything in, but this'll 
 make it easy to lose track of the minimum Windows version an application 
 supports.  We probably don't really need to distinguish between 
 Win95/NT4 and earlier Win32 (Win32s, whatever else) anymore, but it 
 might still be worth doing it with some or all Windows versions since then.
 
 Defining a set of version identifiers for the supported Windows versions 
 along the Win9x and WinNT lines is another possibility, but it'll take a 
 bit of work to determine how the #ifs should be converted.
 
 This has also brought out my wish for a version import facility once 
 again....
 
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/11981
 
 Meanwhile, can we get away with supplying a set of command line files 
 for various Windows versions?
 
 Stewart.
 
Its probably legally better to offer it under one of the freest licenses (MIT, BSD, libpng, etc.)
Mar 28 2006
parent reply J C Calvarese <technocrat7 gmail.com> writes:
In article <e0cf4q$mu3$1 digitaldaemon.com>, Kyle Furlong says...
Stewart Gordon wrote:
 This project is now officially based on the public domain MinGW headers. 
  I've translated a few more of the files on this basis, and rewritten 
 the instructions to make more sense to a translation from C headers.
 
 I've also set up a page on Wiki4D to coordinate the project:
 
 http://www.prowiki.org/wiki4d/wiki.cgi?WindowsAPI
 
 Now, who's going to contribute?
 
 In line with comments from various people including Walter, my plan is 
 for the work to be public domain.  Is this OK with everyone?
..
Its probably legally better to offer it under one of the freest licenses (MIT,
>BSD, libpng, etc.)
What's freer than releasing it as public domain? Public domain would be my preference if it were my choice. jcc7
Mar 28 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
J C Calvarese wrote:
 In article <e0cf4q$mu3$1 digitaldaemon.com>, Kyle Furlong says...
 Stewart Gordon wrote:
 This project is now officially based on the public domain MinGW headers. 
  I've translated a few more of the files on this basis, and rewritten 
 the instructions to make more sense to a translation from C headers.

 I've also set up a page on Wiki4D to coordinate the project:

 http://www.prowiki.org/wiki4d/wiki.cgi?WindowsAPI

 Now, who's going to contribute?

 In line with comments from various people including Walter, my plan is 
 for the work to be public domain.  Is this OK with everyone?
..
 Its probably legally better to offer it under one of the freest licenses (MIT,
>BSD, libpng, etc.)
What's freer than releasing it as public domain? Public domain would be my preference if it were my choice. jcc7
The problem with releasing anything into the public domain is that eventually it becomes ambiguous that it IS public domain. People drop the work anywhere and however they please, and somewhere down the line someone asks, "Hey what is the licensing of such and such." If the project is inactive its easy for this ambiguity to arise. Thus, having an explicit license which stipulates that use of the work is completely free, and that copies of the license must be distributed with the work avoid this.
Mar 28 2006
parent Bastiaan Veelo <Bastiaan.N.Veelo ntnu.no> writes:
Kyle Furlong wrote:
 J C Calvarese wrote:
 What's freer than releasing it as public domain? Public domain would 
 be my
 preference if it were my choice.

 jcc7
The problem with releasing anything into the public domain is that eventually it becomes ambiguous that it IS public domain. People drop the work anywhere and however they please, and somewhere down the line someone asks, "Hey what is the licensing of such and such." If the project is inactive its easy for this ambiguity to arise. Thus, having an explicit license which stipulates that use of the work is completely free, and that copies of the license must be distributed with the work avoid this.
And, releasing in the public domain seems to be problematic in itself, at least in some countries. In the Ares 0.15 release thread I wrote: It appears you cannot simply donate files to the public domain. According to Lawrence Rosen [1], an attorney who served for many years as general counsel and secretary of the Open Source Initiative, "there is no accepted way to dedicate an original work of authorship to the public domain before the copyright term for that work expires. A license is the only recognized way to authorize others to undertake the authors’ exclusive copyright rights." This is the raison d'être of all-permissive licenses like MIT, BSD etc. [1] Lawrence Rosen, 2004, "Open Source Licensing -- Software Freedom and Intellectual Property Law", Prentice Hall, New Yersey, page 74, http://www.rosenlaw.com/Rosen_Ch05.pdf
Mar 30 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Stewart Gordon wrote:
 This project is now officially based on the public domain MinGW headers. 
  I've translated a few more of the files on this basis, and rewritten 
 the instructions to make more sense to a translation from C headers.
 
 I've also set up a page on Wiki4D to coordinate the project:
 
 http://www.prowiki.org/wiki4d/wiki.cgi?WindowsAPI
Fantastic!
 Now, who's going to contribute?
I hope that I can do a bit.
 
 In line with comments from various people including Walter, my plan is 
 for the work to be public domain.  Is this OK with everyone?
 
 The main open issue I can think of at the moment is what to do with the 
 Windows version CC stuff.
 
 We could get rid of the CC and just compile everything in, but this'll 
 make it easy to lose track of the minimum Windows version an application 
 supports.  We probably don't really need to distinguish between 
 Win95/NT4 and earlier Win32 (Win32s, whatever else) anymore, but it 
 might still be worth doing it with some or all Windows versions since then.
Definitely worthwhile for Win95 and above.
 Defining a set of version identifiers for the supported Windows versions 
 along the Win9x and WinNT lines is another possibility, but it'll take a 
 bit of work to determine how the #ifs should be converted.
It's possible to use 'static if', now that it works at module scope. #if (WINVER > 0x4000) #else #endif can become static if (WINVER> 0x4000) { } else { } It's probably abuse of 'static if', but it should work as an interim solution. Don.
Mar 29 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Don Clugston wrote:
 Stewart Gordon wrote:
<snip>
 Now, who's going to contribute?
I hope that I can do a bit.
Excellent! <snip>
 Defining a set of version identifiers for the supported Windows 
 versions along the Win9x and WinNT lines is another possibility, but 
 it'll take a bit of work to determine how the #ifs should be converted.
It's possible to use 'static if', now that it works at module scope. #if (WINVER > 0x4000) #else #endif can become static if (WINVER> 0x4000) { } else { } It's probably abuse of 'static if', but it should work as an interim solution.
Where would the user set WINVER? A module for the user to edit to supply this data might be one possibility, but it would be a nightmare for someone maintaining or even trying to compile several projects that have different OS requirements. But for as long as it's only an interim solution.... It would also be nice if the policy for using the versions is clearer than the WINVER/_WIN32_WINDOWS/_WIN32_WINNT stuff is at the moment. At the moment, I'm puzzled by the number of instances of this #if (_WIN32_WINDOWS >= 0x0410 || _WIN32_WINNT >= 0x0500) or similar. It seems to be saying that the function may be used by either an application that supports Win98 or an application that supports Win2000. So you could have a program that works on Windows 98 and Windows NT4 but not Windows 95, or a program that works on Windows 95 and Windows 2000 but not Windows NT4, and whatever is in that #if would be available to either. Unless I'm misunderstanding, it would appear that the || should be an &&. Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 29 2006
next sibling parent reply xs0 <xs0 xs0.com> writes:
Stewart Gordon wrote:
 It would also be nice if the policy for using the versions is clearer 
 than the WINVER/_WIN32_WINDOWS/_WIN32_WINNT stuff is at the moment.  At 
 the moment, I'm puzzled by the number of instances of this
 
 #if (_WIN32_WINDOWS >= 0x0410 || _WIN32_WINNT >= 0x0500)
 
 or similar.  It seems to be saying that the function may be used by 
 either an application that supports Win98 or an application that 
 supports Win2000.  So you could have a program that works on Windows 98 
 and Windows NT4 but not Windows 95, or a program that works on Windows 
 95 and Windows 2000 but not Windows NT4, and whatever is in that #if 
 would be available to either.  Unless I'm misunderstanding, it would 
 appear that the || should be an &&.
I think that the system is like this: _WIN32_WINDOWS is defined only for Win95/98/Me (the crappy ones) _WIN32_WINNT is defined only for Win NT4/2k/XP/Vista/... (the OK ones) WINVER is defined for all Windows, and equals _WIN32_* for any given OS. Now, the above condition does have to use an ||, as it's never the case that both are defined. It's also true that it could simply be (in this case) #if (WINVER >= 0x0410) because there is no _WIN32_WINNT between 0x0410 and 0x0500.. You also made a slight mistake - the condition doesn't hold for neither of NT4 or Win95, so it's actually not that confusing :) xs0
Mar 29 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
xs0 wrote:
<snip>
 I think that the system is like this:
 
 _WIN32_WINDOWS is defined only for Win95/98/Me (the crappy ones)
 _WIN32_WINNT is defined only for Win NT4/2k/XP/Vista/... (the OK ones)
When one writes a Windows application, it is often hoped that it will work on both lines of Windows.
 WINVER is defined for all Windows, and equals _WIN32_* for any given OS.
 
 Now, the above condition does have to use an ||, as it's never the case 
 that both are defined. It's also true that it could simply be (in this 
 case)
<snip> So I'm writing my program for both Windows 98 and Windows 2000, what versions should I set? Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 29 2006
parent reply xs0 <xs0 xs0.com> writes:
Stewart Gordon wrote:
 xs0 wrote:
 <snip>
 I think that the system is like this:

 _WIN32_WINDOWS is defined only for Win95/98/Me (the crappy ones)
 _WIN32_WINNT is defined only for Win NT4/2k/XP/Vista/... (the OK ones)
When one writes a Windows application, it is often hoped that it will work on both lines of Windows.
You're absolutely right :)
 WINVER is defined for all Windows, and equals _WIN32_* for any given OS.

 Now, the above condition does have to use an ||, as it's never the 
 case that both are defined. It's also true that it could simply be (in 
 this case)
<snip> So I'm writing my program for both Windows 98 and Windows 2000, what versions should I set?
both _WIN32_WINDOWS=0x0410 and _WIN32_WINNT=0x0500 I was obviosuly wrong in saying that both are never defined :) I should get more sleep before posting next time. It should still be ||, though, because otherwise you'd always have to declare both, and there's no real need. BTW, wouldn't something like this work for CC: version(WINAPI_98) { version=WINAPI_95; } version(WINAPI_ME) { version=WINAPI_98; version=WINAPI_95; } version(WINAPI_95) { // win 95 funcs } version(WINAPI_98) { // funcs new in Win 98 } version(WINAPI_ME) { // funcs new in Win Me } Then, when compiling, you can set the api version you want with -version=?. If you don't set it, it should probably default to the latest known version? xs0
Mar 29 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
xs0 wrote:
 Stewart Gordon wrote:
 xs0 wrote:
<snip>
 Now, the above condition does have to use an ||, as it's never the 
 case that both are defined. It's also true that it could simply be 
 (in this case)
<snip> So I'm writing my program for both Windows 98 and Windows 2000, what versions should I set?
both _WIN32_WINDOWS=0x0410 and _WIN32_WINNT=0x0500
And leave WINVER undefined?
 I was obviosuly wrong in saying that both are never defined :) I should 
 get more sleep before posting next time. It should still be ||, though, 
 because otherwise you'd always have to declare both, and there's no real 
 need.
I think I see what you mean now.
 BTW, wouldn't something like this work for CC:
 
 version(WINAPI_98) {
     version=WINAPI_95;
 }
I was thinking something like this myself. Though with names like Windows98, WindowsME, Windows2000 rather than WINAPI_*. <snip>
 Then, when compiling, you can set the api version you want with 
 -version=?. If you don't set it, it should probably default to the 
 latest known version?
This structure would imply that not setting it would default to the earliest known version. As is the case with the C headers. I was thinking of 95/NT4 being the default level and versioning to enable higher Windows versions. I'll study the headers a bit more and correlate them with the info on the MSDN site. This should help to understand what should be enabled when. Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 29 2006
parent reply James Pelcis <jpelcis gmail.com> writes:
I'll help out on this project, too.  I've got some of the smaller bits 
done, but an official answer to how to handle this consistently will be 
necessary before I can do too much more.

Here's some of the stuff I think is done and works, but I haven't had a 
chance to really do anything do test it yet.

http://www.summerseas.com/jpelcis/downloads/win32-032906.zip

Stewart Gordon wrote:
 xs0 wrote:
 Stewart Gordon wrote:
 xs0 wrote:
<snip>
 Now, the above condition does have to use an ||, as it's never the 
 case that both are defined. It's also true that it could simply be 
 (in this case)
<snip> So I'm writing my program for both Windows 98 and Windows 2000, what versions should I set?
both _WIN32_WINDOWS=0x0410 and _WIN32_WINNT=0x0500
And leave WINVER undefined?
 I was obviosuly wrong in saying that both are never defined :) I 
 should get more sleep before posting next time. It should still be ||, 
 though, because otherwise you'd always have to declare both, and 
 there's no real need.
I think I see what you mean now.
 BTW, wouldn't something like this work for CC:

 version(WINAPI_98) {
     version=WINAPI_95;
 }
I was thinking something like this myself. Though with names like Windows98, WindowsME, Windows2000 rather than WINAPI_*. <snip>
 Then, when compiling, you can set the api version you want with 
 -version=?. If you don't set it, it should probably default to the 
 latest known version?
This structure would imply that not setting it would default to the earliest known version. As is the case with the C headers. I was thinking of 95/NT4 being the default level and versioning to enable higher Windows versions. I'll study the headers a bit more and correlate them with the info on the MSDN site. This should help to understand what should be enabled when. Stewart.
Mar 29 2006
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
James Pelcis wrote:
 I'll help out on this project, too.  I've got some of the smaller bits 
 done, but an official answer to how to handle this consistently will be 
 necessary before I can do too much more.
 
 Here's some of the stuff I think is done and works, but I haven't had a 
 chance to really do anything do test it yet.
 
 http://www.summerseas.com/jpelcis/downloads/win32-032906.zip
<snip top of upside-down reply> Thanks. But please use the Wiki4D page to assign files to yourself. That's what it's there for - so we can avoid duplication of effort. And you appear to have so far only done the basic translation and not had a good look through the instructions. And looking at dxerr8/9 in particular: - It's version (Unicode) not version (UNICODE). - We ought to define a debug identifier rather than using debug by itself. Since this is the only place where DEBUG is used, maybe debug (dxerr) or something similar? - You've separated the debug macros into ANSI and Unicode versions. Totally unnecessary. All A/W specific types have versioned aliases. This includes char/wchar, for which the alias is TCHAR. Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 30 2006
prev sibling next sibling parent Don Clugston <dac nospam.com.au> writes:
Stewart Gordon wrote:
 Don Clugston wrote:
 Stewart Gordon wrote:
<snip>
 Now, who's going to contribute?
I hope that I can do a bit.
Excellent! <snip>
 Defining a set of version identifiers for the supported Windows 
 versions along the Win9x and WinNT lines is another possibility, but 
 it'll take a bit of work to determine how the #ifs should be converted.
It's possible to use 'static if', now that it works at module scope. #if (WINVER > 0x4000) #else #endif can become static if (WINVER> 0x4000) { } else { } It's probably abuse of 'static if', but it should work as an interim solution.
Where would the user set WINVER? A module for the user to edit to supply this data might be one possibility, but it would be a nightmare for someone maintaining or even trying to compile several projects that have different OS requirements. But for as long as it's only an interim solution.... It would also be nice if the policy for using the versions is clearer than the WINVER/_WIN32_WINDOWS/_WIN32_WINNT stuff is at the moment. At the moment, I'm puzzled by the number of instances of this #if (_WIN32_WINDOWS >= 0x0410 || _WIN32_WINNT >= 0x0500) or similar. It seems to be saying that the function may be used by either an application that supports Win98 or an application that supports Win2000. So you could have a program that works on Windows 98 and Windows NT4 but not Windows 95, or a program that works on Windows 95 and Windows 2000 but not Windows NT4, and whatever is in that #if would be available to either. Unless I'm misunderstanding, it would appear that the || should be an &&.
To quote windef.h: ---------------------- #ifndef WINVER #define WINVER 0x0400 /* * If you need Win32 API features newer the Win95 and WinNT then you must * define WINVER before including windows.h or any other method of including * the windef.h header. */ #endif #ifndef _WIN32_WINNT #define _WIN32_WINNT WINVER /* * There may be the need to define _WIN32_WINNT to a value different from * the value of WINVER. I don't have any example of why you would do that. * However, if you must then define _WIN32_WINNT to the value required before * including windows.h or any other method of including the windef.h header. */ #endif ---------------- My conclusion -- Seems stupid to me, I bet this is historical. Since D doesn't need to support 1990's legacy D code, we should be able to clean it up.
Mar 29 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Hi Stewart,
Here's a translation of wingdi, one of the largest headers.
It doesn't yet _fully_ comply with your requirements (although I think 
it's not too bad), but I'm loathe to modify it further without better 
testing. It was a lot of work already to get it to that stage. I think 
we need to get some of the early headers in Windows.h done, so that the 
later ones can compile.

-Don.

Stewart Gordon wrote:
 Don Clugston wrote:
 Stewart Gordon wrote:
<snip>
 Now, who's going to contribute?
I hope that I can do a bit.
Excellent! <snip>
 Defining a set of version identifiers for the supported Windows 
 versions along the Win9x and WinNT lines is another possibility, but 
 it'll take a bit of work to determine how the #ifs should be converted.
It's possible to use 'static if', now that it works at module scope. #if (WINVER > 0x4000) #else #endif can become static if (WINVER> 0x4000) { } else { } It's probably abuse of 'static if', but it should work as an interim solution.
Where would the user set WINVER? A module for the user to edit to supply this data might be one possibility, but it would be a nightmare for someone maintaining or even trying to compile several projects that have different OS requirements. But for as long as it's only an interim solution.... It would also be nice if the policy for using the versions is clearer than the WINVER/_WIN32_WINDOWS/_WIN32_WINNT stuff is at the moment. At the moment, I'm puzzled by the number of instances of this #if (_WIN32_WINDOWS >= 0x0410 || _WIN32_WINNT >= 0x0500) or similar. It seems to be saying that the function may be used by either an application that supports Win98 or an application that supports Win2000. So you could have a program that works on Windows 98 and Windows NT4 but not Windows 95, or a program that works on Windows 95 and Windows 2000 but not Windows NT4, and whatever is in that #if would be available to either. Unless I'm misunderstanding, it would appear that the || should be an &&. Stewart.
Mar 30 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Don Clugston wrote:
 Hi Stewart,
 Here's a translation of wingdi, one of the largest headers.
 It doesn't yet _fully_ comply with your requirements (although I think 
 it's not too bad), but I'm loathe to modify it further without better 
 testing. It was a lot of work already to get it to that stage. I think 
 we need to get some of the early headers in Windows.h done, so that the 
 later ones can compile.
<snip> I've just had a look. I hadn't really thought about testing the translation, with there being so much to test and bits of the API to get to grips with in doing so. I see you've begun to implement your "interim solution" on the Windows versions.... Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 31 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Stewart Gordon wrote:
 Don Clugston wrote:
 Hi Stewart,
 Here's a translation of wingdi, one of the largest headers.
 It doesn't yet _fully_ comply with your requirements (although I think 
 it's not too bad), but I'm loathe to modify it further without better 
 testing. It was a lot of work already to get it to that stage. I think 
 we need to get some of the early headers in Windows.h done, so that 
 the later ones can compile.
<snip> I've just had a look. I hadn't really thought about testing the translation, with there being so much to test and bits of the API to get to grips with in doing so.
What would be great would be a 'force extern' dmd option for linking: ensure that every extern function actually exists in the import library. Right now you can write: extern (Windows) { void SomeOldGarbage(); } and it will compile without error. If we had such a feature, we could at least check that all functions were defined correctly. One way of doing it would be take one of those Dparser projects and just create a main() function which creates function pointers to every function mentioned in the file. But obviously it would be better if Walter could create an option to do the same thing. It would help all conversion from C->D.
 I see you've begun to implement your "interim solution" on the Windows 
 versions....
I didn't use the Perl script, I used my half-baked C2D converter to do the initial conversion. It's a moderately correct preprocessor with an regex replacement of the simple D types. #ifdef to static if is something it does semi-automatically. I still don't know what's the right way to do it. Function definitions are OK, but those structs that have additional members...
Mar 31 2006
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Don Clugston wrote:
 Stewart Gordon wrote:
<snip>
 I've just had a look.  I hadn't really thought about testing the 
 translation, with there being so much to test and bits of the API to 
 get to grips with in doing so.
What would be great would be a 'force extern' dmd option for linking: ensure that every extern function actually exists in the import library. Right now you can write: extern (Windows) { void SomeOldGarbage(); } and it will compile without error. If we had such a feature, we could at least check that all functions were defined correctly.
Good idea. <snip>
 I see you've begun to implement your "interim solution" on the Windows 
 versions....
I didn't use the Perl script, I used my half-baked C2D converter to do the initial conversion. It's a moderately correct preprocessor with an regex replacement of the simple D types. #ifdef to static if is something it does semi-automatically. I still don't know what's the right way to do it.
Nor does anybody yet.
 Function definitions are OK, but those structs that have additional 
 members...
Do you mean structs that have members that are only defined in later Windows versions? These will work in the same way - AIUI structs can contain version blocks just the same. Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 31 2006
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Comparing the #ifs in MinGW with the information on the MSDN website, 
there seem to be a lot of errors!  But I guess that we can identify 
these combinations in what supports a given entity:

- 95, NT4
- 98, NT4
- ME, NT4
- NT4
- 98, 2000
- ME, 2000
- 2000
- XP
- Server 2003

There's also a lone mysterious _WIN32_WINNT >= 0x510 for a function not 
documented on MSDN.  I'd think it was preparing for Windows Vista, 
except that
- Vista is internally numbered as 6.0
- there's no doubt going to be more than one new function in it
- Vista will have a whole new API anyway

I'm inclined that there are the following versions for the end 
programmer to concern him/herself with:

- for Windows 9x compatibility: Windows98, WindowsME, WindowsNTonly
- for Windows NT compatibility: Windows2000, WindowsXP, Windows2003
- for IE compatibility: IE3, IE4, IE401, IE5, IE501, IE6

which should be mapped to internal versions based on the above list.

The only problem is that, since there's no way at the moment to import 
version manipulation, we'd need to either maintain a copy of the mapping 
code in each module that uses these versions, or use command line files 
to set these versions.  What do people think?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-  C++  a->--- UB  P+ L E  W++  N+++ o K-  w++  O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.
Mar 31 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Stewart Gordon wrote:
 Comparing the #ifs in MinGW with the information on the MSDN website, 
 there seem to be a lot of errors!  But I guess that we can identify 
 these combinations in what supports a given entity:
 
 - 95, NT4
 - 98, NT4
 - ME, NT4
 - NT4
 - 98, 2000
 - ME, 2000
 - 2000
 - XP
 - Server 2003
 
 There's also a lone mysterious _WIN32_WINNT >= 0x510 for a function not 
 documented on MSDN.  I'd think it was preparing for Windows Vista, 
 except that
 - Vista is internally numbered as 6.0
 - there's no doubt going to be more than one new function in it
 - Vista will have a whole new API anyway
 
 I'm inclined that there are the following versions for the end 
 programmer to concern him/herself with:
 
 - for Windows 9x compatibility: Windows98, WindowsME, WindowsNTonly
 - for Windows NT compatibility: Windows2000, WindowsXP, Windows2003
 - for IE compatibility: IE3, IE4, IE401, IE5, IE501, IE6
 
 which should be mapped to internal versions based on the above list.
This sounds right to me. Are there any which are based on service packs? (eg XP SP2, which seemed to involve big changes to the OS?) Anyway, I've converted winerror.h (using Excel this time, since it was so repetitive!). I think you'll like this one, I spent some time sorting the values. How about setting up a repository for this? Maybe resurrect one of the dead dsource projects which was attempting to do exactly this. D.announce is a terrible place to be submitting files to!
 The only problem is that, since there's no way at the moment to import 
 version manipulation, we'd need to either maintain a copy of the mapping 
 code in each module that uses these versions, or use command line files 
 to set these versions.  What do people think?
 
 Stewart.
 
Mar 31 2006
next sibling parent reply jcc7 <jcc7_member pathlink.com> writes:
In article <e0k1g0$du9$1 digitaldaemon.com>, Don Clugston says...
..snip...

Anyway, I've converted winerror.h (using Excel this time, since it was 
so repetitive!). I think you'll like this one, I spent some time sorting 
the values.

How about setting up a repository for this? Maybe resurrect one of the 
dead dsource projects which was attempting to do exactly this. 
D.announce is a terrible place to be submitting files to!
I think having a dsource project for this is a very good idea. When you mention resurrection, do you mean like Core32. (For the record, I don't think that Core32 is dead, but it might be sleeping. Or just lazy.) I don't think Core32 is the best name. I think WindowsAPI or WindowsHeaders (or something with Windows or Win in the name) would be better. Also, you probably don't want to actually use any of Core32's existing files (due to the questionable copyright situation). So I'd recommend just starting a new project at dsource. Or maybe you mean Deimos? That idea never really took off, but it was supposed to be a place to submit files that might become part of Phobos. Or you could start adding to Bindings without even asking for permission. ;) jcc7
Mar 31 2006
parent reply Stewart Gordon <Stewart_member pathlink.com> writes:
In article <e0k60o$hrq$1 digitaldaemon.com>, jcc7 says...
<snip>
 I think having a dsource project for this is a very good idea.
 
 When you mention resurrection, do you mean like Core32.  (For the 
 record, I don't think that Core32 is dead, but it might be 
 sleeping.  Or just lazy.)
There are a number of problems with some of the existing translations: - how some of the content gets lost in translation - arcane, undocumented features, e.g. version (STANDALONE) in Core32 - as you say, copyright issues Making a clean start is a good way to avoid these. This is kind of what I was trying to do by starting from MinGW and by writing a wiki page to coordinate the effort. <snip>
 Or maybe you mean Deimos?  That idea never really took off, but it 
 was supposed to be a place to submit files that might become part 
 of Phobos.
I'm a bit confused about what Deimos was supposed to be. Most claimed that it's just a name for the etc section of the standard library. Others used it to mean Arcane Jill's big integer library, which was filed in etc but never made it into any official DMD distribution. (Does anyone have any idea where Jill is these days?) Stewart.
Apr 01 2006
parent reply J C Calvarese <technocrat7 gmail.com> writes:
In article <e0n1kg$14b8$1 digitaldaemon.com>, Stewart Gordon says...
In article <e0k60o$hrq$1 digitaldaemon.com>, jcc7 says...
<snip>
 I think having a dsource project for this is a very good idea.
 
 When you mention resurrection, do you mean like Core32.  (For the 
 record, I don't think that Core32 is dead, but it might be 
 sleeping.  Or just lazy.)
There are a number of problems with some of the existing translations: - how some of the content gets lost in translation
I don't know what you mean by this, but you've probably studied Core32 more than I have, and you're probably right.
- arcane, undocumented features, e.g.  version (STANDALONE) in Core32
There's a simple purpose for version(STANDALONE), but it might be controversial.
- as you say, copyright issues
Right.
Making a clean start is a good way to avoid these.  This is kind of 
what I was trying to do by starting from MinGW and by writing a wiki 
page to coordinate the effort.
Since SVN is a problem on your Mac, maybe you could start a project at dsource and just use the Trac wiki to attach files. It's not ideal, but it's better than these newsgroups (IMO). There has to be something better than attaching the files to these newsgroups. The files can be decoded from the web interface, but it sure slows a person down when they don't have a news reader available.
<snip>
 Or maybe you mean Deimos?  That idea never really took off, but it 
 was supposed to be a place to submit files that might become part 
 of Phobos.
I'm a bit confused about what Deimos was supposed to be. Most claimed that it's just a name for the etc section of the standard library. Others used it to mean Arcane Jill's big integer library, which was filed in etc but never made it into any official DMD distribution. (Does anyone have any idea where Jill is these days?)
Deimos was supposed to be "etc". The "etc" section is supposed to include stuff that could be become part of Phobos if it matures. In reality, "etc" seems to be just stuff that Walter doesn't want to junk, but doesn't want to give the Phobos seal of approval to either. I don't know what happened to Arcane Jill. She was very vocal for a few weeks (or months?) and without any warning that I noticed she stopped posting. I suspect that she just decided that D wasn't the language of her dreams after all (I think she had some cryptographic concerns that left her unsatisfied). jcc7
Apr 02 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
J C Calvarese wrote:
 In article <e0n1kg$14b8$1 digitaldaemon.com>, Stewart Gordon says...
<snip>
 - arcane, undocumented features, e.g.  version (STANDALONE) in Core32
There's a simple purpose for version(STANDALONE), but it might be controversial.
The real problem is that nobody seems to know what that simple purpose is. <snip>
 Since SVN is a problem on your Mac, maybe you could start a project at dsource
 and just use the Trac wiki to attach files. It's not ideal, but it's better
than
 these newsgroups (IMO). There has to be something better than attaching the
 files to these newsgroups. The files can be decoded from the web interface, but
 it sure slows a person down when they don't have a news reader available.
<snip> You mean I should set up some pages on the wiki on which to post files? Hmm.... Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Apr 03 2006
parent reply jcc7 <jcc7_member pathlink.com> writes:
In article <e0rfim$145j$1 digitaldaemon.com>, Stewart Gordon says...
J C Calvarese wrote:
 In article <e0n1kg$14b8$1 digitaldaemon.com>, Stewart Gordon says...
<snip>
 - arcane, undocumented features, e.g.  version (STANDALONE) in Core32
There's a simple purpose for version(STANDALONE), but it might be controversial.
The real problem is that nobody seems to know what that simple purpose is.
Firstly, I thought I answered your question about this back in 2005. Your question: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/15262 Perhaps you missed my reply: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/15265 The whole thread for context: http://www.digitalmars.com/d/archives/digitalmars/D/15248.html But I'll try to do a better job of explaining... *What does version(STANDALONE) do?* Core32 is meant to complement Phobos. If someone doesn't want to import std.c.windows.windows, they would compile with the version=STANDALONE set. The default (compiling without the STANDALONE version set) has many of the conflicts with Phobos versioned out. We've tried to add "version(STANDALONE)" to all of the statements that are also in Phobos. DMD doesn't complain about conflicts until they are actually mentioned in code that uses both. Some of the conflicts were found by tediously comparing std.c.windows to the Core32 files, and other conflicts were found by "blah conflicts with blah" error statements from DMD. I guess if I were smart I'd come up with some sort of automated tool to find all of the conflicts once and for all, but for now I just version out the conflicts when I become aware of them. *What is the future of Core32?* (No one else has asked me this question, but I've been asking it to myself.) It's pretty bleak. The guy who originally ported the Windows API headers disappeared quite a while ago. I'd been updating the files some, but I've lost interest in updating Core32, too. Everyone else just wants to complain about it. I haven't even been using it. I don't think anyone really wants to use Core32. Its freckles turned out to be carcinoma. I've thought about fixing some of the problems that have been accumulating, but I don't really see the point anymore. Your new Windows API project seems to be gaining momentum. If it continues to be productive, I don't have an interest in competing. I'd rather occasionally help out with the new team than continue to spend time with Core32.
<snip>
 Since SVN is a problem on your Mac, maybe you could start a project at dsource
 and just use the Trac wiki to attach files. It's not ideal, but it's better
than
 these newsgroups (IMO). There has to be something better than attaching the
 files to these newsgroups. The files can be decoded from the web interface, but
 it sure slows a person down when they don't have a news reader available.
<snip> You mean I should set up some pages on the wiki on which to post files? Hmm.... Stewart.
Actually, what Don is doing in the Bindings project is probably the best solution until you get your SVN problem solved (assuming there is a fix). jcc7
Apr 03 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
jcc7 wrote:
 In article <e0rfim$145j$1 digitaldaemon.com>, Stewart Gordon says...
 J C Calvarese wrote:
 In article <e0n1kg$14b8$1 digitaldaemon.com>, Stewart Gordon says...
<snip>
 - arcane, undocumented features, e.g.  version (STANDALONE) in Core32
There's a simple purpose for version(STANDALONE), but it might be controversial.
The real problem is that nobody seems to know what that simple purpose is.
Firstly, I thought I answered your question about this back in 2005. Your question: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/15262
<snip> Sorry I'd half forgotten about that thread. But it certainly ought to be in project documentation and not just one or two newsgroup posts.
 But I'll try to do a better job of explaining...
 
 *What does version(STANDALONE) do?*
 
 Core32 is meant to complement Phobos. 
 
 If someone doesn't want to import std.c.windows.windows, they would compile
with 
 the version=STANDALONE set.
 
 The default (compiling without the STANDALONE version set) has many of the
 conflicts with Phobos versioned out. 
I see. So there's a difference in purpose between the two efforts. Mine is intended to be a full translation of the Windows API headers that might one day be able to replace std.c.windows.windows. <snip>
 Your new Windows API project seems to be gaining momentum. If it continues to
be 
 productive, I don't have an interest in competing. I'd rather occasionally
help 
 out with the new team than continue to spend time with Core32.
OK. <snip>
 Actually, what Don is doing in the Bindings project is probably the best 
 solution until you get your SVN problem solved (assuming there is a fix).
I'm not sure what you mean. By "what Don is doing" do you mean committing updates to that project on my behalf? Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Apr 04 2006
parent jcc7 <jcc7_member pathlink.com> writes:
In article <e0tm7q$mbn$1 digitaldaemon.com>, Stewart Gordon says...
jcc7 wrote:
 In article <e0rfim$145j$1 digitaldaemon.com>, Stewart Gordon says...
 J C Calvarese wrote:
 In article <e0n1kg$14b8$1 digitaldaemon.com>, Stewart Gordon says...
<snip>
 - arcane, undocumented features, e.g.  version (STANDALONE) in Core32
There's a simple purpose for version(STANDALONE), but it might be controversial.
The real problem is that nobody seems to know what that simple purpose is.
Firstly, I thought I answered your question about this back in 2005. Your question: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/15262
<snip> Sorry I'd half forgotten about that thread. But it certainly ought to be in project documentation and not just one or two newsgroup posts.
You're right, and it is in the documentation now. I thought it was already there, but I was wrong.
 But I'll try to do a better job of explaining...
 
 *What does version(STANDALONE) do?*
 
 Core32 is meant to complement Phobos. 
 
 If someone doesn't want to import std.c.windows.windows, they would compile
with 
 the version=STANDALONE set.
 
 The default (compiling without the STANDALONE version set) has many of the
 conflicts with Phobos versioned out. 
I see. So there's a difference in purpose between the two efforts. Mine is intended to be a full translation of the Windows API headers that might one day be able to replace std.c.windows.windows.
And hopefully we can get Walter to accept it when it's complete. And update it if someone finds a little room for improvement later. <snip>
 Actually, what Don is doing in the Bindings project is probably the best 
 solution until you get your SVN problem solved (assuming there is a fix).
I'm not sure what you mean. By "what Don is doing" do you mean committing updates to that project on my behalf?
Yes, that's what I mean. Sorry if it sounded enigmatic. jcc7
Apr 04 2006
prev sibling parent reply Stewart Gordon <Stewart_member pathlink.com> writes:
In article <e0k1g0$du9$1 digitaldaemon.com>, Don Clugston says...
 Stewart Gordon wrote:
 I'm inclined that there are the following versions for the end 
 programmer to concern him/herself with:
 
 - for Windows 9x compatibility: Windows98, WindowsME, WindowsNTonly
 - for Windows NT compatibility: Windows2000, WindowsXP, Windows2003
 - for IE compatibility: IE3, IE4, IE401, IE5, IE501, IE6
 
 which should be mapped to internal versions based on the above 
 list.
This sounds right to me. Are there any which are based on service packs? (eg XP SP2, which seemed to involve big changes to the OS?)
There have indeed been some API features added in service packs. However, these service packs don't tend to be included in the headers. Rather, I think they just go in as being in the next major Windows version up.
 Anyway, I've converted winerror.h (using Excel this time, since it 
 was so repetitive!).  I think you'll like this one, I spent some 
 time sorting the values.
The web interface (with my being away from my usual workstation) is playing up so I can't download the attachment at the mo. But I'll have a look as soon as I can.
 How about setting up a repository for this?  Maybe resurrect one of 
 the dead dsource projects which was attempting to do exactly this.  
 D.announce is a terrible place to be submitting files to!
I thought about that a while ago. However, I can't really do it simply because I haven't been able to get SVN to work on my Mac. It appears to be a problem with my Internet connection - the error is 400 Bad Request IIRC. I've tried to find a solution but had no luck. The only SVN repository I've found that works for me is the backup of DStress. Stewart.
Apr 01 2006
next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stewart Gordon schrieb am 2006-04-01:
 In article <e0k1g0$du9$1 digitaldaemon.com>, Don Clugston says...
 How about setting up a repository for this?  Maybe resurrect one of 
 the dead dsource projects which was attempting to do exactly this.  
 D.announce is a terrible place to be submitting files to!
I thought about that a while ago. However, I can't really do it simply because I haven't been able to get SVN to work on my Mac. It appears to be a problem with my Internet connection - the error is 400 Bad Request IIRC. I've tried to find a solution but had no luck. The only SVN repository I've found that works for me is the backup of DStress.
Are you behind some HTTP proxy? What happens if you try "svn co svn://dstress.kuehne.cn" instead of "svn co http://dstress.kuehne.cn"? (for firewalls: outgoing traffic to port 3690) Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFELxSQ3w+/yD4P9tIRAsDbAKCB5aprxHC8kfvo6jIt25pOqv9SNACfSkft XgN9oFJnkwm0BVxFX+P4F7s= =AOLf -----END PGP SIGNATURE-----
Apr 01 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Thomas Kuehne wrote:
<snip>
 Are you behind some HTTP proxy?
Yes.
 What happens if you try
 "svn co svn://dstress.kuehne.cn" instead of 
 "svn co http://dstress.kuehne.cn"?
<snip> That works! But now the backup repository isn't letting me update: [masg2-mac:d/dstress/dstress] masg2% svn update subversion/svnserve/serve.c:1642: (apr_err=170001) svn: No access allowed to this repository And it still isn't helping me with getting into Dsource: [masg2-mac:~/Downloads/d/dsource] masg2% svn co http://svn.dsource.org/projects/bindings subversion/libsvn_ra_dav/util.c:670: (apr_err=175002) svn: REPORT request failed on '/projects/bindings/!svn/vcc/default' subversion/libsvn_ra_dav/util.c:294: (apr_err=175002) svn: REPORT of '/projects/bindings/!svn/vcc/default': 400 Bad Request (http://svn.dsource.org) [masg2-mac:~/Downloads/d/dsource] masg2% svn co svn://svn.dsource.org/projects/bindings subversion/libsvn_ra_svn/client.c:151: (apr_err=60) svn: Can't connect to host 'svn.dsource.org': Operation timed out FTR here's the content of my .subversion/servers file: [global] http-proxy-host = wwwcache.lboro.ac.uk http-proxy-port = 3128 Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Apr 03 2006
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stewart Gordon schrieb am 2006-04-03:
 Thomas Kuehne wrote:
<snip>
 Are you behind some HTTP proxy?
Yes.
 What happens if you try
 "svn co svn://dstress.kuehne.cn" instead of 
 "svn co http://dstress.kuehne.cn"?
<snip> That works!
Looks like your HTTP proxy doesn't support/allow: REPORT, MERGE, PROPFIND, LOCK, UNLOCK, DELETE, MKACTIVITY, CHECKOUT, COPY, MKCOL, PUT, OPTIONS, PROPPATCH, CONNECT. If the proxy is a forced one you are out of luck unless you can tunnel out (e.g. ssh) or get the proxy administrator to allow the listed methods. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFEMq6X3w+/yD4P9tIRAnylAKDFXCH4hcyUVSfQtTM8jyHrNFLDigCghv0P /fFRtRlacg9wkZ2BO27+wPc= =iYak -----END PGP SIGNATURE-----
Apr 04 2006
parent reply Brad Anderson <brad dsource.org> writes:
Thomas Kuehne wrote:
 Stewart Gordon schrieb am 2006-04-03:
 
Thomas Kuehne wrote:
<snip>

Are you behind some HTTP proxy?
Yes.
What happens if you try
"svn co svn://dstress.kuehne.cn" instead of 
"svn co http://dstress.kuehne.cn"?
<snip> That works!
Looks like your HTTP proxy doesn't support/allow: REPORT, MERGE, PROPFIND, LOCK, UNLOCK, DELETE, MKACTIVITY, CHECKOUT, COPY, MKCOL, PUT, OPTIONS, PROPPATCH, CONNECT. If the proxy is a forced one you are out of luck unless you can tunnel out (e.g. ssh) or get the proxy administrator to allow the listed methods. Thomas
Thomas, Did you have to do anything in the SVN or Apache configs to enable the svn:// protocol? Did you have to open up a new port in your firewall? BA
Apr 04 2006
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brad Anderson schrieb am 2006-04-04:
 Did you have to do anything in the SVN or Apache configs to enable the svn://
 protocol?  Did you have to open up a new port in your firewall?
http://svnbook.red-bean.com/en/1.1/ch06s03.html Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFEMs5g3w+/yD4P9tIRAsbAAJ45mnG6MdEdk880qOmdQbe6ozUtRgCePHX5 e4vl3le9T2qJA5Hs0aoyCik= =x9qb -----END PGP SIGNATURE-----
Apr 04 2006
parent Brad Anderson <brad dsource.org> writes:
Thomas Kuehne wrote:
 Brad Anderson schrieb am 2006-04-04:
 
Did you have to do anything in the SVN or Apache configs to enable the svn://
protocol?  Did you have to open up a new port in your firewall?
http://svnbook.red-bean.com/en/1.1/ch06s03.html Thomas
I thought I'd try the easy way, but you rightfully slapped me back to the documentation. BA
Apr 04 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Stewart Gordon wrote:
 In article <e0k1g0$du9$1 digitaldaemon.com>, Don Clugston says...
 Stewart Gordon wrote:
 I'm inclined that there are the following versions for the end 
 programmer to concern him/herself with:

 - for Windows 9x compatibility: Windows98, WindowsME, WindowsNTonly
 - for Windows NT compatibility: Windows2000, WindowsXP, Windows2003
 - for IE compatibility: IE3, IE4, IE401, IE5, IE501, IE6

 which should be mapped to internal versions based on the above 
 list.
This sounds right to me. Are there any which are based on service packs? (eg XP SP2, which seemed to involve big changes to the OS?)
There have indeed been some API features added in service packs. However, these service packs don't tend to be included in the headers. Rather, I think they just go in as being in the next major Windows version up.
 Anyway, I've converted winerror.h (using Excel this time, since it 
 was so repetitive!).  I think you'll like this one, I spent some 
 time sorting the values.
The web interface (with my being away from my usual workstation) is playing up so I can't download the attachment at the mo. But I'll have a look as soon as I can.
 How about setting up a repository for this?  Maybe resurrect one of 
 the dead dsource projects which was attempting to do exactly this.  
 D.announce is a terrible place to be submitting files to!
I thought about that a while ago. However, I can't really do it simply because I haven't been able to get SVN to work on my Mac. It appears to be a problem with my Internet connection - the error is 400 Bad Request IIRC. I've tried to find a solution but had no luck. The only SVN repository I've found that works for me is the backup of DStress.
I've copied them into the dsource Bindings repository for now, you should at least be able to see the web version of the files. I've done winbase now, too -- another one of the central ones, which is included very early in windows.h. Next, I'll complete the bits I left out of wingdi.
Apr 03 2006
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Don Clugston wrote:
 Stewart Gordon wrote:
<snip>
 I thought about that a while ago.  However, I can't really do it 
 simply because I haven't been able to get SVN to work on my Mac.  It 
 appears to be a problem with my Internet connection - the error is 400 
 Bad Request IIRC.  I've tried to find a solution but had no luck.  The 
 only SVN repository I've found that works for me is the backup of 
 DStress.
I've copied them into the dsource Bindings repository for now, you should at least be able to see the web version of the files. I've done winbase now, too -- another one of the central ones, which is included very early in windows.h. Next, I'll complete the bits I left out of wingdi.
I've translated winnls and winnetwk, and tweaked winerror.d a little. See the updated win32.zip. Meanwhile, I'll have a look at people's suggestions for getting things to work.... Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Apr 03 2006
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Stewart Gordon wrote:
<snip>
 The main open issue I can think of at the moment is what to do with the 
 Windows version CC stuff.
<snip> For those who haven't noticed already, I now have a proposal - mapping version identifiers to _WIN32_WINDOWS, _WIN32_WINNT and _WIN32_IE themselves. See the wiki page for how this will work. I've started implementing it and will probably upload it soon. There are numerous other versioning #ifdefs in the C headers. How many of them do we really need? I'm in the process of rounding up a list of them.... And by the way, __USE_NTOSKRNL__ is apparently the NT OS kernel, not the N to S kernel. Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Apr 05 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Stewart Gordon wrote:
<snip>
 There are numerous other versioning #ifdefs in the C headers.  How many 
 of them do we really need?  I'm in the process of rounding up a list of 
 them....
Here's the list of versions that we _might_ want to keep in: DIRECT3D_VERSION ODBCVER COBJMACROS DESC_CHAR_UNICODE INITGUID MCI_USE_OFFEXT NEC_98 ODBC_STD OLE2ANSI PROXY_CLSID PROXY_CLSID_IS PROXY_DELEGATION REGISTER_PROXY_DLL RPC_UNICODE_SUPPORTED SERVERONLY SH3 SNMPSTRICT UNDER_CE UNICODE_ONLY USE_STUBLESS_PROXY WIN32_LEAN_AND_MEAN XFree86Server _FIX_ENABLEMODELESS_CONFLICT __COMPILING_LARGEINT __USE_NTOSKRNL__ __USE_W32_SOCKETS __W32API_USE_DLLIMPORT__ The first two of these identify versions in much the same way as _WIN32_WINDOWS and _WIN32_WINNT do, and so probably want to be treated in a similar way. And I'm not sure if the largeint stuff is necessary at all. I suppose there's no point in translating largeint.h, as it's all stuff that D has built in. But do we need to keep the LARGE_INTEGER and ULARGE_INTEGER structures (defined in winnt.h) for compatibility? Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Apr 05 2006
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Stewart Gordon wrote:
 Stewart Gordon wrote:
 <snip>
 There are numerous other versioning #ifdefs in the C headers.  How 
 many of them do we really need?  I'm in the process of rounding up a 
 list of them....
Here's the list of versions that we _might_ want to keep in: DIRECT3D_VERSION ODBCVER COBJMACROS DESC_CHAR_UNICODE INITGUID MCI_USE_OFFEXT NEC_98 ODBC_STD OLE2ANSI PROXY_CLSID PROXY_CLSID_IS PROXY_DELEGATION REGISTER_PROXY_DLL RPC_UNICODE_SUPPORTED SERVERONLY SH3 SNMPSTRICT UNDER_CE UNICODE_ONLY USE_STUBLESS_PROXY WIN32_LEAN_AND_MEAN XFree86Server _FIX_ENABLEMODELESS_CONFLICT __COMPILING_LARGEINT __USE_NTOSKRNL__ __USE_W32_SOCKETS __W32API_USE_DLLIMPORT__ The first two of these identify versions in much the same way as _WIN32_WINDOWS and _WIN32_WINNT do, and so probably want to be treated in a similar way.
I'd like to see almost all of those things disappear. DIRECT3D is important, and probably ODBCVER, but most of the others should vanish. Many of them only exist to reduce compilation time. There seem to be a few that are for compatibility with the DDK headers, but the ones I've seen are mostly to avoid duplicate definitions, so shouldn't be a problem with D.
 And I'm not sure if the largeint stuff is necessary at all.  I suppose 
 there's no point in translating largeint.h, as it's all stuff that D has 
 built in.  But do we need to keep the LARGE_INTEGER and ULARGE_INTEGER 
 structures (defined in winnt.h) for compatibility?
It would be good to get rid of them, I don't think it will cause any problems (it's almost as if the WinAPI uses standard D types, and C code needs LARGE_INTEGER as a workaround for the absence of int64 in C. We don't need that stuff). One other thing I've done is remove any macros that are stated as being only for Win16 compatibility *and* that have no effect. We should probably remove the aliases for near pointers. There's not many of them, and most of them were a bad idea even in the Win 3.0 days.
Apr 05 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Don Clugston wrote:
 Stewart Gordon wrote:
<snip>
 Here's the list of versions that we _might_ want to keep in:
<snip>
 I'd like to see almost all of those things disappear. DIRECT3D is 
 important, and probably ODBCVER, but most of the others should vanish. 
 Many of them only exist to reduce compilation time.
Taken the words out of my mouth there. And now that computers are faster and that D's symbolic imports are supposed to be more efficient than old-fashioned C preprocessor includes, this benefit isn't really there to the same extent.
 There seem to be a few that are for compatibility with the DDK headers, 
 but the ones I've seen are mostly to avoid duplicate definitions, so 
 shouldn't be a problem with D.
Yes, I cut those out of the list already. And what's DDK? <snip>
 We should probably remove the aliases for near pointers. There's not 
 many of them, and most of them were a bad idea even in the Win 3.0 days.
Aliases for near pointers? I thought there were only aliases for default pointers and aliases for far pointers. But the distinction is irrelevant in Win32 and hence in D. But the C headers still use both sets of aliases. Personally I don't think we need either. Shall we do away with them? BTW it seems one of us made a slip-up with winbase.d and an older version ended up being re-committed to Dsource. Revision 40 of this file is better than revision 43. Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Apr 05 2006
parent Don Clugston <dac nospam.com.au> writes:
Stewart Gordon wrote:
 Don Clugston wrote:
 Stewart Gordon wrote:
<snip>
 Here's the list of versions that we _might_ want to keep in:
<snip>
 I'd like to see almost all of those things disappear. DIRECT3D is 
 important, and probably ODBCVER, but most of the others should vanish. 
 Many of them only exist to reduce compilation time.
Taken the words out of my mouth there. And now that computers are faster and that D's symbolic imports are supposed to be more efficient than old-fashioned C preprocessor includes, this benefit isn't really there to the same extent.
 There seem to be a few that are for compatibility with the DDK 
 headers, but the ones I've seen are mostly to avoid duplicate 
 definitions, so shouldn't be a problem with D.
Yes, I cut those out of the list already. And what's DDK?
The Device Development Kit. It's in the w32api\ddk\ directory in MinGW. Microsoft distributes DDK seperately from the SDK, and it seems that there are some #defines that are different in the two files.
 
 <snip>
 We should probably remove the aliases for near pointers. There's not 
 many of them, and most of them were a bad idea even in the Win 3.0 days.
Aliases for near pointers? I thought there were only aliases for default pointers and aliases for far pointers.
In Wingdi.h was typedef LOGPALETTE * PLOGPALETTE, * NPLOGPALETTE, * LPLOGPALETTE; and in winnt.h was typedef CHAR * NPSTR; I've just removed them. Grepping through the MinGW files I didn't find any other examples. But the distinction is
 irrelevant in Win32 and hence in D.  But the C headers still use both 
 sets of aliases.  Personally I don't think we need either.  Shall we do 
 away with them?
That one's tricky. Usage of LPSTR seems to be _really_ common. Much more common than PSTR. I think we need to get a D SDK that compiles before we consider a cleanup on that scale.
 
 BTW it seems one of us made a slip-up with winbase.d and an older 
 version ended up being re-committed to Dsource.  Revision 40 of this 
 file is better than revision 43.
'one of us' would be me <g>. Unclobbered. BTW - I think the primary goal for the short term should be to have the WIN32LEANANDMEAN subset compiling. Once we have that, this project will be a viable substitute for std.c.windows.windows. I think it would be good to split the file list in the wiki into the LEAN&MEAN files, which are high priority, and the more obscure stuff. It would be good to see how much we still need to do.
Apr 06 2006
prev sibling parent reply "John C" <johnch_atms hotmail.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
news:e10hmd$265q$1 digitaldaemon.com...
 Stewart Gordon wrote:
 <snip>
 And I'm not sure if the largeint stuff is necessary at all.  I suppose 
 there's no point in translating largeint.h, as it's all stuff that D has 
 built in.  But do we need to keep the LARGE_INTEGER and ULARGE_INTEGER 
 structures (defined in winnt.h) for compatibility?
Can't these just be changed to long and ulong?
Apr 05 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
John C wrote:
 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
 news:e10hmd$265q$1 digitaldaemon.com...
 Stewart Gordon wrote:
 <snip>
 And I'm not sure if the largeint stuff is necessary at all.  I suppose 
 there's no point in translating largeint.h, as it's all stuff that D has 
 built in.  But do we need to keep the LARGE_INTEGER and ULARGE_INTEGER 
 structures (defined in winnt.h) for compatibility?
Can't these just be changed to long and ulong?
That's what I'd begun to think. But it depends on: - whether the Windows calling/name mangling convention relies on the distinction between structs and primitive types that have the same size - whether there are enough Windows programmers out there who rely on the quick access to the high and low dwords that the LARGE_INTEGER and ULARGE_INTEGER structures provide (but considering that casts, bitmasks and bitshifts are always available....) Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Apr 05 2006
next sibling parent "Chris Miller" <chris dprogramming.com> writes:
On Wed, 05 Apr 2006 11:26:20 -0400, Stewart Gordon <smjg_1998 yahoo.com>  
wrote:

 John C wrote:
 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message  
 news:e10hmd$265q$1 digitaldaemon.com...
 Stewart Gordon wrote:
 <snip>
 And I'm not sure if the largeint stuff is necessary at all.  I suppose  
 there's no point in translating largeint.h, as it's all stuff that D  
 has built in.  But do we need to keep the LARGE_INTEGER and  
 ULARGE_INTEGER structures (defined in winnt.h) for compatibility?
Can't these just be changed to long and ulong?
That's what I'd begun to think. But it depends on: - whether the Windows calling/name mangling convention relies on the distinction between structs and primitive types that have the same size - whether there are enough Windows programmers out there who rely on the quick access to the high and low dwords that the LARGE_INTEGER and ULARGE_INTEGER structures provide (but considering that casts, bitmasks and bitshifts are always available....)
They turn into the same mangled name; such functions can be overloaded to take either: extern(Windows) { BOOL QueryPerformanceCounter(LARGE_INTEGER* lpPerformanceCount); BOOL QueryPerformanceCounter(long* lpPerformanceCount); } int main() { LARGE_INTEGER li; long l; assert(QueryPerformanceCounter(&li)); assert(QueryPerformanceCounter(&l)); return 0; }
Apr 05 2006
prev sibling parent "John C" <johnch_atms hotmail.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
news:e10nit$2gk2$1 digitaldaemon.com...
 John C wrote:
 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
 news:e10hmd$265q$1 digitaldaemon.com...
 Stewart Gordon wrote:
 <snip>
 And I'm not sure if the largeint stuff is necessary at all.  I suppose 
 there's no point in translating largeint.h, as it's all stuff that D has 
 built in.  But do we need to keep the LARGE_INTEGER and ULARGE_INTEGER 
 structures (defined in winnt.h) for compatibility?
Can't these just be changed to long and ulong?
That's what I'd begun to think. But it depends on: - whether the Windows calling/name mangling convention relies on the distinction between structs and primitive types that have the same size - whether there are enough Windows programmers out there who rely on the quick access to the high and low dwords that the LARGE_INTEGER and ULARGE_INTEGER structures provide (but considering that casts, bitmasks and bitshifts are always available....) Stewart.
I usually overload those functions to provide a choice. It's especially nice to be able to have both inout and pointer versions for functions that take pointers to structs. I meant to ask, what are you doing with all those ghastly LPARAM, LRESULT, INT/UINT and handle typedefs? Is there a clean way that you can use native D types for these instead without losing portability for example to Win64?
Apr 05 2006
prev sibling next sibling parent reply DBloke <DBloke NoSpam.org> writes:
How is this progressing?
Apr 21 2006
parent reply Don Clugston <dac nospam.com.au> writes:
DBloke wrote:
 How is this progressing?
The current status is visible from the Wiki web page, and from the dsource bindings repository. In summary: * Almost everything included by windows.h has now been converted. The only exceptions are the rpc stuff, which requires a big chunk of the COM code to be converted. * Some of the macros and bit fields in structs haven't been converted yet -- but most have. * During the conversion, many bugs in the MinGW code have been discovered and fixed. (Most of those bugs relate to Windows versioning). * It's not very well tested yet. * I believe that it's very close to being a viable alternative to the Windows header in Phobos. Almost all of the functions in Phobos are included.
Apr 21 2006
parent reply DBloke <DBloke NoSpam.org> writes:
 The current status is visible from the Wiki web page, and from the 
 dsource bindings repository. In summary:
Sorry just seen this page from one of other posts in this thread.
 
 * Almost everything included by windows.h has now been converted. The 
 only exceptions are the rpc stuff, which requires a big chunk of the COM 
 code to be converted.
Then this is a massive chunk done, but COM is a dog to work with in any language, so converting this might be challenging to say the least ;)
 * Some of the macros and bit fields in structs haven't been converted 
 yet -- but most have.
Is this due to being complicated or just a lower priority?
 * It's not very well tested yet.
Difficult to test I guess without much to test against a kind of chicken and egg situation
 * I believe that it's very close to being a viable alternative to the 
 Windows header in Phobos. Almost all of the functions in Phobos are 
 included.
Pure D Headers would be useful and a good stead for building a GUI toolkit? I take it all the blanks on the wiki are todo? Is it just a case of editing wiki where I take a file? DBloke
Apr 21 2006
parent reply Don Clugston <dac nospam.com.au> writes:
DBloke wrote:
 
 The current status is visible from the Wiki web page, and from the 
 dsource bindings repository. In summary:
Sorry just seen this page from one of other posts in this thread.
 * Almost everything included by windows.h has now been converted. The 
 only exceptions are the rpc stuff, which requires a big chunk of the 
 COM code to be converted.
Then this is a massive chunk done, but COM is a dog to work with in any language, so converting this might be challenging to say the least ;)
Actually, Phobos already has the core elements converted, so it's a matter of copying them across. I've begun playing around with it, but I'm short of time at present.
 
 * Some of the macros and bit fields in structs haven't been converted 
 yet -- but most have.
Is this due to being complicated or just a lower priority?
The priority was to get a draft of everything so that windows.d would compile.
 
 * It's not very well tested yet.
Difficult to test I guess without much to test against a kind of chicken and egg situation
A great help would be a tool that parsed a D file and extracted the names of all of the functions. With that, we could make a file that just consisted of void main() { auto f1 = &CreateWindowA; auto f2 = &MessageBoxA; auto f3 = &CreateDialogParamA; : : } If we had that, we could test that every function declaration in the headers actually existed in the implib, which would be a tremendous step. (and would be useful for *all* D conversions of C header files!) Probably one of the D parsing libraries could do this without much trouble -- any volunteers?
 
 * I believe that it's very close to being a viable alternative to the 
 Windows header in Phobos. Almost all of the functions in Phobos are 
 included.
Pure D Headers would be useful and a good stead for building a GUI toolkit? I take it all the blanks on the wiki are todo? Is it just a case of editing wiki where I take a file?
Correct. It's particularly important for Stewart, who hasn't been able to get access to the repository. Once a file is in the repository, it's fair game for anyone, because it's easy to merge changes in.
Apr 21 2006
parent reply DBloke <DBloke NoSpam.org> writes:
 A great help would be a tool that parsed a D file and extracted the 
 names of all of the functions. With that, we could make a file that just
 consisted of
 
 void main()
 {
    auto f1 = &CreateWindowA;
    auto f2 = &MessageBoxA;
    auto f3 = &CreateDialogParamA;
 :
 :
 }
 
So you just want a utility that takes a D file as input scans it and dumps out a text file with all functions in that file? E.G. File ABC.d contains void FuncA(int a); int FuncX (); real FuncZ(int a, int b); Output File ABC.txt FuncA FuncX FuncZ If you give me some more info, I will give it a go, and maybe create a file that calls these functions too as well as just text files, but I need more specifics DBloke
May 09 2006
parent reply Don Clugston <dac nospam.com.au> writes:
DBloke wrote:
 
 A great help would be a tool that parsed a D file and extracted the 
 names of all of the functions. With that, we could make a file that just
 consisted of

 void main()
 {
    auto f1 = &CreateWindowA;
    auto f2 = &MessageBoxA;
    auto f3 = &CreateDialogParamA;
 :
 :
 }
So you just want a utility that takes a D file as input scans it and dumps out a text file with all functions in that file? E.G. File ABC.d contains void FuncA(int a); int FuncX (); real FuncZ(int a, int b); Output File ABC.txt FuncA FuncX FuncZ
That's exactly right.
 
 If you give me some more info, I will give it a go, and maybe create a 
 file that calls these functions too as well as just text files, but I 
 need more specifics
Ultimately we want to create testABC.txt, which is: import ABC; void main() { auto f1 = &ABC.FuncA; auto f2 = &ABC.FuncX; auto f3 = &ABC.FuncZ; } If this links, we know the definitions are correct. -Don.
May 10 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Don Clugston wrote:
 DBloke wrote:
<snip>
 So you just want a utility that takes a D file as input scans it and 
 dumps out a text file with all functions in that file?
<snip>
 Output File ABC.txt
 FuncA
 FuncX
 FuncZ
That's exactly right.
Why not make the program generate the D code straight off?
 If you give me some more info, I will give it a go, and maybe create a 
 file that calls these functions too as well as just text files, but I 
 need more specifics
Ultimately we want to create testABC.txt, which is: import ABC; void main() { auto f1 = &ABC.FuncA; auto f2 = &ABC.FuncX; auto f3 = &ABC.FuncZ; }
I'd thought it had to have a .d extension to work. Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
May 10 2006
parent Don Clugston <dac nospam.com.au> writes:
Stewart Gordon wrote:
 Don Clugston wrote:
 DBloke wrote:
<snip>
 So you just want a utility that takes a D file as input scans it and 
 dumps out a text file with all functions in that file?
<snip>
 Output File ABC.txt
 FuncA
 FuncX
 FuncZ
That's exactly right.
Why not make the program generate the D code straight off?
Of course. Given a program that creates the text file, it's trivial to modify it to make the D code. It was just easier to explain the text file...
 If you give me some more info, I will give it a go, and maybe create 
 a file that calls these functions too as well as just text files, but 
 I need more specifics
Ultimately we want to create testABC.txt, which is: import ABC; void main() { auto f1 = &ABC.FuncA; auto f2 = &ABC.FuncX; auto f3 = &ABC.FuncZ; }
I'd thought it had to have a .d extension to work.
Yes. typo.
 
 Stewart.
 
May 10 2006
prev sibling next sibling parent reply Serg Kovrov <dyh pathlink.com> writes:
Hi Stewart,
How it meant to be built? Currently I need to compile objects in 
bind/win32 dir, and link against them from command line.
Not too convenient, but maybe I missed something.
Could you comment?

--
serg.
May 16 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Serg Kovrov wrote:
 Hi Stewart,
 How it meant to be built? Currently I need to compile objects in 
 bind/win32 dir, and link against them from command line.
 Not too convenient, but maybe I missed something.
 Could you comment?
 
 -- 
 serg.
No work has been put into packaging it yet. Here's what I've done: I have a directory c:\dlibs on my root, and I've put win32 into it. I've added the c:\dlibs directory to my path, and replaced std.c.windows.windows with the following: ------------ module std.c.windows.windows; import win32.windows; ----------- If you use functions that aren't in the import libs supplied with DMD, you'll need to obtain recent import libs from Microsoft (eg, by downloading the 2005 SDK) and run coffimplib on them.
May 16 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Don Clugston wrote:
<snip>
 If you use functions that aren't in the import libs supplied with DMD, 
 you'll need to obtain recent import libs from Microsoft (eg, by 
 downloading the 2005 SDK) and run coffimplib on them.
Which functions are they? We ought to do something about this sometime.... Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
May 17 2006
next sibling parent jcc7 <jcc7_member pathlink.com> writes:
In article <e4f6a0$2ivj$1 digitaldaemon.com>, Stewart Gordon says...
Don Clugston wrote:
<snip>
 If you use functions that aren't in the import libs supplied with DMD, 
 you'll need to obtain recent import libs from Microsoft (eg, by 
 downloading the 2005 SDK) and run coffimplib on them.
Which functions are they? We ought to do something about this sometime.... Stewart.
If there are functions missing in the official DM libs, they might be in these def files in the Bindings project at dsource: http://www.dsource.org/projects/bindings/wiki/DefFiles jcc7
May 17 2006
prev sibling parent Don Clugston <dac nospam.com.au> writes:
Stewart Gordon wrote:
 Don Clugston wrote:
 <snip>
 If you use functions that aren't in the import libs supplied with DMD, 
 you'll need to obtain recent import libs from Microsoft (eg, by 
 downloading the 2005 SDK) and run coffimplib on them.
Which functions are they? We ought to do something about this sometime.... Stewart.
comctl32.lib dates from 2001, the other libs are from 1995 or 1996. Any functions more recent than that are not included. All that's required is for Walter to download the latest SDK and run coffimplib on them all. (he just said he has a license to redistribute them).
May 17 2006
prev sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Stewart,

Thanks for all the work you've done so far on this, it's sure been helpful!

I've changed a couple of things in winuser.d though:

alias MAKELONG MAKEWPARAM;
(the commented C code uses MAKELONG, but it was aliased to MAKEWORD)

BOOL ExitWindows(UINT r,DWORD c)
{
	return ExitWindowsEx(EWX_LOGOFF,0);
}

alias GetWindow GetNextWindow;


L.
May 18 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Lionello Lunesu wrote:
 Stewart,
 
 Thanks for all the work you've done so far on this, it's sure been helpful!
 
 I've changed a couple of things in winuser.d though:
 
 alias MAKELONG MAKEWPARAM;
 (the commented C code uses MAKELONG, but it was aliased to MAKEWORD)
 
 BOOL ExitWindows(UINT r,DWORD c)
 {
     return ExitWindowsEx(EWX_LOGOFF,0);
 }
 
 alias GetWindow GetNextWindow;
 
 
 L.
Thanks, I've folded that in. Stewart -- we should think about making an alpha release soon. Then a beta where we make minor improvements to the Windows API -- eg make the organisation of header files a bit more rational, get rid of the worst instances of poor typing.
May 19 2006
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Don Clugston wrote:
<snip>
 Thanks, I've folded that in.
 Stewart -- we should think about making an alpha release soon.
 Then a beta where we make minor improvements to the Windows API --
 eg make the organisation of header files a bit more rational, get rid of 
 the worst instances of poor typing.
Hmm. I'm not sure what standard we should get it up to before we're ready for an alpha release. I suppose we should at least fix the most straightforward of FIXME comments. I've made several improvements over the last few days, but somehow seem to have left my memory stick at home today :-( Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
May 19 2006