C++/VB - Opening DLLs

Asked By p byers

08-Jan-10 01:16 PM

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 !!!!

08-Jan-10 02:46 PM

You cannot 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 is a hokey and risky approach. You'd
need to work out the data types and debugging
would be very difficult. it is a bit like a teenager
who asks someone to buy liquor for them outside
a liquor store. If you are lucky you will 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 is 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.

08-Jan-10 04:05 PM

I do not go along with "hokey".  That's a pejorative and
disrespectful term.  Granted ms did not have calling api's
in mind when they offered up vbs, but 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.

The usual suggestion here for calling api's is the DynaCall/
DynaWrap approach, courteously hosted by Guenter Born,
(DynaCall originally written by Tom Plooy, and the wrapper
by Jeff Strong).  An "improved" version is offered by Yuri
Popov called "DynamicWrapperX" (with the "X" presumably
meaning "extended").  Yuri's version is an improvement over
the Plooy/Strong version, but is a bit more risky because
no source is offered.

http://www.script-coding.info/dynwrapx_eng.html

There are other possibilities.  For example, "XNeat"
(do not ask me what that stands for):

http://www.xneat.com/doc/call_win32_api.html

Finally, my favorite (other than my own API Toolkit) is
something called "sfcMini" (do not ask why) and it was found
posted on Source Forge (Japan), written by "Katsumi" (no
indication as to whether that is his/her first or last name?).
Also, the documentation is part Japanese, and part English:

http://kandk.cafe.coocan.jp/sfcmini/catid-19.html

However, google will do a reasonable translation into
fractured English, if you click on "translate this page".
So go to google and search for "sfcmini".  You will get
a number of hits.  Pick out a url that points to:

kandk.cafe.coocan.jp/sfcmini/item...

and select "translate this page".  That will send you
into the middle of the documentation under the control
of google's translator, and you may then navigate through
the rest using the left-hand menu.  Google will follow
you along translating as you go.

If you wish to try out sfcmini, you may download the
source, binaries, samples (demo code), and libraries
(class code) from this page:

http://sourceforge.jp/projects/sfcmini/files/

Download the "sfcmini-1.0.1.zip" file, dated 17Feb07.
Unzip the file into a folder of your choosing.  Then
LEAVE THAT FOLDER AND ITS INCLUDED SUB-FOLDERS ALONE.
The successful operation of SFCmini depends on retaining
the structure that the zip file installs.  Run the
installation vbs script.  That will register the
sfcmini(i/a).dll.  The sfcminii.dll is supposedly for
intel systems, and the sfcminia.dll is supposedly for
AMD systems.  You may choose the INTEL installation
(as I did) if you have an intel processor.  That will
get you into a morass of "DEP" (data execution prevention)
errors. For some reason, even though I have admin privileges
I could not bypass the DEP error checking.  And so, I
un-installed INTEL and installed the AMD version.
Against all common sense, the AMD version DOES work
on an intel processor (miracles never cease).

If successful, you will find the following progID's
in your registry:

SfcMini.ClassEx
SfcMini.DynaCall  (obviously to call api's)
SfcMini.MachineCode
SfcMini.Structure  (for typedefs)
SfcMini.Tools

You may then try running the demo scripts in the "samples"
folder.  One little bothersome item.  There are THREE
I eventually sorted it out.  The "winform.vbs" script in
the samples folder is a demo script.  The "winform.vbs"
script in the "lib" folder is class code (used by other
demo scripts for creating "forms" a.k.a., windows).  And
the "winform.vbs" in the consts folder is just an
enumeration of the windows system api constants used.
Still in all, if it were up to me, I would have given
those different entities different names.

The sfcmini actX objects in question all come with source,
so if you are handy with a c/c++ compiler, you can create
your own binary (just in case you are a suspicious person).
If you do not wish to compile-yer-own, the binaries come
with the download.

One final thought.  Although it is fun to bend-and-twist vbs
to do your will (as in calling api's), if you have "real work"
to do, there are countless other -- and probably much more

08-Jan-10 05:18 PM

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

08-Jan-10 08:43 PM

Interesting choice of words. it is not
a personal issue for me. it is practical. One
does not "disrespect" or insult a bad idea. :)


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 is similar, allowing
people to use Perl to call the Win32 API. But the
fact that it is possible does not make it sensible. it is
simply the wrong tool for the job.


Yes. I think that is what I said, no?   :)

