When will VB6 be Unable to Run Under Windows

[gibra]

That statement could actually be misunderstood by people who accomplished and run
a working VB6-installation on Vista up to Win10, but didn't use your Installer to do so...

A clear statement from you, what those people would have to do in *addition*
(on their "normal" VB6-installation), to be able to safely run the IDE non-elevated
would be nice, to not mislead them into thinking that this switch is not necessary.

Olaf

The issue is complex because it involves many factors that are not always easily understood by a developer that does not mean these things.
Especially when 'transmitted' via web, they may be even less clear.

For a correct installation, also require to edit manuallly some files. It is not so easy to explain, and even less to make it clear. There is a study, behind all this.

There are many 'guides' in the web that indicate how.
More or less, these guides give correct information, but these indications were valid at that time.
For example, since its release Windows 10 TP, I already have done three updates to my wizard (the latest 4.3 version just yesterday).
Unfortunately MS likes to change the rules: from version to version, from build to build, so the problem is not 'how to' but became 'how do IF ...'

The IF is for:
- Windows version
- Version of VB: From Visual Studio 6.0 or from Visual Basic 6.0 distribution ?
- Edition of VB: Professional or Enterprise ?
The combinations are different, each with different problems!

Moreover, not all distributions of VS/VB seem to be exactly alike, can also be different from the localized language.
For example, on some distributions, the MSDN Library CD folders structure of Italian language is different of English language.

In addition, the Retail version of Visual Studio is different from the MSDN Subscription version:
IE4 folder doesn't exists in Subscription version, so MSJAVA.DLL doesn't need to be copied con C:\Windows (setup run correctly without it).

As you can see, the problems are many and different.

It 'easy to understand that explain all this in a comprehensive manner requires writing a guide long and complex, and here we return to the starting point: those with little or insufficient knowledge of these issues will eventually make just a mess and will be disappointed.

My VS6I Wizard tries to solve all these problems in an automatic and transparent to the user.


When I thought of designing my VS6 Installer wizard, I did it because I was tired (whenever I had to re-install Windows on my PC) than reading a guide (found on the web) to manually change the setup of my Visual Studio 6.0 Enterprise Edition (ITA), the only tool I had created for my personal use.
Next, seeing that many, like me, had increasingly complex problems in installing Visual Basic 6.0 so I decided to make the wizard public (and free), for others to solve the problems that I had to face.

Experts do not need my tools, they already know how to do.
It is the less experienced who find themselves in difficulty, I hope that my tool could be helpful, and, given the number of downloads (over 49.000), it seems to be appreciated.

[Schmidt]

My VS6I Wizard tries to solve all these problems in an automatic and transparent to the user.

I hear you, but was talking specifically only about the problem of the "run as Admin"-necessity
after "normal installs" (which for most users are not a larger problem). This setting seems to be
required for the VB6-IDE, to behave properly in COM-compiling, COM-typelib-reading/registering
and OutOfProcess-COM-Debugging-scenarios (e.g. when working across several running IDE-Instances).

For those scenarios the "run as Admin"-setting is needed (so far ... and you claimed that
your installer makes this switch unnecessary).

Experts do not need my tools, they already know how to do.

Well, I certainly do *not* know exactly (aside from a guess, which would require experimenting
I don't want to invest time into currently, because "running as Admin" is quite "cheap to do" -
and works well enough so far, for most Users).

What I was hoping for, was some explanation from your end, which only relates to the topic
of the "run as Admin"-switch (which is a universal problem, not related to "Professional- or
Enterprise-versions or to "System-versions").
The problem is not related to the dozens of other small problems you mentioned, which crop
up with different VB6-Setup-packages, and different languages on different systems.

So, why not give us at least a hint here, what one has to do to avoid that "run as Admin" switch?

My guesses are that you (whilst running from your elevated Setup) will ensure that:
- the VB6-IDE-related Folders will get proper access-rights set-up (to avoid virtualization)
- certain registry-hives will end up with proper rights, set-up by your installer, to allow VB6.exe access to them even when running un-elevated

And if my guesses are right, then this is not a problem which "differs across VB6-Installation-CDs",
but a universal one (which one could possibly write a simple VBScript - or *.reg-File for).

Could you at least confirm - or deny my above guesses?
Or is there more (when we only talk about the "run as Admin"-necessity)?

Olaf

[gibra]

