Swift Required DLLs on Windows 10

We're distributing software built on Swift 5.4 to a few million users and have been getting reports of missing DLLs on some systems. We've been using dumpbin to determine what DLLs to include in our installer, and things seem to work for the vast majority, but we still get reports sometimes.

Running dumpbin against our executable and the DLLs found in C:\Library\Swift-development\bin yields the following result:

ADVAPI32.dll
BlocksRuntime.dll
CRYPT32.dll
Foundation.dll
IPHLPAPI.DLL
KERNEL32.dll
MSVCP140.dll
RPCRT4.dll
SHELL32.dll
SHLWAPI.dll
Secur32.dll
USER32.dll
VCRUNTIME140.dll
WINMM.dll
WS2_32.dll
api-ms-win-core-errorhandling-l1-1-0.dll
api-ms-win-core-fibers-l1-1-0.dll
api-ms-win-core-file-l1-1-0.dll
api-ms-win-core-file-l1-2-0.dll
api-ms-win-core-file-l2-1-0.dll
api-ms-win-core-file-l2-1-2.dll
api-ms-win-core-handle-l1-1-0.dll
api-ms-win-core-heap-l2-1-0.dll
api-ms-win-core-io-l1-1-0.dll
api-ms-win-core-libraryloader-l1-2-0.dll
api-ms-win-core-libraryloader-l1-2-1.dll
api-ms-win-core-localization-l1-2-0.dll
api-ms-win-core-memory-l1-1-0.dll
api-ms-win-core-namedpipe-l1-1-0.dll
api-ms-win-core-path-l1-1-0.dll
api-ms-win-core-processenvironment-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-1.dll
api-ms-win-core-processthreads-l1-1-3.dll
api-ms-win-core-profile-l1-1-0.dll
api-ms-win-core-realtime-l1-1-1.dll
api-ms-win-core-rtlsupport-l1-1-0.dll
api-ms-win-core-string-l1-1-0.dll
api-ms-win-core-synch-l1-1-0.dll
api-ms-win-core-synch-l1-2-0.dll
api-ms-win-core-synch-l1-2-1.dll
api-ms-win-core-sysinfo-l1-1-0.dll
api-ms-win-core-sysinfo-l1-2-0.dll
api-ms-win-core-timezone-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-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
bcrypt.dll
dbghelp.dll
dispatch.dll
icudt67.dll
icuin67.dll
icuuc67.dll
ole32.dll
swiftCRT.dll
swiftCore.dll
swiftDispatch.dll
swiftWinSDK.dll

We should not be depending on anything that the Swift runtime does not. Is there a definitive way to know we are distributing the DLLs necessary to support all operations the Swift runtime uses?

1 Like

Very cool!

It would be interesting to know what library is indicated as missing. The current dependency set would be VS2019 x64 Runtime (The latest supported Visual C++ downloads) which is also part of Visual Studio for embedding in an installer. Additionally, you should be distributing the ICU and Swift runtime MSIs (which currently, sadly require you to crack open the installer - its entirely a distribution setup thing that needs to be pushed on, the intent was always to have the MSI available separately as well for re-distribution). Everything else should be a system provided library.

1 Like

Thanks @compnerd! We'll try that route out in our next release.

It would be very nice to have a "blessed" MSI from swift.org for redistribution of the ICU and Swift runtime for non-developers (like the JDK vs. JRE in Java land). That would allow an end-user to install manually or have it included in a product installer.

Thanks for all you do!

That is actually exactly the model that everything is setup for. The toolchain installer is setup as just an envelope for the MSIs, it installs 5 MSIs:

  • ICU (runtime component)
  • Swift Runtime (runtime component)
  • toolchain (core toolchain; e.g. clang, swiftc, lldb)
  • x64 SDK (developer SDK - this is meant to be configurable with i686, x64, ARM, ARM64 being available)
  • developer tools (spm, etc)

This also helps with the distribution sizes. The ICU MSI is large (previously brought up at ICU usage in Swift) and weighs in at 13 MB (compared to the SDK which is 10 MB). The runtime isn't exactly tiny either at 5 MB. The runtime components basically sum up to ~20 MB. Hopefully we will get to the point where we can start focusing on the distribution sizes to help reduce some of the cost.

My personal opinion is that products should really just bundle the runtime components, and because the runtime components would have the same product id, multiple packages installing it would not be a problem. Of course, there are a few more issues left to iron out still (namely versioning for parallel installation a la SxS). Fortunately, most of the work is just something which requires engineering effort, the solutions to them are pretty clear and simple to implement.

CC: @mishal_shah (for help with figuring out how to host the additional copies of the MSIs for redistribution sorted out)

Thank you :smiley:

3 Likes
Terms of Service

Privacy Policy

Cookie Policy