HDTenEightyP/NetNews huggingface dataset:
From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
Newsgroups: comp.sys.mac.programmer
Subject: Re: How do I find out if Multi-finder is running??
Date: 14 Apr 92 17:27:24 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <65131@apple.Apple.COM>, lsr@taligent.com (Larry Rosenstein) writes:
> In article <1992Apr9.164156.7341@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence
> D'Oliveiro, Waikato University) writes:
>>
>> But why bother thinking up all these elaborate techniques? Just check
>> for the presence of the OSDispatch/JugglerDispatch trap ($A88F). It's the
>> technique Apple themselves use. You can't get any simpler, or more reliable,
>
> As I recall, checking for the MF Temporary Memory calls requires more than
> testing for the trap.  Didn't you also have to check a low-memory global to rule
> out Switcher?

Last I heard, Switcher didn't support JugglerDispatch, so unless you can
run both Switcher and MultiFinder at the same time, or there's been an update
to Switcher, the presence of this trap automatically rules out Switcher.








:-)








On a related note, I'd like to revive the term "Juggler" as a generic way
of referring to both the pre-System-7 MultiFinder and the System 7 Process
Manager. After all, "MultiFinder" seems a somewhat inappropriate term for
the latter. I know Apple couldn't use "Juggler" as a product name because
someone else had already trademarked it; but there's no problem with our using
it as a technical term, is there?

Lawrence D'Oliveiro                       fone: +64-7-856-2889
Computer Services Dept                     fax: +64-7-838-4066
University of Waikato            electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
From: ksand@apple.com (Kent Sandvik)
Newsgroups: comp.sys.mac.programmer
Subject: Re: SADE en MPW
Date: 5 Apr 92 23:24:37 GMT
Organization: MacDTS Mongols

