Execute dll file after copying

[sashaDG]

Good afternoon, did not find a solution in the forum, but found other useful information.
My question is: after copying, renaming and moving from another disk file vbscript.dll to vb.dll, then successfully entered into the registry using regsvr32. I want use the file vb.dll in VFP. CREATEOBJECT("VBScript.RegExp") works good.

If you use CREATEOBJECT("vb.regexp") - "Class definition not found".
If through DECLARE - "Cannot load 32-bit DLL". I think, since it is still COM, this initialization is not correct.
But if I’m wrong, whereas to know the parameters of the called function, there is no documentation.

 

[Chris Miller]

I think you confuse two things here.

When you define a class in VFP code as olepublic, the VFP class name becomes the second part of a com.class name convention. The first part is the filename you pick when building, usually the project name. I'm not even sure if it's always the project name or when you change the file name during build whatever name you give the built file then.

But this is only working that way for VFP, if you remane vbscript.dll to vb.dll and register that, it doesn't replicate VBScript.RegExp as VB.REGEXP, the COM class names are part of the type library sometimes available as tlb file, sometimes extractable from the DLL using midl from the Windows SDK, fopr example. The point is that the COM names are not always simply constructed in the way VFPs build process does, so you can't just have a secondary instance of all the OLE classes of a dll with new alias/class names by renaming the dll file or a copy of it and registering that.

So what's wrong with using vbscript.regexp?

Chriss

 

[sashaDG]

Yeah, I really didn’t think VBScript was a class name, it became clearer.

So what's wrong with using vbscript.regexp?

With vbscript.regexp all ok.What if there is no VBScript.dll on the computer.

Thanks for fast and detailed answer!

 

[Chris Miller]

What if there is no VBScript.dll on the computer?

Well, then you'd need it, but that's not the same as having it and renaming it. What was the reasoning behind that?

I don't think you have to worry about it not being present unless you want to support Windows 95. It#s part of WSH, and even after the deminse of IE, where VBScript is also supported, even though there is poershell and many things are modernized in Windows, it's not only installed, if IE is installed. So it should be everywhere from Windows 98 to Windows 11.


Chriss

 

[Chris Miller]

I googled a bit and found, that indeed since Windows 11 build 25309 VBScript can be uninstalled.

https://www.elevenforum.com/t/install-or-uninstall-vbscript-feature-in-windows-11.13095/

This forum thread also tells how to install it (on that Windows version, when it's unavailable) by calling

DISM /Online /Add-Capability /CapabilityName:VBSCRIPT~~~~

It would normally not be necessary. I guess even if VBSCRIPT is disabled/deinstalled with one of the other given options and ways, that does disable .vbs sscripts to be run, mainly, I wouldn't be surprised when you could still use the ole class anyway. Usage of Scripting.FileSystemObject also is possible, when WSH is disabled on a system.

There would be other reasons you could use another component for regular expressions, though, because the way Miscrosoft implemented them with VBScript.RegExp differs from how regular expressions work in other languages and platforms. I'm sure you cna find something else to use, unless you already used this for all your regex coding and now just need it to be available.

I wouldn't care too much and document it for users that have disabled this in their Windows 11.

Chriss

 

[sashaDG]

Well, then you'd need it, but that's not the same as having it and renaming it. What was the reasoning behind that?

I want to keep all the features I use in the program folder. So I tried to use a copy of the file, but, for example, with a different name (of course, given that I used regsvr32)

So it should be everywhere from Windows 98 to Windows 11.

Okay, you’ve calmed me down. I know exactly that we will not switch to win 11, so check does not make sense.

It would normally not be necessary. I guess even if VBSCRIPT is disabled/deinstalled with one of the other given options and ways, that does disable .vbs sscripts to be run, mainly, I wouldn't be surprised when you could still use the ole class anyway.

And CREATEOBJECT("VBScript.RegExp") still works, interesting.

Anyway, thanks for answering, you have been very helpful!

 

[Chris Miller]

So I tried to use a copy of the file, but, for example, with a different name (of course, given that I used regsvr32)

Let me guess, you didn't want to cause any trouble by registering a renamed dll having other class names. Well, that doesn't work out, so indeed it would just cause the original DLL to be demoted and when you then later deinstall the system would get broken.

Chriss

 

[sashaDG]

So it’s a good thing it didn’t work out

 

[Chris Miller]

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:

https://west-wind.com/wconnect/Weblog/ShowEntry.blog?id=890

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

 

[sashaDG]

Thanks for the tips. I tried to remove the DLL at the time of the launch - the error did not appear. With the manifest file - I created it, but I did not initialize it (or it should initialize itself). It doesn’t matter much.

I want to say that the answers to the initial questions I received and it is enough for me. Thanks again for the help!

 

[Chris Miller]

Okay, then you don't need this answer, but any future reader interested:

Manifests are not initiallised, they are simply embedded or put separate as application.exe.manifest file and read by Windows before it looks into the registry. So you just have to have the manifest and then are done with it, there's no additional code to activate or initialize it, you obviously need to ensure it has the correct XML tags and attributes and located in the right section so it overrides what any other application still finds in the registry but not your own exe, so any CREATEOBJECT of a com server class mentioned in your manifest acts differently as without the manifest.

the error did not appear

You haven't understood what the manifest test is about. If you have something wrong in the manifest it means CREATEOBJECT() falls back to whats registered in the registry. You don't get an error when your manifest modification is not correct to the point, you still just get the generally available VBScript.RegExp object. That's what's making it so hard to check whether your manifest is correct or not. you'd only get an error in a system far in the future which neither has a correct manifest nor the registered class.

Chriss

 

[sashaDG]

Test by deleting, after creating the manifest, understood!

 

[Chris Miller]

No, after creating an object. To test whether the object uses the DLL you point to in the manifest instead of the official DLL.

I have the feeling you don't just misunderstand this detail, but the whole concept. So you could also go back to what you said, you just live with the knowledge this isn't an imminent problem at all, you neither need ysour own DLL in the setup nor a manifest and just rely on VBScript.RegExp being available from Windows.

Chriss

 

[sashaDG]

I have the feeling you don't just misunderstand this detail, but the whole concept. So you could also go back to what you said, you just live with the knowledge this isn't an imminent problem at all, you neither need ysour own DLL in the setup nor a manifest and just rely on VBScript.RegExp being available from Windows.

Well, that’s what I’ll do

 

[Chris Miller]

Good,

the Regfree COM/OLE class usage is mainly intersting for cases where you can't register a DLL that's not at all already registered on the system. And that's not your case. It would also be interestng for your case to become completely independent, but you have a lot of other areas to improve before you need this.

Chriss