HDTenEightyP/NetNews huggingface dataset:
From: grobbins@Apple.COM (Grobbins)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Gestalt Selectors in APPL
Date: 24 Dec 92 06:19:14 GMT
Organization: Experimental System Software Investigations

In article <BzqC31.FAM@world.std.com> zobkiw@world.std.com (Joe Zobkiw) writes:
>1) Can I perform a "6-byte-xdef" type trick on this 
>code? I'm not sure I can since even if I mark the 
>6-byte resource as sysHeap the code it points to is 
>still in my application heap.

It should work so long as the application is running, but since the
application may quit and there is no way to remove a gestalt selector,
you will need at least one totally stand-alone block of code.  So the
6-byte trick won't solve this problem.

(This limitation doesn't apply to things like time manager tasks; since
they can be removed, it is appropriate to simply make the task code a
function of the application, or to put an initial jump instruction in
the system heap, and remove the task before the app quits.)

You can copy a function from the application into a block in the
system heap.  If the function were called MySelectorFunction and
it were followed by a procedure called NullProc, then this would
work:

 mySelectorFunctionSize := Ord4(@NullProc) - Ord4(@MySelectorFunction);
 { mySelectorFunctionSize should be something reasonable, definitely >0 }

 { make space in the system heap }
 mySelectorFunctionPtr := NewPtrSys(mySelectorFunctionSize);
 IF mySelectorFunctionPtr <> NIL THEN
    BEGIN
      { copy the function into the system heap }
      BlockMove(@MySelectorFunction, mySelectorFunctionPtr, 
                mySelectorFunctionSize);
      retCode := NewGestalt(kMySelector, mySelectorFunctionPtr);
    END;

This is more fragile than just compiling a stand-alone code resource
(on which you'd call set the SysHeap bit, call GetResource, DetachResource,
HLock; see IM VI 3-43) since the BlockMove method makes the assumption
that the functions in the compiled code are in the same relative order
in memory as they are in the source file.  Check the compiler output
with a disassembler (like ResEdit's code viewer) to make certain that
functions are sequential as expected in the final application code.


>2) If I place my Gestalt selector function in a separate 
>CODE resource, can I mark that resource as sysHeap and 
>have it work properly? This would be WITHOUT any 6-byte 
>tricks.

Yep, that's the canonical way.  Be sure it's locked in memory before
installation, too.

>3) How can I remove the Gestalt selector once the app 
>quits? Will
>    err = ReplaceGestalt(selector, nil, &oldGestaltFunction);
>work or will this cause the System to jump to location 0 
>the next time someone calls my selector?
>What's the easiest way? Thanks in advance! :)

Rather than try to remove the selector, just make a simple replacement
selector function that returns zero or something else distinct and
strand it in the System heap.


Grobbins              grobbins@apple.com

Usual disclaimers apply.
From: wisdom@picasso.ocis.temple.edu (Robert Wisdom)
Newsgroups: comp.sys.mac.programmer
Subject: Dumb beginner's Question?
Date: 22 Dec 92 12:49:15 GMT
Organization: Temple University
X-Newsreader: TIN [version 1.1 PL8]


	I have been going through "Macintosh C Programming Primer, Vol. I,
2nd ed." and I started wondering about resources.
	Question 1:
		When is it (un)acceptable to check the "Purgeable"
attribute of a resource?
	Question 2:
		What are the (dis)advantages of "Compressing" a resource?
	Question 3:
		Where would I be able to find this info if I didn't have
internet access?   :-)
			Thanks, Robert
