Yes, let me double check...
...yes.
There is one way to not influence the whole system: Regfree COM:
If you embed COM class information inside a manifest of your application exe and don't register the vb.dll, then only your exe uses the vb.dll and the rest of the system still uses the vbscript.dll, whereever it is. This is explained here:
There's no need to rename the vbscript.dll to vb.dll, and I wouldn't, you'll not confuse the rest of the system or other aplications that still just use what the registry has for vbscrpt classes, because you don't change these keys and the original dll and configuration.
Without regfree COM usage, the problem is in double registering a class that already exists. What does that do?
I checked that out from the VFP perspective: When you build a VFP COM Server, no matter if you pick "Regenerate Component IDs" when building or not, registering a dll you generate in a different directory (i.e. changing directory when building to get the DLL in a new location), when registering that DLL the same ole classname used causes the old keys to be deleted and the new keys will point to the dll file you register. The same will happen for vbscript.dll, also when renamed.
Even if that's done during a setup (Installshield or Inno or anything) that stores some information for Windows to offer the deinstallation by knowing which files where added by the setup and thus need to be deregistered (if they get registered) and deleted. During registering of the setup I think - the old keys are not remembered is, so they don't get restored in deinstallation. Even if that would be the case, for as long as your software is installed and redirects instantiation to the DLL in your application folder, that would mean also Windows, the Internet Explorer or Office would make use of the DLL in your application, you serve that for the whole system.
It will then break when your software is deinstalled and the previous registration of the original vbscript.dll at the location it still exists is not reinstated, so that's when the system can break. It can also be broken while your DLL is used, when it's not the same version or when other dependences/files are assumed to be in the DLL folder, too, while you only install your vb.dll and not others.
All in all, while it's a good idea to have all third party DLLs you use in your own application folder to prevent DLL hell of multiple uses of some DLLs with version mismatches and other problems, it's not idea to do that for system components like vbscript.dll
You could argue that a C++ runtime in the Windows System32/SysWow64 is exactly like that and the recommendation there is to put it into your own application directory, too. The major difference is that this is not a OCX dll, and you don't redirect uses of the system runtime with your runtime when you install it, only your exe/dll will use your local installdir C++ runtime, you don't influence the whole system and other software.
So OLE/COM differs by being centralized with registry information. And that's where you can go back to what I said about Regfree COM server (ole class) usage at the start. That could be the ideal solution, now the only thing to test is whether the vbscript.dll is really used from the changed manifest information, i.e. whether you have modified that xml manifest correctly) and then whether the one DLL file is all you need or whether there are further dependencies. Both things are hard to see. If your manifest modification is not correct you'd likely just use the normal vbscript.regexp class without a problem. And when further dependencies are system dlls installed anywhere, too, you'd not detect whether it could break when a future Windows version removes dlls you also depend on, so it would be effort invested for nothing.
One test I would assume to prove both thigs is trying to delete the copied dll while its used. If you can delete your vbscript.dll copy while your exe is using it, your exe is not using the copy, but the original.
And when that works and vbscript.dll is self contained (likely a C++ runtime is one dependecy you can solve by also adding it without legal license worries), you'd be fine forever with regfree com, no matter whether Windows changes or not, except when the Regfree COM manifest mechanism is deprecating. And that's not to be expected. So it would pay off long term to know dependencies of vbscript.dll.
Chriss
