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