I previously released a beta for AdFind that wasn’t statically linked. I did that with the thought that one of the big benefits of using Visual Studio is that a lot of people would already have the necessarily DLLs. While a lot do, a lot also do not so I will be releasing a beta version of AdFind that is statically linked so there will be no need for other DLLs to be present on the machine.
And in the same vein, I took me a couple of weeks but I finally sorted out an issue with Visual Studio with writing code for Windows 7 / Windows Server 2008 R2. There is this new concept of Universal CRT and “API Sets” which are awesome for newer OSes but do not support the older OSes at all. It took me entirely too long to find this article
https://msdn.microsoft.com/en-us/library/windows/desktop/dn505783(v=vs.85).aspx
and in particular
Note Compatibility with Windows 7, Windows Server 2008 R2 and older operating systems: Binaries that link to MinCore.lib or MinCore_Downlevel.lib are not designed to work on Windows 7, Windows Server 2008 R2 or earlier. Binaries that need to run on earlier versions of Windows or Windows Server must not use either MinCore.lib or MinCore_Downlevel.lib.
The really awesome thing is that the MSDN Documentation for the API calls apparently assumes that no one wants to write code that runs on the older OSes so when they tell you what library (*.lib) to link in they tell you mincore.lib for a lot of stuff and not what the actual library needs to be if you need people to use an older OS with your application. IMO this is a massive documentation fail on the part of Microsoft. For example when you need to use the function GetFileVersionInfoSize you see on the website https://msdn.microsoft.com/en-us/library/windows/desktop/ms647005(v=vs.85).aspx that you need mincore.lib, no mention of what to use if you need compatibility. Searching around doesn’t help you a whole lot until you start digging up some older posts where you find that it should be version.lib that is actually included.
The only way I am immediately aware to quickly determine this information will require generous use of DUMPBIN /EXPORTS against the *.LIB files on your machine looking for the function you need. I visualize a perl script in my future.
Here is an example of what DUMPBIN /EXPORTS will show you for version.lib.
[Tue 04/18/2017 8:25:20.40]
E:\DEV\cpp>"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\dumpbin" /exports "c:\Program Files (x86)\Microsoft SDKs\windows\v7.1a\lib\version.lib"
Microsoft (R) COFF/PE Dumper Version 14.00.24218.2
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file c:\Program Files (x86)\Microsoft SDKs\windows\v7.1a\lib\version.lib
File Type: LIBRARY
Exports
ordinal name
_GetFileVersionInfoA@16
_GetFileVersionInfoExW@20
_GetFileVersionInfoSizeA@8
_GetFileVersionInfoSizeExW@12
_GetFileVersionInfoSizeW@8
_GetFileVersionInfoW@16
_VerFindFileA@32
_VerFindFileW@32
_VerInstallFileA@32
_VerInstallFileW@32
_VerQueryValueA@16
_VerQueryValueW@16
Summary
C3 .debug$S
14 .idata$2
14 .idata$3
4 .idata$4
4 .idata$5
C .idata$6
Anyway, I am testing the new beta build of AdFind compiled with Visual Studio 2017 with static linking and LIBS that are actually supposed work on the older (and still supported MICROSOFT THANKYOUVERYMUCH) operating systems. I hope to post the new beta binary in the next day or so depending on issues encountered.
joe
p.s. This had me pretty close to dumping Visual Studio again. I still might because it is crap that it is so poorly documented and I could see this causing all sorts of issues for developers.