What is the optimal high level language for batch files

[skorpio07]

i have a few .cmd files that i would like to compile for distribution on other computers.
 
i have looked at:
Quick Batch File Compiler
BatLite
Bat2Exec
Batch File Compiler PE (Advanced Bat 2 Exe Converter 2.49)
Batch Compiler v3.1.2
Bat to Exe Converter
ExeScript
PowerBatch
 
all have basically failed to have the compiled version run like the batch version. (the closest is Bat2Exec which allows the compiling but then the .com file does not work like the batch file).
 
the lines that seem to fail or not work is:
 
if exist %some_variable_name% do command or if not exist %some_var_name% do command
 
also i use the SET command (or the SETX extended command) which seems to fail as well. (ie set somevarname=avalue, or setx somevarname avalue).
 
it looks like i will need to move up to a higher level language that will allow me to set the environment variables and have them "stick" upon exit.
 
what would be the best software package that would allow me move my batch files to?
 
any help would be appreciated.
 
thanks
   

[Squashman]

The issue becomes that most of these Bat 2 Exe programs have is that they are just self extracting executables.  Many of them extract themselves to the Windows or Users Temp folder.  So if the batch file needs to look for a file in that location it is not going to find it because the working directory is now the TEMP folder and not the folder you need to process.
So if you are looking to see if a file EXISTS, it is checking to see if it exists in the TEMP folder.

I believe Salmon Trout did a right up on this very affect in a previous thread a couple of days ago.

Remember that SETX is not native to Windows XP. That is part of the Support tools.  It may not be loaded on every person's computer that needs to run the batch file.

[Squashman]

Here is that post by Salmon Trout.
http://www.computerhope.com/forum/index.php/topic,125819.msg822623.html#msg822623

[skorpio07]

Thanks squashman..
 
i had seen this article before, but it did not mention my issues...
 
and the if exists statement is NOT looking for filenames, it is looking for folders/directories
 
the core of my command is this:
either
set return=%cd%
or
setx return %cd%
 
then this might run afterwards:
 
