[RESOLVED] Alternative "simple" package and deployment of a VB6 program

I have written using VB6 a fairly complex program which includes database access using ADODC, a DATAGRID and MS Access .db1 files containing several tables.

Connection of the ADODC to the Access database is by CONNECTION STRING. The DATAGRID datasource property is set to ADODC.

For a particular reason I wish to distribute this program other than by using a full-blown Package and Deployment process.

So I have produced a folder containing just the .exe and all the dependency files which the Visual Studio P&D wizard lists when I ask it to generate a Dependency File List.

The program folder thus arrived at is copied to a "foreign" machine, and the .exe is run from that folder.

I have two near-identical "foreign machines". Both, like the source machine, are Win XP Sp3. The difference between them is that that one has VB6 installed and the other does not. (This is so as to test deployment to non-VB6 machines).

For the most part this seems to work OK, but one particular aspect of it - the reading of an Access Database fails when attempting to run the .exe on a NON-VB6 machine. When running the program as described, no errors are displayed but the program fails to open and display the Access .db1 Tables.

However, if I run the selfsame routine on the "foreign machine" which DOES have VB6 loaded, the program runs just fine.

So to investigate this matter further, I wrote a very simple special program. Just a Command button, an ADODC and a Datagrid. On clicking the command button, the ADODC is directed to a (known good) Access .db1 file and table. I made a .exe from this, and tried it on the two "foreign" machines.

Once again, it failed to work on the NON-VB6 machine. No errors were notified, but the Access data table failed to open and the DATAGRID remained unstructured and blank.

However when I ran the .exe on the VB6 INSTALLED machine, it ran fine and the Access table opened correctly into the DATAGRID.

My preliminary conclusion is that although my "deployment package" folder contains both the .exe and all the listed dependency files it must be missing "something" which is nonetheless provided when a "foreign machine" has VB6 installed.

Since I get no reported errors when I run the .exe thus on a non-VB6 machine, what could be missing?

It is appreciated that the deployment method I am trying to use is "unconventional", but there is a reason for this.

Suggestions and ideas welcomed please.

camoore

Wales, UK

You asked very complicated i need to find out the solution!

What you're missing is registering the components on the machine... installs do more than jsut copy files around... they also are responsible for registering DLLs and OCXs on the target machine so that when the app needs them, it knows where they are.

Supposedly there's a way to make VB6 apps use the app directory to find things, but I've never done it so I don't know how it's done. I'm not even sure how to search for it, but I've seen it discussed here a few times. Other than that, all I can offer is 1) use a proper installer, it doesn't have to be the P&D, but use something. or 2) write a bat file that registers the Dlls & Ocxs ... and run it after copying the files.

-tg

Thanks for your reply TechGnome.

I appreciate what you say in your first paragraph - all understood.

However I too have read/heard that it is possible to distribute an .exe with all the dependency files contained within the same folder as the .exe - ie. a simple file transfer. That was what I was, for the first time, trying to do. There is a reason for this in the context of how/where the program will be used.

In the case of my present program, this almost works. Most of the dep files (.dll. .ocx etc.) are found and run OK on my non-VB6 machine. There is just one (so far) which for some reason is not found/recognised from the application folder. This was MSBIND.dll, which is necessary in linking an ADODC to a DATAGRID and to a DATABASE. (I worked out that this was the problem dep. file by returning to my VB6 machine and temporarily disabling the support files one by one until I reproduced the behaviour in VB6 design mode which I was experiencing on my non-VB6 machine when running the .exe.)

So I went back to the non-VB6 machine and registered MSBIND.dll. I did this by

Start | Run | Regsvr32 MSBIND.dll | OK

That appeared to run OK, and now my program is (so far) working fine on the non-VB6 machine with all other dep. files contained within the application folder. Only MSBIND.dll needed to be separately registered thus.

That is progress, but I question why this one dep. file, MSBIND.dll, could not somehow have been "extracted" from my application folder in the way that all the others apparently were.

Lastly, could you please give me an example of how to write a .bat file as you describe. Just a simple example for MSBIND.dll would get me started.

