home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / mac / programm / 13140 < prev    next >
Encoding:
Text File  |  1992-07-28  |  1.7 KB  |  47 lines
  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!ocsmd!gumby!obi
  3. From: obi@gumby.ocs.com (Kuryan "Obi" Thomas)
  4. Subject: Problem with MPW 32-bit code?
  5. Message-ID: <Bs4wn7.Mnu@gumby.ocs.com>
  6. Sender: obi@gumby (Kuryan "Obi" Thomas)
  7. Reply-To: obi@gumby.ocs.com
  8. Organization: Online Computer Systems, Inc.
  9. Date: Wed, 29 Jul 1992 05:01:55 GMT
  10. Lines: 35
  11.  
  12. I seem to be having a problem with MPW's "32-bit everything" code. Version
  13. numbers are: MPW Shell and C 3.2; C++ 3.1.
  14.  
  15. It looks as though when a CODE segment is unloaded and then loaded later
  16. at a different address, the PC addresses are all screwed up. For example:
  17.  
  18. #pragma segment FooSeg
  19. void Foo::Bar()
  20. {
  21.     AnotherFooProc();   /* this method is also in the FooSeg segment */
  22. }
  23.  
  24. Let's say that a routine in the Main segment unloads the FooSeg segment.
  25. Later, another routine in Main makes an (intersegment) call to Foo::Bar().
  26. This works fine; I end up in the function above. But now comes an
  27. intrasegment call to Foo::AnotherFooProc(), which is also in the FooSeg
  28. segment. The PC skids off into the weeds and I get an illegal instruction
  29. fault. I've traced through this with MacsBug and observed it happen.
  30.  
  31. I'm quite positive that I'm calling UnloadSeg() on the FooSeg segment only
  32. at approved times -- all UnloadSeg()s are in my main event loop, which is
  33. in the Main segment.
  34.  
  35. Absolutely everything in the entire application is compiled with -model
  36. far. (Everything except the MPW libraries, that is.) I am not using
  37. MacApp.
  38.  
  39. Has anyone else succeeded in using UnloadSeg() with the new 32-bit model
  40. in MPW C? Am I doing something wrong here?
  41.  
  42. Please reply by email if you can help. Thank you all in advance.
  43.  
  44.     obi@gumby.ocs.com
  45.     ocsmd!gumby!obi@uunet.uu.net
  46.     ...!uunet!ocsmd!gumby!obi
  47.