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