-3

How to call interrupt in assembly language using NASM on 32 bit architecture. I try many time but result not desired.

On Linux "core dump error" and on Windows nothing happens on CMD. I read some deep that in 32 bit user application are run under ring 3 level and kernel and driver are run in ring 1. How can I do that in user level?

I follow someone on YouTube he work very well on Visual Studio with C++ or C (with inline and external assembly file ) but when I call any interrupt in external file or inline, Visual Studio says memory location violation error.

Intel 32 bit architecture (Ring level).

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Umar Draz
  • 21
  • 2
  • 3
    You can’t use BIOS interrupts when an OS is running. (Unless you are using a BIOS emulator.) Are you sure you know what you want to do? – prl May 08 '19 at 04:20
  • Duplicate in spirit: https://stackoverflow.com/questions/35821912/how-can-i-use-dos-interrupts-in-32-bit-windows-assembly/35822014#35822014 – Seva Alekseyev May 09 '19 at 19:32
  • Another duplicate in spirit: https://stackoverflow.com/questions/22512471/why-does-using-int-21h-on-assembly-x86-masm-cause-my-program-to-crash/22512751#22512751 – Seva Alekseyev May 09 '19 at 19:39
  • Actually i want to use BIOS graphic interrupt in 32 BiT in 32 bit like visual studio or using GCC in NetBeans – Umar Draz Sep 07 '19 at 12:45

1 Answers1

3

You can't use BIOS (or DOS) interrupts under an OS like Linux or Windows. Use system calls (Linux) or WinAPI library calls (Windows).

There is no portable ABI for interacting with the system outside your own process in assembly that works under both Linux and Windows; MacOS is also incompatible.

To use a BIOS interrupt:

  • make sure the BIOS exists and all of the state it depends on hasn't been modified. If the computer booted with UEFI then BIOS doesn't exist. If an OS has started it's would've nuked the state (e.g. PIC chip config, PIT config, PCI configuration space, BIOS data area, IVT, ...) that the BIOS depends on.

  • make sure you're in real mode or similar. If your code is 32-bit then you need to switch back to real mode, or setup a virtual8086 task (and its monitor), or use some sort of emulator (e.g. to interpret the BIOS's code instead of executing it directly).

Note that there are some special cases (e.g. the old "Advanced Power Management" API that was superseded by ACPI, the VESA BIOS Extensions) where a protected mode interface is provided as an (sometimes optional) alternative. These are mostly painful (e.g. involve setting up special descriptors for "16-bit protected mode" and copying binary blobs into them) and almost never worth the hassle.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Brendan
  • 35,656
  • 2
  • 39
  • 66
  • how i can boot without UEFI – Umar Draz May 14 '19 at 18:01
  • 1
    Currently most 80x86 computers support "BIOS compatibility" in the firmware's settings - you'd change the settings, then install the operating system/s to boot using BIOS. However; Intel have stated that next year BIOS compatibility will no longer be supported in Intel CPUs/chipsets/motherboards (and I'd expect other manufacturers to do the same); so it won't be very long before you won't be able to boot from BIOS at all (without a virtual machine). – Brendan May 15 '19 at 01:13
  • Note: Ideally you'd use "boot loader" to abstract the firmware's details (e.g. obtain memory map, setup video mode/frame buffer, load stuff from whichever device you're booting from, and put the system into a "defined for the OS" state) so that nothing else in the entire OS has a reason to care what the firmware was; and so that it's easy to support older computers that don't support UEFI and newer computers that don't support BIOS and anything else (e.g. "kexec()") just by installing a different boot loader and not having a reason to touch anything else. – Brendan May 15 '19 at 01:21
  • 1
    Of course this ("boot loader as abstraction layer") means you need to avoid "firmware dependencies" after boot - e.g. use ACPI for power management (and not the ancient BIOS APM interface), have a "generic frame buffer" video driver that can't change video modes until/unless you write native video drivers, don't use the BIOS services for disk IO (and have native drivers for that), etc. Fortunately, these are all things that a good OS will want to do anyway (for performance, for providing better features, etc). – Brendan May 15 '19 at 01:25