I am not sure about TP 5.5, however, for version 7 there was a runtime error 200 thingy on fast computers. If this is what you were talking about there are couple of solutions for that. One of them patches the TPL itself so you can recompile your project or you can patch the executable so no recompilation needed. Some of the executables compressed with exepackers so that you might need to unpack first then apply the patch and repack or leave it as it is. http://www.merlyn.demon.co.uk/pas-r200.htm http://www.codecomments.com/archive353-2005-4-463168.html anyway, google on it: http://www.google.ie/search?hl=en&q=turbo+pascal+tpl+patch+runtime+error+200+fast+cpu&btnG=Google+Search&meta= Tamas On 28/10/06, Bob Axtell wrote: > > William Couture wrote: > > On 10/27/06, Bob Axtell wrote: > > > > > >> NONE (not one) application written under DOS6+ by TP5 (Turbo Pascal 5.5 > >> for DOS)- which all work > >> fine under a DOS system- will work under WinXP. I just ran thru about > 50 > >> that I knew were not hardware-related. > >> They would give me a screen OK, but none of the keys or F-keys respond. > >> I can't even EXIT the program. > >> > > > > Hmmm... that rings a small bell. > > > > I was trying to track down why a program didn't seem to work right > > under a DOS Window, and I found that it was Windows trying to be > > too helpful. > > > > When the program was doing a BIOS call to see if a character was > > waiting, the "BIOS" seemed to be telling itself: > > Since the keyboards in existance when this BIOS call was originally > > written didn't have all these extended functions, I'm sure the > program > > doesn't know how to handle them, so I'll just be helpful and remove > > them so the program isn't confused. > > > > Of course, since *ALL* of the function keys now reply with an extended > > code sequence, not the original code sequence from the IBM-XT keyboard, > > *ALL* of the function keys are "missing" when you call BIOS. > > > > Interstingly, a DOS call does not have that problem (IIRC). > > > > What I wound up doing was the "later", 101-key keyboard BIOS call > > to get the char, and if that failed, then I fell back to the original > BIOS > > call. So, a "check for character and get it if one is waiting" becomes: > > XOR AL,AL > > MOV AH,11H ; 101-key keyboard "check for char" > > INT 16H > > JC OLD_BIOS > > JNZ GET_CHAR > > OLD_BIOS: > > MOV AH,1 > > INT 16H > > JNZ GET_CHAR > > XOR AX,AX ; no char waiting > > JMP GET_CHAR_DONE > > GET_CHAR: > > MOV AH,0 > > INT 16H > > OR AL,AL ; extended keypress (FN key or such) > > JNZ GET_CHAR_NORMAL > > MOV AL,AH ; scancode to AL > > MOV AH,1 ; flag extended key > > JMP GET_CHAR_DONE > > GET_CHAR_NORMAL: > > MOV AH,0 ; just a normal character > > GET_CHAR_DONE: > > > > which works fine under any version of DOS with any BIOS. > > > > I'm wondering if you can write a trivial TSR to "fix" TP5 programs. > > Something like: > > INT16HERE: > > CMP AH,1 ; fn = check for keypress? > > JNE CONTINUE_INT16 > > MOV AH,11H ; change to 101-key check for keypress > > CONTINUE_INT16: > > JMP FAR OLD_INT16_VECTOR > > > > > >> Its like I am living on another planet... You guys are, like, putting > me > >> on, right? > >> > > > > No, we've just been lucky -- we haven't had "BIOS" (not the REAL BIOS, > > it's part of the XP kernel) try to "HELP" us. > > > > Bill > > > > > That is an interesting observation. Thanks for the heads-up. > I might tinker with that as soon as some time is freed up. > > --Bob > > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- unPIC -- The PIC Disassembler http://unpic.sourceforge.net -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist