Re: No need to distribute VB runtime files?

None of this is needed. I myself am a longtime VB6 developer and have a full Installer program developed with VB6 that is semi-widely distributed.

Here's the facts:

VB6 runtime IS installed BY THE OS on ME, 2000, XP, 2003, Vista
It also is installed by SP4 and greater for NT 4.0, which ANYONE running NT4 is going to have.

That leaves 95 and 98 which might not have the runtime. But most will as it has likely been installed by some other program in the past. I have conducted several studies on this over the years. Based on my June 2007 stats, if you do NOT include the runtime, you will have about 1-2% of total users that can't run your program if you don't include the runtime. Those users will be 95/98 users primarily.

You do NOT need to distribute the runtime to an OS that already has the runtime. If you really want to ensure that 100% of your users can use your program, go ahead. But you don't need to and quite frankly in this day and age really isn't needed anymore. Also as noted by another poster, you should definitely avoid distributing on Vista, although in my testing Vista seems to protect its VB runtime quite well - I have seen no issues with this.

This lack of need to distribute the VB runtime is now one of VB6's great strengths as compared to .Net (despite what some ill-informed people think). While the .NET framework already comes in 3 different flavors (not even counting the 32-bit vs. 64-bit flavors and v3.0) and varying depending on OS, SP, etc., the *1* VB6 runtime is ALREADY installed on basically everything from 2000/ME forward and most machines before that as well.

By the way, my installer is called SSE Setup (www.ssesetup.com). The last release is almost a year old now, but a MAJOR (and I mean MAJOR) update is coming soon. I have many VB6 developers that use it as their installer. (don't think I'm trying to bash Inno Setup though because I'm not - I do like Inno Setup).

Edit: Posts split from thread http://vbforums.com/showthread.php?t=491859 in order to preserve the original thread as we are on a new variation of the topic. ;)

All those OS's do NOT already have the VB runtime files installed. You may have mistaken for another program installing them prior to you checking. This can be verified by doing a complete OS install then checking for these files. You will see that they do not exist.

You can never rely upon a system having the runtimes installed by some other program. ;) Besides, what if they dont have all the components that your app uses or an older version? :D

I'm sorry Randem, but you are wrong. I do have all of those OS's except for ME & 2003 (both of which I have also verified do install the runtime). I routinely test on the OS's going back to Win95 for my Setup program and frequently reformat and start over for the testing of my Setup program (I literally have a row of test machines). All Win OS's from Windows ME/2000 forward DO have the VB6 runtime installed with the OS. And SP4+ for NT4. Further all of this information is publicly available on the Net (though admittedly there is a lot of conflicting info out there, but even MS's DLL database - which no longer covers ME - does show it installed for 2000+).

To RobDog - no you can't trust to other programs. But you can reasonably trust what is installed with the OS. Every once in a while some oddball might have corrupted their OS installed VB runtime - but this is EXTREMELY rare. My program is a common VB6-made installation program. Do you know how many times I have heard of a problem for lack of VB6 runtime? Once or twice. That's in over 3 1/2 years. This is a non-issue these days. The only people it matters for are 95/98 folks, but WHO is targetting solely to them these days??? Nobody. And there ARE many programs and updates that have/do install the runtime for them (including Office 2000, MS Works, LOADS of 3rd party programs, etc.). So yes, the reality is this is a practical non-issue for anybody wishing to create and deploy a VB6 program across all 32-bit Windows OS's.

There is so much misinformation out there about all of this. I've read some of it on this site. I am a setup developer who has devoted probably a billion hours by now (obviously an exaggeration) over several years to my VB6 created Setup program which many developers use. I know the ins and outs pretty well now of what works and what doesn't and what's an issue and what's not. The VB6 runtime is a practical non-issue.

That doesn't mean that if you really want to heavily target the 95/98 crowd, that you might not want to have it installed anyway. My Setup program does allow to have the runtime distributed and installed automatically for instance. If you really could care less about the extra 1MB size, then if properly deployed, there's no harm to installing it and it does help to "ensure" that everything will be ok. There's nothing wrong with a little extra "safety net". But that's all it really is.

Since you are NEW here you obviously think that you alone do these sorts of things... You are so wrong... All you have to do is do a search....

Perhaps you would like to read this Installation Problems

VB 6 runtimes are not part of the OS and if you reformat / clean install you will see this. If they were included with the OS then they would get updated via Windows Updates etc and have no need for a Redistributable Runtime package that MS does put out.

I never once said I was the only one that did these things. But I am highly qualified to know about this since I have an actual VB created installer (not just for me - but an actual installer platform used by developers worldwide). You are using Inno Setup. A great installer. But Inno Setup is not a VB-created installer. I have had to work through MANY issues in getting the VB installer to work right, etc. This runtime nonsense is one of the biggest points where people are very confused about and sometimes don't even know it.

I was correcting misinformation. I only joined to correct that misinformation. I never attacked you personally. I merely corrected/clarified misinformation for the person who asked the question. And yes I'm "new" because I joined specifically for this thread.

You stated that I was wrong about the VB runtime being on those OS's. You were wrong. It is. I'm sorry if that bothers your ego. Get over it. I don't think I know everything. I'm always learning. But I do know about this. I do know what OS's the VB runtime is on and I do know it is a non-issue. I know this because of my high-level experience with it and constant testing in regards to it on numerous test machines. I can't tell you the countless reformats and testings from scratch I've done with my Setup program on various Win OS's to get my Setup program working right on all of them.

The question on this page is about the VB runtime files - period. The person was asking whether he needed to include them. The correct answer is no he does not because they are installed on all Win OS's except 95/98 - so it is not necessary unless they really want to ensure support for the relatively small number of 95/98 users in the world today that won't have the runtime.

Your page on installer problems addresses a number of issues, some of which are valid. Various DLL issues and things with MDAC, etc. can be big problems. But in regards to the actual VB Runtime ITSELF (msvbvm60.dll and supporting files installed via the 1MB redistributable package), it is not an issue any more. It used to in 1999. I remember it well. That's because in 1999 a lot of people didn't have it. It was a pain in the butt. Every OS since Windows 2000 released in 1999 though has the runtime installed with the OS. It isn't just Vista. It's everything in the last 8 years. That's substantially better coverage than the various flavors of .NET (where XP might have 1.0, 1.1, and/or 2.0, Vista has 3.0, 2000 might have 1.1, 2003 x64 might have 2.0 x64 or 2.0 x86, etc.)

The point I was making randem is that I have a VB installer which by default (and recommended operation) is not to include the runtime. I have developers of all types of languages (.Net, Delphi, C++, etc.) using my installer. If there were issues with the VB runtime, I would be hearing constantly from all the developers that use it about how their customers were complaining about problems installing, etc. I know because I've had this happen in the past with other issues. This has never been a problem in 3 1/2 years.

So, I'm sorry if you felt I knew it all. I don't. But I do know about this issue. I joined to help spread information about this since there is so much misinformation around. Hopefully it might help somebody in the future that looks at this thread. I do apologize if I came off brash - that was not the best 'netiquette on my part.

I'm done responding to this issue and won't do so any more. How's about we both just drop it - future people reading the thread can read and decide for themselves.

I do appreciate your willingness to help people and I meant no disrespect to you. :)

Yes, they are RobDog. You are wrong.

Go ahead and clean install any of the following:
ME
2000
XP
2003
Vista

You will find the VB6 runtime there once installed.

Since you seem to be very hardheaded about this, here's an MS site to at least partially PROVE it:

http://support.microsoft.com/dllhelp/

Click to search by file only and enter MSVBVM60.dll into the search box. MSVBVM60.dll is the main VB6 runtime file. It will bring up numerous versions of the file. Click the more info button on each unique version to see all the things it's been installed with. The DLL Help site is not complete in that it doesn't show files installed on 9x/ME anymore (it used to) so you won't see ME in the list. It also doesn't show Vista. But it is on both ME and Vista (there's a separate MS article proving its on Vista - feel free to google it). You will however find 2000, XP, and 2003 in the list (as well as some other MS things it has been installed with)

You are operating out of ignorance RobDog. The redistributable is to install the LATEST Service Pack version of the runtime, which is at SP6 (and has been since 2004). However, Windows 2000 - which is the oldest OS of the ones that have the runtime - older than ME - included SP2 of the runtime.

If a VB program encounters specific problems that were fixed in SP3 or greater, then one might want to place a much higher priority on ensuring the runtime is the latest.

As I said to randem, I won't reply any more on this. I've provided you the proof - I've told you that you are wrong as someone that has high-level experience with this. If you want to stick your head in the sand and keep saying I am wrong, you can do so. I really don't care.

Id have to ask if this is for all of us?

Quote:

---

Originally Posted by chrislong2

I do apologize if I came off brash - that was not the best 'netiquette on my part.

---

But yes you are coming off that way a bit ;)

Anyways,...

As I have posted ...

Quote:

---

Originally Posted by RobDog888

You always have to distribute runtime files as there is no guarentee that a system will have everything your app requires.

---

and ...

Quote:

---

Originally Posted by RobDog888

You can never rely upon a system having the runtimes installed by some other program. Besides, what if they dont have all the components that your app uses or an older version?

---

and as shown by the actual MS dllhelp page ...
http://support.microsoft.com/dllhelp...=55&fid=204993
http://support.microsoft.com/dllhelp...l=55&fid=42247

Where does it show that other non-core vb 6 runtime files are included?
you cant run a half decent program written in VB 6 without having some amount of dependancy runtime files not included in an OS or OS SP.

As shown by this link a basic windows common controls ocx is not included on XP or XP SP-2.
http://support.microsoft.com/dllhelp...+&S=1&x=8&y=16
http://support.microsoft.com/dllhelp...+&S=1&x=5&y=10


Hence my statements quoted earlier.

Later.

Yes RobDog888, I agree. Some will just never learn...

The Runtime files that came with the OS are not sufficient hense is why MS released the VB Runtime SP 6. The one that will run on every OS not just some of them.

Hmmm, I guess that is why PDW get's that annoying message about the runtime files being out of date... Since they are all the same eh???:p :p :p

I wonder why MS needed to release 6 SP's when all the files are the same ;)

I also wonder why MS included this note if all the runtime files from all the OS's were the same???

• As a troubleshooting step when an installation of Visual Basic or a Visual Basic application fails

If Setup fails with an error message that mentions one of the core files or if registration of a component fails during Setup, the core files on the target computer might be mismatched. If the versions of the files in the VBRun60.exe file are newer than the versions on the target computer, you might resolve the problem by running the VBRun60.exe file before you run Setup.

And then again for SP6

• As a troubleshooting step when an installation of Visual Basic or a Visual Basic application fails.

If Setup fails with an error message that mentions one of the core files, or if registration of a component fails during Setup, the core files on the target computer might be mismatched. If the versions of the files in the VBRun60sp6.exe file are newer than the versions on the target computer, you might resolve the problem by running the VBRun60sp6.exe file before you run Setup.

I said I wouldn't reply. I won't address randem, but I will address you RobDog. The answer to your question is there is a difference between the RUNTIME and other external support files. You are correct that a decent VB program will probably rely on external components. THOSE you may very well want to distribute. But that is not the "runtime". The "runtime" is collectively known as msvbvm60.dll (this is the main runtime) and a few other supporting DLL's. The runtime is what is required to run a VB program "out of the box" as it were. This is what is installed on 2000/ME and greater and NT4 SP4+. Other dependencies (mscomctl, mscomdlg, msinet, MDAC, etc. etc.) all have to be taken on a case-by-case basis and may need to be distributed depending on what the component is and what your target OS's are, etc. Generally you do want to include your external components.

As to your 2nd MS-note: That is talking about the ORIGINAL VBRun60.exe runtime redistributable. That note was correct....for 1998. It still COULD be applicable if your program makes use of problems that may have been fixed in a later service pack. For instance as I said earlier, if your VB6 program REQUIRES one of the fixes made to SP3 or greater, you may want to distribute. But otherwise it is no longer valid. Most VB6 programs will still run fine with the original (non-service-packed) runtime from 1998! I never said that all the OS's files were the same. I said that ME/2000+ have the runtime. They do. They are not the same version necessarily. But they all should be at least SP2 or greater (and most SP3 or greater).

By the way, just for completeness info on this topic, I've included the relevant info out of my SSE Setup help file on this topic below:

VB Runtime Include

SSE Setup REQUIRES the VB6 runtime support files to run. Windows NT 4.0 (SP4+), ME, 2000, XP, 2003, and Vista already have them installed with the OS. Many (but not all) Windows 95 and 98 users also have them already because other programs or updates installed them. It is very common.

So as you can see, this is almost completely a non-issue. As of June 2007, only about 4% of Windows users are even still using 95 or 98. I would estimate that out of this 4%, 3% have the runtime, leaving only about 1% of people which cannot run the installation unless you include the support to do so. The added file size to include this support is about 1MB. It is your choice to include or not. Optionally you can create 2 different versions for each of the package types you select, one which has it in it and one which doesn't. In this way you can provide 2 separate packages: 1 for Win95/98/NT4 users and 1 for everyone else.

My personal recommendation would be to not include the runtime and just run the risk that about 1% of people can't run the install. (even if the install won't run, they will receive a generic error message about MSVBVM60.dll - which they can then search on the Net for and then download the runtime)