Thanks again for your reply TechGnome,

camoore

Wales, UK

it might be because it's not directly in use by your app... but used by a component used by your app... it's a dependent of a dependency of the app... maybe... I don't know for sure. I've always used a proper install for everything. And I've never used the ADODC beyond some experimentation in my wild & carefree youth. I normally used ADODB (ADO Classic) all I ever got from ADODC was trouble.

-tg

TechGnome, I tried to think of such possibilities. I have made SURE that every sub-dependent file listed in the .dep of all dependency files is present in the project folder. This seems to work just fine for all except MSBIND.dll for some reason. It only came good when I specifically registered MSBIND.dll as above described.

About the use of ADODC, my VB6 programming skills are limited. Years ago I followed a self-help course which taught me how to use databound controls to link an Access database to a DATAGRID via an ADODC. From the DATAGRID, bound text boxes allow access to / change of individual data fields plus the use of database field content within a VB6 program. I have also sucessfully used ADODC/DATAGRID with Excel data sources. These served me well and hence I have not experimented with ADODB.

camoore

Wales, UK

Right that's what I'm saying... it's a dependency of something else in the chain... if it had been a direct dependence in you app, it might have worked but it's at least once removed (possibly twice removed) ... I don't know how far through the dependency chain things will go.... That said, it sounds like your solution is to simply register it when deploying the app...


here... may be this would be of some help....
start with the 4th post down. and again with post #6...
http://vbcity.com/forums/t/41609.aspx


-tg

What you probably want is Reg-Free COM. Anything else is going to require admin rights to properly self-register those libraries when the VB runtime finds them plooed in the app directory. Never a good thing even when it works.

Sadly Microsoft enver provided tooling for this even though the feature was developed specifically to support VB6 applications. So you have to either fiddle with .Net tools or find one of the few 3rd party tools supporting it.

In essence your program requires isolation manifests. In many cases you can bypass separate assembly manifests and shove everything into the application manifest. The trick of course is creating proper manifests, and that's where the tools come in.


Here's a sample of one for a program I have that uses several of the same libraries you are using:

Code:

---

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <!-- Make My Manifest 0.10.306 -->
  <assemblyIdentity name="DeMoCo.DataGrid" processorArchitecture="X86" type="win32" version="1.0.0.0" />
 
  <file name="deps\MSADODC.OCX">
    <typelib tlbid="{67397AA1-7FB1-11D0-B148-00A0C922E820}" version="6.0" flags="control" helpdir="" />
    <comClass clsid="{67397AA3-7FB1-11D0-B148-00A0C922E820}" tlbid="{67397AA1-7FB1-11D0-B148-00A0C922E820}" threadingModel="Apartment" progid="MSAdodcLib.Adodc.6" miscStatusIcon="recomposeonresize,cantlinkinside,insideout,activatewhenvisible,nouiactivate,alignable,setclientsitefirst" description="Microsoft ADO Data Control 6.0 (SP6) (OLEDB)" />
  </file>
  <file name="deps\MSStdFmt.dll">
    <typelib tlbid="{6B263850-900B-11D0-9484-00A0C91110ED}" version="1.0" flags="" helpdir="" />
    <comClass clsid="{2B11E9B0-9F09-11D0-9484-00A0C91110ED}" tlbid="{6B263850-900B-11D0-9484-00A0C91110ED}" threadingModel="Apartment" progid="MSSTDFMT.StdDataValue.1" description="StdDataValue Object" />
    <comClass clsid="{6D835690-900B-11D0-9484-00A0C91110ED}" tlbid="{6B263850-900B-11D0-9484-00A0C91110ED}" threadingModel="Apartment" progid="MSSTDFMT.StdDataFormat.1" description="StdDataFormat Object" />
    <comClass clsid="{99FF4677-FFC3-11D0-BD02-00C04FC2FB86}" tlbid="{6B263850-900B-11D0-9484-00A0C91110ED}" threadingModel="Apartment" progid="MSSTDFMT.StdDataFormats.1" description="StdDataFormats Object" />
  </file>
  <file name="deps\MSDATGRD.OCX">
    <typelib tlbid="{CDE57A40-8B86-11D0-B3C6-00A0C90AEA82}" version="1.0" flags="control" helpdir="" />
    <comClass clsid="{CDE57A43-8B86-11D0-B3C6-00A0C90AEA82}" tlbid="{CDE57A40-8B86-11D0-B3C6-00A0C90AEA82}" threadingModel="Apartment" progid="MSDataGridLib.DataGrid.1" miscStatusIcon="recomposeonresize,cantlinkinside,insideout,activatewhenvisible,alignable,setclientsitefirst" description="Microsoft DataGrid Control 6.0 (SP6) (OLEDB)" />
  </file>
  <file name="deps\richtx32.ocx">
    <typelib tlbid="{3B7C8863-D78F-101B-B9B5-04021C009402}" version="1.2" flags="control" helpdir="" />
    <comClass clsid="{3B7C8860-D78F-101B-B9B5-04021C009402}" tlbid="{3B7C8863-D78F-101B-B9B5-04021C009402}" threadingModel="Apartment" progid="RICHTEXT.RichtextCtrl.1" miscStatusIcon="recomposeonresize,cantlinkinside,insideout,activatewhenvisible,setclientsitefirst" description="Microsoft Rich Textbox Control 6.0 (SP6)" />
  </file>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
        <requestedPrivileges>
          <requestedExecutionLevel level="asInvoker" uiAccess="false" />
        </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

