Privalov,
This is a long desired option, that maybe you will find useful, Fasm could guess the output filename from the format directive, so it could be an optional command line parameter. Like in fasmw with dlls and exes.

I need mainly when coding on linux.

What do you think

I agree... That would be a nice feature.

I'd say that if no output is specified then output = input - extension (thus all text before but not includng the last dot )

eg.
fasm input.asm => "intput"
fasm input.something.foo.txt.asm => "input.something.foo.txt"

Guessing output names beyond this could be hazardous...

(/me still dreams of fasm output to stdout (of the compiled data only, no "extra" output))

Actually I am doing that way, stripping the ".asm" when launched by file association.

Fasmw guesses the extension from format directive and I see no hazard on it. There are no ambiguities. Am I missing something?

Imagine if you "dblclick" an asm file in any filemanager and Fasm produces exactly the file you intended.

how does it know if I want no extension, .bin, .foo, .bar, or .whatnot? You see that kind of "hazard"

then you could use "fasm source output" form. The whole simplification wouldn't have any sense if I had to modify filename by myself.

Look that it is optional, it guesses only if you don't specify output.

What about this:

BTW, why ordinary COFF files have default .obj extension? GCC produces *.o

my suggestion:

Perfect !
Now left only the boss' opinion

maybe .com extension when selecting "format binary", which is the default option, but specifing it is still valid?

In fact I don't recall any serious requests for this feature - though it's quite easy to add.

As for the "extensioning" strategy - isn't the one used by fasmw enough? I'd copy it when implementing into console versions.

IMO binary means (flat) binary, not .com (which iirc, actaully has an orgian at 100h, not 0h (as "pure flat binaries")). better go with some "format com" instead.

isn't it possible to get "origin" of first data in file when quesing extansion? If yes, then COM file will be generated only if first data of flat binary is at origin 100. I think such quessing would be okay and backward compatible too.

It's a good idea, though it cannot be done this way. But it might be possible to catch the values given to "org" directive and store the first one (or the last one used at the point, where not yet any data has been generated) for later extension guessing.

i think it should catch argument of first "org" not preceded by data and followed by data immediately (eg. no other "org" between them).

I second scientica on "format com".
Reasons:
1. Conceptually, com is a format (one that is not different to plain binary, but a format anyway)
2. Extension guessing depending on directives other than format could become very complicated or ambiguous.

format com is a nice idea, but would be unusual

My suggestion is to add another one directive to header
Let it look like this one (for Windows):



Of course it would be an optional parameter

i agree more with mike than with others, but remember we are talking about *QUESSING* filename extension, so it can be (or should) be heuristical. Don't you think it will be confusing to see some .COM files with "format COM" and some without? Also, would you like to add another format for every case when someone might want another extension, like "MZSYS" or "PECPL"? Also it won't be precise - that wouldn't be another formats, format will be still binary regrdless if it's data file or .COM file, that would be hint to quess desired extension, and so it would be confusing what "format" is what real format etc.

Mike's idea is better, but i think having another keyword to QUESS filename extension (which should be extreme case, when you CAN'T specify it in command line) doesn't look so good to me.

If some heuristic scanning of source code will be possible, then i think it will be best solution.