home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.96 / text1526.txt < prev    next >
Encoding:
Text File  |  1996-07-25  |  2.4 KB  |  56 lines
  1. >>>>> "Andreas" == Andreas Sikkema <a.t.sikkema@student.utwente.nl> writes:
  2. In article <314EA718.3FF3@student.utwente.nl> Andreas Sikkema <a.t.sikkema@student.utwente.nl> writes:
  3.  
  4.  
  5.     Andreas> Hi, I'm not that an Executor user, but I have seen it
  6.     Andreas> many times.  Still, I'm interested in all this so I read
  7.     Andreas> this newsgroup alot.
  8.  
  9. We're glad we can hold your interest.
  10.  
  11.     Andreas> My question is, everytime a bug is discovered and Ardi
  12.     Andreas> fixes it, is this bug just removed so that only one
  13.     Andreas> program has been helped or are more structual measures
  14.     Andreas> being taken.
  15.  
  16. It depends on the nature of the bug.  In theory, any time we fix a bug
  17. the fix could help out other programs.  In reality bugs largely fall
  18. into two categories: application specific and penetrating.
  19.  
  20. Application specific "bugs" often are due to applications being
  21. programmed incorrectly, but just happening to work on real Macs.  An
  22. example is a program that calls the OS call "GetTrapAddress" with the
  23. contents of memory location 0xA198 and then calls GetTrapAddress with
  24. the contents of memory location 0xA89F and then compares the two
  25. addresses returned.  This is a bug in the program in question -- they
  26. should be passing the literal values 0xA198 and 0xA89F to the
  27. GetTrapAddress calls, but instead they are passing the contents of
  28. these addresses.  Memory is laid out on a real Mac in such a way that
  29. their incorrect calls still yields values that work.  Executor has
  30. been modified so that the right thing happens under it, too.  If you
  31. don't program a Mac, it won't be obvious that what they're doing is a
  32. bug, but trust me, it is, *and* it's incredibly unlikely that any
  33. other programs are going to have this same bug.
  34.  
  35. Penetrating bugs are ones that potentially affect many programs, such
  36. as Executor using a different algorithm for mapping wdef part codes to
  37. FindWindow result codes.  Once we realize what we were doing wrong we
  38. make the appropriate change and then all the programs that had
  39. problems with our old way of doing things will suddenly work.
  40.  
  41.     Andreas> If not structual measures have been taken, Executor
  42.     Andreas> should grow larger than necessary I think.
  43.  
  44. If I understand what you are saying, you're correct, but we *do* make
  45. structural changes as appropriate.
  46.  
  47.     Andreas> Thanx and keep up the good work
  48.  
  49. Thank you for your interest.
  50.  
  51.     Andreas> Andreas Sikkema a.t.sikkema@student.utwente.nl
  52.  
  53. --Cliff
  54. ctm@ardi.com
  55.  
  56.