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...
Related
I am currently taking a class on Assembly Language and Computer Architecture. We're programming in MASM for x86 processors. I have a Macbook Air, so of course I have to run Windows on a virtual machine to program in MASM for our assignments.
What I'm confused about: We're learning about, and programming for x86 architecture. When I looked up my Macbook Air's processor, it seemed to be in the x86 family. Considering that, why doesn't MASM work with Mac OS X?
Furthermore, if assembly language communicates directly w/ hardware, why does merely installing the Windows OS (or running it through a VM) on Apple Hardware suddenly allow me to program in MASM?
Thanks,
Ian
[EDIT for clarification: My understanding -- please tell me if i'm wrong -- is that Assembly Language is as "low as you can go." I.e. it's pre-operating system, and provides instructions directly to the hardware itself. Thus, I don't understand why an assembly language for x86 architecture doesn't work on ALL x86 machines, regardless of OS]
Programs are made up of more than just the raw machine code. The executable needs to have a special format that the OS can understand, so it can load and run the code. Also, the code expects a certain environment, such as libraries and system calls (along with the appropriate calling conventions).
To compile and run your assembly program you need to assemble it first, that is run it through MASM in this case. However, MASM itself is a windows executable. It is in the executable format for windows, and it uses libraries and operating system functions accordingly. As such, you can't run it directly on mac os. Afterwards, you typically also need to link your code, which has the same issues. The next problem is with the program itself. MASM (and the rest of the toolchain) is by default also targeting windows (or dos) and so the created program has the appropriate format.
You can theoretically create a program intended to run on mac os using windows and masm. This is called cross-compiling in general. If your toolchain does not support the required mac format, you will need to create everything by hand. You obviously also need to write your program such that it expects the mac environment. For example, you can't use dos interrupts or windows libraries.
Since the architecture is the same, you don't need to virtualize the cpu. You can get away with emulating just the environment. An example for this is the windows emulator, wine, or cygwin emulating unix on windows.
A very rough analogy: there are human languages that use the same alphabet, but you still need to translate. There are also languages that do not even use the same alphabet, or don't even have letters. You will need to do more work in these cases.
Background
I've been bouncing around this for a while and still haven't come up with an adequate solution, hoping someone out there can point me in the right direction.
Essentially I need to identify whether I can run 64bit VM on a target machine (working in GO but happy to consider binding c code or some assembly (though I feel a bit out of depth there)
In order to run a 64 bit VM the system need Hardware Virtualisation support available and enabled in the bios (im only concerned with intel/amd at this time)
Journey so far
From windows 8 onwards, Windows ships with Hyper-V, and there is a nice function you can call IsProcessorFeaturePresent from the kernel32.dll with an arg of 'PF_VIRT_FIRMWARE_ENABLED' which will tell you if hardware virtualisation is enabled in firmware:
IsProcessorFeaturePresent
now I dont really like the way this behaves (it says not available if hyper-v is installed) but i can cope with it by checking if hyper-v is enabled through other means so this pretty much does the job from win8 upwards.
Problem is this function always return false on win 7 for some reason - even on a system on which I know hardware virtualization is enabled.
Coming from another angle I have used this lib to determine what instruction sets are available: intel processor feature lib - this allows me to know what type of virtualization instructions are available on the processor (if any)
But I'm still missing the final piece of knowing if its enabled in the bios on win 7. I figure in principle it should be easy from here - I should be able to call something which utilizes the virtualization extensions and see if it responds as expected. But unfortunately I have no idea how to do this.
Does anyone have any suggestions as to how I might do this?
Note: Im happy to consider 3rd party libs but this would be used in commercial software so licensing would have to allow for that (e.g nothing from Microsoft)
I am afraid you won't be able to achieve what you want unless you are ready to provide a kernel driver, because checking if BIOS has enabled virtualization requires kernel privileges.
Intel Software Developer Manual describes a model-specific register (MSR) with number 3Ah called IA32_FEATURE_CONTROL. Its bits 1 and 2 control whether VMX instructions are allowed in SMX and non-SMX modes. Also there is bit zero which, when written with 1, locks the whole register's value, thus making impossible to enable/disabled features until the next processor reset. This means that, if BIOS code has disabled VMX and locked it, an OS that boots later will be unable to change that fact, only to see it.
To read this or any other MSR one should use machine instruction RDMSR, and this instruction is only available when CPL is zero, that is, within an OS context. It will throw an exception if attempted to be used from application code.
Unless you find a program interface method that wraps RDMSR around and provides it to applications, you are out of luck. Typically that implies loading and running a dedicated kernel driver. I am aware about one for Linux, but cannot say if there is anything for Windows.
As an extra note, if your code is already running inside a virtual machine, like it is for some Windows installations which enable a Hyper-V environment for regular desktop, then you won't even be able to see an actual host MSR value. It will be up to the VMM to provide you with an emulated value, as well as it will show you whatever CPUID value it wants you to see, not the one from the host.
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.
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.
I am using Turbo C 3.0 and Turbo c 2.0 for the programming. Added to this I am using Windows XP. While using Windows 98, the above said programs were really worked fine. But after installing XP, those programs were really slow-down my system. Those were really using high CPU power even when idle(idle refers to "no interaction between program and user").
Can anybody previously solved this issue, Post here.
Also, I want to know what is causing those slow-down!
Those are 16 bit DOS programs, and they probably will not run on XP. They are probably running in the NT Virtual DOS Machine. Use the task manager, or better yet, Process Explorer, to check this. You will probably not see your programs running; look for instances of ntvdm.exe instead.
I have noticed several antivirus programs (Checkpoint, Proventia Desktop) seem have a problem with ntvdm. It is as if they eat up quite a bit of cpu when an ntvdm instance is running.
Also, wasn't Turbo C finicky about its extended memory settings? If you still have your Autoexec.bat and Config.sys files from the Win98 system, you could try changing XP's settings to match. The XP equivalent to these files are autoexec.nt and config.nt; they are in the Windows\System32 directory.
I suspect Adrian's comment is the correct answer: old DOS programs did not account for multitasking and so tended to put themselves in tight loops when "idle". Back in the day, it didn't matter as nothing else was running at the same time and the operating system would interrupt the running program to handle hardware, well, interrupts.
I would highly recommend avoiding such tools on modern hardware because the programs the generate are likewise not multitasking friendly. They are also going to be optimized for ancient processors and have limited memory addressing. If you have some old hardware and want to goof around with it, then knock yourself out. But there are plenty of modern compilers that are free (either as Visual C++ Express is to get you hooked, or open source).
This can be avoided partially by setting process priority.
Start the App eg. Turbo C++ 3.0
Minimize and go to Task Manager
Find ntvdm.exe
Right Click > Set Priority > Low > Yes
Then it runs with not so annoying speeds.