All these years i have been successfully using EnumServicesStatus in combination with OpenScManager (with SC_MANAGER_ENUMERATE_SERVICE) to get a list of the services installed on a computer. This has been working well since NT 4 and up to Vista.
Now, for some reason, in Windows 7 I'm not getting the whole list of the installed services, but only a few of them. No errors, just a very incomplete list of services
Has anything changed in Windows 7? Do I need administrative powers now to enumerate services (I hope that's not the case)? Using Delphi 2010 but the same code was working file in D2007.
I don't think anything has changed here. It would cause huge incompatibilities with old software. But D2007 used the ansi version ENUM_SERVICE_STATUSA and I think D2010 calls the unicode version ENUM_SERVICE_STATUSW. Maybe you are doing some manipulation in the results that assume that the result is ANSI when you are getting Unicode? Just guessing.
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 have some free-standing C++ code (i.e. not a Windows program) that needs to identify the version of Windows that is installed on a PC.
I can easily differentiate between the different Windows client releases by kernel version (e.g. GetFileVersionInfo on ntoskrnl.exe), however I'm wondering if there's a reliable way to distinguish between a client and server installation.
A problem arises when using this method to distinguish between Windows Vista SP2 and Windows Server 2008 SP2 (6.0 build 6002 the both of them) and Windows 7 and Windows Server 2008 R2 (6.1 build 7600 for RTM and 6.1 build 7601 for SP2, both). What is a reliable (and preferably as straight forward as possible, avoiding the registry would be great as access to Win32 API is not available) method of identifying client vs server OSes correctly for code running outside the environment?
I suppose I could check for files only present on the server edition (what's a good file guaranteed to be on any server edition install, regardless of configuration?), check the Panther folder (which is safe to delete, so no guarantees there), etc. but I'm sure this is a problem that people have run into before and (hopefully) solved more elegantly?
(Sidenote: this question has been asked on SO before, but the solution (WMI) is inapplicable for out-of-band checking)
I'm not entirely sure what you mean about out of band checking, so I'm going to ignore that for the moment.
The normal way would be to call GetVersionEx, and look at the wProductType member of the OSVERSIONINFOEX.
A PE image does NOT specify whether the image should work on a client or server. It only specifies the runtime requirements regarding subsystem, dependencies, memory, affinity, etc...
I ended up searching for a number of binaries in the system32 directory that are generally associated with the Server Edition of Windows. It's not very clean, but in practice it works very well.
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.