Modifications Required for VB6 Applications to Work on Vista/7
Thanks to Hassan Basri in VBForums
- 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 application
- If 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. http://www.vbforums.com/showthread.php?t=456940
- Relocate settings files, data files etc into "Common Files" (C:UsersPublic) 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. http://www.vbforums.com/showthread.php?t=461613[/URL]
- 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 UsersDocuments").
- 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. Another incompatibility with vista (64)is the Deletesettings no longer works without a key. 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.
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.
If you have Windows 7, MS provides a free "Virtual PC" that runs "XP Mode" that you can download from the following site:
Any application done in XP will run in the virtual XP mode on Windows 7. 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 OCX controls I use(d), and loaded up an old VB6 app, and it worked without a hitch.
We have to consider though that any Windows version after 7 will NOT support vb6 applications anymore, as per Microsoft. We will all be stuck, unless we go over to .net, which is what I am currently doing.
When installing Visual Studio or Visual Basic 6 directly on Windows 7, run the application as administrator, otherwise there will be errors with the install.
First make sure you have got all the necessary runtime files and check the
service pack levels. MS ships a XP VM for XP Mode and I'd guess the SP
levels there would be SP6, but I haven't checked, and of course the usual, ensure
your dlls are all there and registered applies.
When using a 64 bit system, the following by Mayayana -
In addition to what others have said, 64-bit
could be something that requires planning,
depending on what you're doing. Win64 is
basically two OSs and two Registries in one.
It requires different code if you want to write
to the main system Registry. There are two
system folders. Etc.
I haven't tested on 64-bit and I don't really
expect issues with my software, but a good
example of unexpected problems is the following:
I've written a number of COM DLLs for use in
scripting. Recently someone wrote to say that
one of them wasn't working. They were on 64-bit.
The DLL is 32-bit. They were trying to run it in
a VBScript. It turned out that there are two versions
of WScript -- 32-bit and 64-bit. The person had to
assign the 32-bit version as the default program
to open .vbs files in order to get my DLL to work.
At some point a person like that will need to
either switch over to all 64-bit or invent new file
extensions in order to run both in parallel. They
have parallel, redundant systems now. It's just not
a big deal yet because there isn't much 64-bit software.
To make matters worse, the 64-bit system folder
is named System32 and the 32-bit system folder
is named SysWOW64! And on top of that, the error
messages don't seem to be very intelligent. I think
the error in the example above was something like
"File not found" rather than "Library is 32-bit and
WScript64 will not run a 32-bit library."
So Win64 problems are likely to increase in the
future and may not always be easy to diagnose.
Teach Your Apps To Play Nicely With Windows Vista User Account Control - http://msdn.microsoft.com/en-us/magazine/cc163486.aspx
Understanding and Configuring User Account Control in Windows Vista - http://technet.microsoft.com/en-us/library/cc709628(WS.10).aspx
Finally for now...
I will update this as I find more information on this. I am currently running all three OS's with Windows 7 only as a test and some small apps. So far everything seems fine. I am looking to get myself a Mac and will then see how does VB6 get treated over there. I will keep you all informed.:cool: