HydrogenAudio

Lossless Audio Compression => FLAC => Topic started by: ktf on 2022-11-24 13:11:42

Title: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: ktf on 2022-11-24 13:11:42
Don't hold your breath for the build of FLAC nobody has been waiting for: FLAC for MS-DOS! Instead of fixing actual problems, I thought this would be fun to build. As the regular Windows build supports Windows versions from Windows XP and up, this build will be most useful for MS-DOS, Windows 95, 98 and ME, probably. Maybe Windows 2000 too. You can now decode 24-bit and 32-bit FLAC on systems featuring a 16-bit kernel! Hooray!

Below you'll find some answers to anticipated questions.

With whatever ancient software has this been build?
GCC 12.2.0 as modified by DJ Delorie, a.k.a. djgpp

Why? Seriously, why?
Just for fun. And for bragging rights. I saw there is a compile of FLAC 1.1.2 for MS-DOS here (https://sites.google.com/site/blairdude/flac) which is obviously very outdated (it cannot decode most 24-bit FLACs) and I saw an outdated mention of DOS support here (https://tweakers.net/pricewatch/161537/flac/specificaties/) so I felt like making a new build. Also, it is a showcase for the portability of the FLAC source code, because there were no changes to the source code necessary for this build. Same goes for Ogg, no changes were necessary there either.

Does it support UTF-8 filenames?
No, MS-DOS doesn't work with those. In other words, this build does not bring UTF-8 support to Windows 98 or similar. I'm not sure the latter is even possible, and if it is, it is probably a lot of work to get it right.

Can I get a DLL?
No, because MS-DOS doesn't have any form of dynamic linking as far as I'm aware.
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: Replica9000 on 2022-11-24 13:56:50
When I get time, I'll fire up my copy of MS DOS 6.22 to try it out. (I still have the floppies).  What does Flac output for the file extension?  .fla?  I don't remember if you could have file extensions with more than 3 characters back then.
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: Porcus on 2022-11-24 16:11:38
The HA mob demands performance tests!  :))
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: MrRom92 on 2022-11-24 16:13:09
Wild. Now someone just needs to backport EAC 😂
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: Replica9000 on 2022-11-24 16:36:43
The HA mob demands performance tests!  :))

I still have a working AMD K6-III+ if we need period-accurate results!  I think it still has Win98 SE on it.
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: ktf on 2022-11-24 19:12:15
I did functional testing in a Windows 98 VM, but that isn't a representative environment to do performance testing in, obviously.

DOSBox is a MS-DOS emulator specifically made for gaming. Those old games apparently heavily depended on the speed of the CPU to be constant as a 'timing source'. So, a faster CPU would mean a faster game. As the emulator has been crafted specifically to emulate old CPUs, not just in functionality but also for speed, I think timings here are valid. As I threw away all my hardware that old years ago, I don't have anything else to go on anyway.

