"Hans Mustermann" <x@fhskd.com> wrote in message news:ntjgrchqcyedtkjeddaf@forum.dlang.org...
> On Friday, 2 August 2013 at 19:05:30 UTC, Walter Bright wrote:
>
>> I'm not suggesting breaking support for XP. Just unofficial support, meaning we won't break it, and we'll accept pull requests to fix issues with it.
>
> Just to be sure that I understand correctly what this thread is about: Are you talking about the platforms that DMD itself runs on, or the programs that are created with DMD, or both?

Hopefully soon these will be the same thing.

On Friday, 2 August 2013 at 08:47:31 UTC, Jonathan M Davis wrote:
>> 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.
>

This actually is a rather common thing. Declare function pointers for the newer API functions. At run time, use LoadLibrary and GetProc to load them from the system DLLs. If GetProc can't find the symbols, you know that this version of Windows doesn't support them, so you fall back to the older stuff.

On 02/08/2013 06:51, Sönke Ludwig wrote:
<snip>
> 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.

Maybe, but there are probably a number of programs out there that still use ANSI for backward compatibility reasons.

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

I'm not sure what else some library might reasonably define version(Unicode) to mean that might cause a conflict....

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 01/08/2013 21:59, Stewart Gordon wrote:
<snip>
> - Just use the D const pointer syntax where we need it, rather than this CPtr template
> that was made for D1 compatibility.

Now implemented.

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

Now in the translation instructions, but most modules still need to be updated to this policy.

I have made Windows XP the default version.  Version Windows2000 is still available for anybody who wants to target Win2K using a third-party compiler (does GDC still generate W2K-compatible code?) but no older versions are supported.

And for anyone who wants to build old D1 Windows apps, I have placed a snapshot of the bindings from before this work began here:

http://pr.stewartsplace.org.uk/d/legacy/win32.zip

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.