Assembly Interupt in C++

I wrote a piece of working assembly code and I am now trying to combine it with a c++ program. I have just figured out that dev-c++ can't handle interupts. How else can I get my assembly code into the c++ program.

My original assembly code

Code:

main:
mov ax, 09
mov ds, ax
mov ax, 0a000h  ;Set ES to be the graphics segment
mov es, ax
mov ah, 0Fh  ;Gets and saves current video mode
int 10h
push ax
mov ax, 0013h  ;Turn on mode 13 graphics
int 10h
 
mov cx, 320  ;Number of pixels per row/Screen width
mov ax, 100  ;Set y coordinate
mul cx
mov cx, 160  ;set x coordinate
add ax, cx
mov bx, ax
mov cx, 9  ;Set Color
mov es:[bx], cx  ;Place point
 
 
mov   ah,0       ;wait for keypress
int   016h
pop ax   ;Restore original graphics mode
mov ah, 0
int 10h
mov ax, 4c00h  ;Exit program
int 21h

My updated c++ program

Code:

void point()
{
    __asm("mov %ax,_09");
    __asm("mov %ds, %ax");
    __asm("mov %ax, _0a000h");
    __asm("mov %es, %ax");
    __asm("mov %ah, _0Fh");
    __asm("int 10h");
    __asm("push %ax");
    __asm("mov %ax, _0013h");
    __asm("int 10h");
    __asm("mov %cx, _320");
    __asm("mov %ax, _100");
    __asm("mul %cx");
    __asm("mov %cx, _160");
    __asm("add %ax, %cx");
    __asm("mov %bx, %ax");
    __asm("mov %cx, _9");
    __asm("mov %es:[bx], %cx");
    __asm("mov %ah,_0");
    __asm("int 016h");
    __asm("pop %ax");
    __asm("mov %ah, _0");
    __asm("int 10h");
    __asm("mov %ax, _4c00h");
    __asm("int 21h");
}

Any Help would be appreciated,
Steven

> I have just figured out that dev-c++ can't handle interupts.
That would be because it isn't a DOS compiler.
Which should be fairly obvious, since your OS isn't DOS either.

Don't make the mistake of assuming that the nice black rectangle you see with a "C:\>" prompt in it is DOS. It isn't, not by a long way.

What you're creating using dev-c++ are win32 console programs. Consoles don't do graphics, and don't need messy interrupt calls to muck about with specific memory locations.

If you want to do graphics, then use the package manager to download the "devpak" for libsdl

Originally Posted by Salem

> I have just figured out that dev-c++ can't handle interupts.
That would be because it isn't a DOS compiler.
Which should be fairly obvious, since your OS isn't DOS either.

Don't make the mistake of assuming that the nice black rectangle you see with a "C:\>" prompt in it is DOS. It isn't, not by a long way.

What you're creating using dev-c++ are win32 console programs. Consoles don't do graphics, and don't need messy interrupt calls to muck about with specific memory locations.

If you want to do graphics, then use the package manager to download the "devpak" for libsdl

Actually, I believe that if you do a 16-bit application, you can convince the DOS shell to go into graphics mode and do all sorts of "wonderful" things. This, however, requires that the code is built for 16-bit mode, which dev-c++ doesn't, and the limit of 640KB of memory is quite a challenge for modern software.

I'm also pretty sure that 64-bit version of Windows doesn't support any 16-bit apps, and that will be the future versions of Windows - maybe not the next year or two, but certainly not that distant in the future.

I agree that libsdl or similar is definitely the right solution.

--
Mats

Interupts are a bad thing unless you are specifically writing for real mode. Nowadays the only people that write real mode programs are hobbiests and industrial engineers. Command prompt isnt really dos, its a VM, which emulates dos (poorly). I dotn even know of any 16 bit compilers anymore, last one I had was Turbo C back in the early 90's

The DOS emulation in Windows XP is actually rather robust but it will not let you load drivers into high memory, service certain interrupts, or do low level DMA programming (at least without being harassed by the OS). It's also much picker about how you handle memory even while in protected mode which was not true under DOS or extended DOS via DPMI. You could theoretically map an address outside of your address space into your address space using near pointers with no problem. Windows XP barfs when you attempt this in a DOS session.

As has been suggested use a modern compiler with a modern graphics API.

