DOS ain't dead

> version 1.67.3xx (2009 Feb)
>
> [-] deleted UNreal mode support in DOS commandline version

EDIT: Not trying to be off-topic, just thought this would explain the advantages and difficulties that Tomasz encountered developing FASM in this direction:

Just for the record, here's some historical tidbits for FASM:

> When processor is in real mode, fasm uses its unREAL engine to get
> into the fastest possible 32-bit environment. DPMI is used only when
> there's no way to use unREAL, that is when processor is in V86 mode
> (and under DPMI fasm is generally slower, though on modern computers
> it doesn't make any visible difference, but try it on some 386SX machine).

And this:

> I've got a bad news for the fasm's unREAL mode fans.
> As you may know, even though unREAL allows the 4 GB of data
> to be used in one segment, it still limits the code that can
> be run from one segment to 64 KB. And this is starting to
> become a problem, because fasm's code (with all the data
> - tables, etc. - already moved above) is almost 64 KB
> already, and is going to "break this barrier" soon.
> So I have two choices - either I will try to keep the unREAL
> version running somehow (it could be possible to move some
> parts of code to other segments, but still I would have to replace
> some parts of common core code particularly for this version - and
> I dislike it), or get rid of unREAL code and leave only the DPMI
> variant (this already happened with FASMD). What do you think?
>
> I'm OK with throwing away the unreal, but I won't provide DPMI
> host with fasm. I just feel it's not the way it should be.
> I would make it work just like FASMD does now.

And here:

> So it's the early Cyrix - I suspected so, since that explains
> the [32-bit real mode] incompatibility.

It also had compatibility issues with BOCHS and DOSBox due to this.

And (finally) here:

> The first approach I've used to achieve such mode was a bit
> different from current - it had universal interrupts handlers,
> that (thanks to some opcode-tricks) were able to detect whether
> they are executed as 16-bit or 32-bit code and jump to appropriate
> code. In current version I the IDTR is different for the 32-bit
> code, and so there is separate interrupt table for this mode.
> I've invented this solution after I realized that on all processors
> I could test the IDT base can be altered even for real mode, and
> it seems to be much more stable in my tests.

> version 1.67.34 (2009 Feb 22)
>
> [-] Fixed small bug with DT directive far pointer syntax

Refreshed again (March 2), and now FASMD support more .INI directives as well as File Browsing / Saving selector dialogs.

EDIT: Forgot to mention, the unreal FASM didn't seem barely much faster at all on my 486 Sx/25 than the DPMI version (only like two extra seconds less to assemble itself, 13 secs. vs. 15 w/ DPMI), so you'd really need a big project to notice a difference. And it's probably not worth the extra hassle to clean boot anyways. Still, a nifty hack for its time. And on my P166, slowest to fastest seemed to be: FASM + CWSDPMI, FASM + HDPMI32, FASM Win32 stubbed via WDOSX, FASM Win32 via HXRT. (Of course, the biggest speedup was running on a RAM disk instead of slow HD, e.g. 1 sec. vs. 3.5 or so.)

> > 2. Even worse, since you failed to start using FASM after -D got
> > added in 1.67.24 / 1.67.26 , you are now obviously unable to punish
> > Tomasz by stopping using it after -D got kicked
>
> Where did he say he would start using FASM if it had the -D option?

Obviously Japheth prefers MASM v6 / JWasm instead.

P.S. FASM is now at 1.67.37, soon coming 1.68 (since preliminary EFI support seems to work). He's fixed a tiny bug in SSE4 and IDE (plus sped up s/r). But, strangely, flat real is gone again. (I tested speed of it vs. HDPMI32, which showed like only 5% increase, so maybe he figured it wasn't worth it?? Can't say I honestly disagree....)