Subj : Interrupts To : Nick Andre From : Mike Luther Date : Thu May 03 2001 04:03 pm Nick, I used this toolset for years. NA> Hi... NA> NA> I have two questions about programming for OS/2. NA> NA> First, what is the DOS interrupt to give up NA> timeslicing back to the OS? I think its 2F, but can NA> someone tell me for sure? And when specifically should NA> a timeslice be given back to OS/2? (keyboard idling, NA> etc?) Instead of working at it this way, I think you will be better served by giving a look not only at this, but the TAME330 utility, or one like it. It works for most, but not all applications to bust up CPU bashing. At least do that for learning's sake first as well, OK? For example, before I started fooling around with assembler code to break it up in my actual programs, TAME330 took care of everything I ever threw at it via the M/S Bascom PD7 package. I had *LOTS* of code in it, actually over 750,000 lines of source..... NA> And second, I have MS-PDS 7.1 (QuickBasic), which can build both DOS and NA> OS/2 applications. It works wonderful, except for some NA> reason I can't perform ANY "low level" operations if I NA> want to compile for OS/2 (ie. poking around in memory, NA> calling interrupts, etc). I think there is a way NA> around this in the BC compiler (or possibly the NA> linker?) but does anyone know why? Aha! We are now on the same wavelength here, officially! Some of the operations that are provided in DOS are not enabled in OS/2. I never continued toward native OS/2 applications with it. The reason for that was that things I distribute had to be Y2K certified. There was no way to stand on that toolset for that reason. I still have all the hard bound docs for the toolset. I think if you read the reference guide carefully, you will find that certain functions are not enabled in OS/2. Unless I miss this, for example, I think you will find that the direct port communications functions OUT and INP do not work in the OS/2 side of the house. Nor does anything else that makes direct use of the hardware ports, although there were cross platform communications functions for things like using the serial ports with file management techniques. You could, indeed, and I did, as I recall, splice in assembler coded low level comm port operations via linking custom libraries to them. I never, therefore, went beyond the low-level assembler stuff I managed to write which worked in DOS as well. I figured that when time came, I'd still be OK porting it all to OS/2. But when the Y2K game hit, and I realized that there would be no further way to upgrade to anything with PD 7.1, I looked for another DOS solution. That just to get me through Y2K. That move produced a decision, based on the time it would take and the Y2K deadlines, to at least temporarily use PowerBASIC as a substitute for PD 7.1 so I did that. It has actually taken until this time to move everything there .. now a total of over 1,200,000 lines of source covering over 110 full inter-related executables and major common library modules in PB 3.5. Of course I'm still stuck with what to do on moving to native OS/2, so where I really wanted to go, C++ in Watcom, has been waiting in the wings. Presently, I've managed to write a complete translator from about 138 off the 210 functions we use in PB 3.5, very much like BC 7.1, to Watcom C++ version 11b. That enroute to IBM's Visual Age for C++.. as well. Either way I can get to OS/2. But with VAC++ I can also get to LINUS/*IX if I must. I probably, like it or not must .. groan. The number of lines in the suite will likely, from early research in the translator, grow to about 4,000,000 lines in C++ .... gloom. From all this has come an assembly language snipset that I now use in the PowerBASIC compiler operations to give me time slice control in every program, as it now stands. The PowerBASIC compiler has a very easy to use in-line assembler interface, much like you can use with PD 7.1 .. Here's how it looks in PB 3.5 code. I think if you look at it, you can likely adapt it to PD 7.1. That just *MIGHT* get you where you want to go in native 16 bit OS/2 as well. Hence the long pig trail to here! > IF ISTRUE BIT(pbvHost, 8%) THEN ' In WIN environment > ! push DS > ! mov AX, &H1680 > ! int &H2F > ! pop DS > ELSE ' Not in a WIN environment > ! push DS ; Save DS for PowerBASIC > ! mov AX, &H8600 ; Place function $AH68in AX > ! mov CX, &H00 ; Use less than 1000 MS delay > ! mov DX, &H0A00 ; Try &H0A00 for a delay in DX > ! int &H15 ; Call timer interrupt > ! pop DS > END IF In PowerBASIC I learned it is necessary, and safer for sure, to save the DS for the compiler return. I never did that in M/S code. It may be useful even in BC 7.1 I think. As well, the internal function for pvbHost is a product specific internal function for PowerBASIC which does the above job of detecting whether the box is operating in a WIN environmnet. That snoop lets you safely operatine in the &H2F mode you are seeking, I think. I suspect that if you look at Ralf Brown's interrupt list site, you can find a non-PowerBASIC function that will let you determine if you are in WIN or an OS/2 environment, which the above does *NOT* address. I know there are several ways at low level to do this. If you get the TAME320 or TAME330 utility, which I think is on HOBBS, I think you will get all the help you need on identifying which polling monsters for which you should provice. The keyboard is the most obnoxious in my estimation. But note! To this very day I have *NEVER*, using any combination of third party tools,ever been able to break the PowerBASIC IDE of sucking eggs with the CPU. Never .. ever .. no never .. NEVER. To that extent, be careful on the old classic Pentium CPU chips. Any application you distribute or run on them that maxes the CPU out, can trigger the F0 bug gambit. I've had PowerBASIC reduce my OS/2 hard disk to rubble twice, forcing a complete tape rebuild, just from accidentally leaving it up overnight running the IDE while four other sessions were doing DOS port applications and all writing and cross-writing to the hard disk. I fell asleep and let PB 3.5 sit idle trashing the CPU on a classic P-box. Cheers .. Mike @ 1:117/3001 --- Maximus/2 3.01 * Origin: Ziplog Public Port (1:117/3001) .