"heap" directive should be followed by a 16-bit value defining maximum size of additional heap in paragraphs (this is heap in addition to stack and undefined data).

Use "heap 0" to always allocate only memory program really needs. Default size of heap is 65535.

"heap" directive should be followed by a 16-bit value defining maximum size of additional heap in paragraphs (this is memory allocated additionally to the program size and the stack space). Use "heap 0" to always allocate only memory program really needs. Default value here is 65535, the effect is completely filling the biggest free continuous memory block.

Among with flags also one of the special PE data identifiers can be specified to mark the whole section as a special data, possible identifiers are "export", "import", "resource" and "fixups". If the section is marked to
contain fixups, they are generated automatically and no more data needs to be defined in this section.

Also resource data can be generated automatically from the resource file, it can be achieved by writing the "from" operator and quoted file name after the "resource" identifier. Below are the examples of sections containing some special PE data:

section '.reloc' data discardable fixups

Quote:

"heap" directive should be followed by a 16-bit value defining maximum size of additional heap in paragraphs (this is heap in addition to stack and undefined data).

Strange ...

Quote:

Use "heap 0" to always allocate only memory program really needs. Default size of heap is 65535.

Not really.

Problem: When placing multiple aforementioned things into one section, FASM is happy and brews the PE, but it is garbage and doesn't run.

Quote:

Also resource data can be generated automatically from the resource file, it can be achieved by writing the "from" operator and quoted file name after the "resource" identifier. Below are the examples of sections containing some special PE data:

section '.reloc' data discardable fixups

Should be:

section '.reloc' data readable discardable fixups

Some Win32 examples are also affected by this bug.

The MZ executable can have larger size in memory than in file, if you put undefined data at the end of source, the header will tell DOS to allocate more memory than just what is needed to load the pages from file.

There is a lot of methods how to make executable that's will not work properly by abusing various settings. However you can still (if you're clever enough) utilize them in such a way, that even with combined (supposedly contradictory) settings you may get something correct. fasm should not limit your options unless it's something impossible to implement according to format limitations. But this is not the case.

This is questionable - the "readable" flag applies to the run-time settings of the section, that is it refers to the ability of your own code to read this section. However it should not affect the loader, which has to be able to read all the sections anyway. Personally, I think that combining "readable" with "discardable" is not a very useful combination, since the section that can be discarded is not safe for you to read anyway, so if you wanted to be able to read it from your code, you shouldn't put "discardable" there in the first place.