From DOS to Windows 10 assembly

Question

This code will print "Hello, world!" in DOS as a .COM executable:

org 100h
mov dx,msg
mov ah,9
int 21h
mov ah,4Ch
int 21h
msg db 'Hello, world!',0Dh,0Ah,'$'

However it will not run on Windows 10 64-bit and all trivial examples of a Helloworld program for x86 and x64 I've seen involve linking to some library.

So my question is do these later versions of Windows still follow an ISR IO model or more simply how do I convert this example to a "higher bitness"?

If you're after basic assembly, you'd probably have better luck running on a Dosbox or another emulator. — Leeor, Apr 30 '16 at 19:52
No. DOS died nearly two decades ago, and you can't run that type of code on modern versions of Windows. So the answer to *how do I convert this program* is *you don't*. Move into this century. — Ken White, Apr 30 '16 at 19:59
Interrupt 21h is a DOS function. Anyone reading "Mastering Turbo Assembler" (Tom Swan) will also want to use BIOS calls such as INT 10h. See: https://en.wikipedia.org/wiki/INT_10H — Alan Campbell, Dec 28 '17 at 00:13

score 1 · Accepted Answer · answered Apr 30 '16 at 19:54

1

You can't do that not only in Windows 10 but in fact in any Windows that runs applications in protected mode (Windows NT 3 and newer) - the application doesn't have direct access to interrupts and HW. Additionally, the executable format itself is OS-dependent. While there is some backwards compatibility (e.g. Win10 should be able to run Win7 apps) but it definetely doesn't stretch back to the DOS days (.COM format is by definition restricted to Real mode, that died before Win NT 3).

There is no direct way to convert this code to be Win10-compatible. You'll need to use OS-provided APIs to access the interrupts/HW.

answered Apr 30 '16 at 19:54

SomeWittyUsername

18,025
3
42
85

I would imagine that somewhere this still shows up even if it's coated over with an API. – Chicken Wing Apr 30 '16 at 20:09
@ChickenWing Sure it is, but it's not accessible to applications. OS Kernel has this logic implemented by the relevant drivers (in your case it would probably be the bus driver and the display driver). User applications have the relevant higher-level APIs that are exported by the Kernel. – SomeWittyUsername Apr 30 '16 at 20:50
That's ultimately what I'm trying to understand. I guess I need to investigate how all that interacts through assembly but it's hard enough when I barely know anything in the first place. – Chicken Wing Apr 30 '16 at 21:01
It is *possible* to bypass the API, but it isn't *sensible* to do so. For one thing, it means your application will only run on the specific version of Windows you wrote it for. So for example if you wrote it for the original release of Windows 10, it would stop working when the computer was upgraded to Windows 10 version 1511. – Harry Johnston Apr 30 '16 at 22:15
7

This answer is somewhat incorrect. 64-bit versions of Windows (not just Win10) do not support NTVDM which is a dos Virtual subsystem that provides limited support for 16-bit and 32-bit DOS programs (exe and com). However all versions of 32-bit Windows at this time do support NTvDM. On Windows 10 32-bit(I know the OP isn't using it, I'm just giving info) you turn the feature on via `Programs and Features / Turn Windows Features on or off / Legacy Components / Enable NTVDM`. On 64-bit Windows you could run a 32-bit OS (or DOS) using Virtual Machine software, or use an emulator like DosBOX. – Michael Petch Apr 30 '16 at 22:56
@HarryJohnston I'll keep that in mind. – Chicken Wing Apr 30 '16 at 23:25
@MichaelPetch It's not related to correctness. Virtual machines are a different story. I can run Windows VM on Linux machine but that wouldn't mean that Linux supports Windows API. – SomeWittyUsername May 01 '16 at 11:42
3

