Howto use a 16 bit program on 64 bit Windows.

[Geek-9pm]

Some old programs are 16 bit. Maybe you have one or two that you would like to use, but Windows will give you an error if you are using a 64 bit version of Windows. And it is not just Windows 10 64 bit, even older versions of Windowsd do not let you run an old 16 bit program.
Unless you really try hard. Very hard. 
See this  thread on  answers.microsoft.com
https://answers.microsoft.com/en-us/windows/forum/windows_10-windows_install-winpc/is-it-possible-to-run-a-16-bit-program-on-windows/50497e46-707e-42b4-af7f-539037f5d0a0?auth=1

If you have a compatible version of Windows the application works with, see instructions how to setup a virtual machine.

That leads to this:
https://www.groovypost.com/howto/create-virtual-machine-windows-10-hyper-v/
No, I am not going to try it.   

[patio]

1 question...why do you need to ? ?

Just curious.

[Geek-9pm]

1 question...why do you need to ? ?
Just curious.

Mistakenly, I thought it had to be simple. If they do it in the 32 bit version, there ought to be an easy way to do it in the 64 bit.
But was wrong. I looked and looked and the only answer was to use a virtual machine.

I have both 32 bit and 64 bit versions of my Windows 7 and Windows 10. Someold programs I like are the old simple 16 bit things.

I should know better. The term '16 bit"in this context does not simply mean a 16 bit memory span, rather it means the strange way Intel created the memory scheme of the original 8086 CPU.   

Now for some Intel History:
https://www.pcworld.com/article/146957/components/article.html
Birth of a Standard: The Intel 8086 Microprocessor

he release of Intel's 8086 microprocessor in 1978 was a watershed moment for personal computing. The DNA of that chip is likely at the center of whatever computer--Windows, Mac, or Linux--you're using to read this, and it helped transform Intel from merely one of many chip companies to the world's largest.
What's most surprising about the tremendous success of the 8086, though, is how little people expected of it when it was first conceived. The history of this revolutionary processor is a classic tale of how much a small team of bright engineers can accomplish when they're given the freedom to do their jobs in innovative ways.

The article might be misleading.  The Apple people stayed away from  Intel stuff for a reason. Intel assembly language is /was very painful before the 386 was made yearns later. Linux could not exist until the 386 came. The 8800 never made it out of the gate

The 386 was a big winner. It had a  32 bit flat memory. Yet it could also do the 16 bit thing the same way the 8086 did.  Before that the Motorola 68000 was  a preference of many professional programmers and that was the choice of Apple when then later wanted to made a better PC. If Intel had not invented the 386 to take over from the 8986, we all might have Motorola chips today and Intel would have been forgotten.

One mow quote:
It would probably have had a radically different instruction set, but all PCs today would be based on that architecture instead." In a similar vein, IBM veteran Bradley jokes, "If IBM had chosen the Motorola 68000 for the IBM PC (as some wanted), we would have had the WinOla duopoly rather than the Wintel duopoly."

That is way you can not run 16 bit on a 64 bit system.   

[BC_Programmer]

It's not impossible to run 16-bit code on a 64-bit CPU, just not possible to run it directly on the CPU when operating in 64-bit Long mode. For example in 32-bit Protected Mode you can still thunk and run 16-bit instructions, and in 64-bit Long mode, you can do the same and run 32-bit instructions, however you cannot, in 64-bit long mode, thunk down to 16-bit and run 16-bit instructions. Because of that, it would be necessary to write a full-blown x86 emulated environment in that case, and in the case of Windows apparently it wasn't considered a worthwhile engineering investment. Fact is you can download and use any number of emulation or virtualization programs and run that software, just not directly. I have some PCEM setups that attempt to accurately emulate the original IBM PC as well as the IBM XT, so perhaps the thoguht was users could download BOchs, PCEm, VMWare, VirtualBox, etc. if they needed to run that sort of software.

68K had the early benefit of being 32-bit only. Not only that, but since was no backwards compatibility legacy there was no legacy to be compatible with- the entire instruction set was 32-bit. Simplified everything to not have any context switches. Even the 6888x co-processors were better designed, but that was again largely because of there being no particular need for backwards compatibility. Intel learned that lesson twice- first with the 80186 and then later with the Itanium.- as much as they might want to they cannot realistically come out with a new CPU design that drops backwards compatibility because no matter how revolutionary or amazing it's design, nobody will want it unless they can use it with existing software. the 68K had a bit of a jump-start by being present in the Macintosh, which helped jump-start it's position.

