On 2 August 2013 15:51, Sönke Ludwig <sludwig@outerproduct.org> wrote:

> 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.
>

+1, totally agree. There's no compelling reason to support the ascii functions, and it's not in the spirit of D.

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...
>

Can we do a sensis of some sort?

On Friday, 2 August 2013 at 05:51:50 UTC, Sönke Ludwig wrote:
> I would seriously take into consideration to just drop the "A" versions.

+1
or at least, the W version should be aliased by default.

On 8/1/2013 11:10 PM, Brad Roberts wrote:
> 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.

That's good to know.

On Thursday, August 01, 2013 22:41:14 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.
> 
> 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.

Well, if you want to do that, I'm not against it. I'd actually like to make some changes to std.datetime which require Vista or later, so being able to not bother with XP would be nice (though I've managed to work around the problems caused by not having the newer Win32 functions from Vista). It's just nice and straightforward to say that we support what Microsoft supports, and on some level, what Microsoft supports reflects what's actually in use.

Regardless, we should probably make it clear somewhere on the site what we officially support.

- Jonathan M Davis

On 8/2/2013 12:50 AM, Jonathan M Davis wrote:
> Well, if you want to do that, I'm not against it. I'd actually like to make
> some changes to std.datetime which require Vista or later, so being able to
> not bother with XP would be nice (though I've managed to work around the
> problems caused by not having the newer Win32 functions from Vista).

Is it possible to test at runtime if those newer functions are available, use them if so, and a workaround if not?


> It's just
> nice and straightforward to say that we support what Microsoft supports, and
> on some level, what Microsoft supports reflects what's actually in use.
>
> Regardless, we should probably make it clear somewhere on the site what we
> officially support.

Yes.

On Friday, August 02, 2013 01:27:11 Walter Bright wrote:
> On 8/2/2013 12:50 AM, Jonathan M Davis wrote:
> > Well, if you want to do that, I'm not against it. I'd actually like to
> > make
> > some changes to std.datetime which require Vista or later, so being able
> > to
> > not bother with XP would be nice (though I've managed to work around the
> > problems caused by not having the newer Win32 functions from Vista).
> 
> Is it possible to test at runtime if those newer functions are available, use them if so, and a workaround if not?

I'm not sure. Possibly. Given that we previously had code that checked the version of Windows and used the A functions if it was running on Windows 9x, there's probably a decent chance that something similar could be done with the Vista vs pre-Vista time functions. I'm not sure that it would be worth the extra complication though. What's there works. It's just not quite as clean as it would be otherwise.

- Jonathan M Davis

On 02/08/2013 09:47, Jonathan M Davis wrote:
<snip>
> I'm not sure. Possibly. Given that we previously had code that checked the
> version of Windows and used the A functions if it was running on Windows 9x,
> there's probably a decent chance that something similar could be done with the
> Vista vs pre-Vista time functions. I'm not sure that it would be worth the
> extra complication though. What's there works. It's just not quite as clean as
> it would be otherwise.

If we add stuff like this, it's getting beyond the point of being a set of Windows API bindings.  Stuff like this should be done, if at all, by a higher-level library.

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 02/08/2013 02:55, Mike Parker wrote:
<snip>
>> - 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.

Well, I need to use a string mixin to implement it anyway, unless you've found another way.

> 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.

The compiler has to process the content of the bindings source files when using the bindings, not just when compiling them.  Indeed, part of what I'm trying to do is have no library to build, just as is the case with the C headers.

But all this actually reinforces the points you've made.  So maybe I'll give this idea a miss after all.  But maybe when I've a bit more time I'll experiment with it.

But that does suggest that good old C macros are considerably quicker to compile than mixins.  I haven't tried to compare them.  I suppose that, now that computers are several orders of magnitude faster than they were 30 years ago, D has focused on other objectives than being as fast as possible to compile.

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 Friday, August 02, 2013 10:06:34 Stewart Gordon wrote:
> But that does suggest that good old C macros are considerably quicker to compile than mixins.

Strings get allocated and operated on when you're doing string mixins rather than simply doing textual replacement like occurs with macros.

> I haven't tried to compare them.  I suppose that, now
> that computers are several orders of magnitude faster than they were 30
> years ago, D has focused on other objectives than being as fast as possible
> to compile.

Not really. What it comes down to is that CTFE is horribly slow due to the fact that it was originally implemented essentially by hacking it into the compiler rather than integrating it a clean manner. For instance, at present, _every_ time that it mutates a variable (including stuff like ++i), it allocates a new value on the heap. When you're doing stuff that, performance is going to absolutely tank. What's there is really quite scary. Don's been working hard on cleaning it all up so that he can actually start fixing the efficiency problems, and he's getting close, but until CTFE's performance problems are fixed, stuff like string mixins are going to be slow. However, once CTFE's core implementation problems have been fixed, the situation should improve considerably.

- Jonathan M Davis

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.

Windows XP user-base is still very big. I would vote against ditching the XP support. The main reason ReactOS (http://www.reactos.org) is becoming so popular is precisely because XP users consider it as alternative once the XP support from Microsoft is gone. ReactOS is slowly reaching the stable state, it even "works" on my HP Z200 workstation at work! :)

I have a Windows XP netbook that I still use on a daily basis! :) All I am trying to say is - XP is not dead, yet...