In the interest of disclosure, but again something that really doesn't matter: Users running a brand new, fresh installation of Win95, 98 original (but not SE) or NT4 may receive an "oleaut32.dll out of date" error message that will prevent installation. There are MANY updates/programs (including IE5+, Office 2000+, DCOM95/98, service packs & hotfixes, other programs, etc.) which fix this problem, which is why this only really affects brand new, fresh installations of these OS's. If you have included the runtime, even though they will still receive this error, if the user reboots their computer and tries again, it will then work. Assuming you are creating an install package that is targeted at all Windows platforms, I estimate that this error msg would only occur with about point 2 percent (.2%) of users.

I think we are all saying the same thing different ways here.

The basic runtime msvbvm60.dll is on the systems but that is not what is really needed to run a basic program. So whats the use of not including that one single file? You have to have an installer anyways regardless of that. I dont think there is a decent program that anyone would install that only used the msvbvm60.dll anyways. ;)

The VB "runtimes" are pural so its not just isolated to the single virtual machine dll but several core vb dll/ocx's. This is the main issue and why its so important to not depend on only the msvbvm60 being present.

Quote:

---

Originally Posted by chrislong2

I said that ME/2000+ have the runtime. They do.

---

I have to disagree there.. I have deployed to many versions of Windows, and found that some versions of Windows 2000 do not contain the runtime at all.

I agree that these days most people will have it, but it is certainly not guaranteed - and even if you don't have 'known' issues that require the latest SP version, I would recommend distributing it anyway, as we have seen many cases on the forums where simply doing that has fixed bugs.

Yes Si,

The fact that there are many different versions of Windows and so have it and some don't. To be a PROFESSIONAL one has to account for any and all conditions not just the ones that they like...

To NOT deploy the VB runtime files is Like telling your clients I don't care what you have on your system MY app is suppose to work with what windows allegedly came with. It doesn't matter that someone else who obviously doesn't know squat about the VB runtime file deployed the wrong ones. I wont correct that problem and you are on your own.

It is totally irresponsible and not professional...

Of course that is the main reason I developed the Automatic OS Updater to account for those non professionals who take that approach and think they know everything.

And that is why I get those mismatched messaged 0% of the time and the app works 100% of the time.

Occam's Razor...

Well, I guess each person can just decide what they want to do.

For me, I don't include it. And that has worked fine for my 3 main VB apps (including my installer) for several years now. I have rarely had a problem. And I'm not about to change that when it is not needed. See, I don't mind leaving out the occasional oddball that doesn't have it. And that's exactly what my experience has shown it to be: An extremely rare occurrence. My setup program is ironclad proof of this in my book. I have clients that have been using it for years. I have heard of all sorts of installation-related issues from their users which I've had to look into. This is not one of them!

If someone else here has had deployment issues where it hasn't existed, etc. then go for it if you want. We are after all only talking 1MB (not the large .NET runtime). And 1MB certainly means a lot less in today's terms then it did in 1998 too. :)

To Robdog: There are many programs that use additional components, but there are also plenty that are not or are system API driven. My Setup program I have purposefully created without these dependencies. Therefore it doesn't use them and Setup needs nothing but the runtime to run. I have 2 other programs - a backup program and text editor, both of which do have additional dependencies. And both of which ship with them. But those dependencies are not the same as the runtime. They're "in addition" to it.

I also have a Win95/98-only targetted program which I DO include the runtime for since it is only targetted at 95/98, the 2 platforms which have a much higher chance of not having the runtime.

Since there seems to some confusion on to what constitutes the "VB6 runtime" here it is:

The actual runtime itself IS a single file. It is msvbvm60.dll.
However, IT depends on a few other files being installed and proper versions. So that is why MS's runtime redistributable pack also contains a few other files. This includes oleaut32.dll, olepro32.dll, asycfilt.dll, comcat.dll, and stdole2.tlb. They can collectively be called "the runtime". These are all installed on ME/2000+.

Many VB developers in the past (and unfortunately a few still to this day) when deploying the runtime had/have a nasty habit of not using the redistributable but only deploying msvbvm60.dll. That CAN work and probably WILL in most cases, but it may not as depending on the system the inconsistent versions between msvbvm60 and those other files (especially oleaut32) could potentially cause problems. But I haven't seen this kind of issue in a long time now, either.

I guess that's about all I can say on the matter. If you want to make a VB6 program and distribute with the runtime, go for it. If you want to ensure that 100% of your target audience can run your program, do it. If you want to ensure that any possible problems are solved by including the latest runtime, do it. If, like me, you don't care about the very small amount that can't run it and your program runs fine on SP2 or earlier (most will), don't. 1MB's not a big deal any more but it's still another MB that must be downloaded...and one thing my site stats have shown me is that people STILL care about size and the larger the program, there's still a decent amount of people that will cancel the download if it's too large for their tastes.

