Running DOS Apps on Windows | Hacker News Reader

Running DOS Apps on Windows

gekk.info

96 pointsbluedino57 comments

> specifically, it had no "process management"; no concept of "processes" at all, in fact.

I don't know if that statement is quite true. In MS-DOS, each PSP segment is arguably a process. Processes can spawn sub-processes, albeit the parent process is mostly suspended while the child process runs. (Not entirely suspended, because a child process can call back to a parent process – most commonly by invoking software interrupts for which the parent process has installed handlers.) While only one process can be executing in the foreground at a time, multiple processes can coexist in memory. TSRs rely on this ability to have multiple processes in memory at once.

By contrast, some other operating systems, for example CP/M-80 1.x and 2.x, only supported loading one program into memory at a time, and had no support for spawning subprocesses. (Later versions of CP/M did develop some support for spawning subprocesses, although arguably it was less polished and cohesive than that provided by MS-DOS.)

Microsoft BASICs for DOS (BASICA, GW-BASIC, QBASIC, etc) provide a SHELL statement which runs a subprocess and then continues executing the BASIC program when it has finished. Microsoft BASIC for CP/M (MBASIC) has no SHELL statement, because the earlier versions of CP/M it was developed for lacked that facility.

You can actually implement the equivalent of "ps" for MS-DOS by walking the MCB chain and checking which MCBs look like valid PSPs. (One can look for signs that an MCB contains a valid PSP – for example, that it starts with the bytes 0xCD 0x20.)

I implemented time shared multitasking in a DOS TSR... Had a modem tender sending and receiving files in the background. Thanks for reminding me about the existence of Program Segment Prefixes and Memory Control Blocks. twitch

I seem to recall that common practice for playing games in the 3.1 and 95 eras was to exit windows and just run DOS.

A few games, but hardly all, worked in the virtualized full screen mode. It was rare that any decent game would run windowed.

By the time 98 rolled around it was less common to want to play a game that wasn't already targeting Win32/DirectX.

I also remember having to exit into DOS on my parent's PC running Windows 95 whenever I wanted to run MS-DOS games. I remember a PIF setting that allowed booting into DOS, directly running the program, and immediately rebooting into Windows upon closure, which bypassed the need to use DOS commands to execute the program. I was just a kid at the time, and I remember my dad buying cheap DOS games at the 98 Cent Store, which became the Dollar Tree sometime around 2000. One game I remember was a shooting game named Kiloblaster that I enjoyed a lot, and I also remember some educational titles, one teaching history and geography (I forget the name, unfortunately), and another teaching fractions. I also remember a MS-DOS version of PacMan.

If I remember correctly, Windows 95 was able to detect whether a DOS program would run well while Windows is running, or if it required booting directly into DOS. QBASIC was well-behaved and thus did not require a reboot.

This article brought back some pleasant childhood memories.

> at the 98 Cent Store, which became the Dollar Tree sometime around 2000

That's inflation for ya.

I remember Kiloblaster, and many other old DOS games (and edutainment).

https://archive.org/details/Kiloblaster

The full incentive was never there for Windows 9x (nor NT) to run the most innovative DOS games since Windows was never popular until Windows 3 and it was mainly for offices to adopt the mouse. Windows 95 is when mice reproduced exponentially along with PC's once they were 32-bit and powerful enough for the GUI. Office people could pick the least unlikely choice from a menu, and lower-cost operators having far less ability or training could be utilized in force to compensate for the less common talent that was previously needed.

DOS gamers had already been well established with their IRQ's, joysticks and custom config.sys files.

And every non-NT Windows system was always actually just a dual-boot DOS/Windows installation, transparently defaulted to boot Windows at startup. They just tweaked so they could display the Microsoft bootmenu. Serious gamers, WordPerfect, or CAD/CAM operators had three main choices to run their DOS programs[0];

1. Right there in Windows, where you open a _DOS_ command prompt window then run your program, or double click on a DOS EXE and it opened a DOS window and ran. Some programs would run one way but not the other, behavior could be dependent on custom config.sys & INI files.

2. Dropping down from the Windows shell to the underlying DOS which is in memory already. INI & config.sys files still apply and behavior can be interesting. Higher performance with better graphics could sometimes be had.

3. Reboot to clean DOS, or choose it from a multiboot menu upon startup. Different INI & config files can be stored in different directories and apply to different boot paths, including Windows.

