HDTenEightyP/NetNews huggingface dataset:
From: d88-jwa@byse.nada.kth.se (Jon Wtte)
Subject: Re: little INIT code resource problem
Followup-To: comp.sys.mac.programmer
Originator: d88-jwa@byse.nada.kth.se
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Thu, 15 Oct 1992 09:58:34 GMT

> zocca@amc.uva.nl (Vincent Zocca) writes:

		   INITHndl := GetResource('INIT', 0);
		   DetachResource(INITHndl);


Here is your problem. You code lies in the INIT resource, and
the startup mechanism already has a handle to the resource.
You DetachResource that resource, so when the startup handler
gets around to realeaseresource it...

ALl you should do with the handle is locking it, but it's
already locked, so don't sweat it.

		   GotEvent := WaitNextEvent(DiskMask, myEvent, 60, nil);

However, calling WaitNextEvent in an INIT is not my idea of
supported and healthy things to do, unless you initialise
some managers (dialog manager?)

		   until False;

Never care to return, huh? What's wrong with an application
put in the startup items folder?

-- 
 -- Jon W{tte, h+@nada.kth.se, Mac Hacker Suedoise (not french speaking) --

  "On a clear disc, you can seek forever."
Newsgroups: comp.sys.mac.programmer
From: fixer@faxcsl.dcrt.nih.gov (Christopher Tate)
Subject: Re: MacsBug.  How to use to discover causes of crashes
Reply-To: fixer@faxcsl.dcrt.nih.gov
Organization: Computer Systems Laboratory, DCRT, NIH
Date: Thu, 8 Oct 1992 00:36:30 GMT

In article <kevin.718501310@crash>, kevin@crash.cts.com (Kevin Hill) writes:
>
>  I recently dropped macbug into my macs system folder. 
>  However, all it has been used for as of yet, is to rs the machine.
>Could someone give me some hints on where to look for info on how to 
>use it so that I can actually find out why I crashed?

Addison-Wesley has a very good book out on MacsBug.  It comes with a disk,
and covers quite a lot of ground in a fairly straightforward manner.  It
also has some tips on general programming practice, designed to help you
make your programs easier to debug.

(The book is part of a series of technical Mac books, but I don't remember
the name of the series or the exact name of the book... sorry.  A good
technical bookstore, or even a computer dealer, might well have copies in
stock, though.)

Until you get a book, try "help" from the command line, and browse through
the command summaries.  It won't tell you how to use various dcmd's, but it
will tell you how to use the Programmers' Switch to do useful things like
check the heap every so often, and suchlike.

------------------------------------------------------------------------------
Christopher Tate             | The Leadfoot Collection, Continued:
Management System Designers  |        * Barracuda (Heart)
                             |        * Summer of '69 (Bryan Adams)
fixer@faxcsl.dcrt.nih.gov    | Because driving fast is a cathartic experience.
From: us277614@mmm.serc.3m.com (Dave T. Berquist)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Temporary memory & PictCompressor
Date: 14 Oct 92 13:28:15 GMT
Organization: 3M Company

In article <16336@borg.cs.unc.edu> lari@bach.cs.unc.edu (Humayun Lari) writes:
>In article <rtgrc-121092111528@euler.rc.rit.edu> rtgrc@rc.rit.edu (Rob Gayvert) writes:
>..........
>Interesting fact: System 6.0 apparently had no way to mark a temporary memory
>block as being purgeable. So, under 6.0, does setting the pixPurge bit have
>any effect if the useTempMem bit has been set?
>
>Humayun Lari

Actually both of these flags used together in a NewGWorld call under
system 6 do indeed work (even though it is not documented in the
original 32bit QuickDraw developer not).  HOWEVER, there is a bug in the
system 6 memory manager where (bear with me hear) calling DisposeGWorld
on a GWorld allocated with pixPurge and useTempMem will corrupt the
application heap IF THE PIXELS WERE INDEED PURGED (e.g. MultiFinder
needed the memory to launch another application).  Apparently the
problem is in DisposHandle called on a handle in a heap other than the
current heap zone.

Therefore I would recommend against using temp mem and pixPurge with
GWorlds under system 6.

Dave Berquist
3M Company
From: webb@cm.deakin.OZ.AU (Geoff Webb)
Newsgroups: comp.sys.mac.programmer
Subject: Gestalt, Think C and System 6
Date: 15 Oct 92 01:41:22 GMT
Article-I.D.: sol.1bii82INNrnm
Distribution: world
Organization: Deakin University, Geelong, Australia
NNTP-Posting-Host: aragorn.cm.deakin.oz.au

Using Think C 5.0.3, with the declaration

        long gestalt_response;

the calls
        Gestalt(gestaltFindFolderAttr, &gestalt_response);
        Gestalt(gestaltNotificationMgrAttr, &gestalt_response);
        Gestalt(gestaltHelpMgrAttr, &gestalt_response);

all fail to alter the value of gestalt_response when run on System 6.

I can get the desired results by initializing gestalt_response to 0 before
each call, but this does not seem right.

Is this a bug?

Am I missing something?

Thanks in advance for any help.

Geoff.
From: gb2a+@andrew.cmu.edu (George J. Baxter)
Newsgroups: comp.sys.mac.programmer
Subject: THINK C bug AGAIN
Date: 7 Oct 92 07:09:13 GMT
Article-I.D.: andrew.keojqNa00Uh7A2Z21K
Organization: Science & Technology Center, Carnegie Mellon, Pittsburgh, PA

This is a confirmation of the bug I found on October 5th and posted. 
The code before was:
------
	while (*longString != ' ' && longString != (comLine + (long)(comLine[0]+1L)))
		   firstWord[i++] = *longString++;
	firstWord[i]=0;
------
where the compiler,instead of null-terminating my firstWord string, was
doing this:

firstWord[0]=0;

Thus killing my string.  I tried a fix:
------
char    *dummy;
.
.
	while (*longString != ' ' && longString != (comLine + (long)(comLine[0]+1L)))
		   firstWord[i++] = *longString++;

dummy = firstWord + (long)i;
*dummy=0;
---------
It STILL didn't work.. it totally ignored the '(long)i'.

I had to do this to get it to work:
-----
dummy = firstWord;
dummy += (long)i;
*dummy = 0;
-----

I have found another piece of code that fell apart due to the Think
5.0.3 upgrade:

	while (*index != CR && i < 9)
		posString[i++] = *index++;
	posString[i]=0;


basically, a similiar piece of code, and the exact same problem,
confirmed in the assembly with MacsBug.  See previous post.

I have gone back to Think C 5.0.2, and the code all works again.

-gjb
From: lari@bach.cs.unc.edu (Humayun Lari)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Temporary memory & PictCompressor
Date: 14 Oct 92 04:00:26 GMT
Organization: The University of North Carolina at Chapel Hill

In article <rtgrc-121092111528@euler.rc.rit.edu> rtgrc@rc.rit.edu (Rob Gayvert) writes:
>The PictCompressor application that is part of the
>QuickTime Starter Kit is particularly interesting. When loading a large
>image, it creates a GWorld in temporary memory if there is enough; 
>otherwise, it spools the image in, probably with DrawTrimmedPictureFile.
>The trick is this: PictCompressor doesn't release the "temporary" memory
>until you try to launch another application which requires more memory
>than is available. Any guesses how they do this?

From your description, it sounds like PictCompressor is asking NewGWorld
to make the GWorld pixels purgeable, so they can vanish whenever the Mac
needs more memory. If you do this, note that you need to check the result
of LockPixels to make sure your GWorld hasn't dissipated while you weren't
looking (and then use UpdateGWorld to get it back if necessary). Under Sys7,
HPurge can be used to mark any temporary memory block purgeable.

Interesting fact: System 6.0 apparently had no way to mark a temporary memory
block as being purgeable. So, under 6.0, does setting the pixPurge bit have
any effect if the useTempMem bit has been set?

Humayun Lari
From: udmorrow@mcs.drexel.edu (Daniel Morrow)
Newsgroups: comp.sys.mac.programmer
Subject: checking to see if the command key is down.
Date: 16 Oct 92 20:18:20 GMT
Distribution: usa
Organization: Drexel University

Mm+Basically, I'm just trying to see if the command key is down
during idle time by checking the modifiers flag of the event record.

I'm following IM-6 guidelines with how to do an event loop
(gotEvent := WaitNextEvent(...), if gotEvent then DoEvent, else DoIdle)

and the idle routine appears to never get called.

So, as a result, I just did my checking at the beginning of my DoEvent
routine before I check to see what event needs to be processed.

This worked until I turned on balloon help. It seems that something else
is being stuffed into the modifiers flag (besides cmdKey) when balloon
help is on. (Usually, this value is 7)


So, please, if anyone has a better way that can check to see if the
command key (or any modifier key) is down, please let me know.

-Dan.
udmorrow@mcs.drexel.edu
Newsgroups: comp.sys.mac.programmer
From: absurd@applelink.apple.com (Tim Dierks, software saboteur)
Subject: Re: Best way to get A5 into VBLTaskProc?
Date: Thu, 15 Oct 1992 01:55:43 GMT
Organization: MacDTS Marauders
Followup-To: comp.sys.mac.programmer

In article <MHALL.92Oct14201313@abc.comp.sys.mac.programmer>,
mhall@abc.comp.sys.mac.programmer (Matthew Hall) wrote:
> 
> Hello-
> 	I asked this same question recently and got the same answer.
> However, that the address of the task is stored in A0 is not
> documented in any IM that I can find.  If it isn't documented, isn't
> it about as safe as self modifying code? (I know for revised and
> x-time tasks it is stored in reg A1, but it explicitly says in IMVI
> that for slot tasks you may need to use self modifying code)

You're right- I can't find any place where this is documented.
Nonetheless, it's far more compatible than self-modifying code
if only because of the "safety in numbers" principle; Apple would
just as soon not break a large number of applications when releasing
a system release, if only because we always seem to take all the
blame, so you're safer if you're doing something a lot of people
are doing.

If you don't like it anyway, here's another way which isn't as
preferable (to me) as the VBLTask method, but which is much better
than your self-modifying code: if you're using MPW, put this in
an assembly file:

    CASE ON

Stash   PROC EXPORT  ; Returns a pointer to the globals storage
    LEA     Store,A0 ; Load the address of the storage
    MOVE.L  A0,D0    ;  into D0
    RTS

Store
    DC.L    0        ; Where the globals pointer is stored

    ENDPROC

and add the following declaration to your C file:

extern long *Stash(void);

(If you're using Think, you'll need to translate this to inline assembly.)

Now, if you want to store a variable for later retrieval (your value of
A5, a counter, or the price of lettuce in Zanzibar), you just do the
following:

    *(Stash()) = myImportantValue;

When you want to get it back later, such as from your VBL, you can just
do the following:

    superImportantNumber = *(Stash());

If you wanted to store something else, like a Handle, you would just change
the prototype:

extern Handle *Stash(void);

This is safer because it doesn't actually modify code; thus, it won't run
afoul of data or instruction caches; however, it does store data in code
space, and therefore it would break if Apple ever decided to write-protect
program code.

> Confused about what Apple is doing,
> -matt hall

You think *you're* confused about what Apple is doing...

Tim Dierks
MacDTS, but I speak for the little men in my head
From: liran@bimacs.BITNET (Eshel Liran)
Newsgroups: comp.sys.mac.programmer
Subject: Creating gray PixPat
Date: 15 Oct 92 10:20:52 GMT
Organization: Math & CS, BarIlan U, Ramat-Gan, Israel

I used the system 7 call which is supposed to created a gray color but
when I looked at the result on a mac connected to a gray scale moniter with
the colors option chosen it the monitors control panel, the color I got was
white. Is there a way the created a consistent gray (like in the dimmed menus)?

Liran Eshel,
Bar-Ilan University, ISRAEL
liran@bimacs.cs.biu.ac.il
-------------------------------

Newsgroups: comp.sys.mac.programmer,comp.os.ms-windows.programmer.misc,comp.sys.novell
From: d88-jwa@alv.nada.kth.se (Jon Wtte)
Subject: AppleEvents to Windows?
Originator: d88-jwa@alv.nada.kth.se
Organization: Royal Institute of Technology, Stockholm, Sweden
Distribution: comp
Date: Fri, 9 Oct 1992 21:08:01 GMT


We have a workgroup prductivity application for the Macintosh,
that is now being written for Windows as well. We have coped
with the "normal" Mac->Windows problems, like using the resource
fork for a Mac file, but are really stuck on the network part.

We use AppleEvents (a session/presentation level protocol) for
sending small non-persistent mail messages among nodes, and
also for silent notification that "things have happened." We
want something that works the same for Windows. Ideally, it
would be compatible with "something" on the Mac (not necessary
AppleEvents, since I don't think Apple has released the format)

Barring that, we want SOMETHING that gives us network
communication from the Mac -> Windows world, and some dictionary
service (writing a network address in a file on a shared server
is quite OK; writing a file in a known directory and poll it
once every second is definately out of the question)

If that helps, we could limit ourself to always using a Novell
network for shared or Windows-only environments.

We cannot use a "heavy-duty" mail system like QuickMail or
CC:Mail since we need much more lightweight services, and
besides, the price per workstation is prohibitive. Wish list:

1) AppleEvent library for Windows
2) PPCToolbox under Novell and Windows
3) ADSP library for Novell
4) Novell SPX (IPX?) libraries for Mac and Windows

