DOS ain't dead

> I don't know the details, just know that the very few who needed such
> things often seemed happy to use "strict".

I definitely belong to that group. Very good thing to have.

> Not as painful as it sounds (though it is a change from years past), esp.
> if you use Makefiles or set the NASMENV (or whatever) environment
> variable.

Command line options eventually become necessary, even without full-blown makefile-ish build environment. I found that ultimately, they recently again became (even more?) necessary to me because I collected several versions of a common macro file, committed all of them into their own repo in order, and then looked into how to replace the actual usages in the repos I gathered the files from. Ultimately, I went with a model where the macro file's repo (usually shared by multiple other repos) lives at the same directory level as the repos, with the NASM command line hence specifying an include path using the dotdot ".." specifier, ie to back up a directory level, to get into the sister directory where the macro file is located. This is necessary to conveniently allow rebuilding with the macro file elsewhere (just needs an additional include path on the NASM command line, no changes to source files) and so that the source files and the macro files referring to each other do not have to specify any pathes. That is, any given source or macro file will only use lines like:

        %include "xxxxxx.mac"

This does not include any path modifiers in the specified name. Finding the directories is managed entirely by the specified include pathes.

> Any kind of assembly code depending on specific opcodes or sizes is likely
> to bite you later and should (probably?) be avoided (or else hardcoded in
> "db 0x9, 0x10" directly). IMHO, YMMV.

Well, byte-comparison of output is a very specific one, but if you're referring to my example on patchable code nahhhhh my code is full of that =P

What I find especially important here is that the language itself, apart from (sometimes) possible optimisations which the assembler did not previously use, doesn't actually change any longer. I'm targeting 8086-, 186-, or 386-compatible Real 86 Mode. These instruction sets are fixed.

For regular usage in code, instruction encoding using DB gets impractical for anything longer than a single byte, which is why my code seldom if at all uses it, and even single-byte instruction encoding usually not with the raw number but via a macro named in an obvious way to simplify reading and writing the code.

> I'm fairly certain you can override sizes in the source, yes, but no, I
> don't think you can disable size optimizations at runtime at all (though
> perhaps limiting FASM passes would somewhat work). No reason to do so,
> honestly, though I may be short-sighted in believing that.

Easier to create (nearly) byte-compatible output for comparison with another (less/unoptimising) assembler's output, sometimes a viable tool to check that porting succeeded.

> (I hate such generalizations when people say, "Nobody needs xyz.")

Hmm, the point I see here is that the only resources it takes to add that feature is a few allowances in the design, as well as slightly larger on-disk executable size (of the assembler itself). Seeing as the latter is largely meaningless now (can't even fill 40 GiB with just the programming things that I work with/on myself, let alone 400 GiB!), it's essentially just the design trade-off to allow the other mode - which other than that will not hurt users that do not require it.

Sooooo~ basically, "Nobody needs xyz." can be more or less agreeable. It depends on the context a lot!

---
l