libcurl is what I am going to try to use for posting messages to a JMS queue from a C program running on Windows XP compiled using Visual Studio 6.
With this I need to link in libcurl.lib - but where do i get this from?
I link numerous lib's to my program (wsock32.lib, kernel32.lib, etc) so once I can get hold of it I can't see a problem.
I have downloaded all of the Win32-Generic binaries etc (http://curl.haxx.se/download.html) but none of them contain the lib/headers I need.
Anyone out there know where I get get them from.
thanks for any help.
Problems running on a 64bit machine now - please see my 'answer' post
I have used the link you supplied (direct link). I now link in the libcurl_imp.lib to my dll and it compiles fine. My app can call my new library routines that call the curl methods fine and works a treat - BUT ONLY ON A 64BIT MACHINE? - if I try to run the same dll/binary app on a 32bit XP machine it just dumps out immediately. In fact all my applications abort - and they make no reference to my new library routines, they just use the dll. It seems that just because I build in the cURL calls into my dll it immediately aborts the spawned process– I just get –
1 + Done(134) testapp
5656 Abort testapp
I have a printf statement immediately after main but I get no output on the command line.
I then removed all my new library functions from the dll apart from one, and in this all I do is –
CURLcode res = curl_global_init(CURL_GLOBAL_DEFAULT);
This one line causes all my apps to fail on 32bit when built into my dll – comment it out and they all work.
As stated, the same dll/binary works fine on my 64bit machine. The 64bit machine has the same curllib.dll as the one on my 32bit machine.
For info, my build machine is 32bit, we have productions machines that are both 32 and 64 bit.
Is the link you sent me actually 64bit only?
Related
I've built this really simple mulithreaded winsock tcp based multi-user chat in C++.
I'm personally running a 32 bit windows 7 version, the chat works fine and now I want to test it among different computers in my LAN, simply for the example, I would like to run my client.exe file within another computer, a windows 7 that runs 64 bit.
so I have a few questions before doing so:
firstly assuming both computes run x86 architecture It shouldn't be a problem to transport those .exe files and run them on different computers right?
now my second question is missing dll's, when tried executing my client.exe file on the other computer, a missing "MSVCR120.dll" dll error message has popped. which actually makes sense as the computers may be architecture compatible but may have different dll's. so my question is, if within my C++ Client.exe file source code, I will load the MSVCR120.dll and include it to the folder of my Client.exe file, would that solve my problem?
You have two options:
To create installation package for your exe that includes VC++
redistribuables.
To compile your exe with VC++ runtime compiled in as a static library.
In second case you don't need installation package, just copy the exe on target machine and run it from there.
if you built you program with visual studio, you will need to install Microsoft redistribuables:https://support.microsoft.com/en-us/kb/2977003
Regards
i'm trying to create an installer for my opencv project. The Projects runs just fine, no error while compiling or at runtime.
And i need the program to run on other machines as well, so i thought of making an installer. I've read that MS VS 2013 has discontinued the Deployment tool and so i am using InstallShied Limited.
I'm setting everything according to their tutorial and i am adding the opencv libs, it builds and i can install my application. But as soon as install it on other machine i get the following errer message:
The procedure entry point _except1 could not be located in the dynamic link library opencv_imgproc.dll
I also get this error if i just copy the dll files to another machine along with the exe file. Does this mean, that the dlls are not compatible with the system? i am using windows 8.1 on both machines. and its also weird that it runs when i build it from VS.
Any advice is greatly appreciated.
regards,
hh
Solution: i had the 64bit dlls included and runnning on 32bit. The 32 Bit dlls are in vc10
Im trying to deploy a C++ AMP application to another Windows 7 machine.
I have tried to include the vcamp110.dll in the same folder, and also compiled with /MT do get rid of dependency on msvcp110.dll and msvcr110.dll.
Also tried both x64 and win32 release of the application.
On the computers i have tried it on whitout VS11 installed, the program stops responding.
I tried to do a simple test with the hello world application and i have the same problems there.
The files can be downloaded from here http://www.2shared.com/file/IofZlrJs/amptest.html (source, binary and the dll).
Any suggestions to how this can be fixed?
Deployments like the one you tried are definitely supported – full details here:
http://blogs.msdn.com/b/nativeconcurrency/archive/2012/03/12/deploying-apps-built-with-c-amp.aspx
There are a few things you can do to diagnose the issue you are facing yourself:
The bitness of vcamp110.dll has to match the bitness of your app, so 32bit for one means 32bit for the other.
Ensure that there are no other instances of vcamp110.dll in some central location (e.g. system32)
Attach a debugger and see what DLLs are loaded and what exception gets thrown.
Most important of all, for all your apps, surround your parallel_for_each call with try…catch to see what runtime_exception you are getting. More on C++ AMP exceptions can be found here: http://blogs.msdn.com/b/nativeconcurrency/archive/2012/02/01/c-amp-runtime-exceptions.aspx
For the specific repro you shared, we tried that under the debugger on a clean Windows 7 machine and indeed a rutime_exception is being thrown: “The binary for the parallel_for_each is incompatible with this version of runtime.”, which indicates a mismatched runtime version (either mixing bitness or mixing Developer Preview with Beta or something like that).
I've written a quick C++ console app using VS2010. I'd like to run it via the remote debugger on the Windows Server 2008 platform, in order to determine why I can't enumerate the CLSID_AudioInputDeviceCategory on that OS.
The console app works on the XP and W7 platforms.
The remote debugger gives the following error when I first tried to run the console app:
The program can't start because MSVCP100D.dll is missing from your computer. Try reinstalling the program to fix the problem.
I did try just copying this DLL from my development machine to the target folder on the remote machine, but it returned an even more obscure message:
The application was unable to start correctly (0xc0000007b). Click OK to close the application.
I've tried installing the VS2010 C++ re-distributable on the target host. This has no effect. I'm out of ideas, does anyone have any suggestions?
Having spent some time on this problem, I've noticed that the Windows Audio service on server 2008 was disabled, but my query is more to do with getting remote debugging working on the server 2008 platform than solving my audio hardware enumeration problem.
Thanks to Errata, I had a look at
Project Properties -> Configuration Properties -> C++ -> Code Generation
I changed Runtime Library from Multi-threaded Debug DLL to Multi-threaded Debug (/MTd).
This allows remote debugging without having to rely on the correct debug DLLs residing on the remote machine.
I hope this helps someone out there!
I had this exact situation. I grabbed copies of MSVCP100D.dll and MSVCR100D.dll. However I grabbed them from system32 (the 32-bit version), which resulted in the 0xc0000007b error.
0xc0000007b apparently means invalid DLL, often architecture mismatch between program and DLL (i.e. x86 and x64). In my case I grabbed the wrong (32-bit) version of the DLL from my developement computer resulting in 0xc0000007b. After grabbing the file from SysWOW64, it worked.
I've written a C++ console application in Visual Studio 2019 and am trying to deploy it to another windows laptop. Both laptops are up-to-date with 64 bit Windows 10, and my target laptop has installed/up-to-date .NET Framework, vc_redist.x64.exe, and DirectX.
In terms of deployment method, I followed this Microsoft walkthrough word for word, with the added step of ensuring that my newly created "setup" project was also targeting x64 platform, since some of the external libraries in my code required x64. The resulting "setup" .exe/.msi pair work as planned on the source laptop - installs and runs with no frills required.
Installation goes fine on the target laptop, but launching the program gives the error mentioned in the title of this post. After a few hours of trying to figure it out, I think I have an idea where the problem is coming from, but first, I'll share what I've tried, which is basically every recommendation found by googling this error code:
clean boot
SFC scan
chkdsk c: /f /r
repairing/fresh installing all of the frameworks mentioned in the first paragraph
running both the application installer and the installed application as administrator
restarting laptop and reinstalling application after all of those changes
What I think is the root of the problem:
In the setup/deployment project in VS, three of the "detected dependencies" (MSVCP140D.dll, ucrtbased.dll, VCRUNTIME140D.dll) have filepaths through …\System32\ rather than the identical dependencies that could be found in …\SysWOW64. The other two detected dependencies are external 64-bit DLLs (which is why I specified my entire project to x64). When I run my application through Dependency Walker, it agrees that the three formerly mentioned dependencies are "wrong CPU type", while the two latter ones are fine. This scenario does not, however, explain to me why install/run (outside of VS) works fine on the source laptop (shouldn't it not work if VS is packaging a mix of 32 and 64 bit dependencies?). In fact, running the application through Dependency Walker on the source laptop reveals the exact same thing as on the target laptop - the same 3 dependencies are "wrong CPU type", yet the application runs here.
I do not see an option in VS to change the "setup" project to read the 64 bit filepath. I have tried manually swapping in the 64-bit DLLs at various stages (including restarting the computer between DLL swap and application run), which did not seem to have any effect. In fact, I tried replacing the 3 relevant DLLs in the System32 folder with the DLLs from the SysWOW64 folder (my idea of a cheap workaround for not being able to change the filepath - just change the file) and this just caused me to get the same error on my source laptop as I had been getting on my target laptop.
All of this stuff is relatively new to me, so please let me know if I'm foolishly overlooking some fundamental detail with my process/project - at this point it would be nice if that were the case and this is easy to fix.
Wrote this before I noticed the above comment had already answered.
Just leaving it in.
Debug Binary: Looks like you have deployed a debug version of your binary (The D in the file name: MSVCP140D.dll). Try to compile in Release mode and deploy the new binary.
Cause: Debug binaries generally need the debug-versions of the VCRedist binaries to exist on the box you try to run the binary - they are only available on developer PCs with the SDK (and / or Visual Studio) installed. That error message: 0xc000007b means "STATUS_INVALID_IMAGE_FORMAT".
Tips: There are some resource links here and some tips on how to debug deployment problems.