What is the optimal high level language for batch files

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
   

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Not entirely true. Powershell will still recognize most batch commands. Also allows you to utilize VBScripts within the same "program." Might be the only other language available that would allow some porting options from batch.

Still, the OP may be much better off utilizing an actual programming language to accomplish whatever tasks that are needing accomplishment.

Or you could always reasearch and try writing your own program in machine language as well. Talk about efficiency. You take out the compiler aspect completely. Of course it will likely only work for your particular chipset, but it will work nonetheless.

Not entirely true. Powershell will still recognize most batch commands.

It doesn't recognize any batch commands. It does have a few commands that happen to have the same name as existing batch commands. Dir acts completely differently and is just an alias for ls, much as it is on most modern distros. sort doesn't execute the sort.exe 'external' command, and instead invokes the built-in sort cmdlet, which has a different syntax and usage.  Things like SetLocal, the addressing of variables using either percent signs or exclamation marks, and several other frequently used features are nonexistent or drastically changed in Powershell. set works differently. for is completely different altogether. there aren't goto's or labels, those would have to be replaced by functions. Commands like "Start", "fc", "if" and so forth are either noexistent (if), have completely different functions altogether (fc= File Compare in batch, Format_Custom cmdlet in Powershell), or have different parameters, limitations, and fiobles (start)).

Any non-trivial Batch script will end up being pretty much rewritten to be "ported" to Powershell. Powershell is closer to Bash than it is to Batch.

Also allows you to utilize VBScripts within the same "program."

No idea what this means. VBScript- and in fact the ActiveX Scripting Host- can be accessed from powershell, but I can't think of a way to integrate VBScripts into a Powershell script any better than the same type of echo method used in a batch for that purpose. The "integration" basically consists of still allowing you to execute CScript.exe from powershell.

Might be the only other language available that would allow some porting options from batch.

It offers no more portability for batch code than Bash. Nobody opens up a Batch Script in gedit and screws around with it until it works. You rewrite it using the native functionality of Bash; same for Powershell.

Still, the OP may be much better off utilizing an actual programming language to accomplish whatever tasks that are needing accomplishment.

Except Batch is "an actual programming language" as is Powershell. Thing is, it already sounds like they accomplished what they want in Batch, thus Salmon Trout's original question as to why they need to do anything further.

Or you could always reasearch and try writing your own program in machine language as well. Talk about efficiency. You take out the compiler aspect completely. Of course it will likely only work for your particular chipset, but it will work nonetheless.

I know this was probably facetious, but the compiled result from most modern compilers will be many times faster and more optimized than Machine code, unless that person has spent the last 40 years hand-tuning machine code. Same for Assembly, which would have been far saner to mention since there isn't a huge difference between Assembly and Machine code, that's why Assembly is assembled, it's basically a process of substitution of Assembly keywords with the appropriate machine instructions. Also, most of the "Batch compilers" I've seen tend to use a 32-bit executable to wrap the batch file which is no less machine-dependent than hand-tuned x86 Assembly. 

Well thank you for tearing apart my post. *goes into corner and cries ...comes back*

Yes I was being facetious with that last comment. I mentioned it because I recall a homework assignment that had us do the machine code for an 8088 chipset that would assign two variables, add them together, and output it to the screen. It was ridiculous the amount of work that went into that. I was just happy that we were able to write it in hex rather than binary.

As far as the actual programming language comment, that was written hastely and was inaccurate. I suppose the more correct term would be to say a programming language designed to output .exe files. Powershell is not one of them, I know.

For Powershell, I haven't actually dabbled too much into it, and yes the stuff I did dabble in was a pretty trivial batch file. Powershell documentation had either the implicit or explicit connotation that many batch commands worked just as well in Powershell, or perhaps that the batch functionality was still supported through Powershell. It's been awhile, so I'm not certain.

You have been very helpful in teaching me to stick with what I know and not to talk about the things I don't, as that's when the beatings start. You have effectively paddled me in front of the school assembly, so I will now lick my wounds and live to program another day. 

Yes I was being facetious with that last comment. I mentioned it because I recall a homework assignment that had us do the machine code for an 8088 chipset that would assign two variables, add them together, and output it to the screen. It was ridiculous the amount of work that went into that. I was just happy that we were able to write it in hex rather than binary.

My main point was that the people writing compilers are better than the vast majority of programmers at assembly... they know all sorts of tricks and implement them into the compiler.

I suppose the more correct term would be to say a programming language designed to output .exe files.

Not really. There is no reason so far that they've given to use a language that makes executables. If their goal is "I just want executables" than, well, that's sort of a silly goal.

For Powershell, I haven't actually dabbled too much into it, and yes the stuff I did dabble in was a pretty trivial batch file. Powershell documentation had either the implicit or explicit connotation that many batch commands worked just as well in Powershell, or perhaps that the batch functionality was still supported through Powershell. It's been awhile, so I'm not certain.

Everything I wrote I verified. you can run batch scripts from powershell but then cmd.exe is what interprets them, not Powershell. This can be useful so that if something comprises of several batch files, rewriting them in powershell could be done top down, and the powershell can call batch files, until those batch files are rewritten in powershell.

You have been very helpful in teaching me to stick with what I know and not to talk about the things I don't, as that's when the beatings start. You have effectively paddled me in front of the school assembly, so I will now lick my wounds and live to program another day. 

Sorry that's what happens when I drink too much coffee. 

I guess in further analysis that I dont really need to compile them as they run perfect in their native batch format (.cmd)
The real need for comiling was for speed and not much else.
i guess that i just will pick the language that seems to meet the needs of the batch file (mainly set envir var's)
and no {shudder} to writing in machine language, lol
but will take a look at powershell too.
 
many thanks for all the comments, great to learn at U of CH 
 

OK, but why do you need to compile them?

skorpio07, we keep asking you:

Not entirely true. Powershell will still recognize most batch commands.
Or you could always reasearch and try writing your own program in machine language as well. Talk about efficiency.

This can be useful so that if something comprises of several batch files, rewriting them in powershell could be done top down, and the powershell can call batch files, until those batch files are rewritten in powershell.

The real need for comiling was for speed and not much else.

So you were looking to slow down your batch file! J/K. LOL!
I am sure you are aware now of why it wasn't speeding it up but actually slowing it down.

i never got to the point of being able to test the speed issue, as the compiled program wasn't working as expected. working on a freebasic version, hopefully things work out.
 

I am sure you are aware now of why it wasn't speeding it up but actually slowing it down.

so this is more or less solved...
 
im going to use freebasic unless there are limitations when doing the port from batch.
 
many thanks to all for your input and suggestions
 
thanks