# Visual Basic > Visual Basic FAQs >  Modifications Required for VB6 Applications to Work on Vista/7

## Hassan Basri

I have compiled a list of changes required for your VB6 application to work correctly on Vista. If you learn something new please post the information in this thread. Every once in awhile I will edit this first post to keep the list complete. So far this is what is known:

*Application Changes* 

Remove SendKeys calls and replace them with API code.Use the HKEY_CURRENT_USER in the registry for the settings of your application. Do not write to HKEY_LOCAL_MACHINE.If you are using ADO use 2.8 and above in your application.If you are using XML use XML version 3.0 and above in your applicationIf you are using the PlaySound API, if your wave files are not PCM but mpeg layer-3 make sure your mpeg wave files are Stereo and not Mono.If you need the Printer Setup dialog either using the Common Dialog Control, or by using the API functions, the dialog will not return the correct number of copies. The dialog will always return 1 on Vista. The way around this bug is to create your own Printer Setup dialog box and when you get the correct number of copies you will have to send to the printer multiple times to print out multiple copies. Here is a link that discusses this issue in details. Relocate settings files, data files etc into "Common Files" (C:\Users\Public) instead of "Program Files". You should use the API calls to locate these folders because the folders are in different paths for different machines and OSs. Here is a link that discusses this issue in details.
Per-user settings should be in a separate file located under "Application Data" and this should also be requested of the OS in the same manner.For "Common Files" ask for ssfCOMMONDATA (or CSIDL_COMMON_APPDATA).For "Application Data" ask for ssfAPPDATA (or CSIDL_APPDATA). To properly use these filesystem locations you are supposed to create a subdirectory for your "company name" and under that another for your "application name." Then put your settings or data under that. Any working "document" files that are meant to be found and manipulated by the user (i.e. via Explorer) should be placed into CSIDL_PERSONAL ("My Documents") or CSIDL_COMMON_DOCUMENTS ("All Users\Documents"). DeleteSetting no longer works without a key. e.g. DeleteSetting "Mytestprogram, "General" fails to delete anything and gives an error. but DeleteSetting "Mytestprogram, "General","keyname" works fine. It seems that key is no longer Optional in: DeleteSetting appname, section[, key] as in documentation. Credit: roylow

*Setup Package Changes*

*Administrator Account running your Setup Package*

Require users to "Run as Administrator" directly in your setup package.Inform users to right-click the setup package and click "Run As Administrator".

*Non-Administrator Account running your Setup Package*

Remove the VB6 Runtime files, MDAC and any of these files from your setup package.

*Visual Basic IDE Changes*

If you are using Visual Basic 6.0 on Vista, you will notice a latency in speed. This can be solved by using "Windows Classic Theme" or "Windows Vista Basic theme" instead of the new Vista Theme with the Aero effect.

*Useful Links*

Teach Your Apps To Play Nicely With Windows Vista User Account Control Understanding and Configuring User Account Control in Windows Vista

*Credits*

 Thanks to RobDog888 for his links and knowledge on VB6 / Vista issues from several of his posts.

----------


## RobCrombie

Thanks for the 'heads up' on SendKeys.
That's a bummer.
Here is a link on the subject -
http://forums.microsoft.com/MSDN/Sho...74685&SiteID=1

----------


## Ellis Dee

> Use the HKEY_CURRENT_USER in the registry for the settings of your application.
> [...]
> Relocate settings files, data files etc into "Common Files" (C:\Users\Public) instead of "Program Files". You should use the API calls to locate these folders because the folders are in different paths for different machines and OSs. Here is a link that discusses this issue in details.
> Per-user settings should be in a separate file located under "Application Data" and this should also be requested of the OS in the same manner.For "Common Files" ask for ssfCOMMONDATA (or CSIDL_COMMON_APPDATA).For "Application Data" ask for ssfAPPDATA (or CSIDL_APPDATA). To properly use these filesystem locations you are supposed to create a subdirectory for your "company name" and under that another for your "application name." Then put your settings or data under that. Any working "document" files that are meant to be found and manipulated by the user (i.e. via Explorer) should be placed into CSIDL_PERSONAL ("My Documents") or CSIDL_COMMON_DOCUMENTS ("All Users\Documents").


How are these changes? These have been the official stated guidelines for XP development for years now.

----------


## Hassan Basri

> How are these changes? These have been the official stated guidelines for XP development for years now.


That is true but before you could get away with it, now in Vista you can't.

----------


## NickThissen

> *Visual Basic IDE Changes*
> 
> If you are using Visual Basic 6.0 on Vista, you will notice a latency in speed. This can be solved by using Windows Classic Theme instead of the new Vista Theme with the Aero effect.


I would just like to add to this, you don't have to use the Windows Classic Theme, you can also use the Windows Vista Basic theme, which still looks like Vista except for the Aero (glass) effects.
You can acces it like this:
- Rightclick on the desktop
- Choose _Personalization_
- Choose _Windows Color and Appearance_
- Choose _Open Classic appearance properties for more color options_
- Select _Windows Vista Basic_ and press OK or Apply.

