Will VB6 application run under Vista 1

[moben]

I have several VB6 applications with Access 2000 as back end, running on Windows 2000.

We will be moving to Vista next year.

Question:Will the VB6 application run on Vista, if not what changes are required ?

moben.

 

[strongm]

>Will the VB6 application run on Vista

Sure

 

[ChewDoggie]

I've read that Vista restricts apps like VB from writing registry values. Microsoft site suggests the use of .INI files as a replacement.

Chew

10% of your life is what happens to you. 90% of your life is how you deal with it.

 

[strongm]

An application written in VB should happily run under Vista as long as it follows the rules.

Those rules are not particularly onerous. I have a bit of freeware that I wrote back in 1998 for Windows 95 and Windows 98 that works absolutely fine under Vista, reading and writing to the registry. It was carefully written to follow all MS guidelines at the time and, as a result, has worked flawlessly* under all versions of Windows since then.

I'd love to know where you found "Microsoft site suggests the use of .INI files as a replacement", as that's news to me.





*The only change I have had to make since the program was originally written was to include a proper way of calculating the thickness of a window border instead of a naughty shortcut that I originally took

 

[three57m]

While INI files would work fine; I think some confusion started with the HKEY_LOCAL_MACHINE restriction. When the Vista UAC is enabled apps cannot write to HKEY_LOCAL_MACHINE. However writing to HKEY_CURRENT_USER is still allowed. I would guess this is per MS guidelines back to XP or before.

http://msdn.microsoft.com/en-us/library/aa753633(VS.85).aspx

 

[three57m]

>onerous

 

[dilettante]

I'd love to know where you found "Microsoft site suggests the use of .INI files as a replacement", as that's news to me.

Registry Virtualization

Virtualization is intended only to provide compatibility for existing applications. Applications designed for Windows Vista should not write to sensitive system areas, nor should they rely on virtualization to remedy any problems. When updating existing code to run on Windows Vista, developers should ensure that applications only store data in per-user locations or in computer locations within %alluserprofile% that properly use an access control list (ACL).

While this doesn't rule out HKCU (and actually mentions it indirectly as a valid place for storing settings) there have been plenty of suggestions that developers move to ini or config files instead. Note that per-computer settings are clearly meant to live outside the registry entirely though.

Virtualization can make some programs seem to work right until it finally becomes clear that each user has a separate shadow copy of common settings, each getting updated separately.

So if one moves to ini/config files for common settings why not use the same approach for per-user settings as well?

 

[yacyac]

I believe that VISTA will not allow you to write to the app.path folder. Writing to app.path folder never was a good idea and shouldn't be done, however many "programmmers" have done it in the past.

 

[TLowder]

yacyac, I guess I'm a "programmmer" as I've always used app.path. Why is app.path never a good idea and shouldn't be done?

Tom

 

[Bluejay07]

Going back to the original question,

I believe Vista ships with all of the required VB6 runtime files needed.

This helps in running programs within the Vista environment.

I'm not sure about Access 2000 compatibility as Office 2007 was designed specifically to work with Vista.

I also read somewhere about the .ini files. I am not sure if it was somewhere on tek-tips forums or other sources while looking something up.

 

[dilettante]

App.Path is fine where appropriate. The problem is you're only supposed to retrieve read-only data from files at and below App.Path.

The idea is that most programs should be deployed into the Program Files folder, and this is not an area users should have write access to. Vista enforces this now even if administrators have not protected this filesystem location by setting an ACL on it, i.e. the default ACL has changed.

To allow old programs that broke the rule to continue working Vista will virtualize such data files on a per-user basis. This can wreak havoc if a given file is meant to contain shared settings, is an MDB file meant to be common to all users, etc. Each user ends up with a virtualized copy containing only his own changes.

New (i.e. Vista aware) programs should be putting read/write common files into an application folder under CommonAppDataFolder after creating the folder and setting the desired ACL on it. This is normally an Installer responsibility, done with elevation.


All of this is pretty old news now. You can read more at The Windows Vista and Windows Server 2008 Developer Story: Windows Vista Application Development Requirements for User Account Control (UAC).