In the string table of a elf file generated with Fasm 1.64 it appears:
' .rel.text ' ,i think it should be a zero after '.rel'

For each section like .text or .data the section containing relocations for it is named .rel.text or .rel.data (see ELF specs). By pointing into right offsets into string table the .rel.text and .text section names are obtained from the same data - this is a nice space saving.

Ok, i didn´t read enought.

there is another strange thing on the elf file, in the symbol table,the symbol 'main' has 'stt_notype=0' that means undefined or constant value
but since the value of 'main' is related to where the code section is loaded
i think it should be 'stt_section=3' type.

and another question, why the clib version of fasm uses functions like:
putchar,fread,lseek+ftell
instead of the more simple and efficient:
printf,read,filesize.

Type STT_SECTION means the symbol representing whole section object, not the label inside the section. Anyway latest fasm versions changed to put STT_FUNC type for the simple labels.
See the guide about porting fasm for explanation why "lseek", "ftell", etc. are needed.

Finally i get out that constant symbols use a especial section index
so in general the symbol type can be ignored.
I don´t found the explanation in fasm internals about the use of
'fwrite' instead of 'write' or 'putchar' instead of 'printf',thats not a problem at all and i know that i can change the sources myself, but first i want to try a generic solution that could be used also for porting other software.
And finally, how the assembly to ram project is going?

Why write would be better than fwrite? putchar is used to implement all the functions from the display_* family - why import more functions when one is enough? And printf wouldn't work for display_block implementation, as the string is not zero-ended in that case.

is that the code generation library project or some project i havent heard about?

i'm not sure if this is the same, what i want to do is to load directly the source code ,without using executables, i already do this with my assembler and it shoudn´t be much complicated to do the same with fasm.

Why would you like to do that?

If the source is also the executable:
1: less files and disk space is needed
2: less programing tools are needed, no linker, no exe loader etc...
3: source is more portable than executables.
4: you can always take a look at the program with a txt editor to see
if it includes something like 'include virus.asm '
5: it was easy to do the same with Fasm.
6: Why would you like to use exe files?

1: less files and disk space is needed
2: less tools are needed, no linker, no compiler/interpereter etc...
3: source is less portable than executables and thus more efficient for one particular implementation.
4: you cannot take a look at the program with a txt editor to see
if it includes something like 'include virus.asm '
5: it is easy to do the same with Fasm.

:DDD

don't take me too serious, i like the idea

Not necessary. You can have source in a .7zip, or don't have it at all, if you're not interested in it.
Yes, though you don't necessarily need a linker.. but you need Fasm in this case (some guys probably only want the .exe and not the source)[/quote]
What do you mean? Maybe there are tools that convert exe to another. and besides, is it THAT hard to recompile your program once again for a new version, whatever?[/quote]

Perhaps
.exe files are much faster, they do not need assembling. They are smaller, etc. They are the native language of the processor. Just imagine yourself trying to speak a language you find hard to understand -- of course it will SLOW you down to understand someone in that language. Same with processor.

Personally, I hate text files that get executed at run-time, or something like that. For example, some years ago, when I didn't know asm at all, I compiled some scripts for Starcraft. Then, a friend asked me if I could write some AI for Warcraft III for him to play with (since he wasn't good at it). And I tried to help him with it, but I realized Warcraft 3 uses 'text' scripts (not compiled) and I hate them. It wasn't that I couldn't learn them -- in fact, I finally managed to get the AI to my friend and he was pleased, but I felt strange to know that these 'scripts' get inside the game archive and whatever, and are compiled at run-time. I just don't like it. Don't get me wrong

Most people find "xml" or other text formats magical.. I simply do not understand why? On the contrary, they are even less magical. I especially hate them when they affect the run-time of a program or whatever (except customization things like .ini, of course )