In the DOS-based Windows series, config.sys is your native Microsoft multiboot menu.

For one institution we're still required to run an '80's DOS enterprise masterpiece on the field laptops.

I'm just a science dude but IT came to me for this one. Probably just because I'm old or something.

I do remember the way I programmed the first effective battery-powered computer for my industry, but they didn't have laptops yet, or IBM-compatible PC's, not even the earliest real IBM desktops. So I used a TRS-80 with a one-line LCD, RS-232 interface, and mini printer/plotter.

It only did one thing, but at least the UI was less error-prone than what people usually settle for any more.

Anyway to validate an epic DOS program in increasingly virtual systems works pretty good if you have the right modern 64-bit PC configuration.

So I fixed up a PC where any time you want you can just boot bare metal to DOS, W9x, WXPx86, W10x86 or W10x64 the regular ordinary way, quickly and easily[1]. Partition1 is FAT32 which looks like it's made a comeback after patent expiry so everybody's doing it again now.

The DOS system was established fundamentally, then each Windows system could be made to run the program in a DOS window which could be minimized and restored full-screen, by running the same files residing on partition1. Enabling Windows feature NTVDM is what allows 16-bit programs to run on 32-bit Windows.

It all does fine after little tweaks when needed for a particular Windows version, running in Windows compatibility modes turned out not to be essential.

Networking and printing to the site resources could all be handled in Windows, like they had done with XP.

I even got them a mouse working which they never had before.

But no DOS in 64-bit Windows for you.

Until I tried Vdos, a nice emulator which turned out to perform as needed, paying attention to its particular options.

So it's just a regular PC that can run an '80's DOS program using any of 5 different generations of Windows/DOS which appeared over the 30-year period since then.

Glad this program was intentionally less bleeding-edge than many DOS games at the time, or I might not have gotten so lucky.

[0] It would be decades before most people knew what you were talking about if you called them apps.

[1] How-to available on request.

I have vague memories from the Windows 3.1 era of writing a batch file that would replace AUTOEXEC.BAT and CONFIG.SYS with stripped-down versions (after creating backup copies). This would save memory and allow some games to run that otherwise wouldn't.

I'd run the batch file, then reboot and play the game. When I was done, I'd run another batch file to rename the backup copies onto the original files, then reboot again and Windows would start.

Good times.

Microsoft did made an earlier attempt to a games API for Windows 3.x, but only a few games bought into it, WinG.

https://en.wikipedia.org/wiki/WinG

https://www.gamasutra.com/view/feature/3199/a_whirlwind_tour...

I guess I was one of the few people that bothered to use it.

WinG allowed you to blit a bitmap from user memory directly into a window. It was a bit like the XShm extension from X11, where compatible pixmap data can be copied directly into the drawable from client memory.

Normally when you transferred image data from a bitmap in user memory (called a DIB) into a GDI drawable such as a window or bitmap with a call to SetDIBits or StretchDIBits, it's slow because there's a conversion step that has to take place: GDI bitmaps were typically held internally in a planar format (on EGA and VGA anyway), and DIB data was chunky. Also, as DIBs were identical to the BMP format, they were scanned from the bottom up instead of the top down (the first pixel in the DIB pixel buffer was the lower left rather than the upper left). This, I believe, was a holdover from OS/2, because IBM decided they wanted proper Cartesian coordinates in their bitmaps? Needless to say, most users and most video cards do not lay out bitmap image memory in that format.

With the proliferation of 256-color graphics cards, WinG became possible because 256-color modes typically had a chunky format. So you could draw your game screen in a buffer and use the WinG calls to write that buffer directly to the screen. WinG provided for additional DIB formats including top-down, so that memory could simply be copied from the DIB buffer straight from the screen on a blit call. WinG even supported accelerated blitting on cards with hardware acceleration.

The other DirectX predecessor is a bit less well known, and is called DISPDIB.DLL. DISPDIB allowed you to suspend GDI calls to the screen, put the screen in mode 0x13, and draw directly from a DIB into the display, giving you a 320x200, 256-color full-screen display -- just like DOS. The window would also capture all keyboard and mouse input while it was active. Some early pre-DirectX Windows 95 games, including Earthworm Jim and Pitfall: The Mayan Adventure, used DISPDIB.

