From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-071 Date: Mon, 28 Nov 1994 18:41:24 +0100 (MET) C.S.M.P. Digest Mon, 28 Nov 94 Volume 3 : Issue 71 Today's Topics: (PPC) MDEF's in application code Getting The PSN or Sig of AE Client Is THINK Pascal dead? Newbie Q:Why no DisposeHandle-ReleaseResource call? Prograph 2.5 [Q] Programming with the QuickTime toolkit The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier (pottier@clipper.ens.fr). The digest is a collection of article threads from the internet newsgroup comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi- regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail help@anon.penet.fi for more information). Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at nef.ens.fr). Article threads are not added to the digest until the last article added to the thread is at least two weeks old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The digest is officially distributed by two means, by email and ftp. If you want to receive the digest by mail, send email to listserv@ens.fr with no subject and one of the following commands as body: help Sends you a summary of commands subscribe csmp-digest Your Name Adds you to the mailing list signoff csmp-digest Removes you from the list Once you have subscribed, you will automatically receive each new issue as it is created. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest. Questions related to the ftp site should be directed to scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP digest are available there. Also, the digests are available to WAIS users. To search back issues with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html. ------------------------------------------------------- >From tcarsten@cayman.jpmorgan.com (Tom Carstensen) Subject: (PPC) MDEF's in application code Date: 25 Oct 1994 16:25:54 GMT Organization: J.P. Morgan & Co Before PPC, I would load a stub 'MDEF' and set the proc ptr: typedef struct GenericMDEF { short JMPInstruction; void *defProc; } GenericMDEF; mdefHdl = GetResource('MDEF', 200); /* sub def */ (**((GenericMDEF **) mdefHdl)).defProc = myMdefProc; NOW, with PPC, I'm doing: (**((GenericMDEF **) mdefHdl)).defProc = NewMenuDefProc(myMdefProc); which, with code warrior, creates a new routine descriptor, and sets it up appropriately. This does not work. I've read IM PowerPC System Software - but it's somewhat confusing. If I'm defining an accelerated resource, than I need a routine descriptor that tells what kind of code is ahead. I thought the above should work, assuming the menu manager uses CallUniversalProc to call the menu definition procedure. BTW - I'm using Code warrior in the above example. Thanks for any hints. Tom Carstensen -- -- ___ Thomas Carstensen //__/ 60 Wall Street 17th Floor tcarsten@jpmorgan.com /__// New York, NY 10260 tomc@digex.access.net Morgan 212.648.4584 +++++++++++++++++++++++++++ >From d88-bli@xbyse.nada.kth.se (Bo Lindbergh) Date: 31 Oct 1994 16:31:38 GMT Organization: Royal Institute of Technology, Stockholm, Sweden In article tcarsten@cayman.jpmorgan.com (Tom Carstensen) writes: [mostly correct example of stub MDEF hacking deleted] Try bracketing the struct definition with alignment pragmas: #if defined(powerc) || defined (__powerc) #pragma options align=mac68k #endif typedef struct GenericMDEF { short JMPInstruction; void *defProc; } GenericMDEF; #if defined(powerc) || defined(__powerc) #pragma options align=reset #endif Without them, you'll get two bytes of padding between the short and the void *. /Bo Lindbergh +++++++++++++++++++++++++++ >From Graham@impro.demon.co.uk (Graham) Date: Wed, 9 Nov 1994 17:02:12 GMT Organization: N/A I use the following routines to do this- on 68K macs it defaults to the old way of creating a stub for the jump, on PowerMacs it creates a routine dscriptor, so the same code works in all cases. try it. #include "MixedMode.h" typedef struct { short Jmp; // jmp instruction void* Routine; // address to jump to } JmpInstructionTemplate; Handle GetUniversalFunctionHandle(ProcPtr functionAddress,ProcInfoType pInfo); void PatchJmpInstruction(void* patchAddress, void* jumpAddress); Handle GetUniversalFunctionHandle(ProcPtr functionAddress,ProcInfoType pInfo) { Handle pHNullProc = NULL; ISAType isa; UniversalProcPtr axDEFUPP; isa = GetCurrentISA(); if (isa == kPowerPCISA) { pHNullProc = NewHandle(sizeof(RoutineDescriptor)); axDEFUPP = NewRoutineDescriptor(functionAddress,pInfo,isa); BlockMove(axDEFUPP, *pHNullProc, sizeof(RoutineDescriptor)); DisposeRoutineDescriptor(axDEFUPP); } else { pHNullProc = NewHandle(sizeof(JmpInstructionTemplate)); PatchJmpInstruction(*pHNullProc, (void*)functionAddress); } return(pHNullProc); } void PatchJmpInstruction(void* patchAddress, void* jumpAddress) { JmpInstructionTemplate* aJmpInstructionPtr; aJmpInstructionPtr = (JmpInstructionTemplate *) patchAddress; aJmpInstructionPtr->Jmp = 0x4EF9; aJmpInstructionPtr->Routine = jumpAddress; } You have to pass the proc info type for the routine, which youll have to look up in the universal headers, and the proc ptr to your MDEF function, it returns a handle which you simply stuff into the relevant defProc field. Apple DTS gave me the bones for this, so it even has the "official" stamp of approval! ************************************************************************ * MHROTD, Graham. (Sorry, I haven't got time to think of a witty signature) +++++++++++++++++++++++++++ >From rang@winternet.com (Anton Rang) Date: 10 Nov 1994 14:33:59 GMT Organization: Trillium Research, Inc. In article Graham@impro.demon.co.uk (Graham) writes: >I use the following routines to do this- on 68K macs it defaults to the >old way of creating a stub for the jump, [...] Don't forget the posting last month from someone who had created a six-byte handle to hold their 'JMP $xxx' instruction and found that when the handle was moved by the memory manager, the i-cache wasn't flushed 'cause the handle was too small. :) -- Anton Rang (rang@winternet.com) +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Fri, 11 Nov 1994 05:15:43 +1200 (NZST) Organization: (none) rang@winternet.com (Anton Rang) writes: > In article Graham@impro.demon.co.uk (Graham) writes: > >I use the following routines to do this- on 68K macs it defaults to the > >old way of creating a stub for the jump, [...] > > Don't forget the posting last month from someone who had created a > six-byte handle to hold their 'JMP $xxx' instruction and found that > when the handle was moved by the memory manager, the i-cache wasn't > flushed 'cause the handle was too small. :) I missed that one. But I've never understood why people use the "six-byte resource" trick when it's so easy to use a "ten-byte resource" trick that is I-cache safe. -- Bruce --------------------------- >From Jonathan Gary Subject: Getting The PSN or Sig of AE Client Date: Tue, 8 Nov 1994 19:59:50 GMT Organization: Eastman Kodak I'm trying to get the the PSN of the process that sends me an AE. I can get the address from the event, but how do I get at the PSN? +++++++++++++++++++++++++++ >From wysocki@netcom.com (Chris Wysocki) Date: Fri, 11 Nov 1994 06:52:40 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) In article , Jonathan Gary wrote: >I'm trying to get the the PSN of the process that sends me an AE. I can >get the address from the event, but how do I get at the PSN? The following routine should work: // ---------------------------------------------------------------------- // CAppleEvent::GetProcessSerialNumber // ---------------------------------------------------------------------- void CAppleEvent::GetProcessSerialNumber(ProcessSerialNumber& thePSN) const { DescType actualType; Size actualSize; TargetID theTargetID; FailOSErr(AEGetAttributePtr(&fMessage, keyAddressAttr, typeTargetID, &actualType, &theTargetID, sizeof(theTargetID), &actualSize)); FailOSErr(GetProcessSerialNumberFromPortName(&theTargetID.name, &thePSN)); } I believe that the sending process needs to be running on the same machine as the target process for this to work, since PSNs are only unique to a particular machine. Chris. --------------------------- >From bernier@dialup.francenet.fr (Jean-Yves Bernier) Subject: Is THINK Pascal dead? Date: Fri, 04 Nov 1994 11:14:55 +0100 Organization: SPECTRA Soft Excuse-me if the topic has already been discussed here (I am a newcomer) but I have see no such thing in the 100 last articles, and I could not figure a more suitable group. I am one of the many THINK Pascal users left in the dark by Symantec, after the PowerPC. I have thousand of lines of Pascal to port to the PowerPC and I don't want to loose the advantages of THINK Pascal (the wonderful source-level debugger, among others). What is the official status of THINK Pascal? Will ever exist a PowerPC version? Is it dead? I am a registered user, but I receive absolutely no information from Symantec. Have they e-mail support? Thanks. - ------------------------- Jean-Yves Bernier - SPECTRA bernier@dialup.francenet.fr - ------------------------- +++++++++++++++++++++++++++ >From nick+@pitt.edu ( nick.c ) Date: Fri, 04 Nov 1994 10:49:30 -0500 Organization: The Pitt, Chemistry Yes, very dead. I would not expect any udates or new versions. That said a lot of folks still use it. It should be possible to port your code to CodeWarrrior Pascal (one of the compilers included with the CodeWarrior Gold or Bronze CD). The Gold version runs native (fat - I think) and compiles for PPC. Internet: nick+@pitt.edu _/ _/ _/ _/_/_/ _/ _/ eWorld: nick _/_/ _/ _/ _/ _/ _/_/_/ CIS: 71232,766 _/ _/_/ _/ _/ _/ _/ http://www.pitt.edu/~nick/ _/ _/ _/ _/_/_/ _/ _/ +++++++++++++++++++++++++++ >From lbotez@picard.cs.wisc.edu (Lynda Botez) Date: 6 Nov 1994 17:36:45 GMT Organization: U of Wisconsin CS Dept Er, Think Pascal isn't really dead, it's just comatose. If you need to convert stuff over to the powerpc, though, I would suggest you look into CodeWarrior. They actually have a pascal powerpc compiler (its in beta, but I would imagine it works pretty good)... and I doubt Symantec will bother with Think Pascal. Also, I think most of the programmers that developed Think Pascal are now working for Metrowerks (the company that owns CodeWarrior); so you can imagine that Think Pascal is not long for this world.. +++++++++++++++++++++++++++ >From johnmce@world.std.com (John McEnerney) Date: Sun, 6 Nov 1994 19:11:16 GMT Organization: The World Public Access UNIX, Brookline, MA lbotez@picard.cs.wisc.edu (Lynda Botez) writes: >Also, I think most of the programmers that developed Think Pascal are now >working for Metrowerks (the company that owns CodeWarrior); so you can >imagine that Think Pascal is not long for this world.. For anyone who's interested, the programmers who developed THINK Pascal are: Me (at Metrowerks these days) David Neal (director of Symantec's Mac language group) Rich Siegel (of Bare Bones software fame) Pete Maruhnic (author of CA's Realizer for Windows) So only one of us ended up at Metrowerks. Still, the product is pretty much dead wrt PowerPC, as much my fault as anyone else's: a lot of the code was written in assembly language, the context-switch mechanism would probably not survive a port to the PPC, etc. It is rumored that Symantec still has plans in the Pascal arena (but as you might imagine they don't tell me that sort of thing anymore) -- John McEnerney, Metrowerks PowerPC Product Architect +++++++++++++++++++++++++++ >From RobTerrell@vmedia.com (Rob Terrell) Date: 6 Nov 1994 21:26:52 GMT Organization: Jecta Development Corp. John McEnerney said: > So only one of us ended up at Metrowerks. Still, the product is pretty > much dead wrt PowerPC, as much my fault as anyone else's: a lot of the > code was written in assembly language, the context-switch mechanism > would probably not survive a port to the PPC, etc. It is rumored that > Symantec still has plans in the Pascal arena (but as you might imagine > they don't tell me that sort of thing anymore) Yeah, there was a rumor in MacWeek regarding this. I doubt it. The Symantec folks were real arrogant on the topic of the death of Pascal at the WWDC. So, John, what's happening with Metrowerks' Pascal? I would totally abandon Think Pascal if CW supported an Object Pascal. Rob +++++++++++++++++++++++++++ >From siegel@netcom.com (Rich Siegel) Date: Mon, 7 Nov 1994 17:57:38 GMT Organization: Bare Bones Software In article <39j47d$gfq@spool.cs.wisc.edu> lbotez@picard.cs.wisc.edu (Lynda Botez) writes: > >Also, I think most of the programmers that developed Think Pascal are now >working for Metrowerks (the company that owns CodeWarrior); so you can >imagine that Think Pascal is not long for this world.. > That is not true. Of the four people most directly involved in the development of THINK Pascal: - one is at Metrowerks - one is director of the development tools group at Symantec - one is off doing something else (I don't recall where) - one is president and CEO of his own software company When this question was recently posted to Symantec personnel at a recent BCS MacTechGroup meeting, the response was (basically) that they plan to work with certain third-party compiler makers to produce a Pascal solution for Rainbow (their new development environment that is currently under development). R. -- Rich Siegel % siegel@netcom.com % President & CEO, Bare Bones Software Inc. --> For information about BBEdit, finger bbedit@world.std.com <-- +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Tue, 08 Nov 1994 11:23:59 +0800 Organization: NCRPDA, Curtin University In article <39jhms$ja@redstone.interpath.net>, RobTerrell@vmedia.com (Rob Terrell) wrote: >Yeah, there was a rumor in MacWeek regarding this. I doubt it. The >Symantec folks were real arrogant on the topic of the death of Pascal >at the WWDC. A Symantec fellow told me that the rumour is crap. There is no Symantec plans for a PPC pascal compiler. >So, John, what's happening with Metrowerks' Pascal? I would totally >abandon Think Pascal if CW supported an Object Pascal. You and me both. I'm strugling on with THINK Pascal waiting for objects to show up in MW Pascal. MW Pascal is scheduled to go 1.0 without objects in January (CW5), and MW Object Pascal is scheduled for CW6 in May (it better be there, otherwise Greg will have to face down some heckling at the WWDC :-). The best you can do to help is to a) make sure MW knows that Object Pascal is what you need; b) buy MW CW; c) feed any bugs back to the MW bug report line as precisely as you can. That's what i've been doing, an Marcel has been very good at fixing bugs (such that basically every bug I have reported has been fixed by the next version). Enjoy, Peter. -- Peter N Lewis - Macintosh TCP fingerpainter FTP my programs from redback.cs.uwa.edu.au:Others/PeterLewis/ or amug.org:pub/peterlewis/ or nic.switch.ch:software/mac/peterlewis/ +++++++++++++++++++++++++++ >From ingemar@lysator.liu.se (Ingemar Ragnemalm) Date: 8 Nov 1994 08:17:05 GMT Organization: (none) johnmce@world.std.com (John McEnerney) writes: >lbotez@picard.cs.wisc.edu (Lynda Botez) writes: >>Also, I think most of the programmers that developed Think Pascal are now >>working for Metrowerks (the company that owns CodeWarrior); so you can >>imagine that Think Pascal is not long for this world.. >For anyone who's interested, the programmers who developed THINK Pascal are: >Me (at Metrowerks these days) >David Neal (director of Symantec's Mac language group) >Rich Siegel (of Bare Bones software fame) >Pete Maruhnic (author of CA's Realizer for Windows) >So only one of us ended up at Metrowerks. Still, the product is pretty >much dead wrt PowerPC, as much my fault as anyone else's: a lot of the >code was written in assembly language, the context-switch mechanism would >probably not survive a port to the PPC, etc. MetroWerks Pascal is sort of ok as replacement. It doesn't have Instant, it's debugger is far from the elegance of Lightsbug, but it works. But I wonder, why wasn't the debugger integrated with the compiler? No flames, but I really didn't think a Think Pascal decveloper would let so many Think C flaw through. Why mimick the clumsy Think C when Think Pascal is so much better (language issues aside). Imagine a system where you step and set breakpoints in the editor, while the editor and the debugger communicated with Apple Events. I can't see the problem, as long as we don't demand Instant. >It is rumored that Symantec >still has plans in the Pascal arena (but as you might imagine they don't >tell me that sort of thing anymore) Long ago, I bought Think C. It took several years before I got any feedback - probably that was after buying Think Pascal. When Symantec now tries to convince me that I should get SC++, I bought CodeWarrior instead. Much better C environment, and a future for my Pascal code. Fortunately, my Think Pascal isn't dead yet. I guess it will stop working somewhere between 7.5 and 8.0 or so, but not yet. -- - - Ingemar Ragnemalm, PhD Image processing, Mac shareware games E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se +++++++++++++++++++++++++++ >From palais@binah.cc.brandeis.edu Date: 12 Nov 1994 19:55:02 GMT Organization: Brandeis University One should also mention that Language Systems is making a very credible effort at developing an industrial strength Pascal compiler. Unlike CodeWarrior, the LS version runs under MPW, which you may or may not find an advantage. But for those of us who got hooked on Object Pascal before Apple pulled the rug out from under us, it is the only way to go, since it does compile Object Pascal while CodeWarrior does not. R. Palais --------------------------- >From roxanne@bnr.ca (Roxanne Friesen) Subject: Newbie Q:Why no DisposeHandle-ReleaseResource call? Date: Mon, 07 Nov 1994 11:53:32 -0400 Organization: Bell-Northern Research Ltd. I'm trying to get a better *handle* on when handles should be disposed of and resources released. In the first sample function below, I would have thought that the alias handle should be disposed of once the resource has been written to the resource file but this function doesn't do that. Am I wrong, is this function wrong, or is it simply not necessary, in this case, to dispose of the handle? (For the sake of simplifying the samples, assume I'm writing to my apps own resource fork and not a prefs file of some kind ... or does that make a difference?) FUNCTION doCreateAlias(fileSpec:FSSpec):OSErr; VAR alisHandle : AliasHandle; result : OSErr; BEGIN result := NewAlias(NIL, fileSpec, alisHandle); IF (alisHandle <> NIL) THEN BEGIN AddResource(Handle(alisHandle), rAliasType, 128, 'File Alias'); result := ResError; IF (result = NoErr) THEN BEGIN WriteResource(Handle(alisHandle)); result := ResError; END; END; doCreateAlias := result; END; {doCreateAlias} In the second sample function below, again, I would have thought that the resource should be released once I'm finished with it but, again, this function doesn't do that. Am I wrong, is this function wrong, or is it simply not necessary, in this case, to release the resource? FUNCTION setResStr(rsrcType:ResType; rsrcID:INTEGER; content:STR255):OSErr; VAR rsrcHdl : Handle; result : OSErr; BEGIN rsrcHdl := GetResource(rsrcType, rsrcID); result := ResError; IF (rsrcHdl <> NIL) THEN BEGIN SetHandleSize(rsrcHdl, LENGTH(content) + 1); BlockMove(@content, rsrcHdl^, LENGTH(content) + 1); ChangedResource(rsrcHdl); result := ResError; IF (result = NoErr) THEN BEGIN WriteResource(rsrcHdl); result := ResError; END; END; setResStr := result; END; {setResStr} Any help, hints, tips, suggestions would be appreciated. Roxanne. -- Roxanne Friesen Bell-Northern Research Ltd. roxanne@bnr.ca +++++++++++++++++++++++++++ >From jones.794@osu.edu (Matt Jones) Date: Mon, 07 Nov 1994 19:15:24 +0500 Organization: The Ohio State University In article , roxanne@bnr.ca (Roxanne Friesen) wrote: > I'm trying to get a better *handle* on when handles should be disposed of > and resources released. > > In the first sample function below, I would have thought that the alias > handle should be disposed of once the resource has been written to the > resource file but this function doesn't do that. Am I wrong, is this > function wrong, or is it simply not necessary, in this case, to dispose of > the handle? (For the sake of simplifying the samples, assume I'm writing > to my apps own resource fork and not a prefs file of some kind ... or does > that make a difference?) > > FUNCTION doCreateAlias(fileSpec:FSSpec):OSErr; > VAR > alisHandle : AliasHandle; > result : OSErr; > > BEGIN > result := NewAlias(NIL, fileSpec, alisHandle); > IF (alisHandle <> NIL) THEN BEGIN > AddResource(Handle(alisHandle), rAliasType, 128, 'File Alias'); > result := ResError; > > IF (result = NoErr) THEN BEGIN > WriteResource(Handle(alisHandle)); > result := ResError; > END; > END; > > doCreateAlias := result; > END; {doCreateAlias} > > > In the second sample function below, again, I would have thought that the > resource should be released once I'm finished with it but, again, this > function doesn't do that. Am I wrong, is this function wrong, or is it > simply not necessary, in this case, to release the resource? > > FUNCTION setResStr(rsrcType:ResType; rsrcID:INTEGER; content:STR255):OSErr; > VAR > rsrcHdl : Handle; > result : OSErr; > > BEGIN > rsrcHdl := GetResource(rsrcType, rsrcID); > result := ResError; > > IF (rsrcHdl <> NIL) THEN BEGIN > SetHandleSize(rsrcHdl, LENGTH(content) + 1); > BlockMove(@content, rsrcHdl^, LENGTH(content) + 1); > ChangedResource(rsrcHdl); > result := ResError; > > IF (result = NoErr) THEN BEGIN > WriteResource(rsrcHdl); > result := ResError; > END; > END; > > setResStr := > result; > > END; {setResStr} > > > Any help, hints, tips, suggestions would be appreciated. > Roxanne. > > -- > Roxanne Friesen > Bell-Northern Research Ltd. > roxanne@bnr.ca If your compiler is any good, it checks if any of the handles in local storage are still attached. ( I think ) Otherwise, you would be unable to find the handles to dispose of them later. However, this is tricky internal compiler stuff, much like pre-initialized variables. I always explicitly dispose of handles since the moment you assume your compiler does it for you, it stops. - ------------------------------------------------------------------------ | it won't give up it wants me dead | |\ | | | /| | jones.794 | | goddamn this noise inside my head | | \ | | | / | | @ohio-state.edu | | Trent Reznor | | \| | |/ | | Stop the Clipper! | - ------------------------------------------------------------------------ +++++++++++++++++++++++++++ >From sigurasg@rhi.hi.is (Sigurdur Asgeirsson) Date: Tue, 08 Nov 1994 09:49:56 -0100 Organization: University of Iceland In article , roxanne@bnr.ca (Roxanne Friesen) wrote: [snip] > In the first sample function below, I would have thought that the alias > handle should be disposed of once the resource has been written to the > resource file but this function doesn't do that. Am I wrong, is this > function wrong, or is it simply not necessary, in this case, to dispose of > the handle? [snip] > FUNCTION doCreateAlias(fileSpec:FSSpec):OSErr; > VAR > alisHandle : AliasHandle; > result : OSErr; > > BEGIN > result := NewAlias(NIL, fileSpec, alisHandle); > IF (alisHandle <> NIL) THEN BEGIN > AddResource(Handle(alisHandle), rAliasType, 128, 'File Alias'); > result := ResError; > > IF (result = NoErr) THEN BEGIN > WriteResource(Handle(alisHandle)); > result := ResError; > END; > END; > > doCreateAlias := result; > END; {doCreateAlias} > > [second code example snipped for brevity] There is no need in this case to dispose the handle, unless the AddResource call fails, in which case the handle should be disposed of with DisposeHandle (since the handle is not a resource if the call fails - see below). In general there is no need to dispose of resource handles, because they are the responsibility of the Resource Manager. Resource handles must NEVER be disposed of via DisposeHandle, since that confuses the Resource Manager and you end up with heap corruption. (The Resource Manager does a DisposeHandle for all loaded resources in a resource file when the resource file is closed). If you feel the need to dispose of a resource handle when you're done with it (maybe because you'd like to free the memory that the resource is using) do it with the ReleaseResource call. It's generally better though to mark your resources as purgeable and leave it up to the Memory and Resource Managers to free the memory when needed. Be sure however, to use LoadResource in this case and mark the resource unpurgeable (or lock it) if you need to be sure that it doesn't "go away" while you're using it. -- Sigurdur Asgeirsson | "Well you know, C isn't that hard, void (*(*f[])())() Kambasel 26 | for instance declares f as an array of unspecified 109 Reykjavik, Iceland | size, of pointers to functions that return pointers to sigurasg@rhi.hi.is | functions that return void... I think" +++++++++++++++++++++++++++ >From johns@efn.org (John Selhorst) Date: Tue, 8 Nov 1994 14:43:55 GMT Organization: hisself In article , jones.794@osu.edu (Matt Jones) wrote: [ stuff from Roxanne deleted ] > If your compiler is any good, it checks if any of the handles in local > storage are still attached. ( I think ) Otherwise, you would be unable to > find the handles to dispose of them later. However, this is tricky internal > compiler stuff, much like pre-initialized variables. I always explicitly > dispose of handles since the moment you assume your compiler does it for > you, it stops. Wrong. This is not fancy compiler stuff. The handles Roxanne was referring to belong to the resource manager and the resource manager will dispose of them when it needs to. Johnny johns@efn.org +++++++++++++++++++++++++++ >From Scott.Francis@SuperMac.com (eScott Francisternet alt.bbs.lists alt.bbs.lists.d alt.bbs.majorbbs alt.bbs.metal alt.bbs.pcboard alt.bbs.pcbuucp alt.bbs.renegade alt.bbs.searchlight alt.bbs.unixbbs alt.bbs.unixbbs.uniboard alt.bbs.uupcb alt.bbs.waffle alt.bbs.wildcat alt.beadworld alt.) Date: Tue, 08 Nov 1994 10:49:31 -0800 Organization: Radius In article , roxanne@bnr.ca (Roxanne Friesen) wrote: > I'm trying to get a better *handle* on when handles should be disposed of > and resources released. > In both cases the resource handle should be released with ReleaseResource(). Many programmers have not always done so, particularly when building apps since the res file will be closed (and all resources from that file released) when the app quits. While calling ReleaseResource() is then not strictly necessary, it is good form, and can help some types of memory problems. Another dimension to the problem: If you will be refetching resources again and again, you might want to make the preloadable, and *not* release them. This will keep them in memory and speed up the calls to GetResource(). --Scott +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 8 Nov 1994 15:39:07 -0800 Organization: SRI International, Menlo Park, CA In article roxanne@bnr.ca (Roxanne Friesen) writes: >I'm trying to get a better *handle* on when handles should be disposed of >and resources released. Simple. Handle are disposed and Resources are released. >BEGIN > result := NewAlias(NIL, fileSpec, alisHandle); > IF (alisHandle <> NIL) THEN BEGIN > AddResource(Handle(alisHandle), rAliasType, 128, 'File Alias'); At this point aliasHandle is no longer a plain ol handle. After you call Addresource the handle you supply becomes a ResourceHandle. If its a resource handle what are you supposed to do with it? Yep ReleaseResource. DON'T CALL DISPOSEHANDLE AFTER YOU CALLED ADDRESOURCE ON THAT HANDLE. > >In the second sample function below, again, I would have thought that the >resource should be released once I'm finished with it but, again, this >function doesn't do that. Am I wrong, is this function wrong, or is it >simply not necessary, in this case, to release the resource? In the example that was shown, you don't have to call release resource if you might use that resource again. If you don't want it around go ahead and call release resource. If the resource file is closed, the Resource handles will be released. Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 8 Nov 1994 15:40:13 -0800 Organization: SRI International, Menlo Park, CA In article jones.794@osu.edu (Matt Jones) writes: >If your compiler is any good, it checks if any of the handles in local >storage are still attached. ( I think ) Otherwise, you would be unable to >find the handles to dispose of them later. However, this is tricky internal >compiler stuff, much like pre-initialized variables. I always explicitly >dispose of handles since the moment you assume your compiler does it for >you, it stops. Huh? Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Wed, 09 Nov 1994 11:27:40 +0800 Organization: NCRPDA, Curtin University In article , roxanne@bnr.ca (Roxanne Friesen) wrote: >In the first sample function below, I would have thought that the alias >handle should be disposed of once the resource has been written to the >resource file but this function doesn't do that. Am I wrong, is this >function wrong, or is it simply not necessary, in this case, to dispose of >the handle? (For the sake of simplifying the samples, assume I'm writing >to my apps own resource fork and not a prefs file of some kind ... or does >that make a difference?) First off, you must never call DisposeHandle on a resource handle, nor ReleaseResource on a non-resource handle. Bad THings(tm) will happen. There are a pair fo inits (DoubleTrouble and DisposeResource or some such) that catch bugs like this, available from ftp.apple.com:/mac/dts/ I believe. Second, when you write a resource to a file, it's not necessayr to release it afterwards, since it will be automatically released when the resource file is closed (which tends to be quite soon afterwards anyway). Also, you can set the handle to be purged (HPurge) and then it'll be released when memory is needed, but not until. Make sure to call GetResource again to reload the (possibly) purged handle before reusing it. Enjoy, Peter. -- Peter N Lewis - Macintosh TCP fingerpainter --------------------------- >From fallside@rahul.net (David C. Fallside) Subject: Prograph 2.5 Date: 10 Nov 1994 06:39:19 GMT Organization: a2i network I recently accepted a $59.95 offer for Prograph 2.5. The promo blurb "Very High Level Pictorial Object-Oriented Programming Environment" seems to be accurate, and having worked my way through half of the tutorials, it seems that it should be possible to develop complex applications. But I'm not a professional programmer, and haven't found anyone else who has ever heard of Prograph. Any comments from Netland? Thank you. David ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'd rather be on the river .... K1/4, SQRT/3 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +++++++++++++++++++++++++++ >From nick+@pitt.edu ( nick.c ) Date: Thu, 10 Nov 1994 11:42:38 -0500 Organization: The Pitt, Chemistry In article , fallside@rahul.net (David C. Fallside) wrote: > I recently accepted a $59.95 offer for Prograph 2.5. The promo blurb "Very > High Level Pictorial Object-Oriented Programming Environment" seems to be > accurate, and having worked my way through half of the tutorials, it seems > that it should be possible to develop complex applications. But I'm not a > professional programmer, and haven't found anyone else who has ever heard > of Prograph. Any comments from Netland? Thank you. Prograph was my first environment (not counting hypercard), and I consider that a mistake. Don't get me wrong - prograph is both a great concept and a great engineering feet. I still argue that inconic input will be the way we'll all code 10 years from now (or sooner). However, prograph is a dual mode environment, it allows you to program at a low level, but defaults to a high level environment by use of it's integrated class library. As a result, and with the added factor there is very little sample code or literature, it's hard to tell where the library ends and the toolbox begins. You can generate nice (albeit large and slow) apps with 2.5.2 - nicer ones with CPX - but you won't learn anything about Mac programming with it. To learn how to program the Mac you'll need to learn a classical low level language (Pascal or C would be best), and when you do you'll find you can generate much smaller, faster binaries and have access to a wealth of established library code and example code from all over the world. My guess is most "professional" programmers, don't want to give up those advantages. Prograph was marketed as a non-programmers programming language, and I think that's still true. However, as I said above, it does allow low level coding, is very powerfull, and has the best interface and debugger I've ever seen. It's a glimpse of the future of programming, and worth knowing, just remeber you get paid in the present. Internet: nick+@pitt.edu _/ _/ _/ _/_/_/ _/ _/ eWorld: nick _/_/ _/ _/ _/ _/ _/_/_/ CIS: 71232,766 _/ _/_/ _/ _/ _/ _/ http://www.pitt.edu/~nick/ _/ _/ _/ _/_/_/ _/ _/ +++++++++++++++++++++++++++ >From pjensen@netcom.com (Peter Jensen) Date: Thu, 10 Nov 1994 16:53:40 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) fallside@rahul.net (David C. Fallside) writes: >I recently accepted a $59.95 offer for Prograph 2.5. The promo blurb "Very >High Level Pictorial Object-Oriented Programming Environment" seems to be >accurate, and having worked my way through half of the tutorials, it seems >that it should be possible to develop complex applications. But I'm not a >professional programmer, and haven't found anyone else who has ever heard >of Prograph. Any comments from Netland? Thank you. >David Prograph 2.5 is the predecessor of Prograph CPX 1.x, which is the Prograph development environment with all the bells and whistles. $60 is a great price for 2.5 which has the full language implementation found in CPX. CPX has a rich class library a'la TCL/MacApp and a user-modifiable GUI Builder. I use Prograph full-time to develop complex commercial applications. There are some very intriguing apps with high-volume potential being developed in Prograph right now. Prograph has arguably one of the best debuggers ever implemented (in the interpretive mode). There is an optimizing compiler that generates stand-alone apps. The code isn't as fast or tight as C/C++ but you get RTTI, garbage collection, automatic deref of handles/pointers, cool list management stuff, and of course, a gorgreous visual syntax that prevents syntax errors via constrained input. Visual Programming is for real; and Prograph is the most "real" of the new generation. It's one of the things that makes the Mac a special development platform. Sometime next year there will be a Windows Prograph and the framework will become cross-platform. Plus they're developing DAL/SQL database tools that will allow you to do everything you can do in Omnis/4D but drop into Prograph if you want real programming power. For compute-bound operations it's fairly straightforward to import external primitives written in C if you feel the need for speed. In normal usage, you can't tell whether well-crafted apps were written in Prograph or C++ (well, maybe you can, since they're delivered earlier!). I'm very happy with Prograph. net.persons interested in Prograph can join the commotion over on comp.lang.prograph. Also, Kurt Schmucker of Apple's ATG has written an extensive review of CPX in November's MacTech. Look for more Prograph articles in coming issues. Peter Jensen pjensen@netcom.com Pepper Tree Design, Inc. Santa Clara, CA "Software crafted from the choicest of electrons" (tm) +++++++++++++++++++++++++++ >From howardb@enlil.premenos.com (Howard Berkey) Date: 10 Nov 1994 17:03:19 GMT Organization: Premenos Corp In article , David C. Fallside wrote: >I recently accepted a $59.95 offer for Prograph 2.5. The promo blurb "Very >High Level Pictorial Object-Oriented Programming Environment" seems to be >accurate, and having worked my way through half of the tutorials, it seems >that it should be possible to develop complex applications. But I'm not a >professional programmer, and haven't found anyone else who has ever heard >of Prograph. Any comments from Netland? Thank you. >David > I've never used it myself but it gets a lot of praise from those who have. You might want to check out comp.lang.prograph... I'm sure you'll get a lot of info there. -H- --------------------------- >From ladan@cs.umd.edu (Ladan Gharai) Subject: [Q] Programming with the QuickTime toolkit Date: 2 Nov 1994 18:52:59 -0500 Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Hi everyone I am new to the QuickTime and am trying to understand how it works. I have a bunch of questions and would appreciate any answers. I need to write a player with very specific functionality. Going through the Inside the Mac: Quicktime I have the following questions: 1. A sample is defined as "A single element of a sequence of time-ordered data" does this mean that for a vedio a sample would be a frame? 2. What function calls should I use to be able to access a single frame? In the Inside the Mac it says that a programmer can access every frame. How? 3. Where does QuickTime store information about the frame rates (fps) of a movie? For example the frame rate that a movie was created with? 4. Is there a realtionship between frame rate (fps) and playback rate? 5. When QuickTime does not have enough time to display all the frames of a movie, it starts dropping frames. Is there a pattern to this frame dropping? For example does it drop everyother frame, or the third in every 3 frames? How does it decide which frames to drop? thanx Ladan +++++++++++++++++++++++++++ >From rich@cs.umd.edu (Richard Gerber) Date: 2 Nov 1994 19:44:03 -0500 Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 I am interested too. But specifically: from within a quicktime player is there any way to dynamically determine -- as the movie is playing -- which particular frames are being dropped. If not, what's the lowest level of granularity I can get to? rich - ---------- Richard Gerber Assistant Professor Department of Computer Science University of Maryland College Park, MD 20742 USA Email: rich@cs.umd.edu Tel: (301) 405-2710 FAX: (301) 405-6707 +++++++++++++++++++++++++++ >From ivan_cavero_belaunde@avid.com (Ivan Cavero Belaunde) Date: 8 Nov 1994 00:00:42 GMT Organization: Avid Technology, Inc. In article <3998qv$7id@mingus.cs.umd.edu>, ladan@cs.umd.edu (Ladan Gharai) wrote: > Hi everyone > > I am new to the QuickTime and am trying to understand how it works. I have > a bunch of questions and would appreciate any answers. I need to write a player > with very specific functionality. Going through the Inside the Mac: Quicktime > I have the following questions: > > 1. A sample is defined as "A single element of a sequence of time-ordered > data" does this mean that for a vedio a sample would be a frame? Yup. > 2. What function calls should I use to be able to access a single frame? In the > Inside the Mac it says that a programmer can access every frame. How? If I want the sample at time 10 on the first track: theTrack = GetMovieIndTrack(theMovie, 1); theMedia = GetTrackMedia(theTrack); mediaTime = TrackTimeToMediaTime(theTrack, 10); if (mediaTime != -1) { err = GetMediaSample(theMedia, sampleDataHandle, 0, &sampleDataSize, mediaTime, nil, nil, sampleDescriptionHandle, nil, 1, nil, &sampleFlags); > > 3. Where does QuickTime store information about the frame rates (fps) of a movie? > For example the frame rate that a movie was created with? It doesn't since the frame rate can vary over time throughout the movie. You can estimate it by walking each track by track edits via GetTrackNextInterestingTime and then figuring out the frame rate for each edit by looking at the edit rate for each edit as well as the durations of the samples spanned by the edit. > 4. Is there a realtionship between frame rate (fps) and playback rate? I'm not sure what you mean here. The QuickTime movie will never play at a better rate than its original stored rate - additionally, it is eminently possible to create a movie with too high a stored frame rate that will not play properly and will drop frames. > 5. When QuickTime does not have enough time to display all the frames of a > movie, it starts dropping frames. Is there a pattern to this frame dropping? > For example does it drop everyother frame, or the third in every 3 frames? > How does it decide which frames to drop? A movie has a "running clock" that tells it what "time" it is within the movie. When falling behind, QT will drop as many frames as necessary to catch up the frame being displayed with its running clock. The results are dependent on boatloads of factors, such as the horsepower of your machine, the bandwidth of your storage device, the seek speed of your storage device, the compression scheme used, the frame-differencing characteristics of the movie, and where within the movie the "playback head" is. There's no simple answer, sorry. Hope this helps. Followups redirected to comp.sys.mac.programmer. -Ivan - -- Ivan Cavero Belaunde (ivan_cavero_belaunde@avid.com) Avid VideoShop Lead Avid Technology, Inc. Disclaimer: All views expressed are entirely my own and do not reflect the opinions of Avid Technology, Inc. --------------------------- End of C.S.M.P. Digest **********************