convert VB script code to vb application
Frank
Steven Burn
--
Regards
Steven Burn
Ur I.T. Mate Group
www.it-mate.co.uk
Keeping it FREE!
"Frank" <signu...@sina.com> wrote in message
news:e4idrQA...@TK2MSFTNGP15.phx.gbl...
mayayana
VBS. The languages are similar but the details and
the context are different. You'd have to know VB and
rewrite your code, then compile. Some things, like
string operations, are almost the same in VB. Other
things, like the easy WScript.Shell registry operations,
translate to very complex Windows API operations in VB.
The whole point of script is to be easy, quick, transparent
and simple - with easy editing in case of changes or
problems. If you could compile script you'd get all of the
inefficiency of it, with none of the benefits. If you want to
make EXEs then you want to use a programming language.
--
_____________________________
mayayX...@mindYYspring.com
For return email remove XX and YY.
_____________________________
Frank <signu...@sina.com> wrote in message
news:e4idrQA...@TK2MSFTNGP15.phx.gbl...
mr_unreliable
be used DIRECTLY in vb, (resulting in a vbFrankenScript.exe).
Take the features of script that allow for reading/writing
the registry. You don't need to convert them to api calls.
You can use the "WScript.Shell" object directly in vb, by
instantiating it at runtime (with CreateObject) just the
same as vbs does it (gasp!). This is perfectly legit vb
code:
Set oSH = CreateObject("WScript.Shell")
sRegValue = oSH.RegRead(sRegKey)
vb coders call this "late-binding". With vb there is
another way to instantiate "WScript.Shell" (called
early-binding?). At "design time" you set a reference
to an item in the references dialog called:
"Windows Script Host Object Model"
To instantiate the "WScript.Shell" using this (early-
binding) approach, you would declare (using a dim stmt)
your object like this:
Dim oSH as New wshShell
Then this code would work (same as before):
sRegValue = oSH.RegRead(sRegKey)
Generally speaking, "real" vb-coders prefer the early-
binding approach. But, for simplicity in converting
script code, late-binding will work perfectly well.
This is maybe a little long-winded way of saying that
many of the vbs features (more specifically any of the
"objectified" ones), can be used in vb the same as vbs,
without converting to api calls. This applies to
"WScript.Shell", "Scripting.FileSystemObject", and
all the others you know and love.
cheers, jw
Michael Harris (MVP)
Dim oSH as New wshShell
This does not actually create an instance in VB6 (it does in VB.Net). It
causes VB to wrap all later code references to oSH with housekkeping code
that will create an instance if oSH is still nothing.
A more efficient style is to Dim without New and use the New operator when
explictly creating an instance when you actually need it.
Dim oSH as wshShell
...
...other code...
...
Set oSH = New wshShell
Even this will work and be early bound...
Set oSH = CreateObject("WSCript.Shell)
...which would fail only if the wrong progid were used.
--
Michael Harris
Microsoft MVP Scripting
http://maps.google.com/maps?q=Sammamish%20WA%20US
mr_unreliable
"Not to be picky???"
That is reminiscent of my mother's little speech always delivered
before spanking me: "This is going to hurt me more than you"...
And Yes, it is always reassuring to know that somebody will pick
up my errors, and correct them. As you can tell, I do have trouble
with "New", and when it is appropriate to use it in the "Dim" stmt,
vs. when to use it in the "Set" stmt.
However, it is somewhat comforting that you didn't quarrel with the
point of the posting. That is, if one wishes to convert script to
vb, one doesn't need to resort to api's in order to read/write the
reg, or to use other native scripting goodies in vb (fso, oSH, oDic).
cheers, jw
Michael Harris (MVP) wrote:
> Not to be picky but...
>
McKirahan
news:OZmK92HF...@TK2MSFTNGP14.phx.gbl...
Please don't top post or change the subject of the thread.
mayayana
Sheesh! Don't these people have scroll bars? :)
> However, it is somewhat comforting that you didn't quarrel with the
> point of the posting. That is, if one wishes to convert script to
> vb, one doesn't need to resort to api's in order to read/write the
> reg, or to use other native scripting goodies in vb (fso, oSH, oDic).
>
Of course you're right about VB using COM objects, but
I was trying to answer what the poster seemed to really be
asking: "Without knowing VB, can I just turn my script into
an EXE?" My point was that there wouldn't be much use in
taking inefficient script code and packaging it into an EXE....
that there are strengths and weaknesses with both ways
of doing things. Script is quick and easy but not very
efficient. Compiled code is leaner but takes more work.
There's not much sense taking the trouble to write compiled
code if one is just going to use it to call a lot of slow, bulky,
dependent COM objects like FSO, WScript.Shell, etc.
mr_unreliable
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
Michael Harris (MVP)
> 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.
>
> http://basic.mindteq.com/
>
Or try out ASE (The Admin Script Editor Home Page -
http://www.adminscripteditor.com/main.asp)...
Limited language support (vbscript, kix, autoit, and bat) but it does have a
script packager that builds an EXE (much like C&D #1).
If you like it, cost is $99 US.
I've used it and it works as advertised. My main complaint is the limited
language/file format support (see above and no support for
wsf/wsc/htm/hta/asp)...