In article <13603@star.cs.vu.nl>, fstiva@cs.vu.nl (Stiva F) writes:
> - The linker generates:
>   LocalID has previous, conflicting type (error 85)
>   <bad object file or compiler errors>
>   The makefile looks like this:
>   Asm -Sym on  file.a
>   Link -Sym on  file1.a.o ... filen.a.o   -o prog
>   What is the problem?
Can't say exactly, are you using Link 3.2 and Asm 3.2, or a mix
of releases (SYM format changed between releases, so for instance if 
one of the other files was compiled long time ago it maybe has old
SYM format information?

Cheers,
Kent Sandvik/DTS
Newsgroups: comp.sys.mac.programmer
From: zobkiw@world.std.com (Joe Zobkiw)
Subject: Re: PLookupName weirdness
Organization: The World Public Access UNIX, Brookline, MA
Date: Wed, 8 Apr 1992 17:34:36 GMT

>> The Function PLookupName returns an OSErr of 1

Are you sure you initialized the variable that PLookupName is returning
it's OSErr into?






-- 
<--------------------------------------------------->
 joe zobkiw                     zobkiw@world.std.com
 mac.synthesis.MIDI.development.C.asm.communications
>---------------------------------------------------<
From: ksand@apple.com (Kent Sandvik)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Does MPW support aliases?
Date: 10 Apr 92 01:30:32 GMT
Organization: MacDTS Mongols

In article <121548@lll-winken.LLNL.GOV>, nessett@llnl.gov (Danny M. Nessett)
writes:
> 
> I am having trouble using a folder alias from within the MPW shell. In
> particular, if I use the finder to make an alias of a folder, place that
> alias in another folder and then try to reference the alias as a child
> folder, MPW doesn't cooperate. For example, consider the following
> MPW commands and their output :

Most, if not all, MPW tools *don't* support aliases. I placed a request
for change about this to tools engineering some time ago.

Cheers,
Kent Sandvik
Dynamic Language Missionary
From: d88-jwa@hemul.nada.kth.se (Jon W{tte)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Question opening data fork
Date: 9 Apr 92 20:56:46 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden
Originator: d88-jwa@hemul.nada.kth.se

.cc.ukans.edu> skinner@oread.cc.ukans.edu writes:

   begin
    dataForkInfo := FCBPBPtr(NewPtr(SizeOf(paramBlock)));
    dataForkInfo^.ioRefNum := fileReferenceNumber;
    dataForkInfo^.ioFCBIndx := 0;
    OSResult := PBGetFCBInfo(dataForkInfo, false);
   end;

   THINK tells me that the dataForkInfo variable in the O 
   PBGetFCBInfo call is of the wrong type but according
   to IM it is supposed to be a FCBPBPtr which I believe is

Well, why don't you switch to "C" where a quick cast to
void * fixes it all ? :-)

Seriously, I believe it actually might need another of those
strange union types...

Anyway, you do some other things wrong, like not assigning
the ioNamePtr to point to a Str255 - even though the arrow
is pointing left, you have to do that. And you should
use NewPtrClear instead of NewPtr. And, most important,
you should de-allocate your memory when you're done...

-- 
h+@nada.kth.se; Jon W{tte, the Diplomat - NOT!
Xref: sparky comp.sys.mac.programmer:8119 comp.lang.fortran:1821
From: dpkemp@afterlife.ncsc.mil (David P. Kemp)
Newsgroups: comp.sys.mac.programmer,comp.lang.fortran
Subject: Re: Animating floating point numbers?
Date: 13 Apr 92 00:28:26 GMT
Organization: The Great Beyond

In article <1992Apr2.023545.25559@cco.caltech.edu> dougm@bradbury.cns.caltech.edu (Doug McNought) writes:
>In article <rdg4tINNg0h@agate.berkeley.edu> thomas@garnet.berkeley.edu (Mark) writes:
>>I'm doing some animation that includes floating point numbers.  The routine
>>I'm using (my own) to convert from double to ascii is very slow.  On my IIx
>>it takes about 7 ticks.  I clocked it against ThinkC's sprintf routine,
>>which came out at about 8 ticks.  You can see the problem - 5 doubles = 35
>>ticks = .5 seconds = lousy animation!
>Er--have you timed the Toolbox Num2Str or the SANE conversion routines? I have
>absolutely no idea whether they would be faster, but it's certainly possible.
>... Apple has been known to use good algorithms on occasion... :)

A good algorithm in this case would be to avoid binary <-> ascii conversion
entirely.  Any time you do formatted writes and reads, you're gonna be
slow. The only reason to use ascii is if a human is going to look at the
data, or if you are going to move it to a machine with a different
architecture.  If both your data generating program and your animation
program are running on the same machine, just use unformatted I/O. It'll
be MUCH faster.


-- 
   Dave Kemp   dpkemp@afterlife.ncsc.mil              "Pave the Bay!"
   #include <std/disclaimer>
Newsgroups: comp.sys.mac.programmer
From: quinn@cs.uwa.edu.au (Quinn "The Eskimo!")
Subject: Re: Does MPW support aliases?
Organization: The University of Western Australia
Date: Mon, 13 Apr 1992 04:01:23 GMT

In article <pj#vHmu0n6@atlantis.psu.edu>, dn5@apix.psu.edu (D. Jay Newman) writes:
> 
> In article <22808@goofy.Apple.COM>, ksand@apple.com (Kent Sandvik) writes:
>  
> > Most, if not all, MPW tools *don't* support aliases. I placed a request
> > for change about this to tools engineering some time ago.
> 
> I *really* wish they did (at least the C++ compiler).  I am working on a
> project with 6 shared files, and using aliases would be *much* easier than
> either keeping two copies of source code (which occasionally change) or
> shuttling them back and forth.
> 
> I've tried to keep the shared files in a common directory, but never got
> that to work real well.

If I was a member of MPW engineering I would tell you to use Projector.
Projector was specifically designed to support projects where two people are
modifying shared source code.  If you're going to put up with MPW's extreme
lack of speed, the least you could do is actually use some of its neater
features.

Quinn "The Eskimo!"   <quinn@cs.uwa.edu.au>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  -- Projector's #1 biggest fan!
Organization: Queen's University at Kingston
Date: Sunday, 5 Apr 1992 23:29:52 EDT
From: <CHARLESW@QUCDN.QueensU.CA>
Newsgroups: comp.sys.mac.programmer
Subject: How about C.S.M.P on CD-ROM?

  Like many people who follow CSMP I keep my own little archives of things
I think will be useful some day--bits of code, bugs and pitfalls, and corres-
pondence on all those things I hope to have time to delve into some day.
And, whenever I run into an area I'm struggling over, I scan the last year or
so of my archives using Gopher.  Often I find useful things.  Of course 90%
of what I save probably never gets used, but who can tell in advance.

  Has anyone proposed making CSMP available periodically on CD-ROM, say with
On Location index files?  I'm assuming, of course, that CSMP is essentially
a large community conversation where all participants are aware that their
comments are broadcast, and so moving the notes to a different medium wouldn't
require copyright releases from everyone who even said "This is a test...".
CD-ROM production prices are reasonable, CD-ROM players are becoming plentiful
(now that I have one :-), and the overhead might be low enough for it to fly.

  What do people think?  Would a semi-annual CD-ROM be worth ten or fifteen
bucks or would it already be too stale?

.../Dave   Dave Charlesworth
Newsgroups: comp.sys.mac.programmer
From: krk@itl.itd.umich.edu (Kenneth Knight)
Subject: Garbage in my GWorld's - help!
Originator: krk@helen
Organization: Instructional Technology Laboratory, University of Michigan
Date: Thu, 9 Apr 92 09:04:15 GMT

I am designing a program that does some fairly advanced graphics for work. The
program is meant to provide an interactive means towards image compression
(display both before and after images and let the user modify them). The image
data are stored in Graphics World's (GWorld's). There are three main GWorlds:
the before image, the after image (compressed before image), and a buffer for
the Undo command (a fourth is created sometimes for things like psating). My
problem is that it appears that garbage is being stored in the second (and
probably thrid and fourth) GWorld's that I create. For example, the before
image seems to draw to the left side of the main window perfectly , but the
after image is crud (it should , on startup, be a large white rectangle since
the before image has not been compressed). Right now the GWorld's are declared
globally like this:
     GWorldPtr   gAfterWorld, gBeforeWorld, gUndoWorld, gPasteWorld; /* with
proper extern GWorldPtr statements in the other files that use these
variables. */
 
