fix 6625 - update OMF import libraries

[MartinNowak]

• an update_libs.bat script to regenerate omf import libs from a
  Windows SDK is contained in the .zip archive and will be shipped
  as dmd2/windows/lib/update_libs.bat as well

update_libs.bat

if -%1-==-- echo Missing Windows SDK folder argument & exit /b

:: CTL3D32 is missing in Windows SDK
:: Uuid is a static library in Windows SDK
for %%l in (COMCTL32.LIB CTL3D32.LIB ODBC32.LIB OLEAUT32.LIB WS2_32.LIB advapi32.lib comdlg32.lib gdi32.lib glu32.lib kernel32.lib ole32.lib opengl32.lib rpcrt4.lib shell32.lib user32.lib uuid.lib version.lib wininet.lib winmm.lib winspool.lib wsock32.lib) do coffimplib %1\%%l %%l

As the script comment says, CTL3D32.DLL is no longer present and Uuid.lib is now a static library, so those 2 remain in their current state.

Also see COFFIMPLIB - Digital Mars

[dlang-bot]

Thanks for your pull request, @MartinNowak!

Bugzilla references

Auto-close	Bugzilla	Description
✓	6625	Distribute newer Windows API import libraries

[CyberShadow]

This is great, thanks!

[MartinNowak]

@MartinNowak The batch didn't make it into the 2.077-rc1 installer.

As always, build scripts are messy ;), #267.

If it's ok to update the existing libraries from the Win10 SDK, would it be a lot different to add other converted import libraries, too?

You mean adding more import libraries? No problem from my side, should stay relevant though.
Import libs are fairly small, so it's hardly a size issue. Only from the Windows SDK, or do you have other things in mind?

On the other hand I have created a program to convert the MinGW def files to import libraries and added a stub for linking against the ancient MSVCRT.DLL which should be available on every system. That would allow to convert all import libraries to OMF libs, too.

By means of creating COFF import libs and then converting those?
Sounds good and would allow to automate this in the release script.

Should we integrate that with druntime or should it be part of the installer creation? I think the latter makes more sense as it only changes with new MinGW releases.

Could you submit it to the tools repo?
I'd say it's best to integrate with the release scripts,
https://github.com/dlang/installer/blob/765b42f1243e3b61b27ce7fc81678a4228d5748c/create_dmd_release/build_all.d to downloads MinGW def files and
https://github.com/dlang/installer/blob/765b42f1243e3b61b27ce7fc81678a4228d5748c/create_dmd_release/create_dmd_release.d to convert them to import libraries.

[rainers]

You mean adding more import libraries?

Yes. I wonder about distribution licensing issues, though. If it's ok to just copy them, there is no reason to go through MinGW.

Could you submit it to the tools repo?
I'd say it's best to integrate with the release scripts,

Ok, I'll have a look.

[MartinNowak]

Yes. I wonder about distribution licensing issues, though. If it's ok to just copy them, there is no reason to go through MinGW.

Unfortunately the sdk_license.rtf and REDIST.rtf seem to disallow this.

For any Distributable Code having a filename extension of .lib, distribute only the results of running such Distributable Code through a linker with your program;

Subject to the license terms for the software, the .lib files under the following directories may be distributed unmodified when built as part of your program:
Program Files\Windows Kits\10\Lib<version>\um\x86
Program Files\Windows Kits\10\Lib<version>\um\x64

Now constants and names aren't copyrightable, but any contained code from stubs et.al. could be problematic from my understanding.

Also MinGW would be easier for automation, installing/updating the Windows SDK as part of the build would be a pain.

We could also update those things outside of the release process, much like libcurl and now omflibs, but that required someone to regularly do it, e.g. the last libcurl update from @brocolis is almost 10 month old.