Xref: utzoo comp.os.msdos.programmer:448 comp.lang.c:30985 alt.msdos.programmer:2017 Path: utzoo!utgpu!watadm1!watserv1!ria!pruss From: pruss@ria.ccs.uwo.ca (Alex Pruss) Newsgroups: comp.os.msdos.programmer,comp.lang.c,alt.msdos.programmer Subject: Re: Help needed multitasking DOS (a little bit) using TurboC Keywords: Interrupts,TSR,MSDOS,C Message-ID: <769@ria.ccs.uwo.ca> Date: 10 Aug 90 14:30:17 GMT References: <1162@zeus.irc.usq.oz> Followup-To: comp.os.msdos.programmer Distribution: comp Organization: University of Western Ontario, London Lines: 79 In article <1162@zeus.irc.usq.oz> is written: >My references have primarily been: > >Stevens, Al "TurboC - Memory-Resident Utilities, Screen I/O and > Programming Techniques" > >Hyman, Michael "Advanced DOS - Memory-Resident Utilities, Interrupts > and Disk Management with MS and PC-DOS" > >Simrin, Steven "The Waite Group's MS-DOS Bible 3rd Ed." You should always have with you: 1. IBM Technical Reference Guide or another BIOS disassebly 2. Inter290 interrupt list Enough said, let's go on. >PROBLEM > >The resultant program basically works but is intermittently unstable >(i.e. crashes, jumping off to all regions of memory). This degree of >stability has been achieved after hacking some of the TC-compiled assembler >code (to make it smaller, use RET 2 at the end of the disk interrupt >to preserve registers etc etc). Now, wait... What do you mean to preserve registers? If you declare a function as interrupt, the registers will be OK. If you mean not to overwrite the flags, it is better (i.e. pure C code), to declare as an interrupt\ routine, then do a lahf (which you could even do via an emit) followed by flags=_AX; I have a lot of experience with writing int handlers in C. What I've noticed is that it is necessary usually to go to assembly. Anyways, here are some thoughts of mine: 1. do you make sure that either: a. by the time the next timer tick comes in, your handler is finished (you only have a 1/18.2 second slot). b. you send a specific/nonspecific EOI (I'd go for specific, but IBM's BIOS goes for nonspecific) as soon as possible (nonspecific EOI is outportb(0x20,0x20). 2. you do not reenter MesS-DOS (exception: safe reentry after swapping the three DOS stacks--see int 21/ AX=560B? in inter290). >SOME THOUGHTS > >Does anyone know of the reentrancy status of TurboC code/subroutines - >I mean more than whether DOS or BIOS routines are used? Are there any >sneaky stack swaps or something anywhere? Hmm.... I haven't got library source. I would think they are almost always reentrant... What routines do you use? I almost NEVER call TC routines from within an interrupt handler. But, I do think most things are reentrant. Ah! Wait! Floating point code is not reentrant! (Turbo C does not do a software stack-extend) Especially if you use the fp emulator and not a real coprocessor. (8087 programs are sort-of-reentrant, but the stack is only 6 numbers long). Also any routines that `return a pointer to a static area' are probably not reentrant (e.g. get password routine). >Are BIOS routines reentrant? Most of them. Of course if you reenter the disk routines in the middle of the DMA setup, you're screwed. It should be fine, however, to reenter while disk is running... maybe. I would check the disk motor status before calling a disk routine. >Any comments AAARRRGGGHHH!!!! (emotive cry of desparation), anything at >all, with regard to this problem, the references I have cited, something >I am likely to have missed etc. etc. etc. would be appreciated. >I suspect that further email discussion would be required/appropriate. I think so too. Answer my two questions, and if necessary please send me your code. I am afraid I cannot contact the original author by email, so I am posting. Alex Pruss pruss@uwo.ca pruss@RIA.UUCP pruss@UWOVAX.BITNET [pruss@uwo.ca is preferred, the others are subject to change]