I have an application developed in VC++ 2010 , it runs in xp , it also runs in Windows 7 when i check the run in XP mode. When i check the run in xp mode , it sets a string value in HK_LOCAL_USER \Software\microsoft\windowsNT\currentversion\appcompatflags\layers folder , and runs well.
When i set the same value in the folder through an application built in VC++ 2010 , it doesn't work why..?
are there any other dependencies , that i should look into..?
That's because the hive is (and has been, ever since the dawn of Windows Registry) named HKEY_LOCAL_MACHINE.
There also is HKEY_CURRENT_USER, you seem to be mixing things up here. I highly doubt your HK_LOCAL_USER has ever really worked.
Also, setting the compatibility flag for an application that is still under active development seems like the wrong way to go. Have you looked into why the application needs that flag? Do you know what code would need to change in order for it to run on Windows 7 without the compatibility fixes? In most cases the changes are quite small.
Related
I am using "Microsoft Visual Studio" to work with an "MFC application".
I am using "Installshield" to create the setup file for this application.
I get a "setup.exe" file.
If I run this setup on a "Windows XP 32 bit" machine, the installation ends properly.
Yet, when I try to start the installed program, I get the message:
"The procedure entry point _except_handler4_common could not be located in the dynamic link library msvcrt.dll."
In debug mode, I can't find the moment the error occurs because whatever the breakpoint I put in the code, the message appears before reaching the breakpoint, I guess at the very beginning of the program execution...
Note: It works for Vista 32 bit and Seven 64 bit.
It appears lots of people do have the same problem but I couldn't find a solution for myself.
Can you help?
Thank you.
Welcome to the world of DLL hell and application dependency analysis.
I found that DLL on my Win8 machine in the SYSWOW64 (32bit System32 folder ) with version 7.0.9200.16384. Looking at it using Dependency Walker I can see it in fact exports the function you are looking for.
I also see on my InstallShield machine a merge module called MSVCRT.MSM that redistributes version 6.00.8797.0 of this file. However when I look it using Dependency Walker, I see it has the exported functions _except_handler2 and _except_handler_3 but not _except_handler_4_common.
So therefore you need a newer DLL and that merge module won't help you. Microsoft used to have this cool website called DLL Help Database that told you all the versions of a file and what shipped them but sadly they killed it.
BTW, I can also see that this DLL is installed with Windows these days. Windows XP? I'm not so sure as I'd have to fire up a VM and look.
A couple possible resolutions:
Find out what SP or Hotfix of Windows fixes this and make it a dependency of your MSI.
Grab the DLL from a Win 8 machine and add it to your INSTALLDIR and deploy it privately.
One final note. This is either caused by the version of Windows XP comes with an old version of the DLL ( A related KB Article says it does ) or that a third party application whacked the DLL causing the problem. Some more study is required here.
I recommend you first try installing the MSVC Redist version 2008. That one does include the implementation of the missing function.
This post is old but I wanted to leave my solution since this problem was hell to me. My python app was working for Linux, Win7, 8 and 10 but WinXP refused to work with that message.
I was using py2exe to get an executable and it will put some DLLs along with the exe file.
Deleting some dlls from the exe's directory was the only thing that make the app work in XP and continue working in the other systems:
[ "POWRPROF.dll","IPHLPAPI.DLL","USP10.DLL", "DNSAPI.DLL" ]
Also distributing "Microsoft.VC90.CRT" directory along with the exe file, with it's manifest and DLL files.
I hope this will be useful for someone, since it took me weeks to figure it out.
(i know the OP wasn't working with python, but the error is just the same)
Your program has a dependency which is not being satisfied on Windows XP. You might try using Dependency Walker to identify it, or you might check for known limitations. For example, Visual Studio 2012 doesn't support Windows XP until update 1 and a build option change - is that what you're using?
The problem was probably because you might used a corrupted DirectX version on your Win XP. It happened to me as well because I randomly downloaded a DirectX setup which was corrupted and caused these. The solution I did was is I deleted all the files that has anything to do with directX from C:Windows/System32, deleted the directX from add/remove program as well and completely removed the whole registry key from regedit. Local_machine/software/microsoft/DirectX... What I did then was found a original values and keys for DirectX 9 on the net and made a new registry key.
The DirectX folder was once completely and originally back on regedit and it showed in dxdiag that the directX is installed.
In case you encounter crashes in the game, I suggest you to download .NET Framework 3.5 Service Pack 1 and then make a backup on your PC (If you're not using nVIDIA graphic cards like I do, I use ATI Radeon) and download nVIDIA PhysX system software driver and see if it works. (You need nVIDIA phydX drivers to run this game without crashes only if you use Win XP, the problem shouldnt encounter on Win 7) In case the drivers screw up your PC (The nVIDIA PhysX one) you will be able to restore your old PC function before those drivers (If you made a backup of your PC, I suggest using Acronis Boot for backups) it means you're totally out of luck if you're not able to get the nVIDIA PhysX on ur for example, ATI graphics on Windows XP, because without nvidia physx, on Win XP, Metro wont run, while on Win 7 / Vista / 8 it should.
I just installed the latest VS 2017 and was running into the same problem. I googled everything but couldn't find any solution, so I just defined it myself:
extern "C" int _except_handler4_common() {
return 0; // whatever, I don't know what this is
}
I've spent the last 8 hours picking my code apart with this exact same error and it turned out to be a line of code in my application, specifically a check for IPv6 support in the OS:
conf.IPv6Disabled = !(Socket.OSSupportsIPv6);
I commented that line out and voila, error disappeared.
This problem persists to every software or game that requires windows 7 or 8 or vista but is made run into windows xp. So if you want to resume or start your program you need to upgrade your windows to 7 or 8 or vista as per the system requirements of the program.
HOPE IT WAS HELPFUL
THANKS
I am trying to run an old Clipper application. It runs fine on Win 7 32bit but when I try using the DOSBox 0.74 it crashes with the following error:
Exit to error: CPU_SetSegGeneral: Stack segment zero
Are there some settings I forget to set when running the DOSBox?
I need to be able to run this app in DOSBox as it appears to be only portable solution that would work on any Win 7, being it 32 or 64bit.
If no apparent solution is known for this problem maybe you can tell me what alternatives I have to run a Clipper 5.3 application on a Win 7 64-bit Home edition?
EDIT:
I tried it on Win 7 Home 64 bit with the very same result. What can I do?
I used clipper many years ago, clipper does cause problems because incorrect config.sys configuration, specially the setting "FILES" must be big enough (let´s say 200) for your application, but "original" dosbox does not provide a way to adjust this setting.
Try the patch from http://www.shdon.com/blog/2009/09/05/adjustable-files-setting-in-dosbox
This patch allows to configure FILES adding a new setting on dosbox options file
Steps:
Backup dosbox.exe and replace it with the patched version
Edit the dosbox options file and add FILES=200 to the [DOS] section
Try it and post the results since i don't have clipper 5.3 to test.
Wanting to close this question I will write what was the only solution thanks to which I was able to run that aged application on Win7 64bit.
It was VMLite XP Mode.
I simply followed the steps described in their how to guide and it was up and running then I copied my application into the VMLite XP Mode, and it was running fine.
Finally I created, after some googling, a shortcut to my desktop and now I can easily start the application from my Win7 64bit desktop which then lunches the VMLite XP Mode which starts the application :) or something along this lines anyway, so far, it works great.
I need take an old software that was built in 4D 2004 (you probably never heard about 4D but it doesn't matter) and make it compatible with Windows 7 by fooling it and making him believe he's running under Windows XP.
I thought the application was getting the version number of windows from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion and that I could change this value but I was wrong… Even if I change the values in the registry, the version number of windows returned by my application is always the same:
498139398 for Windows 7
170393861 for windows XP
Those value contains the windows version (this link explain how to extract the version number) but I don’t know where it was taken from.
If you google those numbers, you’ll find out that other applications are referring to the same version number.
I tried to find what registry was used by the application with a Process Monitor but none of the registry accessed by the application seems to be related to a windows version.
Does anyone have a clue of where those values might be coming from? Could it be outside the registry / hardcoded somewhere?
Windows already has tools to do this. Have you tried right-clicking on the program, selecting Properties and looking at the Compatibility tab?
For more complex tricks investigate "Microsoft Application Compatibility Toolkit".
I have a flash drive which has an application whose code is written VC++ 2008 , the application works fine in xp , but the problem arises when i plug in the drive to a windows 7 machine , it doesn't run properly. is there any way that i can make it compatible to windows by writing a code.
i dont want to set the compatibility tab in windows 7 to run the program..
i want to code it in the program , more like a patch.
You can use the Microsoft Application Compatibility Toolkit, which will tell you exactly which Windows XP compatibility shims are used by your code when you run your application under Windows XP mode.
You simply run your application and disable various shims until your code once again behaves incorrectly. The last shim you disabled is the cause of the incorrect behavior. You can then research the exact consequences of each shim as well as exactly what your code will have to do to fix the bugs it has that force it to run in Windows XP Compatibility Mode.
You probably need to add an Application Manifest to your application to request the appropriate security permissions to allow your application to do what it needs to do.
This may cause a UAC prompt to be shown to the user if elevated permissions are needed, but then your code will be allowed to do whatever Windows 7 is currently blocking.
If you know that the problem exists and know that UAC / etc ... / Manifest on Win7 don't solve your problem and that it's not connected with 32/64 bit issues, try a different approach.
I guess you know what goes wrong with your app on Windows 7. If you're not sure exactly, at least you should know where (in which logical block) your problem is located (e.g IO block, Disk read/write block, Gui, etc.
Now stick to the debugger. Hope your program isn't that big that you can't analyze it and find the source of your problem. You could have your problems because of some functions working not as expected or something like that.
Then, I guess, you could rethink / remanage your code and change it the way it works on both platform. If there is no universal solution, use #ifdefs to determine your current platform (the worst case actually, because you would have to have different binary files for different windows versions).
Has anyone ever tested a Microsoft Access 2007 .accdr application on Windows Vista 64 bit version? I sell a shareware program using the Access 2007 runtime, and, for one customer with that setup, there's some kind of problem. According the user ". When I try to execute the program, it opens IE and then brings up the dialog box to either Open, Save, or Cancel the "myprogram.accdr" file. If I choose run it simply goes away and then returns back to the same question"
It sound like this somehow got mapped to IE. On my windows XP system, it starts Access and runs the program. Any ideas?
MS Access isn't supported on 64bit, as it requires a 64bit JET engine which isn't available, Microsoft only released a 32bit JET engine. So your application has to run on WOW so it runs as 32bit and therefore is able to use the 32bit jet engine.
It works just fine. After 3 weeks of hair pulling with access installer packager. I got it wot work. your references must be added in the packager or you will get run time errors. Billions of them.. Not really 4 or 5. and then it will not recognize the built in functions like date, time, isloaded....etc.
SO YES IT WILL WORK.
Is the customer using the 64 bit IE? Access 2007 is 32 bit only. The 32 bit IE might work properly.