DOSBox was set to normal emulation, running at 7800 cycles. According to this source (https://www.dosbox.com/wiki/Performance), that should be close to a i386.

Anyway, I took a FLAC file from my collection: Nine Inch Nails - HYPERPOWER! from the album Year Zero. The track has a playback length of 102 seconds and is CDDA (stereo, 44.1kHz, 16-bit PCM).

Results
Decoding of file compressed with preset 0: 144s (0.71x realtime)
Decoding of file compressed with preset 8: 181s (0.56x realtime)
Re-encoding file with preset 0: 310s (0.33x realtime)
Re-encoding file with preset 8: 2515s (0.04x realtime)

As can be seen, a i386 is too slow to decode FLAC in realtime. A i486 or newer is probably fine though.
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: cid42 on 2022-11-24 21:01:45
Time to define a subsubset that decodes CDDA in realtime on i386 :P Verbatim+constant only, maybe a fast fixed predictor?

Why do I feel this should be whispered in hush tones:
Spoiler (click to show/hide)
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: Porcus on 2022-11-24 21:07:41
Part of me is asking how fast FLAC (decoding) is compared to compress(1) or to its predecessor pack(1). pack is still supported by way of gzip (although support was broken for a few years without anyone noticing: https://www.vidarholen.net/contents/blog/?p=691 )

Part of me is asking me to stop asking such questions ...
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: rutra80 on 2022-11-25 07:32:47
Time to define a subsubset that decodes CDDA in realtime on i386 :P Verbatim+constant only, maybe a fast fixed predictor?

Why do I feel this should be whispered in hush tones:
Spoiler (click to show/hide)
AMIGAAAH!  :D
I was able to decode mp3 on 40MHz 68040 and have spare CPU time to do other things. Is FLAC decoding slower than mp3?
Most common 14MHz 68020 or 7MHz 68000 might surely be not enough...

MPEG decoding used tricks like frame skipping to make video playback possible at all, wouldn't it be possible to simplify FLAC decoding, so only storage is lossless but actual playback lossy?
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: Porcus on 2022-11-25 08:44:42
Is FLAC decoding slower than mp3?
FLAC is faster! At least on well-optimized compiles. The Rockbox gang would test this thoroughly: https://www.rockbox.org/wiki/CodecPerformanceComparison
Notice in particular how several of these players will downclock as much as they can (for battery life!), in which case the relevant figure in the respective table is the MHz number.

Say if you text-search for the first table done on an iPod Classic, then it would downclock to 8.05 MHz while decoding FLAC -8, while Lame at 96 kbit/s would need 20.47 (and Monkey's Extra High would need 220.47).
People would use FLAC over MP3 for extended battery life. Or well, at least they would use FLAC over MP3 for "I got more playback time than you have!". While Monkey's users - remember that not only CPU but also storage was expensive, so Monkey's had a heyday - would align themselves to what ape setting they could play back in real time.

8 MHz is ... not much! A mere 190 CPU cycles for each of the 88200 samples you need to get in place every second. As a Rockbox dev put it, you can decode a few FLAC samples by hand with pen and paper - and lo and behold, ktf & co do decode a couple of frames in the IETF draft spec: https://www.ietf.org/archive/id/draft-ietf-cellar-flac-07.html#name-first-audio-frame
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: ktf on 2022-11-25 10:00:34
I was able to decode mp3 on 40MHz 68040 and have spare CPU time to do other things. Is FLAC decoding slower than mp3?
My results are from an emulator, so I wouldn't be surprised if actual decoding speed is twice (or half) what I got. It is just a rough estimate.

In general, looking at the RockBox results Porcus linked, FLAC is about twice as fast as MP3 on these very low power ARM7, ARM9 and ARM11 CPUs. Could very well be numbers are very different on x86, or the instruction set that Motorola uses.

Looking at the results here (http://audiograaf.nl/losslesstest/Lossless%20audio%20codec%20comparison%20-%20revision%205%20-%20cdda.html) one could extrapolate that reasonably modern superscalar, out-of-order x86_64 CPUs could decode FLAC with 7.5MHz or less. Wouldn't make any sense though.
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: danadam on 2022-11-25 10:46:06
AMIGAAAH!  :D
I was able to decode mp3 on 40MHz 68040 and have spare CPU time to do other things. Is FLAC decoding slower than mp3?
Most common 14MHz 68020 or 7MHz 68000 might surely be not enough...
According to this (http://eab.abime.net/showthread.php?t=91092):
Quote
Minimal configuration to play flacs realtime is 68030/50 - and some may still fail. Trying with lower lpc setting when encoding can help (lowering the replay frequency also does, of course).
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: shadowking on 2022-11-25 11:20:05
What about WAV ?  It should even less demanding than flac
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: Porcus on 2022-11-25 11:51:33
Sure. Uncompressed WAVE requires no "decoding" to produce the samples, they are there in order. 

For nitpickery, you might add: "presuming the appropriate endianness". Indeed, the reason for RIFF (over IFF) was that it was fit for little-endian. (And for even more nitpickery: the device needs to know signed vs unsigned.)
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: Replica9000 on 2022-11-25 20:46:03
Resurrected the old 586 (socket 7) I built 22 years ago.  One of the memory sticks died and had to re-seat the GPU, but she still works! 

The CPU was released in April of 2000, and FLAC v0.5 (beta) was released about 9 months later.
 
Hardware:
CPU: AMD K6-III+ @ 550MHz
RAM: 128MB @100MHz
HDD: WD 40GB ATA100
OS: MS-DOS 7.1 (Win98)

Test Files (cdda/44.1/16):
The Fragile.flac - 1:43:48 (6228s)
Ghosts I.flac- 27:03 (1623s)
10 Miles High.flac - 5:14 (314s)

Seems as though the HDD is the bottleneck when decoding back to wave files.

10 Miles High:
-d = 13s
-0 = 11s
-1 = 14s
-2 = 16s
-3 = 26s
-4 = 35s
-5 = 48s
-6 = 81s
-7 = 100s
-8 = 165s

Ghosts I:
-d = 64s
-0 = 67s
-1 = 73s
-3 = 130s
-5 = 256s
-8 = 859s

The Fragile:
-d = 232s
-0 = 273s
-1 = 300s
-3 = 531s
-5 = 1005s
-8 = 3346s

USB 2.0 is quite a bit slower on this old machine than it is on modern machines.  Coping the files took a few minutes from my laptop to a USB 2.0 drive, but took almost 25 minutes to copy from the drive to the old machine.

10 Miles High (on the USB drive):
-d = 160s
-0 = 133s
-3 = 133s
-5 = 182s
-8 = 227s

I also have an old 286 laptop with MS-DOS 4.0 and I think Win 3.1, but I think storage will be an issue...
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: Porcus on 2022-11-25 23:13:17
Those who have a 32-bit Windows 10, can find a 16-bit compatibility mode: https://www.groovypost.com/howto/enable-16-bit-application-support-windows-10/

Uh, and for those who want to run their nostalgia speed tests:
FLAC 0.7 for Windows is available at https://sourceforge.net/projects/flac/files/flac-win/flac-0.7-win
Beware that it requires output filename and no "-o". And that the presets are quite different, so you probably want to give full switches like -l 8 -m -r 6 -b 4608 (only multiples of 576!) to "compare" and find out how much faster new FLAC runs. (Around a factor of 4.5-ish on that setting here.)
And -8 was ... ooooh, slow. And there was a -9 for testing purposes (week-end testing I guess). Right now at this new computer I get it to run at 4.5 x realtime. (Yeah, two 4.5, no typo.)
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: Chibisteven on 2022-11-26 01:32:48
Resurrected the old 586 (socket 7) I built 22 years ago.  One of the memory sticks died and had to re-seat the GPU, but she still works! 

The CPU was released in April of 2000, and FLAC v0.5 (beta) was released about 9 months later.
 
Hardware:
CPU: AMD K6-III+ @ 550MHz
RAM: 128MB @100MHz
HDD: WD 40GB ATA100
OS: MS-DOS 7.1 (Win98)

Test Files (cdda/44.1/16):
The Fragile.flac - 1:43:48 (6228s)
Ghosts I.flac- 27:03 (1623s)
10 Miles High.flac - 5:14 (314s)

Seems as though the HDD is the bottleneck when decoding back to wave files.

10 Miles High:
-d = 13s
-0 = 11s
-1 = 14s
-2 = 16s
-3 = 26s
-4 = 35s
-5 = 48s
-6 = 81s
-7 = 100s
-8 = 165s

Ghosts I:
-d = 64s
-0 = 67s
-1 = 73s
-3 = 130s
-5 = 256s
-8 = 859s

The Fragile:
-d = 232s
-0 = 273s
-1 = 300s
-3 = 531s
-5 = 1005s
-8 = 3346s

USB 2.0 is quite a bit slower on this old machine than it is on modern machines.  Coping the files took a few minutes from my laptop to a USB 2.0 drive, but took almost 25 minutes to copy from the drive to the old machine.

10 Miles High (on the USB drive):
-d = 160s
-0 = 133s
-3 = 133s
-5 = 182s
-8 = 227s

I also have an old 286 laptop with MS-DOS 4.0 and I think Win 3.1, but I think storage will be an issue...

That system with a socket 7 CPU should have zero problems playing FLACs.  I put together a socket 7 PC just last year.  Any x86 Windows machine from the mid to late 90's should be able to handle FLAC.  If it can run Windows 95 it'll probably handle FLAC fine (at least be able to play it).

I want to see a test with a CPU whose frequency is in the teens or twenties in terms of megahertz speed and something early 90's or late 80's.  Your 286 laptop sounds more interesting of the two to test.
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: Replica9000 on 2022-11-26 02:39:25
That system with a socket 7 CPU should have zero problems playing FLACs.  I put together a socket 7 PC just last year.  Any x86 Windows machine from the mid to late 90's should be able to handle FLAC.  If it can run Windows 95 it'll probably handle FLAC fine (at least be able to play it).

I want to see a test with a CPU whose frequency is in the teens or twenties in terms of megahertz speed and something early 90's or late 80's.  Your 286 laptop sounds more interesting of the two to test.

I'm not sure what size HDD is in the 286 laptop.  I think it's 30MB.  If I remember correctly, DOS and Win 3.1 only take up 6-7MB.  So I could only test with a small wave file, maybe 15MB.  I also think the only way I'm going to be able to transfer files is via floppy disk.  Maybe split and combine them after transfer, unless a ~1.44MB wave file is enough for a test. 
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: ktf on 2022-11-26 07:03:38
Seems as though the HDD is the bottleneck when decoding back to wave files.
You can use flac -t instead of flac -d to check. That way it fully decodes but doesn't write anything.

Quote
I also have an old 286 laptop with MS-DOS 4.0 and I think Win 3.1, but I think storage will be an issue...
This won't run on a 286. That is 16-bit, and this compile needs at least 32-bit to work. So, bare minimum is i386 with 80387 coprocessor.
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: Porcus on 2022-11-26 08:32:13
Oh. So you need a 32-bit architecture, but then it works on a 16-bit OS?
Is 32-bit bus needed? Asking for all those 386SXes around. I know of at least one in daily use, (https://www.kaspersky.com/blog/computers-in-space/1626/) you don't want a crash report from them.
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: Octocontrabass on 2022-11-26 09:13:45
Bus width doesn't matter, it will work on a 386SX. (Assuming you have a 387SX to go with it, of course.)
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: ktf on 2022-11-26 09:24:03
Just for reference, Intel introduced it's Pentium before I walked this earth, so I'm not totally sure on the details.

Apparently, MS-DOS worked fine on 16-bit CPUs like the Intel 8086. However, the Intel 80386, while preserving backward compatibility, added 32-bit capabilities. With the much more recent switch from 32-bit to 64-bit, you need a 64-bit OS to enjoy the benefits of a 64-bit CPU, but apparently, back in the day, it was possible to use 32-bit capabilities on a 16-bit OS. Windows OS before 95 (and not the NT variants) would run on 16-bit only, but capabilities were limited (https://en.wikipedia.org/wiki/Windows_3.1x#System_requirements): 80286 processor for standard mode, 80386 or higher for enhanced mode

This worked with so-called DOS extenders. There were 16-bit DOS extenders that only extended memory addressing, but much more common were 32-bit DOS extenders to extend memory addressing AND arithmetic to 32-bit. FLAC uses 64-bit arithmetic, which can be reasonably emulated with 32-bit but not so much with 16-bit. Also, even if FLAC were stripped of 64-bit arithmetic, it would be much slower.

Anyway, the compiler suite I build this with, djgpp, targets "32-bit extended MS-DOS". That means i386 minimum. Also, FLAC has a build option to disable the use of floating point instructions, but then the encoder can only encode fixed subframes, so presets 3 through 8 become useless. Decoder is unaffected by the way. However, I didn't use this build option, so an FPU is needed, which means the i386 will need an 80387 coprocessor, as it doesn't have a built-in FPU like we are used to these days.
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: Porcus on 2022-11-26 10:05:36
Ah, floating-point on Pentium![note] https://en.wikipedia.org/wiki/Pentium_FDIV_bug

The most powerful of the first-release Pentium was the Pentium 66 running at, apparently, closer to 67 MHz than 66.
There must have been 66.6 jokes around already then - all those sources who tell you about "Satan Inside" after the FDIV bug cannot all be conveniently backdating it a few years from the Pentium III 667 (https://www.cpu-world.com/CPUs/Pentium-III/Intel-Pentium%20III%20667%20-%2080526PZ667256%20(BX80526U667256%20-%20BX80526U667256E).html), can they?  :-X

(https://www.pelicancrossing.net/netwars/assets_c/2018/01/Satan_inside-thumb-360x450-698.jpg)



[note] OK, to those who don't know FLAC internals: FLAC does not depend on floating-point math being "correct".
FLAC works by creating a "predictor" to "coarsly approximate" the signal, and because it has to be lossless in the end, it also has to encode the difference between signal and predictor ("residual").
A better predictor leads to better compression. A worse predictor leads to worse compression. Buggy floating-point math will at worst give you a worse predictor, because once a (good or bad) predictor is found, the rest of the encoding is done "in integer math".
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: Replica9000 on 2022-11-26 17:39:08
The laptop is a no go anyway.  The HDD is dead and it won't boot from floppy.  The only thing I have between the 286 and my K6-III+ is a Pentium 233 chip (that'll work on the same board as the K6-III+).  It's configured by jumpers so the lowest I can run it at is ~133MHz which should still be able to play Flac files just fine.
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: Octocontrabass on 2022-11-26 21:13:26
Just for reference, Intel introduced it's Pentium before I walked this earth, so I'm not totally sure on the details.

[...] 32-bit DOS extenders to extend memory addressing AND arithmetic to 32-bit.
Well, thanks for making me feel old. A DOS extender is only necessary for 32-bit addressing; it's possible to do 32-bit arithmetic without one.

However, I didn't use this build option, so an FPU is needed, which means the i386 will need an 80387 coprocessor, as it doesn't have a built-in FPU like we are used to these days.
Somehow I forgot this when I posted earlier (must be getting old  :)) ), but DOS extenders can include FPU emulators, so you might not need a FPU.
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: ktf on 2022-11-27 09:56:43
Just for reference, Intel introduced it's Pentium before I walked this earth, so I'm not totally sure on the details.

[...] 32-bit DOS extenders to extend memory addressing AND arithmetic to 32-bit.
Well, thanks for making me feel old. A DOS extender is only necessary for 32-bit addressing; it's possible to do 32-bit arithmetic without one.
Are you sure? That doesn't seem to make sense: how would an application access a 32-bit register to do arithmetic on from a 16-bit OS? 32-bit arithmetic can be emulated that way, but that is very slow. Here's something written on the subject, I don't know how reliable that is: http://wiki.freedos.org/wiki/index.php/DOS_Extender

Quote
When running 32-bit DOS applications using the DOS Extender, the CPU runs in Protected Mode (a special mode of 80386 and higher CPUs that allow use of advanced features including access of 4GB of memory, 32-bit registers, memory paging and protection, etc). This is different from Real Mode, which is the standard mode for 80286 and higher CPUs, and the only mode of 8086/8088 CPUs.
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: Porcus on 2022-11-27 11:22:12
Another question: decoding shouldn't need floating-point - but maybe it is non-trivial to do away with that?
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: ktf on 2022-11-27 12:14:06
libFLAC can be specifically compiled without needing floating-point math. This was done mostly to make porting to embedded architectures easier. In the decoding part of this library, there are only two uses of floating point in seeking, and these are replaced with (less accurate) fixed-point approximations when necessary.

However, the flac command line tool is not programmed like that, because those tools aren't really useful in embedded environments. It uses floating point calculations in a few places for convenience. For example, to calculate the completion percentage and the compression ratio. These are trivial to replace, but there is no alternative code currently.

So, an FPU is necessary with these compiles, but a soft FPU will probably not harm performance much on decoding.

edit: apparently building this with an FPU-emulator (only used when necessary) is rather easy. http://www.delorie.com/djgpp/v2faq/faq11_1.html
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: ktf on 2022-11-27 19:27:50
Just did some tests on an Intel Pentium 200MHz with Windows 98. A label on the PC marked it as a P54C running on 200MHz, but according to Wikipedia it is actually a P54CS. It was introduced in June of 1996 and if memory serves me right, the computer originally came with Windows 95 instead of 98.

Results for Nine Inch Nails - HYPERPOWER! from the album Year Zero. The track has a playback length of 102 seconds and is CDDA (stereo, 44.1kHz, 16-bit PCM).

Decoding of file compressed with preset 0: 10 seconds (10x realtime)
Decoding of file compressed with preset 8: 13 seconds (8x realtime)
Re-encoding file with preset 0: 24 seconds (4x realtime)
Re-encoding file with preset 8: 197 seconds (0.5x realtime)

I've also taken a 24-bit file with a length of 10.000.000 samples. While it was 44.1kHz, I'll calculate realtime numbers as if it was 96kHz, as to emulate a 96/24 file. The file has a 'length' of 104 seconds then.

Decoding of file compressed with preset 0: 28 seconds (4x realtime)
Decoding of file compressed with preset 8: 43 seconds (2x realtime)
Re-encoding file with preset 0: 83 seconds (1.2x realtime)
Re-encoding file with preset 8: 600 seconds (0.2x realtime)

So, apparently, an old original Pentium clocked at 200MHz can decode high-res FLAC fine in realtime.
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: Octocontrabass on 2022-11-27 23:19:59
Are you sure? That doesn't seem to make sense: how would an application access a 32-bit register to do arithmetic on from a 16-bit OS?
Yes, I'm sure. Applications can access 32-bit registers using the operand size override prefix (0x66). Assemblers that support i386 instructions will automatically add this prefix when writing code to access 32-bit registers from within a 16-bit OS. There's no way for an OS to prevent applications from using this prefix.

Here's something written on the subject, I don't know how reliable that is: http://wiki.freedos.org/wiki/index.php/DOS_Extender
It's not entirely accurate, but there aren't many applications that use 32-bit registers without also using 32-bit addressing. If you use 32-bit registers, your program requires a 32-bit CPU, so you might as well use 32-bit addressing too. (32-bit addressing is a lot more convenient than 16-bit addressing.)

Another question: decoding shouldn't need floating-point - but maybe it is non-trivial to do away with that?
At least the decoding speed indicator requires floating-point. I'm not sure if silencing it will avoid all of the floating-point code paths. There are also ways to tell the CPU to silently ignore floating-point instructions when a FPU isn't available, but then FLAC might misbehave when it sees gibberish results in its floating-point math.
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: ktf on 2022-11-28 06:27:33
Are you sure? That doesn't seem to make sense: how would an application access a 32-bit register to do arithmetic on from a 16-bit OS?
Yes, I'm sure. Applications can access 32-bit registers using the operand size override prefix (0x66). Assemblers that support i386 instructions will automatically add this prefix when writing code to access 32-bit registers from within a 16-bit OS. There's no way for an OS to prevent applications from using this prefix.
Interesting. It is rather clear the migration from 32-bit to 64-bit went very differently compared to the migration from 16-bit to 32-bit. No need for a new OS with the right kernel and an enormous amount of DLLs for both 64-bit and 32-bit environments (so called WoW64) just set the right prefix.  :))
Title: Re: Back to the future: FLAC 1.4.2 for MS-DOS
Post by: Octocontrabass on 2022-11-28 17:36:29
Interesting. It is rather clear the migration from 32-bit to 64-bit went very differently compared to the migration from 16-bit to 32-bit. No need for a new OS with the right kernel and an enormous amount of DLLs for both 64-bit and 32-bit environments (so called WoW64) just set the right prefix.  :))
You definitely needed a compatible OS to use 32-bit registers! DOS was compatible because it was single-tasking. You couldn't get away with that on something like 286 Xenix.

In retrospect, making 32-bit registers available in 16-bit mode was a very odd choice...