---

But keep in mind this is one of those "Not For Blind Kids" technologies, much like the Mainway Toys Invisible Pedestrian Halloween costume. You need to know what you're doing.

Thank you TechGnome and Dilettante for replies.

In last few days I have been looking at the reference which TechGnome provided - http://vbcity.com/forums/t/41609.aspx Here there are described two VB programs (.zipped) to register and un-register .dll and .ocx etc. While this code was superbly well commented (I thought) it seemed very complicated, but prompted me down a simpler path of using Regsvr32 under a shell command :

eg. SHELL Regsvr32 /s MSBIND.dll

The /s causes Regsvr to run in silent mode, and hence the method is not apparent to the user. If omitted, then the user will see the Regsvr32 messages.

(SHELL Regsvr32 /s /u MSBIND.dll would un-register that .dll).

My program uses about a dozen .dll / .ocx references. Thus far when running the .exe on a non-VB6 machine, all but one of these appear to work satisfactorily if contained withing the Application folder, as opposed to being "formally" registered or installed. The only one which gives me a problem is MSBIND.dll, which needs to be registered before the program will work OK on a non-VB6 machine.

32 bit .dll, .ocx etc. are normally stored in C:\Windows\ System, System32 or SysWOW64 folders. Which one depends on the operating system. (System = 98, System32 = 2000/XP, SysWOW64 = Win7/64).

So I wrote a subroutine called REGISTER. It is called up by a simple code command

eg. REGISTER MSBIND.dll, N
(N is either 1 or 0 - see later).

The logic of REGISTER is this :

i. If a folder C:\Windows\System exists, then check if it contains MSBIND.dll. If not, copy MSBIND.dll to that folder from the Application folder.

ii. If a folder C:\Windows\System32 exists, then check if it contains MSBIND.dll. If not, copy MSBIND.dll to that folder from the Application folder.

iii. If a folder C:\Windows\SysWOW64 exists, then check if it contains MSBIND.dll. If not, copy MSBIND.dll to that folder from the Application folder.

Then, if it was found necessary to copy MSBIND.dll to any of those folders (if they exist) run

SHELL Regsvr32 /s MSBIND.dll

That formally registers the .dll.

It is appreciated that the existence of MSBIND.dll in one of those 3 folders is not proof positive that MSBIND.dll has been registered - but for most purposes this seems an adequate criterion. However, while un-necessary, to re-register a .dll which is already registered does not seem to cause a system run problem.

(From my reading, it is a rather complicated matter to determine in code if a .dll IS formally registered as opposed to its just being present in one of the Windows folders, for which I use the simple Dir() function.) - Maybe not so complicated. See my post #20 below.