Just because i hate the classic windows look :P

----------


## roylow

Another incompatibility with vista (64). Deletesettings no longer works without a key.
e.g. DeleteSetting "Mytestprogram, "General" fails to delete anything and gives an error. but 
DeleteSetting "Mytestprogram, "General","keyname" works fine.

It seems that key is no longer Optional in:
DeleteSetting appname, section[, key] as in documentation.

----------


## TheBigB

> I would just like to add to this, you don't have to use the Windows Classic Theme, you can also use the Windows Vista Basic theme, which still looks like Vista except for the Aero (glass) effects.
> You can acces it like this:
> - Rightclick on the desktop
> - Choose _Personalization_
> - Choose _Windows Color and Appearance_
> - Choose _Open Classic appearance properties for more color options_
> - Select _Windows Vista Basic_ and press OK or Apply.
> 
> Just because i hate the classic windows look :P


Even easier;
- Go to the VB6 shortcut properties
- Go to the tab Compatibility
- Check the boxes:   
   - Disable visual themes
   - Disable desktop composition

That's it, no need to stick to Vista Basic theme or switch around constantly.

----------


## Czor

I changed my Vista to classic theme, and everything works fine..
Are these modifications important?

----------


## NickThissen

If you mean the modificiations TheBigB listed, they simply switch the theme to Vista Classic automatically as soon as VB6 is started and also switch back to your normal theme when VB6 is closed.
So it does exactly the same as manually setting the theme, only than automatically.

----------


## Siddharth Rout

An Interesting Read

See the post by mindserve at the bottom

Hope this helps...

----------


## BruceG

Hello all,

This is not a question, but an FYI.

This may be old news to some of you, but for those that are not aware, if you have Windows 7, MS provides a free "Virtual PC" that runs "XP Mode" that you can download from the following site:
http://www.microsoft.com/windows/vir.../download.aspx

Once you set it up, you can run XP in a separate window from your Win 7 desktop (from my perspective, it feels like you are running "gotomypc" or VNC or something similar). Anyway, all your Win 7 drives and folders are automatically shared on the virtual XP box. Anyway, this makes it easy to install VS/VB6 - there are none of the headaches that I have seen reported by folks trying to install VS/VB6 on Vista or Win 7. I was able to install VS6, then SP 5, then I registered some other AX controls I use(d), and loaded up an old VB6 app, and it worked without a hitch.

It is true I was a VB6 holdout for longer than most, but I did move over to the "dark side" of .NET over 2 1/2 years ago and have not done any new VB6 development since then; however I still do have a fair number of VB6 apps to maintain. This is my first development box that runs an OS higher than XP (although I have tested VB6 apps on Vista boxes).

So I just wanted to share this with you, and recommend this option for those of you who need to run VS/VB6 on a Win 7 box. Again to reiterate, AFAIK, the "Virtual XP box" option is only available on Win 7 (not Vista).

----------


## baja_yu

I have a few additions to this.

Section 'Administrator Account running your Setup Package'

Vista and 7 has compatibility mechanisms that detect keywords like setup, install, update in the exe name and project description (file properties) and will automatically elevate such a process. This is good and bad. Good it makes old installers work (most of them) without the need to do right click > Run as administrator, but on the other hand if you named your exe or project something like "InfoUpdater" it will be automatically elevated every time which you will most likely not want to happen.
Aside how stupid this thing is, MS also never provided a way of downgrading the privilege level. This means that if an application running with admin rights shells another application, that other application will be launched with admin rights too. On the other hand, applications running as standard user _can_ request elevation of a process to admin level (followed by the UAC prompt).

There are also changes in the way how Services work. They now run in a separate, isolated, session 0. This means they can no longer have any interaction with other sessions (Desktop). Services can't shell applications, they can't show any windows or messages, but they have unrestricted access to protected areas of the file system and registry (except the HKCU hive).

----------


## dilettante

> Vista and 7 has compatibility mechanisms that detect keywords like setup, install, update in the exe name and project description (file properties) and will automatically elevate such a process. This is good and bad. Good it makes old installers work (most of them) without the need to do right click > Run as administrator, but on the other hand if you named your exe or project something like "InfoUpdater" it will be automatically elevated every time which you will most likely not want to happen.


This only happens for a legacy program, i.e. one that does not declare itself Vista Aware, i.e. one that does not have a proper application manifest with ExecutionLevel set to "asInvoker" if you don't want to require elevation.



> Aside how stupid this thing is, MS also never provided a way of downgrading the privilege level. This means that if an application running with admin rights shells another application, that other application will be launched with admin rights too. On the other hand, applications running as standard user can request elevation of a process to admin level (followed by the UAC prompt).


How is this an issue?

If your program has elevated privileges and it spawns an external process it should "know where that process has been."  I.e. don't write programs that run arbitrary programs.

If a program is running unelevated and the user wants to request an elevated action it is perfectly reasonable to elevate just that function (either via the Elevated COM Moniker or RunAs or just Shell-ing an external process that has an elevation manifest.

Finer control is always available through the use of security tokens and the various CreateProcessXXX API calls.

----------

