www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The future of the WindowsAPI bindings project

reply Stewart Gordon <smjg_1998 yahoo.com> writes:
There's been another call for the Windows API bindings to be put into druntime.
 But 
before we do, a few things need to be thought about:


1. What are we going to do with the HANDLE type?  There was a thread about it
in February 
but no decision was reached.

What we want is:

(a) HANDLE to be a distinct type from void* or any constancy variation thereof
(b) specific handle types to be implicitly convertible to HANDLE, but not
arbitrarily 
interconvertible
(c) other handle types to act as subtypes of specific handle types, such as
HGDIOBJ.

The MinGW headers, if STRICT is defined, implement (b), but not (a), and use a
workaround 
to try to get as near to (c) as possible.

I've refined my earlier solution, and this is what I have now.

----------
version (D_Version2) {
     struct HANDLE__(T) {
         T t__;
         mixin("alias t__ this;");
         typeof(this) opAssign(typeof(this) t) { t__ = t.t__; return this; }
     }
     mixin("alias HANDLE__!(const(void)*) HANDLE;");
} else {
     template HANDLE__(T) {
         mixin("typedef T HANDLE__;");
     }
     mixin("typedef void* HANDLE;");
}

template DECLARE_HANDLE(string name, string base = "HANDLE") {
     mixin("alias HANDLE__!(" ~ base ~ ") " ~ name ~ ";");
}

// example declarations using it
mixin DECLARE_HANDLE!("HWND");
mixin DECLARE_HANDLE!("HGDIOBJ");
mixin DECLARE_HANDLE!("HPEN", "HGDIOBJ");
----------


2. An annoyance is the need for .lib files generated from the bindings in order
to support 
those functions that are #define directives in the C headers.  Ellery Newcomer
has 
suggested getting around this by making them nullary templates

-WORD MAKELANGID(USHORT p, USHORT s) { return cast(WORD)((s << 10) | p); }
+WORD MAKELANGID()(USHORT p, USHORT s) { return cast(WORD)((s << 10) | p); }

since this way the function will be compiled on demand (presumably inlined when
it's a 
simple function like this).


3. Windows 9x support has been officially discontinued in the D2 line.  Indeed,
it's been 
reported that programs compiled with recent DMD2 versions won't run under
Win9x.  Keeping 
in the versioning for Win9x enables those D1 programmers that remain to write
stuff that 
runs under Win9x.  But it does complicate the code quite a bit, and D1 will be 
discontinued at the end of the year anyway.

On this basis, what should we do?  Indeed, what exactly is D2's official
minimum supported 
version of Windows?  Me, NT4 or 2000?

Advantages of keeping the Win9x versioning in the bindings:
- Enables those D1 programmers that remain to write stuff that runs under Win9x.
- Saves the effort of going through removing it

Advantages of getting rid of it:
- Makes the bindings less complicated, as we no longer need to worry about the
separate 
_WIN32_WINDOWS and _WIN32_WINNT constants
- Less work for people translating the headers
- Would reduce the temptation to try writing a Win9x app in D2

Of course, when the bindings are put into druntime, it would make most sense to
put in a 
version with this Win9x and D1/D2 versioning removed.  But for as long as we
still have 
both D versions to support....


Anyway, I'm inclined to implement the solutions proposed for points 1 and 2. 
And of 
course update the translation instructions accordingly.

Any objections?

