Re: Byte ordering

On 10/4/2024 12:30 PM, Anton Ertl wrote:

David Brown <david.brown@hesbynett.no> writes:

On 04/10/2024 00:17, Lawrence D'Oliveiro wrote:

Compare this with the pain the x86 world went through, over a much longer
time, to move to 32-bit.

>
The x86 started from 8-bit roots, and increased width over time, which
is a very different path.

 Still, the question is why they did the 286 (released 1982) with its
protected mode instead of adding IA-32 to the architecture, maybe at
the start with a 386SX-like package and with real-mode only, or with
the MMU in a separate chip (like the 68020/68551).
 

And much of the reason for it being a slow development is that the world
was held back by MS's lack of progress in using new features.  The 80386
was produced in 1986, but the MS world was firmly at 16-bit under it
gained a bit of 32-bit features with Windows 95.  (Windows NT was 32-bit
from 1993, and Win32s was from around the same time, but these were relatively small in the market.)

 At that time the market was moving much slower than nowadays.  Systems
with a 286 (and maybe even the 8088) were sold for a long time after
the 386 was introduced.  E.g., the IBM PS/1 Model 2011 was released in
1990 with a 10MHz 286, and the successor Model 2121 with a 386SX was
not introduced until 1992.  I think it's hard to blame MS for
targeting the machines that were out there.  And looking at
<https://en.wikipedia.org/wiki/Windows_2.1x>, Windows 2.1 in 1988
already was available in a Windows/386 version (but the programs were
running in virtual 8086 mode, i.e., were still 16-bit programs).
 And it was not just MS who was going in that direction.  MS and IBM
worked on OS/2, and despite ambitious goals IBM insisted that the
software had to run on a 286.
 The fact that the 386SX only appeared in 1988 also did not help.
 

If old stuff is still around and usable, it works...
Meanwhile, nowadays stuff is starting to decide that my Zen+ is too old...
Win 11 apparently regards my system as incompatible (not that I would really want to run it anyways; would almost rather jump over to Linux land at this point if Win10 becomes unusable, which possibly isn't really a good sign).
I am left still running WSL1 and needing to resort to FOSS emulators when needed (like DOSBox and QEMU), because WSL2 and most commercially made VMs had gone over to requiring hardware virtualization, which doesn't work on my PC for whatever reason (despite being supported by the CPU and enabled in the BIOS, *).
If stuff isn't cheap, people aren't going to just drop whatever they have and buy something new as soon as it appears on the market.
So, conservatism makes sense here: Delay requiring new thing until pretty much everything in the wild is new enough to support it.
*: WSL1 works apparently by emulating Linux syscalls on top of the Windows kernel, whereas WSL2 runs a Linux kernel in a VM apparently with a translation glue layer to interface with the underlying OS.
Ironically, a use-case for DOSBox is using it to run Win 3.11, which amusingly is able to run most Win16 era software, in the cases where one feels inclined to run Win16 era software. There are some tools from this era that ironically lack good modern equivalents.
Say, pretty much none of the modern graphics programs (that I am aware of) really support working with 16-color and 256-color bitmap images with a manually specified color palette.
Typically, any modern programs are true-color internally, typically only supporting 256-color as an import/export format with an automatically generated "optimized" palette, and often not bothering with 16-color images at all. Not so useful if one is doing something that does actually have a need for an explicit color palette (and does not have so much need for any "photo manipulation" features).
And, most people generally haven't bothered with this stuff since the Win16 era (even the people doing "pixel art" are still generally doing so using true-color PNGs or similar).
Could theoretically make my own, but had thus far not bothered.
Well, and in some cases it is less effort to use modern image editing tools and then convert the images into 4 or 8 bit BMP images as needed (so, for reasons of internal wonk, besides just being a compiler, BGBCC also has some image and audio conversion functionality; mostly in relation to working with resource sections and WADs).
Theoretically, there is also a BMP editor hidden in Visual Studio somewhere, but not really an easy/obvious way to get to it. Trying to invoke Visual Studio on image files does not appear to work.

- anton