Windows 10: Why not a 16bit on a 64bit system

Hi,

I'm not sure if this question ought to be here or in hardware, but it does have to do with software and apps.

I have a 64bit processor. It can run 32bit software, but not 16bit. I can understand why a 32bit processor could not run a 64bit program as the 64 bits do not fit into the 32 bit registers. I can understand why a 32 bit program will run in a 64 bit processor - as long as it recognises that it is a 32 bit program so there are no overflow problems. But I can't understand why a 16 bit program cannot run in a 64 bit processor. Surely there should be no greater problem doing this that for a 32 bit one. Or is there?

Matt

:)

 

I installed lotus smartsuite 97 on Windows 10. Worked great until a reboot, it appeared like screen flashing. It looked as though Reggie maybe corrupt, guess.

Are you using the 32 bit or 64bit version of Windows 10?

Is Smart Suite 97 16bit or 32bit?

 

Incompatible games for new HP laptop.

The original version of these games are DOS based games and will not run on Win10 ( shouldn't run on Win7 either ).

DOS based games need to run through DOS BOX (an DOS emulator ). The link below is to a user interface

that helps make the included DOS BOX a bit more user friendly.

D-Fend Reloaded: Overview

- They most likely also use 16bit installers, which are not compatible with 64bit Windows (32bit is OK).

I haven't done a search, but some of the more popular games with 16bit installers have 64bit custom installers on their fan sites

(I have one for my disk based version of Grim Fandango) .

( DirectX based games that use 16bit installers will generally run on 64bit, but have to be installed to a 32bit Windows

and copied to the 64bit Windows. )

.

 

It's not just a matter of register size. Any non-trivial 16-bit program will use OS and hardware resources from the DOS/Windows 9x era that may not be available today.

The processor actually has to switch to a different mode when running a 32-bit or 16-bit program from a 64-bit OS. For historical reasons, possibly because AMD didn't want anything to do with ancient Intel CPU modes (recall that AMD actually developed the 64-bit x86 ISA), VM86 and real mode are not directly accessible from long (64-bit) mode.

So 16-bit DOS programs cannot run at all from a 64-bit OS but a 16-bit Win9x program theoretically could in compatibility mode. However, to support this Windows needs to translate legacy API calls (i.e. win32 APIs that have been removed or modified) and hardware accesses into ones compatible with current Windows APIs and drivers. Most likely MS decided that it's so easy to run a VM that there's no need to keep maintaining this translation layer.

Legacy 16-bit Applications on 64-bit Operating Systems - Xylos Blog has a pretty clear description.

 

As is so often the case, things are more complicated than they first appear.
A 64 bit capable CPU has 2 different operating modes, 64 bit mode and 32 bit mode. There are actually more but they are not relevant to the current situation. These modes are set at system startup and cannot be changed without a system restart. While in 32 bit mode the CPU can run either 32 or 16 bit code. While in 64 bit mode it can run either 64 or 32 bit code. It cannot run 16 bit code. It is important to understand that this CPUs ability to run downlevel code is not automatic. It is something that must be explicitly designed in and it is not simple. The CPU behaves in some very significant ways in the different modes.

And there is more.
The ability of a 64 bit OS to run 32 bit applications is not automatic, even with a compatible CPU. The native 64 bit environment is totally alien to 32 bit applications and they would not be able to cope. To make this work a 64 bit OS but create a complex artificial environment for 32 bit applications.

Similarly, a 32 bit OS has no automatic ability to run 16 bit applications. It must have a 16 bit subsystem that provides the environment expected by 16 bit applications. 64 bit operating systems do not have this subsystem because the CPU would not be able to run it anyway.

The bottom line is that 16 bit, 32 bit and 64 bit operating systems differ in very significant ways beyond the bit count. They could have been designed to be more alike but there was the desire that the operating system take advantage of the capabilities of the new 32 and later 64 bit processors. A wise choice.

A 64 bit OS can run 16 bit applications in a compatible OS running under a virtual machine such as VMWare or VirtualBox. This is technically far more complex and there is a performance penalty. And you need a legal copy of the OS used.

 

Thank you so much for your explanations. I can't say I understand all of it, but I do now understand that it's more complicated than I thought.

One of the main reasons for my question is that I have a printer that's around 15 years old, and it works perfectly well (I have no intension of getting rid of it, and in fact it works (or did work) better in some resects than the more modern ones). However, the printer's main manufacturer's driver and the software that allows significant control over it is a 16 bit system, which will not run on my current 64 bit machine, and there is no compatibility setting. There is no upgraded version of the driver and software, so I have to use the only available driver, which is the Windows basic one. This doesn't give a satisfactory result, but I'm loathed to give it up. Running a VM is fine but it doesn't allow direct through-put that I'm aware of.

Another reason - very similarly - is a piece of graphic editing software that I have used for two decades and is very good - not to mention very familiar. As a 16 bit program it will no longer work on my system. I am not very comfortable with the modern all-singing-all-dancing graphic editing programs.

My initial thoughts were that if I'd realised that these pieces of software would not work on a 64 bit system I would have resisted the temptation to buy a top(ish) end of the range system. However, the speed of computer advancement, suggests that, even if I had resisted, there would very quickly have been no option. I seem to be very quickly and continuously being forced into places where I will have to get rid of the things that are perfectly good in their own right, simply because tech is advancing so quickly and is leaving the good old software programs unusable.

Sorry - rant over.

Matt

 

Adding to all of this is that the later computers, probably back several years, have had the 25-pin/socket LPT1 port left off in favor of USB. Same for the older 9-pin and 25-pin COMM ports, no often needed.

I've kept a WinXP computer as it has both 3.5" and 5.25" floppy drives and a 250MB Zip drive, useful for folks coming across those type disks and want to know what is on them. The floppy support in the BIOS and the ports/sockets for the cable to the motherboard have been left off for some time now.

 

A simple answer.

It is to costly for the manufactures, creators of programs and hardware to have the ability of using 16, 32, and 64 bit.
Fifteen year old hardware and software will just have to be upgraded and or replaced.

It's just not price and time feasible for the use of old 16 bit hardware and programs to be usable in today's computing world just to make a few customers happy.

Jack

 

Hi, Berton, I tried something similar up till a few years back, but I found that other software that I 'had' to use meant that I was more often on the newer one; and as space was tight, it eventually had to go. For a long time, I had one that was just running DOS/Win 3.1. I still currently have a small XP laptop that I get out every now and then.

Jack. I agree with you, but it's not just the hardware that the software writers are concerned with. Much of the software support is removed simply because the other software, such as older OSs, are just not used as much. Dropbox is an example. The support was removed from XP versions. One of my home (the laptop) and one of my works computers both still uses XP; both have Dropbox. The works one uses it all the time. We now have to access it via the website. My understanding is that the software their end has to be maintained, and that's the reason for them discontinuing support. But what they could have done is remove support and explain the vulnerability but keep the XP system active as there is still a significant proportion of XP users. But they discontinued connectivity.

But it's not just the cost of integrating with 'old' hard/software systems that many software writers are concerned with. There are some (not all) that seem to deliberately upgrade and create incompatibilities with slightly older systems simply so that consumers will have to upgrade. That's how they make their living. [A certain operating system] used by many is a typical example in the news lately. The deliberate incompatibility with systems require upgrading, either the OS or the hardware.

But my biggest problem is not this. It's simply the short timeframe for the incompatibility stages. To have a life-style system, such as ones home computer, to be continually out of date just a couple of years after purchase, is quite frankly intolerable. Yet if I want to use a computer, by-and-large I have to put up with the changes and continually upgrade my system. I cannot think of any other life-style system that operates with the same speed. Cars, for instance, are changing all the time, but not so fast as to make your 35-year-old one obsolete. You could probably still get all the parts for it.

Sorry - I'm on my soapbox again.

Matt

 

Matt, I understand what you are posting.
One just has to be a little bit of a realist.
Everything in the computing world moves very fast; hardware, software and methods. In the most part things get better for the consumer.
We just have to keep buying things. Of course money and profits are one of the driving reasons. Their are other reasons. The producers of software and hardware have to keep make new and better things or the competition will run them out of business.
Their really isn't anything wrong with Windows 7, it just stopped producing money, (sales). Older Microsoft operating system cost lots of time and money for Microsoft to keep updated and or upgrading. So now we have Windows 10 with all it little goodies, (most I don't use).