if exist %return% goto returnlabel   (or if not exist %return%...)  (to make this work in compilers, i did: if not "%return%"=="" goto returnlabel
 
both the set(setx) and the if exist do not run properly
 
as for setx, i believe that it is included in Vista/Win7 if I am not mistaken. but yes, my routine does test for the presence of the setx command.
 

The issue becomes that most of these Bat 2 Exe programs have is that they are just self extracting executables.  Many of them extract themselves to the Windows or Users Temp folder.  So if the batch file needs to look for a file in that location it is not going to find it because the working directory is now the TEMP folder and not the folder you need to process.
So if you are looking to see if a file EXISTS, it is checking to see if it exists in the TEMP folder.

I believe Salmon Trout did a right up on this very affect in a previous thread a couple of days ago.

Remember that SETX is not native to Windows XP. That is part of the Support tools.  It may not be loaded on every person's computer that needs to run the batch file.

[Squashman]

and the if exists statement is NOT looking for filenames, it is looking for folders/directories

That is irrelevant.  My original statement still holds true.

[skorpio07]

But my program does not extract files...it is not an installer...its primary job is to set environment variables...
 
when i run the: set return=%cd%
this produces a path like: c:\windows\system32
 
how does the exe batch file uncompressing itself to a temp folder override my explicit path set for the environment variable "return"??
 
please illuminate 
 
fyi, still looking for that next best high level language to port the batch files to...
 

That is irrelevant.  My original statement still holds true.

[Salmon Trout]

This thread just goes to prove what I (and others) have said before, namely that batch-to-exe converters are a bad thing, and not for any serious work. The first question that comes to mind, is why bother to hide the batch script? If the answer is "to hide my code from the prying eyes of people who might want to steal my ideas", then my answer would be "If you are still at the level of batch scripting, then your ideas are almost certainly not worth stealing". Many people, when presented with an .exe file of unknown origin, wonder "what does this thing do?" If the answer from the supplier is "I'm not going to tell you, and I have deliberately hidden the code" then that is a warning sign straight away. Also the use of setx makes me wonder just what the *censored* is going on. If the motivation is to make something that looks "professional" then just dressing a batch file up with a wrapper is not going to do this. There are plenty of compiled languages which are free and can make exes.  C, C++, FreeBasic, there are a ton of them. Even Auto-It can make an exe file. If you want to make a proper program, put in the effort with a proper language.

Now to some specifics: all that most batch-to-exe converters do is create a self-extractor that spits out the original batch file into a convenient folder (usually the current user's temp folder) and then runs it from there. Therefore anything that expects to find folders and files that are defined as relative to the .exe file or its folder is not going to work. Secondly, some of those converters are for MS-DOS which is not the same as Windows NT family command prompt. I notice that Quick Batch Compiler is payware, so did you pay for this or is a cracked version? BatLite is MS-DOS only. So is bat2exec. Batch File Compiler PE is payware, so again did you crack it? (You sure have listed a lot of payware there!)  Batch Compiler v3.1.2 needs a runtime: .NET Framework v1.1. The "compiler" is written in C# .NET and as such requires the .NET runtime to run. Bat to Exe Converter is free, exescript is payware, so is powerbatch. Batlite and Bat2Exec produce 16-bit .com executables which will not run on 64 bit operating systems.

[Salmon Trout]

how does the exe batch file uncompressing itself to a temp folder override my explicit path set for the environment variable "return"??

Because %cd% (the current directory) will not be what you think it is.

[Squashman]

Put an ECHO %CD% in your batch file and put a pause after it, then compile it to an exe and run it and tell us what is output.

[BC_Programmer]

i have a few .cmd files that i would like to compile for distribution on other computers.

Either merge them all into one .cmd file and distribute that, or zip them up. A Batch "Compiler" (which there really is no such thing, as far as I've seen) will not really help with your particular issue, which is one of packaging. In fact, as Salmon Trout points out, many of the so-called compilers will add additional required components in order for a system to run the "compiled" result, such as the .NET framework. And of course if it generates a executable that executable will typically have it's own requirements; it could be 32-bit or 64-bit, which could change the assumptions made by the batch or it could in the case of a very old "compiler" be 16-bit, assuming it is able to "compile" at all.

I've been putting "compile" in quotes because it seems that there is a rather wide misconception that anything that turns one thing into an executable is a "compiler" but the definition is more or less that the program turns one set of instructions into another set of instructions. In the case of C/C++, the compiler turns C/C++ code into machine code for running on a given processor architecture, or even P-Code for running in the appropriate P-Code interpreter, which is often built-in to the program. C#/VB.NET compiles to IL, Java compiles to Java Bytecode, etc. But no Batch compiler I've seen actually does this- they all simply package up the batch file inside a wrapper executable and call it the "compiled result" when all it really does is extract the contained Batch file and execute it using the system, as normal. All it really does is add size and additional requirements to the batch file, as well as introducing any number of gotcha's based on broken assumptions, which Salmon Trout has gone through quite thoroughly before.

For your purposes, I reiterate my suggestion that distribution should be simply distribution of the .cmd files. If you need it all in one file, use a zip file, or even a self-extracting zip file. "compiling" to a executable will merely compound your problems.

[skorpio07]

lots of interest  , you guys are great
 
yes i agree that the batch compilers leave much to be desired. hence my looking into alternate programming languages to continue my coding in.
 
not to hide, but the source file is getting a bit large so as a way of making it run faster. there is nothing revolutionary about my code, all it does is set the current diretory (where ever i happen to be) to an environment variable, in this case called return.
 
and yes, i won't be selling my compiled wares    anytime soon. it is just basic stuff that i would like use on more than one machine on the network, be compact and run fast.
 
the use of setx is so that instead of using the set command (for the local DOS window), im setting the value for all future DOS windows (actually, after testing to make sure that SETX is valid, i run this: setx return %cd% & set return=%cd% The primary intent of the batch file is whether to set local or global env var's.. other than choice (though i could use set/p), setx is the only external file that runs in the routine. All the rest are batch related (ie rem's, labels', if's and for's)
 
now to the goodies:
so i put in the echo %cd% (plus lots of other stuff) to see what the compiled version showed. and certainly enuf, the echo %cd% showed as... nothing  (i put in the line: echo %%cd%% is %cd%). so during runtime, there is no apparent directory. where i did get an unexpected hit was with this line: echo The filename will be %~n1
this spit out something like this: the filename will be CDCURRDIRCURRDIRTEMPTSTERRORLEVELTEMPTS T ╨ì╢ßC:\WINXP\SYSTEM32
what i had expected was this: the filename is C:\winxp\system32\sp, so clearly the %1 parameter for the command (just a filename is all) is undergoing changes at runtime.
 
but all of this is not to fix the obvious shortcomings of the compilers as what to use to do the new coding with??
 
im pretty good at vb, lisp and some c++, so i will take a look at what you suggest. as for quick batch compiler, im running that in trial mode (ver 3.2.9) (and the PE version im incorrect about, it looks like its just the batch compiler standard, using nem's tools)
 

This thread just goes to prove what I (and others) have said before, namely that batch-to-exe converters are a bad thing, and not for any serious work. The first question that comes to mind, is why bother to hide the batch script? If the answer is "to hide my code from the prying eyes of people who might want to steal my ideas", then my answer would be "If you are still at the level of batch scripting, then your ideas are almost certainly not worth stealing". Many people, when presented with an .exe file of unknown origin, wonder "what does this thing do?" If the answer from the supplier is "I'm not going to tell you, and I have deliberately hidden the code" then that is a warning sign straight away. Also the use of setx makes me wonder just what the *censored* is going on. If the motivation is to make something that looks "professional" then just dressing a batch file up with a wrapper is not going to do this. There are plenty of compiled languages which are free and can make exes.  C, C++, FreeBasic, there are a ton of them. Even Auto-It can make an exe file. If you want to make a proper program, put in the effort with a proper language.

Now to some specifics: all that most batch-to-exe converters do is create a self-extractor that spits out the original batch file into a convenient folder (usually the current user's temp folder) and then runs it from there. Therefore anything that expects to find folders and files that are defined as relative to the .exe file or its folder is not going to work. Secondly, some of those converters are for MS-DOS which is not the same as Windows NT family command prompt. I notice that Quick Batch Compiler is payware, so did you pay for this or is a cracked version? BatLite is MS-DOS only. So is bat2exec. Batch File Compiler PE is payware, so again did you crack it? (You sure have listed a lot of payware there!)  Batch Compiler v3.1.2 needs a runtime: .NET Framework v1.1. The "compiler" is written in C# .NET and as such requires the .NET runtime to run. Bat to Exe Converter is free, exescript is payware, so is powerbatch. Batlite and Bat2Exec produce 16-bit .com executables which will not run on 64 bit operating systems.

[skorpio07]

yup your right... once compiled, the echo the current directory is %cd% did not display, all that showed was: the current directory is
 
thanks
 

Put an ECHO %CD% in your batch file and put a pause after it, then compile it to an exe and run it and tell us what is output.

[skorpio07]

sorry, what i meant to say was that i have individual files that need compiling, i don't want to have a bunch of files uncompress somewhere. im not trying to "group" my batch files and distribute them (for that i would use zip)
 
thanks for the info, very helpful.
 

Either merge them all into one .cmd file and distribute that, or zip them up. A Batch "Compiler" (which there really is no such thing, as far as I've seen) will not really help with your particular issue, which is one of packaging. In fact, as Salmon Trout points out, many of the so-called compilers will add additional required components in order for a system to run the "compiled" result, such as the .NET framework. And of course if it generates a executable that executable will typically have it's own requirements; it could be 32-bit or 64-bit, which could change the assumptions made by the batch or it could in the case of a very old "compiler" be 16-bit, assuming it is able to "compile" at all.

I've been putting "compile" in quotes because it seems that there is a rather wide misconception that anything that turns one thing into an executable is a "compiler" but the definition is more or less that the program turns one set of instructions into another set of instructions. In the case of C/C++, the compiler turns C/C++ code into machine code for running on a given processor architecture, or even P-Code for running in the appropriate P-Code interpreter, which is often built-in to the program. C#/VB.NET compiles to IL, Java compiles to Java Bytecode, etc. But no Batch compiler I've seen actually does this- they all simply package up the batch file inside a wrapper executable and call it the "compiled result" when all it really does is extract the contained Batch file and execute it using the system, as normal. All it really does is add size and additional requirements to the batch file, as well as introducing any number of gotcha's based on broken assumptions, which Salmon Trout has gone through quite thoroughly before.

For your purposes, I reiterate my suggestion that distribution should be simply distribution of the .cmd files. If you need it all in one file, use a zip file, or even a self-extracting zip file. "compiling" to a executable will merely compound your problems.

[BC_Programmer]

what i meant to say was that i have individual files that need compiling

OK, but why do you need to compile them?

As I noted, it's really impossible to "compile" the batch files. I'm not really sure what you are aiming for; you want it to "run faster"; really the only way to do that would be rewrite the entire thing in another language. And only if performance has become an issue for the tasks that the batch file performs.

As per your original question "What is the optimal high-level language for batch files", I don't think the question really makes sense; there is only one language to choose from for batch files, and that is the batch language. If you are asking what other high-level language would be the easiest to port to, well... none of them. You would end up rewriting it from scratch anyway, which makes the question sort of moot.

[Salmon Trout]

skorpio07, we keep asking you:

Why don't you just use the batch files, why do you have to turn them into exes?

and you don't answer.