The last part of my comment deals with 3rd party solutions. NTVDM has been a Windows Subsystem for 32-bit Windows since early days of WinNT and exists to allow Windows to utilize 16/32-bit DOS programs. NTVDM provides a set of APIs (That happen to look and act like DOS/BIOS Interrupts) that are processed and if need be - passed to Windows Kernel. On a system with NTVDM, Windows understands 16/32-bit DOS EXE & COM programs (32-Bit Windows comes with 16-bit dos debugger). The hardware reason that NTVDM doesn't run on 64-bit Windows is because Intel's 64-bit long mode doesn't support vm8086. – Michael Petch May 01 '16 at 12:01
@MichaelPetch Whether the solution is 3rd-party or not is secondary. The point is that there is a mediator, either native or not (VM), that translates the required functionality. And on 64-bit machines the mediator can't operate due to HW restrictions, like you noted. – SomeWittyUsername May 01 '16 at 16:49
1

But in protected mode with Win32 there is a mediator (the kernel) that does device contention, tasking, hardware access. Whether there is one layer or multiple layers, 32-bit windows inherently has support for real DOS EXE and COM programs, setting up a virtual 8086 task and intercepting interrupt requests and acts like DOS. Whether there is 2,3,4 levels of layering doesn't matter. 32-bit Windows supports 16-bit and 32-bit DOS EXE and COM program (32-bit via a dos extender). – Michael Petch May 01 '16 at 17:11
1

I don't see you mentioning the same argument for Win32 32-bit code that requires the WOW64 compatibility layer on 64-bit Windows. NTVDM is effectively a WOW32 layer. WOW64 just doesn't need VM8086 task to operate. – Michael Petch May 01 '16 at 17:11
@MichaelPetch It's a matter of terminology, I suppose. You consider anything as supported if it can be emulated with VM. The problem with this approach is that almost everything can be emulated (Windows over Linux is a good example), it's SW after all (unless there are HW restrictions, such as on 64-bit machines). – SomeWittyUsername May 01 '16 at 17:32
1

Your use of `Real mode` is also a problem. VM8086 is not real mode (although supports code that runs in real mode since it supports 20 bit segmented memory in a protected mode environment). A 16-bit COM (or EXE) program can run in a properly programmed VM8086 task which is what NTVDM is (at least on the intel architecture - Dec Alpha WinNT used an emulator). – Michael Petch May 01 '16 at 17:45
1

Lines are going to be blurred when Ubuntu will be supported on Windows through yet another subsystem - Windows Subsystem for Linux (WSL) – Michael Petch May 01 '16 at 17:54
@MichaelPetch Yes, VM8086 isn't real mode but emulated real mode - not sure I follow how is that related to the discussion, though. – SomeWittyUsername May 01 '16 at 17:55
3

Because your answer states **.COM format is by definition restricted to Real mode,**. That is NOT correct. VM8086 supports running 16-bit code on the CPU level without going into real mode. Realmode != VM86 . VM8086 is PROTECTED MODE that supports the 20-bit segmentation model and can run those instructions natively. The DOS/BIOS interrupts in VM8086 pass through to the Windows Kernel where they are emulated or passed to real hardware. But that's not a whole lot different than the interrupt mechanism that makes kernel calls in a win32 application (hidden under the veneer of the Win32 API) – Michael Petch May 01 '16 at 17:58
@MichaelPetch Ok, it will be more precise to say that .COM format is by definition restricted to Real mode, either native or emulated. But it's again a matter of terminology - you choose to include the virtual modes as supported, while I didn't in this answer. – SomeWittyUsername May 01 '16 at 19:03
1

The distinction obviously matters because in practice you can run a `.com` on 32-bit Windows XP, for example. Windows fires up an emulated DOS environment for you so it Just Works. (Apparently [included by default in 32-bit Windows up to Win7, then as an optional feature](https://stackoverflow.com/questions/29597600/assembly-programming-for-windows-7#comment62905377_29597600) – Peter Cordes May 01 '18 at 23:11

From DOS to Windows 10 assembly

1 Answers1

Linked

Related