Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!xylogics!merk!alliant!linus!think!ephraim From: ephraim@think.com (Ephraim Vishniac) Newsgroups: comp.sys.mac.programmer Subject: Re: Disinfectant 2.0 Sample Code Message-ID: <40562@think.Think.COM> Date: 12 Jul 90 15:00:43 GMT References: <9510@accuvax.nwu.edu> Sender: news@Think.COM Reply-To: ephraim@think.com (Ephraim Vishniac) Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 56 In article <9510@accuvax.nwu.edu> jln@acns.nwu.edu (John Norstad) writes: >Disinfectant 2.0 has been released to the public - see comp.sys.mac.misc >for details. >I have also released the version 2.0 sample code. All of the code in >Disinfectant except for the virus detection/repair "engine" is available >to the public. Lots of people got the 1.0 sample code - the version 2.0 >stuff is much improved. It's in MPW C 3.1. I've ported the version 2.0 sample code to Think C 4.0. I've got the application itself working, but I haven't actually run the report building tools yet. If you're using Think C, watch for an announcement in a few days and save yourself a hefty amount of aggravation. I'll send the finished port to the usual places (sumex, rascal, the think-c archive @ ics.uci.edu) and maybe John will put up my version alongside his at acns.nwu.edu. Or maybe not - I haven't asked him yet. Aggravating things I found in this port: Think C doesn't define "normal" along with the text styles. OK, so the others are bit settings and normal = no bits set. Fine, I can live with that. Think C doesn't define osEvt, suspendResumeMessage, and other multifinder stuff. At least, not in the header files. If you look really hard, you can find them in CSwitchboard.c, which is a pretty strange place. (No reply from Rich Siegel on this one.) Think C doesn't use the prototype information if you give full prototypes for pointers to procedures. Instead, it attempts to infer the correct calling sequence from the actual parameters, sometimes with bogus results. Rich Siegel tells me that "this non-conformance will be addressed in the next version of the compiler." I don't know if he means 4.03 or 5.0. Equal time: MPW apparently defines the low memory globals as small integers. So, every use of them in John's code looks like this: *(actualType *)lowMemGlobal instead of just plain lowMemGlobal. I can't imagine why MPW does this, except perhaps to discourage the use of low memory globals. MPW does less stringent type checking. For example, it must not complain when you assign between (char *) and (unsigned char *), because John does this a lot. Think C gripes about this if you have pointer type checking turned on, which I always do. -- Ephraim Vishniac ephraim@think.com ThinkingCorp@applelink.apple.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142 One of the flaws in the anarchic bopper society was the ease with which such crazed rumors could spread.