I've made some changes following recentish discussion.  The changes are:

- Do away with Windows 9x versioning, given that Windows 9x is no longer supported either by Microsoft or by DMD (implemented).

- a DECLARE_HANDLE template to declare handle types (I think it's fully implemented, please let me know if I've missed any).

- function macros from the C headers are defined as templates, in order to force inlining (partly implemented).

I've realised that some of the changes I've made (such as using @property) mean that the code now doesn't work under D1.  What do people think?  Can we safely decide that these bindings are going to support D2 only from this point forward?  I still have an old D1-compatible version of the bindings, which I'll put on the web in due course for anyone who wants them.

Along these lines, I'm thinking of making a few more changes:

- Just use the D const pointer syntax where we need it, rather than this CPtr template that was made for D1 compatibility.

- Declare all constants as enums, in order to force inlining.

- Define a mixin template along the lines of __AW in newer versions of MinGW, so that

    version (Unicode) {
        alias QwertW Qwert;
    } else {
        alias QwertA Qwert;
    }

can become simply

    mixin DECLARE_AW!("Qwert");

Moreover, if we're going to do this, should we place these declarations:
- in a block at/near the end of the file, as we tend to do currently?
- immediately below the declaration of which it declares an alias?
- immediately below for structs, and for function signatures below the whole list of them?


What do people think?

I'll be away for a week and a bit starting tomorrow, but will pick up this discussion on my return.

Stewart.

-- 
My email address is valid but not my primary mailbox and not checked regularly.  Please keep replies on the 'group where everybody may benefit.

Moreover, while getting rid of Windows 9x has simplified the versioning, I was just thinking about how far back along the NT line we should go.

At the moment, we go back to NT4.  But it's now harder to verify whether it supports a given API since the MSDN docs now seem to start at Win2k (even functions that were in Windows 3.x are now down with "Windows 2000 Professional" as the minimum version).  So maybe we should just make Win2k the baseline version.

Moreover, my inkling is that Win2k is the oldest version any major software company claims to support now.  Programs made with current DMD have XP as their minimum Windows version, but that doesn't necessarily mean we shouldn't support 2k, since third-party compilers could also use our bindings.

The baseline version doesn't necessarily need to be the same as the default version.  For instance, we could make 2k the baseline version, i.e. the minimum supported version and hence what one gets when none of the "static if (_WIN32_WINNT >= ...)" blocks are compiled in, but have XP has the default version, i.e. the one assumed if no version flags have been specified.

What do people think we should do?  Opinions please!

Stewart.

-- 
My email address is valid but not my primary mailbox and not checked regularly.  Please keep replies on the 'group where everybody may benefit.

On 8/1/2013 3:28 PM, Stewart Gordon wrote:
> What do people think we should do?  Opinions please!

Even supporting XP is problematic because of the badly broken thread local storage support for DLLs in it, which D heavily relies on. I wouldn't say this for a C++ compiler, but for D, I kinda feel that Windows 7 should be the minimum.

We can certainly ditch all the Windows 9x support.

On Thu, 01 Aug 2013 16:00:09 -0700, Walter Bright <newshound2@digitalmars.com> wrote:

> On 8/1/2013 3:28 PM, Stewart Gordon wrote:
>> What do people think we should do?  Opinions please!
>
> Even supporting XP is problematic because of the badly broken thread local storage support for DLLs in it, which D heavily relies on. I wouldn't say this for a C++ compiler, but for D, I kinda feel that Windows 7 should be the minimum.
>
> We can certainly ditch all the Windows 9x support.
>

+1
...
+1,000,000

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Thursday, 1 August 2013 at 23:00:09 UTC, Walter Bright wrote:
> On 8/1/2013 3:28 PM, Stewart Gordon wrote:
>> What do people think we should do?  Opinions please!
>
> Even supporting XP is problematic because of the badly broken thread local storage support for DLLs in it, which D heavily relies on. I wouldn't say this for a C++ compiler, but for D, I kinda feel that Windows 7 should be the minimum.
>
> We can certainly ditch all the Windows 9x support.

+1

If Windows 7 is going to be the baseline, it would be nice to have some updated Win32 libs ship with DMD. They seem to be rather old and are missing functions that have been added to the API in recent years.

On Thursday, 1 August 2013 at 20:59:31 UTC, Stewart Gordon wrote:

