How to ensure successful instantiation of some common classes from system dlls.

[bPrice]

I have a vb6 app that references scrrun.dll, winhttp.dll, and some ActiveX dlls made by myself. Everything is fine when I test the app on my own desktop. But when I send this app to other people, and when they run, sometimes errors will occur - ActiveX Object cannot be created.

I didn't just send them the files but I have a setup program, where all files are packaged together in a setup.exe, and there is script to specifically register *dlls made by myself*. I assume I didn't have to package scrrun.dll and winhttp.dll as well and register them as I did with *my dlls* since they should *come along with the system*?

Registering Dlls will always cause a warning, or even worse, a automatic *kill*, from common anti-virus softwares here. And I really wish I had less dlls to ship with my app.

what to do?

[dilettante]

The winhttp.dll can't be installed into any OS. Where it can run (dead Win2K SP3 and later, dead WinXP SP1 and later, and all supported versions of Windows) it ships as a protected part of the OS.

The scrrun.dll can be installed into dead OSs that did not include it, but only as part of a complete installation of Windows Scripting. However Microsoft no longer offers the required Scripting redistribution packages for these OSs so if you do not have them it is not safe for you to attempt to install scripting into unsupported OSs. It shipped as a protected part of the OS for all supported versions of Windows, and the unsupported XP SP3 added it as a protected part of the OS as well.

Do not use the old redist package that shipped with Visual Studio 6 when it was new. It is full of security bugs and is an old version you don't want anyway. As far as I can tell Microsoft never issued a Scripting merge module, a sure sign that you should not be trying to deploy this as part of an application anyway. 1998 was a long time ago and things changed shortly after that.


You can't just grab system DLLs off one computer and blindly dump them into other computers. In many cases they contain code tailored to work properly in a specific version and service pack level of Windows.


Proper Installer packages and even many legacy scripted setups should run without triggering malware alerts. The same cannot be said about the attempts by contrarians to bypass the proper processes and use "dropper" techniques that tryto hide PE files as resources within programs..

[bPrice]

Dilettante:

OK. Basically I don't have to deploy either winhttp.dll or scrrun.dll with my app. And if errors occur when, i.e. trying to create a Scripting.Dictionary object, it's just because their system is outdated and I shouldn't try to fix the problem.

However, I do see, that some software includes Microsoft.mshtml.dll or excel.dll in their install folder. Mshtml.dll shouldn't be a system DLL?

I used SetupFactory to package my app. I guess it was not outdated as well? Or is there a better and easier option specifically for VB6?

[FunkyDexter]

Moved to deployment section

[dilettante]

However, I do see, that some software includes Microsoft.mshtml.dll or excel.dll in their install folder. Mshtml.dll shouldn't be a system DLL?

Mshtml.dll is part of IE and anyone trying to deploy some random version of it will either be spurned by Windows' self-protection mechanisms or the victim's PC may be trashed (mostly Win9x). Excel.dll is never safe or legal to deploy by itself.

So I don't know what ponds you've been swimming in but I recommend a hot shower and a lot of soap! Hopefully your own PC hasn't been trashed yet. If you are seeing these DLLs you are either dealing with the products of some really rank amateurs or some people with dubious goals.


See BUG: Distribution of Microsoft Scripting Runtime Library Fails for information on redistribution of Windows Scripting. However some of the links to the redist packages currently point at a documentation download. In other words if you did not download and archive these packages for later use... well you snooze, you lose. Microsoft has pulled the downloads except for the ones to update Win2K and WinXP from 5.6 to 5.7 - and yes, if you use these you must use "chained installs" that are smart enough to use the correct package on the correct target OS.

See An update package that includes BITS 2.0 and WinHTTP 5.1 is available for Windows Server 2003, for Windows XP, and for Windows 2000 for information covering WinHttp.dll deployment to downlevel systems. Again, these contained tailored code, which is why there are separate deployment packages for each of those OSs.


You can't just grab a system DLL off one PC and go around dumping them into other PCs.

[dilettante]

I used SetupFactory to package my app. I guess it was not outdated as well? Or is there a better and easier option specifically for VB6?

I don't know anything about that product except that it is a legacy scripted installer.

Normally VB6 programs deploy most cleanly in the form of MSI packages created using the Microsoft-supplied merge modules. Merge Modules for Service Pack 6 for Visual Basic 6.0 and Visual C++ 6.0

When it comes to deployment "better" and "easier" are opposite ends of a spectrum. "Easier" almost always means "not better" and vice versa.

[dilettante]

BTW:

Those packages that Microsoft does still offer above (links in post #5) do not grant any redistribution rights to developers as far as I can see. This means you can't grab these to make chained installs anyway, or even give them the files on a CD. The user must obtain and install them for themselves.

This is why we say Windows XP and earlier are "dead." You can limp along and sort of get away with using them but they are really, really not supported.