Originally Posted by abachler

Interupts are a bad thing unless you are specifically writing for real mode.

Because more advanced operating systems don't use interrupts? I think there's a break in your logic there.

In a modern OS it is unusual for a user application to install an interrupt handler but it's not like there aren't any interrupts going on.

Originally Posted by brewbuck

Because more advanced operating systems don't use interrupts? I think there's a break in your logic there.

In a modern OS it is unusual for a user application to install an interrupt handler but it's not like there aren't any interrupts going on.

There are of course two aspects of this. Yes, HARDWARE interrupts are DEFINITELY going on in ANY system (at least anything more complex than a very basic electronic toy).

Software interrupts, like in the above code, is also used quite often to do system calls [in Windows, Linux, OS/2 and most of the RTOS's I've seen the source for].

However, I think abachler's point is that the programmer rarely, if ever, use these software interrupt him-/herself, because they are part of the low-level runtime library functions, and it's fairly well hidden and separated from the application programmer - and so it should be. There are for example things like SYSCALL/SYSENTER that got introduced to recent x86 processors, that allow a faster entry into the kernel than INT xx instructions. If you replace one with the other, then the application software gets affected. That's not very good for the application software. If the application software is actually using the system calls directly, then that means binary compatibility is broken when an upgrade of the OS happens - not a good idea.

So, I agree in the principle that calling Software interrupts inside application code is broken.

--
Mats

Software interrupts have been replaced by calls to drivers who then perform the low-level functionality you need. This is the way Intel designed protected mode to work according to the tech refs and I believe there is even a whole section in the books about this very topic.

The idea from a software level is that now instead of having to call BIOS, hook interrupts, etc, etc, we call drivers in the operating system which then handle the nitty gritty that most of us could care less about. If I'm an application needing low level access to the hard drive I really don't care how it gets done or the process involved. All I know is a driver in memory should be able to handle all of that junk and the outcome is I gain low level access to the hard drive. Windows does this by providing the DDK and by allowing users to install drivers which then get called by the OS to perform their specific tasks.

Thankfully the days of loading registers and doing an interrupt are over. Now if I'm in Direct3D and want a 32-bit 1024x768 screen I simply ask for it and the driver either tells me you are crazy we don't support that or it does what I want. I could care less how it does that......I just care that it does it.

Originally Posted by Bubba

Software interrupts have been replaced by calls to drivers who then perform the low-level functionality you need. This is the way Intel designed protected mode to work according to the tech refs and I believe there is even a whole section in the books about this very topic.

The method suggested by Intel, using call-gates, is actually not used very much. Most OS's that I know of use software interrupts or the relevant SYSCALL or SYSENTER instruction. Windows and Linux certainly does. I ported one OS to x86, and that used call-gates. But that is the only semi-commercially available product I know of that uses this technique. I think OS/2 may also do that - not sure.

So, although you use drivers to do hardware interaction from the user-mode app, it still has to enter the OS, and that's commonly done by Software Interrupt - many of the non-x86 processors also have no other way to enter the OS [e.g. PDP-11, VAX and 68K uses TRAP, 29K uses the "assert" instruction ("ASNEQ", assert not equal, with the same register on both sides, to be precise), ARM uses the SWI instruction - don't know details of any other processors].

The idea from a software level is that now instead of having to call BIOS, hook interrupts, etc, etc, we call drivers in the operating system which then handle the nitty gritty that most of us could care less about. If I'm an application needing low level access to the hard drive I really don't care how it gets done or the process involved. All I know is a driver in memory should be able to handle all of that junk and the outcome is I gain low level access to the hard drive. Windows does this by providing the DDK and by allowing users to install drivers which then get called by the OS to perform their specific tasks.

Thankfully the days of loading registers and doing an interrupt are over. Now if I'm in Direct3D and want a 32-bit 1024x768 screen I simply ask for it and the driver either tells me you are crazy we don't support that or it does what I want. I could care less how it does that......I just care that it does it.

Yes, software drivers is a much better approach than BIOS calls, that's for sure. And supporting multiple devices is much easier when the entry point to a driver is defined as a function pointer in a data-structure that there can be multiples of than when there is one INT XX entry that handles ALL disk drives, for example.

--
Mats

Thanks. Moving on.