HTML, JScript, VBScript to EXE online converter

Hello all,

Please check this online free converter and tell me your feedback.

http://www.vbs2exe.com/

Thanks in advance,
Sa6ry

Massi
Thu Mar 13 12:37:37 CDT 2008

Il 13/03/2008, Sa6ry ha detto :

> http://www.vbs2exe.com/

new version? :)

mayayana
Thu Mar 13 13:15:34 CDT 2008

Your page converts a 2-line custom API
script to a 104 KB EXE that's not actually a real
EXE but rather a .Net "assembly", adding another
70MB+- of dependency. It's hard to see how
that's a better method than a self-executing
zip file. You're really providing a way to write
a simple .Net program, complete with API calls,
using script. But doesn't that really lose the
advantages of each? Someone who can handle
writing to the API is better off not using .Net and
certainly better off not using script.

I can see your point about avoiding the extreme
security around script files, but I'm not so sure
this is the best solution.

Sa6ry
Thu Mar 13 13:31:01 CDT 2008

yes, now you can add js, vbscript , html .

hope you find it useful. currently i am adding more features, expect a new
update soon

"Massi" wrote:

> Il 13/03/2008, Sa6ry ha detto :
>
> > http://www.vbs2exe.com/
>
> new version? :)
>
>
>

Sa6ry
Thu Mar 13 13:39:02 CDT 2008

hello mayayana,

what you mean by .Net assembly !!! , the output is win32 EXE. it doesn't
require .Net runtime.

I simply wrote another wscript.exe but with more features like calling win32
API.

and knowing that wscript.exe is 112kb so 104kb makes sense.

"mayayana" wrote:

> Your page converts a 2-line custom API
> script to a 104 KB EXE that's not actually a real
> EXE but rather a .Net "assembly", adding another
> 70MB+- of dependency. It's hard to see how
> that's a better method than a self-executing
> zip file. You're really providing a way to write
> a simple .Net program, complete with API calls,
> using script. But doesn't that really lose the
> advantages of each? Someone who can handle
> writing to the API is better off not using .Net and
> certainly better off not using script.
>
> I can see your point about avoiding the extreme
> security around script files, but I'm not so sure
> this is the best solution.

mayayana
Thu Mar 13 18:03:24 CDT 2008

> what you mean by .Net assembly !!! , the output is win32 EXE. it doesn't
> require .Net runtime.
>

I didn't try to run it, but the file references
mscoree.dll and has a path to a .Net debug
file embedded:
d:\Work\Vbs2exe\ExeTemplate\Release\ExeTemplate.pdb

Maybe I'm wrong, but I can't imagine how anything
that's not .Net would be using mscoree.dll.

Sa6ry
Thu Mar 13 20:08:00 CDT 2008

you are right, that is very strange !!

I have made some googling and here is what i come with
http://www.themssforum.com/VC/CorExitProcess/

win32 exe compiled with VC++ call CorExitProcess if mscoree.dll exists.

Don't ask me why !!! check the above link they are are speaking about that.

if you have Virtual machine you can try running the exe. understand your
concerns! ,but it is the same risk as downloading any other exe from the net.
anyway i hope by time this project becomes more mature and gains more
credibility from the community.

btw, I have build a very popular product called xNeat (windows automation
wriitten using VBScript) you can find it here http://www.xneat.com/ ,
actually vbs2exe is subset of xNeat.

xNeat GUI is totally written using vbs2exe. and the 90% of the code is
writing using VBScript.

I write code using c#,vb,c++,win32assembly and for me i believe the easiest
way to build GUI is using HTML. that is what i try to make with vbs2exe
making it

Build your GUI using HTML & Javascript.
Make your code using VBScript and when you stuck in something make some
calls to win32 API.
If you really want to make a very low code, write it in a dll and call it
form VBScript.
and after you finish hide your source code.

that is all :)

btw, you may give www.vbs2exe.com another look i have added html converter


Regards,
Sa6ry


"mayayana" wrote:
> I didn't try to run it, but the file references
> mscoree.dll and has a path to a .Net debug
> file embedded:
> d:\Work\Vbs2exe\ExeTemplate\Release\ExeTemplate.pdb
>
> Maybe I'm wrong, but I can't imagine how anything
> that's not .Net would be using mscoree.dll.

mayayana
Thu Mar 13 22:16:38 CDT 2008


> you are right, that is very strange !!
>
> I have made some googling and here is what i come with
> http://www.themssforum.com/VC/CorExitProcess/
>
> win32 exe compiled with VC++ call CorExitProcess if mscoree.dll exists.
>
> Don't ask me why !!! check the above link they are are speaking about
that.
>