Might have been, sometimes it is ironic how OS/2 gets so much praise, when around this time the APIs were quite similar (given its historical relation). Most likely from devs that never actually coded for OS/2. :)

Thanks for the DISPDIB.DLL overview, I wasn't aware of it.

> sometimes it is ironic how OS/2 gets so much praise, when around this time the APIs were quite similar

A lot of the praise I've seen was specifically that OS/2 ran Windows programs better than Windows did.

It did, hence like WINE, people just kept writing Windows software instead of bothering with CSet++, SOM (better than COM actually) or the other development stacks for OS/2.

Borland had an OWL like framework for OS/2.

As in "I was a developer back then and used this API" or as in "I was a user and installed software that used it"?

I remember WinG being necessary for the Warcraft 2 map editor by the way.

I started coding in the mid-80's on Timex 2068.

Its keyboard looks super interesting. Were these keys used as shortcuts to enter complete keywords at once?

https://en.wikipedia.org/wiki/Timex_Sinclair_2068#/media/Fil...

Yes, that was common in the Spectrum and compatible computers.

You see that there are multiple words per key.

The exact one depends on the current input mode, so we would keep changing modes all the time.

That is also a reason why game developers with enough money would eventually get a 16 bit machine with UNIX, VMS or whatever, so that they would get a better development experience and then upload them via the extension port.

Here is an overview of it, https://retrocomputing.stackexchange.com/questions/3314/how-...

Yes, it's a version of ZX Spectrum. Each keyword had its own code in the character set.

Does this mean that these keys inserted actual instructions instead of a string of characters into the source code?

No, it was a mix of opcodes and text, from "The Complete 48K Disassembly"

"1B17: THE 'MAIN PARSER' OF THE BASIC INTERPRETER"

https://speccy.xyz/rom/asm/1b17

"1A48: THE SYNTAX TABLES"

https://speccy.xyz/rom/asm/1a48

You can read about "The Complete 48K Disassembly" on a recent HN post, https://news.ycombinator.com/item?id=23757449

Now, the Timex 2068 was a bit different, because its had more capabilities than the 48K, including a proper sound chip, the 48K compatibility was achieved via an extension Eprom.

Like these ones, https://k1.spdns.de/Vintage/Sinclair/Software/Timex%202068%2...

Not in my experience. Off the to of my head some games that worked fine on 95:

Duke Nukem 3D (build games in general)

Stunts

Death rally

Settlers 2

Transport Tycoon

Warcraft

The biggest problem was accidentally hitting the Windows key which minimized the game and that crashed most of them. That is one thing that improved on 98. You could restore most of these games there with a 90% success rate.

IIRC one of the biggest factors in whether a game would work under Windows was whether it tried to change the interrupt rate of the timer from the 18.2Hz default.

This seems a good occasion to plug Raymond Chen's blog where he also shares some war stories about his time working on Windows 95's backwards compatibility, especially for games

https://devblogs.microsoft.com/oldnewthing/

There is a much longer (and more detailed) description of the history of the transition from DOS to Windows: https://www.filfre.net/2018/06/doing-windows-part-1-ms-dos-a...