----
Sign held by an abortion protester:        | Robert Wisdom
"Abortion Kills America's Future Soldiers" | wisdom@picasso.ocis.temple.edu
You figure it out (Because I can't!).      | My opinions are !yours.
----
Newsgroups: comp.sys.mac.programmer
From: Dmitry Boldyrev <dmitry@chemistry.chem.utah.edu>
Subject: "DisposePtr" routine in THINK Pascal
X-Xxmessage-Id: <A58760FFC301C4C9@quadra.chem.utah.edu>
X-Xxdate: Wed, 1 Jan 92 09:13:51 GMT
Organization: University of Utah
X-Useragent: Nuntius v1.1.1d16
Date: Fri, 1 Jan 93 19:11:32 GMT

Hello,
I figured out very strange thing in THINK Pascal 4.0.1:
I've placed one fragment from my program:
var
	AppPtr: IntegerPtr;
begin								    #debugger info: address of AppPtr is 000000000
 AppPtr := IntegerPtr(NewPtrClear(2));	#debugger info: address of AppPtr
is 0001D23A2 (OK)
 AppPtr^ := 327;						#debugger info: address of AppPtr is 0001D23A2 (OK)
 SetPtrSize(Ptr(AppPtr), 4);		    #debugger info: address of AppPtr is
0001D23A2 (OK)

 DisposePtr(Ptr(AppPtr));				#debugger info: address of AppPtr is
0001D23A2 (OK)
end.									#debugger info: address of AppPtr is 0001D23A2 ?
		
I used standard THINK Pascal debugger..

Why, after calling *DisposePtr* my address is  0001D23A2 ?
It can't be! The address must be 000000000 here !!!!
What does it mean ? *DisposePtr* do nothing here? or smth else ?
I'm always care about "memory" in my programs! 
Therefore I CAN'T CONTINUE MY PROJECT! Please, if anyone know what I'm
doing
wrong, help!
Thank you!
Internet: dmitry@chemistry.chem.utah.edu.
= Dmitry =
Newsgroups: comp.sys.mac.programmer
Distribution: world
From: Matt_Harrop@magicbb.uucp
Organization: MAGIC - Macintosh Awareness Group In Canada
Date: Wed, 30 Dec 1992 15:31:34 EST
Subject: Re: THINK pascal

>I'm using an old version of Think pascal, (Version 2.03) and I want to use 
>certian toolbox calls that became available with system seven. Do I have to
>upgrade to version 4, (costly at 175$ NZ) or can I get the libraries from
>somewhere?

Unfortunatly, you can't upgrade THINK Pascal 2 to program for system 7.  You
may be able to find libraries and interfaces for system 7, but TP v2 lacks the
GLUE code required for new toolbox calls.
Pascal v3 can be upgraded for System 7.  Their are public domain updaters that
update v3.0 with the needed GLUE code, and libraries and interfaces are also
available via FTP or from BBSs (and CD-ROMs).

I use THINK Pascal 4.01, which I got at a educational discount for only $80
(Canadian).  It is worth it.  It's faster, produces tighter code, and has a
TCL upgrade that is fairly bug-free!

Matt_Harrop@magicbb.uucp
Newsgroups: comp.sys.mac.programmer
From: keith@taligent.com (Keith Rollin)
Subject: Re: Sample Source Needed
Followup-To: comp.sys.mac.programmer
Organization: Taligent
Date: Tue, 22 Dec 1992 20:55:30 GMT

In article <1992Dec19.191735.368353@magicbb.uucp>, sharkman@magicbb.uucp
(Matt Daw) wrote:
> 
> Hello, I need a sample Pascal source code for using the file manager. Anything
> would be appreciated.

I'll let others point you to free source code at ftp sites, etc. I just
wanted to mention that the new Inside Macintosh volume on Files contains
plenty of source code on the File Manager, all of it in Pascal.

-----
Keith Rollin
Phantom Programmer
Taligent, Inc.
From: ephraim@think.com (Ephraim Vishniac)
Newsgroups: comp.sys.mac.programmer
Subject: Re: HELP-DIALOG anyone?
Date: 23 Dec 1992 15:06:05 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: charon.think.com

In article <1992Dec22.221714.6031@bnr.ca> brunner@crchh447.bnr.ca (James Brunner) writes:
>It would be nice if it allowed scrollable text and great if it had one of 
>those nifty pop-up menu's at the top to allow the user to jump to different
>sections.  Oh, by the way, I don't plan on selling my app, so it would be
>nice if the code was free.

Take a look at Disinfectant's Help system. Like it? You can get the
MPW source for it from ftp.acns.nwu.edu, or a Think C version from
think.com. All for free, thanks to John Norstad (and to me, for doing
the Think C port). 
-- 
Ephraim Vishniac    ephraim@think.com   ThinkingCorp@applelink.apple.com
 Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142
        One of the flaws in the anarchic bopper society was
        the ease with which such crazed rumors could spread.
Newsgroups: comp.sys.mac.programmer
From: fixer@faxcsl.dcrt.nih.gov (Chris Feelin' Groovy Tate)
Subject: Re: Sozobon C - a free C for the Mac, too?
Reply-To: fixer@faxcsl.dcrt.nih.gov
Organization: Computer Systems Laboratory, DCRT, NIH
Date: Thu, 31 Dec 1992 13:41:36 GMT

In article <3917@isgtec.isgtec.com>, ken@isgtec.com (Ken Newman) writes:
>In article <29848@castle.ed.ac.uk> ngse18@castle.ed.ac.uk (J R Evans) writes:
>> connected with Sozobon's assumption that sizeof(int)=4, whereas Think C 
>> uses sizeof(int)=2, 
>
>Gag! Think C uses 16-bit ints?! Is there no option for 32-bit ints?
>Wow, I thought Think C was a major full-featured compiler. This label
>doesn't apply to 16-bit int compilers. :) I still like Laser C on the
>ST, but would like to have a switch for 32-bit ints. (I have gcc as
>well, if I need 32-bit).

Yes, THINK C has a switch for whether or not to make the 'int' type 32 bits.

Of course, if you're writing code which requires that 'int' be 32 bits, rather
than declaring things 'long' that need to be that size, and 'short' when they
don't, you're probably going to cause yourself some major headaches if you ever
try to port the code to other platforms (and possibly even to other compilers). 
Keeping your type declarations as unambiguous as possible is just good
programming practice.

[Yes, I'm getting off my soapbox now... :-) ]

Remember, too, that at a purely practical level, arithmetic involving 16-bit
values is faster than arithmetic using 32-bit values, so declaring things
'short' whenever possible is also an efficient thing to do from an object-code
standpoint.

------------------------------------------------------------------------------
Christopher Tate             | Return of the CryptoSig (tm):
Management Systems Designers |    LR KMBVALMH ZKM HD CNDMH, LV CLYY.  LR
                             |    MDVALMH AKT HDMU CNDMH, BDX'QU DQUNYDDEUJ
fixer@faxcsl.dcrt.nih.gov    |    TDIUVALMH.
Newsgroups: comp.sys.mac.programmer
From: gurgle@netcom.com (Pete Gontier)
Subject: Re: HELP! INIT and patching probs
Organization: cellular
Date: Thu, 31 Dec 1992 00:23:55 GMT

cole@alexia.lis.uiuc.edu (Sandra Stewart-Cole) writes:
>        The central problem is that I've got an INIT that installs some trap 
>patches for various tasks (primarily a patch to PrGlue and one to SystemTask so
>I can get regular frequent cpu time without VBL hassles) and I need these 
>patches to have access to some resources (alerts and dialogs being the chief 
>need) but I found no supported way to either find my own filename as an INIT, 
>or to lock open the INIT's file so that I have a resource map to let resource 
>calls work with.

I don't have the first clue where the -34 error is coming from, but you
don't need to find out. And you don't need to go to low memory, either.
A call to CurResFile and then PBGetFCBInfo will do nicely. If the resource
file is opened more than once, the resource file reference number may
not match to the file manager file reference number, which is what you
need for the call to PBGetFCBInfo, but it seems that they match if the
resource file is open only once, which is the case at INIT time.
PBGetFCBInfo also works no matter where your INIT is installed in the
special folder hierarchy in the System Folder. It doesn't work if the
user moves your INIT after booting, but you can do a hierarchical search
within the file system for a file with your creator code if you're
worried about that.

Regarding leaving your file open: the INIT 31 mechanism (the INIT loader)
does some pretty weird things to ensure that all resource files opened
by an INIT get closed. I even went so far as to patch CloseResFile
once to see if I could keep my own resource file open. No dice. INIT
31 goes to low memory and checks some resource map chain variables to
see when they are restored to a state before it started the INIT. If
you patch CloseResFile to not close your fork, INIT 31 vainly keeps
trying. I considered munging the map chain, but it was too ugly a
thought and I decided to open the file whenever I needed it.
-- 
 Pete Gontier // EC Technology // gurgle@netcom.netcom.com
Newsgroups: comp.sys.mac.programmer
From: bskendig@netcom.com (Brian Kendig)
Subject: Re: How does my app know that its document was double clicked?
Organization: Starfleet Headquarters: San Francisco
Date: Thu, 31 Dec 1992 20:57:47 GMT

fixer@faxcsl.dcrt.nih.gov writes:
>
>If your app is *not* AE-aware, you'll get some information passed along to you
>at launch time.  You get at this info via the CountAppFiles() routine,
>documented in the Segment Loader chapter of IM-II.  CountAppFiles() returns
>information about how many documents were double-clicked, along with whether or
>not you should be opening them or printing them.  Then, you use GetAppFiles()
>and ClrAppFiles() as you wind through the list of double-clicked documents to
>get their information and Do The Right Thing.

Now I've got a question, too.  How do you cope with double-clicking
files that belong to an _open_ application?  Does this require the use
of AppleEvents?  Right now, when I dragdrop a file onto my app, it
launches and opens the file, but when I dragdrop another file onto my
app, the Finder says "Some files could not be opened.  Try opening
them from within the application."

-- 
_/_/_/  Brian Kendig                             Je ne suis fait comme aucun
/_/_/  bskendig@netcom.com                de ceux que j'ai vus; j'ose croire
_/_/                            n'etre fait comme aucun de ceux qui existent.
  /  Nolite te bastardes     Si je ne vaux pas mieux, au moins je suis autre.
 /    carborundorum.                                             -- Rousseau
From: bobert@informix.com (Robert Murphy)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Detecting File Launch
Date: 22 Dec 92 20:29:37 GMT
Organization: Informix Software, Inc.

>>In article <1992Dec21.040009.26063@mcs.drexel.edu>, udsugar@mcs.drexel.edu (David Sugar) writes:
>>> I am looking for a way to detect how a file was launched.  For
>>> instance I need to know if an application was launched by
>>> being double clicked or weather it was started at startup
>>> time because it was in the StartUp Items folder.  (I realize
>>> that I can check to see if the application is in the Startup
>>> Items folder but I need to see if it was user launched.)

I just noticed a remark in a tech note to the effect that under System 7,
an application launched as a startup item has a lower process id number
than the Finder does.

Regards,
Bob Murphy
From: gdl1000@cus.cam.ac.uk (G.D. Landweber)
Newsgroups: comp.sys.mac.programmer
Subject: Telling the volume type
Date: 24 Dec 92 15:09:41 GMT
Organization: U of Cambridge, England

Hello!  Given a vRefNum, how can you tell whether the volume to which
it refers is a floppy disk, hard disk, file server, etc.?  I want to
display a sicn for each volume like when you view the contents of the
"Desktop" folder in the SFGetFile dialog box.

Please respond via e-mail.

-- Greg (of the Buttons)
   gdl1000@cus.cam.ac.uk
From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
Newsgroups: comp.sys.mac.programmer
Subject: Re: I will kill or die for this tool
Date: 22 Dec 92 11:12:02 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <1992Dec21.043540.20183@hobbes.kzoo.edu>, k044477@hobbes.kzoo.edu (Jamie R. McCarthy) writes:
>
> Might some enterprising developer want to write a Macsbug dcmd that will
> keep track of the state of a handle/resource?  It would trap _HLock,
> _HUnlock, _HPurge, _HNoPurge, _AddResource, _DetachResource,
> _ReleaseResource, and _DisposHandle, oh yeah and _HSetState too.  You
> tell it to keep track of a certain handle, and to drop into Macsbug when
> its state changes a certain way.

How about a brute force approach: use the SS command on the block header?

The block header for 32-bit heaps is described on page 2-23 of the new "Inside
Macintosh: Memory".

Lawrence
just got his NIM volumes today. :-)
From: chriswd@cco.caltech.edu (Chris Michael Ward)
Newsgroups: comp.sys.mac.programmer
Subject: Resource help?
Date: 22 Dec 1992 16:58:45 GMT
Organization: California Institute of Technology, Pasadena
NNTP-Posting-Host: punisher.caltech.edu
Summary: I need some help with resources...

I was wondering if someone could help me out.  As a newtimer to Macintosh
programming, I am in the process of learning how to use resources.  I'm
trying to get the data from a simple 'STR#' resource, but it doesn't
seem to be working correctly.  

Should I do something like this:?

aHandle = GetResource ('STR#', RES_ID);
the_string = (char *) aHandle;
strncpy (temp_string, the_string, 2);
num_words = (int) temp_string;
... then proceed to get the character data as the_string[x]?

I'm sure I'm probably approaching this problem incorrectly.  Any advice
would be greatly appreciated.  (I can't seem to find any more info in
Inside Macintosh)

Thank you greatly!

- Chris

Newsgroups: comp.sys.mac.programmer
From: jimlynch@netcom.com (Jim Lynch)
Subject: Re: Best Mac value of all time
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Sat, 2 Jan 1993 14:07:33 GMT

By nominating the SE/30 and then saying 'no used machines', you have thrown out
your own nomination. As far as I know, SE/30s are discontinued (but they abound
in the used market for bargain basement prices, like you say.)
Newsgroups: comp.sys.mac.programmer
From: Alban E J Fellows <A.E.J.Fellows@bham.ac.uk>
Subject: MacTCP Development System
X-Xxmessage-Id: <A75F542714019802@tucker.met.bham.ac.uk>
X-Xxdate: Thu, 24 Dec 92 11:48:55 GMT
Organization: IRC in Materials, University of Birmingham, UK
X-Useragent: Nuntius v1.1.1d16
Date: Thu, 24 Dec 1992 11:59:18 GMT

I would like to know how to obtain the MacTCP Developer's Pack. I
downloaded it from an
ftp archive quite a long time ago, however that copy got trashed. I have
since been
unable to locate it on any of the Mac archives. I understand that it is
available from
Apple at a price however I am not a heavy duty Mac programmer and the
expense would be
excessive for the amount of software I would write using it. If anyone
has the kit and
is prepared to email it to me, or put it on an ftp archive please let me
know by email.

Specifically I am experimenting with writing a Mac implemention of Fsp
which uses udp
to send messages between server and client. The few programs which use
MacTCP for which I
have the source use stream protocols. So far I have succeded in opening
the MacTCP driver.
But then in Think C 5 thats only 3 lines of code!

Thanks in advance. All Information etc gratefully received.
Alban.
From: ficara@remus.rutgers.edu (ken ficara)
Newsgroups: comp.sys.mac.programmer
Subject: abs(-32768) = -32768 in Th C
Summary: Problem with abs function in Think C 5.0.4
Keywords: Think C
Date: 22 Dec 92 01:22:19 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

I'm having a problem with the library function abs in Think C 5.0.4.
It's supposed to accept an int as argument. INT_MIN is defined as
-32768. But when I take the abs of -32768, I get -32768 back. I
realize that this is because the two's complement of 0x8000 is 0x8000
with 2-byte ints. But shouldn't a function that receives an int deal
with any possible in that could be passed to it? I mean, this is a
classic boundary case.

Corllary: when I say "printf("%d\n",INT_MIN);" I get "-32768." But
when I open up <limits.h> and look at it, it says "#define INT_MIN
(~32767)". Huh?

Thanks for any help.


Ken Ficara                                        ficara@remus.rutgers.edu
GEnie: K.FICARA / Compuserve: 71311,1461 / AOL: KENFICARA / Prodigy: (Ha!)
From: bowman@reed.edu (BoBolicious)
Newsgroups: comp.sys.mac.programmer
Subject: Re: ETO#9 MacApp won't build - C - Fatal Error : 407
Date: 31 Dec 92 01:46:59 GMT
Article-I.D.: reed.1992Dec31.014659.8917
Organization: Reed College, Portland, OR

In article <ksand-301292134859@wintermute.apple.com> ksand@apple.com (Kent Sandvik ) writes:
>In article <1992Dec29.234245.13507@reed.edu>, bowman@reed.edu (Mr. Stress
>Tensor) wrote:
>> In article <1992Dec29.225510.11821@verity.com> anders@verity.com (Anders Wallgren) writes:
>> >In article <1992Dec29.211429.28535@cs.tulane.edu> Jeff E Mandel,
>> >mandel@tmc.tulane.edu writes:
>> >># C - Fatal Error : 407
>> >># could not proceed, BAD VERSION NUMBER in Dump file
>> >># No error (OS error 0)
>> >You should delete all dump files created by previous versions of
>> >the compiler and let the new compiler regenerate them.
>> 
>> Unless I'm mistaken, all you *really* need to do is add an "-e" to your
>> command line.
>
>From Cplus 411:
>    -e                      # write preprocessor results to output

I meant, "buildprogram -e", not "cplus -e".

>No, there are no magic flags to tell MPW C++ to reproduce a dump file,
>unless you write a fancy dependency somewhere in the makefile. Yes,
>I've pointed this out to the compiler people, because during the N versions
>of MacApp 3.0 alpha/beta versions this was a known gotcha, and it
>would be nice if the compiler either warned about this, or generated
>a new dump file using a special flag.
>
>Anders is right, delete any folders inside your "{MALoadFiles}" folder
>and start afresh. In addition, if any of you see cases where the compiler
>barfs in Geometry.h, this is another possible example of where the dump
>files
>needs to be re-generated.

I could swear buildprogram -e worked...but at the moment I'm working on
some non-MacApp stuff and don't have the drive space or patience to test it
out, but I'm pretty damn sure I *never* threw out any dump files, but just
threw the -e in there and everything worked ok.  As long as the necessary
make rules for the load files are in there somewhere, this should work.

And if I'm wrong, well, it wouldn't be the first time... :-)

cheers,
bobo              In seeking the unattainable,
bowman@reed.edu            simplicity only gets in the way.
Eternal nothingness is fine if you happen to be dressed for it. - Woody
Newsgroups: comp.sys.mac.programmer
From: mike@rahul.net (Mike Smithwick)
Subject: Getting the colormap from a spooled PICT image
Organization: a2i network
Distribution: worwld
Date: Wed, 23 Dec 1992 04:46:40 GMT

[]

I am spooling large PICT bitmapped images from the drive as
described in the UMPG, p. 197FF. I'm not exactly clear as to
what is happening when, but I get some sort of pict handle
that let's DrawImage() blat the picture in the window. 

I assume that DrawImage() handles the memory allocation stuff
automatically, etc. to permit me to read in the data. Anyway, I take
that pict handle after the call to DrawImage, call GetPictInfo() and
get garbage back. Some of the PictInfo data is correct, the rect size, etc,
but it also tells me that the image depth is only 1 or 0 bits, that
the number of unique colors is only 1 or 2, and so on.

The sequence of calls is :

        /* set up stdprocs for the spool function */

        DrawImage(pict,&rect);

        GetPictInfo(pict,&pi,...);

         etc...

So, the question is, is DrawImage, when spooling the data from the drive
creating a full pict in memory that GetPictInfo() can use? Or is the pict
data incomplete so as to screw up GetPictInfo?

And if so, how can I get the colormap info from a spooled file, so I don't
have to load the full image into memory (which defeats the whole process
of spooling).

mike

 

-- 
This message brought to you by the Happy Fun Ball! It's Happy! It's
fun!! It's the HAPPY FUN BALL!!! (Still legal in 16 states)
*** Mike Smithwick - mike@rahul.net 
*** No disclaimer is necessary since I only work for myself, HA! HA! HA! HA!
Newsgroups: comp.sys.mac.programmer
From: jimlynch@netcom.com (Jim Lynch)
Subject: Re: TopSoft contacts
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Sat, 2 Jan 1993 14:11:34 GMT

In article <29869@castle.ed.ac.uk> ngse18@castle.ed.ac.uk (J R Evans) writes:
>jimlynch@netcom.com (Jim Lynch) writes:
>
>>Meetings, oh yes, meeting of TopSoft
>>6:00 PM PST wraps around to 10am Thursday in Perth
>
>And wraps to 0300 CET (0200 UT), if I've got my time zones right.  Pity, 
>but it rather looks as if only the most dedicated Jolt drinkers are
>likely to join from Europe!

And a shame as well; however, you can still participate by email.
Newsgroups: comp.sys.mac.programmer