The Portable Freeware Collection Forums

This is in response to http://portablefreeware.com/forums/view ... hp?p=15194

In another forum, someone was asking about nircmd, and its exclusion from the database. The reason for exclusion is that most all console, or "DOS" apps (as use older folk knew of them) apps can be considered portable.

I rejected Portabilizer, and some other means of making an interface for command line apps due to one flaw: command line parameters that are variable don't seem to be included. PStart suggests command line parameters, but I have not been able to get them to work.


My own workaround: BatToExe v1.4 (http://www.f2ko.de), some of Horst Schaeffer's 32-bit batch apps with prompts (http://home.mnet-online.de/horst.muc/win.htm), and the command line app in question.

I create a .bat file, using the Schaeffer utilities to ask the prompts. I then put the .bat file with the used utilities into one directory, and compile with BatToExe in Ghost Application mode (keeps the console from appearing!)

Note: to make the program stealth, the app in question must be stealth, and the batch file must clean up its files after itself, as the first thing it does is extract the Schaeffer utilites and the app program(s).

"Compiled" batches have no bug-free way to store relative paths.
Therefore I recommend not to use it. Batches themselves are better.

m^(2) wrote:"Compiled" batches have no bug-free way to store relative paths. Therefore I recommend not to use it. Batches themselves are better.

Looking into this: what about environment variables or temporary text files?

Midas wrote:

m^(2) wrote:"Compiled" batches have no bug-free way to store relative paths. Therefore I recommend not to use it. Batches themselves are better.

Looking into this: what about environment variables or temporary text files?

Wow, an old thing.
I don't know what do you mean by "environment variables or temporary text files". To do relative paths right, you'd have to first know the directory in which your batch is placed and with most compiled batches you have no way to get it, %cd% can be anything and %~dp0 is some file in temp.

Anyway, I remember seeing a "compiler" that hacked the issue, after a quick look it looked OK.
It took your batch and built another from it; one that did a 'shift' and run your code.
The exe launcher would extract the script to text (like all batch 'compilers' do) and execute from there, but providing own exe path (or something like that) as the first parameter and passing parameters that it got after it.
This way, the user batch had exe name as %0 and all other parameters after it, about the same as it would get by not being "compiled" in the first place, so you could use %~dp0 and have it working. Still it didn't work correctly with some fun stuff (like self-modifying scripts), but for 99% of users should be good enough.

So if you really want to "compile", I recommend using that "compiler".
You may ask how is it called...I don't know, it was a brief look years ago. Others might be able to help. I think sb. from here showed me the program.

I think you will find that AutoHotkey scripts can do anything a batch file can do, and far more. The syntax is very similar and easy to learn, the only drawback is that a compiled AHk script will have a much larger file size than a batch file. A minimum of about 400kb.

m^(2) wrote:I don't know what do you mean by "environment variables or temporary text files". To do relative paths right, you'd have to first know the directory in which your batch is placed and with most compiled batches you have no way to get it, %cd% can be anything and %~dp0 is some file in temp.

I think you answered it anyway, m^2. Thanks for the feedback, fellas, much appreciated...

You can also compile .vbs files to .exe - much easier and more powerful scripting.
The problem with .bat to .exe compilers is that they just extract the .bat file to your %temp% and then run the .bat from there.
With true .vbs to .exe compilers such as ScryptCryptor (commercial software) - they run completely in memory without using any intermediary temporary file creation.

robertcollier4 wrote:You can also compile .vbs files to .exe - much easier and more powerful scripting.
The problem with .bat to .exe compilers is that they just extract the .bat file to your %temp% and then run the .bat from there.
With true .vbs to .exe compilers such as ScryptCryptor (commercial software) - they run completely in memory without using any intermediary temporary file creation.

I have tried Abyssmedia software (QBFC with free trial)
and they are pretty awesome compilers

but not important enough for me to shell out 50 bucks
are there any freeware softwares that are comparable?

edit
from the same site as Bat2EXE
VBS to EXE
Havent tried it tho, so I dont know if its as good as ScryptCryptor

I tried ExeScript 3.0 but could never get any of my conversions to work
(script errors...I dont know alot about VBS)

robertcollier4 wrote:You can also compile .vbs files to .exe - much easier and more powerful scripting.
The problem with .bat to .exe compilers is that they just extract the .bat file to your %temp% and then run the .bat from there.
With true .vbs to .exe compilers such as ScryptCryptor (commercial software) - they run completely in memory without using any intermediary temporary file creation.

There was a real compiler for batches, but nobody cared to port it to 32 bit architecture, so it's pretty useless nowadays.

HTWOO by Hadi Kiamarsi is a great tool I have found for a free VBS-to-EXE compiler. It is listed as a tool for "Python script to EXE" but then you find out that it also does VBS to EXE and many more compilations for free. It should probably be added to the portablefreeware database.



Download: https://sourceforge.net/projects/htwoo/
Youtube Tutorial: convert-vbscript-to-exe-by-hadi-kiamarsi: http://www.youtube.com/watch?v=NWOFt0SYyEo
Youtube Tutorial: convert-javascript-to-exe-stand-alone-file-by-hadi-kiamarsi: http://www.youtube.com/watch?v=ldbzKvAsVE8
Youtube Tutorial: convert-bat-file-to-exe-stand-alone-file-by-hadi-kiamarsi: http://www.youtube.com/watch?v=zkRJlTxN4w0

The icon for the compiled EXE can be changed from the default via Resource Hacker.

Another great example use of a VBS-to-EXE is to pass arguments to rename-replace an EXE without needing to change the associations to that original EXE. For example, for chrome.exe - if you want to pass arguments on every open, it is very difficult since chrome.exe has associated itself in numerous places in the registry for .URL shortcuts, .HTM shortcuts, HTTP handlers, StartMenu handlers, etc. To make Chrome portable - rename chrome.exe with chrome2.exe and then replace chrome.exe with the following compiled VBS-TO-EXE file. It is made portable with flag "--user-data-dir" and you can also specify any additional flags such as "--disable-new-menu-style" and "--new-window".

Inside a quoted string, two-quotes escapes to a single-quote. Below example shows how to detect args and also double up "" to have a literal quote character inside of a quoted string.

Thanks for the tip, might become handy for some inflexible buggers around here...