jhs@hpfinote.HP.COM (John Stanback) (02/22/90)
I'm trying to install a mouse event handler function using TurboC 1.5 with the medium memory model. The mouse handler is installed using INT 33, function 12. The references I've seen to doing this use an area in the PSP to store the mouse event status and access this memory referencing _CS in the mouse handler. This seems to work in the small memory model, but not in the medium. How can I store the mouse event status using the medium memory model???? Also, I would like to be able to access the programs global variables from the mouse handler. Is this possible??? Thanx, John Stanback jhs@hpfcla.HP.COM
jdc@beach.cis.ufl.edu (Jeff Capehart) (02/24/90)
In a previous article jhs@hpfinote.HP.COM (John Stanback) writes: >I'm trying to install a mouse event handler function using TurboC 1.5 >with the medium memory model. The mouse handler is installed using >INT 33, function 12. The references I've seen to doing this use >an area in the PSP to store the mouse event status and access this >memory referencing _CS in the mouse handler. This seems to work in >the small memory model, but not in the medium. How can I store the >mouse event status using the medium memory model???? Also, I would >like to be able to access the programs global variables from the >mouse handler. Is this possible??? Yes, it is possible because I have done it. You may not like my solution but it works. If all you are interested in is working then listen up. The problem comes from the fact that the _PSP doesn't seem to work right in the medium and large models. And, when referencing _CS, you are in a different segment than in the small model. The example programs that came with the mouse for TurboC *CHEAT* and use small model. Anyone could do it in small model, sheesh! The main program can setup the buffer area fine in the end half of the PSP area. The interrupt handler cannot find it because it uses a different code and data segment. So, there must be someway to get it to use the same area. Well, this is exactly why you were using the PSP area in the first place. Viscous circle right? Global variables won't cut it because you get a different _DS and _CS when the interrupt handler is called. It can't find your global variables. What I decided to do was use some globally known memory locations. Since 8088 doesn't have a "zero page" like on 6502 machines, the closest thing was the Interrupt Vectors. These are modifiable and they come in groups of 4 bytes. The easiest one to pick is the "switch to Basic" interrupt. Who needs it anyways, especially if you are in TurboC anyways! heh heh. Ok, so I forget which it was, but assume it is 0000:0064 for now. Before installing the handler, make a far pointer to it MK_FP (0x0000, 0x0064) and then stuff into it the address of the PSP, or the _CS for the _MAIN. Also, in the interrupt handler, make a far pointer to it and extract the value from there. Then, make another far pointer out of THAT value and you have the address you want. You can either save the segment or both the seg & offset. Just be consistent. Be careful about what interrupt vector you steal because some of them are important. Others are not so important like the Basic interrupt. -- Jeff Capehart Internet: jdc@beach.cis.ufl.edu University of Florida UUCP: ..!uflorida!beach.cis.ufl.edu!jdc
pipkins@qmsseq.imagen.com (Jeff Pipkins) (02/27/90)
In a previous article jhs@hpfinote.HP.COM (John Stanback) writes: >I'm trying to install a mouse event handler function using TurboC 1.5 >with the medium memory model. The mouse handler is installed using >INT 33, function 12. The references I've seen to doing this use >an area in the PSP to store the mouse event status and access this >memory referencing _CS in the mouse handler. This seems to work in >the small memory model, but not in the medium. How can I store the >mouse event status using the medium memory model???? Also, I would >like to be able to access the programs global variables from the >mouse handler. Is this possible??? There is no reason to make this solution so hard. Elaborate hacks involving PSPs (such as some that have been suggested) are not just ugly, they're overkill as well. This problem is much simpler than that, and no undocumented information is required. First of all, the PSP is no place to store mouse data. In .EXE files, the CS register does not give proper access to it anyway. I am not familiar with Turdo C's library functions for mouse handling, but I have written mouse handlers in ASM and interfaced them to MSC. If you use the "interrupt" keyword to create a C function with interrupt entry code (not great style, but it works), you can do the same in C. This C interrupt function can access global or local static storage just like any other C function. No magic necessary. Suggestion dept: Create a source file (maybe mouse.c) to hold all functions you will write concerning mouse support. If these functions need to share memory, define this memory at the top of the file and declare it "static". This means that only functions in this source file can access it. Do not define globals. Instead, define functions that will return values of interest. This approach will separate the mouse functions from the applications, so that later you can modify the mouse functions without having to modify the apps. An event queue is a very nice way to handle a mouse, but there is not much literature on it that I have seen. It is simple to implement. You just create a circular queue. There is a lot of literature on that. (See Knuth) When the interrupt handler gets invoked (an event has occurred), all it does is insert a token in the event queue representing the event. Entries may have room to store additional information, like position. A separate C function can then easily read these events from the queue and process them. A finite state machine is useful for this purpose. The most straightforward version is a switch construct inside a loop. The nicest feature of this architecture is that you don't have to worry about calling nonreentrant functions (or DOS) from the interrupt handler, and you don't have nightmares about interrupt handlers accessing global variables. Hope this helps. -Jeff Pipkins pipkins@imagen.com