Yeah, that's what I was trying to say above:

and of course, that also applies to linking just a single object file

Sorry

Hey no problem

BTW, .fas format contains one mistake, which perhaps it's too late to correct. The signature was intended to have value 1A736166h, but because of my mistake it has the value 1B736166h.

Well, I personally wouldn't mind if you changed it. And I don't think the average user would even notice. Maybe only programs that check this signature for some reason would need to be very slightly modified (1 byte ) and recompiled.

Another way could be, if you have other ideas to change or add to the fas format, is to just (at some time) introduce version 2 of the fas format. File formats change and are updated, that's not unusual.

BTW, was it just a typo that caused your intended 1A to become 1B, or do these bytes have some special meaning?

Tomasz, this is probably a silly question, but does the assembly dump part of a fas file have any value on its own?
I mean, it links src lines from the preprocessed src to offsets in the output file, so you need the output file to be able to see what is actually at those offsets (fasm's own listing tool also needs to open the output file). But I usually assemble to object files, which I later link, so the offsets in the object file are not the same as the offsets in my final binary. Also, with elf binaries, most things are relocatable, so you're not even sure that offsets in the object file are final. Eg, if you disassemble (the .text section of) an object file with objdump, it just shows offsets from 0.
The point is I've written a program (in C ) that displays the contents of a fas file in human-readable form, and I have all of the different parts of the format done except for the assembly dump. Since I would like my program to not be dependent on an external object/binary file, and since even such a file might not provide the correct information, I wonder if the assembly dump is very useful for displaying as-is.
Am I correct in thinking this, or am I missing something?

Assembly dump is generally crucial for both the listing production, and for the source-level debugging. Of course it's not so useful with object files, because you don't debug object file, nor really need the listing of it - however, if you wanted linker to produce information required for source-level debugging, the linker would still have to get the line offsets from somewhere (and that's what the pecvt tool provides for the COFF objects).

Yes that's what I thought: it's primarily there for debug info. I don't think my program needs to generate a listing, so I guess I won't include the assembly dump then.

Since this was never answered, I'll take a guess:

736166h = "saf" ("fas" in reverse). I assume the 1Ah was meant as EOF as some other file formats (ARC? ZOO?) had similar so that you could "type myfile.zoo" and still know what it was without hearing lots of annoying console beeps because it would ignore everything after that EOF byte.

That sounds plausible, so that's probably it then

The 1.68 is going to use 1Ah value there. Please be ready to do that 1-byte modification and recompiling.