10 ms·

Running DOS Apps on Windows

96 points by bluedino 6y ago

bane 6y ago
That was actually way more in depth and interesting than I thought it was going to be.
userbinator 6y ago
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.
asveikau 6y ago
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 6y ago
  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 6y ago
    > at the 98 Cent Store, which became the Dollar Tree sometime around 2000 That's inflation for ya.
  - JoshTriplett 6y ago
    I remember Kiloblaster, and many other old DOS games (and edutainment). https://archive.org/details/Kiloblaster https://archive.org/details/Kiloblaster
  - fuzzfactor 6y ago
    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.
deleted 6y ago
[deleted]
ilyagr 6y ago
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-and-its-discontents/ 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.
miles 6y ago
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 6y ago
  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.
  - jchw 6y ago
    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.)
  - jaclaz 6y ago
    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/Portable_Executable https://en.wikipedia.org/wiki/.exe https://en.wikipedia.org/wiki/.exe
  - rasz 6y ago
    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-windows-1-0-hello-c/ https://virtuallyfun.com/wordpress/2020/05/22/examining-wind... 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.
skissane 6y ago
> 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 6y ago
  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
kanobo 6y ago
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 6y ago
  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 6y ago
    Oh that makes much more sense, thanks!
MrYellowP 6y ago
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.
- haecceity 6y ago
  the term applications was just as common as programs? Apps as a short form for directories names or variable names was also pretty common?
  - laumars 6y ago
    “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.
    - badsectoracula 6y ago
      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)
      - laumars 6y ago
        “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 https://en.wikipedia.org/wiki/Application_software#Metonymy
mnl 6y ago
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 6y ago
  You can actually run the Windows 95 UI on 320x240, I’ve seen it happen when the VGA driver messes up

96 points by bluedino 6y ago

bane 6y ago

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

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.

asveikau 6y ago

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 6y ago
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 6y ago
  > at the 98 Cent Store, which became the Dollar Tree sometime around 2000 That's inflation for ya.
- JoshTriplett 6y ago
  I remember Kiloblaster, and many other old DOS games (and edutainment). https://archive.org/details/Kiloblaster https://archive.org/details/Kiloblaster
- fuzzfactor 6y ago
  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.

deleted 6y ago

[deleted]

ilyagr 6y ago

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-and-its-discontents/ 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.

miles 6y ago

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 6y ago
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.
- jchw 6y ago
  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.)
- jaclaz 6y ago
  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/Portable_Executable https://en.wikipedia.org/wiki/.exe https://en.wikipedia.org/wiki/.exe
- rasz 6y ago
  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-windows-1-0-hello-c/ https://virtuallyfun.com/wordpress/2020/05/22/examining-wind... 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.

skissane 6y ago

> 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 6y ago
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

kanobo 6y ago

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 6y ago
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 6y ago
  Oh that makes much more sense, thanks!

MrYellowP 6y ago

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.

haecceity 6y ago
the term applications was just as common as programs? Apps as a short form for directories names or variable names was also pretty common?
- laumars 6y ago
  “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.
  - badsectoracula 6y ago
    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)
    - laumars 6y ago
      “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 https://en.wikipedia.org/wiki/Application_software#Metonymy

mnl 6y ago

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 6y ago
You can actually run the Windows 95 UI on 320x240, I’ve seen it happen when the VGA driver messes up