The fact is that the issue is not so clear and simple.
There isn't a something to say: do so and doesn't have to use Run As ...

If you want to understand with an example, analyze the differences on my two videos:

The 1st video is in English: http://www.youtube.com/watch?v=1tkTb6AYlAg
install Visual Basic 6.0 Enterprise (version of MSDN Subscription)

After installation (minute 8:00 of the video), when I start VB6, appears an error Automation. Then I show that by setting Run As Admin error appears (but the UAC always requires confirmation).
Going forward in the video, you see that I deactivate the Run As Admin, and the error no longer occurs.
Also, to avoid flicker Desktop Composition for Windows 10, I have to set the Compatibility Mode on Vista SP2.

There is a logical explanation for all this? If there is, I do not know.
I can only think that it happened in the registry 'something' that solved the problem.


The 2nd video is in Italian: https://www.youtube.com/watch?v=pF5oyvZ_N6Y
install Visual Studio 6.0 Enterprise (retail version)
Always per minute 8:00 you'll see that VB6 will run with no error, and do not even need to set the compatibility on Vista SP2.

Is there a reason for this difference? I don't know.

The only thing I can think is that the setups distributed by Microsoft are not all equal.
And some updates may change the rules, also.

I.e. A curiosity of MSJAVA.DLL:
1. The SETUP of VB Enterprise ENG (MSDN Subscription) does not require the presence of MSJAVA.DLL
2. In Windows 10 pre-release (TP) the MSJAVA.DLL could be zero length.
3. In Windows 10 (build 10240) the MSJAVA.DLL must be the original one

Again: is there a logical explanation for all this? If there is, I do not know.

[Schmidt]

The fact is that the issue is not so clear and simple.
There isn't a something to say: do so and doesn't have to use Run As ...

So, I guess I'm correct with my assumption, that your elevated running Setup-Process will
- not apply any special rights to certain Registry-Hives
- and will also not apply lowered Access-Rights to the Root-Folder of a VB6-installation

In this case (as your video shows quite clearly) - your setup-process did nothing to solve the
necessity to run the IDE "as Admin".

Your assumption (or suggestion), that after using your Installer, the "running as Admin" setting
would not be necessary anymore, is a wrong one.

The same problem (as it became apparent at the first start of your fresh installed IDE in your vid at 8:00),
still applies - and is just "waiting for the next time you run into it" (which is for example, when you develop,
debug or compile ActiveX-Dlls, or ActiveX-Exes - depending on their "Project-Compatibility or BinComp-Settings" -
or when you use complex ProjectGroups - or try to run two isolated IDE-Instances in a Cross-Process-Debugging-
scenario.

I think it was important, that we established that now for the other readers of this thread:
The "Run as Admin setting is needed!" (when you use the VB6-IDE in more complex scenarios).

The IDE will work without that Admin-setting, when the Project you will start-up will use only
"already existing and stable COM-Interfaces which already have proper entries in the registry"
(e.g. those of the built-in OCX-stack - and typelibs which ship with VB6).
So it's a "less capable-mode" (COM-wise) - but one which still can be useful, e.g. when you want
to test stuff as the already mentioned Ole-Drag&Drop for example.


Olaf

[gibra]

The IDE will work without that Admin-setting, when the Project you will start-up will use only
"already existing and stable COM-Interfaces which already have proper entries in the registry"
(e.g. those of the built-in OCX-stack - and typelibs which ship with VB6).

Honestly I do not understand the meaning of what you write.
VB6 works without any problems. Always.

[Schmidt]

Honestly I do not understand the meaning of what you write.
VB6 works without any problems. Always.

Nope, that simply cannot be, when you consider the following:

1) Why do you think it is necessary, to run e.g. regsvr32.exe elevated (to make it succeed)?
Right, it wants to write to registry-hives which require "Admin-access-rights".

2) Now, keep in mind that the VB6-IDE supports a whole lot of development-modes, as well
. as project-types, where it will need the very same access-rights, to be able to write to
. those (COM-related) registry-hives itself.

I hope you see as clearly as I do, that the point #2 above is not going conform with your:
- "works without any problems. Always."
statement.

Your statement denies the fact, that the VB6-IDE is *dependent* on full access-rights
to certain areas of the registry (to work properly and behave as expected in scenarios,
where it has to register and unregister COM-stuff - sometimes even temporarily).

Olaf