Quote:

---

If you want to ensure that 100% of your target audience can run your program, do it. If you want to ensure that any possible problems are solved by including the latest runtime, do it.

---

This is a requirement if you want your app to be professional, business related or not, period.

Yes, you can write an app that is derived from sstem APIs, I have done it too, that requires nothing more then the msvbvm60.dll but its allot of work especially if you are rewritting controls that are in the comctl and comct2 ocx's. Its just so much easier to add those "runtime" files as only a handful of developers write apps without using them. This is the main issue that allot of people post about when stating "runtimes" as its plural and not just a single file. The ocx's are an essential part of application development now a days.

I can see I'm dealing with people that don't understand even basic programming terms and aren't willing to learn either.

OCX's are not the VB runtime.

The VB runtime is the VB runtime. THAT is what the question was about. Not other dependencies.

My post and info was about the VB runtime. Not other OCX's. I've already stated that I include other dependencies. That has NOTHING to do with whether one should distribute the VB runtime. The runtime is the runtime is the runtime. It's not anything else.

In your world, if you want to call the VB6 runtime anything your program requires, you can, but you'll be alone in that world (with maybe some other ill-informed people like randem) to keep you company, I don't know. But you certainly won't have company with developers that actually know better.

Further, you had no place to move the comments as they were directly related to the issue that was posted about the VB RUNTIME. My comments were directed at that issue and you instead have moved them separate.

Personally what scares me is that I periodically frequent forums such as this to get answers to things that I don't know. It scares me a lot that there are people like you and randem who give answers to things with such forcefulness when you don't know anything about them. I'm not saying this is the case with any other issues (I have no basis to levy such an attack), but if it can happen with this one it can happen with any of them. THAT scares me as I, like most developers, rely on the spread of developer information (such as I was trying to provide for others but was "shot down" by people that don't know anything about it)

In any event, I've been successfully "run off" of this forum. I've provided the correct information. If you and randem and anyone else want to keep your head in the sand about it, okay. If you want to delete this post or move it because it offends your ego's, okay (I have no control over it do I???)

In any event, you don't need to worry about me posting any more. I joined specifically to provide the correct information to that question. Rather then being welcomed and thanked for the information that obviously you and randem didn't know (runtime included on all OS's in the last 8 years), you/randem instead came at me with guns drawn telling me that I was wrong. When I was NOT. Major ego's going on here. And I don't want any part of it.

I don't need you or randem to validate for me what I already know. I have a successful VB6 product which is used by many developers around the world which does NOT distribute the runtime and works correctly on 99% of machines in today's world. This is a fact and one which I have closely monitored.

I thought the "misinformation" on this topic was just due to ignorance but that once shown differently, the correct information would be accepted. That is not the case. Obviously, the spread of correct information is secondary to people defending indefensible positions (and thus their pride and ego's). I don't have any desire to be involved in such "power struggles" in the future and thus as said, I won't reply and/or post any more in the future. (I should have just done this when I said I would earlier - that is MY fault)

Despite my "tough talk" above - I do not wish you or randem or anyone else ill and I HOPE that perhaps it will be taken to heart.

Chris

Man what a bunch of noise for such a tiny file. Why don't you all just switch to .NET, then you don't have to argue about it, because it is clear that the runtime won't be installed on all OS's. No more argument.

As for the VB6 virtual machine. It's such a tiny thing that you might as well include it in any package. Compared to the .NET runtime, those few megs isn't worth even thinking about.

Don't waste time arguing over that tiny problem, MS is entirely capable of replacing it with a much BIGGER issue to argue over.....and they have.

Quote:

---

Further, you had no place to move the comments as they were directly related to the issue that was posted about the VB RUNTIME. My comments were directed at that issue and you instead have moved them separate.

---

Since you are new here you obviously dont see how the thread was actually resolved in last post by the thread starter, something like post #7 or #8 was it.

With all the off topic discussion about the theory/logic of distributing the "runtimes" its our policy to split the off topic posts to a new separate thread where the discussion can continue on and be about the point being discussed.

The original poster was having issues deploying more then just the single vb virtual machine file so everything after that is not appropriate for that thread and warrented one of its own instead of deleting them. ;)


Well like you have posted before, you have come off with a big ego and rude to match. I take no offense as you have your opinion as well as others do either for or against the point being made about redistributing several dependancy files, which is what we were discussing, vs what you wee discussing, a single file.

@chrislong2:

a little off topic - you probably typed more characters in this single thread than most of us in three-four years. ;)