Idea similar to _exit

[eoredson]

Hi,

I had an idea..

Since _exit traps Control-Break which is int x1B
then why not trap _print with PrintScreen which is int x05

Erik.

[mnrvovrfc]

I made a quick look at "libqb.cpp", toward the bottom, at the "big fat main loop". It doesn't look like "_EXIT" is being handled by ancient interrupts. What you're requesting might have to be programmed like that for "_EXIT" but check for a different keystroke combination. Why do you want to trap "Print Screen" key? Oh OK you must actually have a printer and it's annoying to press it. Or it's annoying that Windows interferes when it guesses the user must have wanted to print a text file via Notepad.

You have to remember that any trace of "CALL INTERRUPT" is emulated by QB64PE only with the first three or so mouse functions, because those calls were quite common in programs written for QBasic, especially those by "TheBob". Cannot emulate BIOS or MS-DOS like we could do in M$QB or QBasic many years ago. Therefore, any emulation of ancient interrupts have to be implemented. Oh no somebody is going to request the "BSOD" one or the disk sector one... just ignore them devs.

The same thing goes on with the ancient input and output ports. Because so many QB/QBasic programs played around with EGA/VGA bit planes, the ports were emulated at that end. One more thing to emulate might have had to do with the keyboard. Otherwise Windows Vista and later was going to make it a pain installing a DLL only to be able to use "INP()" and "OUT" and "WAIT" in a QB program away from 16-bit.

[Pete]

15 innings? How can you stand sitting through 15 innings of baseball? Now if you will excuse me, I have to watch golf.

Pete

[SpriggsySpriggs]

I made a quick look at "libqb.cpp", toward the bottom, at the "big fat main loop". It doesn't look like "_EXIT" is being handled by ancient interrupts. What you're requesting might have to be programmed like that for "_EXIT" but check for a different keystroke combination. Why do you want to trap "Print Screen" key? Oh OK you must actually have a printer and it's annoying to press it. Or it's annoying that Windows interferes when it guesses the user must have wanted to print a text file via Notepad.

You have to remember that any trace of "CALL INTERRUPT" is emulated by QB64PE only with the first three or so mouse functions, because those calls were quite common in programs written for QBasic, especially those by "TheBob". Cannot emulate BIOS or MS-DOS like we could do in M$QB or QBasic many years ago. Therefore, any emulation of ancient interrupts have to be implemented. Oh no somebody is going to request the "BSOD" one or the disk sector one... just ignore them devs.

The same thing goes on with the ancient input and output ports. Because so many QB/QBasic programs played around with EGA/VGA bit planes, the ports were emulated at that end. One more thing to emulate might have had to do with the keyboard. Otherwise Windows Vista and later was going to make it a pain installing a DLL only to be able to use "INP()" and "OUT" and "WAIT" in a QB program away from 16-bit.

I'm very confused as to why you are bringing up mouse interrupts and such. I think all he's saying is that he wants a way to catch if someone has pressed "PrintScreen". Very easy to do, as far as I can tell. Not easy to make a new keyword to do it (for me, at least) but definitely easy to do it with Win32 API in a program. It's the "VK_SNAPSHOT" key (0x2C). I'm not sure why he said it was 0x05. That's "VK_XBUTTON1".

GetAsyncKeyState (MSDN page for the function used to check for key presses from the Virtual Key Codes page)

[mnrvovrfc]

I'm very confused as to why you are bringing up mouse interrupts and such.

I based my answer on the OP saying which ancient interrupt did this or that, but that's all. There shouldn't have been any confusion. Anyway, you could explain to @eoredson better than I did what is happening.
The OP also said "INT 0x05" which is something you've obviously missed. It's not a virtual keyboard code. It was a BIOS interrupt.
https://en.wikipedia.org/wiki/BIOS_interrupt_call

[SpriggsySpriggs]

Either way, the pages I referenced will provide what he's looking for since he's trying to catch those events. He's familiar with Win32.

[eoredson]

The assembly code I am using to trap x1b and x05 is this:

Code: (Select All)

;Traps and ignores Print-Screen and Control-Break. v1.1a PD 2020.

;Compiled with 'Tasm /t Keytrap;'

;Compile calling program using /fs with BC. (QBX forces /fs).

            .model  medium, basic          ;Stay compatible with basic.
    extrn  SETUEVENT: far
            .code
public      SETINT

