gross@umiami.miami.edu (05/28/90)
A friend of mine and me were having another one of our "religious" conversations
about the virtues of the Mac vs. <insert system here>.
Now both of us aren't such zealots that we won't use other machines,
especially if that machine is better suited to do a job than another one.
However, we do have our preferences. Mine is the Mac, his is more PC
oriented. Anyway, we got about to talking about multitasking...and
you know where this is leading. Then he made a very interesting statement...
something like this: Apple is coming up with version 7 of their OS. When
are they going to make it stable enough so that the least little problem
doesn't bring up those system error messages and crash your system.
Here's the meat of the matter: I and my friend would like to know two
things from Apple and from other informed people:
1) Why did Apple decide to go with their version of multitasking instead of
"true" multitasking like even a lowly Amiga 500 can do (and I don't want
arguments that run like 'Well, if you do multitask on an A500, your system
will get real slow...I ain't talking performance..I want to know what
why certain capabilities have been put into a machine)
2) Why does Apple allow these system errors to continue? I can't believe
that after 6.0.5 versions of the OS that they haven't found a better
way to recover from various errors? Is it because everything runs in
supervisor mode? Can't Apple protect certain sections of memory?
I hope someone can answer these...
Thanks!
--
Jason Gross Comp Sci Ugrad University of Miami Class of '91 (?)
===========================================================================
Hey, wanna save the world? | Got sumtin' to say? gross@umiami.bitnet
Nuke a Godless, Communist, | Pick and choose! gross@umiami.miami.edu
gay whale for Christ. | gross@miavax.ir.miami.edu
- Anonymous |
===========================================================================
The University of Miami has a lovely fountain. bskendig@phoenix.Princeton.EDU (Brian Kendig) (05/28/90)
In article <6364.266023a1@umiami.miami.edu> gross@umiami.miami.edu writes: >A friend of mine and me were having another one of our "religious" conversations >about the virtues of the Mac vs. <insert system here>. >Now both of us aren't such zealots that we won't use other machines, >especially if that machine is better suited to do a job than another one. >However, we do have our preferences. Mine is the Mac, his is more PC >oriented. Anyway, we got about to talking about multitasking...and >you know where this is leading. Then he made a very interesting statement... >something like this: Apple is coming up with version 7 of their OS. When >are they going to make it stable enough so that the least little problem >doesn't bring up those system error messages and crash your system. When they release it, of course. You can't expect alpha software to go for long periods of time without running into problems; if it did, then it would be beta or release. And as for the bad system bombs: if you use well-written software, then you shouldn't have problems with system errors. The same goes for any computer. I have an SE that I use all day long, and I haven't had a system error for at least a month and a half now. Another good point: the bomb dialog box has buttons for "Restart" and "Resume", the latter appearing only when the error is recoverable. I'd say this is a pretty stable way of handling errors; certain other itty bitty machines I've used just won't tell you that you've had an error -- the PC just locks up, or starts behaving in very weird ways. What I *would* like to see is another button in the system error dialog box that would attempt to clean up the system heap and abort to the Finder. I can do this about half the time from MacsBug anyway; it would be nice if the computer were to automatically give me this option. >Here's the meat of the matter: I and my friend would like to know two >things from Apple and from other informed people: >1) Why did Apple decide to go with their version of multitasking instead of > "true" multitasking like even a lowly Amiga 500 can do (and I don't want > arguments that run like 'Well, if you do multitask on an A500, your system > will get real slow...I ain't talking performance..I want to know what > why certain capabilities have been put into a machine) The way the Macintosh handles multiple processes (by letting the one in the foreground pretty much have as many cycles as it wants while other applications lie dormant) is fine for my uses. It's different from Unix: if I'm working in my draw program, why should the machine be paying any attention to that word processor and hypertext program over there? >2) Why does Apple allow these system errors to continue? I can't believe > that after 6.0.5 versions of the OS that they haven't found a better > way to recover from various errors? Is it because everything runs in > supervisor mode? Can't Apple protect certain sections of memory? If you can discover the universal method to recovering from system errors, I'll trade you a bridge in Brooklyn for the secret. ;-) >I hope someone can answer these... That'll be five cents, please. << Brian >>
adam@media-lab.MEDIA.MIT.EDU (Adam Glass) (05/28/90)
bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: > gross@umiami.miami.edu writes: >> Apple is coming up with version 7 of their OS. When are they >> going to make it stable enough so that the least little problem >> doesn't bring up those system error messages and crash your system. > > When they release it, of course. You can't expect alpha software to > go for long periods of time without running into problems; if it did, > then it would be beta or release. I doubt that's what he meant. I believe he was asking when they were going to fix the problem with the OS, not the new release. And if you really think that system errors are going to disappear entirely with System 7, you're more than just a little bit naive. > And as for the bad system bombs: if you use well-written software, > then you shouldn't have problems with system errors. That's a good defense. ("The bombs shouldn't be happening in the first place.") Is MacWrite well-written software? It crashes with ATM and Switch-A-Roo. I mean, you can't assume that all software will be written perfectly. There are always going to be conflicts and rare crashes. Saying that the problems shouldn't have occurred in the first place is not a solution. The original poster was looking for a way to recover from the *inevitable* crashes. > What I *would* like to see is another button in the system error > dialog box that would attempt to clean up the system heap and abort to > the Finder. Now that's a good idea. I've found that doing this with MacsBug works more often under MF than it does without MF. Is the RAM cache written out in the event of a crash? The program should in some way be told that it's crashed so that it can do something about it. Even in the case of fatal errors, the application should be able to make a last-ditch effort to save any data that would be lost. > The way the Macintosh handles multiple processes (by letting the one > in the foreground pretty much have as many cycles as it wants while > other applications lie dormant) is fine for my uses. That's great. Just because it's fine for you and you haven't had a crash for a month and a half means that these are non-issues, right? > It's different from Unix No kidding. Unix is true multitasking. > if I'm working in my draw program, why should the machine be paying > any attention to that word processor and hypertext program over there? It should be paying attention, but as word processors basically don't have to do anything unless there's an event, practically speaking it wouldn't be paying attention. And who says we're using multiple programs? What if a game wants to start a process to play a theme? How about a 3D program that could render a complex object (or scene) in the background while you work on a program that doesn't need much CPU power (like a word processor) in the foreground? Adam -- "Fathers and teachers, I ponder 'What is hell?' I maintain it is the suffering of being unable to love." - Dostoyevsky
rcfische@polyslo.CalPoly.EDU (Ray Fischer) (05/29/90)
gross@umiami.miami.edu writes ... >A friend of mine and me were having another one of our "religious" conversations >about the virtues of the Mac vs. <insert system here>. >1) Why did Apple decide to go with their version of multitasking instead of > "true" multitasking like even a lowly Amiga 500 can do (and I don't want > arguments that run like 'Well, if you do multitask on an A500, your system > will get real slow...I ain't talking performance..I want to know what > why certain capabilities have been put into a machine) Pre-emptive multitasking on the Mac would require a major rewrite of large chunks of the ROM code. One example. The menu manager saves the screen under the menu on the stack. With pre-emptive multitasking the screen might change under the menu, thus invalidating the saved screen contents. Thus, the current menu manager wouldn't work too well. The current cooperative multitasking does work passably well; most of the shortcomings affect programmers more than users. >2) Why does Apple allow these system errors to continue? I can't believe > that after 6.0.5 versions of the OS that they haven't found a better > way to recover from various errors? Is it because everything runs in > supervisor mode? Can't Apple protect certain sections of memory? Ever written a perfect program? Neither have I. Bugs exist. Could it be made more robust? Yes. Memory protection would help, but is not a trivial undertaking as it would require many modifications. (how do you protect low memory globals anyway?) It also wouldn't work on the Mac Plus, SE, or portable. Ray Fischer rcfische@polyslo.calpoly.edu
dplatt@coherent.com (Dave Platt) (05/29/90)
In article <2545@media-lab.MEDIA.MIT.EDU> adam@media-lab.media.mit.edu (Adam Glass) writes: > > It's different from Unix > > No kidding. Unix is true multitasking. Sigh. Please... in order to reduce the flame-level which seems to appear whenever this topic arises, it'd help a great deal if people would be willing to avoid the use of the phrase "true multitasking". In this context, "true" is a loaded term... it's terribly suggestive. It's also unnecessary... there are more precise words available for the purpose... I prefer "preemptive" to refer to Unix-style multitasking, and Apple seems to prefer "cooperative" to refer to Mac-style multitasking. It's quite arguable that both of these are "true" multitasking... they both allow two or more tasks to be "alive" on one machine at a time. Based on what Apple has said to date, System 7.0 will be MultiFinder- style multitasking... cooperative (nonpreemptive), with no memory protection. Applications will still have to yield time to one another, and will still be able to step on one another's memory if they're not careful. System 7.0 will be only as robust as 6.0.x when faced with applications that stomp on random areas of memory... sometimes it'll recover with an "Application exited unexpectedly", sometimes it'll bomb. Applications which are _not_ MultiFinder-aware, or are fundamentally incompatible with the MultiFinder environment, won't do at all well under 7.0; I imagine that some will be revised, and others will undergo a Darwinian sort of slow death in the marketplace as the number of 6.0.x (or older) systems dwindles. At some point further down the road (7.x? 8.0?), Apple will probably introduce two new features in the Mac operating system... memory protection, and preemptive multitasking. A memory-protected environment can probably be made compatible with most applications... but many utilities (INITs, etc.) may need to be rewritten to live in the new "thou shalt not mess with the System heap" world. Many applications will probably run quite happily in a preemptive- multitasking environment, too... but I predict that Apple will probably require that preemption-aware applications must set a new flag in their SIZE resources (much like the "MultiFinder aware" bit that's there now). Only applications with this bit set will be preempted; there will probably also be some traps that an application can use to enable and disable preemption. This combination of tweaks will allow applications to yield time more gracefully, while ensuring that those applications which tweak low memory don't get preempted when low memory is in a "dirty" state. When 7.0 arrives, life will become rather interesting... there are probably quite a few popular products which won't work correctly in a virtual-memory environment, and will have to be revised. The same is true of future architectural changes such as protected memory environments and preemptive multitasking. I'm just as happy that not all of these are being dumped on us at once!
mwilkins@jarthur.Claremont.EDU (Mark Wilkins) (05/29/90)
In article <58604@coherent.coherent.com> dplatt@coherent.com (Dave Platt) writes: >When 7.0 arrives, life will become rather interesting... there are >probably quite a few popular products which won't work correctly in a >virtual-memory environment, and will have to be revised. Actually, from my experience with 7.0a9, very, very little is incompatible with virtual memory. The only things which seem to cause trouble are certain types of DMA NuBus cards, some driver INITs which install stuff above BufPtr rather than in the system heap, and some types of software which do screwy things at interrupt time. I have had no difficulty whatsoever with System 7's VM. Now the 32-bit memory manager is another story entirely... -- Mark Wilkins
jeff@eniac.seas.upenn.edu (Jeff White) (05/29/90)
In article <2661ada6.62fa@petunia.CalPoly.EDU> rcfische@polyslo.CalPoly.EDU (Ray Fischer) writes: > > >gross@umiami.miami.edu writes ... >>A friend of mine and me were having another one of our "religious" conversations >>about the virtues of the Mac vs. <insert system here>. >>1) Why did Apple decide to go with their version of multitasking instead of >> "true" multitasking like even a lowly Amiga 500 can do (and I don't want >> arguments that run like 'Well, if you do multitask on an A500, your system >> will get real slow...I ain't talking performance..I want to know what >> why certain capabilities have been put into a machine) > >Pre-emptive multitasking on the Mac would require a major rewrite of >large chunks of the ROM code. (other stuff deleted) I think this is the major point. The present from of multitasking under MultiFinder allowed multitasking capability to work with the majority of applications on all the entire Macintosh line. If a prgram was written properly from the beginning, it didn't take much to make if MF compatible. Just look at OS/2. It was designed to bring (among other things) multiasking to 80x86 (ie. DOS) machines, but for that to happen, you need completely new applications written specifically for it. I don't know if anyone has exact details, but System 8.0 was supposed to be the MAJOR rewrite of the OS for the Mac, so I would hope that true multitasking would appear at least in that version, if not sooner. I guess only the people at Apple who are working on 7.0 now know whether any attempt is being made to write it in a form that would somehow allow true multitasking to be incorporated into it at a future date. Jeff White jeff@eniac.seas.upenn.edu
jeff@eniac.seas.upenn.edu (Jeff White) (05/29/90)
In article <58604@coherent.coherent.com> dplatt@coherent.com (Dave Platt) writes: >When 7.0 arrives, life will become rather interesting... there are >probably quite a few popular products which won't work correctly in a >virtual-memory environment, and will have to be revised. The same is >true of future architectural changes such as protected memory >environments and preemptive multitasking. I'm just as happy that not >all of these are being dumped on us at once! Is 7.0's form of virtual memory much different from the way Connectix does it in their VM init? If I had a piece of software I was concerned about, I think I would at least try it under that first, figuring that if it didn't work right under that, it probably wouldn't work under 7.0 either, and that some rewrite was in order. Jeff White jeff@eniac.seas.upenn.edu
edgar@shape.mps.ohio-state.edu (Gerald Edgar) (05/29/90)
In article <7307@jarthur.Claremont.EDU> mwilkins@jarthur.Claremont.EDU (Mark Wilkins) writes: >In article <58604@coherent.coherent.com> dplatt@coherent.com (Dave Platt) writes: > I have had no difficulty whatsoever with >System 7's VM. Is it better than Virtual? I know of 3 programs that fail whan Virtual is set above 8 megabytes. -- Gerald A. Edgar Department of Mathematics Bitnet: EDGAR@OHSTPY The Ohio State University Internet: edgar@mps.ohio-state.edu Columbus, OH 43210 ...!{att,pyramid}!osu-cis!shape.mps.ohio-state.edu!edgar
steve@uswmrg2.UUCP (Steve Martin) (05/29/90)
In article <58604@coherent.coherent.com> dplatt@coherent.com (Dave Platt) writes: >When 7.0 arrives, life will become rather interesting... there are >probably quite a few popular products which won't work correctly in a >virtual-memory environment, and will have to be revised. The same is >true of future architectural changes such as protected memory >environments and preemptive multitasking. I'm just as happy that not >all of these are being dumped on us at once! Actually this brings up a very interesting point. How many people are currently using VM on their Macs? I am using Virtual '030 on my IIcx and have found no instances of software that crashes. I often use: Excel 2.2 Word 4.0 MacProject II MPW 3.01 ThinkC 4.06 NCSA Telnet 2.3 White Knight 11.06 And a host of utilities and INITs running under System 6.0.5. Has anyone ran into an application that does not work under VM? Why don't we start a list now and see what might create problems when 7.0 comes out! -- Steve Martin | Nothing I say can be held against U S West Marketing Resources Group | Me or my employer! (...!rutgers!bellcore!uswat!uswmrg2!steve)
philip@Kermit.Stanford.EDU (Philip Machanick) (05/30/90)
In article <58604@coherent.coherent.com>, dplatt@coherent.com (Dave Platt) writes: > Many applications will probably run quite happily in a preemptive- > multitasking environment, too... but I predict that Apple will probably > require that preemption-aware applications must set a new flag in their > SIZE resources (much like the "MultiFinder aware" bit that's there now). > Only applications with this bit set will be preempted; there will > probably also be some traps that an application can use to enable and > disable preemption. This combination of tweaks will allow applications > to yield time more gracefully, while ensuring that those applications > which tweak low memory don't get preempted when low memory is in a > "dirty" state. Yet another hack. Apple have already shown how to implement compatibility for old applications while introducing pre-emptive multitasking. It's called A/UX. I don't think unix is the right route to go for a mass-market system, but the principle still applies. My prediction: System 8 will have protection, one address space per application, controlled sharing through shared pages, pre-emptive multi-tasking etc. - and System 7 running in a compatability box. Oh yes, and probably on a RISC processor, emulating the 680x0 in software. Philip Machanick philip@pescadero.stanford.edu
lim@iris.ucdavis.edu (Lloyd Lim) (05/30/90)
In article <6364.266023a1@umiami.miami.edu> gross@umiami.miami.edu writes: >[...] Apple is coming up with version 7 of their OS. When >are they going to make it stable enough so that the least little problem >doesn't bring up those system error messages and crash your system. Actually, it's not too bad right now. As most developers know, if you are running a debugger with MultiFinder and a System error occurs, you can exit to the Finder without affecting other applications for most errors. This isn't totally reliable though. >Here's the meat of the matter: I and my friend would like to know two >things from Apple and from other informed people: These two questions are like asking something like: Cars that run on methane are better than cars that run on gasoline. Why doesn't Ford start making all their 1990 cars run on methane? (Methane is just some example - I don't know what fuels are good.) >1) Why did Apple decide to go with their version of multitasking instead of > "true" multitasking like even a lowly Amiga 500 can do (and I don't want > arguments that run like 'Well, if you do multitask on an A500, your system > will get real slow...I ain't talking performance..I want to know what > why certain capabilities have been put into a machine) Compatibility. The Mac OS started out as non-multitasking system and there are many things in it that need to be cleaned up before true multitasking can take place. Multitasking operating systems usually are written from the ground up. Actually, it's pretty impressive that they were able to pull off the kind of multitasking that occurs with MultiFinder. There's a lot of stuff that goes on behind your back... >2) Why does Apple allow these system errors to continue? I can't believe > that after 6.0.5 versions of the OS that they haven't found a better > way to recover from various errors? Is it because everything runs in > supervisor mode? Can't Apple protect certain sections of memory? Most system errors occur when an application fails to handle some situation correctly. The first place to blame is the person who wrote the application. The next best thing, like you said, is to have the OS recover from these errors without affecting other applications. The way everything is currently set up, applications share some things so you can't be sure everything is ok after an error. The usual way to handle this is to isolate the OS and have applications access the OS through routines. Then you can run in supervisor mode for the OS and user mode for applications and possibly have memory protection. The newer Systems seem to be heading this way but there is a lot of old stuff to clean up (e.g. - low memory, direct access to the System heap). Apple has managed to push developers away from some bad practices already. Not many applications write directly to the screen these days, which makes MultiFinder and multiple connected monitors of different bit depths possible. Interestingly, when the Mac started out, it forced developers to access the OS through routines (the Toolbox) more than any other computer. The rules were not as firm then but Apple has been making them firmer and life harder for developers who don't follow them. So far this has given the Mac remarkable consistency between applications, the ability to run on very different machines, and to have neat things like multiple screen desktops and international Systems work for most applications. Now the Mac is being compared to things like NeXT and OS/2 which were written from the ground up. The Mac has been heading that way for a while but it takes time to push the software mass and there are other features Apple wants to add also. Look at how developers are worried over System 7.0. I'd say you probably won't see true multitasking until there is a low cost 68030 Mac and developers have been pushed more in the right direction with more System versions. Maybe not until System 9.0 which might take about three years on the bright side. :-( I don't mean to say the Mac is perfect, Apple knows what it's doing all the time (Apple has done some pretty bone-headed things), and developers are bad (we just need guidance and alternatives), but I thought I'd try to explain how things were and why things don't happen now (as I see it that is, of course you may disagree). I too would like to see the day when my file transfer in the background doesn't timeout when I'm looking at some menu in the foreground application. +++ Lloyd Lim Internet: lim@iris.ucdavis.edu (128.120.57.20) Compuserve: 72647,660 US Mail: 146 Lysle Leach Hall, U.C. Davis, Davis, CA 95616
mwilkins@jarthur.Claremont.EDU (Mark Wilkins) (05/30/90)
In article <1990May29.144632.25946@uswmrg2.UUCP> steve@uswmrg2.UUCP (Steve Martin) writes: >ThinkC 4.06 4.06? Is this a typo? If not, how can I update? >And a host of utilities and INITs running under System 6.0.5. Has anyone >ran into an application that does not work under VM? Why don't we start >a list now and see what might create problems when 7.0 comes out! Well, the version of the Hewlett Packard DeskWriter driver which was current as of last fall failed completely under Virtual 2.0. It would print an error message and quit instead of printing the document. -- Mark Wilkins
edgar@shape.mps.ohio-state.edu (Gerald Edgar) (05/30/90)
* Programs I have found that do not run when Virtual is set above 8 megabytes.
Coral Object Logo, version 2.0
Allegro Common Lisp (probably for the same reason)
The "Flips" DA, included in the disk "Letterforms and Illusion", by
Scott Kim, published by Freeman.
-----
Gerald A. Edgar
Department of Mathematics Bitnet: EDGA@HSTPY
The Ohio State Univesty Internet: edgar@mps.ohio-state.edu
Columbus, OH 43210 ...!{att,pyramid}!osu-cis!shape.mps.ohio-state.edu!edgar
--
Gerald A. Edgar
Department of Mathematics Bitnet: EDGAR@OHSTPY
The Ohio State University Internet: edgar@mps.ohio-state.edu
Columbus, OH 43210 ...!{att,pyramid}!osu-cis!shape.mps.ohio-state.edu!edgarblood@aludra.usc.edu (Brian Blood) (06/05/90)
From blood Tue Jun 5 00:15:34 1990
To: /home/chaph9/blood/.article
Subject: Crashsaver/P Key
The following Binhex file contains the combination Crashsaver INIT and P Key.
Crashsaver obviously gets loaded first and it sets up so that when the Interrupt
button gets pressed, an ExitToShell() call is given. P Key sets up so that when
you press command and the Power key (no matter what machine) are pressed, it is
the functional equivalent of press of the interrupt button is done. All this
trickery, smoke and mirrors will get you out of 60-70 % of system bombs. It will
also allow you to get out of a program that you do not want to be in but can't
get control of. I personally have these and Macsbug running so I pretty much covered.
Remember that when a system bomb occurs, the memory is now on shaky ground and n
othing is to be trusted, so save what you can and restart your machine!
Merry X-Mas!
(This file must be converted with BinHex 4.0)
:"Q9c,R0TG!"6593K8dP8)3!!!!!*BJ!!!!!Fh90*9#%!!`!!#@*b6'&e!3!!!!!
!!!!#!!p$FQ&cD&0KGQ9b)%PZDA3Z8%P$9!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!"*6NP83e0"9L%!R+I93*f0bTd!!!-X!!!!!!!
!!C8!!!!!%X%!!!!!!!!!!*0H!!!%#!K!`+H!!3i'E%5`SF1(%#%q'#)Rc"`d8m,
B+5-(4")hDHJ))*M%54)U3kB%X4)L)+f!*8qQA0N5`%XY!$+mQ"(a)DG6eB!m(-#
LTp'M5*-UAFUd+G-$-DNmj$$6#X%!5BBi'H%3N!!4+8@-G#8S"Bb#J%D@&-N#S%"
!*1IJi32"Jk#%8Kj#)!-!4bm!1Rlaq18M!NN3I3!Jd,8,bJ@6EamH1+NMi!UqIiF
")(L"T+#618lLT+)AHM6"#K8S@N3$)Z2'MP&"a(!"!`C#L!332"3!)D$3J"&q%`J
i!*!!#J!-rJ$5$!#%CJ+3!!$iBHi(!L(T#2m"!M6J(c!!"rk"!r$J(ccbjJ&mq)G
(r6pmlR(&RlmHI[Rc$rUG$cqqqrF!fJ8dR82r&'MJJ3JQU1##$$ESi)-34LMKJVF
&C""##J(!N!!!E'!5J"i%F3#!)!!3m&9B"+NJK"0%-%'3!!e4%54%935CT"9A!H%
%5)%plIJ233X8Y-eb!b8@d!T#`K)3M`%&8K!fk!$J)d'E&*30!JUSGT&V(!%#!!9
3)%YPH90KGQ9b)%PZDA3Z8%P$9!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!"*6NP8384#BL%!R9`%%jj8QiX!!!I#!!!!!!!!"3-!!!!
!Bm)!!!!!!!!!!"6f!!!%#!MJ!)D!"Ji'9!AL9UK#"#-5&)!J)-9r'$0Ua&J!#SJ
PCI)))*M%54)U3BJ)%4-L)$F!@L3@L9MbC-U9,3'mM!PJ351*3!PfiN*J!Y!$`MB
UAFUdUG1R8+0+R8T9Bm#"3E0UhFUe+m%r'2d"#cJ!%!`'!3$KmC!!PJH2!)%mi3N
Jk"'m!)31J3Z!D"!`[(VTfS8VYqeEY@c0SKd,B!$BIrkm5Tj-1H"MIe8cDeCkq@V
Pck#$AQCFpLSJdeF$RDDlQY"U4+eA#eUY@Z"TfkJ&NZiFZ[IRbjZ$DqB0J-00-33
$*"RLC)4%3%DN&$(bR1#"QP5!AV%#4FkE-h,#Y'P64Xk*14p$JJ#4+NB1($GBJ)$
L!N56mQ2+0aMbCMcq0''`!3)CDFa"KaaTL&%((@Qmi3B)BZ3"!KYTj1I'('@!i#!
EH64J4APc02KJ$#l%3"!""c``J!&Nq3''&GJ&Y%&hhiARRhRSJ53KL6%)-F0k,Dc
h!3T$T!##Hr$*Kb31mi94Ki$hbC'I(%#Z0d%3E!L)i"PSd)'H('9J+)FGCC!!%BC
!UMKKa6rJ)((1"ckF'B!'CPJJ*`pQ32!$$`!!)UFS6(c$"cj1H1&%(AX#%)LFNS$
KcJX)r!$!$`%)%833qZJ%!3B5B)!T!0JS!F%C'S#!"`2i-)!#!#-&B%C!G)#!"J!
)B)%)!UJ8"-!$3H!6!"d"`!)"!'G`J3!1"3@JaaNk(([9(QF`i+`!!Hca+J"HJ-'
%X`08HkdHcJUNal9`))",XRV)m!%-(i$`a3[)mR(SY0@H)B'jV&DV,V[Z[U!$YSI
ZfqklrcTaU")i$!#''HiN+J!UPB$K$m)+Q`%1`JM)BiB$3Tb5#K-`m!'!!U$Xd2(
()32J3FQ*"J#aa+B+i)S6F$L"cXLI)4b!('Ti%+kh&MLV`!)LQ#%!'!KJqSmf%2!
L%"`!(!T(!)Gfr!)2ab8+5#UJJ2$"'8D!!-4m3qMc$be+4&$f2kSB638L-N#L0#S
JR%Z'dU68$3!I)2!CN!!pTAKJ"JBL)%%#%TMk`dRI"0N$LJXK*!-!'8)!)6A9G6!
!L"Ye6*'%'8PRLN$6!KdDN!$5r)JDEGp[V&&''6+m!!!"B$$`Jq`%*)U#%lV3kLi
96cJ"MCS"[E#!e6`Xep`2,Sc-YGGRV!F%+#QBJ-3,HMD2!1m!82!4+#T!QXSS*Ra
4U!ZI(!U'2@Vk`iUE2h!!E`)%,1(12rb%d!cp5,Ma$ckSF%2rh)H+0m!!"`PJ`6L
`S!!J3#!%X-"$!Pa`"J``!"G3F")E&)#(-b!J"[bJ93,"B)!Bi%-"INKJ%0cK2KL
XLJ%%!!)!8)!%)"``J5d!`Mp-N!$$IkM!!'i!!!Mq`3)J#Y'(*JLL!X*!JaZb3!E
D8`-"C-!R&%!M#$%!4J)Af-!(CR'#!f3&+[S3JQr3,e!ii%HKh-@&4`J[#II$!!S
@B3"+%!3314!C!@BR"&B!`!!T%"N)K$Lb&c#J##amRaTBK33p!)!&rGYKSJE3-95
`J`"f$!JJ$)Q%43UJN3#!3#40d,*+XX0d%4RN)!9L(B8NK##U!-!-5J'$"E!S)"`
!J#CQTccR$%3&3R!#%CK!%#&%CcS%FF*a@+Q&'!9%$SV##!NL-J05`+02dK6)(U[
*$QcqBj!!&(N14X#j+SQ-Ne8cU!i!TLN!4mL5&$FEb!(!DBPhJX-!Bh#3!"R5i-'
E#!&-B9J$!!-+8#",CANJ5@jQEh0VG'p`,P"*3e3!!!!!!Irr!!B!1AG'!#LG%!!
PC!B!+3Dm!4)!&`%!!4)!&`!!!!!!+*dU9%9B9%e"3d%!!*rUhbQIkZ%X!!!!!!!
!!I3!!!!!!!!"C!!!X"8!!!!!!!$jk#3&[ZCE,EG!XPeZ36'KU65a3D%U961UNmS
*6,%cQkdK4++T90+G9&UZd0&jYb`V3X9R@8@ZlTG8#ah!R&Q,a1CD8VT5ZSk%9iR
Pjcaf"-P4F+NmGMFQTJD8dIC6I1QYk4I0RqEHV`,ch+Ejde[6@P+IB+(UK8eirbY
dDi82lq9qZP$qrRiHp4BA2TqG*rP3aK0YqcU6bp0hk(UmSSe[6mYTK#b[0YdAXQ6
GJCEjf9i6,-HV`,cf8q`-je-*%L[$lDFq4QHbl-%9jR+Tl6cdRMX#C-*'5VZ0BTi
l'j06$eHA++Z3!*6k@FYN`NC&`Vmdr8C$T0CJClq12C['%L6fj%FqcbVE1mIEVcf
8q`Dc!SSeZX`20Q-))Db8X[dc(kjV-$f8qard8Dh@BIpAYEpFmfB`JKUmUZAR,Y&
A0+@r6#40Y30V12Ya5br6-IVQX`+VPjcaf&%b2YejpP0mkDhTV&&mfIjYk-KJ!!!:
+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/Brian Blood
INTERNET: blood@usc.edu Business Hours: 20/24 daily
Disclaimer: 'Vuja De'--None of this has ever happened!
SnailMail: 333 Prestonwood Dr #2506 AT&TLink: (214)907-2943
Richardson, TX 75081
'Pain don't hurt'-'Roadhouse' 'We don't need no stinkin' badges!'-BS
+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/+-*/