If I create the GWorlds in the order: gBeforeWorld, gAfterWorld, gUndoWorld I
immediately see garbage in the second GWorld. If, however, I create the
GWorlds in the same order as they are declared the garbage in the second world
is less visible (though I believe still there , also I think garbage might be
in the first world, too). The three main GWorlds are all the same size (the
picture frame rectangle that is being displayed) and of the same depth (8 or
32 bits per pixel). This problem appears no matter what I pass to my creation
routine (essentially a call to NewGWorld with the proper parameteres set).
 
As far as I can tell the problem is NOT with any of my drawing routines, but
with the GWorld's themselves (NewGWorld appears to be working fine, no error
is returned and the partition I've given the application in tests is far
greater than it needs to be). Specifically, the portPixMap base address of,
say gAfterWorld in the first example, is either just slightly before or after
the portPixMap base address of gBeforeWorld. The result is a mangled image
appearing on the right side of the display (i.e. the pixel maps of gAfterWorld
and gBeforeWorld are overlapping).
 
What am I doing incorrectly? Can anyone suggest things to check (the params
passed to the creation routine and then NewGWorld are coorect, the GWorld
structures that are returned - with the exception of the portPixMap^^.baseAddr
- seem valid (e.g. proper rects, regions, rowBytes), and the drawing routines
are drawing with the right rects (the CopyBits call has the proper params and
I am quite sure that no colorizing errors are taking place - I insure that the
foreground color is black and the background color white before calling
CopyBits))?
 
Thanks in advance....
 
   ** Ken Knight **
