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).
Related
I'm working on an application developed for Windows XP SP3, using VB6. I'm currently in the process of getting it to work on Windows 7, but am encountering a problem with one of our custom OCX files.
When attempting to load a form that contains an instance of the control contained in the problem OCX, the following error is produced:
Failed to load control 'x' from y.ocx. Your version of y.ocx may be outdated. Make sure you are using the version of the control that was provided with your application.
I've checked the version numbers and they're all correct and referencing the proper version. The OCX registers fine, and all the expected registry entries are present.
Inspection with DependencyWalker shows no missing dependencies.
The software works fine under XP, and this is (seemingly) the only issue when running on Windows 7.
Interestingly, if I run through the VB6 IDE using a VB6 group (with the offending OCX part of the group, and the application the startup project), I don't have the issue. Running the application on it's own through the IDE still presents the error.
Any ideas on what could be missing which would cause the application to throw this error?
Error occurs on both Windows 7 Professional and Home Professional, both 32 bit.
This is almost certainly an interface compatibility problem. COM interfaces are versioned entirely separately from your Major/Minor/Revision numbers, which are little more than comments except as used by Installer.
Somewhere along the line you broke binary compatibility, and you are trying to deploy a library with a newer interface than your application was compiled against.
These version numbers are found in keys such as:
HKEY_CLASSES_ROOT\CLSID\{class Id GUID}\VERSION
Your program needs to have its old reference to the OCX removed, a new one set, and then it must be recompiled. This also means deleting any instances of the control and adding them back one by one.
I doubt this is a Windows 7 issue.
I would suspect this is a UAC problem. Try turning UAC off to see if that solves the immediate issue. If it does then you have to regsiter everything using 'run as administrator' and/or create a manifest for you application.
Sounds like on of the controls included in your OCX is having issues loading, not a general registration error. Look at the constructors for x control, and see if they are doing anything that disagrees with UAC or such. One way you can debug this is put some kind of a break before the control is initialized, and debug the application from Visual Studio (remember to create the PDB's in VB6), and then carry on from the break to see why the control isn't initializing.
I have a game that I have made in C# and it installs and runs as expected under Windows XP. However when I install it on a Windows 7 machine, then it either simply doesn't work (without any error message) or it gives a generic error message. Is there anything special that I have to do in order to be able to use SDL.Net with a Windows 7 computer?
UPDATE: I have just been informed that it doesn't even work on XP. Both XP machines I tried it on had SDL.NET installed (I didn't know that one of them already had it when I used it for testing). So pretty much if SDL.NET SDK is not installed on a computer my program doesn't work. Does anyone have some insight into what exactly needs to accompany my program from SDL in order to make it work properly? right now I have all the base SDL_*.dll and SdlDotNet.dll and Tao.Sdl.dll. More needed? Or is there some kind of SDL runtime that I have to install with my program in order to use it? I am really stuck with this one.
Have you tried running it as admin? I don't mean happening to be logged in as an admin account, I mean right click the exe and Run As Administrator? If you do that and don't get the error, then your problem will be quite easily solved, without requiring it to always Run As Admin.
Added every Dll including those that weren't explicitly needed and it now works. Apparently there are some hidden links between dll's that I didn't know about.
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 an application written in Delphi 2006 that was working fine in Windows XP. I packed the application using Inno Setup, using Program Files as the default folder. A few users migrated to Windows Vista and Windows 7. The issue here is that the application creates some files inside its installation folder by its own. This was working in XP but in Windows Vista the users were having problems with the created files (they don't appear and so on). After investigating the users' reports I discovered KB 927387: "Common file and registry virtualization issues in Windows Vista or in Windows 7."
Running the application with administrator rights just solves the problem, but that is (I think) an awful workaround. I would like to know if there are any directives or tips for making the application compatible with Vista and 7, because more users will migrate to these OS soon.
You need to re-write your application to store its files in the proper locations, even in XP, but especially in Vista onwards, particularly if UAC is enabled. This is becoming more and more important to get right as Microsoft keeps locking down and enforcing its security models with each new OS version. The rules for how to properly manage application- and user-related files is documented on MSDN, for example: "Application Specification for Microsoft Windows 2000 for Desktop Applications, Chapter 4: Data and Settings Management" and "Application Specification for Microsoft Windows 2000 for Desktop Applications Appendix A: Best Practices" (yes, they are old, but are still quite relevant). Look at SHGetSpecialFolderLocation(), SHGetFolderPath(), SHGetKnownFolderPath() and other related functions to help you.
For Vista/Win7, your app can't put the files in a subfolder of Program Files / Programs unless UAC is turned off or the app is running as elevated. Note that "elevated" does not necessarily mean "logged in as Administrator." Non-administrator users can elevate, and Administrator isn't necessarily elevated.
If the app does attempt to write to Program Files but is not elevated, the OS will either block the app or "virtualize" the write (put the files somewhere else), depending upon how UAC is configured. Neither one helps the app succeed at what it was trying to od.
So it needs to put them somewhere else. Where depends on why the files are being created, and you haven't told us that. You can read this article to learn about the options. Note that in addition to the user's AppData and Roaming folders, there is also an "All Users" (shared) profile.
You should probably look at this article and screencast, which discusses UAC in depth from a Delphi point of view.
Files you create for use by your application other than at installation time should go into the ProgramData directory if its global to the workstation, or into the users ApplicationData directory if its specific to the user.
For cases where you absolutely must place a file in the program files directory, you can use com to request elevation. This is discussed in great detail, and delphi specific bits are also available. One example that I have used this is in patching my users installation base. They are warned by UAC that the system needs to make changes, so if your doing this as an automated task, you might need to rethink the logic to be more user driven.
Here is another article, by Zarko Gajic, which shows how to get different system directories. Also have a look at this related question.
I had a similar enquiry here (Stack Overflow).
In the end I realised that I needed to put my application into Program Files at install time (requiring UAC/elevation) and then store my app's data in the user's App Data folder. I had to change the way my program generated 'default' configuration settings and also where I was saving this stuff, but it was worth the effort in the end - we ended up with something that installs and runs fine on XP, Vista and Windows 7.
The only UAC hit we get is at installation time, which makes sense to me (and you get a similar hit at install-time on the Mac too). We didn't have any data that would be common to all users in this particular case but I would have looked at the Program Data special folder if that had been the case.
The installer software we use (Setup Factory) made this fairly straightforward (we just wrote a small bit of code to detect XP versus Vista/Win7 and choose the right special folder accordingly). It would be easy to do this in Inno Setup too, from what limited experience I have of it.
My application needs administrative access and I want it to run without any hassles in Windows 7.
I have the following options
1.Ask the user using the application to turn off UAC. This is a last resort option and would hate to do that.
2.Embed a manifest in the application that says elevate to adminstrator privelege. This will work but it seems that it will bring up a dialog requiring users consent every time a user runs the application.
3. Configure the application to run in Windows XP compatibility mode. This works, but i had to do this using explorer->application properties. if can I do this programmatically during installation time, I would really prefer this option. My question is if there is any way to achieve this.
regards
Ganesh
Try making an application compatibility shim that says your app needs the XP compatibility mode, and distributing it with your app. A shim is a means for administrators to simplify installation of a 3rd party app that needs compatibility settings - it saves them tweaking each PC individually. You can probably roll it into your install program with a little ingenuity.
I've gotten pretty used to dealing with the UAC dialog, running Vista for the last 2 years. If it bugs you, I have to wonder how much experience you have using post-XP OS'es.
As a user I think there are two ways to look at it:
The program inherently requires admin. For these, I very much appreciate the dialog, as I know it means nobody's going to sneakily run that thing in the background on me and modify my system.
The program inherently does not require admin. Most programs only need admin to auto-update themselves (and probably shouldn't need it then). My attitude is that these programs are poorly-designed. Such a program should only invoke AUC if it discovers it needs to update, not every single frigging time I start it up. This is a security issue too, as any buffer overflow someone finds in the entire program puts me at risk.
Localize the need for UAC as much as you possibly can. The best would be to put in a separate executable. (eg: an "updater")