So it all boils down to a few specific questions: [LIST=1]
Has anyone had any issues converting from an older version of InstallShield to 2010 and recieved similar errors?
After researching (for the past few hours) I keep reading about how there are different versions of CTL3D32.DLL for Windows 95 and NT (NT needing a different version). Is this true for Vista too, does Vista need it's own version?
The installation (using this installshield version, 2010) works fine on Windows XP but throws the above errors whenever someone installs on Vista. The last version of InstallShield that was used was able to create a Vista installer but since converting we are unable to get past this error. I keep reading about how there are different versions that are OS specific so I am at a loss here on this. Also I am unsure if this issue is caused by the DLL versions...
The only change I have made since the conversion is to add a string to the 'product version' area under the 'General' section.
Any help is greatly appreciated! And please realize that I have inherited (was hired to replace someone) and am fairly new to this process/position so please bear with me... Thank you...
So if anyway for prosperity I figured I would share me find with the world:
After some more digging I found that there are certain files that in Vista are completely locked (meaning that they are cannot be overwritten). The product I work on included these DLLs because it used to support older versions of Windows. In the case of 3D control "CTL3D32.DLL" you CANNOT overwrite this file even in administrator mode. There are perhaps ways of getting around this but this is unnecessary since these DLLs have not changed since 98se (the versions shown in the properties menu remain the same).
So now I'm stuck at how to NOT install these files for a Vista (or Windows 7) box but allow them to be registered for older windows. Is there an easy solution that I may have overlooked?
You're probably only seeing this issue with newer versions of InstallShield because all built setup.exe's contain an application manifest, which turns off a number of application compatibility shims in the OS (the manifest indicates to the OS that the EXE being launched is more or less compatible with the OS). Since the setup.exe's built with IS Pro 6 didn't contain an application manifest, Windows would have turned on a number of app compat shims that would have made it look like the registration of these files succeeded, when in fact, the registration was silently blocked and a success status was returned by the OS.
Moving these files to components that only install on older operating systems would be the best practice for resolving this issue.
Then how would we update system components that need updating? Wait for Microsoft to patch it? I'm just wondering because of the DLLs and OCX's we need are version specific.
Basically, only operating system mechanisms are privileged enough to update protected resources. This functionality was added to prevent applications from overwriting system files with incompatible versions of these files.
