Is the VB run-time automatically installed on Windows XP/Vista?

I'm looking to develop an application in either VC++ or VB - old style executable, not .NET code. I need to distribute this app to multiple PC's runing Windows, (XP and Vista, maybe Win2K). I won't have any control over the configuration of Windows on these computers.

I seem to remember that with VB that you needed to have some runtime files installed on the computer before your program would work, and that these run-time files weren't always installed by default. (I might be going back into the dark ages here, it's been a long long time sonce I've written any VB). I don't want to have to distribute VB runtime with the app if at all possible. If this is the case then I'd probably look at VC++.

So my questions:
1. Does a VB app (non .NET, lets say VB6) still need to have runtime files on the computer.
2. Are these files installed by default with:
2.1 Windows XP
2.2 Windows Vista
2.3 Windows 2000

Thanks,
EC.

1) Yes
2.1) Yes
2.2) Yes..but....
2.3) I'm not sure

Keep in mind that MS no longer supports VB6. They are under no obligation to distribute the VB6 runtime files... It's possible that the next version will not include the RT files... and it's very much possible that that version may not even allow the vbRT to run.

-tg

Thanks. I'm not familiar with .NET.

What I need to do is develop a program (progA) which uses an ActiveX UI component. Was thinking of developing progA in C++ or VB. progA needs to be called from another program (progB) which is not a .NET app. I assumed the easiest way to do this would be to create a stand-alone exe application and shell to it from progB. Yes progA could do a DLL but easier with a separate exe, I think.

So perhaps progA could be .NET as long as progB can shell to it? But then don't I need to be sure that .NET runtime is installed?

vb6 runtime is installed on every microsoft OS since 98 osr2.
vb5 runtime is installed on vb95 and 98.
Based on this it is possible that vb6 runtimes won't be installed on a newer OS since vb.net is the new standard. However if they ever block them from running, they will be breaking a LOT of programs because vc6 has a runtime as well, and if they block one they will block the other too.

You can't count on the correct VB runtimes being install even if they come with the OS (except Vista for now). Some people who don't know what they are doing will create an installation with the wrong runtime files and forcibly install them. If this is the case if you do not install the correct ones with your app it may not work correctly. If everyone did it correctly you would not have to worry... but they DON"T!!! So you should always include them so you do not have to make excuses on why your app isn't working correctly... Of course unless you just like making excuses...

I like for my apps to work 100% of the time 99% or less isn't good enough for me...

Please read Installation Problems for more assistance on this

Quote:

---

Keep in mind that MS no longer supports VB6. They are under no obligation to distribute the VB6 runtime files... It's possible that the next version will not include the RT files... and it's very much possible that that version may not even allow the vbRT to run.

---

None of this is true. The IDE goes unsupported in April 2008 but programs are supported for the life of Windows Vista, and this appears to be true for Windows 2008 Server as well though I've seen no statement from Microsoft.

Support Statement for Visual Basic 6.0 on Windows® Vista™

Quote:

---

You can't count on the correct VB runtimes being install even if they come with the OS (except Vista for now).

---

Balderdash!

The VB6 runtimes have been protected system files since Win2K, if not Me. Of course this may limit you because the shipped runtimes were ~ SP 2 levels in Win2K Gold (SP3 in XP Gold?).

It is true that you really want the SP6 (or later, i.e. Vista) VB6 runtimes though. Then there are the MDAC level issues, ...


Vista and VB6

Vista is actually a better VB6 platform than XP is, for a number of reasons. Of course the UAC and AppCompat headaches can be nasty if you haven't written your programs to fit the Win2K, XP, and Vista guidelines - which Vista now enforces.

If you could limit your target OSs to XP SP2, Vista, and Win 2008 you'd have some nice options. For one thing most of the important system components are about as new as they'll ever get - and already installed. For another you can use SxS Isolation on those OSs for applications that only use in-process component libraries (even XP SP1 if you avoid most non-intrinsic controls).

