Dependency on DLLs not Documented

[jgmanning]

After the app failed to run on an old Windows server, I found that the cause was a missing DLL. The exact DLL depends on the version of Tidy being used.
The DLL(s) are not distributed with the app so it would be good to have this dependency documented somewhere.
FYI - #515 gives more information about this dependency

[geoffmcl]

@jgmanning certainly agree the Windows /MD builds by various versions of MSVC have a dependency on MSVC runtime DLL's being installed in the system...

I just re-read Understanding Dependency, and tried the suggested dependencywalker, with not much success... then read some related links, but it is hard to find simple answers... But yes, MS offers redistribution packages, but you must choose and install the correct one... all quite a mess...

I have just added tidy-5.6.0-vc14-mt-32b.zip and tidy-5.6.0-vc14-mt-64b.zip to the 5.6.0 release, but not yet added them to the binaries...

These are using the static runtimes, /MT, and may run in an old Windows server. It would be much appreciated if you could give them a try, and report... thanks...

And in general will try to look for a place where this dependancy could be more clearly documented than in #515... ideas welcome, like where would you expect to find this information? Maybe a README/DEPENDENCY.md document, or something... thanks...

[jgmanning]

Hi @geoffmcl - I tested tidy-5.6.0-vc14-mt-32b (tidy.exe) on the server and it worked.
Testing tidy-5.6.0-vc14-32b.zip in the same environment gives the error "The application was unable to start correctly (0xc000003b)" so your update definitely resolved this error.

As for where to put this dependency information... the first place I checked was the release notes, so maybe at the top of that document would work? Otherwise, any document that mentions "installation", "readme", "installation" or the like should grab people's attention.

Thanks!

[majkinetor]

Can we have a completely statically compiled binary with 0 deps ?

[geoffmcl]

@jgmanning glad the mt static version worked...

Still deciding where to put this dependency information, but the first thing I suppose is to collect the info. I have a pedump2.exe which gives me a good list of imports, as follows, for each version -

1. msvc140-64\tidy-5.6.0-vc14-64b\bin\tidy.exe
   api-ms-win-crt-convert-l1-1-0.dll api-ms-win-crt-environment-l1-1-0.dll api-ms-win-crt-heap-l1-1-0.dll
   api-ms-win-crt-locale-l1-1-0.dll api-ms-win-crt-math-l1-1-0.dll api-ms-win-crt-runtime-l1-1-0.dll
   api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-time-l1-1-0.dll
   api-ms-win-crt-utility-l1-1-0.dll KERNEL32.dll VCRUNTIME140.dll
   PE/OBJ: Machine Type: 8664 (AMD64-K8)

2. msvc140-32\tidy-5.6.0-vc14-32b\bin\tidy.exe
   api-ms-win-crt-convert-l1-1-0.dll api-ms-win-crt-environment-l1-1-0.dll api-ms-win-crt-heap-l1-1-0.dll
   api-ms-win-crt-locale-l1-1-0.dll api-ms-win-crt-math-l1-1-0.dll api-ms-win-crt-runtime-l1-1-0.dll
   api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-time-l1-1-0.dll
   api-ms-win-crt-utility-l1-1-0.dll KERNEL32.dll VCRUNTIME140.dll
   PE/OBJ: Machine Type: 014c (Intel 386)

3. msvc100-64\tidy-5.6.0-vc10-64b\bin\tidy.exe
   KERNEL32.dll MSVCR100.dll
   PE/OBJ: Machine Type: 8664 (AMD64-K8)

4. msvc100-32\tidy-5.6.0-vc10-32b\bin\tidy.exe
   KERNEL32.dll MSVCR100.dll
   PE/OBJ: Machine Type: 014c (Intel 386)

5. msvc140-64\tidy-5.6.0-vc14-mt-64b\bin\tidy.exe
   KERNEL32.dll
   PE/OBJ: Machine Type: 8664 (AMD64-K8)

6. msvc140-32\tidy-5.6.0-vc14-mt-32b\bin\tidy.exe
   KERNEL32.dll
   PE/OBJ: Machine Type: 014c (Intel 386)

7. MinGW-64/tidy-5.6.0-MinGW-64b/bin/tidy.exe
   KERNEL32.dll msvcrt.dll
   PE/OBJ: Machine Type: 8664 (AMD64-K8)

The last, MinGW-64, is not yet part of our distribution, and I built it just to see the difference... it is interesting in that it has one more dll dependency than the /MT msvc static builds, namely the msvcrt.dll.

And now that I look at this listing it does not seem very helpful to a user. First they would not necessarily be aware of all these DLL's, especially the long list of the msvc140 /MD default build. Why MS makes this so difficult is unknown...

Maybe there should be a strong note somewhere that if the user gets an error like you point out - "The application was unable to start correctly (0xc000003b)", or some other similar error noting missing DLL's, the user may need to install the appropriate runtime DLL's, and give a pointer to various MS sites for such a download and install....

The problem is that tidy.exe is a console app, and it is not common to include it in say a Windows installer package.

We did try that initially, but is has other problems for the user. The main one being that the default install is usually to places like C:\Program Files\Tidy, which then requires say C:\Program Files\Tidy\bin to be added to the PATH environment variable to use tidy.exe globaly...

By default we do link the tidy.exe to the static tidy library, to make it easy to use tidy.exe from anywhere, simply by copying the exe into an existing path already in the PATH variable. Or indeed run it from exactly where it was built, or unzipped...

There are cmake options to link it with the DLL, if someone really wants that additional complexity...

And then there are the users of library tidy, linked to their own app. Installing tidy-dev, headers and tidy.dll/lib into C:\Program Files\Tidy is again not easy to use...

In general, tidy is such a small package, and it does not seem worth the effort to try to provide such a full Windows package install, which could then include the required runtime redistributables from MS...

In fact we encourage that users build from source, and thus will have installed all the runtime stuff as part of the building of Tidy... although we do also provide some binary downloads, but they have the runtime dependencies mentioned here...

And @majkinetor I do not think it is possible to create a tidy.exe with 0 deps! Would like to learn how, other than the present /MT build, which does have very minimal DLL dependency... thanks...

In fact I just tested built the simplest source possible, main() { return 0; }, switching to /MT static runtimes, with both MSVC 14 and 10, and that test_null.exe still had a dependency on KERNEL32.dll, and you would be surprized at the number of entries, some 67, in the import table... As stated, any ideas welcome...

I think this has been discussed a few times in the past, like #515, but are always willing to listen to further feedback, ideas, suggestions, etc... thanks..