videogamer555 wrote:

Is there a way to prevent hardware interrupts from happening (such as preventing the CPU from responding to interrupts generated by key presses on the keyboard)? And instead put the CPU in charge of explicitly polling the keyboard (via the use of IN and OUT instructions) at points in the program where keyboard input is needed? That way I could use the IN and OUT instructions in my software directly (not depending on the underlying DOS OS do to it), and therefore I can avoid the use of INT calls, as well as avoid hardware interrupts being fired by the connected keyboard (and other input devices). Therefore I can prevent interrupts from happening that could kick the program's execution out of of its valid 32bit segment (which would otherwise crash the system). Is it possible to do this, completely disable the use of all interrupts, and instead depend on the use of IN and OUT, directly from the program itself?

Key presses generate another IRQ, so CLI would take care of that too. I would not worry about NMI as those only happen when something really bad happens. And I already gave you a bit of code to disable them as well anyway.

As for what I plan to do. My plan is simple:
Create a COM file, who's first action when run from DOS is to switch into 32bit protected mode.
Then have it run 32bit code.
It does not have any requirement of being able to switch back into real mode (which should significantly cut down on program complexity), as I intend that program then to continue to run until the computer is powered off.
Because it doesn't have any need to exit to DOS, there's no need to keep in mind that the COM file is running within DOS. It can reuse any memory that DOS previously used for its code (it can overwrite DOS code, so I don't need to be very careful about keeping DOS in tact, which should make it easier to write the COM file without restrictions).
I don't need it to use interrupts of any kind (hardware or software), because I intend to use IN and OUT to directly communicate with any other hardware (keyboard, mouse, etc).
So completely disabling all interrupts (even more thoroughly than can be done with the CLI command) would be beneficial (don't want an interrupt to kick me out of 32bit protected mode, which could crash the system), and don't want to have to bother to write 32bit interrupt code.

You probably want to use Unreal mode:
https://en.wikipedia.org/wiki/Unreal_mode
Example code is shown here:
http://wiki.osdev.org/Unreal_Mode

So does that mean that I have to manually write 256 pieces of code (one for each interrupt, as any one could be called at any time, without warning, by the underlying system),

Technically yes, but most of them could be simple stubs, and one piece of code can be shared by multiple interrupts.

and make sure they behave in exactly the same way as the original real-mode versions of the interupts?

No, they don't have to behave in the same way. That depends on your needs.

What happens if I just disable all interrupts by using the assembly language opcode CLI? Doesn't that prevent any interrupts from ever being used?

Your system is crippled. You'll need at least CPU exceptions and hardware interrupts pretty quickly.

You don't need to use software interrupts (int xx instructions) for anything. DOS and BIOS use them, Linux uses them (at least the 32-bit version), Windows doesn't.

videogamer555 wrote:

As for what I plan to do. My plan is simple: Create a COM file, who's first action when run from DOS is to switch into 32bit pro […]
Show full quote

As for what I plan to do. My plan is simple:
Create a COM file, who's first action when run from DOS is to switch into 32bit protected mode.
Then have it run 32bit code.
It does not have any requirement of being able to switch back into real mode (which should significantly cut down on program complexity), as I intend that program then to continue to run until the computer is powered off.
Because it doesn't have any need to exit to DOS, there's no need to keep in mind that the COM file is running within DOS. It can reuse any memory that DOS previously used for its code (it can overwrite DOS code, so I don't need to be very careful about keeping DOS in tact, which should make it easier to write the COM file without restrictions).
I don't need it to use interrupts of any kind (hardware or software), because I intend to use IN and OUT to directly communicate with any other hardware (keyboard, mouse, etc).
So completely disabling all interrupts (even more thoroughly than can be done with the CLI command) would be beneficial (don't want an interrupt to kick me out of 32bit protected mode, which could crash the system), and don't want to have to bother to write 32bit interrupt code.

just use a dos extender. there is lots of little things you need to take care of with pmode and dos, is user running himem? or some variant? qeem? desqview? emm386? do they have a vcpi or dpmi server running? no need to create your own gdt, idt, ldt and setup page tables and everything else and futz with wich way to determine memory, int 15, direct scanning, cmos, some other method etc.

easier to use dos32, pmode, etc already written extenders to do it.

even if you dont need to use interrupts, they run anyway (this thing called a real time clock).. you press key on keyboard, the hardware generates IRQ.. isa cards in system want bus control, generate IRQ..

anyway, if you want to disregard dos, its pretty simple. I wrote a bootsector that would switch into pmode for my OS dev stuff. but there are still many things to take care of.

Unless you want to write your own OS (which is exciting but extremely hard), use a DOS extender.
You can write protected mode programs in C or C++ using DJGPP and OpenWatcom.
If you want pure assembly, NASM will work with both - yes I tried.

There's also Free Pascal that uses the same extender as DJGPP.