But of course for that you need to use 3rd party tools, since even though SxS is a Win32 technology (and not a .Net technology) Microsoft offers nothing for the VB6er and darned little for the C++ programmer.

Isolated Applications and Side-by-side Assemblies

And you really need the VB6 SP6 runtime components for Isolated Applications in VB6. One of its "fixes" was an enhancement to provide controls support for SxS. Of course you can isolate those files too.

The VS 2005 SxS Interop features are broken! VS 2005 doesn't know how to isolate VB6 controls in general, it's working off an obsolete Manifest File Schema for one thing. VS 2005 SP1 did fix one bug though, and I suspect VS 2008 addresses the other big flaw.


But we're quite happy with the results we've gotten with XCopy deployment of VB6 applications to Vista and XP SP 2.

Oh what a good discussion. :)

Vista does ship with some vb 6 runtime and support controls but not all. These unsupported controls are common and if you dont distribute all necessary dependancies for your app then you will eventually fail.

Sure you can say that the vb 6 runtimes are supported but only very basic programs written in vb6 will use just the msvbvm60.dll dependancy. No respectable programmer or software company will write apps like this.

Winsxs is only fully supported on XP and above. Why would you say that the sxs manifest system is obsolite if you praise it as being the best yet on Vista? Sxs is great and ever evolving so dont look for it to be phased out anytime soon at all.

Most programmers puke and state that Vista "sucks" but they just dont understand it and how its newer technology works.

Vista ships with all 4 .NET Framework versions so if you wanted to write a portable app then .NET is more feasible then VB 6 hands down.

Quote:

---

Winsxs is only fully supported on XP and above. Why would you say that the sxs manifest system is obsolite if you praise it as being the best yet on Vista? Sxs is great and ever evolving so dont look for it to be phased out anytime soon at all.

---

SxS is great, and only gets better on Vista. SxS makes it easy to distribute those other dependencies, and of course you'll want and need to do so.

VS 2005 is what's broken! Be careful trying to use it for creating VB6 Reg-Free COM manifests.

VS 05 works great, much better then 03. Are you saying just on using interop to provide backwards support/use of vb6 controls in .NET?

Yes, VS 2005 is ignorant about VB6 controls, many of which (even 3rd party and MS controls done in C++) require various miscStatusXXX attribute values. This isn't even in the latest Manifest XSD Microsoft has published.

See KB 828629.

There are lots of little gotchas like this. We just keep adding remediations to our VB6 XCopy packaging tool.

Well I would expect the issue like that in regards to vb 6 controls in .net. Backwards compatibility, IMO, shouldnt have been even provided in .NET for VB 6 at all. This just keeps the stubborn VB6ers hanging on to their VB 6 programs for yet another 5 years or so. They are really missing out on the benefits of .NET altogether.

Benefits or no, it was really pretty much a no-brainer to allow Interop.

Do you realize how much of the BCL is just wrappers on COM libraries anyway? They're not even straight Win32 calls!

.Net is pretty limited if you were to strip COM out of the OS. That's where a lot of the work left in Mono is - replacing stuff .Net uses COM for.

From a marketing standpoint is is a "brainer" :D but how they decided to wrap it all up as best for the language may be beyond us as Im sure they have a good reason(s) for doing so on the ones they wrapped.

Ps, maybe Bill was in a holiday giving mood :lol:

Quote:

---

Originally Posted by dilettante

Balderdash!

The VB6 runtimes have been protected system files since Win2K

---

If this is true how do you explain what is in my article Installation Problems Notably the part about Access 97. If your statement were true then I could not do what I did. My expertise is by ACTUALLY doing the research and reporting what I have found not by repeating what someone else claims...

And if they are so protected how do you explain the Mis-Matched Runtime dll message in PDW???

if by "protected" he means "they came in the system folder' then perhaps...

Quote:

---

Originally Posted by RobDog888

