PDA

View Full Version : Structure of .exes



Al6200
March 24th, 2007, 07:08 PM
A few days ago I decided to embark upon an ambitious project, one that I had strong doubts I could ever make work: my own programming language.

I've made strong progress on lexical analysis, and division of the code into usable chunks.

Even if I get the lexical analysis to work perfectly, I doubt I'll know enough assembly to allow my programming language to translate into machine code.

So here is my question: how are .exes structured? Any articles or documentation?

Also, I've just started on the function parsing, and I'm thinking I want to treat functions as a sort of a preprocessor directive. In C/C++, are functions a language construct?

MTsoul
March 24th, 2007, 07:23 PM
Do you mean how a compiler works?

If you can write a C++ compiler for x86 Windows, you can practically get a job as a programmer anywhere in the world.

Try looking up information/documentation on the available compilers. MinGW is an open source one.

λ
March 24th, 2007, 08:11 PM
writing a C++ parser is indeed a very difficult task, stick with C unless you are very talented indeed.

This should give you a hand: http://win32assembly.online.fr/pe-tut1.html

Al6200
March 24th, 2007, 08:16 PM
I don't think I'll actually get done. Come to think of it, making it object-oriented would be a big, big challenge. I don't plan for it to include things like objects, pointers, and structs. That's way above my head. Even real functions are above my head, my functions would simply be a pre-processor directive that inserts in the function definition and replaces parameters. Thanks for the links.

Templarian
March 24th, 2007, 11:24 PM
^Pointers are way above your head... then you really should learn some more first.

I just told my brother this (hes a very skilled programmer in C++), hes like he would have to have a lot of time and know everything about the language.

hybrid101
March 25th, 2007, 02:17 AM
if you can understnad brain****, i bet you'll find this quite easy:P
but seriously mate, that would be indeed very difficult. not only do you have to get a full grasp of assembly, you also have to learn and make the right commands for your language;)

Al6200
March 25th, 2007, 12:15 PM
When I said I didn't grasp pointers, I meant that I couldn't imagine how to code a pointer system in assembly.

Yah, I'm pretty sure I'll fail. But even if I never make the language a reality, I'll still learn a lot about assembly and lexical analysis.

Even if I do succeed, this language is nowhere near as complex as C/C++. I want to code in loops and conditionals, but I'm not sure quite how I'd do this. (Another thing to work on).

Here's the syntax so far:

### Set1:
setMemory[int, 2]
setMemory[String, 1];
###/

### Set2:
int a = 2;
int b = 3;
"ab" -> myStr;

### Set3:
#preprocessor::include[myFunc];
Set[1 -> a, 2 -> b];
#/

$function myFunc:
Params: a, b;
Method:
<<
myStr = a + b;
>>
$/

The syntax is full of symbols which give the code a cluttered look and aren't really neccessary, but I'm a beginner. I find it a little bit easier if I end each statement with a semi-colon, or use $ and $/ to mark preprocessor definitions and # to mark preprocessor calls.

In this, -> is set as preprocessor assignment, while = is runtime assignment. Basically my lexical analysis works by dividing the code into a series of objects called Sets. Each set has a property called identifier, and a property called statements, an array of strings with each statement. It also has an array of conditionals and loops, each of which has an array of statements.

This system has its problems, but its the best I've come up with thus far.

Templarian
March 25th, 2007, 02:36 PM
I've spent time writing my own languages* also, but maybe you would be better making it script based running through a shell.exe that way you can spend more time making the language contain everything before actually making a compiler.

*my construction set program that i spend to much time on uses a custom language that only has events and basic namespace structure.