I see what you mean. That is strange. Even stranger is
that it seems to be an optional call. After my last post
I ran your EXE through Depends and saw that it was
as you said - dependencies only on basic system
files.


> if you have Virtual machine you can try running the exe. understand your
> concerns! ,but it is the same risk as downloading any other exe from the
net.
> anyway i hope by time this project becomes more mature and gains more
> credibility from the community.
>
> btw, I have build a very popular product called xNeat (windows automation
> wriitten using VBScript) you can find it here http://www.xneat.com/ ,
> actually vbs2exe is subset of xNeat.
>

I'll take a look at that. Thanks. I don't really understand
what it is that you've written, so maybe that will help
explain it. I get the concept of a WSH replacement, but
then the sample online seems to actually be some sort of
custom script used with your XNHost to make an API call.

> xNeat GUI is totally written using vbs2exe. and the 90% of the code is
> writing using VBScript.
>
> I write code using c#,vb,c++,win32assembly and for me i believe the
easiest
> way to build GUI is using HTML.

I know what you mean. I've written a number of small
programs as HTAs. It's quick, fun, and less exacting than
compiled code.

mr_unreliable
Fri Mar 14 13:29:24 CDT 2008

Sa6ry wrote:
> I have made some googling and here is what i come with
> http://www.themssforum.com/VC/CorExitProcess/
>
Your browser must be way better than mine (Firefox).

I entered that location, and got 404 error (page not
found).

Then I entered it into google, and it pointed to
the same place, which got ANOTHER 404.

Finally, I clicked on the "cached" version of the
page which was offered by google, and then the page
did come up. Just in case anybody else is chasing
the lost "CorExitProcess" page, try looking here:

http://209.85.165.104/search?q=cache:N4xx1rCAvCMJ:www.themssforum.com/VC/CorExitProcess/+themssforum+vc+corexitprocess&hl=en&ct=clnk&cd=1&gl=us

cheers, jw

mayayana
Fri Mar 14 22:53:21 CDT 2008

> > http://www.themssforum.com/VC/CorExitProcess/
> >
> Your browser must be way better than mine (Firefox).
>
> I entered that location, and got 404 error (page not
> found).
>

I just tried it again. It works fine for me. Maybe MS
is blocking your Win98. :) I'm also using Win98 but
I just happen to be using a WinXP userAgent string
lately. (Just kidding, though. I've seen MS cause
deliberate trouble for Firefox, but causing trouble
for "end-of-lifed" OSs seems unlikely.)

mr_unreliable
Sat Mar 15 09:21:47 CDT 2008

