Win Headers

Mike Parker aldacron at gmail.com
Thu Dec 12 04:16:57 PST 2013


On 12/12/2013 8:08 PM, Regan Heath wrote:

>> MinGW distros. Even with VC, you still have to download the Windows
>> SDK separately.
>
> I don't believe this last statement is true.  I am fairly certain that
> upon installing VC you have everything you need to call/use Win32
> functions.  The only reason to download/install a separate SDK is if
> your VC version is older and you want a newer SDK/API.

Oh, I was sure I had to install the SDK when I installed the VC Express. 
But I see now that it is included.

>
>> Should DMD ship with X-Windows bindings, too? What about Cocoa on OS X?
>
> How big are they?  If we're just talking about D "header" files then I
> am all for it, the more the merrier.  It's not like internet bandwidth
> or hard disk space is currently an issue and it will only become less of
> an issue the more time rolls on.  If people are really anxious about
> this, why not have a separate download for windows and the various
> flavours of UNIX.. wait a minute, we already do. :)

It's not the bandwidth or disk size that bothers me. It's mostly a 
matter of maintenance. I appreciate the "batteries included" approach as 
far as Phobos is concerned, but given that DMD aims to be a 
cross-platform compiler, I don't think platform-specific API bindings 
should fall into that category. I mean, all these years and the Win32 
bindings are still incomplete, while there are a couple of complete (or 
mostly complete) third-party bindings out there that do a good job of 
staying relevant.

Why is that? Because Win32 bindings are not a priority for the DMD team. 
If they aren't a priority, then why ship them? Maintenance is going to 
depend on community members anyway. Much more efficient, IMO, as a user 
to use the third-party bindings. It would be different if DMD were 
Windows-centric, or if it didn't have a platform abstraction in the form 
of Phobos.

Platform API bindings basically provide system functions and GUI 
functions. IMO, let Phobos abstract away the system and third-party libs 
abstract away the GUI. Beyond that, I can't imagine that those needing 
direct API access beyond a handful of functions will be more than a 
minority. So for them, let third-parties handle the API bindings too.

I haven't done any straight-up Win32 development in years and when I do 
need a Win32 function, it's usually one that isn't available in the 
ancient libs DMD ships so I have to prototype it and load it manually 
anyway. But if I do need more of the Win32 API, then I have no problem 
using an external lib for it. Especially if that lib supports dub.

>
>> I would be content if DMD did not ship Win32 bindings at all, except
>> for the minimal needed to implement cross-platform stuff in Phobos.
>
> This is more or less the current situation right?  Last time I tried to
> do any Win32 stuff in D there were enormous gaps.. this is one reason I
> don't have any current projects using D.

 From what I can tell, there's more in there than what Phobos actually 
uses. But because it's incomplete, it's essentially useless.

>
>> As it stands, the static libs for the Win32 API that ship with DMD are
>> old and don't include a good number of modern functions anyway. IMO,
>> complete OS API bindings *should* be separate. I wouldn't expect them
>> with the compiler.
>
> Sure, if we're talking about DLL/LIB files then I agree, we don't want
> to be shipping these with the compiler.  They should be obtained from
> official channels i.e. downloading the windows SDK.

The static libs for DMC need to be shipped for 32-bit programs. There's 
just no way around that. But they desperately need updating. I believe 
they don't include anything beyond Windows XP. With the dependence on VC 
for 64-bit, that goes away for 64-bit apps. But you still have the 
problem of maintaining compatibility between 32- and 64-bit versions if 
that's a priority.

At any rate, it's not going to kill me if all of the platform API 
bindings are included. As long as they're complete and well-maintained, 
then no big deal.


More information about the Digitalmars-d-learn mailing list