From: pottier@clipper.ens.fr (Francois Pottier)
Subject: csmp-digest-v3-097
Date: Mon, 8 May 1995 18:38:11 +0200 (MET DST)
C.S.M.P. Digest Mon, 08 May 95 Volume 3 : Issue 97
Today's Topics:
Answer to your SetDeskCPat Woes Here
Extended Disk Initialization Manages woes
How do UPP's work?
Memory Allocation Question
QuickDraw GX Fan Club Page (correct address !)
Quicktime Musical Instruments
Threads and Stacks
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 newsgroups
comp.sys.mac.programmer.help, csmp.tools and csmp.misc. It is designed for
people who read news 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.
-------------------------------------------------------
>From fizzbomb@aol.com (FizzBomb)
Subject: Answer to your SetDeskCPat Woes Here
Date: Sun, 23 Apr 1995 13:58:04 -0400
Organization: Zyfno Zyne, Inc.
Well, I don't know if you guys got your SetDeskCPat problems straightened
out, but I have the answer right here. It comes to us from Craig
Marciniak (templardev@aol.com), author of shareware sensation Before
Dark. I tried it and it works! Enjoy!
FizzBomb <--> fizzbomb@aol.com
"And here it is"
- -----------
The Trap is very stable - just poorly documented!
here's what you need to do:
SetZone(SystemZone());
sysdeskPixPat = GetPixPat(theID);
if(sysdeskPixPat)
{
DetachResource((Handle)sysdeskPixPat);
SetDeskCPat(sysdeskPixPat);
}
SetZone(ApplicZone());
Also make sure that the right bits are set on the ppat resource (sys and
purge) so other applications that count on those attribute won't puke on
your patterns - AND DON'T use your own compression method on standard ppat
resources - make your own type...
Craig Marciniak
---------------------------
>From gspnx@di.unito.it (Fabrizio Oddone)
Subject: Extended Disk Initialization Manages woes
Date: Sat, 22 Apr 1995 12:05:35 +0200
Organization: Computer Science Faculty, Torino
I got the File System Manager SDK a while ago and browsing around I found
a useful chapter documenting a set of new system calls, namely:
DIXFormat, DIXZero, etc.
Problem: the Universal Headers (I am at 2.0a4) don't contain the function
prototypes of the Extended Disk Initialization Manager calls.
I am especially interested in calling DIXZero.
I have tried lots of undocumented _Pack2 selectors, but haven't found the
right one (and no, I don't want to spend days disassembling _Pack2 or
trying selectors one by one ;-) ).
Can some good soul point me towards some newer headers/docs?
(Please use also private e-mail, besides posting)
TIA,
--
Fabrizio Oddone <gspnx@di.unito.it>
http://www.di.unito.it/pub/WWW/www_student/apple/FabrizioOddone/
+++++++++++++++++++++++++++
>From jumplong@aol.com (Jump Long)
Date: 23 Apr 1995 12:46:41 -0400
Organization: America Online, Inc. (1-800-827-6364)
>I got the File System Manager SDK a while ago and browsing around I
>found a useful chapter documenting a set of new system calls, namely:
>DIXFormat, DIXZero, etc.
>
>Problem: the Universal Headers (I am at 2.0a4) don't contain the
>function prototypes of the Extended Disk Initialization Manager calls.
I know. I asked to have them added back before the FSM SDK shipped, but
there didn't get added until recently.
Until then, these will work for 68K code development:
extern pascal OSErr DIXFormat(short drvNum, Boolean fmtFlag, unsigned long
fmtArg, unsigned long *actSize)
THREEWORDINLINE(0x700C, 0x3F00, 0xA9E9);
extern pascal OSErr DIXZero(short drvNum, ConstStr255Param volName, short
fsid, short mediaStatus, short volTypeSelector, unsigned long volSize,
void *extendedInfoPtr)
THREEWORDINLINE(0x700E, 0x3F00, 0xA9E9);
extern pascal OSErr DIReformat(short drvNum, short fsid, ConstStr255Param
volName, ConstStr255Param msgText)
THREEWORDINLINE(0x7010, 0x3F00, 0xA9E9);
It should be easy enough to build routine descriptors and call these from
PPC code, too.
WARNING: DIXZero has a bug in current versions of the Disk Initialization
Package. If you pass a non-zero value in the mediaStatus to DIXZero, it
will call the Dialog Manager with a NULL DialogPtr (and that will likely
crash your system). Until you see something telling you how to determine
the problem has been fixed, don't call DIXZero with a non-zero mediaStatus
value.
- Jim Luther
---------------------------
>From rba26@cas.org (Brad Andrews)
Subject: How do UPP's work?
Date: Wed, 19 Apr 1995 12:16:29 GMT
Organization: Chemical Abstracts Service
Could someone either explain to me exactly how UPP's work, or where I can find
documentation on such? Do both 68K and PPC programs work well with such, or will
I have to #ifdef my code for each processor?
- -
Brad Andrews
randrews@cas.org
All opinions are strictly mine
+++++++++++++++++++++++++++
>From soori@netcom.com (Mahesh Sooriarachchi)
Date: Wed, 19 Apr 1995 14:53:10 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
In article <1995Apr19.121629.9113@chemabs.uucp> rba26@cas.org writes:
You would create a UPP by calling NewRoutineDescriptor() or a bunch of
different flavors of it, which ultimately calls NewRoutineDescriptor().
For instance, if you want a sound completion proc for playing sound from
a file, you would call FilePlayCompletionUPP(yourProc). This would return
you a FilePlayCompletionUPP which you can pass into SndStartFilePlay().
Once the sound has finished playing you can dispose the routine
descriptor by calling DisposeRoutineDescriptor(). You should get the New
Inside Mac book "PowerPC System Software" of something like that.
>Could someone either explain to me exactly how UPP's work, or where I can find
>documentation on such? Do both 68K and PPC programs work well with such, or will
>I have to #ifdef my code for each processor?
>
>---
>
>Brad Andrews
>randrews@cas.org
>All opinions are strictly mine
>
>
--
MicroSloppy - Making it all make half ass sense.
Where do you want to go today? None of your f$#*ing business.
Mahesh Soori. My openions are mine, not of my employer!
+++++++++++++++++++++++++++
>From jaks@netcom.com (Eric Jackson)
Date: Thu, 20 Apr 1995 02:20:15 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
In article <sooriD7AEoM.IB8@netcom.com>,
Mahesh Sooriarachchi <soori@netcom.com> wrote:
>In article <1995Apr19.121629.9113@chemabs.uucp> rba26@cas.org writes:
>
>You would create a UPP by calling NewRoutineDescriptor() or a bunch of
>different flavors of it, which ultimately calls NewRoutineDescriptor().
>For instance, if you want a sound completion proc for playing sound from
>a file, you would call FilePlayCompletionUPP(yourProc). This would return
>you a FilePlayCompletionUPP which you can pass into SndStartFilePlay().
>Once the sound has finished playing you can dispose the routine
>descriptor by calling DisposeRoutineDescriptor(). You should get the New
>Inside Mac book "PowerPC System Software" of something like that.
>
>
>>Could someone either explain to me exactly how UPP's work, or where I can find
>>documentation on such? Do both 68K and PPC programs work well with such, or will
>>I have to #ifdef my code for each processor?
>>
Also I don't know if you have found this out yet but you don't really need all
that many UPP's in your code. One place that you will need one is in making
a native call to TrackControl, and another place is in AEInstallEventHandler,
but its only in places where you are passing a pointer to a procedure to another
procedure that goes into the tool box that you even need to worry about UPP
troubles.
On the other hand when you are making a call from one procedure to another
inside of your own code you can do this just the same way you always did.
When you recompile your program with the universal headers you will get
compiler errors because of the type changes so you just use the right functions
to create your UPPs and your one your way.
Good Luck
Eric
+++++++++++++++++++++++++++
>From Bruce@hoult.actrix.gen.nz (Bruce Hoult)
Date: Fri, 21 Apr 1995 16:04:21 +1200 (NZDT)
Organization: (none)
rba26@cas.org (Brad Andrews) writes:
> Could someone either explain to me exactly how UPP's work, or where I can find
> documentation on such? Do both 68K and PPC programs work well with such, or will
> I have to #ifdef my code for each processor?
read Inside Macintosh: PowerPC System Software.
UPP code works on both 68K and PPC because it is already #ifdef'd to do nothing
on the 68K, unless you're using the 68K Code Fragment Manager (which you aren't,
yet).
UPP's work by always assuming that a proc ptr points at 68K code, and if it
isn't really 68K code then it will start with a special A-trap opcode that
switches you into the appropriate code type -- PPC or MIPS or PA-RISC or
whatever (up to 256 different processor types can be used in a "fat" program).
You could implement a "CallUPP" routine by simply switching to 68K mode and
jumping to the ProcPtr, but of course it's much faster to check for the
special opcode first to see whether you'd just get switched right back.
-- Bruce
---------------------------
>From dwilliss@tnt (Dave Williss)
Subject: Memory Allocation Question
Date: 11 Apr 1995 14:25:51 GMT
Organization: MicroImages, Inc.
I have a problem with the way the Macintosh allocates memory. It sucks!
I have no idea how much memory the program will need. It depends
entirely on what the user tries to do at runtime. If the user wants to
process a really large image, they have to bump up the "Preferred Size"
I looked into the possibility of using "Temporary Memory", but the
Inside Macintosh section (2 pages) on this is rather vague. It says
you can't leave a block of temporary memory locked when calling
WaitNextEvent or GetNextEvent. Why not? Is there a simple memory
allocation scheme that behaves more like malloc() under Unix?
Also, is the malloc() in MPW slow? Is there a faster replacement?
I have heard of faster malloc's that would allocate a larger chunk and
manage them, but I havn't found one.
--
David C. Williss #include <standard.disclaimer>
Software Engineer -- MicroImages, Inc. dwilliss@microimages.com
WWW: http://tnt.microimages.com/~dwilliss dwilliss@csealumni.unl.edu
-- PGP Public Key available via finger from: dwilliss@csealumni.unl.edu --
+++++++++++++++++++++++++++
>From Alex Rosen <alex@procd.com>
Date: 11 Apr 1995 21:38:52 GMT
Organization: Pro CD, Inc.
In article <3me3hf$bfd@westie.mid.net> Dave Williss, dwilliss@tnt writes:
> I looked into the possibility of using "Temporary Memory", but the
> Inside Macintosh section (2 pages) on this is rather vague. It says
> you can't leave a block of temporary memory locked when calling
> WaitNextEvent or GetNextEvent. Why not? Is there a simple memory
> allocation scheme that behaves more like malloc() under Unix?
There are two reasons not to leave a temporary handle locked: (1) it can
fragment the entire Mac memory, preventing the user from launching
programs, and (2) Apple Says It's A Bad Thing, meaning it's likely to
break with future System Software. If you're just developing in-house and
don't mind fragmentation problems, it's probably not horrible, but if
you're releasing this I would advise against it.
> Also, is the malloc() in MPW slow? Is there a faster replacement?
> I have heard of faster malloc's that would allocate a larger chunk and
> manage them, but I havn't found one.
All implementations of malloc and the C++ new operator use this technique
already. They allocate 15K chunks of memory, then dole them out as
needed. They do this because NewPtr (which they call to actually do the
allocation) is slow.
This whole mess is an unfortunate byproduct of the simplicity of the
MacOS. Learn to live with it, and be glad it's not DOS!
--Alex
+++++++++++++++++++++++++++
>From grobbins@znet.com (Grobbins)
Date: Sat, 15 Apr 1995 12:42:11 -0700
Organization: Skunkworks
In article <3mestc$j3i@sundog.tiac.net>, Alex Rosen <alex@procd.com> wrote:
>In article <3me3hf$bfd@westie.mid.net> Dave Williss, dwilliss@tnt writes:
>> I looked into the possibility of using "Temporary Memory", but the
>> Inside Macintosh section (2 pages) on this is rather vague. It says
>> you can't leave a block of temporary memory locked when calling
>> WaitNextEvent or GetNextEvent
>There are two reasons not to leave a temporary handle locked: (1) it can
>fragment the entire Mac memory, preventing the user from launching
>programs, and (2) Apple Says It's A Bad Thing, meaning it's likely to
>break with future System Software.
Temporary memory is not an evil or dangerous thing, but you should observe
a number of rules when using it.
- Use blocks from within the application partition for static needs.
Any memory usually required by the application should be accommodated within
the application partition. The user should be guaranteed that if the
application can be launched, it has enough memory to at least run properly.
Program code, window records, dialog contents, scratch space and necessary
small buffers are examples of items that should all be held in normal blocks
from within the application heap.
The minimum partition size should also be able to accommodate at least one
document with a moderate amount of data. This is necessary to keep the
promise that if the application can be launched, it can be used.
- Use temporary memory for documents and other dynamic needs.
The primary use of temporary memory is for dynamic data. Documents are
"temporary" in the sense that the space they occupy is not always needed
when the program is running.
Temporary memory is also useful for large buffers, such as might be used for
copying files. Remember to provide adequate minimal space within the
application partition so that these functions can be carried out even when
no temporary memory is available.
- Be prepared to reallocate handles.
Sometimes adequate space will be available in the application heap when it
is not available in temporary memory. Sometimes the opposite will be true.
If an attempt to grow a handle with SetHandleSize fails, try reallocating
the block so the user will be able to take advantage of any available
memory.
- Never require temporary memory.
Prior to the introduction of MultiFinder, applications were restricted to
the memory available in their own heap zone. This wasn't a problem because
the application heap occupied most of the Mac's memory.
Down the road, temporary memory may become unavailable or unnecessary under
future system software. For example, if each application were to be
allocated its own unique address space, then it would again offer no
advantage for applications to request space from outside of their partition.
Applications should never require the presence of temporary memory. When
Gestalt indicates that temporary memory is not available, an application
should continue to make the best use of the memory available to it.
- Unlock temporary memory handles across calls to WaitNextEvent.
Temporary memory occupies space which might be needed by the System or by
other applications. Good citizenship demands that temporary memory handles
be unlocked whenever an application calls WaitNextEvent to avoid
unnecessarily restricting the memory available to other applications.
- Reduce or dispose of temporary memory handles whenever possible.
A key element to giving users natural control of memory usage is that, when
documents are closed, more memory should become available to all
applications. This requires that applications not hold on to temporary
memory handles which are not currently needed. When the data in a handle is
no longer absolutely necessary, the application should immediately dispose
of or empty the handle.
Similarly, users will expect that closing a document should free up memory
for other applications. When a user closes a document which is being kept in
the application's heap, and that frees up enough space to move data from
temporary memory into the application heap, the application should do so.
This gives the user the benefit of the additional free space for other
applications.
- Remember that temp memory handles come from a different heap.
Some rare toolbox calls or code libraries may check which heap a handle is
in and operate in an unexpected manner if the handle is from a heap other
than the application heap. Unfortunately, there is no list of System calls
which expect handles to be in the application heap. Under System 7, the
Memory Manager is fully compatible with temp memory handles. Beware when
passing a temp memory handle to any code which might make inappropriate
assumptions about the handle.
- Do not allocate a large number of temporary handles.
The Memory Manager uses relatively simple algorithms to manage heaps.
Allocating too many handles in one heap can have a noticeable, adverse
affect on performance.
Because the heap from which temporary handlers are allocated is shared,
applications should allocate only a reasonably small number of temporary
handles. One temporary handle for each open document, up to several dozen,
is not excessive, but a hundred or more temporary handles probably is too
many. When a large number of handles is necessary, create a new heap in
either a non-relocatable block in the main application partition or in a
locked temporary block.
Grobbins grobbins@znet.com
---------------------------
>From kenneth.trueman@residences.ulaval.ca (Kenneth Trueman)
Subject: QuickDraw GX Fan Club Page (correct address !)
Date: Mon, 24 Apr 1995 05:13:11 GMT
Organization: Laval University
Hi everybody !
I recently setup the QuickDraw GX Fan Club Page on the WWW. It's a page
devoted to all things GX (the technology, compatible applications,
utilities, drivers, etc.)
Since everybody here is a programmer (? :-), I figure most of you know
about GX, etc. The problem is that Apple doesn't promote GX much to The
Rest Of Us. My page tries to fill that void. ;-)
If you have any info about GX that you'd like to share, if you have a GX
based product you want to let people know about, etc, let me know. I'd be
very happy to put it on my page, or provide a URL to it elsewhere ... If
you see info on my page that is incorrect let me know, and I'll change it
...
We've already converted one guy to GX (I've got the e-mail to prove it),
and we can convert more, if enough people know about it. So come on by
and let me know what you think. :-) I really want to make this the best
page possible !
Here's the URL for the QuickDraw GX Fan Club page ...
<http://aah.residences.ulaval.ca/quickgx/quickgx.html>
This a totally non-profit, independant thing by a guy who digs GX ! :-)
Thanks :-)
Kenneth
--
Kenneth Trueman kenneth.trueman@residences.ulaval.ca
Laval University ktrueman@eworld.com
Quebec City, Canada KTrueman@cmq.qc.ca
QuickDraw GX Fan Club: <http://132.203.80.10/quickgx/quickgx.html>
The Trueman Files : <http://132.203.80.10/>easy
Have a nice day ! ?8-)
---------------------------
>From suhieber@cln.etc.bc.ca (Susan Hiebert)
Subject: Quicktime Musical Instruments
Date: Mon, 17 Apr 1995 03:45:20 GMT
Organization: Education Technology Centre of B.C.
Hi. My program uses QuickTime 2.0 & QT Musical Instruments to play
MIDI files. I have never used the Gestalt Manager before. How do I
use it to determine if QT 2.0 & QT Musical Instruments are installed?
+++++++++++++++++++++++++++
>From mhl@icf.hrb.com (mark)
Date: 17 Apr 95 13:12:36 EST
Organization: HRB Systems, Inc.
In article <1995Apr17.034520.28107@news.etc.bc.ca>, suhieber@cln.etc.bc.ca (Susan Hiebert) writes:
> Hi. My program uses QuickTime 2.0 & QT Musical Instruments to play
> MIDI files. I have never used the Gestalt Manager before. How do I
> use it to determine if QT 2.0 & QT Musical Instruments are installed?
Better yet, how do we get a chance to look at you code? I have been
trying to figure out how to use QTMI && MIDI for a while.
--
Hope this helps.
Mark H. Linton
____________________________________________________________________
mark \'mdrk\ n [ME, fr. OE mearc boundary, march, sign; akin to OHG
marha boundary, L margo] 1 a : a conspicuous object serving as a guide
for travelers 2 : A standard or criterion of quality 3 : An object or
point that serves as a guide --idiom. mark time. 1 : To make little or
no progress
+++++++++++++++++++++++++++
>From sandvik@apple.com (Kent Sandvik)
Date: Mon, 17 Apr 1995 23:37:03 -0800
Organization: Apple Computer, Inc. Developer Technical Support
In article <1995Apr17.034520.28107@news.etc.bc.ca>, suhieber@cln.etc.bc.ca
(Susan Hiebert) wrote:
> Hi. My program uses QuickTime 2.0 & QT Musical Instruments to play
> MIDI files. I have never used the Gestalt Manager before. How do I
> use it to determine if QT 2.0 & QT Musical Instruments are installed?
[could someone FAQ this, thx?]
Get the DTSQTUtilities kit from the following URL:
ftp://ftp.info.apple.com/dts/quicktime/dtsqtutils.Apr95.hqx
The documentation, QuickTime 2.0 Developer Guide for Macintosh:
ftp://ftp.info.apple.com/dts/quicktime/QT_MAC.PDF.hqx (Acrobat format).
Sneak preview of the DTSQTUtilities kit (test for QT, test for the
PowerPlug file, test is musical instruments are available). Cheers,
Kent/DTS:
- ---
/*______________________________________________________________________
QTUIsQuickTimeInstalled - Test if QuickTime is installed.
pascal Boolean QTUIsQuickTimeInstalled(void)
DESCRIPTION
InitQuickTime will test if QuickTime is present. We are not interested
in the QuickTime
version.
*/
pascal Boolean QTUIsQuickTimeInstalled(void)
{
long qtVersion;
OSErr anErr;
anErr = Gestalt(gestaltQuickTime, &qtVersion); DebugAssert(anErr == noErr);
if (anErr != noErr)
return false; // no QT present
else
return true;
}
/*______________________________________________________________________
QTUIsQuickTimeCFMInstalled - Test if the QuickTime CFM libraries are
installed and in the
right place.
pascal Boolean QTUIsQuickTimeCFMInstalled(void)
DESCRIPTION
QTUIsQuickTimeCFMInstalled will test if the CFM QuickTime libraries are
present (QuickTime
PowerPlug, for instance), and if the libraries are still present (this
because the libraries are
registered once when Gestalt finds then during runtime, and the end
user might delete these,
or move them to another location later)(.
*/
#ifdef powerc
pascal Boolean QTUIsQuickTimeCFMInstalled(void)
{
OSErr anErr;
long qtFeatures;
// Test if the library is registered.
anErr = Gestalt(gestaltQuickTimeFeatures, &qtFeatures);
DebugAssert(anErr == noErr);
if (!( (anErr == noErr) && (qtFeatures & (1 <<
gestaltPPCQuickTimeLibPresent)) )) // not true
return false;
// Test if a function is available (the library is not moved from the
Extension folder), this is the
// trick to be used concerning testing if a function is available via CFM.
if ( ! CompressImage )
return false;
else
return true;
}
#endif powerc
/*______________________________________________________________________
QTUGetQTVersion - Return the current QuickTime version number.
pascal long QTUGetQTVersion()
DESCRIPTION
QTUGetQTVersion is a simple function that will return the current
QuickTime version number,
and if QuickTime is not installed it will return 0L. The high order
word defines the version number,
for instance 0x0161 defines version 1.6.1.
You could also directly assign a boolean value stating if a certain
version is true by using this
kind of an expression:
Boolean gHasQT2.0 = (( QTUGetQTVersion() >> 16) & 0xFFFF) >= 0x200;
EXAMPLE
if( (QTUGetQTVersion() >> 16) < 0x150 ) return; // need to work with QT
1.5 or higher.
*/
pascal long QTUGetQTVersion()
{
long version;
if(Gestalt(gestaltQuickTime, &version) == noErr)
return version;
else
return 0L;
}
/*______________________________________________________________________
QTUAreQuickTimeMusicInstrumentsPresent - Test if the Musical
Instruments Extension is
installed.
pascal Boolean QTUAreQuickTimeMusicInstrumentsPresent(void)
DESCRIPTION
QTUAreQuickTimeMusicInstrumentsPresent tests if the QuickTime Musical
Instruments
extension (actually a component) is registered. If this is not the
case, then most likely
the extension was never placed into the extension folder, and the end
user should be
informed about this.
*/
pascal Boolean QTUAreQuickTimeMusicInstrumentsPresent(void)
{
ComponentDescription aCD;
aCD.componentType = 'inst';
aCD.componentSubType = 'ss ';
aCD.componentManufacturer = 'appl';
if(FindNextComponent((Component)0, &aCD) != NULL)
return true;
else
return false;
}
--
Kent Sandvik sandvik@apple.com Working with Multimedia stuff...
Apple Developer Technical Support. Private activities on Internet.
+++++++++++++++++++++++++++
>From suhieber@cln.etc.bc.ca (Susan Hiebert)
Date: Thu, 20 Apr 1995 02:02:24 GMT
Organization: Education Technology Centre of B.C.
> > Hi. My program uses QuickTime 2.0 & QT Musical Instruments to play
> > MIDI files. I have never used the Gestalt Manager before. How do I
> > use it to determine if QT 2.0 & QT Musical Instruments are installed?
> Better yet, how do we get a chance to look at you code? I have been
> trying to figure out how to use QTMI && MIDI for a while.
Actually that part was very easy. I converted the MIDI
files with MoviePlayer, then I took the 'moov' resource
out of the file, and stored it as a resource in my program's
resource fork, under a different, custom resource type.
Then I also stored the data fork of the file as a different
type of resource in my program.
Then, to play a movie I:
* call EnterMovies() at startup
* copy my resource to my preference file in the system folder (sneaky, eh?)
and change the resource type back to 'moov'
* copy the other resource to the data fork of my pref file
* I have a global variable of type Movie declared (as moovy)
* I call OpenMovieFile() on my pref file, and then NewMovieFromFile(),
then CloseMovieFile()
* to play the movie I call
GoToBeginningOfMovie(moovy);
MoviesTask(moovy, 0);
StartMovie(moovy);
then to keep the music going during game play, every once and a
while I call MoviesTask() again. To stop the movie, I call (what
do you know) StopMovie(), and before I load a new movie, I call
DisposeMovie().
* Then before my program quits, I delete all the movie stuff
from my pref file, so no one will find it.
Thus, I can play movies and protect the MIDI files written by a
friend specifically for the game, from being copied around
It was quite easy. I learned everything I need to know in order
to do this in one afternoon, from the header file, and a code
example off the CodeWarrior CD.
Hope this helps. Good luck!
Btw, if any QT gurus notice anything wrong I am doing, let me know
please! It works for me though.
P.S Not my account, so E-mail should go to Regulus240@aol.com
---------------------------
>From bentley@crenelle.com (Michael Brian Bentley)
Subject: Threads and Stacks
Date: Fri, 21 Apr 1995 16:14:22 -0500
Organization: Crenelle Incorporated
1) What is the default stack size for a Thread Manager (non-main) thread?
2) Does anyone have a deterministic procedure for calculating a thread's
stack requirements?
3) Do any MacOS debuggers provide a tool for recording the maximum stack
usage of threads during stress testing?
-Mike Bentley
Crenelle Inc.
--
Michael Brian Bentley - Crenelle Incorporated - bentley@crenelle.com
1935 West Pratt Boulevard Suite One, Chicago Ill 60626-3133
AOL: crenelle CIS: 75026,315 GIS: BENTLEY Alink: Crenelle
+++++++++++++++++++++++++++
>From oster@netcom.com (David Phillip Oster)
Date: Sat, 22 Apr 1995 03:05:08 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
In article <bentley-2104951614220001@bentley.pr.mcs.net> bentley@crenelle.com (Michael Brian Bentley) writes:
>2) Does anyone have a deterministic procedure for calculating a thread's
>stack requirements?
allocate a 10k stack. Fill the first 9k with 0xDEADBEEF. On termination,
search from the end toward the beginning looking for the first word that
isn't DEADBEEF. That will give you the stack usage. Remember the
sp points to the high address end of the stack!
--
- ------- <mail-to:oster@netcom.com> ----------
Ahh! The thorazine is wearing off and the odinazine is coming on...
---------------------------
End of C.S.M.P. Digest
**********************