That is why I added the integer 0 or 1 to the REGISTER subroutine command. If set to 0, registration is only carried out if MSBIND.dll was found to be missing from one or more of those 3 Windows folders. This would indicate that MSBIND.dll had not been previously registered.

If set to 1, then MSBIND.dll is registered/re-registered anyway just the once.

In this description I have used by way of example MSBIND.dll, but it could equally well be any .dll, .oca, .ocx etc. which is found necessary.

Hence within my .exe is incorporated a fairly simple subroutine which can be called to formally register .dll etc. if necessary by calling up :-

SHELL Regsvr32 /s <filename>.

Thus far upon testing this routine is working OK. I am not certain yet whether it would work if the user were not assigned ADMIN rights. This is tbd. Would "embedded" Regsvr32 work if the user were not ADMIN?

I have not tested it on a Vista machine, nor on a Win7/32 machine yet.

For me this is work in hand. I look forward to further comments please. If / when fully proven I will post the code for my REGISTER subroutine, but the logic of its operation is described above.

camoore

Wales, UK

All of this is an exercise is why people build installers... that's effectively what you've done in a convoluted, potentially bad way. I have a Windows\System folder ... AND a Windows\System32 folder! AND a Windows\SysWOW64 folder! Did you app really jsut copy that file three times? Meanwhile you install a new program that also uses msbind... but let's say it's a newer version. It sees that it's installing on a 64 bit system, so it goes straight to the sysWOW64 folder, and installs the newer version. You're going to end up with mismatched versions. OR, since you're not bothering to check to see if it was registered and only scanning the Windows directories, what if someone already does have it registered, but in a different location... by moving it and registering it there, you've potentially broken someone else's app.

As for admin rights, I don't know... I would think doing so would need elevated rights... again, this is why there are installers... they can run elevated, install the app, and then that's it... the app can run under normal credentials.

I don't know, maybe it's just me, but I think in the amount of time that's been spent on this, you could have downloaded an installer, built the install and been done with it.

-tg

Thanks TechGnome,

I fully appreciate that a conventional install, using for example the VB Studio P&D Wizard would probably have solved the issue - EXCEPT that as mentioned there is a reason why I wish to try to avoid this and hence to get my program to work "simply" from a copied application folder containing the .exe and the necessary support files.

In answer to your specifics :

My REGISTER routine firstly makes sure that there is a copy of MSBIND.dll in those 3 Windows folders. If not, it puts a copy there. If there already was a copy there, it does not seek to over-write that copy (which could be of a later issue). Then it carries out Regsvr32 /s <filename> . That seems to work OK on 98/2000/XP/7.

If a subsequent install of another program causes a later version of MSBIND.dll to be registered instead, that should not be a problem since later versions are "supposed to" support earlier applications of the same routines, and usually do.

The circumstance you postulate could in any case arise under "conventional" installation packages. With XP for example the normal place to put a .dll is Windows\System32\. So suppose the user installed a program which did just that, then subsequently installed another program which used a later version of that .dll. That could be a "normal" situation, yet it would potentially lead to the version conflict problem to which you refer. My routine does not replace any existing .dll with it's own - whether of later or earlier issue.

Am not sure about your comment regarding interference with an already installed program which has MSBIND.dll registered but "in a different location". Were that the case, then would not any conventional installation process for a new program which called up MSBIND.dll into the standard folder (eg. C:\Windows\System32\) have a similar potentially detrimental effect?

The Regsvr32 function appears only to work from a .dll / .ocx etc. file which is present within one of those 3 Windows folders (System - System32 - SysWoW64). That upon which it operates depends on the operating system in use. That is why I copy it to all three (or as many as are present). Only one will be used, depending on the opsys, and copies in the other(s) appear to cause no problems.

camoore

Wales, UK

A proper (not "conventional") installer is supposed to track down COM libraries through the registry by Class ID. If it finds the registry entries it should also check version info there, and only if the version is too old should it update the library by copying the new one to the prior version's location (as found in the registry), and for any shared library it should update the usage count in the registry.

