www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Updates to the WindowsAPI translation instructions; D2 only?

reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Aug 01 2013
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Aug 01 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 01 2013
next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
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/
Aug 01 2013
prev sibling next sibling parent "Mike Parker" <aldacron gmail.com> writes:
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.
Aug 01 2013
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Aug 01 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 01 2013
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
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.
Aug 01 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 02 2013
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Aug 02 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 02 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Aug 02 2013
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Aug 02 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/2/2013 1:53 AM, Stewart Gordon wrote:
 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.
I'm not suggesting this workaround code go in windows.di. It should be in std.datetime.
Aug 02 2013
prev sibling parent "Mike Parker" <aldacron gmail.com> writes:
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.
Aug 03 2013
prev sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:ktfgps$2ghh$1 digitalmars.com...
 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.
It would be rather silly to stop officially supporting the second most popular desktop operating system.
Aug 02 2013
parent "Dicebot" <public dicebot.lv> writes:
On Friday, 2 August 2013 at 14:26:12 UTC, Daniel Murphy wrote:
 It would be rather silly to stop officially supporting the 
 second most
 popular desktop operating system.
Well, it is no longer supported by Microsoft itself, isn't it? There is a difference between formally supporting and spending any considerable efforts.
Aug 02 2013
prev sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
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...
Aug 02 2013
next sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Friday, 2 August 2013 at 09:28:46 UTC, Dejan Lekic wrote:
 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...
Here is a link for you to backup my claim - http://en.wikipedia.org/wiki/Usage_share_of_operating_systems . If you go to http://www.netmarketshare.com/ and pick the Operating Systems -> Desktop Share by Version option, you will see the most recent data. Windows XP holds 37.2% of the desktop share - IMHO it is not something to ignore.
Aug 02 2013
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 2 August 2013 at 09:28:46 UTC, Dejan Lekic wrote:
 Windows XP user-base is still very big. I would vote against 
 ditching the XP support.
Me too. I guess I'd be ok with it being "supported" rather than /supported/, but XP is still a *lot* of users and can't be completely ignored.
Aug 02 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/2/2013 6:41 AM, Adam D. Ruppe wrote:
 On Friday, 2 August 2013 at 09:28:46 UTC, Dejan Lekic wrote:
 Windows XP user-base is still very big. I would vote against ditching the XP
 support.
Me too. I guess I'd be ok with it being "supported" rather than /supported/, but XP is still a *lot* of users and can't be completely ignored.
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.
Aug 02 2013
parent reply "Hans Mustermann" <x fhskd.com> writes:
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?
Aug 02 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/2/2013 3:25 PM, Hans Mustermann wrote:
 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?
Programs created with DMD.
Aug 02 2013
prev sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"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.
Aug 02 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/2/2013 2:28 AM, Dejan Lekic wrote:
 All I am trying to say is - XP is not dead, yet...
Is it feeling much better?
Aug 02 2013
prev sibling next sibling parent reply "Mike Parker" <aldacron gmail.com> writes:
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.
Aug 01 2013
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Aug 02 2013
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Aug 02 2013
prev sibling next sibling parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
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...
Aug 01 2013
next sibling parent Manu <turkeyman gmail.com> writes:
On 2 August 2013 15:51, S=C3=B6nke 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 al=
so
 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 chanc=
e
 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?
Aug 01 2013
prev sibling next sibling parent "Tavi Cacina" <octavian.cacina outlook.com> writes:
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.
Aug 01 2013
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
02-Aug-2013 09:51, Sönke Ludwig пишет:
 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("")).
+1,000,000
 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...
-- Dmitry Olshansky
Aug 02 2013
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Aug 19 2013
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Aug 19 2013