DOS ain't dead

FASM 1.67.34 now lacks unreal mode hack (Announce)

posted by Rugxulo , Usono, 24.02.2009, 07:36

> 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.

Complete thread:

• FASM version 1.67.28 available - rr, 08.11.2008, 23:53 (Announce)
  • FASM version 1.67.29 available - Rugxulo, 25.11.2008, 06:52
    • FASM version 1.67.30 is available - rCX, 09.02.2009, 03:47
      • FASM version 1.67.32 is available - Rugxulo, 13.02.2009, 23:02
        • FASM version 1.67.32 is available - Rugxulo, 18.02.2009, 00:53
          • FASM version 1.67.34 is available - DOS386, 24.02.2009, 05:22
            • FASM 1.67.34 now lacks unreal mode hack - Rugxulo, 24.02.2009, 07:36
            • FASM version 1.67.34 is available - Rugxulo, 04.03.2009, 03:05
              • FASM version 1.67.35 is available - Rugxulo, 10.03.2009, 23:23
  • FASM version 1.67.35.01 available - DOS386, 15.03.2009, 02:12
    • FASM version 1.67.35.01 available - Rugxulo, 15.03.2009, 16:04
      • FASM version 1.67.35.01 available - Japheth, 15.03.2009, 16:40
        • FASM version 1.67.35.01 available - Rugxulo, 17.03.2009, 00:21
        • FASM version 1.67.35.02 available | -D hack for Japheth - DOS386, 22.03.2009, 05:27
          • ... Die stets das Böse will und stets das Gute schafft. - Japheth, 22.03.2009, 07:20
          • FASM for Japheth - ecm, 22.03.2009, 11:40
            • FASM 1.67.37 - Rugxulo, 27.03.2009, 16:57
              • FASM 1.67.38 - DOS386, 05.04.2009, 04:35