I have a c++ program compiled in VS2010 using the v100 platform toolset which I try to get to run on a Windows server 2008 but I get the following error:
Entry Point Not Found: The procedure entry point [...] could not be located in the dynamic link library: Kernel32.dll
Googling around I have found that these types of errors seem to be related to the program trying to access some old functionality in Kernel32.dll (possibly related to winsock), link: https://support.microsoft.com/en-us/kb/300179
Now I have no idea why this would happen, the program is compiled and works perfectly on an x64 Win7 computer, using - as far as I know - standard modern Windows programming practices. It is a console (service) application.
I'm thinking this is some incorrect setting somewhere which when explained is super easy to fix but that I have no idea of. A simple Hello World program compiled with the same settings had no problems running.
The program is using the VS2010 x64 SP1 runtime (installed on the server), and also an external API that in turn uses VS2012 runtime (also installed on the server). The dll files of the external API are in the same folder as the exe.
Related
I am attempting to convert the ndn library project found at "https://github.com/named-data/ndn-cpp" into something that can be imported into several existing mfc/wpf/forms Visual Studio Projects (building it as .lib or .dll would work).
As a note, it appears to have previously been converted into c# for windows for a older build of ndn, but is no long supported and will not connect with the current ndn network.(https://github.com/named-data/ndn-dot-net)
I have looked into the using the WSL features that they have added to windows 10, and the Visual studio Linux Cross Platform projects, but these all seem to only be able to make .exes that will run in windows not a .lib or .dll that can be imported into another project.
I have also look into the shared items project but what I was able to find didn't seem like it would work for what I'm trying to do.
Lastly, I tried using cygwin. I was able to compile and generate the linux style libraries(.a) on my windows 10 machine, but when i attempted to generate windows style dlls off the .o files(gcc -shared -o mydll.dll mydll.o) I ran into a large number of reference errors that I was unable to resolve.
Does anyone have any recommendations on which of these methods I should be using or if I should be attempting some other method entirely?
Does anyone have any good references or examples of how to do this for someone with limited Linux experience?
Thanks
Ok. I've tried going about this several ways now, and here's what I've learned that might be useful to someone else trying to do this and also where I stand so far:
If you have a simple Linux dll that you have written it's possible to compile it as a Windows dll using MSYS2 or MINGW, instructions are here: http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs
If you have something a bit more complicated like the program I'm trying to convert above, there is no quick fix to convert from Linux to windows, however you still might be able to compile your program for windows using Visual Studio.
Here's how you do it:
Download vcpkg from https://github.com/microsoft/vcpkg This is a linux package manager for windows, it will allow you to download windows equivalents to many common Linux packages (for the above I had to download boost and sqlite3)
Create your own unistd.h, here's a link to that: Is there a replacement for unistd.h for Windows (Visual C)?
Get dirent.h for windows, here's a link to that: https://github.com/tronkko/dirent
replace instances of gmtime with _mkgmtime or redefine gmtime as _mkgmtime: timegm cross platform
This got me about 90% of the way there (and from about 13,000 compiler errors to about 30), The rest of the errors so far have been for calls where there is no easy linux to windows conversion and those sections of code have had to be re-written. (In the code above this would be the socket code for the tcp/udp connections in the tranport files, Linux and Windows handle it pretty differently, boost does have a good guide for how to use it's sockets in windows though: https://www.boost.org/doc/libs/1_60_0/more/getting_started/windows.html)
So that's it. Hopefully this helps someone else down the line. I'll be adding more to this answer as I discover new things.
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?
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.
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
I made a program using Visual Studio 2012 with compiler VC11, platform toolset v110 running on a net framework v4.0 on Win7. In addition to Windows libraries, I used a third-party library, OpenCV, whose path I linked directly to my project.
Include directories: "E:\opencv\build\include"
Linker directories: "E:\opencv\build\x86\vc11\staticlib*.lib"
Now I'm trying to start that executable on a different PC and program immediately crashes with typical Win7 message that the program has stopped unexpectedly. I don't know which net framework that PC uses. Versions of OpenCV are identical on my PC and the other PC. My PC and the other PC both use Windows 7 OS. I built the program in Release mode.
I don't exactly know how do programs work after compiling, but I think that the problem is that the path to the OpenCV library on the other PC is different than the path on my PC. Since OpenCV dlls are located in the library directory, program can't fetch them (since it has a different path to the OpenCV library) and thus results with error. I think that linking a relative path to the OpenCV library would solve the problem.
I'd like to know whether this would make the program work. If other PC uses different net framework than my PC, will it result in error?
I can't solve the problem using trial and error since I used my desktop PC to make the program and I need to demonstrate it on a desktop PC which has VS2013 installed with VC12 framework and compiling a modified solution results with version mismatch error.
So I have been programming in console C++ for a while, but I finally decided to try graphical applications using OpenGL. It took me a while to learn that GLUT and other libraries are obsolete, so I began installing and preparing GLEW and FreeGLUT. I managed to get to the point were my includes are working; however, now I'm running into this problem:
Visual Studio is telling me that I don't have glew32.dll when it is clearly sitting in the system32 folder. Is this not the default folder for these libraries?
In addition, every time I run my program (and hence get this error) the visual studio process continues running in the background, even after the program is closed. It refuses to be ended and it causes another problem: whenever I reenter Visual Studio I get a message saying that the default storage location is currently in use by another instance of visual studio (the one running in the background.) As a result, to continue working I have to restart my computer every time.
Does anyone have any clue what could be wrong with this and how I could get things up and running? This is my first time installing libraries, but I haven't touched random things in the system folder (at least not intentionally) and I've been careful to clean up behind myself when I've done something I shouldn't have.
Other info:
Visual Studio 2012
Latest stable releases of freeGLUT and GLEW
Windows 8.1 64bit
There are a few things worth mentioning here:
You really should not even bother with using the dynamic linking version of glew (glew32.lib). Just link against the static linking library (glew32s.lib) and forget that the DLL version ever existed.
The DLL version is more trouble than it is worth, especially since it will not work with other compilers (e.g. g++) on Microsoft Windows.
For goodness' sake, do not install glew32.dll to System32!
Never, ever, put any user DLLs there. This is the primary cause of "DLL hell." What you should do is distribute them along with your application instead (e.g. in your .exe's working directory) or if the software has a run-time redistributable installation program (glew does not) ship that with it.
I am willing to bet good money you are running a 64-bit version of Microsoft Windows.
You are compiling a 32-bit application, and it will run in Microsoft Windows' 32-bit compatibility layer known as Windows on Windows. All 32-bit DLLs will be sourced from a separate location SysWow64 when running in the compatibility layer.
This can be confusing, as you would think that System32 means 32-bit... but for historical reasons System32 actually contains the DLLs for the native version of Windows (32-bit on Win32 and 64-bit on x64).
Nevertheless, do not install glew32.dll to SysWoW64 either :)
Since you mentioned in comments that you do not understand what "linking against glew32s.lib" means, I will tell you simply that this line in your header file is causing the linker to use the DLL version of glew:
#pragma comment (lib, "glew32.lib")
This is an ugly hack for the Microsoft Visual C++ compiler that tells the linker to add this as a dependency. It is not understood by other compilers (e.g. g++), but if your software is always going to be compiled with Visual Studio you can continue to use it.
To change your software to use the static (non-DLL) version of glew, simply replace that line with this:
#pragma comment (lib, "glew32s.lib")
Now you do not need to distribute a DLL along with your program and this whole problem effectively disappears.
Here's my configuration:
Computer A - Windows 7, MS Visual Studio 2005 patched for Win7 compatibility (8.0.50727.867)
Computer B - Windows XP SP2, MS Visual Studio 2005 installed (8.0.50727.42)
My project has some external dependencies (prebuilt DLLs - either build on A or downloaded from the Internet), a couple of DLLs built from sources and one executable. I am mostly developing on A and all is fine there. At some point I try to build my project on computer B, copying the prebuilt DLLs to the output folder. Everything builds fine, but trying to start my application I get
The application failed to initialize properly (0xc0150002)....
The event log contains two of those:
Dependent Assembly Microsoft.VC80.CRT could not be found and Last Error was The referenced assembly is not installed on your system.
plus the slightly more amusing
Generate Activation Context failed for
some.dll. Reference error message: The
operation completed successfully.
At this point I'm trying my Google-Fu, but in vain - virtually all hits are about running binaries on machines without Visual Studio installed. In my case, however, the executables fail to run on the computer they are built.
Next step was to try dependency walker and it baffled me even more - my DLLs built from sources on the same box cannot find MSVCR80.DLL and MSVCP80.DLL, however the executable seems to be alright in respect to those two DLLs i.e. when I open the executable with dependency walker it shows that the MSVC?80.DLLs can be found, but when I open one of my DLLs it says they cannot. That's where I am completely out of ideas what to do so I'm asking you, dear stackoverflow :)
I admit I'm a bit blurry on the whole side-by-side thing, so general reading on the topic will also be appreciated.
Your question has the answer to your problem: Computer A has VC runtime of version 8.0.50727.867, and Computer B has only version 8.0.50727.42.
You built your libraries on Computer A, and they depend on version 867 of VC runtime. (This can be found in manifest embedded in the libraries.) When you copy them to Computer B, these libraries still require version 867 of the runtime but you have only version 42.
To resolve the VC runtime assembly dependencies, you have to install VC runtime redistributables of version 867 on Computer B. However, I'd advise you to update Visual Studio on Computer B so that you have the same version on both computers. And even better, install Visual Studio 2005 SP1 on both computers and then install this security update to SP1. After installing the latter, your libraries will depend on version 8.0.50727.4053.
it's possible the problem is related with different versions of CRT runtime installed on both machines. is it possible to build all your modules to use statically linked CRT runtime to verify this?
first I'd check that prebuilt dlls by preparing dummy project to load them
I recently had the same type of error when building projects on one machine and then moving them to another machine. The biggest culprit here is likely a debug configuration for one of the binary components. That is, MSVC has the fairly rigid requirement of all DLLs/EXEs being built with the same runtime library, debug or release, otherwise they will not work together.
When I had this happen they also tend to compile just fine, but when you attempt to run them you get that extremely cryptic error message.
You need to ensure that every module you build together uses the same configuration, thus debug or release through the entire build chain. This error also likely comes up with mismatches in other libraries, so make sure your MSVC is the exact same version on the machines where you are building.