(That's part 1 out of 9)

It has a slightly different focus: it doesn't mention PIF files, but spends time on the business relationship between IBM and MS. It also discusses OS/2.

Microsoft leaned in hard to videogame support, but never did improve DOS emulation to a point where you could practically play much of anything in a window. In fact, I seem to recall NT did a little better at this at times. You'd think they could have managed it under 9x, and that they would have considered it worthwhile, but perhaps it's a harder trick than I think.

That's actually something handled by the video driver, or more precisely, the VXD responsible for virtualising the GPU; and although MS did write a few of their own, that is typically supplied by the GPU vendor.

The whole DOS-based Windows product line, from Windows/386 onwards, are better thought of as thin bare-metal hypervisors, like Xen, rather than a traditional OS. The main difference is that instead of contemporary virtualisation that denies guests access to the host hardware by default and requires specific "passthrough" configuration otherwise, Windows allows guests to access the hardware by default, and traps and virtualises only the bare minimum necessary for itself.

I recently experimented with writing a minimal VESA video driver ("framebuffer") for Windows 9x, and it was a very interesting experience; there's a usermode component (running in 16-bit protected mode, basically a DLL) which is called by GDI for the various drawing calls, and you can either implement acceleration if you can, or pass it on to the DIBENG ("DIB engine") to have it do all the drawing in software. This component is actually surprisingly easy to write, since all you need to do is set the video mode and pass DIBENG the framebuffer to draw into; I was able to get Windows to boot with the driver and graphical Win16/32 apps using it with around a weekend of work.

Trying my driver on various physical and emulated hardware revealed that with some GPUs, although Windows applications worked perfectly, opening just a DOS prompt window would corrupt the screen, yet full-screen DOS worked fine. I discovered that although Windows' built-in VXDs virtualised a standard VGA, if the video BIOS or DOS apps accessed the hardware beyond the standard VGA registers, it would not be trapped by the VXD and thus the state would "bleed out of the VM". A lot of super-VGA hardware is "hidden" inside the same interface as a regular VGA, which explains how my user-mode-only driver didn't encounter this issue; but others have more registers and I/O ports which Windows didn't know about.

I have yet to find the time to write the VXD component, but I think it's definitely possible to get graphical, even high-resolution, DOS graphics to work well in a window.

Sorry for being off-topic. There was a time when we called programs programs and I really miss it. I believe it was Apple, who caused this change with thier iPad.

That's quite the major change of language. They've managed to push computers so deep into the mainstream, it changed not just a word, but public perception about computers.

the term applications was just as common as programs? Apps as a short form for directories names or variable names was also pretty common?

“Applications” were a subset of “Programs” and generally covered productivity type software like image editors, word processors, etc. Then you had “games”, “system software” and I think possibly “tools” or “utilities” too (the latter which were single purpose software like a clock or calculator).

It’s more of a recent trend to call all software “applications” (or “apps”) irrespective of their utility. This is something Apple popularised on the iPhone.

I always remembered the other way around: applications being composed by one or more programs (e.g. a lot of software had more than one executables, especially on DOS). Also i highly doubt there was any specific target for "applications", otherwise, e.g., Windows SDK wouldn't use the term to describe, well, all applications (for example the Win32 Programmer's Reference that came with many compilers in the 90s starts with "The Microsoft Win32 Programmer's Reference contains the application programming interface (API) set needed to write applications for Windows® 95 and Windows NT." - and the entire reference uses the term application instead of program)

“Program” can refer to executables if you’re talking in the context of old programming languages such as Pascal and COBOL as they’d literally have a “Program” statement. But I don’t recall anyone calling individual executables anything other than exes on Windows.

As for the API naming conventions, Wikipedia describes the use of “Application” pretty well: https://en.wikipedia.org/wiki/Application_software#Metonymy

> “Program” can refer to executables if you’re talking in the context of old programming languages such as Pascal and COBOL as they’d literally have a “Program” statement.

When I was younger, I wrote my own programs in GW-BASIC (and later QBASIC). I definitely remember calling them "programs" at the time. I taught myself programming from books in the school library (neither of my parents knew how to do it), and they definitely used the word "program" for what I was learning to write.