mayayana wrote:
> I just tried it again. It works fine for me. Maybe MS
> is blocking your Win98. :) I'm also using Win98 but
> I just happen to be using a WinXP userAgent string
> lately. (Just kidding, though. I've seen MS cause
> deliberate trouble for Firefox...

Yes, probably not a DELIBERATE attempt by ms to undermine
firefox, but when I tried IE6 I was able to retrieve that
page just fine.

otoh, when I tried to SAVE the page with IE6, ms told
me that "This web page could not be saved" -- even though
firefox was able to save the cached version.

ain't this fun?, jw

p.s., despite this experience, I'll be sticking with ff for
a number of reasons. Sorry, microsoft...

mayayana
Sat Mar 15 09:55:11 CDT 2008

> ain't this fun?, jw
>
> p.s., despite this experience, I'll be sticking with ff for
> a number of reasons. Sorry, microsoft...

I've also had trouble with MSDN2 using Firefox, though
in a discussion on another group one day, no one else
had the same trouble. I see a gray panel on the right,
blocking the page content, unless I use View -> Page Style
-> No Style. Maybe it has something to do with having
script disabled. I don't know. I dissected one of the pages
and found that it seemed to be connected with the menu
tabs at top having no size limits, but I didn't find the exact
error in the code.

Until recently I was getting
MSDN2 with no scrollbars and all of the content shifted to
the right.

And of course, that's when I can get their pages
at all. I don't understand what MS is doing with their site.
I now *expect* to get a 404 with no forwarding link for
any MS link that's more than a month old. And if I find a
page at all, I expect it to malfunction unless I disable CSS.

I haven't used IE online since about 2000, when an upgrade
to IE5 caused IE to run in slow motion whenever I went online.
I never figured out the problem and ended up switching to
Netscape. Now that I know more about online security I wouldn't
consider using IE online. Though today I came across an article
by Ed Bott:
http://blogs.zdnet.com/Bott/?p=385&page=10

He talks about IE7Pro. Apparently it adds many of the
amenities of Firefox into IE: ad blocking, flash blocking,
userAgent switching, etc. Seems like a case of a silk purse
from a sow's ear to me, but for anyone who really wants to
use IE it looks very useful.

mayayana
Sat Mar 15 14:13:01 CDT 2008

> by Ed Bott:
> http://blogs.zdnet.com/Bott/?p=385&page=10
>
> He talks about IE7Pro. Apparently it adds many of the
> amenities of Firefox into IE: ad blocking, flash blocking,
> userAgent switching, etc. Seems like a case of a silk purse
> from a sow's ear to me, but for anyone who really wants to
> use IE it looks very useful.
>

Woops.
An addendum to that: IE7Pro appears to be spyware.
According to the EULA one has no choice but to let
it contact home and install updates. It also "lets you
choose" whether to send information to homebase, but
that option may not apply to "additional services"...and
they reserve the right to change the functionality of the
software at any time without telling you...etc., etc.
In short, it's a mickey mouse license for spyware.

Which highlights one of the biggest problems with IE,
which many people are unaware of: Any software addon,
BHO, browser extension, toolbar, etc. is loaded with each
instance of IE or a folder window. The component gets
full access to the document object or folder content,
and has the ability to alter the page viewed in IE, to the
same extent possible in dynamic scripting. For instance,
IE7Pro or any other IE addon could do something like write
dynamic click event code into all pages loaded in IE, then
send information about the click to a remote website via
an image request.

mr_unreliable
Sat Mar 15 20:52:22 CDT 2008

mayayana wrote:
> I've also had trouble with MSDN2 using Firefox, though
> in a discussion on another group one day, no one else
> had the same trouble. I see a gray panel on the right,
> blocking the page content...

Yes, I get those gray panels too with ff, but they don't
bother me.

Apparently msdn has coded their "drop menus" in such a way
that will cause the "drop menus" to display (without the
menu items) when ff loads the page -- so one sees only
"gray panels".

My strategy is to simply pass the mouse across the "menu bar",
starting with the first (upper-left) item. Note that these
"menu bars" are sometimes two-or-three lines long. This will
cause all those "gray panels" to (first) extend, and then
retract -- allowing one to go ahead and read the page content.

cheers, jw

p.s. In general browsing situations, ff does just fine.
I suspect that most webpage designers attempt to work over
their webpages to insure that they will render properly with
most of the commonly-used browsers. Of course, microsoft
KNOWS that everybody uses IE -- so why bother catering to
those few of us who use some obscure browser like ff...

mayayana
Mon Mar 17 09:03:08 CDT 2008

> > I've also had trouble with MSDN2 using Firefox, though
> > in a discussion on another group one day, no one else
> > had the same trouble. I see a gray panel on the right,
> > blocking the page content...
>
> Yes, I get those gray panels too with ff, but they don't
> bother me.
>
> Apparently msdn has coded their "drop menus" in such a way
> that will cause the "drop menus" to display (without the
> menu items) when ff loads the page -- so one sees only
> "gray panels".
>
> My strategy is to simply pass the mouse across the "menu bar",
> starting with the first (upper-left) item. Note that these
> "menu bars" are sometimes two-or-three lines long. This will
> cause all those "gray panels" to (first) extend, and then
> retract -- allowing one to go ahead and read the page content.
>

I thought it might be a menu code bug. When I tried removing
code from a downloaded page that section seemed to be what
made the difference. But your trick doesn't work for me. Maybe
their menus require script, which I never enable unless absolutely
necessary.
(IE can't handle the CSS hover pseudo-class, so unlike all other
browsers, a dropdown/popout menu for IE has to be scripted.)

Viewing with "No Style" works, even
though it doesn't look as nice as the standard format.

mr_unreliable
Mon Mar 17 11:59:40 CDT 2008

mayayana wrote:
> But your trick doesn't work for me. Maybe their menus
> require script, which I never enable unless absolutely
> necessary.
>
Yes, I am allowing jscript (at least in Microsoft's msdn
case).

And yes, the behavior I am observing has every appearance
of being scripted -- for example: the drop menus drop-VERY-
SLOWLY, and then they retract-VERY-SLOWLY, as if microsoft
were striving for some sort of sophisticated effect (or
maybe it's just ms's expecting a giga-hz system whereas
what they are getting in my case is a mega-hz system).

cheers, jw

enleverlesX
Mon Mar 17 15:58:42 CDT 2008

Hi!

Thanks! It's cool.

But, my third test (HTML) fail on this JScript line :
var wpx=open("","PBridge");
(the goal is to connect to an opened IE-window).
The message is "Permission refusée" (in french) (try translation: "no
permit", or "deny", or "not authorized" ; sorry for my bad english).

@-salutations
--
Michel Claveau