Jack

 

Thank you Jack. I personally thought XP was perfectly good. And is still used by many large companies (the large high street bank I recently went into, for example). And I do appreciate the need for companies to keep ahead of the game for fear of losing out and going bust. It's just a shame (and to me, often a serious inconvenience) that this has to be the way of the world.

One thought has recently occurred to me in light of the comment made in this thread. (I am unfamiliar with many of the technical terms and soft/hardware architecture, so please bear with me.)

What little dealings I have had with programs such as DOSBox and VirtualBox, I understand that these systems are self contained, i.e. they deal very little with the systems outside of themselves. With VB I have installed XP and Win3.1 in it, but I don't think that I could install just a driver, for instance and run it alongside a Win10 program. (I'm not sure if that makes sense.)

What I'm asking is, is there a piece of software that can 'contain' a 16bit driver or piece of software and make it look from the 64bit OS that it is, say, a 32bit program? Hypothetical e.g., the graphics program that I referred to earlier is loaded through this 'converter'. Win10 x64 looks at it and only sees a 32bit (or even 64bit) system/program/driver, and runs it as such.

I appreciate this might be difficult, but would it be possible? If so, I would have thought that, once the 'converter' has been produced it would not really need to be upgraded.

Sorry if this idea is complete nonsense.

Matt

 

Direct binary conversion of 16-bit code to 32/64-bit code, while theoretically possible, means implementing the entire x86 ISA and all it's quirks in software. At that point you're basically writing an emulator. DOSBOX and QEMU have been around for 15+ years and they still have emulation issues. In addition, you would still require an OS-level translation layer to handle memory, hardware accesses, and software interfaces.

Even on 32-bit Windows, where the CPU can actually be switched to 16-bit mode, a translation layer was needed to run 16-bit apps - Virtual DOS machine - Wikipedia .

So what you're saying is possible but MS has very little financial incentive to do it.

 

If you use Linux with 32 bit WINE that will run 16 bit Windows apps or a lot of them.