So I was writing assembly code in TASM. But now I want to migrate it to MASM and have it run on 32-bit Windows. Can I still keep the DOS interrupts or is there some other way to do it?
I want to ideally run this on Windows 10.
16 bit code from Windows 95 will still run on 32 bit windows at least until windows 7 (I don't have the software to try it on Windows 10).
However for 32 and 64 bit code, you have to start using the win32 api which use the less exciting "call" instruction instead of interrupts.
Simple answer: no, you can't. Under Win32/Win64, calling a DOS interrupt from a Windows program will crash your program with an "Invalid operation" message. Figure out what are you trying to do with DOS interrupts (console output? writing to files?), find corresponding Win32 API functions, and call them.
UPDATE: depends on what are you after. DOS interrupts are only available to DOS executables; Windows executables have to use Windows API. It's entirely possible to make Windows executables in assembly, MASM included, but you'd have to learn new techniques. Building DOS executables is supported in older versions of MASM, but that skillset is rather pointless in today's computing environment. For one thing, the DOS subsystem is slowly but surely going away from Windows - 64-bit versions of Windows don't have it anymore.
Related
I have an old MSDOS program that I might want to run on a modern(er) machine.
Is it possible to install some MSDOS on these machines and run the .exe program?
A cmd window does not work on my machine now: it's 64 bit.
This is the case, for the interested:
I am building a Win10 program to do some tricky calculation. But it's not ready yet to use. My customer comes with a question that I maybe could answer with an old program I have, that ran in DOS, back in the 80's and 90's.
I would try using the compatibility mode windows 7 offers (unlikely that will work).
Your best bet is an emulator like DOSBox.
Any x64 based Windows will not allow you to run old 16 bit DOS code, it wouldn't be able to run 16 bit Windows code either.
I tried the same on my Windows 10 x64 only seconds ago and received this (German) denial message:
In my scenario the exe is even able to run in 386 mode with a dos extender but this does not help either because the base is 16 bit code.
You will need some kind of emulation or virtual machine. I gave DOSBOX 0.74 a quick try and it was able to run my old 16 bit DOS program which even makes use of an dos extender. There is no need to install dosbox, you can simply unpack the exe using 7-zip and provide it alongside your own program and use it as a launcher.
Just create a dosbox.conf file and put it in the same directory dosbox.exe is in. This content will automatically simulate a C-drive for DOS and launch your program as soon as you start dosbox.exe from Windows.
[autoexec]
mount C C:\yourprog.dir
C:
yourprog.exe
Just an addition to emulation/VM answers: for me, big part of DOS programs worked when booted in Windows XP x32 safe mode with console support (sic!). On Vista and higher I was not able to run any DOS executable. So mostly you'll need DOSBox-like program, but XP is still a good oportunity, though.
What is The Interrupt for User input and output in Console Window?
Hello I'm trying to learn Assembly Language, I know that in MS-DOS Operating System, the .COM programs were Supported, and were loaded into memory at 100h, isn't it? And the first 1k bytes were the IVT or Interrupt vector table, it is a list of interrupts, isn't it?? So in MS-DOS if we want to Ask an input from the user we first Move 01 to AH register like MOV ah, 01 and call the Interrupt INT 21h, I don't know if this is gonna work on DOS or not, I never tried the DOS virtual machine or something Similar Applications, i don't want the DOS program I just want a Console Window for Asking a user for Input...
I have just stepped into Assembly programming and found no Complete tutorials on Windows, Or not just One which Shows the use of Interrupts, Everywhere MASM is used with windows.inc libs, and the C standard libs, i don't wanna waste my time learning them, As after learning Assembly programming i Want to learn Writing Booting Programs, Which doesn't Sticks to one Operating system, And the reason i want to use Interrupts is just for learning purpose, Meaning this is just to learn Assembly language, Currently i know very less instructions like MOV ADD SUB INC INT & DEC And know nothing or very less about Registers, So with these limited Capability i cannot write Boot Programs, and for this reason im trying to learn or Practice assembly on Windows but with interrupts, and thus does not want to use those Predefined libraries in my Applications, and want to Only use Interrupts from IVTs and shift to BIOS interrupts, for Boot Programs.
I heard on a forum that Microsoft hides its Windows IVTs from the public as they want their APIs to become popular, Is this true? Thus this means there is no way i can use interrupts to handle I/O in Windows?? because there is no such Documentary on it, if No Kindly Post it with An Example for NASM, and Please Refer to any Online/Offline guide, and my last request please Tell me how can i Convert MASM written souce code for NASM, i mean what is the difference between them, In Short, i have Two requests and One Question as follows:
1. Q1: What is the Interrupt for Console I/O in Windows?
2. R1: Please share any Good tutorials on Assembly for windows Especially on using Interrupts just like TutorialsPoint but Its for Linux and I want for Windows.
And the Last One...
3. R2: How is MASM's input file source code different from NASM one?? I mean How much and where can i find difference writing source code for them, As many tutorials said that Many MASM programs wont run in NASM...
Thanks in Advance!!
And the first 1k bytes were the IVT or Interrupt vector table ...
Modern CPUs have two (in the case of 64-bit CPUs even three) operating modes: The "real mode" and the "protected mode".
When the CPU starts up and in MS-DOS the CPU runs in "real mode". When Windows is running the CPU runs in "protected mode". In this mode the interrupt system works completely different than in "real mode".
It is not possible to access the IVT directly and it is not possible to access memory belonging to a task from another task.
What is the Interrupt for Console I/O in Windows?
Windows NT, 32-bit, used interrupt 1Eh. However other Windows versions (Windows 9x for example) used another method of entering the operating system.
As far as I know 64-bit versions of Windows also do not use interrupts.
No Windows program (with exception of the old 16-bit Windows programs) is using interrupts directly.
hides its Windows IVTs from the public as they want their APIs to become popular, Is this true?
They hide the interrupt numbers because they are only available in some Windows versions.
The only possibility to write a program that works on all Windows versions currently in use is to use the Windows APIs.
i don't wanna waste my time learning them
In this case don't waste your time writing Assembler programs for Windows! Doing so only makes sense if you are interested in compiler development.
Use some virtual machine tool (Bochs, VMware, ...) and start writing "booting programs" NOW or use an MS-DOS emulator and write Assembler programs for MS-DOS.
The only use of Assembler programs for Windows is that the 32-bit assembler is a bit easier to learn than the 16-bit assembler (which is required for MS-DOS and "booting programs") so writing Assembler programs for Windows may be good for learning purposes...
I have a program built with VB6 and using some 32-bit DLL's. Will this program run on a 64-bit machine? This page suggests that it should run fine on the Windows on Windows layer, but what about the DLL's?
Yes, both the VB 6 program and the DLLs will work just fine on a 64-bit version of Windows.
Since both are 32-bit, they will run under the Windows-on-Windows 64 (WoW64) subsystem, which effectively emulates a 32-bit operating system on the 64-bit versions of Windows.
I've run many such programs myself with nary a hitch.
Beyond Explorer extensions and kernel mode drivers (neither of which you've written in VB 6), any compatibility problems that you might experience are almost certainly the result of bugs in your own code, which are easily fixed upon detection. Ask more questions about that when you find them.
Are the DLLs built with VB6 as well? Or are they native?
If you are dealing with 100% VB6, then in my experience, yes they tend to run with minimal problems (I maintained a number of plug-ins for another program that were mostly implemented as VB6 COM components, around the time that Windows 7 came out).
It will all of course depend on what libraries your code is using, whether or not you are accessing locations such as %PROGRAMFILES% etc, calling code in native libraries. These things can cause small problems but it is possible to work around them.
Microsoft are still supporting the VB6 runtime on 64-bit windows
Yes, it works, and if you have any problems they will help you.
I decided to start learning assembly a while ago, and so I started with 16-bit assembly, using FASM.
However, I recently got a really new computer running Windows 7 64-bit, and now none of the compiled .COM files that the program assembles work any more. They give an error message, saying that the .COM is not compatible with 64-bit however.
32-bit assemblies still work, however I'd rather start with 16 and work my way up...
Is it possible to run a 16-bit program on windows 7? Or is there a specific way to compile them? Or should I give up and skip to 32-bit instead?
The reason you can't use 16-bit assembly is because the 16-bit subsystem has been removed from all 64-bit versions of Windows.
The only way to remedy this is to install something like DOSBox, or a virtual machine package such as VirtualBox and then install FreeDOS into that. That way, you get true DOS anyway. (NTVDM is not true DOS.)
Personally, would I encourage writing 16-bit assembly for DOS? No. I'd use 32- or even 64-bit assembly, the reason being there are a different set of function calls for different operating systems (called the ABI). So, the ABI for 64-bit Linux applications is different to 32-bit ones. I am not sure if that's the case with Windows. However, I guarantee that the meaning of interrupts is probably different.
Also, you've got all sorts of things to consider with 16-bit assembly, like the memory model in use. I might be wrong, but I believe DOS gives you 64K memory to play with "and that's it". Everything, your entire heap and stack along with code must fit into this space, as I understand it, which makes you wonder how anything ever worked, really.
My advice would be to just write 32-bit code. While it might initially seem like it would make sense to learn how to write 16-bit code, then "graduate" to 32-bit code, I'd say in reality rather the opposite is true: writing 32-bit code is actually easier because quite a few arbitrary architectural constraints (e.g., on what you can use as a base register) are basically gone in 32-bit code.
For that matter, I'd consider it open to substantial question whether there's ever a real reason to write 16-bit x86 code at all. For most practical purposes, it's a dead platform -- for desktop machines it's seriously obsolete, and for embedded machines, you're more likely to see things like ARMs or Microchip PICs. Unless you have a specific target in mind and know for sure that it's going to be a 16-bit x86, I'd probably forget that it existed, just like most of the rest of the world has.
32-bit Windows 7 and older include / enable NTVDM by default. On 32-bit Win8+, you can enable it in Windows Features.
On 64-bit Windows (or any other 64-bit OS), you need an emulator or full virtualization.
A kernel in long mode can't use vm86 mode to provide a virtual 8086 real-mode environment. This is a limitation of the AMD64 / x86-64 architecture.
With a 64-bit kernel running, the only way for your CPU to natively run in 16-bit mode is 16-bit protected mode (yes this exists; no, nobody uses it, and AFAIK mainstream OSes don't provide a way to use it). Or for the kernel to switch the CPU out of long mode back to legacy mode, but 64-bit kernels don't do that.
But actually, with hardware virtualization (VirtualBox, Hyper-V or whatever using Intel VT-x or AMD SVM), a 64-bit kernel can be the hypervisor for an entire virtual machine, whether that VM is running in 16-bit real mode or running a 32-bit OS (like Windows 98 or 2000) which can in turn use vm86 mode to run 16-bit real-mode executables.
Especially on a 64-bit kernel, it's usually easier to just emulate a 16-bit PC entirely (like DOSBOX does), instead of using HW virtualization to running normal instructions natively but trap direct hardware access (in / out, loads/stores to VGA memory, etc.) and int instructions that make DOS system calls / BIOS calls / whatever.
how can i make a device input and output control program on windows 7??
Previously there was an option called debug where we wrote our programs. but as far as i know this feature is no more in windows 7. how can i do assembly on windows7??
You can use an assembler such as NASM, YASM, etc., or MASM which is free with Visual Studio Express (for non-commercial use).
I was thinking of Grdb, but it is only available for 32-bit, as a debug alternative.
I'm not sure what you are asking for with your first question, so I cannot answer it. I hope the above answers your second question.
It sounds more like you want to write a device driver? If so, download the Windows Driver Kit from Microsoft.
You can use this to write your driver in assmbly code if you wish. Be aware that this is NOT a trivial task.
What may be a better idea for you is to either install the WinXP virtual machine feature that comes with Windows7, or install WinXP/98/95 on an old machine, and do your coding on that. Under those OSes the driver model was simpler, and you could easily access the interrupts directly and/or easily elevate yourself into Ring 0 if you needed to.
Debug is available on Windows 7 32 bit, but not 64 bit.