krk@itl.itd.umich.edu
From: Pete.Gontier@p811.f70.n109.z1.fidonet.org (Pete Gontier)
Sender: Uucp@blkcat.UUCP
Newsgroups: comp.sys.mac.programmer
Subject: How do I find out if Multi-finder is running??
Date: Fri, 10 Apr 1992 23:23:05 -0500

 JW> From: d88-jwa@dront.nada.kth.se (Jon W{tte)

 JW> f85-tno@nada.kth.se (Tommy Nordgren) writes:
 
 JW> There is one very reliable way. Check for the presence of the
 JW> OSDispatch trap, used to allocate temporary memory from multifinder.
 JW> 
 JW> That is still not a reliable way. It tells you wether you can use
 JW> MF temp mem. It does NOT tell you wether _Launch will return.

It's not *officially* reliable. If System 6.0.9...6.0.10... implement
_OSDispatch when MultiFinder is not running, then you're right, this will
not be a reliable method.

However, a lot of Apple's own utilities use this method and would all have
to be tweaked. And *why* would Apple do such a thing? To foil this scheme?
System 6 is pretty much frozen as far as this sort of OS feature goes.
So, as far as I'm concerned, it's a reliable method. It even works under
System 7, though it's not necessary, as you go on to say...

 JW> However, the whole question is esoteric, since these days there's
 JW> no need to concern oneself about that; _LaunchApplication doesn't
 JW> need a wdRefNum, and DOES return. And if you need launching
 JW> capabilities, there's no reason not to use system software that's
 JW> been out for a ywar and the upgrade to which is free.

My company (Kiwi, not EC) is marketing a System 7 only utility. We've been
making some phone calls to registered users. A surprisingly large percentage
of them have actually *gone back to System 6* for compatibility reasons.
(Obviously those reasons haven't to do with our utility -- often it's a
printer driver or some fax INIT or something else they can't do without.)
System 6 is definitely not dead, folks.
From: bill@hao.ucar.edu (Bill Roberts)
Newsgroups: comp.sys.mac.programmer
Subject: PBHGetFInfo problemo...
Date: 12 Apr 92 17:47:01 GMT
Reply-To: bill@hao.ucar.edu (Bill Roberts)
Distribution: usa
Organization: High Altitude Observatory/NCAR, Boulder CO

Are there any Mac programmer gurus (or someone with some experience) 
that can tell me why the program listed below does not work as 
Inside Mac advertizes?
  By this I mean that the modification and creation times are always
42509 and 42508, respectively, for files that I've been modifying today.
Also why is the file size zero?
  All of this is happening on a MacIIsi, using THINK C, version 5.01.
Oh yes I should mention that the CONSOLE package is being used though
I don't think this has anything to do with the problem, or am I wrong?

Thanks Mucho in advance,
--Bill

#include <stdio.h>

main()
{
	FileParam	paramBlock;
	OSErr		err;
	char		path[120];	
	char 		fname[20];
	unsigned char 	*CtoPstr();	
	long		modtime, creatime, filesize;
	
	fprintf (stdout, "Enter the file name> ");
	fscanf (stdin, "%s", fname);
	
	strcpy (path, "80mb:Development:Think C:Projects:WonderWhy:Mstat:");
	strcat (path, fname);

	paramBlock.ioVRefNum= 0;
	paramBlock.ioFDirIndex= 0;
	paramBlock.ioFVersNum= 0;
	paramBlock.ioCompletion= NULL;
	paramBlock.ioNamePtr= CtoPstr(path);
 	
	err= PBHGetFInfo(&paramBlock, FALSE);
	
	modtime= paramBlock.ioFlMdDat;
	creatime= paramBlock.ioFlCrDat;
	filesize= paramBlock.ioFlLgLen;
	
	fprintf (stdout, "\n");
	fprintf (stdout, "	err= %d\n", err);
	fprintf (stdout, "	Modification date= %u\n", modtime);
	fprintf (stdout, "	Creation date= %u\n", creatime);
	fprintf (stdout, "	File size= %d\n", filesize);
}
From: bruss@cs.ucsd.edu (Brian Russ)
Newsgroups: comp.sys.mac.programmer
Subject: Thanks!  Re: dialog box questions
Date: 15 Apr 92 16:57:36 GMT
Organization: =CSE Dept., U.C. San Diego


	A few weeks ago I posted here, asking some questions concerning
dialog/textedit behavior, and I want to thank all those who responded!
You've been quite helpful ...

	FYI, my second question (how to "activate" an arbitrary text edit
field, other than the next one in the list) was never answered, but
I found a way -- SelIText() turns out to be perfect, though it wasn't
described as doing what I wanted (found out about it in "Inside 
Macintosh" which also has been helpful to me).

	Thanks again!

					Brian
-- 
Brian Russ
CSE Department, UC San Diego
..!sdcsvax!bruss	bruss@beowulf.ucsd.edu
From: elon@phsbbs.princeton.nj.us (Elon Danziger)
Newsgroups: comp.sys.mac.programmer
Subject: Icon Dragging
Date: 13 Apr 92 15:45:26 GMT
Organization: Princeton High School, Princeton, New Jersey

What's the best way in Think Pascal to drag an icon around without 
erasing other icons?  The routine I wrote is too slow and unresponsive.
(I have it check to see whether the mouse is centered over the icon; if 
it isn't, it moves the icon and restores anything left over--the main 
problem is that if you move the mouse quickly, the icon sometimes stays 
where it is.)  Thanks in advance.

-Elon

Elon Danziger, Technical SysOp PHSBBS            Princeton High School
DNS: elon@phsbbs.princeton.nj.us      UUCP: ...!princeton!phsbbs!elon
US Mail: 17 Chestnut Street / Princeton, NJ 08542
DISCLAIMER: Author bears full responsibility for this message.
From: meharp01@vlsi.louisville.edu (Michael Harpe)
Newsgroups: comp.sys.mac.programmer
Subject: Problem with THINK C 5.0.2 (long)
Date: 6 Apr 92 15:09:17 GMT
Article-I.D.: vlsi.1992Apr6.150917.6255
Distribution: usa
Organization: University of Louisville

I have two questions regarding a problem i'm seeing with THINK C 5.0.2.  I
am working on a program that reads in microprocessor cross assembler output
and does some processing with the decoded data.  For checksum calculations,
it's necessary to perform some math on a variable declared thus:

unsigned char rbyte;	/* should be an eight bit byte, true? */

and I want to read this byte from a buffer containing ASCII representations of
hex bytes: AAF3D345...  I should be able to do an sscanf:

	itemCount = sscanf(ptr,"%2X",&rbyte);	/* get a byte */

This should give me one of the bytes in rbyte, correct?  Well, the only way
I can get the behavior I expect is to change the unsigned char declaration
to an unsigned int.  Adding the byte I read to an unsigned char works 
correctly.  The problem is that sscanf is insisting on storing what it finds
in TWO bytes, not just one.  If it reads 0x23, it stores that as 0023 in two
locations.  I discovered this with the debugger.  Changing the field descriptor
to "%X" gives the same result.

That seems incorrect to me.  Taking this at face value, there appears to be
no way to interpret two ASCII characters to an unsigned char.  This works on
UNIX, that's where originally wrote the routine.  I have turned off the
THINK extensions and set up ANSI compliance.

OK, I found a workaround so what's the big deal?  Wellll, after I start this
processing loop, I want to display a dialog box that shows the progress I am
making through the file.  Given:

unsigned short objAddr = 0xE000;
unsigned short bytecnt = 35;
char strobjAddr = "\0";
char strbytecnt = "\0";

I should be able to:

itemCount = sprintf(strobjAddr,"%.4X",objAddr);
itemCount = sprintf(strbytecnt,"%.2u",bytecnt);

and end up with strobjAddr = "E000\0" and strbytecnt = "35\0".  NOT!  I had to
change the sprintf to read:

itemcount = sprintf(strobjAddr,"%.4lX",objaddr);
itemcount = sprintf(strbytecnt,"%.2lX",bytecnt);

Note that I had to make them BOTH read as longs before this worked.  I got
zeroes back with the first method.

Is this a compiler problem?  Or do I need more time with my C textbook (the 
latter being more likely).  The only reason I suspect this is that is seems
to contradict the typing rules.  Those are short integers so it seems kinda
silly to have to read them as longs.

Please respond directly to me.  If this is a really basic and silly mistake
I apologize in advance.  I would appreciate it if you would tell me so
in a constructive way, though :-).

Mike Harpe
University of Louisville
Newsgroups: comp.sys.mac.programmer
From: k044477@hobbes.kzoo.edu (Jamie R. McCarthy)
Subject: Re: Writing apps that use plug-ins?
Organization: Kalamazoo College
Date: Fri, 10 Apr 1992 17:17:11 GMT

jcav@midway.uchicago.edu writes:
>zobkiw@world.std.com (Joe Zobkiw) writes:
>>
>>I've alwasy understoodthat THINK C's Smart Link is 
>>on a FILE BY FILE and NOT a ROUTINE BY ROUTINE "smartness."
>
>I know for certain that THINK Pascal 3.0 or newer does smart linking on a
>routine-by-routine basis, and I would suspect recent versions of THINK C
>would work in a similar fashion.

No, it's by file.  See the User's Manual, p. 96.  There was also a
ReadMe file that clarified this, maybe the one on the TCL 1.1.2 upgrade.

Out of curiosity, how fast are ThP 3.0's smart links?
-- 
 Jamie McCarthy     Internet: k044477@kzoo.edu     AppleLink: j.mccarthy
 "Almost all portables today employ passive-matrix LCDs, and no one expects
 active-matrix screens to be cost-competitive for a few years" -PC World 2/92
From: greenie@drycas.club.cc.cmu.edu
Newsgroups: comp.sys.mac.programmer
Subject: MacTCP/Think C/TCPIP Libraries?
Date: 13 Apr 92 02:01:45 GMT
Organization: Carnegie Mellon Computer Club

I was wondering if anyone out there knows of any TCP programming libraries for
the MAC?  Our MAC's would be equipped with MacTCP, but then we need the
appropriate libraries and such to access everything with.  The main thing is
that we need them for Think C... most of the stuff I've seen is for MPW which
doesn't seem to compile well under Think C at ALL...

For that matter, does anyone know if the Communications Toolsbox under System 7 
will handle TCP/IP "connections"?

(Forgive me if these are FAQ's, but I'm a MAC Newbie :-)

I appreciate any help - can't wait to dive into the MAC's nifty programming
features!

Andy, greenie@drycas.club.cc.cmu.edu
Newsgroups: comp.sys.mac.programmer
From: russotto@eng.umd.edu (Matthew T. Russotto)
Subject: Re: Mapping one color to another - help!
Date: Tue, 14 Apr 92 15:21:06 GMT
Organization: College of Engineering, University of Maryland, College Park

In article <1992Apr14.120824.12158@terminator.cc.umich.edu> krk@itl.itd.umich.edu (Kenneth Knight) writes:
>I need some more help....
>
>I am writing a image processing tool that will re-map one color to another.
>Specifically, all the pixels in an image (32 bit deep GWorld) of the specified
>color will have their color changed to the current foreground color. I thought
>that using the SetEntries() toolbox call to modify the 32-bit deep GWorld's
>CLUT would make sense, but I can not figure out where the current color, the
>one that will be changed, is in the CLUT. Nor am I sure just what goes in
>the CSpecArray.value field. 

32-bit GWorlds do NOT have useful color tables.  They are 'direct
mapped', meaning each pixel value is $aarrggbb, where a = alpha
channel, r = red, g = green, b = blue.  The color table is ignored.
You have to iterate through the values in the pixmap and actually
change the pixel values.



-- 
Matthew T. Russotto	russotto@eng.umd.edu	russotto@wam.umd.edu
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)