Opening DLLs
in [VbScript]
|
From: p byers on 8 Jan 2010 13:16 I have been given a DLL that I need to use in a VBS script. I have been told that it is just a DLL and NOT a COM object. Registering it in REGSVR32 fails, of course. The creator seems disinclined to convert it into a COM object he simply says that it works in C, C++ and VB !! Is there any method of using something like "LoadLibrary" or "LoadDLL" in VBS If so, will it work with the VBScript ASP Alternately, is there any way that I can take the DLL and create an ActiveX/COM type DLL from it ?? Alternately, is there any way that someone cleverer than me can take the DLL and create an ActiveX/COM type DLL from it ?? - lol Pete (Northolt UK) PS - I have documentation of all of the functions in the DLL, so that is not a second problem hiding around the corner !!!!
From: mayayana on 8 Jan 2010 14:46 You can't call it from VBS except possibly by using a COM component that allows you to call standard DLL methods. It typically involves calling the middleman component with a list of your function parameters and their data types. http://freenet-homepage.de/gborn/WSHBazaar/WSHDynaCall.htm But that's a hokey and risky approach. You'd need to work out the data types and debugging would be very difficult. It's a bit like a teenager who asks someone to buy liquor for them outside a liquor store. If you're lucky you'll get what you want and not get into trouble, but you have no direct control over the process. :) What you can do is to write an ActiveX (COM) DLL wrapper. The wrapper DLL would be designed to be VBS-compatible and to take care of any necessary data type conversion. It should ideally expose only variant data types, converting to the needed types internally, handling error trapping internally, and returning the result as a variant. you can do the job yourself if you have some kind of programming tool for writing COM DLLs. The job is not hard. It's just a bit picky because what VBS "sees" needs to be straightforward and error-proof. And it needs to provide enough error info. for VBS to debug calls. > I have been given a DLL that I need to use in a VBS script. > > I have been told that it is just a DLL and NOT a COM object. > > Registering it in REGSVR32 fails, of course. > > The creator seems disinclined to convert it into a COM object he simply > says that it works in C, C++ and VB !! > > > Is there any method of using something like "LoadLibrary" or "LoadDLL" > in VBS > > If so, will it work with the VBScript ASP > > > > Alternately, is there any way that I can take the DLL and create an > ActiveX/COM type DLL from it ?? > > > > Alternately, is there any way that someone cleverer than me can take the > DLL and create an ActiveX/COM type DLL from it ?? - lol > > > Pete (Northolt UK) > > PS - I have documentation of all of the functions in the DLL, so that is > not a second problem hiding around the corner !!!! >
From: mr_unreliable on 8 Jan 2010 17:18 mr_unreliable wrote: > Download the "sfcmini-1.0.1.zip" file, dated 17Feb07. uh-oh. If you followed-up with sfcMini, then you will have found that the latest version is (currently) 1.0.5_beta, dated: 2008-04-25 11:45, and found here: http://sourceforge.jp/projects/sfcmini/downloads/30737/sfcmini_105b.zip cheers, jw
From: mayayana on 8 Jan 2010 20:43 > > But that's a hokey and risky approach. > > I don't go along with "hokey". That's a pejorative and > disrespectful term. Interesting choice of words. It's not a personal issue for me. It's practical. One doesn't "disrespect" or insult a bad idea. :) > they clearly "left- > the-door-open" by providing vbs with the ability > to interface with com objects. Once the com > door is opened, anything is fair game. They did no such thing. VBS can handle dispatch COM interfaces that use digestible data types. That's a very long way from "anything is fair game". Perl also has a component that's similar, allowing people to use Perl to call the Win32 API. But the fact that it's possible doesn't make it sensible. It's simply the wrong tool for the job. > ...if you have "real work" > to do, there are countless other -- and probably much more > effective -- ways to deal with non-com dll's. Yes. I think that's what I said, no? :)
From: mayayana on 11 Jan 2010 11:14
This post is so full of misleading untruths that it smells to me like a post planted by Microsoft. (And that's not a paranoid statement. MS is famously documented to do such things. http://www.groklaw.net/articlebasic.php?story=20071023002351958 They're also trying to "upsell" .Net and they're "de-emphasizing" VBS these days.) > the good news is that VB Express is free and the > executable doesn't, like > vb6 come with gobs of baggage other than the > CLR which is probably already > installed on your machine(s). > ?? "VB Express" is VB.Net, which is a JIT-compiled Java clone. It doesn't support COM except through the "Interop" system. VB (VB5/6) produces Windows executables (native code) and was specifically designed for COM compatibility -- thus it's easy to write VBS-compatible COM DLLs in VB6 that have no real dependencies. VB6 does not come with "gobs of baggage". It has a runtime of about 1.6 MB that is pre-installed on all systems later than Win98. (And yes, it is pre-installed on Win7.) I haven't shipped that runtime with my software for years. For all practical purposes, VB6 itself is dependency-free and runs on all Windows versions in current usage. (Even with Win95/98 one is unlikely to find a system where VB software has never been installed.) In that regard, VB6 is even better than C++ software written with VS. Each VS C++ version has it's own runtime. So someone using C++ in Visual Studio later than VS6 is faced with less support than VB6 has. > Installing a VB.Net app is literally > copying the exe (and making sure the clr is present). > That's quite a wild understatement. The current version of the .Net Framework (what you're calling the CLR) is about 300 MB!. (That's about 1/2 the size of an entire Windows 98 installation. 1/3 the size of an entire XP install.) It is only supported on XP SP2+. The framework is not "probably already installed". A lot of target machines will have it. That's not the same as "probably installed". Anyone writing .Net software has to figure on some people not having the runtime. Since .Net has become so incredibly bloated... and left off support for Win98/2000/ME... and the 300 MB of dependencies are not universally installed... Visual Studio 2008 provides for the option to write .Net software for the V. 2 framework (2005). The v. 2 framework supports Win98+ and is widely distributed. (Though it's still 88 MB total size -- about 24 MB download.) > I think adding yet another layer, just for this, is foolish, especially if > in the end someone else is going to support it (like if you go into > hospital). > A VB.Net DLL is another layer -- with a huge dependency. A VB or C++ COM DLL is also another layer. One could say a script is an extra layer, but scripts are fairly simple and they're plain text. And...this is a scripting group, after all, not a .Net revival meeting. What you're saying is that it's foolish to look for a scriptable solution when the OP could learn a new programming language and write a DLL with a slow, bloated 300 MB dependency that may not be installed on the target machine. --------- .Net *could* make sense IF the OP only needs to install this locally and IF he wants to learn a new programming language. And VB6, while currently the most widely supported programming tool, is no loger supported by MS and even finding a VB6 CD might be difficult. So there are pros and cons to any option he chooses. But the OP deserves to know the true pros and cons. |