Stewart.
May 13 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 13-05-2012 17:07, Stewart Gordon wrote:

 There's been another call for the Windows API bindings to be put into
 druntime. But before we do, a few things need to be thought about:


 1. What are we going to do with the HANDLE type? There was a thread
 about it in February but no decision was reached.

 What we want is:

 (a) HANDLE to be a distinct type from void* or any constancy variation
 thereof
 (b) specific handle types to be implicitly convertible to HANDLE, but
 not arbitrarily interconvertible
 (c) other handle types to act as subtypes of specific handle types, such
 as HGDIOBJ.

 The MinGW headers, if STRICT is defined, implement (b), but not (a), and
 use a workaround to try to get as near to (c) as possible.

 I've refined my earlier solution, and this is what I have now.

 ----------
 version (D_Version2) {
 struct HANDLE__(T) {
 T t__;
 mixin("alias t__ this;");
 typeof(this) opAssign(typeof(this) t) { t__ = t.t__; return this; }
 }
 mixin("alias HANDLE__!(const(void)*) HANDLE;");
 } else {
 template HANDLE__(T) {
 mixin("typedef T HANDLE__;");
 }
 mixin("typedef void* HANDLE;");
 }

 template DECLARE_HANDLE(string name, string base = "HANDLE") {
 mixin("alias HANDLE__!(" ~ base ~ ") " ~ name ~ ";");
 }

 // example declarations using it
 mixin DECLARE_HANDLE!("HWND");
 mixin DECLARE_HANDLE!("HGDIOBJ");
 mixin DECLARE_HANDLE!("HPEN", "HGDIOBJ");
 ----------


 2. An annoyance is the need for .lib files generated from the bindings
 in order to support those functions that are #define directives in the C
 headers. Ellery Newcomer has suggested getting around this by making
 them nullary templates

 -WORD MAKELANGID(USHORT p, USHORT s) { return cast(WORD)((s << 10) | p); }
 +WORD MAKELANGID()(USHORT p, USHORT s) { return cast(WORD)((s << 10) |
 p); }

 since this way the function will be compiled on demand (presumably
 inlined when it's a simple function like this).


 3. Windows 9x support has been officially discontinued in the D2 line.
 Indeed, it's been reported that programs compiled with recent DMD2
 versions won't run under Win9x. Keeping in the versioning for Win9x
 enables those D1 programmers that remain to write stuff that runs under
 Win9x. But it does complicate the code quite a bit, and D1 will be
 discontinued at the end of the year anyway.

 On this basis, what should we do? Indeed, what exactly is D2's official
 minimum supported version of Windows? Me, NT4 or 2000?


2000, AFAIK. There is currently a pull request to repair Windows 2000 
support in druntime.


 Advantages of keeping the Win9x versioning in the bindings:
 - Enables those D1 programmers that remain to write stuff that runs
 under Win9x.
 - Saves the effort of going through removing it


I think we should just get rid of it. For D2, we'll have to remove the 
9x stuff at some point anyway. And keeping the 9x stuff around for D1 is 
not worth it, since D1 is being discontinued kind-of soon. Besides, does 
anyone actually write Windows 9x programs in D anymore?


 Advantages of getting rid of it:
 - Makes the bindings less complicated, as we no longer need to worry
 about the separate _WIN32_WINDOWS and _WIN32_WINNT constants
 - Less work for people translating the headers
 - Would reduce the temptation to try writing a Win9x app in D2

 Of course, when the bindings are put into druntime, it would make most
 sense to put in a version with this Win9x and D1/D2 versioning removed.
 But for as long as we still have both D versions to support....


If someone really wants to, they can put the Windows 9x stuff into the 
D1 branch of druntime. But let's not put it into master.


 Anyway, I'm inclined to implement the solutions proposed for points 1
 and 2. And of course update the translation instructions accordingly.

 Any objections?

 Stewart.


-- 
- Alex
May 13 2012
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 13/05/2012 16:13, Alex Rønne Petersen wrote:
<snip excessive quote>

 On this basis, what should we do? Indeed, what exactly is D2's official
 minimum supported version of Windows? Me, NT4 or 2000?


 2000, AFAIK. There is currently a pull request to repair Windows 2000 support
in druntime.


That would be my inkling.  But has it actually been stated somewhere, or are
you just 
assuming?


 Advantages of keeping the Win9x versioning in the bindings:
 - Enables those D1 programmers that remain to write stuff that runs
 under Win9x.
 - Saves the effort of going through removing it


 I think we should just get rid of it. For D2, we'll have to remove the 9x
stuff at some
 point anyway. And keeping the 9x stuff around for D1 is not worth it, since D1
is being
 discontinued kind-of soon. Besides, does anyone actually write Windows 9x
programs in D
 anymore?


Probably nobody of significance writes programs to target Win9x now.  But some
people are 
hesitant to move on from supporting a given OS version.  If Mozilla and
OpenOffice are 
still claiming to support Win2000, there are probably people out there still
claiming to 
support Win9x.

But any people who are programming D for Win9x will already have the bindings. 
And if 
they do an SVN update and find that the protection against accidentally using
Win2000+ 
APIs on which they relied has gone, they can update back to the old version. 
So maybe 
you're right.  Still, let's see what the others say.

<snip>

 If someone really wants to, they can put the Windows 9x stuff into the D1
branch of
 druntime. But let's not put it into master.


There's no "D1 branch of druntime".  Under D1, there's just Phobos.

Stewart.
May 13 2012
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 13-05-2012 17:35, Stewart Gordon wrote:

 On 13/05/2012 16:13, Alex Rønne Petersen wrote:
 <snip excessive quote>

 On this basis, what should we do? Indeed, what exactly is D2's official
 minimum supported version of Windows? Me, NT4 or 2000?


 2000, AFAIK. There is currently a pull request to repair Windows 2000
 support in druntime.


 That would be my inkling. But has it actually been stated somewhere, or
 are you just assuming?


Just assuming. Since Windows 9x support was dropped, but not 2000 
support (it was broken accidentally), I assume we still support it.


 Advantages of keeping the Win9x versioning in the bindings:
 - Enables those D1 programmers that remain to write stuff that runs
 under Win9x.
 - Saves the effort of going through removing it


 I think we should just get rid of it. For D2, we'll have to remove the
 9x stuff at some
 point anyway. And keeping the 9x stuff around for D1 is not worth it,
 since D1 is being
 discontinued kind-of soon. Besides, does anyone actually write Windows
 9x programs in D
 anymore?


 Probably nobody of significance writes programs to target Win9x now. But
 some people are hesitant to move on from supporting a given OS version.
 If Mozilla and OpenOffice are still claiming to support Win2000, there
 are probably people out there still claiming to support Win9x.

 But any people who are programming D for Win9x will already have the
 bindings. And if they do an SVN update and find that the protection
 against accidentally using Win2000+ APIs on which they relied has gone,
 they can update back to the old version. So maybe you're right. Still,
 let's see what the others say.

 <snip>

 If someone really wants to, they can put the Windows 9x stuff into the
 D1 branch of
 druntime. But let's not put it into master.


 There's no "D1 branch of druntime". Under D1, there's just Phobos.


Oops, true. That's what I meant. :)


 Stewart.


-- 
- Alex
May 13 2012