Windows Vista compatibility ?

[pww]

Hi,

I just downloaded Windows Vista RC1 demo version and installed the OS, then tested my setups (generated with SF 7.0.5.1) on it.

With all, the following happens:
When I dbl click my setup .exe, an error message 'Application failed to start' or alike pops up (my Vista PC is not around so I'm not sure about the exact messages texts).
The error is about irsetup.exe file

After I repeat this several times (3 to 5 times I guess) , Vista informs me that the next time I start this application, it will run in compatibility mode. And the next time I run my setup .exe, installation goes OK.

However, most Vista users will surely not start the setup 3-5 times - they'll trash it after one or two attempts.

The number of Vista users increases rapidly, and these are mostly users without whatever experience with this OS so they will not know what to do in such case.
Is there any way to avoid this problem with SF 7.0.5.1, if not when an update is to be expected?

[AXXESS]

The number of Vista users increases rapidly

Upon its eventual "official" (non beta or RC release), I'm sure IR will have something in place when Vista is ready for official release...

I also bet that they will not pursue IR product compatibility with "RC" or Beta versions of the OS....

[Lorne]

Rest assured, we have been (and are still) actively testing all our products for compatiblity with Vista.

[Intrigued]

Rest assured, we have been (and are still) actively testing all our products for compatiblity with Vista.

That's stellar good to know and surely helps to build confidence in those looking to buy AMS.

:yes

[redline21]

One of the things I am reading is that on a locked down Vista system, only an Admin can install software. The logic being that companies don't want their dumb empoyees installing all kinds of software all over their machine. So even with a legitimate application, when the user tries to install the software, it will fail if they are not an Admin. I don't see how the SF installer will be able to get around that (unless there is some kind of digital certificate thingy).

Things that will fail include:
1. Installing COM components (for more than a decade, MS pushed COM and DLLs and now they say don't use them!).
2. Modifying the registry anywhere other than HKEY_CURRENT_USER
3. Trying to write files anywhere other than C:\Documents and Settings\UserName\...\Application Data

Other applications can run in so called "compatibility mode" but the user has to be smart enough to configure the system to let the application run.

Also, it seems MS is pushing the MS Installer (and MSI files) as the only valid installation method. Not sure if that means an MSI install can modify the registry or install files whereever.

I haven't seen the Vista Release Candidtate yet. This is only what I have read. Any corrections would be appreciated.

[Adam]

Thanks for the comments. Vista does lock User accounts down pretty tight.


Adam Kapilik

[Intrigued]

Thanks for the comments. Vista does lock User accounts down pretty tight.


Adam Kapilik

Another reason good reason to stay out of the Registry?

;)

[redline21]

Another reason good reason to stay out of the Registry?

;)

Well, the registry is there for a reason, i.e. to store application data. Do you have an alternative? Are we back to INI files? I think you can still write to HKEY_CURRENT_USER. If that was made read only, it would pretty much render all software unusable.

My complaint is that I used HKEY_LOCAL_MACHINE to write application trial version stuff at install time such as the installation date. With that key locked down, all my trial version installs failed. But that has been that way for several years as ADMINS began locking down WinXP.

[Intrigued]

Another reason I watch using the registry beyound the various other reasons is because of future third party applications (security mainly I speak about) potentially going "hey, that's not a safe thing to do AMS program".

So, I will let I.R. (like they have) set safe places in the registry to write (and read) to/from. They have more time to check these sort of things and the staff. Other than that... I don't mind .ini files. We can always encrypt them and ultimatley have more control over them, without the security headaches.

My take on writing into the Registry.

[redline21]

Not to drag this along, especially because I haven't even seen Vista yet, but I think a potential problem with INI files is that once the application is installed, you have to assume the user will not have write permission to C:\Program Files\...

So INI files can not be stored there.

I think the only place fully locked down users have write permission is C:\Documents and Settings\UserName\...\Application Data. So you would have to put your INI file there -- which is fine as long as you can find that directory. I am sure it is written in the registry somewhere but I haven't looked to see.

[Intrigued]

Not to drag this along, especially because I haven't even seen Vista yet, but I think a potential problem with INI files is that once the application is installed, you have to assume the user will not have write permission to C:\Program Files\...

So INI files can not be stored there.

I think the only place fully locked down users have write permission is C:\Documents and Settings\UserName\...\Application Data. So you would have to put your INI file there -- which is fine as long as you can find that directory. I am sure it is written in the registry somewhere but I haven't looked to see.

I came up with a way in AMS to see many of the Shell folders. Check this link out:

http://www.indigorose.com/forums/showpost.php?p=84531&postcount=10

And check out this code:

Shell.GetFolder(SHF_APPLICATIONDATA);

[Eagle]

if not already suggest becoming aware and digesting stuff at the link below:

http://msdn.microsoft.com/windowsvista/default.aspx

When there select 'reference' link at the very least.

imbedded manifests and 'publisher cirtificates' is well worth
a good look.

read\write to hkcu is still ok under Vista.

I have recoded some apps to only use current user App data folder
(via all the great xml file manipulation actions in supported IR products)

UAC and 'account privelege' is a default OS install reality all developers
will have to deal with, if seriously wanting to support Vista.

IR will come up with the goods , we all need some time to digest the changes
and come up with adopting 'best practices developing for Vista.

Vista has not hit the OEMS yet, current version leaked is 5840(pre-release RTM)
-don't ask where or how to get it, I am not bothering with Vista at this point in time

I have coded into product installers - updates to not support vista at this point in time

fwiw

[redline21]

I finally got Vista RC1 installed. I am in the process of testing out all of my SF6 installations. So far, no problems. However, my setups are not particularly complex. I have not yet tried with locked down permissions, but with the default "home user" installation, everythign seems fine. I do get a warning notifcation when I start the setup, but it seems clear enough that users will pass it by. I don't understand the comment about 3-5 installation attempts.

I am quite surprised that my software seems to wokr fine in RC1 except that Vista no longer supports .hlp files and one of my custom controls crashes the program.

[jassing]

I finally got Vista RC1 installed. I am in the process of testing out all of my SF6 installations. So far, no problems.

Are you installing as a user or administrator?

[redline21]

I am logged in as whatever the default user setting is when Vista is installed.

I have found some issues:

1. When you first run the installation program, Vista displays a dialog indicating that the program is unknown. That is OK, it does the same with an MS Office 2000 installation and almost any other program. However, Vista lists the publisher as Indigo Rose corp. That should confuse some of my customers. I don't see any way to change this in SF6. And I am not upgrading seeing as SF7 apparently does not completely import SF6 projects. Way to go Indigo Rose! Don't make any effort to support upgrades.

2. Uninstall is weird in Vista, although I think it is Vista bugs. Every time I go to uninstall one of my applications from the control panel, Vista lists the program as Microsoft Windows Publisher.

I have found a lot of bugs in Vista RC1 and I am not even beating on it that hard. For example, it won't play music CDs at all.

[jassing]

However, Vista lists the publisher as Indigo Rose corp. That should confuse some of my customers.

I agree 100% here -- hopefully; when the vista upgrade comes out; it will list itself as whatever is defined as the company. You can (although I believe it to be against the eula) use something like resource hacker to hack the resource table to be your company.

And I am not upgrading seeing as SF7 apparently does not completely import SF6 projects. Way to go Indigo Rose! Don't make any effort to support upgrades.

I felt similarly years ago when suf7 came out -- the move to LUA is big part of why your sf6 projects can't be "improted".

Don't think of SUF7 as an upgrade to suf6, but as it's successor -- a new program. You're missing out on a ton of great features, not to mention an overall much better product for you and your users.

-josh