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.

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

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.

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