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".
Related
I've been working on detecting Windows 11 machines, which I have successfully done by looking at the CurrentBuild registry value for anything above the build 22000+. However, when it comes to determining Windows 11 editions such as Home, Pro, Enterprise, etc. the only thing I can think of is parsing the ProductName registry value and looking for key words that correspond to the Windows 11 editions. I have tried to look through the Registry to find anything resembling 'Windows 11 Home/Pro/Enterprise' but I have not been able to find anything. Has anyone been able to find a registry value that corresponds to the edition other than in the way I'm currently doing?
From code, you can make use of GetProductInfo assuming you have the proper manifest in your EXE.
Alternatively, look at the WMI API using OperatingSystemSKU in Win32_OperatingSystem.
According to MSDN, GetVersionEx (the de facto way of getting the current windows version) has become deprecated as of Windows 8.1. Apparently it returns wrong values (corresponding to Windows 8) if called on a windows 8.1 or 10 machine. However, it can be made to return correctly if the application's manifest is modified correspondingly. But I'm not sure this is such a good solution since
GetVersionEx may be altered or unavailable for releases after Windows 8.1
I was thinking of simply reading the information I need from this registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion .
Is there any reason I should avoid doing this, given the current situation (API deprecation) ?
Is there any reason I should avoid doing this?
It is plausible that a future version of Windows will not contain the information that you need in that registry key.
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.
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).
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.