Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwvax!tank!tartarus.uchicago.edu!stuart From: stuart@tartarus.uchicago.edu (Stuart A. Kurtz) Newsgroups: comp.sys.mac.programmer Subject: Re: Terminate and Stay Resident? Summary: Don't do it! Message-ID: <3864@tank.uchicago.edu> Date: 15 Jun 89 23:24:37 GMT References: <2361@etive.ed.ac.uk> Sender: news@tank.uchicago.edu Reply-To: stuart@tartarus.uchicago.edu.UUCP (Stuart A. Kurtz) Organization: Dept. of Comp. Sci., The University of Chicago Lines: 66 gjr@etive.ed.ac.uk asks whether or not it makes sense to use an init to aid in porting an MS-DOS program that relies on tsr code. I can only see three reasons for the terminate-and-stay-resident kludge: 1) to evade the limit on process size under MS-DOS. Your program is either too big or requires too much data to fit. 2) for some reason, the original program wants to keep data around across runs within a single boot session. E.g., it might want to know how many times its executed since the last reboot. 3) the tsr code is patching around something in MS-DOS, and the interrupts are replacing BIOS interrupts. All these have easy solutions: 1) the MacOS doesn't have a disgusting limit on process size (well, there is at present a limit of 8M, but let's hope that's not a problem). If this is the problem, just combine the tsr code with the main program and call it directly. 2) There are two solutions to this problem. The lazy solution is to put an unpurgeable resource in the system heap. This will give you trouble under a lot of circumstances. The robust alternative is to store the information in the resource fork of the file, along with the time of last reboot. When you start up, load the resource and check the embedded time: if it's old, revert to defaults. 3) If it's doing this, there is real kludgery present. Either the PC application is (a) fixing something that is broke in a way that won't break other programs; (b) checks to sees who calls it, and then calls the default trap if it's not your application [this is almost too gross to imagine], or (c) breaks other programs. You might find that whatever is broken in MS-DOS isn't broken on the Mac; and even if it is broken, it is probably broken in a different way. In any event, there is a well-defined, safe, and supported mechanism for patching Mac traps. I *really dislike* the idea of an init-dependent application. I almost always run off a hard disk. The init-dependent solution requires that I either: a) always pay the price in memory for the resident code, even when I'm not going to run your application. (I have a 5 meg machine, but I also run Mathematica. Space is too dear to give it up for no good cause.) Or, b) I have to reboot off a special disk whenever I want to run your program. Believe me, I wouldn't accept either solution. Don't do it. Trust me. Stu ------------------------------------------------------------------------- Stuart A. Kurtz Telephone: (312)-702-2493 Department of Computer Science EMail: stuart@cs.uchicago.edu University of Chicago 1100 E. 58th Street Chicago, Illinois 60637 ------------------------------------------------------------------------- Stuart A. Kurtz Telephone: (312)-702-2493 Department of Computer Science EMail: stuart@cs.uchicago.edu University of Chicago