I wrote a C program and works fine on Windows 7 and Linux, but when I execute it on Windows XP I get the error:
"_except_handler4_common could not be located in the dynamic link library msvcrt.dll"
I researched it and some people said to delete the DLL "dwmapi.dll" which I don't have, so that's not my problem.
Some one told me to use depends walker(depends.exe) to find who is using msvcrt.dll. I did and find that pcre library is using it and there actually is a problem with it, but I don't have any idea how to solve this. Can any one help me?
Here's image of what depends walker show me:
Reason possibilities (afaiu):
a) You linked to msvcrt.dll specifically when building - this should
not happen according to Microsoft support unless you specifically do
it.
b) Some other installed or copied program/driver on your XP that
links to "wrong" version of msvcrl.dll is being triggered.
Depending on what the reason is,
here are few ideas to resolve:
1) There might be some program/driver/etc. installation on your XP
machine that has introduced "Vista/Win7 related crap" onto it. It is
said (by the internets) that PCRE3.DLL belongs to "GnuWin32 Non-system
processes". That means you can try to find it and rename/delete it. Or
delete the program you that uses it.
2) Installing the redist for XP of the C++ redistributable that you
used to build on Win7 might help. This is link for VS2005: (darn..
use google - i can only give two links per post :P)
Rebuilding:
3) Just build the file from sources on your XP machine using some
VisualStudio version you can get on it. And check those VS project
properties!
4) Fix your build on Windows7. You might be linking to
_except_handler4_common in msvcrt.dll in your Windows 7 build. Make sure that you do not do that. You can specifically instruct the linker
not to link to it in VisualStudio project properties
"/NODEFAULTLIB:msvcrt80.lib". You also did not specify what are you
using for building. VS2005, VS2008, VS2010, gcc?
Answer based on educated guesses and Jeffrey Tan research here:
and research here:
(On behalf of OP)
The problem was with the pcre3.dll, as i've told before, and i simply change the version of it, I was using the version 7.x and change to 4.4 that calls pcre.dll instead of pcre3.dll, that solve my problem if any one have the same issue.
here is the link to the correct lib:
pcre-4.4-dll.zip
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 have successfully installed allegro 4.2.3 in accordance with the instructions at the following link and it all works great:
http://blog.hamidnazari.com/2010/07/21/installing-allegro-on-visual-cpp-express-2010/
The only thing I've ended up deviating from in respect to the tutorial linked above, is I've selected Windows Application instead of Console Application where illustrated within the 3rd graphical example (note selecting between Win32 Console Application or Win32 Project as illustrated in the 2nd graphical example, I've found to make no noticeable difference so far).
Selecting Windows Application where illustrated in the 3rd graphical example, has for me at least, simply resulted in NOT Needing to include the line: #define USE_CONSOLE in all my Allegro programs.
Please in respect of the tutorial linked above and the title of this post, can someone please help me by answering the following question:
Start of Question:
How can I get my Allegro games to work on other computers that use Windows, without the other computers requiring that Visual C++ 2010 Express be installed, And/Or the pre-built binary version of Allegro 4.2.3 (linked to in the above tutorial) also being required to be on the other computers and linked to/configured within Visual C++ 2010 Express, also described in the above tutorial.
End of Question
Incidentally: A great link for anyone interested in making standard C++ programs (i.e. that don't use Allegro or other various libraries) work by having a fully independent .exe file (compiled/built using Visual C++ 2010 Express) which can indeed run on other computers using windows, is below:
http://www.youtube.com/watch?v=AvrjQtFBJvk
Thank you for taking the time to read this post and I hope very much that someone is able to help.
Gary.
My Reply To Matthews 1st Answer Is Below:
Hi Matthew,
I’ve been looking on Google to try and find out how the various elements you mention, fit in with and compare to the linked tutorial in my post which explains step by step how to configure visual C++ 2010 Express with the Allegro 4.2.3 binary.
The first thing I want to check with you, is if all the binaries in the 4.4.2 section and 4.2.3 section on the Allegro.cc site, are essentially both pre-built binaries, and therefore ultimately configuring version 4.4.2 to work with VC++ 2010 should be in principle similar to configuring version 4.2.3 (or perhaps not?) I have downloaded version 4.4.2 and can see that there are indeed the same 3 folders, bin, include & lib.
Here is the link again to the online tutorial which explains how to successfully configure step by step, Allegro 4.2.3 with visual C++ 2010 Express:
http://blog.hamidnazari.com/2010/07/21/installing-allegro-on-visual-cpp-express-2010/
Working through the steps in the above tutorial, I have noticed additional elements in your initial answer which I have listed below. (Please note, although the tutorial does indeed work well for version 4.2.3, simply selecting the release option instead of debug when building does not result in the .exe files working on other windows computers (although the .exe file in the release folder does still run on my primary computer), and so I guess there are other things that need to be done in addition to selecting release.
1) allegro-4.4.2-monolith-static-mt.lib --- Does this need to be added to additional dependencies in the Input Section within the Linker dropdown for both debug and release. (Also how does this compare with the tutorial for this part of the configuration i.e. are there any other additional dependencies)
2) link to all the various Win32 libraries when you static link --- I don’t know how to link to these libraries. I’m a bit stumped on this.
3) #define ALLEGRO_STATICLINK --- Does this mean that “ALLEGRO_STATICLINK” needs adding to the Preprocessor Section within the C/C++ dropdown, as I read somebody else did in an attempt to get it all working for 4.4.2
To conclude: I suppose to ask my initial question once again considering all that has been said so far, I would ask it in the following 2 parts:
Part 1) How would the online tutorial need adding to/modifying for static builds to work successfully on other computers using windows for version 4.2.3, and would this then just mean selecting the release build option and of course keeping together any files linked with the .exe when distributing.
Part 2) If using the 4.4.2 version, again how would the online tutorial need adding to/modifying for static and dynamic builds to work successfully.
Tutorial type answers to Part 1 or 2 would be awesome for me and many other newbies
Thank you very much indeed for reading this post.
Allegro 4.2 is painfully old. You should use 4.4 at minimum. It is source compatible with 4.2 (same API) and still receives updates from time to time. Allegro 5 is where all the active development is now, but it has a completely new API. I still highly recommend that you take a look at it.
Anyway, to answer the question, yes, you need to static link. Grab a binary from here:
https://www.allegro.cc/files/?v=4.4
Link with the allegro-4.4.2-monolith-static-mt.lib file, and make sure you compile using the /MT switch (as opposed to /MD). The -static aspect means the Allegro DLL is not needed. the -mt flag means the C runtime is not needed.
You'll also need to link to all the various Win32 libraries when you static link. Also, be sure to #define ALLEGRO_STATICLINK in your project settings.
It's been a little while, but if I remember correctly there's an easy way to do this, though it's probably not the best way. It's good for just sending a little demo to a friend. Even if you just build in Debug mode, you can send the game over to other people. Copy/paste the allegro-4.2.2-monolith-md.lib file (Its name is something like that, but probably not that exactly) into the project's Debug folder (next to the .exe). You'll probably also need the MSVCR1000.lib file (or something like that. Can't remember the exact name), but you'll have to find that online somewhere.
DISCLAIMER: I've never used such a completely old version of Allegro, so this solution may not exactly be applicable. But I was using Allegro after version 5 and up to 5.6, so I know it works for newer versions. You should just use a newer version, really.
I have been working on a VS 2005 project and have successfully generated an exe file which works fine on my system. However when I tried to run it on some other pc it didnt run. It throws up the error message "the system cannot run the specified program". Can someone tell me how to make my code immune to such message i.e. system independent?
platform used: Windows XP, VS 2005
the extension of all my code files is cpp but I know only c and thats what I wrote inside them.
I have seen before exe created on Windows Sp1 not working on SP2 and problems such as that.
This should help you perhaps.
I've seen this when you run on a different version of Windows that doesn't have some DLL you depend on. The easiest thing to do is statically link the C runtime (that's the usual culprit) and use depends.exe to see if there are any others.
You will almost certainly need to create an installer that installs your executable and any non-OS-included DLL's it relies upon. It is not always possible or desirable to statically link all dependencies. You can in many cases simply copy the DLL's to the same folder as the executable.
By default, even the C/C++ standard library is provided by a DLL. While the MSVCRT.DLL used by VC++ 6 is included with the OS since later editions Win95, the MSVCRT required by VS2005 is not included with XP installations (other versions I do not know). The run-time support is included VC redistributes package. You may need to arrange for your installer to include that installation, or you could be more selective is you know your dependencies.
Some Win32 API calls if you are using them are dependent on the OS version (check the documentation), but if you built and rin it on XP, it should normally work of any subsequent version of Windows. You need to define various API version macros if you want to extend support to earlier versions of Windows (which seems unlikley).
You might need to install the VS 2005 redistributables on the other machines, depending on how you have compiled your program.
I am trying to modify a current MFC application running on Windows NT4 to use boost libraries for ethernet communcications (originally, it used CommX for serial) and general increased performance, effieciency, and clarity of code.
I started out modifying it in VS2010, but I found that I was unable to produce a valid NT4 app with VS2010. I googled the issue and found that VS2005 was the last version able to create an NT4 app. I got everything to compile in VS2005, but found that I had to change certain #define statements in stdafx.h in order to get the app to run on NT4. However, even after doing that, when I execute the program on NT4, it immediately quits with no error. It doesn't show anything. I even checked the Task Manager processes while executing it. It is like it never executed at all.
I got desperate and tried compiling the app in VS2003, but I got so many errors that I gave that up.
My last attempt was VC6, but again, I got 262 errors and started wondering whether it was even possible for boost to run in VB6 or on an NT4 machine.
Is it even possible to compile and run an MFC app with boost libraries on an NT4 machine? If so, which environment/compiler do I need and how do I configure it to work correctly?
This is a very tight-schedule project, so any (prompt) help would be very appreciated! Thank you!
If you're trying to use VC6 to compile code that uses Boost, you may need an older version of Boost. Try 1.34.1.
You might try using STLport as the standard library implementation instead of the built-in STL that comes with VC6. I'm using boost 1.32 and STLport 4.6.2 successfully in VC6 with an MFC project. I haven't tried moving up to newer versions of boost or STLport, but STLport might be enough to get you going.
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.