Hello! I'm working on an IDE in VB.NET that lets you make batch files and test them easily. But, I really want to include a function to compile them to EXEs or COM files.

I've seen many commercial programs that do this, and I want to make a free program that does it.

I was wondering if it was at all possisble to do this in assembly. I'd like to make it a seperate utlity that is called from within my IDE.

Is this possible, or am I better off leaving this feature out?

what do you exactly mean by converting bat to exe?

doing echo, rem, goto, execute label ?

in exe file?

well, some can do anything in asm.
and i m sure there is no better language than asm, you specify every instruction to the cpu, if it can be done, it can be done in asm.

Well... i don't exactly know how anyone would do it... I suppose you would have to define an assembly function for each batch file funtion... which in the long run would take an extremely large amount of time.

But yes, I meant just converting the funtions in a batch file (rem, echo, etc) into an exe file so no one can tamper with the batch code.

You can write program that will convert .BAT into .ASM and then assemble it with fasm.

Yes, but then I'd have to include the converter PLUS fasm. I'll prolly just leave the feature out. Sounds like too much work for me and I don't even know that much assembly.

Well, other than the few built-in functions, batch files mostly consist of calls to EXE programs. So you could probably even convert a batch file to QBASIC or something similar. Built-in commands would be converted to their equivalent QBASIC commands and everything else is executed with the "SHELL" function of QBASIC. You would end with a "SYSTEM" function, so at the end of the program QBASIC returns to DOS after interpreting the program.

Of course, then you would have to assume the user has QBASIC, write your own QBASIC interpreter, or include it with your program (which is probably illegal, though I doubt anyone at M$ would care..)

Or you can create a linked list or table of machine code instructions, one item per built-in command, plus an item for executing an external program. I would recommend using COM instead of EXE, at least at first, because COM is much more simple. The compiler would look up a built-in command in the linked list or table, send the machine code associated with it to the output COM file, and of course add the arguments. For example, if the batch file says

The template code for the ECHO command, stored in the table or linked list, would have to be modified per argument. You would probably store the data (such as the string "Hello, World!") at the end of the file (probably null-terminated, to save yourself the trouble of storing the length of the string in the data area as well). The location of the string in the data area would be passed to the ECHO function, or (if you simply insert it each time, like a macro in assembly) built into the code directly (you would insert the location into the "macro" when compiling).

Fairly simple either way, although I wouldn't want to do it in assembly (I'm not an assembly expert). You could do it in FreeBASIC or something like that, fairly easily. For projects that are fairly difficult in assembly, but trivial in another language, I would definitely recommend the other language, unless you need fast speed, small size, or both.

I could make a converter like that in FreeBASIC? I'll check it out

Yeah, I think so. Heck, if you want, you could probably do it in VB since you're using that to do the rest of the project.

Here's a simple interpreter that only understands one command: ECHO. Note that this is an interpreter (a very bad one at that), not a compiler (which is what you want. Completely untested, it should however compiler/run on FreeBASIC or Visual Basic.

It executes a batch file which it assumes has been opened as #1, for INPUT.

Note: This is TERRIBLE code, so don't use this code for anything useful. You might want to check out "Let's Build A Compiler!" by Jack Crenshaw; it's probably the best tutorial out there.

You will, of course, need to modify this to your own needs.

Writing a parser is fairly simple; you have to know what you're parsing, and how you're going to parse it. If it's simple, you can use terrible code like mine. Otherwise, use better code (read Jack Crenshaws tutorial to learn about that).