... and, barring ALL ELSE :-) ...

5) TCP/IP for Novell (and using MacTCP on the Mac,
   however, I think that's pretty expensive)

Documentation and source code available would of course
be a big boon. Cost limits: $5,000 for library (one-shot)
or $40 per workstation license. Of course, the less the
better.

I will summarize if there is interest.

Cheers,

					/ h+@nada.kth.se
					  Jon W{tte

-- 
 -- Jon W{tte, h+@nada.kth.se, Mac Hacker Suedoise (not french speaking) --

   What we need is a good GNU [...] licence manager implementation.
                     -- Raphael Manfredi
From: chuck@gte.com (Chuck Hoffman)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Event Handler Demo PLEASE!!!!!
Date: 8 Oct 92 18:24:44 GMT
Followup-To: comp.sys.mac.programmer
Organization: GTE Laboratories

In article <1992Oct8.075345.1@vmsclst1.sc.csupomona.edu>,
mgeorgy@vmsclst1.sc.csupomona.edu wrote:
> 
> Could someone please give me a demonstration of how to use the event handler??? 
> Nothing fancy just the basics...
> 

An example in Pascal is on page 19 of Inside Mac volume 1, in the Main
event loop, starting with GetNextEvent.  Problem is, real applications are
never "just the basics".  If you would like a flow chart and sample
application in C, let me know.  I will be happy to send them to you, but
they are more than just the basics.

The real programming challenge isn't in catching the event, but in setting
up the logic flow after that happens.  Consider the mouseDown event.  You
handle it differently if it is in the active window or not, in a TextEdit
view rectangle, in a button or scrolling control, on the menuBar, in the
close box, on the desktop, etc., etc.

Chuck Hoffman
chuck@gte.com
GTE Laboratories, Waltham, Massachusetts, USA
(617) 466-2131
=====================================
I'm not sure why we're here, but I am sure that while we're here we're
supposed to help each other.
=====================================
Newsgroups: comp.sys.mac.programmer
From: phils@chaos.cs.brandeis.edu (Phil Shapiro)
Subject: Re: THINK C bug AGAIN
Organization: Symantec Corp.
	<Bw4DGs.Gyz@news.cso.uiuc.edu>
Date: Thu, 15 Oct 1992 14:28:21 GMT

>>>>> On 14 Oct 92 16:22:02 GMT, swofford@uxh.cso.uiuc.edu (David Swofford ) said:

 > gb2a+@andrew.cmu.edu (George J. Baxter) writes:

In article <Bw4DGs.Gyz@news.cso.uiuc.edu> swofford@uxh.cso.uiuc.edu (David Swofford ) writes:

>>I have found another piece of code that fell apart due to the Think
>>5.0.3 upgrade:

>>	while (*index != CR && i < 9)
>>		posString[i++] = *index++;
>>	posString[i]=0;


>>basically, a similiar piece of code, and the exact same problem,
>>confirmed in the assembly with MacsBug.  See previous post.

 > This is scary.  I switched to 5.0.3 primarily because of the
 > Debugger fixes.  Now I'm wondering if I too should go back.  The
 > problem is that in a very large application, bugs like this go
 > easily go unnoticed for a long time.

 > Does THINK know about this?  Will there be a 3.0.4 soon?

Due to a very unfortunate mistake, the THINK C 5.0.3 update contains a
bug which causes the "code motion" optimization to produce incorrect
code under many circumstances. We are aware of this problem, and
working on releasing a 5.0.4 update as soon as possible.

In the meantime, I would recommend using the 5.0.3 compiler with all
optimizations off; there are no other known problems with the 5.0.3
release.

	-phil
--
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
		   Internet: phils@cs.brandeis.edu
Newsgroups: comp.sys.mac.programmer,comp.sys.mac.system
From: KOCHER@nvdv01.ind.e-technik.uni-stuttgart.de (HARTMUT KOCHER)
Subject: TrueType and PrintMonitor
Organization: University of Stuttgart, IND (FRG)
Date: Wed, 7 Oct 1992 15:02:05 GMT
X-News-Reader: VMS NEWS 1.23

Hi netters,
I'm not sure if my first post made, so here we go again.
When I create a postscript file using the print to file
option of the print dialog, PrintMonitor always includes some
code for TrueType support, even if I use Postscript fonts that
are resident in the printer and with no TrueType version of the font
installed in the system. If I download the file to a Apple laserwriter
it prints OK. but if I download it to a HP IIIsi printer, it wouldn't
print at all. Any ideas what's going on? How can I prevent PrintMonitor
from inserting TrueType stuff into the Postscript file? (Besides going
back to system 6...).
Any help would be appreciated.

Hartmut Kocher
IND, University of Stuttgart

Newsgroups: comp.sys.mac.programmer
From: tom@dtint.uucp (Thomas R. Kimpton)
Subject: Re: Figuring out MPW StdIo.h FILE.
Organization: Digital Technology, International
Date: Thu, 15 Oct 92 17:26:58 GMT

In article <cluther.719095922@morticia> cluther@morticia.cnns.unt.edu (Clay Luther) writes:
>Hello:
>
>I am attempting to optimize a piece of Unix code on the Mac.  This code makes
>a call to fwrite() through a function pointer.  I can change that pointer to 
>point at my own io routine, but it must accept the same parameters as fwrite().
>
>What I'd like to know is how does the StdIo.h FILE structure relate to more
>standard Mac file refNums and PBs.  I'd like to be able to make a PBWrite()
>call directly after doing some preprocessing.
>
>
>Thanks.
>
>-- 
>Clay Luther
>cluther@morticia.cnns.unt.edu

#include <StdIO.h>
#include <IOCtl.h>
FILE *fp;
int filedes;
long dummy;

	filedes = fileno(fp);
	fRefNum = ioctl(filedes,FIOREFNUM,&dummy);


Look in chapter 3, "The Standard C Library", in the "MPW C Reference"
manual for greater detail.

Tom

-- 
---
Tom Kimpton                            tom@dtint.dtint.com
Digital Technology Int.                (801)226-2984	
500 W. 1200 South, Orem UT, 84057      FAX (801) 226-8438
Newsgroups: comp.sys.mac.programmer
From: d88-jwa@byse.nada.kth.se (Jon Wtte)
Subject: Re: Forcing TextEdit to set scrpAscent and scrpHeight
Originator: d88-jwa@byse.nada.kth.se
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Tue, 13 Oct 1992 09:53:34 GMT

> tonym@polari.online.com writes:

   I am writing a Windows version of a Mac application. It uses the same file

Gee, aren't we all? :-)

   format as the Mac version. This file format uses style scrap records to 
   store information about the text styles. So on the Windows end, I have to

Sorry, but style scrap records are WHOLLY INSUITABLE for temporary
storage, since it refers to fints by number. Font numbers change
between machines, and even ON machines sometimes. Store font info
by name. When you do this, you'll see that the other things you
do will fall out naturally.

You might also want to set up a mapping from windows/mac fonts; so
the user can choose to substitute appropriate fonts from platform
to platform.

-- 
 -- Jon W{tte, h+@nada.kth.se, Mac Hacker Suedoise (not french speaking) --

   There's no problem that can't be solved using brute-force algorithms
   and a sufficiently fast computer. Ergo, buy more hardware.
Newsgroups: comp.sys.mac.programmer
From: ksand@apple.com (Kent Sandvik)
Subject: Re: MacApp 3.0 and THINK Pascal
Date: Wed, 14 Oct 1992 04:32:53 GMT
Organization: Apple
Followup-To: comp.sys.mac.programmer

In article <1992Oct9.095243.24408@news.unige.ch>, roessli@sc2a.unige.ch
(David C. Roessli) wrote:
> Is the latest version of MacApp compatible with THINK Pascal 4.01 ?
> I hear that it's written in C++, how does that work out with THINK P ?

MacApp 3.0.1 works with Object Pascal, but due to certain things
that I don't want to dig up Think Pascal does not support
MacApp 3.0.1 development work. Which is sad, because Think Pascal
is one of the nicest integrated dev. environments I've ever seen,
and I don't use Pascal.

Kent/DTS
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.
Newsgroups: comp.sys.mac.programmer
From: grstate@undergrad.math.waterloo.edu (Gavriel State)
Subject: C++/MacApp compiler speed
Keywords: Argh!
Organization: University of Waterloo
Date: Tue, 13 Oct 1992 19:06:15 GMT

Recently I have been doing some development with MacApp 3 and C++.

For a while I was working on a beautiful fully-loaded Quadra 700 (20 Megs 
of RAM, 16-Inch Color Monitor, tons of HD space, etc).  Compiles would take
about 6 minutes for a no-debug version of the program and 7 for the debug 
version.

At the moment I am using a IIsi with 5 Megs of RAM.  I have virtual memory
turned up to 8 Megs so that C++ can actually run.  No-debug compiles take 
45 minutes and debug compiles take 1 hour 20 minutes.  

Is there any way to make this thing go any faster without adding hardware
(ie: memory)?  Is there any way that C++ will run in anything less than 
8 Megs of RAM?  Will a debug link work with less than 8 megs of RAM?

Any help would be greatly appreciated....

(Oh - my compile is finally done, gotta go!)


-- 
Gavriel State | 2B Systems Design Engineering/Economics | University of Waterloo
grstate@descartes.uwaterloo.ca           |  "What in God's name is going on?"
(519) 884-6478 (Waterloo #) <- Current # |   "FOUL!  No rhetoric!  Two-one!"
(613) 721-9738 (Ottawa #)                | Rosencrantz and Guildenstern are Dead
Newsgroups: comp.sys.mac.programmer
From: k044477@hobbes.kzoo.edu (Jamie R. McCarthy)
Subject: Re: Amateur Programming? [Re: Is IM going to be repackaged?]
Organization: Kalamazoo College
Date: Fri, 9 Oct 1992 15:36:07 GMT

joseph@joebloe.maple-shade.nj.us writes:
>
>Single individuals
>and teams of two or three have produced MANY major, complex, sophisticated 
>pieces of software.  To wit ... GUI apps (HyperCard), etc. 

I have no idea about the others, but--in deference to Bill Atkinson's
prodigious talent--it took a lot more than two or three people to bring
out HyperCard.  (And, from the about box, it looks like developers
turned out in droves to hack on version 2.)  If I remember correctly
from the interview in Danny Goodman's book, Bill didn't write any of
the printing code, or even HyperTalk...
-- 
 Jamie McCarthy      Internet: k044477@kzoo.edu      AppleLink: j.mccarthy
 I suppose ya don't think I was run over by a streetcar!
Newsgroups: comp.sys.mac.programmer
From: jrowney@arco.com
Subject: MPW ToolServer?
Organization: ARCO E & P T
Date: Wed, 14 Oct 1992 13:30:15 GMT

Simple question -- what is it and where can I get it if I need it?

John Rowney

jrowney@arco.com