A shared library is pretty much anything you did not write and compile as part of your single application, that no other application will ever use.

It is always assumed safe to install a higher version of a library, because otherwise there should be a compatibility break and new Class IDs.

For the rare application that can only work with a specific older version, there are special rules of engagement. One of these was the ancient ".LOCAL file in the app folder" mechanism. This never applies to VB6 because of the way VB6 programs and libraries get registered - they can't be localized.

The alternative is the much more robust mechanism of isolated assemblies and isolation manifests. This one can be used with VB6 libraries, since in large part VB6 support was its original goal.


There are only four legal options: (1.) a proper installer, properly written; (2.) a Reg-Free COM XCopy deployment package based on isolation manifests; (3.) a simple, EXE-only application that uses nothing but the VB6 runtime libraries and instrinsic controls; or (4.) a few VB6 applications can be packaged as part of ClickOnce packages (also uses manifests).

There is a 5th option on Vista or later: A simple, EXE-only program that relies on the additional VB6 libraries shipped as part of the OS (referred to as "runtime extended" in some documentation). These are listed at Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008, Windows 7, and Windows 8


Anything else (including poorly-written installers) risks DLL Hell and crippling other applications.

Quote:

---

Originally Posted by camoore

With XP for example the normal place to put a .dll is Windows\System32\.

---

Only true in the degenerate case. The library's .DEP file is supposed to tell the installer developer where a given library is to be installed. This might be System32 or it might be Common Files under Program Files or it might be another location.

On 64-bit XP this changes just as on a later version of Windows. Then it might go into SysWOW64 or somewhere under Program Files(x86) depending on the original target spelled out in the .DEP file. That decision is made by the OS, which uses filesystem redirection on a 32-bit installer to ensure properly relocated placement.

It is fully appreciated that the proper way to deploy a .exe is to use a proper installer, such as the Visual Studio P&D Wizard. However, for a specific reason in this case, I wanted to explore the possibility of avoiding such an install, yet distribute a program which uses dependency files. Hence the post.

So I made a folder which included the .exe and all the dep. files which it required (of which I was able to make a list using the P&D Wizard) and copied this to a non-vb6 machine. The .exe was then run from that application folder (via a shortcut). Virtually everything worked fine thus, and since there had been no install the receiving machine would not be affected in respect of any other programs on it. The application folder would be a stand-alone item and nothing more.

Just one Dep file caused a problem in the case of my program - this was MSBIND.dll. The method I devised of having the .exe call up Regsvr32 to register just this one .dll worked, but anyone seeking to adopt this approach would be very well advised to heed the cautions expressed by Dilettante above in this thread - who is far wiser than I in programming matters.

For what little it is worth, I attach (as .zip) the code of the REGISTER subroutine which I have got working. Hopefully it is adequately commented for understanding. It is written for an application folder stored as C:\RP Program\

I find it curious why all the dependency .dlls apart from MSBIND.dll worked OK when just included in the application folder. Doubtless there are others which would not work, but which I did not happen to be using in my application.

My thanks to Dilettante and TechGnome for their contributions to this thread. I will mark it as "resolved" in a couple of days time unless there are further points raised.

camoore

Wales, UK

You have run across a dangerous feature of the VB6 runtime.

When a VB6 program starts and attempts to link to a DLL or OCX by its registration and fails because the library is not registered, it does a dangerous thing. It attempts to use the system DLL Search to load the library and then calls the library's self-registration entrypoint (which is the only thing RegSvr32 does as well).

If you have hazardously placed such a DLL into the application folder, DLL Search will find it there. Once the runtime calls DllRegisterServer, you now have an improperly registered library. It will appear to function fine.

But as soon as this application is removed (usually anyone "installing" via this ham-handed process "uninstalls" by deleteing the application folder) you have a broken registration, one that points to a file no longer on the system.


The way this causes grief is usually:

