Re: convert VB script code to vb (cheap & dirty)
From: mr_unreliable (kindlyReplyToNewsgroup_at_notmail.com)
Date: 02/17/05
- Next message: Jason: "LDAP Search Script - Issue Querying Terminal properties"
- Previous message: Selmac: "Outlook - Changing SMTP Ports VBScript"
- In reply to: Frank: "convert VB script code to vb application"
- Next in thread: Michael Harris \(MVP\): "Re: convert VB script code to vb (cheap & dirty)"
- Reply: Michael Harris \(MVP\): "Re: convert VB script code to vb (cheap & dirty)"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 17 Feb 2005 11:47:54 -0500
While converting a vbScript to VB is the "right way" to get
an exe, there are other "cheap-and-dirty" ways to do it.
Most likely you have not seen these c&d methods mentioned
here, because most newsgroupies are mature-and-responsible
professionals who wouldn't even consider something that was
cheap-and-dirty.
However, just in case any immature non-professionals are
lurking about, here is a brief discussion.
C&D #1. Another scripting language (which shall remain
nameless so as not to embarrass Microsoft), makes up a bundle
of the compiler, the runtime, your script and a little
"start-up code", and writes it all into a file with an exe
extension. When you run the exe, the "start-up code" copies
the compiler, the runtime and your source code into temporary
files (in win/tmp), and then starts up the compiler, giving
it the locations of the runtime and the source code. In
effect, this is just recreating the situation that you start
with (i.e., running your vbs with wscript). The exe is just
a means of transporting the bundle to another machine. With
respect to wsh/vbs, one could implement this approach
more-or-less directly. There is even some sample code for
this, to be found on the vb source code sites on the web
-- look for: do-it-yourself installer code...
C&D #2. Another scripting language (which shall remain
nameless to avoid embarrassing Microsoft), also makes up a
bundle -- but this time it contains "byte-code" (a.k.a.
p-code), a runtime, and "start-up code". When you run it
on the destination machine, you get something more efficient
than C&D#1. The "start-up code" runs the embedded "byte-
code" directly, using the runtime to interpret the b-c
instructions into machine language. There is no preliminary
task of copying files, and no compilation process. The exe
may be a little bloated (as compared with having the runtime
as a separate dll), but as we said -- it is more efficient.
This could also be done with wsh/vbs, but would take a
little bit more trouble to set it up. As I understand it,
wsh compiles the vbs to p-code, and then runs it. My best
guess is that the p-code is retained in memory while your
script executes. Joe Hacker would have to copy that p-code
out of memory and into a file, along with wscript, and
maybe the runtimes (depending on how comprehensive a
package Joe wishes to create). The "start-up code" would
then load wscript and the p-code into memory, and jump
into wscript (at the place where wscript thinks that it is
done compiling), and execute the p-code. Obviously, this
method would require some research (a.k.a. "reverse
engineering" -- a practice frowned upon by ms). This
research probably wouldn't pay off unless one needed to
"convert" a vast number of scripts to exe's. The benefit
would be a relatively efficient bundle...
C&D#3. This method is relatively "clean", with one
exception. It involves using vb to compile an exe which
instantiates the Microsoft Script Control. You would
build your script into the exe by compiling it as a
"resource file", -- or a more simple-minded approach
would be to include it as a giant string (subject to some
limitations). The exe would just load the string into
the script control and run it. Now for the exception part:
there is no wscript object accessible from within the ms
script control, so you would have to write one. I would
assert that writing your own wscript object is not all that
difficult. WScript has only about 20 "members" (methods
and properties), which are all "do-able" using either
built-in vb features or api's. This is a bit of a hassle,
but may be mitigated somewhat if your script doesn't use
all the wscript methods and properties that are available.
There are also a few hidden "gotchas". For example,
wscript.sleep can not be simply duplicated by using the
sleep api. If you read the newsgroup archives carefully,
you will find that wscript.sleep is a combination of the
sleep api, and something that vb programmers call
"DoEvents". I won't go further, because there is an
explanation in the archives, but care needs to be taken
to duplicate the wscript internals exactly.
While these "cheap-and-dirty" approaches are tempting,
all things considered, you can most likely just as
easily convert your script code directly to vb.
Personally, I go back-and-forth all the time with very
little effort. If you google the archives you will find
little nuggets of advice about converting, like declaring
your variables as variants, etc.
An even more radical approach would be to take up some
other scripting language, which DOES have the capability
of producing an exe. It may even have a longer expected
life-time than vbs, especially if you are willing to
fork over up a little payment (kleingeld) to the developer.
cheers, jw
Frank wrote:
> I am wondering is there a way to convert a vbscript code to vb code and
- Next message: Jason: "LDAP Search Script - Issue Querying Terminal properties"
- Previous message: Selmac: "Outlook - Changing SMTP Ports VBScript"
- In reply to: Frank: "convert VB script code to vb application"
- Next in thread: Michael Harris \(MVP\): "Re: convert VB script code to vb (cheap & dirty)"
- Reply: Michael Harris \(MVP\): "Re: convert VB script code to vb (cheap & dirty)"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