Well I would expect the issue like that in regards to vb 6 controls in .net. Backwards compatibility, IMO, shouldnt have been even provided in .NET for VB 6 at all. This just keeps the stubborn VB6ers hanging on to their VB 6 programs for yet another 5 years or so. They are really missing out on the benefits of .NET altogether.

---

Without interop.... we wouldn't be moving to .NET.... We've got a 10yr old app that jsut simply cannot be converted to .NET overnight (try as we might, it jsut ain't happening) - which means while our application framework moves to .NET, the screens, controls, and DLLs will migrate slowly.... which is only possible because of interop...

So are we missing out? Or taking advantage of a feature of .NET? Granted, we don't get the advantages of .NET in our VB6 objects... but when you've got a system as massive as this.... it's going to take time. If .NET wouldn't/couldn't allow us to run our VB6 components in it.... we wouldn't be migrating and I'd be polishing my resume.

-tg

Quote:

---

If this is true how do you explain what is in my article Installation Problems

---

You have some good advice there, but some of it is a little rough. Software deployment contains lots of pitfalls.

Over time Microsoft has documented many of these, such as PRB: Your Computer Does Not Restart After You Install a Microsoft Visual Basic 6.0 Application That Includes a MSVCRT.dll File. This particular case is a very old issue, and you're supposed to know not to deploy VC++ runtimes. System File Protection addresses this for supported OSs (unless somebody turns it off), but you can also add such DLLs to the PDW VB6DEP.ini file's [Do Not Redistribute] section.

PDW itself is fine, and still works as well as any other legacy installer system as long as you have the latest VB 6 service pack installed and either use it with your eyes open (it gives you the chance to exclude items from your Setup package) or update things like its exclusion lists. The biggest problem is, people often fail to read the instructions and follow them! This includes creating proper DEP files for your own component libraries and making sure you update others when you install updated libraries. And yes, PDW works fine on Vista.

Best practices for deploying Visual Basic 6.0 applications is a good place to start reading.

Quote:

---

When installing on Vista it is very much different than installing on previous Windows versions. One main difference is writing to the registry. Many locations are basically off limits and Vista will perform "Registry Virtualizaion" which means that some registry information that used to go to the registry will now go to your profile on disk.

---

True if your program doesn't have a proper Vista manifest and follow the rules to avoid writing to protected Registry locations. Virtualization happens when your program runs afoul of Vista AppCompat.

Quote:

---

The most common area to install your app in Vista is "C:\Users\Public" or "C:\Users\YourAppName" There are no restrictions to your app in these locations.

---

This is some of the worst advice I've seen. It defeats the protections in Vista that prevent malware from replacing parts of your program with trojan horses and such. Never do this.

The proper solution is to install writable files in the proper per-machine or per-user application data folders as appropriate. These can be located using calls to system functions provided for the purpose.

Quote:

---

Also when deploying MS Scripting Runtime (scrrun.dll) then whole MS Scripting Runtime system should be deployed not just the one dll.

---

Wrong again... or maybe right? Hard to tell what you're trying to suggest people do. DO NOT distribute the Scripting Runtime DLLs! BUG: Distribution of Microsoft Scripting Runtime Library Fails. As stated there, there is a proper way to install Scripting. Perhaps you could add a link to that KB article?


The safest deployments are those based on SxS Isolation. Sadly the PDW is little help here and it isn't available on older systems.

You do realize that if you install to "Program Files" and don't have administrator rights you can not write to the apps installed folder??? So, any legacy apps you suggest to run "As Administrator"? This would leave your whole system open to viruses. At least a limited user could run the legacy apps and if a virus did infiltrate the system it would not have run of the entire system.

But then again that is what virus protection is for...

BTW: You mis-read the Scripting Runtime. it clearly states that you need to deploy the scripting runtime installation... and there are two different ones...

Instead of telling people they are supposed to know (Since beginners rarely know much about these things) the documents I provide actually helps them solve these and other types of problems.

Installing on Vista, apps should install to the per user folder "C:\Users\UserName\AppData".

@TG, yes you do have a point there that I guess will be good for transitioning.

Quote:

---

Installing on Vista, apps should install to the per user folder "C:\Users\UserName\AppData".

---

This is incorrect. It exposes the user's system to the risk that malware may overwrite or alter any programs (EXE, DLL, PCX, and even BAT, CMD, VBS or JS files) with some attack software. When they run your application later, it fires off a load of spam email or worse!

Windows Vista Application Development Requirements for User Account Control Compatibility clearly states:

Quote:

---

Install applications and store per-user data in different locations.
Applications should be installed in a folder under the Programs Files directory. To configure this, you can use the ProgramFilesFolder property in the Directory table of your Windows Installer package, Per-user configuration data should be stored in files either under the \Users\username\AppData directory or in registry keys under the HKCU root. User data, templates, and application-created files all have proper locations in the \Users\username subdirectory. Although this was not enforced in the past, since many users would run programs with a full administrator access token, applications that do not place information in the correct location are likely to fail. This is especially true when virtualization is turned off.

---

The whole point is that "Program Files" is protected against writing so that executable code can't be overwritten!

The VB6 PDW can be a little "handicapped" in this regard if you intend to deploy INI, XML, MDB, etc. data with your program that needs to be updated as it is used. The usual "fix" if you use PDW Setups on a Vista target machine is to have your program look for the files in the correct place when it runs, and if it doesn't find them look in "Program Files" for install-copies placed there alongside your EXE by the PDW Setup - and then copy those files to the correct location. A sort of "first run" activity.

This isn't a great solution for programs that install very large data files. But you always have the option of using a more Vista-aware installer techology than PDW for those cases. Even VSI 1.1 can be told to build an MSI package that puts the data files into a "special folders" location. Worst case you use Orca on the MSI package.


I tend to use a little internal Class that I have a few versions of. You just add the CLS file to any new project, and it provides a global-namespace AppData object with methods Path() and OSVersion() to make it easy to use the special folders in your VB6 programs.

Writing:

Code:

---

strINI = AppInfo.Path(aipAppData) & "\" & App.CompanyName & "\myprog.ini"

---

.. or:

Code:

---

strINI = AppInfo.Path(aipAppDataCommon) & "\" & App.CompanyName & "\myprog.ini"

---

... is hardly much more work than:

Code:

---

strINI = App.Path & "\" & App.CompanyName & "\myprog.ini"

---

I'm sure you've written something like this yourself.

Quote:

---

Instead of telling people they are supposed to know (Since beginners rarely know much about these things) the documents I provide actually helps them solve these and other types of problems.

---

Great work, keep it up! The Windows ecosystem has gotten a lot more difficult for beginners since VB6 was new, and they need all the help they can get.

Perhaps when you have the time you can be more explicit about exactly what they need to do. Links to KB articles describing some of the pitfalls couldn't hurt either, or at least list the KB numbers so they can Google them.

Things are going to get tougher, I don't think Microsoft cares much about the sort of beginners you're trying to help. The same Word document I liked to above says:

Quote:

---

Note
In future releases, the ONLY way to run an application elevated will be to have a signed manifest that identifies the privilege level the application needs.

---

And you think we have it tough now? Gee, thanks Microsoft!

All the more reason to install things right in the first place. C:\Users\UserName\AppData is not it. I won't be surprised to see a Vista Service Pack that includes a Service (a Defender update) that scans these directories and moves any EXE, DLL, etc. it finds there off to some virtualized location under "Program Files" or somewhere.

You do realize that in many settings the AppData folder isn't on the C: drive at all nor under C:\Users\UserName\, right? AppData is a "roaming profile" location, and could be off on some file server or relocated elsewhere on the machine. This might work great on your machine but if you expect others to install and use it you might want to be more careful.

AppDataLocal might be a better choice, but still a poor place to put code.