I have updated the guide to cover the interface changes made in the latest releases, so it may be useful info for people wanting to port fasm to some new OS. Other chapters still have not been written yet.

Thank you Tomasz.
Too pity, it's not finished. But we can wait.

Regards

Thanx Privalov!

This document seems to be clearly written. I hope you'll get it finished someday

regards
Mac2004

Small update today, more should come soon.

Another update, I'm slowly starting to reveal all the "secrets" of preprocessor, I hope my writing is clear enough...

In my opinion, this is a terrific overview to FASM. I have only one modest suggestion. It may be useful to a few of us, if those features of FASM unique to a particular operating system, i.e. required by Windows, or required by Linux, or required by DOS, (or eventually, perhaps, required by Menuet) were identified as such, so that someone seeking to modify FASM, could more readily accomplish that task, by recognizing at once, which modules could be deleted. Suppose one ONLY worked with Linux, for example. In that setting, the code specific for windows and dos, could be trimmed from FASM, without degradation of performance, and to accomplish that task, it would be helpful to know which components existed SOLELY to ensure compliance with a particular operating system environment.
By way of example: in section 2.2 you wrote:
"If program needs to free the allocated memory before exiting, it should do it in the "exit_program" routine which is called by interface after displaying the final messages. This routine restores all the system resources that need to be restored and exits the program. It has one argument, provided in AL register, which is the exit code that should be passed to OS. If OS accepts exit code larger than the byte, the value of AL should be zero-extended to fit the needed size. When this routine is called after the successful assembly, the exit code is set to 0."
The reader of this text assumes that at least some operating system does require a value greater in size than one byte, and so, it would be instructive to either indicate which OS needs a full 16 bit message, else to modify FASM to generate only 16 bit (AX) or 32 bit values (EAX), so that it becomes irrelevant which operating system is receiving the restored resources. Again, terrific job Privalov, thanks for the excellent accomplishment. tom

Another small update, meaning I'm back to work. I had a break because of some small disorganization in my life.

cool.

This is exactly why I'm reading this. I have to say, I've used fasm through the years on and off maybe a decade. The reasons I keep coming back to it are *not* because I prefer to do everything in little pieces of assembly.

1) Fasm is the easiest language I've ever used when exact behavior is desired. The capabilities of the macroassembler and constant expressions will never be exhausted.
2) switching between linux and windows couldn't be simpler. I suffer all sorts of problems when using mingw, and now mingw64 is even more complex. fasm doesn't seem to have as steep of a learning curve for tweaks and hacks because the author created a beautiful macro system *that is part of the language* to handle this.
3) the fasm community is full of knowledgeable and helpful people, and usually they get right to the point

I just want to hand it to the author, after about a decade of following fasm, how wonderful it has been for me. I would say it's the only product that has worked 'dependably' for me. I know most of this is due to the fact that I think about code at a low level, but I've seen nothing quirky in my experience. And through the years I've looked at the fasm source, and I've learned from it. It's clearly written. It's extremely efficient. Mostly, it doesn't borrow or depend on anyone or anything else, like other libraries, compilers, and languages I've studied.

Now, I'm not touting for no reason. Between the clearly and simply written source that is provided, and *this guide*, a person like myself can understand exactly why things are happening in the program, realize the design aspects that went into it, and use it as an example to make better code (or possibly even better compilers). Fasm is truly a work of art. Though there are aspects of the 'multi-layered macro system' that I *wish* worked differently, using it is a revelation as to what other higher level compilers *should* be able to do.

My point is simple. You've created a language that goes almost as low as a programming language can, short of rewriting a processor's internal codes. But it is also a higher than normal language, allowing compile time decisions and processing like lisp or forth would allow. To top it all off, it's lean and mean! The more work that you put into this guide, the more that people like myself looking to learn from your example can understand and improve their own code. As you've slowly added to it through the years, I've also been returning to it. It has been one of the major contributors to my understanding of programming.

I've touted enough, but I hope you see my point. Future generations will put down their .Net homework at night and find this guide on Wiki somewhere, and they will study it in the long hours. Older fellows like myself will return to it, like an old novel series. Some chosen one will create 'the new best thing' based on your accomplishments. Fasm contains the tools, but this guide imparts the wisdom. Please continue developing it.