..

[content deleted]

i always though it to be the same as .data but none of your data actually get stored it gets reserved instead. I always used it to declare variables which i would then give a value later.

It can reduce your application size by a small amount. i imagine that all the bytes that you declared get counted into one number and the exe loader simply allocates that much memory at loadtime and doesnt actually load the values you'd specified. since only the size of the of the section is needed to build the section then it saves space.

I don't really know what im talking about tbh, but the way i see it seems to work.

pool,

Section names are irrelevant in executable, they're used by linker to combine sections with the same [base] name from different object files (in COFF e.g.)

Usually ".bss" section contains only uninitialized data (as in EXAMPLES\DDRAW.ASM you'd mentioned). fasm or linker omits uninitialized trailing bytes from raw section data in resulting executable, thus making it smaller on disk. What did you meant, wrong implementation?

[content deleted]

asmcoder,

Code section can be E-only (at least when you don't need to read from/write to it).

Merging sections is not an easy effort regarding [un]initialized data. Though they can reside in a single section (I forgot to mention: in Windows, section name does matter, see UPX sources or OLEAUT32.DLL code).

And last, but not least: sections in PE executable are made of sections in COFF object files with linker involved.

.text: IMAGE_SCN_CNT_CODE | IMAGE_SCN_MEM_EXECUTE | IMAGE_SCN_MEM_READ
Page protection for execution implies read attribute althou read section attr is not necessary for smart (i believe) MS loader.