> Along these lines, I'm thinking of making a few more changes:
>
> - Just use the D const pointer syntax where we need it, rather than this CPtr template that was made for D1 compatibility.
>
> - Declare all constants as enums, in order to force inlining.

+1 on both. When I dropped D1 support from Derelict, this is exactly what I did.
>
> - Define a mixin template along the lines of __AW in newer versions of MinGW, so that
>
>     version (Unicode) {
>         alias QwertW Qwert;
>     } else {
>         alias QwertA Qwert;
>     }
>
> can become simply
>
>     mixin DECLARE_AW!("Qwert");
>

I would be cautious about doing this. I know that multiple string mixins can have a noticeable impact on compile time. I don't know if that holds to the same scale for template mixins, but given the size of the Win32 bindings I would want to be sure before implementing it. I would want to make compile time a top priority. If everyone were always compiling the bindings as a library, it wouldn't be such a concern. But when using build tools which compile imports along with the app source, it can become an issue.

On Thursday, August 01, 2013 16:00:09 Walter Bright wrote:
> On 8/1/2013 3:28 PM, Stewart Gordon wrote:
> > What do people think we should do?  Opinions please!
> 
> Even supporting XP is problematic because of the badly broken thread local storage support for DLLs in it, which D heavily relies on. I wouldn't say this for a C++ compiler, but for D, I kinda feel that Windows 7 should be the minimum.

I would _love_ to require Windows 7 at minimum, but I'd always figured that we should support all of the versions of Windows that Microsoft currently supports, which would mean supporting XP until April 2014 and Vista until April 2017.

http://windows.microsoft.com/en-us/windows/products/lifecycle

Certainly, right now, for all of druntime and Phobos to work, you need at least XP. We've already dropped all of the Win9x support and most (all?) of the Win2k support.

Regardless, the biggest gain by far will be being able to ditch support for XP and require at least Vista. As bad as Vista was, it had some major improvements to the Win32 API (like adding a proper condition variable).

- Jonathan M Davis

On 8/1/2013 10:17 PM, Jonathan M Davis wrote:
> Regardless, the biggest gain by far will be being able to ditch support for XP
> and require at least Vista. As bad as Vista was, it had some major
> improvements to the Win32 API (like adding a proper condition variable).

As a practical matter, we do not test on XP, and so it is disingenuous to claim official support for it.

I suggest saying we "officially" support Win7 or later, and unofficially support versions back to XP. Unofficially means there's code there to support it, and we accept pull requests to fix bugs in it, we will try not to break it, but we don't test or guarantee that it'll work.

It's like how we "support" Solaris and a VC-built dmd.

Am 01.08.2013 22:59, schrieb Stewart Gordon:
> - Define a mixin template along the lines of __AW in newer versions of
> MinGW, so that
>
>      version (Unicode) {
>          alias QwertW Qwert;
>      } else {
>          alias QwertA Qwert;
>      }
>
> can become simply
>
>      mixin DECLARE_AW!("Qwert");
>

I would seriously take into consideration to just drop the "A" versions. D is unicode by nature, the "W" versions are supported by all NT systems (since Windows 95 using MSLU), and using an ANSI version of a function also just begs for bugs if typed as "char*" instead of "ubyte*". Many newer functions also just have a single wide string variant.

IMO this is just legacy cruft that was maybe still useful in times when supporting Windows 95 was important and MSLU had to be installed as an explicit add-on, but for nothing else really (although frequently used in C programs because it saves typing an additional character: "" vs. L"" or even _T("")).

Also switching API based on a version statement always introduces a chance to break interoperability of two libraries that require the version to be set differently.

The issue here of course is breaking existing code that doesn't use the "Unicode" path. Not sure how serious this is, though...

On 8/1/13 10:41 PM, Walter Bright wrote:
> On 8/1/2013 10:17 PM, Jonathan M Davis wrote:
>> Regardless, the biggest gain by far will be being able to ditch support for XP
>> and require at least Vista. As bad as Vista was, it had some major
>> improvements to the Win32 API (like adding a proper condition variable).
>
> As a practical matter, we do not test on XP, and so it is disingenuous to claim official support for
> it.

If it's important enough, I could add an ec2 windows server 2003 auto-tester.  I'd prefer not to have to since it's not free, but it's easy.