home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 4 / Apprentice-Release4.iso / Information / Digests / CSMP Digest / volume 3 / csmp-digest-v3-054 / doubleCR.1 < prev   
Encoding:
Text File  |  1995-12-31  |  87.1 KB  |  2,362 lines

  1. C.S.M.P. Digest             Wed, 07 Sep 94       Volume 3 : Issue 54
  2.  
  3. Today's Topics:
  4.  
  5.         How to use AESuspendTheCurrentEvent?
  6.         Learning Macintosh Programming
  7.         Should function order be conserved? (CW vs. GestaltValue)
  8.         Sound Manager headaches (again)
  9.         Stopping a 'snd ' resource dead
  10.         [Q] What does "_Xxxxx ,Sys,Immed" mean?
  11.         jGNE from an INIT
  12.  
  13.  
  14.  
  15. The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
  16. (pottier@clipper.ens.fr).
  17.  
  18. The digest is a collection of article threads from the internet newsgroup
  19. comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
  20. regularly and want an archive of the discussions.  If you don't know what a
  21. newsgroup is, you probably don't have access to it.  Ask your systems
  22. administrator(s) for details.  If you don't have access to news, you may
  23. still be able to post messages to the group by using a mail server like
  24. anon.penet.fi (mail help@anon.penet.fi for more information).
  25.  
  26. Each issue of the digest contains one or more sets of articles (called
  27. threads), with each set corresponding to a 'discussion' of a particular
  28. subject.  The articles are not edited; all articles included in this digest
  29. are in their original posted form (as received by our news server at
  30. nef.ens.fr).  Article threads are not added to the digest until the last
  31. article added to the thread is at least two weeks old (this is to ensure that
  32. the thread is dead before adding it to the digest).  Article threads that
  33. consist of only one message are generally not included in the digest.
  34.  
  35. The digest is officially distributed by two means, by email and ftp.
  36.  
  37. If you want to receive the digest by mail, send email to listserv@ens.fr
  38. with no subject and one of the following commands as body:
  39.     help                        Sends you a summary of commands
  40.     subscribe csmp-digest Your Name    Adds you to the mailing list
  41.     signoff csmp-digest            Removes you from the list
  42. Once you have subscribed, you will automatically receive each new
  43. issue as it is created.
  44.  
  45. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
  46. Questions related to the ftp site should be directed to
  47. scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP
  48. digest are available there.
  49.  
  50. Also, the digests are available to WAIS users.  To search back issues
  51. with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
  52. http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.
  53.  
  54.  
  55. -------------------------------------------------------
  56.  
  57. >From phaedrus@chinook.halcyon.com (Mark Phaedrus)
  58. Subject: How to use AESuspendTheCurrentEvent?
  59. Date: 19 Aug 1994 21:44:57 GMT
  60. Organization: NWNEXUS, Inc. - Making Internet Easy
  61.  
  62.      Could someone please post some brief sample code showing the correct use
  63. of AESuspendTheCurrentEvent and AEResumeTheCurrentEvent?
  64.      Basically, this is what I'm doing right now:
  65.  
  66. AppleEvent *pendingEvent,*pendingReply;
  67. OSErr err;
  68.  
  69. pascal OSErr MyEventHandler(AppleEvent *messagein, AppleEvent *reply,
  70.                             long refcon)
  71. {
  72.    /* make sure we're allowed to put up a window */
  73.    if (noErr != (err = AEInteractWithUser(kMyTimeoutTicks,nil,nil)))
  74.         return err;
  75.    /* assorted code to display the window deleted */
  76.    /* keep track of these events for later */
  77.    pendingEvent = messagein;
  78.    pendingReply = reply;
  79.    /* we'll wait for the user to do something that triggers a response */
  80.    if (noErr != (err = AESuspendTheCurrentEvent(messagein)))
  81.        return err;
  82.    return noErr;
  83. }
  84.  
  85. pascal OSErr MyEventCompletion(AppleEvent *messagein,AppleEvent *reply,
  86.                                long refcon)
  87. {
  88.      AEPutParamPtr(reply,keyAEResult,typeChar,(Ptr)myStuff,strlen(myStuff));
  89.      return noErr;
  90. }
  91.  
  92. void CodeCalledWhenReadyToFinish(void)
  93. {
  94.    err = AEResumeTheCurrentEvent(pendingEvent,pendingReply,MyEventCompletion,
  95.                                  0);
  96. }
  97.  
  98.     When the event handler is called, AESuspendTheCurrentEvent returns noErr,
  99. and the event is apparently suspended correctly; at least, the caller never
  100. gets a reply, even though the event handler returns.  The problem is that the
  101. event and reply records seem to be getting disposed immediately; pendingEvent
  102. and pendingReply are pointing at garbage when CodeCalledWhenReadyToFinish is
  103. called, and as a result AEResumeTheCurrentEvent fails miserably.
  104.     Any help you can give is gratefully appreciated...
  105.  
  106.  
  107. --
  108. \o\   If you're interested in books/stories with transformation    \o\
  109.  \o\themes, or in furry/anthropomorphic art, email me, or anonymous-\o\
  110.   \o\ftp to ftp.halcyon.com and check the /local/phaedrus directory. \o\
  111.    \o\ Web users:  Now try http://www.halcyon.com/phaedrus/Menu.html  \o\
  112.  
  113. +++++++++++++++++++++++++++
  114.  
  115. >From hanrek@cts.com (Mark Hanrek)
  116. Date: 22 Aug 1994 04:54:34 GMT
  117. Organization: The Information Workshop
  118.  
  119. In article <33394p$cs5@news.halcyon.com>, phaedrus@chinook.halcyon.com
  120. (Mark Phaedrus) wrote:
  121.  
  122. >      Could someone please post some brief sample code showing the correct use
  123. > of AESuspendTheCurrentEvent and AEResumeTheCurrentEvent?
  124. >      Basically, this is what I'm doing right now:
  125.  
  126. There is some example source code called "SuspendAppleEvent" that will
  127. hopefully help.
  128.  
  129. You will find under "Inter-Application Communication" within the Snippets
  130. collection.  It is on the Developer CD and hopefully available at
  131. ftp://ftp.apple.com/ as well.
  132.  
  133. Mark Hanrek
  134.  
  135. +++++++++++++++++++++++++++
  136.  
  137. >From bb@lightside.com (Bob Bradley)
  138. Date: Sun, 21 Aug 1994 04:13:05 -0800
  139. Organization: SS Software Inc.
  140.  
  141. I don't have a question of how to use AESuspendTheCurrentEvent but,
  142. whether I should use it. When I receive an OpenDoc event, I put up a
  143. dialog and the files attached to the OpenDoc event do not get processed
  144. until the user hits ok in the dialog (or cancel which would not process
  145. the documents at all). Should I suspend the OpenDoc event and resume when
  146. (or if) the user chooses ok in the dialog or should I just let the
  147. AppleEvent return and process the documents when the user wants?
  148.  
  149. IM Interapp Comm says the AppleEvent Manager expects the event to have
  150. been processed when the handler returns which it wouldn't have been in my
  151. case and I'm not sure if I should call AESuspendTheCurrentEvent (and
  152. resume it later). It works fine though.
  153.  
  154. +++++++++++++++++++++++++++
  155.  
  156. >From paul@architecture.mcgill.ca (Paul Lalonde)
  157. Date: Tue, 23 Aug 1994 02:28:45 GMT
  158. Organization: McGill University School of Architecture
  159.  
  160. In article <33394p$cs5@news.halcyon.com>, phaedrus@chinook.halcyon.com
  161. (Mark Phaedrus) wrote:
  162.  
  163. >      Could someone please post some brief sample code showing the correct use
  164. > of AESuspendTheCurrentEvent and AEResumeTheCurrentEvent?
  165. >      Basically, this is what I'm doing right now:
  166.  
  167. > [ stuff deleted ]
  168.  
  169. You have to save the actual event and reply records, not just pointers to 
  170. them.  So a revised version of the snippet you posted would look like this:
  171.  
  172. AppleEvent pendingEvent,pendingReply;
  173.  
  174. pascal OSErr MyEventHandler(AppleEvent *messagein, AppleEvent *reply,
  175.                             long refcon)
  176. {
  177.    /* stuff deleted */
  178.    pendingEvent = *messagein;
  179.    pendingReply = *reply;
  180.    /* more stuff deleted */
  181.    return noErr;
  182. }
  183.  
  184. void CodeCalledWhenReadyToFinish(void)
  185. {
  186.    err = AEResumeTheCurrentEvent(&pendingEvent,&pendingReply,
  187.                                  MyEventCompletion,0);
  188. }
  189.  
  190.  
  191. Hope this helps,
  192.  
  193. Paul Lalonde
  194. paul@architecture.mcgill.ca
  195.  
  196. ---------------------------
  197.  
  198. >From dchakrav@netserv.unmc.edu (Dhruba Chakravarti)
  199. Subject: Learning Macintosh Programming
  200. Date: 19 Aug 1994 11:23:44 -0500
  201. Organization: University of Nebraska Medical Center, Omaha, NE, USA
  202.  
  203. I do not know anything about programming, which should be obvious
  204. from the header.  I have a Macintosh computer and would like to
  205. learn programming for Macintosh.  Please advise me.
  206.  
  207. Regards,
  208.  
  209. Dhruba.
  210.  
  211.  
  212. +++++++++++++++++++++++++++
  213.  
  214. >From mathews@ns9000.furman.edu (Owen Mathews)
  215. Date: 19 Aug 1994 18:50:13 GMT
  216. Organization: furman university computing center
  217.  
  218. Dhruba Chakravarti (dchakrav@netserv.unmc.edu) wrote:
  219. : I do not know anything about programming, which should be obvious
  220. : from the header.  I have a Macintosh computer and would like to
  221. : learn programming for Macintosh.  Please advise me.
  222.  
  223. : Regards,
  224.  
  225. : Dhruba.
  226.  
  227. If you're programming in Pascal, pick up the
  228.  
  229.     -Macintosh Pascal Programming Primer
  230.      by Dave Mark and ??? Reed (something like that)
  231.     **good introductory Mac book; teaches all about the Toolbox
  232.     and Mac programming fundamentals; comes with several well-thought-out
  233.     example programs to get you started
  234.  
  235. If you're using C, then try
  236.  
  237.     -Macintosh C Programming Primer
  238.      same fellow(s?)
  239.     **I haven't see this one, but I assume it's the same idea.
  240.  
  241. If you're really ambitious, take a look at
  242.  
  243.     -Learn C++ on the Macintosh
  244.      guess who?  (I'm a real admirer of this guy)
  245.     **Also probably the same basic idea.
  246.  
  247. No matter which language you use, you'll eventually want to invest in
  248.  
  249.     -Inside Macintosh
  250.      Apple Computer
  251.     **This set of reference books is the ultimate authority on all
  252.     aspects of Mac programming.  It comes in two flavors:  Old Inside Mac
  253.     (IM) and New IM (NIM).  Old IM comes in 6 volumes that are organized
  254.     chronologically.  This unfortunately means that certain related material
  255.     can be spread out over multiple volumes, forcing you to spend extra
  256.     time to find the right volume.  NIM groups material logically by
  257.     subject.  Each volume covers some clearly-defined area of the Mac API.
  258.     Of course, NIM's disadvantage is that when Apple releases new stuff,
  259.     you can't go and pick up the next chronological volume -- instead,
  260.     you'll probably have to go and buy half a dozen updates to the subject
  261.     volumes.
  262.     But I'm rambling.
  263.  
  264. Hey, don't let all that talk daunt you.  With any of the first three books,
  265. you can get started programming quickly and produce your first (albeit ultra-
  266. simple) Mac application within an hour or two.
  267.  
  268. Hope this helps!
  269.  
  270. --
  271.        Owen Mathews    mathews@furman.edu
  272.        <><><><><><><><><><><><><><><><><><><><>
  273.        Furman University, Computer Science Dept
  274.  
  275. +++++++++++++++++++++++++++
  276.  
  277. >From dchakrav@netserv.unmc.edu (Dhruba Chakravarti)
  278. Date: 19 Aug 1994 17:17:42 -0500
  279. Organization: University of Nebraska Medical Center, Omaha, NE, USA
  280.  
  281. Owen Mathews (mathews@ns9000.furman.edu) wrote:
  282. : Dhruba Chakravarti (dchakrav@netserv.unmc.edu) wrote:
  283. : : I do not know anything about programming, which should be obvious
  284. : : from the header.  I have a Macintosh computer and would like to
  285. : : learn programming for Macintosh.  Please advise me.
  286.  
  287. : : Regards,
  288.  
  289. : : Dhruba.
  290.  
  291. : If you're programming in Pascal, pick up the
  292.  
  293. :     -Macintosh Pascal Programming Primer
  294. :      by Dave Mark and ??? Reed (something like that)
  295. :     **good introductory Mac book; teaches all about the Toolbox
  296. :     and Mac programming fundamentals; comes with several well-thought-out
  297. :     example programs to get you started
  298.  
  299. : If you're using C, then try
  300.  
  301. :     -Macintosh C Programming Primer
  302. :      same fellow(s?)
  303. :     **I haven't see this one, but I assume it's the same idea.
  304.  
  305. : If you're really ambitious, take a look at
  306.  
  307. :     -Learn C++ on the Macintosh
  308. :      guess who?  (I'm a real admirer of this guy)
  309. :     **Also probably the same basic idea.
  310.  
  311. : No matter which language you use, you'll eventually want to invest in
  312.  
  313. :     -Inside Macintosh
  314. :      Apple Computer
  315. :     **This set of reference books is the ultimate authority on all
  316. :     aspects of Mac programming.  It comes in two flavors:  Old Inside Mac
  317. :     (IM) and New IM (NIM).  Old IM comes in 6 volumes that are organized
  318. :     chronologically.  This unfortunately means that certain related material
  319. :     can be spread out over multiple volumes, forcing you to spend extra
  320. :     time to find the right volume.  NIM groups material logically by
  321. :     subject.  Each volume covers some clearly-defined area of the Mac API.
  322. :     Of course, NIM's disadvantage is that when Apple releases new stuff,
  323. :     you can't go and pick up the next chronological volume -- instead,
  324. :     you'll probably have to go and buy half a dozen updates to the subject
  325. :     volumes.
  326. :     But I'm rambling.
  327.  
  328. : Hey, don't let all that talk daunt you.  With any of the first three books,
  329. : you can get started programming quickly and produce your first (albeit ultra-
  330. : simple) Mac application within an hour or two.
  331.  
  332. : Hope this helps!
  333.  
  334. : --
  335. :        Owen Mathews    mathews@furman.edu
  336. :        <><><><><><><><><><><><><><><><><><><><>
  337. :        Furman University, Computer Science Dept
  338.  
  339. Thank you very much!  I'll get these books and start reading.
  340.  
  341. Regards,
  342.  
  343. Dhruba.
  344.  
  345.  
  346. +++++++++++++++++++++++++++
  347.  
  348. >From Chris Kueny <yun@fusion.ph.utexas.edu>
  349. Date: 19 Aug 1994 23:37:21 GMT
  350. Organization: The University of Texas at Austin, Austin, Texas
  351.  
  352. In article <332mag$2jq@netserv.unmc.edu> Dhruba Chakravarti,
  353. dchakrav@netserv.unmc.edu writes:
  354.  
  355. >I do not know anything about programming, which should be obvious
  356. >from the header.  I have a Macintosh computer and would like to
  357. >learn programming for Macintosh.  Please advise me.
  358.  
  359. The C Programming Primer by Dave Mark assumes that you
  360. know something about the C programming language (and I 
  361. assume that the Pascal Programming Primer assumes knowledge
  362. of Pascal.) Another good book at this level is Dan Parks Sydow's
  363. "Macintosh Programming Techniques".
  364.  
  365. But if you have no programming experience at all, then a good
  366. one to start with is "Learn C on the Macintosh" by Dave Mark.
  367. This has a stripped down version of Symantec's Think C compiler
  368. that can be used to run the projects in the book. It will give you
  369. an introduction to the C language, but won't tell you everything.
  370. It has a good explanation of programming concepts for people
  371. who have never done such things before. As mentioned above,
  372. Dave also wrote "Learn C++ on the Macintosh".
  373.  
  374. A classic reference for the whole C language is "The C Programming
  375. Language" by Kernighan & Ritchie.
  376.  
  377. I don't have much knowledge of Pascal. I think I heard someone
  378. say that it is easier for a beginner to learn Pascal than to learn C.
  379.  
  380. Eventually you will have to buy a compiler. C and Pascal compilers
  381. are available at good discounts for university and college students
  382. and staff (maybe younger students too?) Used ones are also
  383. sometimes advertised in this newsgroup.
  384.  
  385. +++++++++++++++++++++++++++
  386.  
  387. >From millsp@govonca.gov.on.ca (Phil Mills)
  388. Date: Sat, 20 Aug 1994 13:05:05 GMT
  389. Organization: Government of Ontario
  390.  
  391. In <332mag$2jq@netserv.unmc.edu> dchakrav@netserv.unmc.edu (Dhruba Chakravarti) writes:
  392.  
  393. >I do not know anything about programming, which should be obvious
  394. >from the header.  I have a Macintosh computer and would like to
  395. >learn programming for Macintosh.  Please advise me.
  396.  
  397. 1) Decide why you want to program and what kind of program you would
  398. like to create.  The best choice in tools and information sources will
  399. change depending on that decision.
  400.  
  401. (Without an answer to #1, there *is* no item #2.  :-)  )
  402.  
  403. +++++++++++++++++++++++++++
  404.  
  405. >From kenlong@netcom.com (Ken Long)
  406. Date: Sat, 20 Aug 1994 16:52:14 GMT
  407. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  408.  
  409. Learn C on the Macintosh is NOT a good book for someone who has no 
  410. programming or Mac programming experience.  It contains LITTLE about what 
  411. new Mac programmers are interested in.
  412.  
  413. Think THINK C!, by Dan Parks Sydow is THE book to start with.  It teaches 
  414. new Mac programmers about aspects of Mac programming they WANT to know about.
  415.  
  416. -Ken-
  417.  
  418. +++++++++++++++++++++++++++
  419.  
  420. >From silicon@Simplex.NL (Silicon Island Software)
  421. Date: 21 Aug 1994 08:28:13 GMT
  422. Organization: Simplex Networking Amsterdam, The Netherlands.
  423.  
  424. Dhruba Chakravarti (dchakrav@netserv.unmc.edu) wrote:
  425. : I do not know anything about programming, which should be obvious
  426. : from the header.  I have a Macintosh computer and would like to
  427. : learn programming for Macintosh.  Please advise me.
  428.  
  429.  
  430. Why Visual EzC is good for learning Macintosh programming.
  431.  
  432. When you program in EzC, the Layouts of the applications with
  433. their interface elements are all created graphically in a MacDraw
  434. like Layout Editor. The process has little if anything to do with
  435. programming. 
  436.  
  437. The Menus of the application are also created in a graphic editor
  438. by simply adding menus and menu items in a list.
  439.  
  440. The EzC program code is a C-like code, with all the basic syntax
  441. and functionality the same as in normal C.
  442.  
  443. There is admittedly nothing new about creating layouts and
  444. menus graphically. - The available 4GL languages all do that, each
  445. in their own way. What is new though is, that EzC has a very
  446. powerful and well known programming language, and the EzC
  447. code can be pre-compiled into C, simply by selecting Precompile
  448. from the menu. The resulting C code can then be compiled with
  449. for instance MPW and the project can be made into a standalone
  450. application. 
  451.  
  452. Programs written in EzC are just as fast and small in size as
  453. programs written from scratch in C or Pascal.
  454.  
  455. To give the curious an example of how a simple program looks
  456. like in EzC we can take as an example a window with a text field
  457. and listbox and an accept button. When the user keys in a name
  458. in the text field and clicks the accept button the name appears in
  459. the listbox.
  460.  
  461. Solving the problem:
  462.  
  463. 1) The interface elements are drawn in the layout editor.
  464.  
  465. 2) A menu for the application is created in the menu editor.
  466.  
  467. 3) The code to do the processing is as follows:
  468.  
  469.  
  470. inherit "Std:System:Window";
  471.  
  472. string *arr;
  473.  
  474. void _OpenView()  {
  475.     arr=({});
  476.     LoadMenubar("Main");
  477. }
  478.  
  479. void _Click(string name)  {
  480.     if(name=="ok")  {
  481.        arr+=({Get("field","text")});
  482.        Set("listbox","array",arr);
  483.        Set("field","text","");
  484.     }
  485. }
  486.  
  487. The layout with the program code constitutes an object in EzC.
  488.  
  489. The explanation of the code is simple. 
  490.  
  491. In the first line we inherit the standard behaviour of a window.
  492.  
  493. EzC is event driven, and opening a window generates an event.
  494. To every EzC event corresponds a function. _OpenView() is one
  495. such function. If defined in an object, it is invoked when the
  496. event occurs. _Click() is another event handler function. It is
  497. invoked on clicking the mouse.
  498.  
  499. The interface elements have names. The text field has the been
  500. given the name 'field' and the listbox element is called 'listbox'
  501. and the accept button's name is 'ok'.
  502.  
  503. The Set() function sets a property of an interface element with
  504. given parameters, and the Get() function fetches the value of a
  505. property of an interface element.
  506.  
  507. The code is only a few lines, and this is a functioning application,
  508. and can be made standalone.
  509.  
  510. It is our opinion that EzC is a suitable language for learning
  511. Macintosh programming. - Try for instance for comparison to
  512. teach the beginner to create the above example application with
  513. Think C using the TCL library. 
  514.  
  515. The programmer does not need to study any textbook on
  516. Macintosh programming to be able create simple applications
  517. like the above application in EzC, nor does he need to have read a
  518. word of the voluminous Inside Macintosh. He does however need
  519. to know something about C programming in general and to
  520. understand the events of EzC and to have at hand a reference
  521. over the main kernel and Library functions in EzC.
  522.  
  523. As the programmer becomes more proficient Visual EzC will
  524. grow with him, since it is so strongly related to C. The
  525. programmer also gradually becomes interested in acquiring
  526. knowledge of the Macintosh Toolbox as he needs to solve more
  527. advanced problems. 
  528.  
  529. The main advantage of learning Macintosh programming by
  530. using EzC is that the beginner can actually create useful
  531. standalone applications that he can be proud of within hours.
  532.  
  533. Another important advantage is, that the beginner will quickly
  534. learn to appreciate Object Oriented programming as object
  535. orientation is so closely woven into the EzC language.
  536.  
  537. A third advantage is, that the beginner will learn the basics of a
  538. generally known and accepted language, C.
  539.  
  540. Last but not least. One should not forget that EzC also has a built
  541. in relational database engine, so when the beginner wants to
  542. create a database program, the tools are right there.
  543.  
  544. A demo of Visual EzC can be found on mac.archive.umich.edu in
  545. the /mac/misc/demo/visualezc1.0b4-demo.hqx and on any of the
  546. info-mac mirror sites.
  547.  
  548. Silicon Island Software
  549. Email: silicon@simplex.nl
  550.  
  551. +++++++++++++++++++++++++++
  552.  
  553. >From D.Birnie@Regy.Canterbury.ac.nz (Denis A. Birnie)
  554. Date: Mon, 22 Aug 1994 11:17:06 +1200
  555. Organization: ISS
  556.  
  557. > I do not know anything about programming, which should be obvious
  558. > from the header.  I have a Macintosh computer and would like to
  559. > learn programming for Macintosh.  Please advise me.
  560. Dhruba,
  561.  
  562. The current way to go language-wise is C (or C++).
  563.  
  564. The book which I'd recommend (and which uses C) is
  565. Macintosh_Programming_Secrets (2nd edition) by Scott Knaster & Keith
  566. Rollin.  Shows you all sorts of interesting and neat things as well as
  567. giving you a skeleton application to work from. A VERY good book.
  568.  
  569. I'd also suggest Think Reference if you get serious and have a screen
  570. larger than the original 9"ers.
  571.  
  572. Denis Birnie
  573. --
  574. COBOhoLic!
  575.  
  576. +++++++++++++++++++++++++++
  577.  
  578. >From hanrek@cts.com (Mark Hanrek)
  579. Date: 22 Aug 1994 05:04:10 GMT
  580. Organization: The Information Workshop
  581.  
  582. In article <332mag$2jq@netserv.unmc.edu>, dchakrav@netserv.unmc.edu
  583. (Dhruba Chakravarti) wrote:
  584.  
  585. > I do not know anything about programming, which should be obvious
  586. > from the header.  I have a Macintosh computer and would like to
  587. > learn programming for Macintosh.  Please advise me.
  588.  
  589. Dhruba,
  590.  
  591. Besides all the excellent suggestions and advice thus far, consider doing
  592. the following...
  593.  
  594. Decide on a language, and get the compiler for it.
  595.  
  596. Then, download all the example source code you can find in that language
  597. and compile it.
  598.  
  599. If something is too hard to get going, move on to another.
  600.  
  601. When you get something to compile successfully, and it runs, then maybe
  602. you can think of an easy way to tweak it or make it do something
  603. different.
  604.  
  605. - --
  606.  
  607. This method is an excellent method, because you will quickly become
  608. familiar with your development environment, and the language, and the
  609. Macintosh Toolbox (the three things you'll be learning at the same time).
  610.  
  611. But what is great about this approach is that you will be getting a sense
  612. of gratification as you go along, and you will always be modifying rather
  613. than creating -- these are two very important things in the beginning, and
  614. two of the major reasons many people give up.
  615.  
  616. There's no need to overwhelm yourself.  Always have a language reference handy.
  617.  
  618. So compile freely downloadable program right and left, have fun, make some
  619. changes that make goofy things happen, and next thing you know, you will
  620. have subliminally learned a ton of essential things without even noticing
  621. it.
  622.  
  623.  
  624. Good luck to you.
  625.  
  626. Mark Hanrek
  627. The Information Workshop
  628.  
  629. +++++++++++++++++++++++++++
  630.  
  631. >From garyg@oak.circa.ufl.edu
  632. Date: 22 Aug 1994 12:46:50 GMT
  633. Organization: Center for Instructional and Research Computing Activities
  634.  
  635. Dhruba,
  636. In addition to the other advice offered, I'd suggest that you also get:
  637. Macintosh Programming Techniques: A Foundation for All Macintosh
  638. Programmers by Dan Parks Sydow (1994; M&T Books). It includes a
  639. diskette with interactive tutorials, sample code with small built
  640. applications (in case you don't have a C compiler yet), and lots
  641. of highly useful info. Another great job by DPSydow!!
  642. hth, Gary
  643.  
  644. +++++++++++++++++++++++++++
  645.  
  646. >From dchakrav@netserv.unmc.edu (Dhruba Chakravarti)
  647. Date: 23 Aug 1994 11:27:23 -0500
  648. Organization: University of Nebraska Medical Center, Omaha, NE, USA
  649.  
  650. garyg@oak.circa.ufl.edu wrote:
  651. : Dhruba,
  652. : In addition to the other advice offered, I'd suggest that you also get:
  653. : Macintosh Programming Techniques: A Foundation for All Macintosh
  654. : Programmers by Dan Parks Sydow (1994; M&T Books). It includes a
  655. : diskette with interactive tutorials, sample code with small built
  656. : applications (in case you don't have a C compiler yet), and lots
  657. : of highly useful info. Another great job by DPSydow!!
  658. : hth, Gary
  659.  
  660.  
  661. Thank you all very much!
  662.  
  663. Regards,
  664.  
  665. Dhruba.
  666.  
  667.  
  668. ---------------------------
  669.  
  670. >From will@cs.su.oz.au (William Uther)
  671. Subject: Should function order be conserved? (CW vs. GestaltValue)
  672. Date: 20 Aug 1994 16:19:54 +1000
  673. Organization: Basser Dept of Computer Sciece, Uni of Sydney, Australia
  674.  
  675. Hi,
  676.   I am using CodeWarrior to write a small application.  I want this application
  677. to publish a handle.  I had an earlier version that did this using the
  678. GestaltValue library.  This library does not work with CW 3.5.
  679.   I traced it, and found that the reason it didn't work was because it relied
  680. upon the ordering of functions to find the size of a block of memory to
  681. allocate.  (it subtracted the address of the start of one function from the
  682. address of the start of another function to get the size of the first function
  683. and hence the amount of memory it had to allocate to copy it to the system heap)
  684.   CW 3.5 does not respect this ordering when it converts Apple's '.o' file into
  685. a library.
  686.  
  687.   Is this a problem for MetroWerks (CW SHOULD respect the function ordering),
  688. or is this a problem for Apple (DTS shouldn't write libraries that rely on
  689. function ordering)??  At the moment it just seems to be a problem for me....
  690.  
  691.   Metrowerks tech support were very good at verifying the problem,
  692. unfortunately, since they shifted the blame to Apple they haven't done much.
  693. (BTW the library works in THINK C 5.0, 6.0 and 7.0 - I assume it works in MPW
  694. as it's an MPW object file)
  695.  
  696. Should I be talking to Apple DTS or Metrowerks tech support?
  697.  
  698. \x/ill        :-}
  699.  
  700. will@cs.su.oz.au
  701.  
  702.  
  703. +++++++++++++++++++++++++++
  704.  
  705. >From cokenias@netcom.com (Damon Cokenias)
  706. Date: Sun, 21 Aug 1994 21:16:36 GMT
  707. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  708.  
  709. - ---
  710.   I traced it, and found that the reason it didn't work was because it relied
  711. upon the ordering of functions to find the size of a block of memory to
  712. allocate.  (it subtracted the address of the start of one function from the
  713. address of the start of another function to get the size of the first function
  714. and hence the amount of memory it had to allocate to copy it to the system heap)
  715.   CW 3.5 does not respect this ordering when it converts Apple's '.o' file into
  716. a library.
  717. - ---
  718.  
  719. Every time I'm stepping through somebody's INIT trying to find out if it is
  720. responsible for crashing my machine, I invariably find this sort of programming.
  721. It is sick and immoral.  It is absolutely none of the programmer's business
  722. where or how their code gets compiled.
  723.  
  724. There are two solutions to the Patch/Gestalt Selector/Shutdown Handler install
  725. problem.  (Actually, there are more than two, but these are my favorites).
  726.  
  727. ** A **
  728.  
  729. 1) Call Get1IndResource (INIT, 1) to find yourself (or other appropriate
  730.    GetResource call)
  731. 2) Detach yourself, install all patches, etc.
  732.  
  733. ** B **
  734.  
  735. 1) Load a code resource containing your patch routines, detach and lock
  736. 2) Install patches.
  737.  
  738. I typically use A for quickie jobs that I just want to crank out in a moment
  739. or two.  It has the disadvantage of leaving the loader code behind.  Some of
  740. the advantages are: Only one binary to build (nice for THINK and CW users),
  741. the patches have access to the same A4 globals the loader code did.  This
  742. can be usefull.
  743.  
  744. I choose B for lean and mean INITs that I release to the public.  In order to
  745. initialize the globals for the code resource with values from the loader, I
  746. sometimes do the following:
  747.  
  748. 1) Inside the code resource I have an A4 global called 'intialized'.  It's
  749. initial value is zero.
  750. 2) BEFORE installing the patches, I call my code resource, passing a pointer
  751. to a structure containing initial values.  This can only be done for patches
  752. that accept parameters, obviously.
  753. 3) If 'initialized' is still false, the code resource knows the passed parameter
  754. contains special data and uses that data.  'initialized' is then set to true.
  755. 4) From this point on, all calls to the code resource are treated as one would
  756. expect them to.
  757.  
  758. Often, this is the most convenient way to tell a patch where to jump to after
  759. completion.  It is 100% portable on all platforms that allow a standalone
  760. code resource to have globals.
  761.  
  762. DO NOT:
  763.   * assume code gets put anywhere.  If you use Codewarrior, the frequent
  764.     updates and changes should cure you of that fast enough.
  765.  
  766. (What if CW noticed that a particular routine could be called with a short
  767. branch instead of a long one?  It might re-arrange certain funtions to make
  768. them closer to their callers.)
  769.  
  770. -Damon Cokenias
  771. .
  772.  
  773. -- 
  774. Damon Cokenias
  775. cokenias@netcom.COM
  776.  
  777. +++++++++++++++++++++++++++
  778.  
  779. >From h+@nada.kth.se (Jon W{tte)
  780. Date: Mon, 22 Aug 1994 14:54:28 +0200
  781. Organization: Royal Institute of Something or other
  782.  
  783. In article <cokeniasCuwLro.J8@netcom.com>,
  784. cokenias@netcom.com (Damon Cokenias) wrote:
  785.  
  786. >It is sick and immoral.  It is absolutely none of the programmer's business
  787. >where or how their code gets compiled.
  788.  
  789. Yes; it definately is. For a well-defined runtime architecture, 
  790. like the Mac 68k one, you're allowed and sometimes forced to do 
  791. this.
  792.  
  793. >There are two solutions to the Patch/Gestalt Selector/Shutdown Handler install
  794. >problem.  (Actually, there are more than two, but these are my favorites).
  795.  
  796. >1) Call Get1IndResource (INIT, 1) to find yourself (or other appropriate
  797. >   GetResource call)
  798. >2) Detach yourself, install all patches, etc.
  799.  
  800. >1) Load a code resource containing your patch routines, detach and lock
  801. >2) Install patches.
  802.  
  803. Strangely enough, I use none of these. Instead, I get the 
  804. address of the first instruction (you can use A0 as well, but 
  805. it's slightly less safe - someone COULD have jumped to you 
  806. through another register) Then I call RecoverHandle and 
  807. DetachResource, and use PC-relative addressing to install my 
  808. patches (and store data) This requires your INIT to be marked 
  809. pre-loaded, system heap and locked.
  810.  
  811. >1) Inside the code resource I have an A4 global called 'intialized'.  It's
  812.  
  813. A4 globals are much more horrible than comparing addresses of 
  814. functions. A4 globals require you to always enter through 
  815. main(), unless you do extra inline assembly, which kind of 
  816. rules out the case where the loader and the patch are in the 
  817. same code resource.
  818.  
  819. PS: you can get by the loader-left problem by putting the 
  820. loader code last, branch to it from the top and then call 
  821. SetHandleSize.
  822.  
  823.  
  824.  
  825.  
  826. --
  827.   Jon W‰tte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden
  828.  "Don't Deal with a Dragon."
  829.  
  830.  
  831. +++++++++++++++++++++++++++
  832.  
  833. >From Jaeger@fquest.com (Brian Stern)
  834. Date: 22 Aug 1994 17:00:11 GMT
  835. Organization: The University of Texas at Austin, Austin, Texas
  836.  
  837. In article <9668AA7E6CA4.FDF19@klkmac008.nada.kth.se>, h+@nada.kth.se (Jon
  838. W{tte) wrote:
  839.  
  840. > A4 globals are much more horrible than comparing addresses of 
  841. > functions. A4 globals require you to always enter through 
  842. > main(), unless you do extra inline assembly, which kind of 
  843. > rules out the case where the loader and the patch are in the 
  844. > same code resource.
  845.  
  846. This isn't true.  With A4 globals you must enter through main *once*.  You
  847. save the address of A4 in main.  After that you can enter through any
  848. entry point you like.  Each additional entry point first retrieves A4 and
  849. can then access its globals.  It restores A4 before exiting.  There is no
  850. reason you can't have the loader and the patch in the same code resource.
  851.  
  852. > PS: you can get by the loader-left problem by putting the 
  853. > loader code last, branch to it from the top and then call 
  854. > SetHandleSize.
  855.  
  856. I agree that this is a neat trick.  Unfortunately you can't use it when
  857. using A4 global addressing.  The globals end up at the end of the code
  858. resource.  Oh well.
  859.  
  860. > --
  861. >   Jon W‰tte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden
  862. >  "Don't Deal with a Dragon."
  863.  
  864. -- 
  865. Brian  Stern  :-{)}
  866. Jaeger@fquest.com
  867.  
  868. +++++++++++++++++++++++++++
  869.  
  870. >From h+@nada.kth.se (Jon W{tte)
  871. Date: Tue, 23 Aug 1994 08:54:14 +0200
  872. Organization: Royal Institute of Something or other
  873.  
  874. In article <Jaeger-2208941202170001@slip-2-18.ots.utexas.edu>,
  875. Jaeger@fquest.com (Brian Stern) wrote:
  876.  
  877. >This isn't true.  With A4 globals you must enter through main *once*.  You
  878. >save the address of A4 in main.  After that you can enter through any
  879. >entry point you like.  Each additional entry point first retrieves A4 and
  880. >can then access its globals.  It restores A4 before exiting.  There is no
  881. >reason you can't have the loader and the patch in the same code resource.
  882.  
  883. How do you retrieve the stored value of A4 without extra inline 
  884. assembly? Or does Symantec provide the extra assembler to do it 
  885. for you from anywhere now ?(it was a long time since I last used 
  886. it...)
  887.  
  888.  
  889. Cheers,
  890.  
  891.                 / h+
  892.  
  893.  
  894. --
  895.   Jon W‰tte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden
  896.   "Psychotherapist" - "Phycho-The-Rapist"
  897.    Pure coincidence? You decide!
  898.  
  899.  
  900. +++++++++++++++++++++++++++
  901.  
  902. >From Jaeger@fquest.com (Brian Stern)
  903. Date: 23 Aug 1994 16:19:46 GMT
  904. Organization: The University of Texas at Austin, Austin, Texas
  905.  
  906. In article <9668AA7F69B6.206994@klkmac012.nada.kth.se>, h+@nada.kth.se
  907. (Jon W{tte) wrote:
  908.  
  909. > How do you retrieve the stored value of A4 without extra inline 
  910. > assembly? Or does Symantec provide the extra assembler to do it 
  911. > for you from anywhere now ?(it was a long time since I last used 
  912. > it...)
  913. > Cheers,
  914. >                                 / h+
  915. > --
  916. >   Jon W‰tte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden
  917. >   "Psychotherapist" - "Phycho-The-Rapist"
  918. >    Pure coincidence? You decide!
  919.  
  920. Yes, the inline code is provided in a header file that must be included in
  921. each source file that needs to do A4 addressing.  The header contains
  922. several inline assembler functions for saving and restoring A4.  From the
  923. standpoint of the programmer there is no assembly required.
  924.  
  925. -- 
  926. Brian  Stern  :-{)}
  927. Jaeger@fquest.com
  928.  
  929. +++++++++++++++++++++++++++
  930.  
  931. >From phils@bedford.symantec.com (Phil Shapiro)
  932. Date: Tue, 23 Aug 1994 19:31:26 -0400
  933. Organization: Symantec Corp.
  934.  
  935. In article <9668AA7F69B6.206994@klkmac012.nada.kth.se>, h+@nada.kth.se
  936. (Jon W{tte) wrote:
  937.  
  938. | In article <Jaeger-2208941202170001@slip-2-18.ots.utexas.edu>,
  939. | Jaeger@fquest.com (Brian Stern) wrote:
  940. | >This isn't true.  With A4 globals you must enter through main *once*.  You
  941. | >save the address of A4 in main.  After that you can enter through any
  942. | >entry point you like.  Each additional entry point first retrieves A4 and
  943. | >can then access its globals.  It restores A4 before exiting.  There is no
  944. | >reason you can't have the loader and the patch in the same code resource.
  945. | How do you retrieve the stored value of A4 without extra inline 
  946. | assembly? Or does Symantec provide the extra assembler to do it 
  947. | for you from anywhere now ?(it was a long time since I last used 
  948. | it...)
  949.  
  950. Each source file gets its own copy of A4. As long as you're in the same
  951. source file that you called RememberA0() in (or RememberA4(), if A4 was
  952. valid already), you can call SetUpA4() at any entry point. This is because
  953. A4 is stored inside code in a static function; each file that uses the
  954. function gets a different copy. This has been true for quite awhile, I'm
  955. pretty sure that LSC 4.0 worked this way.
  956.  
  957. If you build with a custom header, you don't even need to enter main() at
  958. all. But you better set up A4 before you access any globals or
  959. cross-segment routines.
  960.  
  961.    -phil
  962.  
  963. ---------------------------
  964.  
  965. >From "Andrew C. Plotkin" <ap1i+@andrew.cmu.edu>
  966. Subject: Sound Manager headaches (again)
  967. Date: Sun, 21 Aug 1994 14:42:43 -0400
  968. Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA
  969.  
  970. When we last left our hero, he had just figured out how to play a sound
  971. at a given frequency (by sending soundCmd and freqDurationCmd to a
  972. sampledSynth channel.) (I sent a code snippet of doing this to
  973. alt.sources.mac, if you care. ./vol-08/sampledsnd.cpt.hqx)
  974.  
  975. Well, there was a reason I wanted to do that. See, I want to get music
  976. out, and I thought that the way to do that was record snd resources of
  977. each instrument, and then use that technique to play notes. Allocate
  978. several channels, you can get multiple notes at once.
  979.  
  980. ...Riiiiight.
  981.  
  982. First problem: they don't start off in synch. I use the algorithm given
  983. in the PlayTwoSoundsSynched in the SM3.0 tech note:  (warning:
  984. pseudocode, not real code, ahead)
  985.     SndDoImmediate(chan1, syncCmd{3, kID})
  986.     SndDoCommand(chan1, restCmd{500});
  987.     SndDoCommand(chan1, freqDurationCmd{500, MIDDLE_C});
  988.     SndDoImmediate(chan2, syncCmd{3, kID})
  989.     SndDoCommand(chan2, restCmd{500});
  990.     SndDoCommand(chan2, freqDurationCmd{500, MIDDLE_G});
  991.     SndDoImmediate(chan1, syncCmd{1, kID})
  992. I expect this to pause a quarter-second, then play a nice chord. Nope.
  993. One channel (the first one, I believe) starts slightly -- but audibly --
  994. first. (They do finish together, though.) This occurs both with and
  995. without SM3.0. 
  996. (My guess: the SM has to resample one or both sounds to a different
  997. frequency, and this takes some time. Sigh.) 
  998. Oh, yeah -- syncCmd behaves with extreme magic. I still don't know
  999. exactly what it does. For example, if I change the last line in the
  1000. algorithm above from chan1 to chan2, only one note plays instead of
  1001. both. Huh?
  1002.  
  1003. Second problem: Under SM3.0, if I play a sequence of notes of the same
  1004. duration, they don't come out with the same duration. Again, the
  1005. difference is pretty audible -- as much as a 50% error in short notes.
  1006. Unless I can do something about this, my entire plan is screwed. (Kinda
  1007. cool, huh? The nifty new SM *doesn't support freqDurationCmd* in a
  1008. usable form. I was pleased.) I recall someone else posted about this a
  1009. few weeks ago, and he couldn't get it to work either.
  1010. (My guess: same reason as before. The SM *does* keep the same
  1011. (distorted) time between channels; if I start two parallel synched
  1012. sequences, they stay synched. I guess that's something. It still ruins
  1013. the music, though.)
  1014.  
  1015. My question, pretty much, is "Have I missed anything?" I don't think I
  1016. have. I think I'm going to have to ditch the whole idea of
  1017. freqDurationCmd, and write my *own* sound-resampling-and-playing module
  1018. a la SoundTracker. (Or just use SoundTracker or some other MOD player.
  1019. This is tempting, but I haven't seen a freeware MOD player which
  1020. includes source code, except for an icky-looking one ported straight
  1021. from Unix, with malloc() everywhere. Anyone? Anyone?)
  1022.  
  1023. ObBribery: if you give me a magic answer that fixes my music-playing
  1024. code, I'll release the code as freeware. And I'll throw in the
  1025. simple-but-oh-so-elegant music editor I've spent the past month on.
  1026. (OTOH, if I wind up writing a MOD-style thing, I'll do the same thing.
  1027. Nevertheless.)
  1028.  
  1029. --Z
  1030.  
  1031. "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
  1032.  
  1033. +++++++++++++++++++++++++++
  1034.  
  1035. >From Rick_Holzgrafe@taligent.com (Rick Holzgrafe)
  1036. Date: Mon, 22 Aug 1994 18:22:58 GMT
  1037. Organization: Semicolon Software
  1038.  
  1039. In article <siJu0X_00gpI9iY0YJ@andrew.cmu.edu>, "Andrew C. Plotkin"
  1040. <ap1i+@andrew.cmu.edu> wrote:
  1041.  
  1042. > Second problem: Under SM3.0, if I play a sequence of notes of the same
  1043. > duration, they don't come out with the same duration. Again, the
  1044. > difference is pretty audible -- as much as a 50% error in short notes.
  1045. > Unless I can do something about this, my entire plan is screwed. (Kinda
  1046. > cool, huh? The nifty new SM *doesn't support freqDurationCmd* in a
  1047. > usable form. I was pleased.) I recall someone else posted about this a
  1048. > few weeks ago, and he couldn't get it to work either.
  1049.  
  1050. That was me, I think. I've heard The Word from The Source: a key
  1051. programmer at Apple tells me that SM 3.0 has been optimized for playing
  1052. sampled sounds. The optimizations DE-optimized for playing melodies via
  1053. freqDurationCmd; something about internal buffers having a size that
  1054. causes perceptible delays when they need to be refilled. There is no
  1055. workaround. For my app, I had to give up on freqDurationCmds (under SM
  1056. 3.0) and convert my tunes to single sampled sound resources, which
  1057. increased their size by two orders of magnitude and (to keep them from
  1058. getting even larger) decreased their sound quality. My app now tests the
  1059. version of the Sound Manager; if it is 3.0, you get one and only one
  1060. melody; if less than 3.0, you get a rotating selection out of a list of
  1061. seven melodies. The seven melodies take up about 20K of disk space; the
  1062. one sampled-sound melody takes several times that. Feh.
  1063.  
  1064. FWIW, I can show you code that should solve your synchronization problem.
  1065. Your various melodic parts will start together correctly, and they will
  1066. stay synched. Doesn't help the uneven tempo, though.
  1067.  
  1068. -- Rick Holzgrafe
  1069.    Semicolon Software
  1070.    rmh@taligent.com
  1071.  
  1072. +++++++++++++++++++++++++++
  1073.  
  1074. >From h+@nada.kth.se (Jon W{tte)
  1075. Date: Tue, 23 Aug 1994 09:49:07 +0200
  1076. Organization: Royal Institute of Something or other
  1077.  
  1078. In article <Rick_Holzgrafe-2208941123020001@ricks-cafe.taligent.com>,
  1079. Rick_Holzgrafe@taligent.com (Rick Holzgrafe) wrote:
  1080.  
  1081. >version of the Sound Manager; if it is 3.0, you get one and only one
  1082. >melody; if less than 3.0, you get a rotating selection out of a list of
  1083. >seven melodies. The seven melodies take up about 20K of disk space; the
  1084. >one sampled-sound melody takes several times that. Feh.
  1085.  
  1086. With QuickTime 2.0, however, all you do is store a General MIDI 
  1087. file in your resource fork (3-10k) and there's your melody.
  1088.  
  1089. Luckily, this isn't rec.music.makers.synth, where "General 
  1090. MIDI" is a cuss word.
  1091.  
  1092. Cheers,
  1093.  
  1094.                 / h+
  1095.  
  1096.  
  1097. --
  1098.   Jon W‰tte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden
  1099.   "Psychotherapist" - "Phycho-The-Rapist"
  1100.    Pure coincidence? You decide!
  1101.  
  1102.  
  1103. +++++++++++++++++++++++++++
  1104.  
  1105. >From Rick_Holzgrafe@taligent.com (Rick Holzgrafe)
  1106. Date: Tue, 23 Aug 1994 18:24:34 GMT
  1107. Organization: Semicolon Software
  1108.  
  1109. In article <Rick_Holzgrafe-2208941123020001@ricks-cafe.taligent.com>,
  1110. Rick_Holzgrafe@taligent.com (Rick Holzgrafe) wrote:
  1111.  
  1112. >version of the Sound Manager; if it is 3.0, you get one and only one
  1113. >melody; if less than 3.0, you get a rotating selection out of a list of
  1114. >seven melodies. The seven melodies take up about 20K of disk space; the
  1115. >one sampled-sound melody takes several times that. Feh.
  1116.  
  1117. In article <9668AA7F7693.236F39@klkmac012.nada.kth.se>, h+@nada.kth.se
  1118. (Jon W{tte) wrote:
  1119.  
  1120. > With QuickTime 2.0, however, all you do is store a General MIDI 
  1121. > file in your resource fork (3-10k) and there's your melody.
  1122.  
  1123. Great. So now instead of checking for the version of the Sound Manager and
  1124. having two methods of playing music, I must also check for the presence
  1125. and version of QuickTime, and have THREE methods. Ain't progress
  1126. wonderful?
  1127.  
  1128. Your pardon, please, for my surliness. I'm just tired of carefully coding
  1129. to Apple's published interfaces, and having my sound code break anyway
  1130. every couple of years.
  1131.  
  1132. -- Rick Holzgrafe
  1133.    Semicolon Software
  1134.    rmh@taligent.com
  1135.  
  1136. ---------------------------
  1137.  
  1138. >From mdc14@ciao.cc.columbia.edu (Michael D Coble)
  1139. Subject: Stopping a 'snd ' resource dead
  1140. Date: 23 Aug 1994 03:53:01 GMT
  1141. Organization: Columbia University
  1142.  
  1143.         I am a programming student trying to write a couple of macintosh
  1144. applications.  I recorded some music into a 'snd ' resource and want to
  1145. invoke the music when a user chooses the about this application from the
  1146. apple menu accompanied by a little animation.  The 'snd ' resource is a
  1147. couple of minutes long, so I'd like to be able to allow a user to click
  1148. the close box and stop it in its tracks.  I wonder if one of you
  1149. experienced programmers out there might point me in the direction to
  1150. reach this goal.
  1151.  
  1152.                 Thanks,  Michael Coble, mdc14@columbia.edu
  1153.  
  1154.  
  1155. +++++++++++++++++++++++++++
  1156.  
  1157. >From bb@lightside.com (Bob Bradley)
  1158. Date: Sun, 21 Aug 1994 15:12:37 -0800
  1159. Organization: SS Software Inc.
  1160.  
  1161. In article <33brqt$mi8@apakabar.cc.columbia.edu>,
  1162. mdc14@ciao.cc.columbia.edu (Michael D Coble) wrote:
  1163.  
  1164. >         I am a programming student trying to write a couple of macintosh
  1165. > applications.  I recorded some music into a 'snd ' resource and want to
  1166. > invoke the music when a user chooses the about this application from the
  1167. > apple menu accompanied by a little animation.  The 'snd ' resource is a
  1168. > couple of minutes long, so I'd like to be able to allow a user to click
  1169. > the close box and stop it in its tracks.  I wonder if one of you
  1170. > experienced programmers out there might point me in the direction to
  1171. > reach this goal.
  1172.  
  1173. You can do this by playing the sound async. Something like this:
  1174.  
  1175. SndNewChannel(...)                  // Create a new sound channel
  1176. soundHandle = GetResource(...)      // Get the snd resource
  1177. SndPlay(...)                        // Play the sound setting async to true
  1178. SndDisposeChanne(...)               // Dispose of the sound channel and setting
  1179.                                     // quietNow to true so it stops any sound
  1180.                                     // that is currently playing.
  1181.  
  1182. Hope that helps and doesn't contain too many errors :)
  1183.  
  1184. +++++++++++++++++++++++++++
  1185.  
  1186. >From reed@medicine.wustl.edu (Thomas Reed)
  1187. Date: Tue, 23 Aug 1994 11:08:58 -0500
  1188. Organization: Washington University
  1189.  
  1190. If you ftp to thomas_mac.wustl.edu, you'll find the source code for a
  1191. solitaire game I wrote a while back.  It contains some very useful
  1192. libraries I've written -- one of which is a sound library.  Not only will
  1193. it let you do what you want to do, but it'll also let you play the sound
  1194. from disk to reduce the memory requirements.
  1195.  
  1196. Hope you like it!
  1197.  
  1198. Oh, for those of you with NewsWatcher, here's the URL:
  1199.  
  1200.   ftp://thomas_mac.wustl.edu/Public/for_ftp/Solitaire_code.sit
  1201.  
  1202. -Thomas
  1203.  
  1204. =====================================================
  1205. Thomas Reed                     Washington University
  1206. reed@telesphere.wustl.edu           Medical School
  1207. reed@medicine.wustl.edu            Saint Louis, MO
  1208. - ---------------------------------------------------
  1209. Clothes make the man.  Naked people have little or no
  1210. influence on society.  -- Mark Twain
  1211. =====================================================
  1212.  
  1213. Opinions posted are not the opinions of Wash. U.
  1214.  
  1215. ---------------------------
  1216.  
  1217. >From chris-b@cs.auckland.ac.nz (Chris Burns)
  1218. Subject: [Q] What does "_Xxxxx ,Sys,Immed" mean?
  1219. Date: Wed, 24 Aug 1994 11:36:07 +1200
  1220. Organization: AucklandUniversity:ComputerScience:HMU
  1221.  
  1222. Hi all,
  1223.  
  1224. What do the ",Sys,Immed" qualifiers mean?
  1225. I know they specify certain bits in the trap word, but what do the
  1226. different combinations mean?
  1227.  
  1228. What I want is a table:
  1229.  
  1230. Sys   Immed    Meaning
  1231.  
  1232.  x      x      ?
  1233.  x             ?
  1234.         x      ?
  1235.                ?
  1236.  
  1237. Thanks Heaps In Advance,
  1238.  
  1239. Chris B
  1240. - ---------------------------------------------------------------------
  1241. NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns
  1242. Internet: chris-b@cs.auckland.ac.nz
  1243. Phone:    +64 9 373-7599 x6194
  1244. Fax:      +64 9 373-7453                         Async, therefore I am.
  1245. - ---------------------------------------------------------------------
  1246.  
  1247. +++++++++++++++++++++++++++
  1248.  
  1249. >From wysocki@netcom.com (Chris Wysocki)
  1250. Date: Wed, 24 Aug 1994 15:27:25 GMT
  1251. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  1252.  
  1253. In article <chris-b-2408941136070001@hmu7.cs.aukuni.ac.nz>,
  1254. Chris Burns <chris-b@cs.auckland.ac.nz> wrote:
  1255.  
  1256. >What do the ",Sys,Immed" qualifiers mean?
  1257. >I know they specify certain bits in the trap word, but what do the
  1258. >different combinations mean?
  1259.  
  1260. The ",Sys" and ",Immed" qualifiers displayed by MacsBug can be
  1261. misnomers, since these are only two of the possible meaning of bits 9
  1262. and 10 of a trap word.  All the possible meaning for these bits can be
  1263. found in Traps.a:
  1264.  
  1265. ; Equates for setting trap option bits
  1266.  
  1267. ; for Device and File Manager routines
  1268.  
  1269. immed        EQU        $200      ; execute immediately, bypass I/O queue
  1270. async        EQU        $400      ; asynchronous, don't wait for completion
  1271.  
  1272. ; for Memory Manager routines
  1273.  
  1274. clear        EQU        $200
  1275. sys          EQU        $400
  1276.  
  1277. ; for string routines
  1278.  
  1279. marks        EQU        $200      ; set to ignore/strip diacriticals
  1280. case         EQU        $400      ; set for case sensitivity
  1281.  
  1282. ; for all Toolbox routines
  1283.  
  1284. autoPop      EQU        $400      ; set to pop an extra return address
  1285.  
  1286. ; for Get/Set & NGet/NSet TrapAddress
  1287.  
  1288. newTool      EQU        $600      ; Toolbox trap, under new ordering
  1289. newOS        EQU        $200      ; OS trap, under new ordering
  1290.  
  1291. ; for HFS routines
  1292.  
  1293. newHFS       EQU        $200
  1294.  
  1295.  
  1296. Chris.
  1297.  
  1298. ---------------------------
  1299.  
  1300. >From chrism@col.hp.com (Chris Magnuson)
  1301. Subject: jGNE from an INIT
  1302. Date: 17 Aug 1994 05:50:18 GMT
  1303. Organization: HP Colorado Springs Division
  1304.  
  1305.   I am writing a jGNE event filter in MPW that needs to be part of an INIT that
  1306.   does alot of other things ( i.e. the jGNE function is one part of the
  1307.   INIT code resource).  I've gotten alot done, but run into problems when
  1308.   events actually call my jGNE routine to do the event "interception/
  1309.   redirection."  
  1310.  
  1311.   short JGNEFilterFunc(short hasEvent, const EventRecord *theEvent)
  1312.  
  1313.   My question is this:  when the JGNEFilterFunc routine is called with an
  1314.   EventRecord, etc. am I supposed to be doing some A5 world swapping to
  1315.   get things to be handled properly in the jGNE routine?  Without posting
  1316.   alot of code here is basically what the INIT initialization does.  Hints
  1317.   are greatly appreciated!
  1318.  
  1319.  
  1320.   main() {
  1321.         oldZone = GetZone();
  1322.     SetZone(SystemZone());
  1323.  
  1324.     MakeA5World(&A5Ref);
  1325.     if (A5Ref == nil) {
  1326.         SetZone(oldZone);
  1327.         return(memFullErr);
  1328.     }
  1329.     a_SetA5Ref(A5Ref);
  1330.     oldA5 = SetA5World(A5Ref);
  1331.  
  1332.     (void) ReadPrefs();
  1333.     jGNEInit();    /* point to assembly glue routine that eventually calls
  1334.                         * JGNEFilterFunc() when events go through jGNE 0x29A
  1335.                         */
  1336.  
  1337.     (void) SetA5(oldA5);
  1338.     SetZone(oldZone);
  1339.    }
  1340.  
  1341. Chris Magnuson
  1342. chrism@col.hp.com
  1343.  
  1344. +++++++++++++++++++++++++++
  1345.  
  1346. >From gurgle@dnai.com (Pete Gontier)
  1347. Date: Tue, 16 Aug 1994 23:10:27 -0800
  1348. Organization: Integer Poet Software
  1349.  
  1350. In article <32s8eq$kdr@hp-col.col.hp.com>,
  1351. chrism@col.hp.com (Chris Magnuson) wrote:
  1352.  
  1353. > I am writing a jGNE event filter in MPW that needs to be part of an INIT...
  1354. > am I supposed to be doing some A5 world swapping... ?
  1355.  
  1356. You will want to read the DSC Technical Note "Stand-alone Code Resources
  1357. Ad Nauseum" if you have not already. The short answer is yes, you do need
  1358. to do some twiddling to get access to global variables.
  1359.  
  1360. Frankly, though, I would recommend doing this project in THINK C, because
  1361. (a) assembly code is easier to integrate, (b) global variables are easier
  1362. to access, and (c) my sample jGNE INIT, "jGNE Helper", is posted monthly
  1363. to 'alt.sources.mac' with a THINK C project and will make all of these
  1364. problems go away for you.
  1365.  
  1366. -- 
  1367.  Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com
  1368.  
  1369.  "I am Homer of Borg! Prepare to be... Ooooooo! Donuts!"
  1370.  
  1371. +++++++++++++++++++++++++++
  1372.  
  1373. >From neil_ticktin@xplain.com (Neil Ticktin)
  1374. Date: Wed, 17 Aug 1994 16:26:42 GMT
  1375. Organization: MacTech Magazine/Xplain Corporation
  1376.  
  1377. In article <32s8eq$kdr@hp-col.col.hp.com>, chrism@col.hp.com (Chris
  1378. Magnuson) wrote:
  1379.  
  1380. >>   I am writing a jGNE event filter in MPW that needs to be part of an
  1381. INIT that
  1382. >>   does alot of other things ( i.e. the jGNE function is one part of the
  1383. >>   INIT code resource).  I've gotten alot done, but run into problems when
  1384. >>   events actually call my jGNE routine to do the event "interception/
  1385. >>   redirection."  
  1386. >> 
  1387.  
  1388. Chris,
  1389.  
  1390. Late last year, there was a great article by Symantec Tech Support in
  1391. about writing a jGNEFilter.  It was one of the THINK Top 10 columns.  It
  1392. contained the template code and an example of how to do it.  I'm on the
  1393. road and don't have the issue handy, but you should check it out.
  1394.  
  1395. Hope it helps,
  1396.  
  1397. Neil
  1398.  
  1399. - ---------------------------------------------------------------------
  1400.            Neil Ticktin, MacTech Magazine (formerly MacTutor)
  1401. PO Box 250055, Los Angeles, CA 90025 * 310-575-4343 * Fax: 310-575-0925
  1402.  For more info, anonymous ftp to ftp.netcom.com and cd to /pub/xplain
  1403.   custservice@xplain.com * editorial@xplain.com * adsales@xplain.com
  1404. marketing@xplain.com * accounting@xplain.com * pressreleases@xplain.com
  1405.    progchallenge@xplain.com * publisher@xplain.com * info@xplain.com
  1406.  
  1407. +++++++++++++++++++++++++++
  1408.  
  1409. >From chrism@col.hp.com (Chris Magnuson)
  1410. Date: 17 Aug 1994 20:14:57 GMT
  1411. Organization: HP Colorado Springs Division
  1412.  
  1413. Pete Gontier (gurgle@dnai.com) wrote:
  1414. : In article <32s8eq$kdr@hp-col.col.hp.com>,
  1415. : chrism@col.hp.com (Chris Magnuson) wrote:
  1416.  
  1417. : > I am writing a jGNE event filter in MPW that needs to be part of an INIT...
  1418. : > am I supposed to be doing some A5 world swapping... ?
  1419.  
  1420. : You will want to read the DSC Technical Note "Stand-alone Code Resources
  1421. : Ad Nauseum" if you have not already. The short answer is yes, you do need
  1422. : to do some twiddling to get access to global variables.
  1423.  
  1424. : Frankly, though, I would recommend doing this project in THINK C, because
  1425. : (a) assembly code is easier to integrate, (b) global variables are easier
  1426. : to access, and (c) my sample jGNE INIT, "jGNE Helper", is posted monthly
  1427. : to 'alt.sources.mac' with a THINK C project and will make all of these
  1428. : problems go away for you.
  1429.  
  1430.  
  1431.  No it won't :)  I must not be communicating what has to happen here.  main()
  1432.  is no longer the entry point for a jGNE filter only.  main() is the entry
  1433.  point for an entire INIT, one component of which is a jGNE event processor.
  1434.  So the code resource in question here is an entire INIT, not just a jGNE
  1435.  filter.
  1436.  
  1437.  In other words, the jGNE portion of the code is one routine within the INIT
  1438.  code resource, and I have glue that dispatches to that routine, but it
  1439.  does not behave properly.
  1440.  
  1441.  So maybe the question is, when the jGNE event is dispatched to the code
  1442.  within my INIT, must I set A5 for some reason?  Even though I am not
  1443.  interested in globals (just the parameters on the stack)?
  1444.  
  1445.  Chris Magnuson
  1446.  chrism@col.hp.com
  1447.  
  1448. +++++++++++++++++++++++++++
  1449.  
  1450. >From chrism@col.hp.com (Chris Magnuson)
  1451. Date: 17 Aug 1994 20:16:09 GMT
  1452. Organization: HP Colorado Springs Division
  1453.  
  1454.   Thanks.  Yes, I did check that out.  It doesnt answer my question since it
  1455.   is a standalone jGNE (in other words the jGNE event processor is not part
  1456.   of a larger code resource with other things going on).
  1457.  
  1458. Chris Magnuson
  1459. chrism@col.hp.com
  1460.  
  1461.  
  1462. Neil Ticktin (neil_ticktin@xplain.com) wrote:
  1463. : In article <32s8eq$kdr@hp-col.col.hp.com>, chrism@col.hp.com (Chris
  1464. : Magnuson) wrote:
  1465.  
  1466. : >>   I am writing a jGNE event filter in MPW that needs to be part of an
  1467. : INIT that
  1468. : >>   does alot of other things ( i.e. the jGNE function is one part of the
  1469. : >>   INIT code resource).  I've gotten alot done, but run into problems when
  1470. : >>   events actually call my jGNE routine to do the event "interception/
  1471. : >>   redirection."  
  1472. : >> 
  1473.  
  1474. : Chris,
  1475.  
  1476. : Late last year, there was a great article by Symantec Tech Support in
  1477. : about writing a jGNEFilter.  It was one of the THINK Top 10 columns.  It
  1478. : contained the template code and an example of how to do it.  I'm on the
  1479. : road and don't have the issue handy, but you should check it out.
  1480.  
  1481. : Hope it helps,
  1482.  
  1483. : Neil
  1484.  
  1485. : -----------------------------------------------------------------------
  1486. :            Neil Ticktin, MacTech Magazine (formerly MacTutor)
  1487. : PO Box 250055, Los Angeles, CA 90025 * 310-575-4343 * Fax: 310-575-0925
  1488. :  For more info, anonymous ftp to ftp.netcom.com and cd to /pub/xplain
  1489. :   custservice@xplain.com * editorial@xplain.com * adsales@xplain.com
  1490. : marketing@xplain.com * accounting@xplain.com * pressreleases@xplain.com
  1491. :    progchallenge@xplain.com * publisher@xplain.com * info@xplain.com
  1492.  
  1493. +++++++++++++++++++++++++++
  1494.  
  1495. >From larson@oahu.cs.ucla.edu (Christopher Larson)
  1496. Date: Wed, 17 Aug 94 21:28:50 GMT
  1497. Organization: UCLA, Computer Science Department
  1498.  
  1499. In article <32tr42$pfg@hp-col.col.hp.com> chrism@col.hp.com (Chris Magnuson) writes:
  1500. >: In article <32s8eq$kdr@hp-col.col.hp.com>,
  1501. >: chrism@col.hp.com (Chris Magnuson) wrote:
  1502. >
  1503. >: > I am writing a jGNE event filter in MPW that needs to be part of an INIT...
  1504. >: > am I supposed to be doing some A5 world swapping... ?
  1505.  
  1506. [...]
  1507.  
  1508. > So maybe the question is, when the jGNE event is dispatched to the code
  1509. > within my INIT, must I set A5 for some reason?  Even though I am not
  1510. > interested in globals (just the parameters on the stack)?
  1511.  
  1512. If you don't use (or cause to be used) any globals, you don't need an A5
  1513. world, and, therefore, you don't need to set A5.
  1514.  
  1515. If the jGNE filter doesn't need access to any globals, why is it part of
  1516. the INIT (I read the above to mean the jGNE code is within the INIT resource,
  1517. if not, ignore this)? Wouldn't it be easier to compile the jGNE portion as
  1518. a seperate resource, and just load, detatch, and install from the INIT
  1519. resource?
  1520.  
  1521. --Chris <Wondering if he's missing something obvious> Larson
  1522. _______________________________________________________________________________
  1523. Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant
  1524. L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious
  1525. Death to the Trojans! Go Bruins!
  1526.  
  1527. (Insert disclaimer here)
  1528. Internet: larson@kingston.cs.ucla.edu
  1529.  
  1530. +++++++++++++++++++++++++++
  1531.  
  1532. >From Jaeger@fquest.com (Brian Stern)
  1533. Date: 18 Aug 1994 00:53:36 GMT
  1534. Organization: The University of Texas at Austin, Austin, Texas
  1535.  
  1536. In article <32tr42$pfg@hp-col.col.hp.com>, chrism@col.hp.com (Chris
  1537. Magnuson) wrote:
  1538.  
  1539. > Pete Gontier (gurgle@dnai.com) wrote:
  1540. > : In article <32s8eq$kdr@hp-col.col.hp.com>,
  1541. > : chrism@col.hp.com (Chris Magnuson) wrote:
  1542. > : > I am writing a jGNE event filter in MPW that needs to be part of an
  1543. INIT...
  1544. > : > am I supposed to be doing some A5 world swapping... ?
  1545.  
  1546. >  No it won't :)  I must not be communicating what has to happen here.  main()
  1547. >  is no longer the entry point for a jGNE filter only.  main() is the entry
  1548. >  point for an entire INIT, one component of which is a jGNE event processor.
  1549. >  So the code resource in question here is an entire INIT, not just a jGNE
  1550. >  filter.
  1551. >  In other words, the jGNE portion of the code is one routine within the INIT
  1552. >  code resource, and I have glue that dispatches to that routine, but it
  1553. >  does not behave properly.
  1554. >  So maybe the question is, when the jGNE event is dispatched to the code
  1555. >  within my INIT, must I set A5 for some reason?  Even though I am not
  1556. >  interested in globals (just the parameters on the stack)?
  1557. >  Chris Magnuson
  1558. >  chrism@col.hp.com
  1559.  
  1560. In order to function properly any jGNEFilter has to insert itself into the
  1561. chain of all jGNEFilters.  When your filter exits it needs to jump to the
  1562. previous filter.  The address of the previous filter must be saved at the
  1563. time that you install your filter.  This saved address must be a global. 
  1564. Therefore your jGNEFilter, and all jGNEFilters for all time, must have
  1565. access to global variables.  There are several mechanisms for accessing
  1566. global variables in stand alone code resources like your jGNEFilter.  As I
  1567. understand it MPW uses an A5-based mechanism that is described in the tech
  1568. note.  Use that mechanism if you like.  Think, and I believe CW, use an
  1569. A4-based mechanism, which is straightforward to use.  Aside from access to
  1570. the previous filter's address or to other global variables there is no
  1571. requirement for an A5 world to be set up.
  1572.  
  1573. There is a sample jGNEFilter written by Dave Falkenberg that can be found
  1574. at ftp.apple.com.  This sample is all in MPW assembler.  It does not use
  1575. the A5 mechanism for storing the address of the previous filter.  It
  1576. simply stores the address within itself.
  1577.  
  1578. -- 
  1579. Brian  Stern  :-{)}
  1580. Jaeger@fquest.com
  1581.  
  1582. +++++++++++++++++++++++++++
  1583.  
  1584. >From gurgle@dnai.com (Pete Gontier)
  1585. Date: Wed, 17 Aug 1994 21:17:15 -0800
  1586. Organization: Integer Poet Software
  1587.  
  1588. In article <1994Aug17.212850.10867@cs.ucla.edu>, larson@oahu.cs.ucla.edu
  1589. (Christopher Larson) wrote:
  1590.  
  1591. > If the jGNE filter doesn't need access to any globals, why is it part of
  1592. > the INIT ... ? Wouldn't it be easier to compile the jGNE portion as
  1593. > a seperate resource, and just load, detatch, and install from the INIT
  1594. > resource?
  1595.  
  1596. His filter might want to call other functions in the INIT without
  1597. duplicating them in the jGNE resource. I don't know enough about
  1598. MPW-generated code resources to be able to say whether it needs A5 to call
  1599. functions. Probably it uses PC-relative calls, but it's something you
  1600. would want to look up.
  1601.  
  1602. -- 
  1603.  Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com
  1604.  
  1605.  "Even during a particularly harsh (Colorado) winter... many of the
  1606.  300 families in the VCTV (movies-on-demand) trial continued to go
  1607.  to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62
  1608.  
  1609. +++++++++++++++++++++++++++
  1610.  
  1611. >From gurgle@dnai.com (Pete Gontier)
  1612. Date: Wed, 17 Aug 1994 21:25:33 -0800
  1613. Organization: Integer Poet Software
  1614.  
  1615. In article <32tr42$pfg@hp-col.col.hp.com>, chrism@col.hp.com (Chris
  1616. Magnuson) wrote:
  1617.  
  1618. >  I must not be communicating what has to happen here.  main()
  1619. >  is no longer the entry point for a jGNE filter only.  main() is the entry
  1620. >  point for an entire INIT, one component of which is a jGNE event processor.
  1621. >  So the code resource in question here is an entire INIT, not just a jGNE
  1622. >  filter. In other words, the jGNE portion of the code is one routine within
  1623. >  the INIT code resource, and I have glue that dispatches to that routine,
  1624. >  but it does not behave properly.
  1625.  
  1626. As I said in email, I know. :-) Probably I am the one who did insufficient
  1627. communicating. With a THINK (or CodeWarrior) compiler, what you're asking
  1628. about is trivial, because the compiler actually knows that it's compiling
  1629. something other than an application, unlike MPW. MPW only knows at link
  1630. time; consequently, MPW code resource have to pretend in many ways that
  1631. they are apps. Hence that entire tech note about code resources and A5.
  1632. Blech.
  1633.  
  1634. >  So maybe the question is, when the jGNE event is dispatched to the code
  1635. >  within my INIT, must I set A5 for some reason?  Even though I am not
  1636. >  interested in globals (just the parameters on the stack)?
  1637.  
  1638. Again as I said in email, if your code does not use statically allocated
  1639. variables (locals declared 'static' or globals), you may still need to set
  1640. up A5 if your filter calls other routines, depending on how MPW finds
  1641. those routines. Probably it finds them PC-relative, but it may find them
  1642. A5-relative. Perhaps some MPW guru can shed light on this.
  1643.  
  1644. -- 
  1645.  Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com
  1646.  
  1647.  "Even during a particularly harsh (Colorado) winter... many of the
  1648.  300 families in the VCTV (movies-on-demand) trial continued to go
  1649.  to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62
  1650.  
  1651. +++++++++++++++++++++++++++
  1652.  
  1653. >From Jaeger@fquest.com (Brian Stern)
  1654. Date: 19 Aug 1994 02:36:45 GMT
  1655. Organization: The University of Texas at Austin, Austin, Texas
  1656.  
  1657. In article <jedavis.777254033@Xenon.Stanford.EDU>,
  1658. jedavis@Xenon.Stanford.EDU (James Edward Davis) wrote:
  1659.  
  1660. > On a side note.. I dont suppose you have any idea if I can 
  1661. > allocate some memory in a jGNEfilter? I dont mind stealing
  1662. > from the host app. I want to muck with the clipboard, so need 
  1663. > a couple handles that dont mind being resized by the Scrap calls.
  1664. > -James
  1665.  
  1666. Since jGNEFilters are called from WNE/GNE and both of those traps are
  1667. documented as moving or purging memory, Yes you can allocate memory from
  1668. inside a jGNEFilter.  If you want the memory to last longer than one pass
  1669. through your filter make sure to allocate the memory in the system heap,
  1670. otherwise it will be lost if the app quits.  If the memory will be
  1671. allocated and disposed within one pass of the filter it can go in the
  1672. application's heap.
  1673.  
  1674. -- 
  1675. Brian  Stern  :-{)}
  1676. Jaeger@fquest.com
  1677.  
  1678. +++++++++++++++++++++++++++
  1679.  
  1680. >From jedavis@Xenon.Stanford.EDU (James Edward Davis)
  1681. Date: 18 Aug 94 18:51:13 GMT
  1682. Organization: Stanford University: Computer Science Department
  1683.  
  1684. larson@oahu.cs.ucla.edu (Christopher Larson) writes:
  1685.  
  1686. >In article <32tr42$pfg@hp-col.col.hp.com> chrism@col.hp.com (Chris Magnuson) writes:
  1687. >> So maybe the question is, when the jGNE event is dispatched to the code
  1688. >> within my INIT, must I set A5 for some reason?  Even though I am not
  1689. >> interested in globals (just the parameters on the stack)?
  1690.  
  1691. >If you don't use (or cause to be used) any globals, you don't need an A5
  1692. >world, and, therefore, you don't need to set A5.
  1693.  
  1694. Yes, but remember that some Quickdraw globals are offset from A5 as
  1695. well. You might not need *your* A5, but you will need a valid one.
  1696. I bring this up, because inside your jGNEfilter you wont
  1697. neccessarily get one. You can set the A5 of the
  1698. currently executing application from the low memory global CurrentA5,
  1699. but remember to put back whatever stuffs was in A5 to start with.
  1700.  
  1701. James Davis : jedavis@cs.stanford.edu
  1702.  
  1703. +++++++++++++++++++++++++++
  1704.  
  1705. >From larson@oahu.cs.ucla.edu (Christopher Larson)
  1706. Date: Thu, 18 Aug 94 21:05:17 GMT
  1707. Organization: UCLA, Computer Science Department
  1708.  
  1709. James said:
  1710. >I said:
  1711. >>Chris Magnuson said:
  1712. >>> So maybe the question is, when the jGNE event is dispatched to the code
  1713. >>> within my INIT, must I set A5 for some reason?  Even though I am not
  1714. >>> interested in globals (just the parameters on the stack)?
  1715. >
  1716. >>If you don't use (or cause to be used) any globals, you don't need an A5
  1717. >>world, and, therefore, you don't need to set A5.
  1718. >
  1719. >Yes, but remember that some Quickdraw globals are offset from A5 as
  1720. >well.
  1721.  
  1722. Making any calls which require Quickdraw globals count as causing globals
  1723. to be used. (Perhaps I should have made that point clear :-).
  1724.  
  1725. > You might not need *your* A5, but you will need a valid one.
  1726.  
  1727. Why? If I don't use Quickdraw or my own globals, I shouldn't (see caveat
  1728. below) need an A5 world and shouldn't care what the value of A5 is. I've
  1729. written numerous code resources and trap patches (though never a jGNE
  1730. filter). I've never needed an A5 world of my own (meaning belonging to
  1731. the code resource), and only needed to borrow the current application's
  1732. A5 when using Quickdraw globals. Unless jGNE filters are inherently
  1733. different, I don't see why one must run with a valid A5. (I didn't
  1734. intend this to sound at all like a flame. I'm just trying to get to
  1735. the bottom of this too.)
  1736.  
  1737. caveat: As Peter Lewis pointed out, calls to other routines within
  1738. code resources may use a jump table, which may use A5. Consult your
  1739. development system regarding this. (I'm paraphrasing, excuse me if I've
  1740. misinterpreted you, Peter.)
  1741.  
  1742. >I bring this up, because inside your jGNEfilter you wont neccessarily get
  1743. >one.
  1744.  
  1745. You sure won't.
  1746.  
  1747. >You can set the A5 of the currently executing application from the low
  1748. >memory global CurrentA5, but remember to put back whatever stuffs was in
  1749. >A5 to start with.
  1750.  
  1751. An invaluable piece of information. Saved my hiney many times.
  1752.  
  1753. --Chris
  1754. _______________________________________________________________________________
  1755. Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant
  1756. L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious
  1757. Death to the Trojans! Go Bruins!
  1758.  
  1759. (Insert disclaimer here)
  1760. Internet: larson@kingston.cs.ucla.edu
  1761.  
  1762. +++++++++++++++++++++++++++
  1763.  
  1764. >From jedavis@Xenon.Stanford.EDU (James Edward Davis)
  1765. Date: 18 Aug 94 23:53:53 GMT
  1766. Organization: Stanford University: Computer Science Department
  1767.  
  1768. larson@oahu.cs.ucla.edu (Christopher Larson) writes:
  1769.  
  1770. >> You might not need *your* A5, but you will need a valid one.
  1771. >Why? If I don't use Quickdraw or my own globals, I shouldn't (see caveat
  1772. >below) need an A5 world and shouldn't care what the value of A5 is. I've
  1773. >written numerous code resources and trap patches (though never a jGNE
  1774. >filter). I've never needed an A5 world of my own (meaning belonging to
  1775. >the code resource), and only needed to borrow the current application's
  1776. >A5 when using Quickdraw globals. Unless jGNE filters are inherently
  1777. >different, I don't see why one must run with a valid A5. (I didn't
  1778. >intend this to sound at all like a flame. I'm just trying to get to
  1779. >the bottom of this too.)
  1780.  
  1781. You're correct. I phrased something badly. I had meant to
  1782. suggest that stealing the current applications A5 would do
  1783. for quickdraw globals, if you didnt have one of your own handy.
  1784.  
  1785. On a side note.. I dont suppose you have any idea if I can 
  1786. allocate some memory in a jGNEfilter? I dont mind stealing
  1787. from the host app. I want to muck with the clipboard, so need 
  1788. a couple handles that dont mind being resized by the Scrap calls.
  1789.  
  1790. -James
  1791.  
  1792. +++++++++++++++++++++++++++
  1793.  
  1794. >From jedavis@Xenon.Stanford.EDU (James Edward Davis)
  1795. Date: 19 Aug 94 09:42:08 GMT
  1796. Organization: Stanford University: Computer Science Department
  1797.  
  1798. Jaeger@fquest.com (Brian Stern) writes:
  1799.  
  1800. >In article <32tr42$pfg@hp-col.col.hp.com>, chrism@col.hp.com (Chris
  1801. >Magnuson) wrote:
  1802.  
  1803. >> Pete Gontier (gurgle@dnai.com) wrote:
  1804. >> : In article <32s8eq$kdr@hp-col.col.hp.com>,
  1805. >> : chrism@col.hp.com (Chris Magnuson) wrote:
  1806. >> 
  1807. >>  So maybe the question is, when the jGNE event is dispatched to the code
  1808. >>  within my INIT, must I set A5 for some reason?  Even though I am not
  1809. >>  interested in globals (just the parameters on the stack)?
  1810. >> 
  1811. >>  chrism@col.hp.com
  1812.  
  1813. >In order to function properly any jGNEFilter has to insert itself into the
  1814. >chain of all jGNEFilters.  When your filter exits it needs to jump to the
  1815. >previous filter.  The address of the previous filter must be saved at the
  1816. >time that you install your filter.  This saved address must be a global. 
  1817.  
  1818. Global? Well not really. Its not really good style, but Ive seen it done
  1819. by stuffing the address into your code at install time. The same way
  1820. many people store their app A5, with code that self modifies to
  1821. contain the location.
  1822. For that matter, where should I store my apps A5, so I can reset
  1823. it without using self modifying code?
  1824.  
  1825. -James 
  1826.  
  1827. +++++++++++++++++++++++++++
  1828.  
  1829. >From larson@oahu.cs.ucla.edu (Christopher Larson)
  1830. Date: Fri, 19 Aug 94 16:15:35 GMT
  1831. Organization: UCLA, Computer Science Department
  1832.  
  1833. In article <jedavis.777289328@Xenon.Stanford.EDU> jedavis@Xenon.Stanford.EDU (James Edward Davis) writes:
  1834. >Jaeger@fquest.com (Brian Stern) writes:
  1835. >>In order to function properly any jGNEFilter has to insert itself into the
  1836. >>chain of all jGNEFilters.  When your filter exits it needs to jump to the
  1837. >>previous filter.  The address of the previous filter must be saved at the
  1838. >>time that you install your filter.  This saved address must be a global. 
  1839. >
  1840. >Global? Well not really. Its not really good style, but Ive seen it done
  1841. >by stuffing the address into your code at install time. The same way
  1842. >many people store their app A5, with code that self modifies to
  1843. >contain the location.
  1844.  
  1845. I'm not sure this strategy counts as self-modification if the installed
  1846. code is contained in its own resource. When the app (INIT, whatever) loads
  1847. the resource, before detaching and installing, it's just data. If it's
  1848. modified at this point, I don't think you will have any problems (still
  1849. need to flush caches though), because the resource has never been loaded
  1850. as code. If the code to be installed is in your 'CODE' resources, all
  1851. bets are off. (Comments on this welcome....)
  1852.  
  1853. >For that matter, where should I store my apps A5, so I can reset
  1854. >it without using self modifying code?
  1855.  
  1856. Well, you could use the above strategy, or if that is still to self-modify-
  1857. ish, you could install a Gestalt selector. Note that trickery to recover your
  1858. A5 is only necessary if your code might run when your app is switched out or
  1859. at interrupt time. If this is not the case, you can recover it from CurrentA5,
  1860. as you suggested earlier. 
  1861.  
  1862. Hmmm. This raises an interesting question. If an app installs a jGNEFilter,
  1863. is that filter visible to all other applications, or is it more like trap
  1864. patches (which, if done from an app, are only visible to the installing app)?
  1865. Anyone?
  1866.  
  1867. Since this thread is about jGNEFilters, I assume your question was specific
  1868. to recovering A5 from a jGNEFilter/trap patch kind of situation. If not, mail
  1869. me with the specifics.
  1870.  
  1871. --Chris
  1872. _______________________________________________________________________________
  1873. Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant
  1874. L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious
  1875. Death to the Trojans! Go Bruins!
  1876.  
  1877. (Insert disclaimer here)
  1878. Internet: larson@kingston.cs.ucla.edu
  1879.  
  1880. +++++++++++++++++++++++++++
  1881.  
  1882. >From larson@oahu.cs.ucla.edu (Christopher Larson)
  1883. Date: Fri, 19 Aug 94 16:22:01 GMT
  1884. Organization: UCLA, Computer Science Department
  1885.  
  1886. In article <Jaeger-1808942138440001@slip-15-7.ots.utexas.edu> Jaeger@fquest.com (Brian Stern) writes:
  1887. >In article <jedavis.777254033@Xenon.Stanford.EDU>,
  1888. >jedavis@Xenon.Stanford.EDU (James Edward Davis) wrote:
  1889. >
  1890. >> On a side note.. I dont suppose you have any idea if I can 
  1891. >> allocate some memory in a jGNEfilter? I dont mind stealing
  1892. >
  1893. >Since jGNEFilters are called from WNE/GNE and both of those traps are
  1894. >documented as moving or purging memory, Yes you can allocate memory from
  1895. >inside a jGNEFilter.  If you want the memory to last longer than one pass
  1896. >through your filter make sure to allocate the memory in the system heap,
  1897. >otherwise it will be lost if the app quits.
  1898.  
  1899. Or, you could receive consecutive calls from two different applications.
  1900. Best, in any case, to allocate from the system heap if you want persistance.
  1901.  
  1902. >If the memory will be allocated and disposed within one pass of the filter
  1903. >it can go in the application's heap.
  1904.  
  1905. Or maybe temporary memory if you don't want to use the app's heap.
  1906.  
  1907. --Chris
  1908. _______________________________________________________________________________
  1909. Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant
  1910. L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious
  1911. Death to the Trojans! Go Bruins!
  1912.  
  1913. (Insert disclaimer here)
  1914. Internet: larson@kingston.cs.ucla.edu
  1915.  
  1916. +++++++++++++++++++++++++++
  1917.  
  1918. >From gurgle@dnai.com (Pete Gontier)
  1919. Date: Fri, 19 Aug 1994 09:45:18 -0800
  1920. Organization: Integer Poet Software
  1921.  
  1922. In article <1994Aug19.161535.10734@cs.ucla.edu>, larson@oahu.cs.ucla.edu
  1923. (Christopher Larson) wrote:
  1924.  
  1925. > If an app installs a jGNEFilter,
  1926. > is that filter visible to all other applications, or is it more like trap
  1927. > patches (which, if done from an app, are only visible to the installing app)?
  1928.  
  1929. It's visible to all other applications.
  1930.  
  1931. -- 
  1932.  Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com
  1933.  
  1934.  "Even during a particularly harsh (Colorado) winter... many of the
  1935.  300 families in the VCTV (movies-on-demand) trial continued to go
  1936.  to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62
  1937.  
  1938. +++++++++++++++++++++++++++
  1939.  
  1940. >From Jaeger@fquest.com (Brian Stern)
  1941. Date: 19 Aug 1994 16:43:20 GMT
  1942. Organization: The University of Texas at Austin, Austin, Texas
  1943.  
  1944. In article <jedavis.777289328@Xenon.Stanford.EDU>,
  1945. jedavis@Xenon.Stanford.EDU (James Edward Davis) wrote:
  1946.  
  1947. > Jaeger@fquest.com (Brian Stern) writes:
  1948. > >In order to function properly any jGNEFilter has to insert itself into the
  1949. > >chain of all jGNEFilters.  When your filter exits it needs to jump to the
  1950. > >previous filter.  The address of the previous filter must be saved at the
  1951. > >time that you install your filter.  This saved address must be a global. 
  1952. > Global? Well not really. Its not really good style, but Ive seen it done
  1953. > by stuffing the address into your code at install time. The same way
  1954. > many people store their app A5, with code that self modifies to
  1955. > contain the location.
  1956. > For that matter, where should I store my apps A5, so I can reset
  1957. > it without using self modifying code?
  1958. > -James 
  1959.  
  1960. App?  I thought we were talking about about an INIT.  Installing a
  1961. jGNEFilter from an app has a number of problems to worry about.  I would
  1962. probably write the filter as a code resource using A4 addressing.  To
  1963. install it I'd load the resource into the system heap, set up A0, and jump
  1964. to it from the app to initilize it.  It would save A5 for later use.  It
  1965. would also have to make sure that the app still existed.  The A4 mechanism
  1966. as used by Think C is also a self-modifying mechanism and I don't see any
  1967. clean way around it.
  1968.  
  1969. Having said that, I recently came across some code in a package called
  1970. Extension Shell by Dair Grant that uses A4 addressing without being
  1971. self-modifying.  Here's the code:
  1972.  
  1973.    WRITTEN BY:
  1974.       Eric Shapiro (from July 1993 BYTE article, and the supporting source code)
  1975.  
  1976. // Saves the current value of A4 on the stack, and puts the address of main
  1977. // into A4. Should be called at start of stand-alone code resource to
  1978. access globals.
  1979. #define GetGlobals()    asm {                                        \
  1980.                         move.l      A4, -(SP)      ; save old A4        \
  1981.                         lea      main, A4       ; get globals        \
  1982.                         }
  1983.  
  1984.  
  1985. // The converse of GetGlobals(). Restore the value of A4                
  1986. #define UngetGlobals()     asm {                                     \
  1987.                         move.l      (SP)+, A4      ; restore A4 from stack \
  1988.                         }
  1989.  
  1990. This is dependent on main being at the beginning of your code resource and
  1991. on your compiler compiling the code resource using A4 addressing.
  1992.  
  1993. -- 
  1994. Brian  Stern  :-{)}
  1995. Jaeger@fquest.com
  1996.  
  1997. +++++++++++++++++++++++++++
  1998.  
  1999. >From bjaques@vanbc.wimsey.com (Barton Jaques)
  2000. Date: Fri, 19 Aug 1994 09:36:35 -0700
  2001. Organization: Wimsey Information Services
  2002.  
  2003. I spent many long hours slaving over my hot jGNEFilter before it worked
  2004. correctly. It is the sloppiest hack I've seen in a while, but it works
  2005. great. In short, here's what I do:
  2006.  
  2007. • I have a separate jGNEFilter.π project which compiles into a single
  2008. resource.
  2009. • My INIT or DRVR reads that resource, detaches it, locks it.
  2010. • At startup time, my INIT or DRVR reads the current value of jGNEFilter,
  2011. pokes it into my patch resource, then sticks the address of my patch
  2012. resource into jGNEFilter.
  2013. • I have another handle which contains useful "global" variables and
  2014. pointers to procedures contained in other code resources. I poke the handle
  2015. into my detached jGNE resource. This way I have access to "globals" which I
  2016. have scattered through different code resources … yet I don't have to
  2017. fiddle with A5.
  2018. • The way I do this is by initialising a couple of local variables in my
  2019. patch resource as follows:
  2020.      globRecH     globalsH = 0xEEEEEEEE;
  2021.      long            nextGNEFilter = 0xDDDDDDDD;
  2022.   My INIT or DRVR scans the resource, finds 0xEEEEEEEE, and overwrites it
  2023. with my "globals" handle. Then it scans for 0xDDDDDDDD, and overwrites it
  2024. with the pointer to the next GNE filter.
  2025. • If my GNEFilter calls a procedure in another of my code resources, THEN I
  2026. need to set up A4/A5 as appropriate, and put it back before I return to my
  2027. patch.
  2028. • When I want to de-install my driver, etc., I cauterise my patch by
  2029. plugging 0x00000000 where my globals handle was. The filter then knows that
  2030. it has been deactivated, so it passes to the next filter without doing
  2031. anything. I can always restore the patch simply by poking globH back in
  2032. again.
  2033.  
  2034.   This is the code in THINK C 68K. It surely will not work under another
  2035. environment without serious modification, but it should illustrate the
  2036. idea. 
  2037.  
  2038. void 
  2039. main() {
  2040.  
  2041.     globRecH        globH    = (globRecH)0xEEEEEEEE;
  2042.     long            nextGNEFilter = 0xDDDDDDDD;
  2043.     EventRecord *filteredEventP;
  2044.   // declare any other local vars you need
  2045.     Ptr            stackP;                            // stackP MUST be last local var declared
  2046.     
  2047.     //    move.l    (a7), -(a7)                        ; In actual res this line must precede LINK A6
  2048.     //                                                    ; In ResEdit, insert '2F17' as 1st word in res
  2049.     //                                                    ; then move 2nd-last byte (= 4E5E) to
  2050.     //                                                    ; precede 5th-last byte (= 4A97)
  2051.  
  2052.     asm{
  2053.         movem.l    a7, stackP                        ; make copy of stack pointer
  2054.         movem.l    a0-a3/d0-d7, -(sp)            ; save registers
  2055.     }            
  2056.     
  2057.     // if nextGNEFilter exists we must fiddle with stack to insert it
  2058.     if (nextGNEFilter) {
  2059.         stackP += ((Ptr)&globH - (Ptr)&stackP) + 8;
  2060.         *(long*)stackP = nextGNEFilter;
  2061.     }
  2062.     
  2063.     // do nothing if no globals
  2064.     if (globH) {
  2065.   // get a pointer to the event record
  2066.         asm{
  2067.             move.l    a1, filteredEventP            ; test a1 (EventPtr)
  2068.         }
  2069.         eventwhat = filteredEventP->what;
  2070.  
  2071.   // now we can do our stuff
  2072.     }
  2073.  
  2074.     // restore registers and stack
  2075.     asm{
  2076.         movem.l    (sp)+, d0-d7/a0-a3        ; restore all registers
  2077.         tst.l        (sp)                            ; in actual res these lines follow UNLK A6 (see note
  2078. above)
  2079.         bne        @END                            ; 
  2080.         tst.l        (sp)+                            ;
  2081.         @END
  2082.     }
  2083.  
  2084.     // control now passes to next GNEFilter handler if any
  2085. }
  2086.  
  2087.  
  2088. -- 
  2089. bjaques@vanbc.wimsey.com
  2090.  
  2091. +++++++++++++++++++++++++++
  2092.  
  2093. >From gurgle@dnai.com (Pete Gontier)
  2094. Date: Fri, 19 Aug 1994 12:20:28 -0800
  2095. Organization: Integer Poet Software
  2096.  
  2097. In article <bjaques-190894093636@pme22.pomo.wis.net>,
  2098. bjaques@vanbc.wimsey.com (Barton Jaques) wrote:
  2099.  
  2100. > I spent many long hours slaving over my hot jGNEFilter before it worked
  2101. > correctly. It is the sloppiest hack I've seen in a while, but it works
  2102. > great. In short, here's what I do...
  2103.  
  2104. With all due respect for your long hours, quite frankly this all seems
  2105. very convoluted and mildly dangerous. If any step in the development
  2106. process goes wrong, the program fails at runtime. There are a minimum of
  2107. helpful compile-time checks, and it's difficult to see why any one part of
  2108. it works the way it does without understanding the whole picture. I'm glad
  2109. it works for you, but it seems a lot simpler and a lot cleaner to simply
  2110. use a strategy like that illustrated in "jGNE Helper" or whatever the hell
  2111. that monthly posting is called. (It may sound like I didn't write it
  2112. because I can't even remember its name, but I did write it, and you should
  2113. assume I am accordingly biased.)
  2114.  
  2115. -- 
  2116.  Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com
  2117.  
  2118.  "Even during a particularly harsh (Colorado) winter... many of the
  2119.  300 families in the VCTV (movies-on-demand) trial continued to go
  2120.  to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62
  2121.  
  2122. +++++++++++++++++++++++++++
  2123.  
  2124. >From Jaeger@fquest.com (Brian Stern)
  2125. Date: 20 Aug 1994 00:25:40 GMT
  2126. Organization: The University of Texas at Austin, Austin, Texas
  2127.  
  2128. In article <bjaques-190894093636@pme22.pomo.wis.net>,
  2129. bjaques@vanbc.wimsey.com (Barton Jaques) wrote:
  2130.  
  2131. > I spent many long hours slaving over my hot jGNEFilter before it worked
  2132. > correctly. It is the sloppiest hack I've seen in a while, but it works
  2133. > great. In short, here's what I do:
  2134.  
  2135. Or, you could simply use A4 addressing to access your globals from your
  2136. Filter.  You can easily set a Boolean flag to let your Filter know if it's
  2137. supposed to do anything.  
  2138.  
  2139. I don't trust any code building method that has instructions in it like '
  2140. In ResEdit, insert '2F17' as 1st word in res then move 2nd-last byte (=
  2141. 4E5E) to precede 5th-last byte (= 4A97)'.
  2142.  
  2143. In programming like in most things simpler is usually better.  There are
  2144. lot's simpler ways to do it than this.
  2145.  
  2146. > -- 
  2147. > bjaques@vanbc.wimsey.com
  2148.  
  2149. -- 
  2150. Brian  Stern  :-{)}
  2151. Jaeger@fquest.com
  2152.  
  2153. +++++++++++++++++++++++++++
  2154.  
  2155. >From jedavis@Xenon.Stanford.EDU (James Edward Davis)
  2156. Date: 20 Aug 94 17:24:09 GMT
  2157. Organization: Stanford University: Computer Science Department
  2158.  
  2159. larson@oahu.cs.ucla.edu (Christopher Larson) writes:
  2160.  
  2161. >In article <jedavis.777289328@Xenon.Stanford.EDU> jedavis@Xenon.Stanford.EDU (James Edward Davis) writes:
  2162. >>Jaeger@fquest.com (Brian Stern) writes:
  2163.  
  2164. >Well, you could use the above strategy, or if that is still to self-modify-
  2165. >ish, you could install a Gestalt selector. Note that trickery to recover your
  2166. >A5 is only necessary if your code might run when your app is switched out or
  2167. >at interrupt time. If this is not the case, you can recover it from CurrentA5,
  2168. >as you suggested earlier. 
  2169.  
  2170. >Hmmm. This raises an interesting question. If an app installs a jGNEFilter,
  2171. >is that filter visible to all other applications, or is it more like trap
  2172. >patches (which, if done from an app, are only visible to the installing app)?
  2173. >Anyone?
  2174.  
  2175. The jGNE filter *is* active across all apps. The low memory global that
  2176. points to the filter chain, is not changed by context switches. This
  2177. means you have to be very careful if you install a filter with code
  2178. in your app heap, since if you quit without cleanup, theres a dangling
  2179. reference and the machine will crash.
  2180.  
  2181. -James
  2182.  
  2183.  
  2184. +++++++++++++++++++++++++++
  2185.  
  2186. >From kluev@jonathan.srcc.msu.su (Kluev)
  2187. Date: Mon, 22 Aug 94 23:02:46 +0400
  2188. Organization: (none)
  2189.  
  2190. In article <jedavis.777403449@Xenon.Stanford.EDU>
  2191. jedavis@Xenon.Stanford.EDU (James Edward Davis) wrote:
  2192.  
  2193. > The jGNE filter *is* active across all apps. The low memory global
  2194. that
  2195. > points to the filter chain, is not changed by context switches. This
  2196. > means you have to be very careful if you install a filter with code
  2197. > in your app heap, since if you quit without cleanup, theres a
  2198. dangling
  2199. > reference and the machine will crash.
  2200.  
  2201. One should be careful about this cleanup. One shouldn't restore
  2202. original value in jGNEFilter, because someone may install gne
  2203. filter on top of one's. Restoring jGNEFilter to original value
  2204. will remove someone's filter and may crash him. The better
  2205. solution is to install one's filter into system heap, never
  2206. remove it, check if filter was already installed (Gestalt is
  2207. one solution) (not to install it twice), set/clear flag on
  2208. application's startup/exit to turn filter's activity on/off.
  2209.  
  2210. Michael Kluev.
  2211.  
  2212. +++++++++++++++++++++++++++
  2213.  
  2214. >From jedavis@Xenon.Stanford.EDU (James Edward Davis)
  2215. Date: 23 Aug 94 02:50:02 GMT
  2216. Organization: Stanford University: Computer Science Department
  2217.  
  2218. kluev@jonathan.srcc.msu.su (Kluev) writes:
  2219.  
  2220. >In article <jedavis.777403449@Xenon.Stanford.EDU>
  2221. >jedavis@Xenon.Stanford.EDU (James Edward Davis) wrote:
  2222.  
  2223. >One should be careful about this cleanup. One shouldn't restore
  2224. >original value in jGNEFilter, because someone may install gne
  2225. >filter on top of one's. Restoring jGNEFilter to original value
  2226. >will remove someone's filter and may crash him. The better
  2227. >solution is to install one's filter into system heap, never
  2228. >remove it, check if filter was already installed (Gestalt is
  2229. >one solution) (not to install it twice), set/clear flag on
  2230. >application's startup/exit to turn filter's activity on/off.
  2231.  
  2232. Yes, that would work but Id rather not leave memory allocated
  2233. in the system heap. But your right about another being installed
  2234. over mine. I allocate a small block in the system heap that just
  2235. jumps to my code in the application heap. When I want to deinstall,
  2236. I check to see if the front jGNEfilter is me. If it is, I can 
  2237. just reset the pointer. If its not, I change my stub to 
  2238. jump to the original address instead of my code. I only end up
  2239. wasting a little system heap that way. I cant claim credit 
  2240. for the technique. I got a snippet from someone else, thought
  2241. it was clever, and used it.
  2242.  
  2243. -James
  2244.  
  2245. +++++++++++++++++++++++++++
  2246.  
  2247. >From h+@nada.kth.se (Jon W{tte)
  2248. Date: Tue, 23 Aug 1994 09:49:02 +0200
  2249. Organization: Royal Institute of Something or other
  2250.  
  2251. In article <jedavis.777610202@Xenon.Stanford.EDU>,
  2252. jedavis@Xenon.Stanford.EDU (James Edward Davis) wrote:
  2253.  
  2254. >Yes, that would work but Id rather not leave memory allocated
  2255. >in the system heap. But your right about another being installed
  2256. >over mine. I allocate a small block in the system heap that just
  2257. >jumps to my code in the application heap. When I want to deinstall,
  2258.  
  2259. I hope you remember to flush the cache when you change this 
  2260. value...
  2261.  
  2262. Cheers,
  2263.  
  2264.                 / h+
  2265.  
  2266.  
  2267. --
  2268.   Jon W‰tte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden
  2269.   "Psychotherapist" - "Phycho-The-Rapist"
  2270.    Pure coincidence? You decide!
  2271.  
  2272.  
  2273. +++++++++++++++++++++++++++
  2274.  
  2275. >From jedavis@Xenon.Stanford.EDU (James Edward Davis)
  2276. Date: 23 Aug 94 22:00:51 GMT
  2277. Organization: Stanford University: Computer Science Department
  2278.  
  2279. h+@nada.kth.se (Jon W{tte) writes:
  2280.  
  2281. >In article <jedavis.777610202@Xenon.Stanford.EDU>,
  2282. >jedavis@Xenon.Stanford.EDU (James Edward Davis) wrote:
  2283.  
  2284. >>Yes, that would work but Id rather not leave memory allocated
  2285. >>in the system heap. But your right about another being installed
  2286. >>over mine. I allocate a small block in the system heap that just
  2287. >>jumps to my code in the application heap. When I want to deinstall,
  2288.  
  2289. >I hope you remember to flush the cache when you change this 
  2290. >value...
  2291.  
  2292. Why.. thats an excellent point. I dont flush it, but it seems to
  2293. work fine on my C610. I think Ive been very lucky.. Ill go change
  2294. that. Unless anyone can think of a legit reason its working.
  2295.  
  2296. Thanks,
  2297. James
  2298.  
  2299. +++++++++++++++++++++++++++
  2300.  
  2301. >From kluev@jonathan.srcc.msu.su (Kluev)
  2302. Date: Wed, 24 Aug 94 21:13:06 +0400
  2303. Organization: (none)
  2304.  
  2305. In article <jedavis.777679251@Xenon.Stanford.EDU>
  2306. jedavis@Xenon.Stanford.EDU (James Edward Davis) wrote:
  2307.  
  2308. > h+@nada.kth.se (Jon W{tte) writes:
  2309. > >In article <jedavis.777610202@Xenon.Stanford.EDU>,
  2310. > >jedavis@Xenon.Stanford.EDU (James Edward Davis) wrote:
  2311. > >>Yes, that would work but Id rather not leave memory allocated
  2312. > >>in the system heap. But your right about another being installed
  2313. > >>over mine. I allocate a small block in the system heap that just
  2314. > >>jumps to my code in the application heap. When I want to deinstall,
  2315. > >I hope you remember to flush the cache when you change this 
  2316. > >value...
  2317. > Why.. thats an excellent point. I dont flush it, but it seems to
  2318. > work fine on my C610. I think Ive been very lucky.. Ill go change
  2319. > that. Unless anyone can think of a legit reason its working.
  2320.  
  2321. This depends on processor type and what your code is looked like.
  2322.  
  2323. If it is looked like that:
  2324.   JMP Address; 0x4EF9 0x12345678; where 0x12345678 is modified address,
  2325. you need to flush cache on 040 processors.
  2326.  
  2327. If it is looked like this:
  2328.   MOVE.L *+$0006, -(sp); 0x2F3A0004;
  2329.   RTS;                   0x4E75
  2330.   DC.L 0x12345678;       0x12345678; where 0x12345678 is modified addr,
  2331. don't worry about flushing cache. (DC.L will not run as code.)
  2332.  
  2333. /* From MacTech magazine */
  2334.  
  2335. Michael Kluev.
  2336.  
  2337. ---------------------------
  2338.  
  2339. End of C.S.M.P. Digest
  2340. **********************
  2341.  
  2342.  
  2343. ˇ