It would be nice if the "format binary" could be followed by the file
extension that would override the default ".BIN", like



So one could create SYS, EXE, COM, DEX, DLL or whatever without always
renaming the ".BIN" .

EDIT: Done in 1.67.22

COOL. Was discussed 2+1/2 years ago ... don't know how FASM worked
that time

But my new suggestion does NOT break anything, is very easy to implement,
and allows me to get rid of the "BIN" ...

It's not a technical problem, it's design question whether to implement it. And the arguments against remained.

The old thread seems highly outdated (FASM did NOT add ANY extension
at that time ???).

Possibly you should point me to the arguments you exactly mean ...

The "format" and extension handling is already done quite well in FASM,
what's missing is to assign the correct extension to "format binary".



FASM already accepts additional stuff ^^^ after main format type

My suggestion is NOT to do some sophisticated "guesses" or what,
simply to override the default ".BIN" by another extension, anything that
begins with a point and has 3 characters becomes the new extension.





and "output" if given would of course still override the extension
given in "format binary" (this "argument" ?)

maybe you should READ that topic. entire second page explains confusion your idea would cause.

sorry, missed this. yes, this is the problem. it is uglying of the syntax, if "something is taken into account only if something else somewhere is not defined". i dislike such "solutions", and tomasz seems to dislike them too.

This is NOT my idea.



It would be "interesting" ..... maybe even silly



It's by far NOT that horrible as you present it

"format binary" defaults to ".BIN"

This default can be overriden by "format binary .BUG"

And finally commandline can override this



Also, my idea is limited to "format binary" only

reaction in my previous post. and it *is* same thing as the one discussed in that topic.

Is this why

format binary
org 100h

still produces a *.com file using the IDE 1.67 instead of a *.bin ?

i bet

from Design Principles:



and a little forward:



so... should we consider the file extension part of the output?
if the answer is yes then a new feature is needed to allow specify the extension
of the output file
and to avoid ambiguitys i suggest that the [output] option be remove from
command line and i even dare to suggest that the options -p and -m be removed to.
after all a programmer should know how much memory and how many passes
his source takes to compile. don't you think?

what this [output] option is useful anyway? fasm don't perform batch procesing.
the only moment that i can think off is when someone want's to compile the
same source but given a diferent name to not overwrite the first compiled
file.



leaving all the options to the source file is more consistent with the SSSO
principle I think.

so if this new feature is added it would be like:

if the feature is used this will override any extension "guessed" from the format directive
if the feature is not used the extension will be "guessed" from the format directive (as it is now)
and if the feature is not used and no format is specifyed then no extension should be added at all.

well is my opinion only.

well, it's meant "same contents of source, same contents of dest file".

Well, the people who write .EXEs manually do indeed use the [output] feature (which is easier than having to rename the file afterwards).

As far as -m and -p are concerned, I can only guess that some projects take more time to assemble if you let it fully optimize all the displacements and stuff. Some people maybe prefer to save some development time by reducing passes, etc.

rugxulo, I think they are forced to use the [output] option because they can't
specify the extension of the output file anywhere else.
if this would be possible they could specify such extension only once inside the
manually-builded exe and not everytime that the file is assembled.
plus: if the file gets distributed they would need to add some information like:

;to compile : fasm manual.asm manual.exe

and if somebody miss this the result would be an exe file with bin extension.

Iguess is really trivial we can rename with a simple batch file.

on the other hand ... fasmw don't have any way to specify the extension
no even an [output] option.

Any progress in this thing ?

vid (not Tomasz) wrote:







Neither FASMW nor FASMD have an output option. Allowing



is by far the simplest solution to this issue, and most compliant with SSSO
and CSWSF ("Complex Solutions With Simple Features") design ...

Just a note about SSSO, because I see it is slightly misunderstood: it applies only to the contents of output in relations to sontents of source. How the source and output are handled - as files or streams or memory objects, depends only on interface, not core - see the fasm DLL for example. In this context the INCLUDE directive is the one slightly breaking SSSO rule, as it passes its parameter to the interface in order to receive another object, and again, how that parameter (path) is interpreted is up to interface (and indirectly the OS which lies behind it). By standard all the interfaces implement accessing the environment variables in the same way (though this is for standarization only, just like all the command line interfaces accept the same command line parameters right now) and do conversions between slashes and backslashes when needed - still the structure of the paths may be very OS-specific.

Thus the SSSO principle was intended to ensure just that the interface cannot affect what output the core generates from the given source. The INCLUDE seems to break this rule, however it may be defended by stating, that INCLUDE only affects WHICH source is processed by the core, not HOW this source is processed into output.

Thus the whole extension adding thing isn't really related to SSSO. It is not contrary to it, but using SSSO to vindicate it isn't really a good point.

As for the feature itself: the core already contains a routine that generates an extension for output in case when interface doesn't already have the output file name specified. Thus adding a setting that would allow altering this behavior to get a different extension than default woulnd't be any problem with current design. Just remember that it's up to OS-specific interface to decide where to put the output data that it receives from core, and for example when the console interface got output path specified from command line, any suggestions from the core are ignored. So this setting would be just a "hint" for core what extension should file have in case when user doesn't state otherwise.

PS. Sorry for coming so late to this thread, recently I had a little less free time than usual.

..

If you did not get such impression from my previous post: you no longer need to convince me, I already considered all the reasons and the rest (implementation) is left for me.

It's implemented in fasm 1.67.22 (I'm going to release it today), you simply write:

to get the desired result.