It's a quite frequent issue to get unresolved externals on Windows, because the lib files of the Windows platform SDK are still stuck at Windows XP age. It would make a lot of sense to update those to the latest Windows 10 SDK, but I couldn't find a place where those are present physically, except for the release archives.

Does anyone know where those are stored or has the means to update them? Martin?

On Tuesday, 14 February 2017 at 14:11:31 UTC, Sönke Ludwig wrote:
> It's a quite frequent issue to get unresolved externals on Windows, because the lib files of the Windows platform SDK are still stuck at Windows XP age. It would make a lot of sense to update those to the latest Windows 10 SDK, but I couldn't find a place where those are present physically, except for the release archives.
>
> Does anyone know where those are stored or has the means to update them? Martin?

My 2 cents: (serious) Windows devs should install their own Visual C++ (linker + C runtime) & WinSDK and use DMD with `-m32mscoff` or `-m64` (to use MS linker instead of OptLink). The Win10 SDK doesn't support XP afaik and so may not be suited for all users; there's no 'one fits them all'.
I don't see a big future for OptLink and the bundled libs; it's only convenient for beginners so that they don't need the MS stuff and can get started with the DMD redistributable alone. The other DMD redistributables don't ship with a linker and system libs either (and you don't need a full-fledged Visual Studio installation anymore). And once everybody finally switches to 64-bit, OptLink is dead anyway.

On Tuesday, February 14, 2017 17:15:59 kinke via Digitalmars-d wrote:
> On Tuesday, 14 February 2017 at 14:11:31 UTC, Sönke Ludwig wrote:
> > It's a quite frequent issue to get unresolved externals on Windows, because the lib files of the Windows platform SDK are still stuck at Windows XP age. It would make a lot of sense to update those to the latest Windows 10 SDK, but I couldn't find a place where those are present physically, except for the release archives.
> >
> > Does anyone know where those are stored or has the means to update them? Martin?
>
> My 2 cents: (serious) Windows devs should install their own
> Visual C++ (linker + C runtime) & WinSDK and use DMD with
> `-m32mscoff` or `-m64` (to use MS linker instead of OptLink). The
> Win10 SDK doesn't support XP afaik and so may not be suited for
> all users; there's no 'one fits them all'.

I would point out that we technically don't support Windows XP. If you use D with it, and it works for you, great, but you're on your own.

That being said, I don't know enough about the Windows SDK to have any clue what we should do with it. If it actually requires Windows 10 to use the Win10 SDK, then I don't see how we could include it by default, since we do support Windows 7 (and most folks I know who use Windows refuse to upgrade beyond 7 until they have to, though there are obviously plenty of folks out there on 8 or 10).

- Jonathan M Davis

On Tuesday, 14 February 2017 at 20:14:32 UTC, Jonathan M Davis wrote:

>
> I would point out that we technically don't support Windows XP. If you use D with it, and it works for you, great, but you're on your own.

Which is why the OMF libs need to be updated. They're ancient!

>
> That being said, I don't know enough about the Windows SDK to have any clue what we should do with it. If it actually requires Windows 10 to use the Win10 SDK, then I don't see how we could include it by default, since we do support Windows 7 (and most folks I know who use Windows refuse to upgrade beyond 7 until they have to, though there are obviously plenty of folks out there on 8 or 10).

It should be fine to just update the libraries to the Win 7 SDK versions. Anyone who actually needs any newer API functions can either use the MS linker or do what we already have to do with the OMF libs and either manually load them via the LoadLibrary API or generate their own.

Though, I do recall a discussion on this quite a while ago. I can't remember how it ended.

Am 15.02.2017 um 07:43 schrieb Mike Parker:
> On Tuesday, 14 February 2017 at 20:14:32 UTC, Jonathan M Davis wrote:
>
>>
>> I would point out that we technically don't support Windows XP. If you
>> use D with it, and it works for you, great, but you're on your own.
>
> Which is why the OMF libs need to be updated. They're ancient!
>
>>
>> That being said, I don't know enough about the Windows SDK to have any
>> clue what we should do with it. If it actually requires Windows 10 to
>> use the Win10 SDK, then I don't see how we could include it by
>> default, since we do support Windows 7 (and most folks I know who use
>> Windows refuse to upgrade beyond 7 until they have to, though there
>> are obviously plenty of folks out there on 8 or 10).
>
> It should be fine to just update the libraries to the Win 7 SDK
> versions. Anyone who actually needs any newer API functions can either
> use the MS linker or do what we already have to do with the OMF libs and
> either manually load them via the LoadLibrary API or generate their own.
>
> Though, I do recall a discussion on this quite a while ago. I can't
> remember how it ended.

Although the Windows 10 import libraries should work fine for a Windows 7 application, too. At least the 8.1 SDK guarantees backwards compatibility down to Windows 7. The 10 SDK has some breaking changes in the runtime, but that AFAIK doesn't affect the WinAPI import libraries.

On Tuesday, 14 February 2017 at 14:11:31 UTC, Sönke Ludwig wrote:
> It's a quite frequent issue to get unresolved externals on Windows, because the lib files of the Windows platform SDK are still stuck at Windows XP age. It would make a lot of sense to update those to the latest Windows 10 SDK, but I couldn't find a place where those are present physically, except for the release archives.
>
> Does anyone know where those are stored or has the means to update them? Martin?

You should ping Martin directly via email - I am not sure whether he regularly checks the general NG.