You might consider writing the compiler as a front-end for another language, such as FASM, as Privalov suggested - however, that would not be much easier than my idea, using table or linked-list conversion - the difference is, you store machine code in your table instead of assembly. Machine language would take up a lot less space, of course. If you have trouble figuring out what opcodes to put, use FASM and a hex editor, or a debugger (DEBUG.EXE would work, though if you're doing 32-bit code you'd probably want GRDB, the Get Real DeBugger). With FASM and a hex editor, you type the code in, use "format binary" and compile. You can pretty much copy directly from the hex editor into your code, preceding each byte (two hex digits) by "&h" (that is the BASIC term for "convert the following hex number to decimal and use the result in the output file, which will actually be stored in binary). With a debugger, use the assemble option ("a" in DEBUG.EXE or GRDB) to type in the assembly code. Note that there are no variables or anything, so don't put variables in front of your code or it won't work properly. Also, in DEBUG.EXE only, all numbers must be in hex. When you finish, press ENTER twice in DEBUG.EXE or GRDB. Then, use the disassemble function and look for the machine opcodes. For example:

Note that 1234 is hex. Also notice that the operands are reversed in the machiner code. Instead of B81234, as one might expect, the two bytes are reversed, as B83412. This is normal and the way numbers are stored on x86 machines - nothing to worry about So you've discovered that the machine code for MOV AX, 1234h (in FASM) is B83412.

I assume your converter will convert to DOS programs, as BAT files are part of DOS anyways, right?

Good luck, and if you get anything good, post the binary or source code if you wouldn't mind.

Wow... that was a VERY informative post. ANd thank you very much for the example. I'm not quite understanding the whole debugging and the hex part, but I'm assuming thatIf I use VB or FreeBASIC to make the compiler (or parser) then I won't really need to understand it.

Here's my problem now...

If it is infact possible to do this in VB (and I know this isn't a VB forum, I'd just rather not leave this topic hanging), then I still wouldn't be able to make it into an exe (or com) file unless I had a VB compiler to include with my program.

I'm still not sure what exactly I would use to make it into an exe... Sorry if I sound a bit newbish... this is my first time messing with making parsers and such.

EDIT: Also, I'm setting up a small website for BIDE so If anyone would be interested in helping with it (making the syntax highlighter better, etc), you can PM me and I'll send you the site address.

Well a compiler turns code (such as a BATch file) into machine language. You can definitely do it in VB. Just think of a table in which each entry contains some machine code. The machine code associated with a command (such as ECHO) is simply placed in the output file when it is encountered in the batch file. Of course, any arguments must also be stored (for example the string "Hello, World!" as an argument to ECHO would obviously need to be stored in the file in order for the code to work). How do you figure out what the machine code for the commands are? Use GRDB or DEBUG.EXE, or FASM and a hexeditor. Type in the assembly and then find the machine language for it. Note that any data must be stored at the end of the code, as it will otherwise be interpreted as machine code by the CPU (which doesn't differentiate between the two).

Basically, you must:
-Generate a table with machine code or template machine code for each command. For example, the code for ECHO would be different for each string, but the underlying code will be basically the same. You would only have to modify a pointer used by the code, which points at the string argument. Note: since this is very high level, you could optimize for speed by checking if two arguments are the same (for example if two ECHO commands both take the argument "Hello, World!") and if so, only store the string once in the output file. Both ECHOes would then use a pointer to the same location.

-Parse the batch file. You check for recognized commands. Of course you may have to deal with multi-line commands and etc. but for now pretend all commands are on one line. Anything following a command is an argument to that command. For any recognized command, use the template machine code from the table, modifying the machine code per command when arguments are present. Put the machine code in the output file which MUST BE OPENED IN BINARY MODE (except in Unix systems on which binary and text modes are no different).

-Put any data constants at the end of the file. For example, if a "ECHO Hello, World!" occurs in the program, the machine code for "ECHO" is placed in the program, but at the very end of the file the string "Hello, World!" is stored.

Of course, you will need a user interface, but since this is unimportant in the beginning you could use a text interface (in FreeBASIC) or a very simple MessageBox and InputBox interface (in VB).

Getting the machine code requires:
-Knowledge of assembly language and the DOS API (I assume you're using DOS, since you mentioned COM and EXE files)
-GRDB, DEBUG.EXE, or FASM and a hex editor.

Good luck!

Well... um... yeah...

Thanks for the information, but I'm 14 and the most I know is what "mov" and "jmp" does... so I doubt I would be able to do any of that.

Maybe I'll just wait on this feature.

I'm 14 too!

Keep learning

But that's quiet good, if you are 14. Really. Shit, never thought the flat assembler board would become a kindergarten

Yeap, good to see there are still kids learning assembly. When I was 14, the 386 was top of the line... I was 16 the first time I saw x86 code (a mov ax, something instruction, still remember it!), but I knew Z80 assembly (oh, my old ZX spectrum, rest in peace ).

Well I also started very young (10 years) and through all this time I've learned a lot from the others, so keep learning that's the right way

I still use "noob" languages like QBASIC when I have a fast project that doesn't need 32 bits and I'm not planning to give it out to everyone (just a quick utility for my personal use), but I use FASM (and I'm learning to use DJGPP, as I already know ANSI C but not DJGPP-specific stuff) as my main language.

I also know HTML, perl, pascal, and some others. Although with an old computer like mine (it's a 486!!!) most of these do me no good, until I get a computer worth talking about.

I started programming when I was 12. Learned asm (thanks to FASM ), C, pascal, delphi, quickbasic, vb, html, vbscript, etc...
I'm now 18 and I'm at computer science and I'm very happy that I learned programming before, so I can be good at this without touch a single book.


Now, my opinion is:
Do this with FASM macros and these macros can be translated into asm code and assembled with fasm.

So this is "prog.bat":
@echo off
echo Hi!

and this is your asm translated code:
mov ah,09h
mov dx,msg
int 21h
mov ax,4c00h
int 21h
msg db 'Hi!',13,10,'$'

simple!

Don't get me wrong, I know lots of languages (QBASIC, C, C++, HTML, PHP, Python, ect), but FASM was just never really my thing.

The language is good and all, but the whole idea of using "interupts" and things kinda scared me away from fully learning the language.

Anyway, thanks for all of the help. I've kinda put the project on hold anyway becuase I'm setting up my linux server (for irc and things) so that's taking up most of my time.

From http://www.wieringsoftware.nl/utils/:

http://www.wieringsoftware.nl/utils/batchcom.zip - Compiles .BAT files into .COM programs, supports many additional commands for program flow, variables, etc.

/ Christoffer

Wow. I have a game called Charlie The Duck made by them, for my little sister, but didn't know they made anything that useful Thanks!

@DataHunter2009: If you use this, you may wish to convert the output COM files to EXE. This is fairly simple, and there are plenty of examples on how to do this on the internet.