Even the co-processor design was better. the original 8087 was sort of a mess- completely different, stack-based approach from the 86, and thanks to backwards compat it's still stack-based today. Rather goofy design. the 6888x co-processors were generally "better" and more simple to interface with. Their main downfall being transcendental trig functions which could actually be executed faster by emulating floating point on the main 68K, largely thanks to some cache performance differences.

It's big disadvantage and why it was eventually dumped by Apple in favour of the PowerPC was that it wasn't really forward capable, it wasn't able to "evolve" as quickly to compete with other processors. Even the 80286 was giving it a run for it's money in '87- the 386 was more or less a finishing move- Apple managed to move on to the PowerPC by 1994. PowerPC itself being another beast altogether, too.

PowerPC is pretty interesting as well. There are some Linux distributions that will run on it. (Yellowdog). Like Motorola PPC eventually got supplanted because Intel just had more manufacturing scale available to overcome engineering problems.

Not to mention the PowerPC's issues regarding power Draw.  A fully loaded Power Mac G5 could draw a full megawatt! Later models even had to use a different IEC connector (C20) for high amperage. Mine is a "boring" Single core-single CPU system.

The 64-Bit transition with Intel is interesting as well. I mentioned the Itanium- the IA-64 Architecture was Intel's first foray into 64-bit and for the most part they sunset support for the x86 altogether- it required software emulation. So in s ome Some Intel was going "Alright time to get rid of all this legacy crap so we can make a nice speedy chip!" but... well nobody really liked it. Software vendors needed to provide 64-bit versions of their software or it would run terribly through software-side emulation, and software vendors would only commit to it if the userbase was high enough, and users wouldn't buy them unless the software they used ran on it, etc.

AMD came out with AMD 64 and defined a 64-bit operating mode that allowed the chip to be fully backwards compatible while supporting 64-bit operating modes. More or less AMD did the same thing Intel did when moving to 32-bit. Intel eventually gave up in IA-64 and through a series of legal battles with AMD eventually agreed to license AMD64.


The most interesting part to me is where x64 came from. x86, after all, had the x "stand" for 2, 3, 4, 5 (Pentium) etc. but what does the X stand for? IK recently saw some rants about how x64 is gibberish and nobody should say it because it's wrong.

That caused me to look into it and determine where the term came from. I doubted that it was "a stupid naming decision made by idiots at Microsoft with Windows XP x64 Edition" and I was sure there was reasoning there.

And it turns out there was. Turns out that AMD and Intel do actually implement different instruction sets. Intel's is called "Intel64" and AMD's is called "AMD 64" so "x64" refers to the common instruction set between them- it "stands in" for AMD and Intel.
 

[DaveLembke]

Why not just run the 16-bit programs through your 32-bit OS system which is backwards compatible to 16-bit games/applications. Virtualization like what BC touched on is a way to run them in a 64-bit OS.

*Note: Some 16-bit games and applications may be hardware specific though. I have for example some really early games made for an 8088/8086 type system and those games the minute you start the game your dead because they were designed around 4.77Mhz clock and weaker CPU for processing, and at 2.7Ghz its as soon as the game starts your dead because for example a generic pac-man written by someone 35 years ago didnt have any realtime timer in it to be able to work on any clock frequency CPU. Back when I had a 286 12Mhz it ran the game faster than it should because it was faster clock. Also I have run into some of my games not running because they paint the graphics in a manner than modern video cards lack the legacy support for.

Its best to pair the software with a computer of the period. Thats one of the reasons why I keep some old slow computers kicking around is to play games on hardware that they were originally designed for vs having to tweak modern systems to run older games etc. Even with my favorite game of Unreal Tournament 99 I have to run a core affinity setting to get this game to behave as for on systems with more than 1 core or even 1 core with Hyperthreading the game acts up. But by specifying the game to only run on Core 0 with core affinity set, the game runs perfect on a new computer. While if I fire up my Pentium 3 700Mhz and play the game on that I dont have the issues because its a game designed to be played on a single core system on a single core system. Diablo 1 and Carmagedon I also have issues with newer computers where the graphics look like an acid trip, yet they run fine on older computer, but new computer requires Explorer tweaking to get the graphics to behave.