Opening DLLs
p byers
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 !!!!
mayayana
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.
mr_unreliable
> But that's a hokey and risky approach.
I don't go along with "hokey". That's a pejorative and
disrespectful term. Granted ms didn't 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"
(don't 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" (don't 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 couldn't 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
"winform.vbs" scripts. This was puzzling at first. But
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 don't wish to compile-yer-own, the binaries come
with the download.
One final thought. Although it's 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
effective -- ways to deal with non-com dll's. There are
countless other scripting languages that _do_ have the ability
(natively) to call api's. And then there are also countless
"full-blown" languages (including vb) which will accommodate
api calls.
cheers, jw
mr_unreliable
> 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
mayayana
>
> 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? :)
p byers
mr_unreliable wrote:
Thank you for your advice - it was very comprehensive.
You said "(other than my own API Toolkit)" - please tell me a URL
so that I can have a look at it as well.
At the moment, XNEAT seems easiest to use
BUT
I bought the XNEAT clipboard and asked for support/advice but
never got any - so Im a bit wary !!
I am just idly curious if these products would work in the
VBScript of active server pages ??
I understand your comments - but I have a dilema
1. The DLL in question writes to and reads from
hardware connected by USB to the PC.
2. The DLL is supplied with the hardware and has
sample C++ and VB code.
3. I want to read from an Access database and send
it to the Hardware.
AND
Read from the Hardware to write it to the database.
4. I can do it with VBS at no cost and can gain knowledge.
5. C++ is a non starter for me.
6. To use VB, I have to buy and learn VB
OR
Pay someone to write and compile it for me.
AND
would have to install VB runtime stuff on the Target PC.
For your interest, the database would be silently Mirrored
with a copy on a public Website.
Then the Hardware can be controlled from secure Internet Web pages.
So the DLL question is a small part of a big and exciting project
AnyRoadUp, thank you for your help and interest
Pete (Northolt UK)
Alan Gillott
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 doesn't, 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 isn't that difficult esp. if you've 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).
"p byers" <p...@sst-ltd.co.uk> wrote in message
news:4B48C22A...@sst-ltd.co.uk...
mayayana
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.
Mike B
"mayayana" <mayaX...@rcXXn.com> wrote in message
news:etxkdjtk...@TK2MSFTNGP06.phx.gbl...
> 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
>
>
> 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.
>
<applause> synopsis accepted. </applause>
mr_unreliable
> Thank you for your advice - it was very comprehensive.
>
> You said "(other than my own API Toolkit)" - please tell me a URL
> so that I can have a look at it as well.
>
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) can't 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 don't have
to extensively re-write Paul's code. In other words, even
though I am recommending it, I haven't 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