As I had feared some of our old VB6 projects are not playing nice with Windows 7. Some of our customers have already upgraded and our one product is returning this error every time you run the executable:
The procedure entry point_except_handler4_common could not be located in the dynamic link library msvcrt.dll
First thing I tried was creating a .local in the folder so it uses all the DLL and OCX files packaged with the product. That didn't do anything, though I'm not sure if this .local trick still works in Win7.
Tried turning on compatibility for several previous versions of Windows, that had no effect either.
Hopefully someone else has some more suggestions, as my Google-Fu has failed me on this one.
When start prg. A.P.CS5 on screen get pop up window with message: The procedure entry point handler4 common could not be located in the dynamic link library msvcrt.dll.
I solved it this way:
FOR XP:
Search to folder/C:windovs/system32, found icon dwmapi.dll, once found, rename to 1dwmapi.dll (or whatever, just rename it so that you can find it later if you need it for some reason) - problem solved!
Related
I'm writing a 32-bit C++ application on Windows 8.1 x64 using Visual Studio 2013 that depends on Python 3.3 and libVLC. I have python33.dll, libvlc.dll, and libvlccore.dll in the same directory as my executable, which I also have set as the working directory under Project > Properties > Debugging. According to MSDN, unless you're using the altered search path (which should only apply if you're using LoadLibraryEx to load the DLLs at run-time; in my case these DLLs are loaded at load-time), the application directory should always be searched before the system directory. However, according to Visual Studio, all three of these DLLs are being loaded from C:\Windows\SysWOW64. This is causing me problems as the version of libVLC I have there is much older than the one I'm trying to use.
That MSDN article only lists 3 exceptions to the normal search process. These DLLs are loaded as soon as the process starts, so obviously it couldn't be the system versions were already loaded (but just to be sure, I created a .local file since it mentioned redirection would override that, and it had no effect). I've checked the registry to see that they didn't somehow get registered as "Known DLLs", so that doesn't appear to be the problem. It's possible that python33 is being loaded as a dependency of Boost.Python, but even if it's loaded only by name the app directory should still be searched first, and in any case none of my other dependencies reference VLC. As a guess I tried marking the VLC libs as delay-load (I couldn't with Python due to data imports), and I got the following warnings, which I found interesting:
1>LINK : warning LNK4199: /DELAYLOAD:libvlc.dll ignored; no imports found from libvlc.dll
1>LINK : warning LNK4199: /DELAYLOAD:libvlccore.dll ignored; no imports found from libvlccore.dll
However, dumpbin shows that my compiled exe imports several functions from libvlc.dll.
I could of course replace or delete the system versions, but that's not really a solution if I ever attempt to distribute this application. I'm not really sure what else would be causing this. Can anyone suggest anywhere else for me to look?
I've installed Lua for Windows "batteries included" 5.1.4-46.
It doesn't have everything I want.
I'm trying to re-write AutoIt scripts that I use on my personal PC.
I can't find an easy way to access the windows registry.
The WinAPI module by Steve Donovan looks like it will give me what I want.
I also want to be able to retrieve file attributes in order to determine if a directory is a junction.
I realize my real issues are not WinAPI, but if I learn how to add it to Lua for Windows, I can hopefully add other Lua addons.
How do I add WinAPI to the Lua installation from Lua for Windows?
Edit: I've found a binary winapi.dll for Lua 5.1 lua for windows.
enter link description here
I copied it to the "Lua\5.1\clibs" folder. I added require("winapi") to the top of a short program. I had to exit and restart SciTE editor and now it appears to be working.
The third party lib will ultimately (after build) be a DLL. As long as the DLL is on your LUA_CPATH, you can require dll_name and it will load dll_name.dll. There are binary (pre-built) versions of winapi for LuaForWindows, like v1.0.1. But you are probably better off getting the most recent release and building using one of the build scripts in root folder of .zip release. Once you have built, look for the .dll produced and move it to one of the locations on LUA_CPATH, or edit LUA_CPATH to include the folder where you want to put all your Lua extension modules.
can someone help me with this error!
"The PROGRAM CANT START because OPENGL.DLL is missing from your system."
I already put the h. and .dll files in the specific directories. i'm working on a 64 bit window 7. microsoft visual c++.
Most systems already have OPENGL.DLL in the Windows System directory.
The way to diagnose this error is to run Dependency Walker (download here).
Run it and open up your .EXE file - and it will tell you specifically what DLL it can't locate, or which is loaded but is not compatible.
OPENGL.DLL
You are sure about that name. Wasn't it opengl32.dll?
I already put the h. and .dll files in the specific directories
Never(!) do this with opengl32.dll. This is a system DLL and must not be overridden by shipping one own's with the program. If you do this, you may very likely end up with not getting HW acceleration.
I had a similar issue and discovered that I had deleted the following line before pasting the test code:
#include "stdafx.h"
Make sure you have the line as above before pasting the test code.
Maybe you could go to one of your friends , and copy this .dll file from his system dictionary
I have a driver which can be installed on Windows (XP/Vista/7). It's accessed via a native C++ DLL that 3rd-party applications link to, and which is also a Winsock Provider (WSP). It used to be installed under System32, but having seen advice not to, I changed it to install under ProgramFiles instead.
Now, the problem is that people are having to either copy it back into System32 or copy it into the application directory whenever they want to use it in their own applications, because Windows won't search the install directory under ProgramFiles when the application tries to load the DLL.
I've been unable to find any Microsoft documentation discussing this issue, so if System32 shouldn't be used then where should shared DLLs be installed?
The Windows side-by-side cache. Backgrounder info is here, technical reference is here.
I haven't seen anybody actually do this yet, other than Microsoft. Quite notable is that MSFT gave up on winsxs deployment for the C/C++ CRT and MFC runtime DLLs for VS2010, it was causing too many problems. They're back in c:\windows\system32. The managed equivalent of this (the GAC) is going strong though. Better tool support, probably.
I'm fairly sure that by a large margin everybody chooses app-local deployment.
Since it's a DLL linked to your driver maybe it's less of an issue, but I'd be wary of trying to share the DLL and would instead try to get all developers of client apps to keep their own version of the dll in their applications folders.
I've had too much fun in DLL Hell to want any more weird bugs because AppX overwrote the DLL with an old version that breaks AppY etc.
Anywhere on the path would work.
If this is only to be used with your set of apps (eg Qt4.dll) then in the root of "c:\program files\my company" would be good, or have a 'shared' folder below that.
If it's to be used by other apps that you don't know about (eg a video codec) then system32 makes sense (you will need admin rights when you install)
Fixed filesystem location
One possibility would be to install them in a sub-directory of Program Files, as already suggested by #Martin Beckett.
Variable filesystem location, fixed entry in Registry
If you don't want to install them at a fixed location, you could also store their location in the Windows Registry. You'd install some keys under HKEY_LOCAL_MACHINE\SOFTWARE that your applications could read to find out where the DLLs are located. Then the DLLs can be loaded at run-time.
P.S.: Preventing orphaned DLLs
You could go one step further and use the Registry, or some other storage (a file, say), to store information about which of your applications uses which of your DLLs. For example:
FooCommon.dll <- FooApp1, FooApp2, FooApp3
FooBar.dll <- FooApp1, FooApp3
FooBaz.dll <- FooApp2, FooApp3
Whenever one of your applications is un-installed, it removes itself from this map. Any uninstaller can then safely delete a DLL that is no longer in use by any application. That method is akin to reference-counting, and the idea is to prevent orphaned DLLs from accumulating on users' filesystem.
Native DLLs can be stored as side-by-side assemblies. See this reference for more information. This is separate from the .NET Global Assembly Cache, but it uses similar concepts. This blog post also has quite a few useful details about how DLLs get resolved as side-by-side assemblies.
I´ve tweaked the VC++ settings so that all of my actual code will go to one place, while compiler generated binaries will go to another. This ncb file is the exception though. It is a quite large IDE generated binary file (Intellisense database). I can´t seem to be able to move it anywhere other than the solution folder. I´ve reasearched on google and found a few references saying that this is impossible. Does anyone have a workaround?
Visual Studio doesn't allow you to move that file. This article on CodeProject shows how one person worked around this problem, by creating a "poor man's" version of symbolic links. This involves hooking Windows' CreateFile function. This approach seems like overkill to me; I think I would just learn to live with this limitation if possible.