SETINT      proc    uses ds
            mov    ax, 351BH              ;Get old control-break interrupt
            int    21h                    ;vector and save it.
            mov    word ptr cs:OldVector1,bx
            mov    word ptr cs:OldVector1+2,es
            push    cs                      ;Set the new
            pop    ds                      ;interrupt vector
            lea    dx, EventHandler        ;to the address
            mov    ax, 251BH              ;of our service
            int    21H                    ;routine.

            mov    ax, 3505H              ;Get old print-screen interrupt
            int    21h                    ;vector and save it.
            mov    word ptr cs:OldVector2,bx
            mov    word ptr cs:OldVector2+2,es
            push    cs                      ;Set the new
            pop    ds                      ;interrupt vector
            lea    dx, EventHandler        ;to the address
            mov    ax, 2505H              ;of our service
            int    21H                    ;routine.
            ret
SETINT     endp

public  EVENTHANDLER

EVENTHANDLER    proc
            iret                            ;eat keystroke. pop stack.

OldVector1  dd      0                      ;keep data in code segment.
OldVector2  dd      0

EVENTHANDLER endp

public      RESTINT

RESTINT    proc    uses ds                ;Restore the old
            lds    dx, cs:OldVector1      ;interrupt vectors
            mov    ax, 251BH              ;so things will
            int    21h                    ;keep working when
            lds    dx, cs:OldVector2      ;this basic program is
            mov    ax, 2505H              ;finished.
            int    21h
            ret
RESTINT    endp
            end

[a740g]

The assembly code I am using to trap x1b and x05 is this:

Code: (Select All)

;Traps and ignores Print-Screen and Control-Break. v1.1a PD 2020.

;Compiled with 'Tasm /t Keytrap;'

;Compile calling program using /fs with BC. (QBX forces /fs).

            .model  medium, basic          ;Stay compatible with basic.
    extrn  SETUEVENT: far
            .code
public      SETINT

SETINT      proc    uses ds
            mov    ax, 351BH              ;Get old control-break interrupt
            int    21h                    ;vector and save it.
            mov    word ptr cs:OldVector1,bx
            mov    word ptr cs:OldVector1+2,es
            push    cs                      ;Set the new
            pop    ds                      ;interrupt vector
            lea    dx, EventHandler        ;to the address
            mov    ax, 251BH              ;of our service
            int    21H                    ;routine.

            mov    ax, 3505H              ;Get old print-screen interrupt
            int    21h                    ;vector and save it.
            mov    word ptr cs:OldVector2,bx
            mov    word ptr cs:OldVector2+2,es
            push    cs                      ;Set the new
            pop    ds                      ;interrupt vector
            lea    dx, EventHandler        ;to the address
            mov    ax, 2505H              ;of our service
            int    21H                    ;routine.
            ret
SETINT     endp

public  EVENTHANDLER

EVENTHANDLER    proc
            iret                            ;eat keystroke. pop stack.

OldVector1  dd      0                      ;keep data in code segment.
OldVector2  dd      0

EVENTHANDLER endp

public      RESTINT

RESTINT    proc    uses ds                ;Restore the old
            lds    dx, cs:OldVector1      ;interrupt vectors
            mov    ax, 251BH              ;so things will
            int    21h                    ;keep working when
            lds    dx, cs:OldVector2      ;this basic program is
            mov    ax, 2505H              ;finished.
            int    21h
            ret
RESTINT    endp
            end

This looks like real mode x86 ASM. Brings back a lot of old memories.  None of this stuff is going to work with QB64 though because QB64 works under protected mode operating systems that does not allow you to use interrupts like we could with DOS. You'll need to use the appropriate OS APIs to achieve what you are trying to do. I would suggest looking at what @Spriggsy said if you are writing your code for Windows. I am quite certain that there are relevant APIs for Linux and macOS too. However, I am not too familiar with those OSes.

[eoredson]

What I found interesting is where iret exits after a Control-Break bios interrupt.
then in that area of code either a subroutine could be called or a variable such as _exit could be set.

My reasoning is thus:

If inline assembly could be injected into 'C' and inline 'C' could be injected (such as Mem.h) into QB64, then why not inject assembly into QB64!?
(I know it doesn't work like that but it is a passing idea)..

[mnrvovrfc]

My reasoning is thus:

If inline assembly could be injected into 'C' and inline 'C' could be injected (such as Mem.h) into QB64, then why not inject assembly into QB64!?
  (I know it doesn't work like that but it is a passing idea)..

It might be darned confusing, but you could employ "dot-h" files to include into QB64 code. The "dot-h" file could have something like is talked about in section 6.47 of "info gcc" manual: "How to use inline assembly language in C code".

https://gcc.gnu.org/onlinedocs/gcc/Using...ith-C.html

It would have to be tested because QB64PE counts on "g++" not on the C compiler of "gcc".

Also @eoredson, it might not be supported by "MinGW" which comes with QB64 v2.0.2 32-bit which you have.