3

I’m developing some Windows software that's sometimes used in embedded-like scenarios. That’s not uncommon for my users to have a dedicated Win7 or Win8 PC they never update, not even connect to the Internet. Users plug those PC to a specific industrial hardware, and use that system for one job only.

My software includes components I've written in Visual C++. I include CRT in my MSI packages using appropriate installer merge modules.

Unfortunately, for a PC that never updated, that doesn’t work: today I got a bug report, the app crashes on startup saying “can’t start because api-ms-win-crt-stdio-l1-1-0.dll is missing from your computer”

This answer suggests static link to CRT.

Did that. But some parts of my C++ code rely on OpenMP for parallelism.

Dependency walker shows me the DLL I’m building depends on vcomp140.dll even when compiled with Multi-threaded (/MT) runtime library settings.

Also it shows vcomp140.dll only depends on kernel32.dll and user32.dll.

Can I just place that single DLL, vcomp140.dll, in the installation folder? Will it work on offline Windows 7 PC?

Community
  • 1
  • 1
Soonts
  • 20,079
  • 9
  • 57
  • 130
  • Statically linking against the CRT is commonly suggested, but not necessarily the best idea (see [Potential Errors Passing CRT Objects Across DLL Boundaries](https://msdn.microsoft.com/en-us/library/ms235460.aspx) for example). A better solution is to deploy your dependencies (CRT and others) alongside your application. Don't expect to find a particular DLL of a specific version on any given client machine. – IInspectable May 04 '16 at 21:49
  • I only passing COM interfaces across DLL boundaries so that's not an issue. Can't deploy dependencies on never updated Windows 7 because modern CRT requires that KB2999226 windows update. – Soonts May 04 '16 at 22:52
  • If KB2999226 is the only problem, I've seen software before that ships with one or more Windows updates. Not sure whether you need a special license to do that or not. Alternatively, I'm not very familiar with OpenMP but I assume it's, well, open; are you able to compile it directly into your application? Combined with a static runtime, that might resolve the problem. – Harry Johnston May 05 '16 at 02:59
  • It seems awfully disingenuous for Microsoft to not include in the runtime redistribution a dll that is not always installed. – Chris Becke May 05 '16 at 06:30
  • @HarryJohnston I do not know whether that update is the only problem. All I have is an e-mail + screen photo from a Spanish user who is using offline Win7 PC, anecdotal evidence that at least for some people that update resolved the problem, and desire (+economic incentive) to make my software just work (tm). – Soonts May 05 '16 at 12:01
  • OpenMP is an API. API is open, implementation of the API is tightly coupled with C++ compiler, and Microsoft’s C++ compiler ain’t open. Porting the project to clang (a C++ compiler that’s open and also supports OMP) will be even more expensive than just dropping OpenMP and moving to windows-provided thread pool. – Soonts May 05 '16 at 12:02
  • Ah, I didn't realize the implementation was part of Visual Studio. Never mind then. A new thought: the documentation for KB2999226 says that it is only necessary for applications built in VS2015 against the Windows 10 SDK. Have you tried using an earlier version of the SDK? Or perhaps going whole-hog on compatibility and telling Visual Studio to generate a Windows XP compatible application? – Harry Johnston May 05 '16 at 22:04
  • @HarryJohnston Thanks for the input. You’re right, I could try switching C++ platform toolset from v140 to e.g. v120, the VS2013 C++ compiler would then use non-universal CRT, and the problem would go away. However, that complicates development, e.g. need both visual studios. The native code calls Direct3D 11 and other Win7+ API (e.g. DXVA 2 to enumerate physical monitor), so XP compatibility isn’t for me. – Soonts May 09 '16 at 22:26
  • I’ve already resolved my problem: static link to CRT, install vcomp140.dll to the application’s folder. Now my app works even on never updated Windows 7 — not possible if redistributing that KB ‘coz the KB only applies to Win7 SP1. – Soonts May 09 '16 at 22:27

2 Answers2

1

Based on the VS2015 Redistribution List I would say that copying that file would be indeed what you need to do and would work fine (if you used VS2015 to build your app). Take care to copy the proper dll based on arm/x86/x64.

Ton Plooij
  • 2,583
  • 12
  • 15
  • Thanks, did what you said here, now works OK on my VmWare Windows 7 sp0. – Soonts May 09 '16 at 19:09
  • But first I tried the recommended way, using MS-provided merge module. Technically works fine even without CRT installed. The problem is, the merge module installs vcomp140.dll to System32. Meaning my app may break if some other app will upgrade/downgrade/uninstall my vcomp140.dll in System32. So yes, ended up with just including the DLL. – Soonts May 09 '16 at 19:11
  • What about OpenMP? Any trick to statically link it in Visual Studio? – Royi Aug 08 '17 at 07:08
1

Just to make it clear, it is not possible to statically link openmp with Visual Studio. Only two things you can do:

  • Remove openmp (and compile with /MT /MTd)
  • deploy vcomp140.dll (or VC redistributable) with your application
lyron
  • 246
  • 2
  • 7