Hacker News Reader

Comment by jhallenworld | Hacker News Reader

This makes no sense to me. Backward compatibility is a huge competitive advantage for Intel, and IMHO, it's royally messed up that vm86 mode doesn't work in 64-bit mode.

One DOS application I use was hurt by this: "old DOS OrCAD". It works well in Windows-XP on a 32-bit machine, but does not work at all in 64-bit Windows. (It's actually a 32-bit DPMI program and has drivers to use Windows GDI so you don't have to mess around with drivers).

More evidence: IBM 360 mainframe software still works in Z/OS.

It might be worth it for non-generic computing devices like cell phones, but Intel missed the boat there already.

View on HN

16-bit x86 code is ancient enough that a software emulation solution can be fast, efficient, and perfectly compatible, so there's no need to keep support for it in hardware at this point.

Microsoft could have used emulation to keep old 16-bit x86 apps working with Windows for AMD64 (in fact they had done this before for non-x86 architectures) but I guess they weren't interested. WINE and DOSBox did it though.

16 bit code is most times braking due to Windows being itself incompatible so you need to emulate it anyway.

And if you have very old but important windows legacy software you either want to also run old hardware and windows OS anyway or run enumeration anyway.

On linux this is somewhat already the case, most distroes are by now for OS 64bit only with at most 32bit application support but not always enabled by default.

> vm86 mode doesn't work in 64-bit mode.

vm86 doesn't work in 64-bit mode, but you can simply temporarily switch down to 32-bit mode, and them vm86 works just fine. Early amd64 Linux would do this, and there was even a kernel module to do it after they dropped support for it.

Microsoft had other reasons to drop 16-bit support in Windows 64.

Microsoft had other reasons to drop 16-bit support in Windows 64

Namely, planned obsolescence. They realised that forcing people to consume could squeeze a little more $$$ from them.

Legacy systems and architectures can’t be around forever.

How many people in the PC market still use 16-bit applications?

>Legacy systems and architectures can’t be around forever.

Why not? The bits don't decay.. Yes, this leads to an architectural mess, but I'm talking about a competitive business advantage.

> Why not?

> Yes, this leads to an architectural mess

Right there.

There's no notable advantage in supporting a very small minority of the applications out there, at the cost of keeping units useless for the 99%.

> There's no notable advantage...

Potentially one if a large customer's paying you for it.

At work, I'm helping a client upgrade from a decade old version (v12) of our product and having to copy over the switches to keep the even older (v11 and previous) behaviours

Ten years ago was 14 years after the introduction of the x86 64-bit instruction set, and 28 years after x86-32.

I’m quite sure we will be OK without support for 16-bit instructions.

Question is, what is the cost of keeping the old cruft around?

Essentially none. It's all make-work (or, since they're intent on breaking things more than fixing them, break-work.)

I wouldn’t say “none”. Real estate in CPUs is extremely expensive.

My immediate sense is that the entire vector system easily dwarfs the 16bit system.. as I'm guessing most of the modern 16bit mode is entirely in microcode.

...and taken up mostly by cache and vector execution units.

An 8086 has 29000 transistors. A modern CPU has several billion. The amount needed to implement the 16-bit subset of the ISA is an absolutely tiny fraction of the total area.

Ah, I see you don't work in the field.

A few of the cost of legacy:

* exponential growth in verification space (each feature combines with all other features),

* design complexity (effort that could be spent better),

* area/power/cycle time overhead (all options require more ports to muxes, more wires to run, etc.)

* and most importantly, opportunity costs: some optimization tricks can't be pursued because the assumptions would break for legacy code

The legacy tax is real

Ah, I see you don't work in the field.

I won't give away too much of my personal history, but it suffices to say I've worked with x86 at the hardware level before.

each feature combines with all other features

They do, but orthogonally.

effort that could be spent better

Effort that has already been spent.

all options require more ports to muxes, more wires to run, etc

It's all ultimately split into uops anyway.

some optimization tricks can't be pursued because the assumptions would break for legacy code

What assumptions in particular?

Well, everything I said was true but I don't think we can agree on that, so I'll just end it here.

Sad.

and has drivers to use Windows GDI so you don't have to mess around with drivers

This was a thing? So, would it still run in the "MS-DOS Command Prompt" in Windows but talk directly to Windows for its screen drawing?

Yes, here is how to do it:

https://airborn.com.au/layout/vddtest.html

A 16-bit DOS application using DirectX..

In the case of OrCAD this was very easy because it already had plug-in architecture for graphics. It had this because even the mouse was not standardized in the early days.

How interesting! Wasn’t aware such programs existed. Thanks.

and IMHO, it's royally messed up that vm86 mode doesn't work in 64-bit mode.

You can blame AMD for that and the other dubious decisions in the design of amd64 in general.

Out of curiosity why are you still using a 16bit DOS CAD application?

Reply on news.ycombinator.com