But while Pascal has a "PROGRAM" statement, most BASIC dialects (including Microsoft's) don't. COBOL doesn't have a "PROGRAM" statement either, although it does have an "EXIT PROGRAM" statement.

So I don't think whether something is called a "program" or not has anything to do with what language it is written in.

> But I don’t recall anyone calling individual executables anything other than exes on Windows.

Here's a software manual from 1993 – https://books.google.com/books?id=jAqUEgrLBa8C&pg=PA14 – you can see on that page the application is divided into a number of executables – "the core TS.EXE program" and a number of "General support utilities", one of which ("PRINTPCX.EXE") is described as "A program to print graphs". Although the other executables are not explicitly called "programs", it seems clear to me that "program" and "executable" are synonymous in the usage of the manual's authors.

That is admittedly an application for MS-DOS, not Windows. But I don't believe there were any great differences in terminology in this area between MS-DOS and Windows.

> But while Pascal has a "PROGRAM" statement, most BASIC dialects (including Microsoft's) don't. COBOL doesn't have a "PROGRAM" statement either, although it does have an "EXIT PROGRAM" statement.

It was PROGRAM-ID in COBOL: https://en.wikipedia.org/wiki/COBOL#Hello,_world

> Here's a software manual from 1993 – https://books.google.com/books?id=jAqUEgrLBa8C&pg=PA14 – you can see on that page the application is divided into a number of executables – "the core TS.EXE program" and a number of "General support utilities", one of which ("PRINTPCX.EXE") is described as "A program to print graphs". Although the other executables are not explicitly called "programs", it seems clear to me that "program" and "executable" are synonymous in the usage of the manual's authors.

That's a utility and I'd already said "utilities" were a classification of programs. The GPs point wasn't about utilities though.

> That is admittedly an application for MS-DOS, not Windows. But I don't believe there were any great differences in terminology in this area between MS-DOS and Windows.

Anecdotally I remember all executables being talked about as "programs" in the DOS era -- which might also be a throwback to when all software was written as a complete program and all executables were commands (eg pre-dynamically linked libraries so shared libraries would either have to be their own command or compiled into the each executable).

But in fairness, terms like "program", "utility", "application" were, to some extent, rather fuzzy descriptions back then anyway. At least in the context of what we're describing anyway.

I wasn't referring to API, but to the fact that the Windows SDK uses the term "applications", e.g. "needed to write applications for Windows® 95 and Windows NT". They use the term "application" everywhere in the documentation, not just in the context of APIs.

Indeed but what you’re describing there is just more examples of metonymies like I’d already discussed in my previous post.

Microsoft obviously need a descriptive term (“software” and “program” does not work as a drop in replacement in all instances) and “application” is well suited. But that doesn’t mean that APIs (“application programming interface”) can’t be used by systems software, for example. It’s just “application” is a broad enough term to be the clearest term in most instances.

I should add, we are talking about the Win 3.x and possible very early 9x era. As time went on “application” did lose its specificity. An example of this is how progman.exe grouped software vs how the Start menu group software.

You originally wrote that applications were a subset of programs and this changed because of iPhone, which as i wrote is wrong since the term "application" was used to refer to programs way before iPhone even existed - using Windows 3.1 as an example of something from 1990 that used that term. With the quote i was referring to the use of the term "application" not the "API". The SDK help file uses the term "application" everywhere to describe software for Windows without making any distinction like the one you wrote in that message above.

Now, the term "application" might have had a more specific meaning before Windows existed (even Windows 1 seem to use the term application) but this is going back decades before iPhone was introduced.

> You originally wrote that applications were a subset of programs and this changed because of iPhone

You’re right I did. Agh truth be told I don’t know when the shift happened (it all feels like ancient history these days) but I do remember people making a distinction between applications, utilities, games and systems software, which they don’t now. I even remember teaching material making that distinction (old enough to have been in Uni when GUI applications were just shifting away from novelty).

Also you keep saying that I’m missing your point about APIs but I’m not. My point is that Windows documentation isn’t a legal document and thus using the term “application” for stuff that could mean any software is perfectly valid. Even now many make a distinction between systems software and applications yet the contents in most of the reference material applies just as much to systems software as it does application software. This is what is meant by metonymic purposes of the term.

I mentioned the Windows documentation not as an authoritative source for what "application" means, but more as an informal source for how people even in the 80s used "application" to mean any sort of software.

I mentioned Windows because it is the most likely to be known, but it also applies to other systems. For example the GEM installation manual[0] uses the term "application" to refer to non-system software and even seems to make the distinction between applications and programs where applications is the whole and program is a part of the application (notice in section 4 where it mentions that to install an application you use its installation program).

[0] http://www.bitsavers.org/pdf/digitalResearch/gem/GEM3/5125-2...

Which is another example of metonymy. Did you read the link? I've referenced this several times now and it explains every example you've given.

In any case, I've also said it was a bit of a fuzzy term and it feels like we're ostensibly arguing similar points.

I did read the link, but i'm not sure how to interpret it, it just mentions that the word application can have several uses. Which, ok it does, but it doesn't sound like it was contradicting anything i wrote about "applications" not being just about specific types of software like productivity or even a subset of "programs" (the GEM manual even shows how it was used in the opposite where an application can be made up of multiple programs).

The term “application” was in common use in the 1980s and 1990s, and shortening it to “app” was not uncommon either.

You might recall the term “killer app”. Here’s an article from 1989 using it:

https://books.google.com/books?id=CbsaONN5y1IC&pg=PP75

Common among engineers but not the general public.

The term was common in computer magazines in the 1980s and 1990s.

A lot of people who read those were not IT professionals, they were popular with enthusiasts.

Many of them were sold in mainstream outlets targeting the general public.

As we have seen, they didn't hit their target often enough for it to make much difference back then.

Most offices didn't have an enthusiast yet, and certainly not IT professionals.

I even took a look at a personal computer publication or two at the time, and I am neither.

Publications needed to cast a wider net, but it took a while to reel ordinary users in.

_App_ was literally understood by enthusiasts for years without ever becoming part of the everyday spoken vocabulary even among themselves. It still had no meaning to users at the time, but they already knew what a program was, as well as a computer programmer. However, most users purchasing their first Apple or PC had never yet heard of a software engineer.

Kind of helps to explain why it took until the 21st century for the nomenclature to become mainstream.

"Applications" was one of the default program groups in Windows 3.1:

https://i.redd.it/e8zxsf8ax1v11.png

At least GEM for MS-DOS and Atari called them "applications" or "application programs" back in 1985 and they ever had an .app extension.

EDIT: also Windows itself uses the term to refer to any program. I do not have the older stuff around, but at least since Windows 3.1, the reference help file that came with some compilers uses the term application everywhere.

Love the collection of tiny, standalone EXEs from Windows NT 3.51 that still run great under Windows 10 (described at the bottom of https://gekk.info ; download directory: https://gekk.info/nt351/ ).

I've commented this a few times in the past unsuccessfully so here I try again:

Ages ago I stumbled upon a website that described a way to run Windows 1.0 EXEs on Windows 10 (32bit obviously). Iirc it involved patching the PE header with a hex editor to say it's for Windows 2.0 or maybe 3.0 and then using an old version of Borland resource editor to recompile the embedded resources, since the that format changed some time between 1.0 and 3.0 and that old editor happens to support both variants.

The page had screenshots of some old programs like reversi, calc etc running on 10. Some looked a little glitchy but it basically worked.

Unfortunately the site either went down or my googlefu is weakening.

As an alternative, WineVDM should be able to run most 16-bit Windows software on Windows 10 64-bit. (I think this may not be what you are talking about, but at least on 64-bit Windows, there is no ordinary way to execute 16-bit code at all. Somebody probably did get it working in 32-bit Windows 10, though.)

Only as a side note Windows 1/2/3 exe would be a NE (16 bit), not a PE.

https://en.wikipedia.org/wiki/Portable_Executable

https://en.wikipedia.org/wiki/.exe

There are only few nerds geeky enough to attempt such feats for pleasure.

http://www.os2museum.com/wp/ Michal Necasek

https://virtuallyfun.com/wordpress/ neozeed

and https://soylentnews.org NCommander come to mind

Maybe this is what you were thinking of https://soylentnews.org/article.pl?sid=20/05/10/1753203

Edit: and indeed NCommander guest post on neozeed blog https://virtuallyfun.com/wordpress/2020/05/22/examining-wind... has first comment mentioning http://toastytech.com/guis/misc.html , Nathan Lineback is your nerd. His whole website is a treasure.

That last link is it! Thanks a ton, I'm gonna set up a win 10 VM tomorrow :-)

I would have mentioned at least DESQview because it's rather nice and then OS/2 for obvious reasons.

About the memory model, for instance Wikipedia does a decent job (see https://en.m.wikipedia.org/wiki/DOS_memory_management). I think it's definitely necessary to understand the gist of what you're writing about and not simply give up because as you can't find it easily now with the whole Internet at your fingertips, then surely few did back then or it's not really important. That strikes me as a strange way to approach these topics tbh.

I don't understand the point about Windows 95 and VGA. The minimum requirements for Windows 95 included VGA, but no one inflicted such pain on themselves. By the time Windows 95 appeared, pretty much everybody got something like an S3 Trio and went with SVGA/XGA. I mean, try to use Word 95/97 with a 640x480 14" screen, it's cramped and you get less PPI than an early 90s $999 Macintosh Classic.

You can actually run the Windows 95 UI on 320x240, I’ve seen it happen when the VGA driver messes up

I haven't touched a Windows machine in the past 15 years and is shocked to read in this article that running DOS apps is no longer a feature of Windows. From my childhood they were as intertwined as the peanut butter and jelly on a de-crusted wonder bread.

You misunderstood the article. It is not a feature of 64 bit Windows, but it still works on 32 bit x86 version. Exactly how it was 15 years ago when Windows XP x64 debuted.

Oh that makes much more sense, thanks!

That was actually way more in depth and interesting than I thought it was going to be.

Reply on news.ycombinator.com