• Poor excuse for an installation runs first, publishing its copy of the shared library.
• Proper installer for another application is run subsequently, sees the library already registered so it can skip adding and registering the library.
• Another.
• Another.
• Sloppy first application is crudely removed, blindly deleting the shared library file but leaving it published as being present in the sloppy-app folder.
• All of the applications are now broken on the machine. User calls for expensive support, everyone is upset.
• In extreme cases, they call a hit man to go after the guy responsible for the "poor excuse" installer. His sloppy efforts have broken untold critical applications on untold numbers of machines.
• The only "survivors" are the applications using private copies of the library along with isolation manifests.
• Microsoft, VB, etc. get blamed because Yet Another Sorry Hack is doing illegal, harmful "installs."

The reason MSBIND.dll probably isn't getting "magically" (incorrectly) registered is that the VB6 runtime is not looking for it directly. Running RegSvr32 just makes matters worse for everyone, even if it makes your own bumbling program work. You just broke another library for everyone else.

Don't do this! There are rules of the road. Breaking them in this way means you are creating a form of malware.

BTW:

The P&D Wizard is not considered a proper tool anymore. It hasn't been for some time (around 1999).

It is better than nothing though. Windows 6.0 and beyond will allow it as a "legacy scripted installer" but it is not the preferred way of packaging and installing programs. This really only works reliably if it triggers "legacy installer detection heuristics" in Windows when it is run.

Just running it elevated is not safe.

Thank you, Dilettante, for your further comments.

It is somewhat apparent from your choice of phrase/wording that you have strong opinions about this matter and that you are knowledgeable. Good, that is why people such as I ask questions in this Forum and seek to benefit from the superior knowledge of others.

But would you please bear with my line of question a little further?

If I understand your latest posts correctly, you are concerned that a "simple installation" would probably work OK, but upon removal (of the application folder) would leave the computer possibly unable to run other programs. That is indeed an important consideration!

Staying for now with my suggested "improper" method : It seems that there are two considerations.

First, the action of having the program .exe "formally" register a .dll (MSBIND.dll in this instance) by use of Shell Regsvr32 <dll filename>.

Second, what a VB6 derived .exe program might do to a non VB6 machine if dependency .dll / .ocx are obtained (called up from) from the application folder (you suggest that they would become "improperly" registered on the non VB6 machine).

So I have investigated this on my non VB6 XP Sp3 test machine, upon which I have run the program several times from my application folder. Results are these :

1. Through the use of my REGISTER subroutine (as .zipped to thread above) MSBIND.dll WAS formally registered, and the path registered was to Windows\System32 - not to my application folder. That is what the subroutine I wrote sought to achieve, and did achieve.

2. Having done this, the subsequent removal of my application folder from the machine would surely not invalidate that registration, since the registered path is to system32 and not to the app. folder? Removal of the app. folder would still leave MSBIND.dll within the Windows\System32 folder, to which it is registered. My REGISTER subroutine copied the .dll (MSBIND.dll) to System32. That .dll was registered by Regsvr32 from THAT location (not from the application folder) so surely subsequent removal of that application folder would not invalidate/corrupt that registration?

3. Others of the .dll / .ocx which I included in my application folder WERE found to be registered. However their registration paths were NOT to my application folder but to other entries in System32 etc. which must have been made by my Windows installation and/or the subsequent previous import of other programs.

4. So it seems that it was not the fact of my program's having called up those .dll which caused them to be registered, and my program has not affected their existing registration(s).

5. Certain of the dependency .dll of my program were NOT registered (eg. RICHTX32.dll - used for the RichTextBox control). Nonetheless the deployed program package ran fine. Since there is still no registry entry for RICHTX32.dll, it would seem that running the VB6 derived .exe on a non VB6 machine did not cause additional registry entries to be made which might become a source of problems were my application folder to be deleted.

Since there appear to be no registry entries which have come to depend on the application folder, it would seem that its subsequent deletion would not affect anything. The formally registered MSBIND.dll would remain thus registered (from the System32 path) but any subsequent program installation could replace it with a later issue if desired.

Removing the application folder would seem not to affect anything, other than the ability of the recipient machine to run my program.

I have not sought to distribute anything yet - am simply seeking opinions, advice and expertise.

camoore

Wales, UK

