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