Some questions about linking 64-bit programs on windows

[finalpatch]

The code in glfw3.lib uses user32/gdi32 (in order to create the 
window). And because you use glfw3 as a static library, you have 
to link in user32/gdi32. However if you use glfw3 as a dynamic 
library (your program links with the glfw3 import library) then 
you don't need user32/gdi32 because your program code does not 
directly use them.

On Thursday, 7 November 2013 at 22:57:22 UTC, Mikko wrote:
> I'm using DMD 2.064.2 and 64-bit Windows 8.1. I have VS2013 and 
> Windows SDK 8.1 installed. I'm running DMD from the VS2013 
> developer console.
>
> First of all there's a bug in sc.ini (line 70) when using these 
> program versions above. The platform libraries are under 
> winv6.3 subdirectory instead of win8. If you don't fix that, 
> you get shell32.lib not found errors when linking.
>
> I'm trying to link a very simple 64-bit GLFW program. In the 
> end I got everything working with following command (64-bit 
> static glfw3.lib is in the same directory):
>
> dmd -m64 app.d glfw3.lib opengl32.lib user32.lib gdi32.lib 
> -L/NODEFAULTLIB:libcmt.lib
>
> Some questions:
>
> There were no instructions anywhere to include user32 and 
> gdi32, but the linking failed without them. Is that normal?
> There was conflict with msvcrt.lib and libcmt.lib. Removing 
> libcmt worked. Why are they both included and is that normal?
> Is it OK to give the library names straight to dmd instead of 
> the linker? Am I assuming right that the "opengl32.lib 
> user32.lib gdi32.lib" part is automagically linking to dynamic 
> (DLL) 64-bit windows libraries?