
Running DOS Apps on Windows - bluedino
https://gekk.info/articles/dosapps.html
======
skissane
> 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.)

~~~
h2odragon
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_

------
asveikau
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.

~~~
linguae
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.

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

That's inflation for ya.

------
ilyagr
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...](https://www.filfre.net/2018/06/doing-windows-part-1-ms-
dos-and-its-discontents/)

(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.

------
userbinator
_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.

------
MrYellowP
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.

~~~
skissane
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](https://books.google.com/books?id=CbsaONN5y1IC&pg=PP75)

~~~
fuzzfactor
Common among engineers but not the general public.

~~~
skissane
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.

~~~
fuzzfactor
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.

------
miles
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](https://gekk.info) ; download directory:
[https://gekk.info/nt351/](https://gekk.info/nt351/) ).

~~~
iforgotpassword
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.

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

[http://www.os2museum.com/wp/](http://www.os2museum.com/wp/) Michal Necasek

[https://virtuallyfun.com/wordpress/](https://virtuallyfun.com/wordpress/)
neozeed

and [https://soylentnews.org](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](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...](https://virtuallyfun.com/wordpress/2020/05/22/examining-
windows-1-0-hello-c/) has first comment mentioning
[http://toastytech.com/guis/misc.html](http://toastytech.com/guis/misc.html) ,
Nathan Lineback is your nerd. His whole website is a treasure.

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

------
mnl
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](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.

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

------
kanobo
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.

~~~
anonymfus
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.

~~~
kanobo
Oh that makes much more sense, thanks!

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