Actually, running RegSvr32 is not a "formal" or proper way to register a component.

RegSvr32 is meant as a tool used during development, and occasionally to manually repair problems. It should never be used for deployment since it skips numerous steps in the process (such as creating/updating usage counts). It's main use is to unregister old versions of libraries during development when you break binary compatibility. Secondarily it can be used to brute force register developer copies of 3rd party libraries when the author failed to provide a proper developer install package.


Testing doesn't mean much unless you test on known clean systems. The best way to do this is to use VMs that you roll-back after every testing session. Otherwise, once you change the system state your tests won't say anything about what you'll do to a user's system. For example Test #1 might put a library into System32. Test #2 might not do that, but now the file is already present in System32.


On systems past Win98, Riched32.dll is a stub library that invokes the newer Riched20.dll. Both of these are non-COM libraries so they don't require registration and can't be registered anyway.

They are also part of the OS and you should never attempt to deploy them or you risk breaking users' systems again. The only exception is deploying to Win95, where it is safe to deploy the Win98-era redistributable from Microsoft for Riched20.dll. Do not try to package up a random version off your development system, many system libraries starting in Win2K contain code tailored to the specific version of Windows they shipped with.


I'm sorry but you're playing with fire here, or a form of Russian Roulette. I just don't know how anyone can say any more.

Your further comments noted and appreciated Dilettante.

The tests I have carried out WERE on clean systems (XP Sp3 and Win7/64).

After each test I did just as you refer to - I manually un-registered MSBIND.dll and deleted it from the system32 / syswow64 folders. Otherwise, as you say, after test#1 it would remain registered and subsequent tests would no longer be on a "clean" machine but upon one which test#1 had modified (by registering of the .dll).

I remain curious why all of the .dll / .ocx dependency files would appear to run OK from inclusion in the application folder other than MSBIND.dll. This .dll is called by a reference to VB6 Microsoft Data Binding Collection, just like the other .dlls which work OK from the application folder.

Thank you again for your comprehensive posts and well-founded cautious warnings.

I will mark the thread as resolved.

camoore

Wales, UK

By way of a post script to this thread, I include the code for a simple VB6 program which determines whether a given .dll or .ocx is registered on the current machine. This would appear to "find" registered libraries whether their dependent files (eg. MSBIND.dll, MSADODC.ocx) are contained within the Windows 32 bit system folder or elsewhere (where another program installation may have placed them).

The program returns a simple boolean value - True or False and displays this in a message box. However this boolean value can be used to determine any subsequent action within a program which is to be dependent upon whether or not a library was registered.

This is done by the DLLREGISTERED subroutine. No additional VB6 project references are required.

To run it you need a simple form with one Command button and one Text box. The name of the .dll is entered into Text1 and then on clicking Command1 the message box shows whether that .dll..ocx was found to be registered or not.

The code is closely based upon the following URL post :-

http://www.developerfusion.com/code/...ll-registered/

Code:

---

'This code is closely based upon that obtained from this URL :

'http://www.developerfusion.com/code/3479/is-dll-registered/

'Option Explicit

Private Declare Function LoadLibrary Lib "kernel32" Alias "LoadLibraryA" ( _
ByVal lpLibFileName As String) As Long

Private Declare Function FreeLibrary Lib "kernel32" (ByVal hLibModule As Long) As Long


Function DLLREGISTERED(ByVal DllFilename As String) As Boolean
'This function determines if a .dll or .ocx is registered
'It requires declaration of LoadLibrary and FreeLibrary at Option Explicit

    Dim hModule As Long

    hModule = LoadLibrary(DllFilename) 'attempt to load DLL
   
    DLLREGISTERED = False              'Return False
   
    If hModule > 32 Then
   
        FreeLibrary hModule            'decrement the DLL usage counter
       
        DLLREGISTERED = True          'Return true
       
    End If
   
    MsgBox DLLREGISTERED              'True or False
   
End Function


Private Sub Command1_Click()

   
    DLLREGISTERED Text1.Text 'eg. DLLREGISTERED "MSBIND.dll"

End Sub

---

camoore

Wales, UK