09-Jan-10 12:51 PM

mr_unreliable wrote:

11-Jan-10 08:37 AM

Oh the arrogance of hardware suppliers (and C affecianados)! he problem is
even invoking a dll directly from vb is not the 'best' solution either but
we live with it: part of the problem being that you are left a hostage to
fortune. The mfgr could change the DLL at any time to handle OS changes and
leave you hanging if the calling interface changes.

the good news is that VB Express is free and the executable does not, like
vb6 come with gobs of baggage other than the CLR which is probably already
installed on your machine(s). The bad news is that MS took leave of their
senses when developing VB.Net and made the learning curve a little to
steep - though in general it is not that difficult esp. if you have already
delved into the mysteries of vb script. Installing a VB.Net app is literally
copying the exe (and making sure the clr is present).

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).

11-Jan-10 11:14 AM

This post is so full of misleading untruths that
it smells to me like a post planted by Microsoft.
(And that is 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 are "de-emphasizing" VBS these days.)



??  "VB Express" is VB.Net, which is a JIT-compiled
Java clone. It does not support COM except through the

VB (VB5/6) produces Windows executables (native
code) and was specifically designed for COM
compatibility -- thus it is 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 have not 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 is own runtime. So someone using C++ in Visual Studio
later than VS6 is faced with less support than VB6 has.


That's quite a wild understatement. The current version
of the .Net Framework (what you are 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
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 is still 88 MB total size -- about 24 MB download.)

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 are plain text. And...this is
a scripting group, after all, not a .Net revival meeting.

What you are saying is that it is 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.

11-Jan-10 12:40 PM

<applause>  synopsis accepted.   </applause>

11-Jan-10 02:24 PM

You are welcome.

Sorry, I should not have mentioned the "API Toolkit", it is
no longer in the public domain.

However, for completeness sake, I should mention yet another
actX object that may be used to call system api's from script.
It is named "DynamicCall", written by Paul Guerra, and found
on the Planet Source Code website:

http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=55777&lngWId=1

I regard "DunamicCall" as an excellent piece of work.  The
(vb) source is provided and the coding is very competent.
In addition, the set of parameter types acceptable to
DynamicCall is "more robust" (a.k.a. more complete) then
DynaWrap/DynaCall.  Even more importantly, DynamicCall handles
both [in] and [out] parameters, something either difficult or
impossible to do with DynaWrap/DynaCall (depending on your
skill level).  It also comes with a number of test cases.

Unfortunately (for me) it is one of those "good-news/bad-news"
situations.  The good-news you already know -- it looks like
a good piece of work.  The bad news (for me) is that Paul did
not include the binary with his download.  The code is "very"
vb6-ish, in that my vb5(cce) cannot handle it.  I am ok with
back-fitting the InStrRev and Split functions, but vb6 extended
what you could do with UDT's (user defined types). I am still
trying to figure out a way to re-write Paul's UDT's in such
a way so that vb5 will compile them, and so that I do not have
to extensively re-write Paul's code.  In other words, even
though I am recommending it, I have not been able to actually
_use_ DynamicCall yet.

If there is any public-spirited vbs-er out there with a vb6
compiler installed and some spare time on his/her hands, it
would be of great public service (to those scripters who are
agreeable to the notion that using the system api from script
is acceptable behavior) -- to post a copy here of the
_compiled_ DynamicCall.dll.

cheers, jw