HDTenEightyP/NetNews huggingface dataset:
From: haynes@mace.cc.purdue.edu (Carl W. Haynes III)
Newsgroups: comp.sys.mac.programmer
Subject: Re: System Extension sample source wanted!!
Date: 29 Jul 92 09:11:58 GMT
Organization: Purdue University

In article <1992Jul29.050358.4513@monu6.cc.monash.edu.au> ins712r@aurora.cc.monash.edu.au (Heng Chiang) writes:
>minh@inst-sun1.jpl.nasa.gov (Minh Lang) writes:
>: I am looking for some sample source for writing System Extension.
>Me TOO!  I have found a lot of source code for general applications
>but I haven't seen any for control panels / extensions.  I would
>really like to know how people actually start writing extensions (INIT)
>with the horrible lack of documentation.

The best piece of documentation I've seen on writing INITs was an article
by Eric Shapiro that I pulled off of AOL called "Writing INITs in Think C".
I'm not sure if it's available in any of the archives. If you can't find
it and don't have access to AOL let me know and I'll e-mail a copy to
any one who wants it. This article has the best INIT shell I've seen.

The second edition of Macintosh Programming Secrets also has info on writing
inits, including patching traps. I personally think that someone should write
a whole book on low-level stuff like drivers and inits.

If your interested in communications, Programming with AppleTalk has an
example of an INIT.

The Macintosh C Programming Primer Vol II has an example of an INIT,
although it does not patch any traps which is usually what you want to
do when you write an INIT. However, it has a good example of a cdev.

Personally, I learned how to write INITs by deciding on something that I
wanted to do and posting lots of questions. Like most aspects of Mac 
programming, writing INIT's has a pretty steep learning curve, but the
rewards definately are worth the effort.

--
Carl W. Haynes III  
Haynes Consulting Services        ||  CWH3@aol.com
PO Box 2715                       ||  haynes@mace.cc.purdue.edu
W. Lafayette, IN 47906            ||  hcs@applelink.apple.com
----------------------------------------------------------------------
     Macintosh Programming & Consulting -- I am currently seeking 
        Macintosh development contracts, available immediately.
From: chick@delft.Berkeley.EDU (Steve Chick)
Newsgroups: comp.sys.mac.programmer
Subject: Think C 5 subroutine size limit
Date: 21 Jul 1992 22:10:25 GMT
Organization: University of California, Berkeley
NNTP-Posting-Host: delft.berkeley.edu

I am using Think C 5, and am trying to port some
C code which functions well on several UNIX systems
to the Mac.  One of the subroutines is rather large
(>1000 lines, lots of local variables).

When compiling, Think C 5 terminates partway through
the source with an error like 'invalid expression' on
a simple arithmetic expression which compiled without
complaint on a unix machine.  Commenting this line made
the compiler terminate on the next expression (which was
equally well formed in terms of syntax).

My conclusion, there is a limit to the size of the 
subroutine within Think C 5.  Is this limit the 32K
hardware limit of the Mac? or is it some other limit?
(I tried beefing up the memory allocated to Think C
by the finder by a factor of 2).

Has anyone had a similar experience? know of any work-
arounds so I won't have to rewrite the subroutine into
several smaller subroutines (not a small task)?

Any help would be appreciated.
Steve Chick
chick@cimsim.berkeley.edu
Newsgroups: comp.sys.mac.programmer
Subject: RE:  Mac programming problem...
From: jmatthews@desire.wright.edu
Date: 31 Jul 92 00:28:56 EST
Organization: Wright State University 

In article <1992Jul29.162801.21739@mprgate.mpr.ca>, hass@mprgate.mpr.ca (Calvin Hass (CS Shad Valley Student)) writes:
[re: talking to the printer directly]
> Actually, I think one can do something like the following:
> 
> Open(f,".printer");
> 
> It has been quite some time since I've used it, but I seem to recall that it
> will open a text channel to the printer.  From there, one only needs to use
> Writeln(f,"Hello there"); commands.

var f: text; {text type file required}
...
rewrite(f, 'printer:'); {'modem:' is the other port}
writeln(f, 'Hello there');
close (f);

This works on an ImageWriter. I can't wait to see what happens on
a LaserWriter; maybe I can send PostScript:-)

o----------------------------------------------------------------------------o
| John B. Matthews, jmatthews@desire.wright.edu, disclaimer:= myViews <> WSU |
| "I'm a commensal .sig virus, indistinguishable from an ordinary organelle."|
o----------------------------------------------------------------------------o
Newsgroups: comp.sys.mac.programmer
From: system@asuvax.eas.asu.edu (Marc Lesure)
Subject: newline mode
Organization: Arizona State University
Date: Wed, 22 Jul 1992 05:57:08 GMT

Inside Mac Vols II and IV briefly mention a newline mode on file reads,
but doesn't expand on it.  Could someone tell me how to use this?

-Thanks

-----------------------------------------------------------------------
Marc Lesure / Arizona State University / Tempe, AZ
"Between the world of men and make-believe, I can be found..."
"False faces and meaningless chases, I travel alone..."
"And where do you go when you come to the end of your dream?"

UUCP:       ...!ncar!noao!asuvax!lesure  
Internet:   lesure@asuvax.eas.asu.edu
From: creiman@Apple.COM (Charlie Reiman)
Newsgroups: comp.sys.mac.programmer
Subject: Re: To ETO or not to ETO?
Date: 30 Jul 92 18:15:47 GMT
Distribution: comp
Organization: Apple Computer Inc., Cupertino, CA

thor@vivaldi.psu.edu (Thomas Moertel) writes:

>I have MPW 3.2 with Asm, C, C++, and SADE.  I want to add MacApp 3 to
>my tool chest.  Should I buy MacApp alone or get ETO (which includes
>MacAPP)?  ETO no doubt costs more, even with the non-introductory
>reduced price.  I called APDA and was given the following prices for
>MacApp 3 with the latest C/C++ compiler:
> 
>MacApp               $350
>C/C++ upgrade         150
>                     ====
>Total $500

>So, I'm looking at $500 for the non-ETO route.  I don't have the
>latest Tools Catalog, so I don't know how much ETO would cost me.  I
>do, however, have the Aug 1991 catalog, and according to it I'd pay
>about $600 for ETO.  I'd be willing to pay the $100 for ETO all its
>extra goodies.
> 
>Could somebody please tell me how much ETO costs now and if the price
>difference is worth it?  Thanks!

Generally, ETO is worth it. It's nice to have one single CD will nearly
all your tools on it, up to date and virtually indestructible. (never
underestimate the value of read-only media). Plus ETO comes with the
latest _pre-release_ versions of MPW & SADE and such, in addition to
the release versions. Sometimes this can invaluable, since they usually
support strange and wonderful new features. And, you get asm and
pascal. Believe it or not, you will more than likely need these both at
some time. There is always some masochsitc hacker out there who's code
you'll just have to compile.  

Anyway, I feel its a bargian, and if I were to strike out and form my
own business, I would definately list a CR-ROM machine and ETO as
must-haves.

-- 
Charlie Reiman - Speaking as an individual, not for Apple Computer.
creiman@apple.com
	    "NEW! Posting Lite! 98% fact free!"
From: keith@taligent.com (Keith Rollin)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Gestalt glue is redundant!
Date: 21 Jul 92 17:40:05 GMT
Organization: Taligent

In article <c6n403hY3dcZ00@amdahl.uts.amdahl.com>, jsp@uts.amdahl.com (James
Preston) writes:
> 
> I disagree when you say that it is not the responsibility of the THINK C
> documentation to talk about something like the Gestalt glue code.  In the
> first place (and I'm sure I don't need to remind Rich of this), THINK C
> is not just a C compiler, it is a Macintosh development environment.
> Therefore, its documentation certainly should talk about the interface
> between the application program and the Mac toolbox.  More importantly,
> in this particular case, calling the glue code is something that the compiler
> does _behind the programmer's back._  It doesn't matter where that glue
> code comes from, be it Apple or anywhere else; the point is that the code
> generator does not see my call to Gestalt and emit a call to directly to
> Gestalt.  It emits code to call the glue code.  I agree that it is a good
> thing to do, but certainly any such behind the back calling must be
> documented by the product that does so, which in this case is THINK C.

I must agree with Paul in disagreeing with you here. First of all, this is
nothing new, and you never complained until now. There are many, many routines
that are glue routines that appear no differently that direct trap calls. Take a
look at Inside Mac. Any routine marked as Not In ROM is a glue routine.
Additionally, until MPW 3.1, almost every OS routine was also a glue routine in
order to convert from a register based convention into a stack based based
calling convention. (This has been now changed with the use of inline code and
#pragma parameter). Finally, there are several calls provided as glue for C
programmers that convert C strings into Pascal strings before calling the
ToolBox or OS.

Secondly, calling the Gestalt glue is definitely not an idiosyncracy of the code
generator. If anything, you've got it the wrong way around. In C, something with
the following form:

        myErr = Gestalt(selector, &result);

is a function call (or a macro, I suppose), and results in the compiler calling
a function linked with your application. Anything else, such as inserting a trap
number, is the exceptional case. The code generator is just doing what the
headers tell it to, and in the normal case, the headers tell the compiler to
generate a function call.

--
Keith Rollin
Phantom Programmer
Taligent, Inc.
From: scott@mcl.ucsb.edu (Scott Bronson)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Loading Resources into MF Temp Mem.
Date: 21 Jul 92 21:57:27 GMT

If I recall, the original reson for pulling this huge resource into a small
application heap was to draw a color about box with a PICT.  If so, IM-V
describes around page 90 or so how to spool a picture in from the disk.
I was hoping someone who knows more about this than I would mention this,
as the one time I tried to get this code to work I couldn't get it to stop
crashing.  I'm fairly certain that it was my fault, but as such, I don't
feel like an expert with PICT spooling.

You could probably rewrite GetPICTData to pull the opcodes in using partial
resource calls, but, personally, I would just stick the PICT data into the
application's data fork and spool from that using (almost?) the exact code
from the book.  Very compatible, suitably fast, and it's all in IM-V page 88.

	- Scott
From: jpugh@apple.com (Jon Pugh)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Apple Events and CD Players
Date: 19 Jul 92 00:26:30 GMT
Organization: Apple Computer, Inc.

In article <mxmora-140792095215@css-mac1.sri.com>, mxmora@unix.sri.com (Matthew Xavier Mora) writes:
> 
> I want my CD player program to be scriptable and to support
> appleEvents. I did a quick browse of the Apple event registry
> and did not see anything I could use. Is there some kind of media
> event type that has been defined that I missed? I'm looking for event
> types like play, pause, stop, rewind, fast forward and QueToHere. You 
> would think that Apple has define something like this for Quicktime or for
> controlling movies or a video disk player.
> 
> Are there such apple events?

There are no such events currently defined. Several people are interested
in creating such events, but no one has taken the responsibility of doing it.
Since all suites have to go through me to become offical, the first one to
get something to me that will work will get it done their way (if I approve).

James "im" Beninghaus of DTS is going to be redoing his CD Remote to support
AE soon.  You might want to collaborate with him to define some standards.
We've been talking about some of the things that would be necessary.  His
address is BENINGHAUS@Applelink.Apple.Com.  Tell him that I sent you.

Once an appropriate spec gets written and approved by me and some cohorts,
we will post it on ftp.apple.com and Applelink.  New suites should also 
appear on the Dev CDs as they are defined.

People are still climbing the learning for AE, but I am talking to more and
more people who are doing things correctly.  It is very encouraging.  The
time of Apple Events is approaching rapidly.

Jon Pugh
kAERegistrar
Newsgroups: comp.sys.mac.programmer
From: djvelleman@amherst.edu
Subject: Printing
Organization: Amherst College, Amherst Mass.
Date: Mon, 27 Jul 1992 21:55:27 GMT

  I'm trying to implement printing for the first time, and I have a very
simple question.  When do I call PrOpen and PrClose?  I remember reading
somewhere (but I'm not sure where) that I shouldn't just call PrOpen when
my application starts up and PrClose when I quit, because the user might
pull out the chooser and change printers in the middle of using my program.
So when do I do it?
  My guess is that I should respond to the Page Setup command with:
      PrOpen
      PrStlDialog
      PrClose
and respond to the Print command with:
      PrOpen
      (do the printing)
      PrClose
  Is that right?
  Anything else tricky I should know about as a first-time printer?
  Please e-mail responses, as I don't read this newsgroup regularly.  Thanks.

  Dan Velleman
  Dept. of Math & CS
  Amherst College
  djvelleman@amherst.edu

Newsgroups: comp.sys.mac.programmer
From: hpoppe@ncar.ucar.edu (Herb Poppe)
Subject: Re: Using GetNextEvent or WaitNextEvent...
Organization: National Center for Atmospheric Research
Date: Tue, 21 Jul 1992 20:21:41 GMT

In article <16JUL199216005351@gergo.tamu.edu> dave@gergo.tamu.edu (Dave 
Martin) writes:

> What's the best way to implement a main loop which can get it's events
> either from WaitNextEvent or GetNextEvent (if WNE isn't available on
> that machine)?

> I was thinking along the lines of a boolean (hasWNE) and doing an:

>     IF (hasWNE AND WaitNextEvent(...)) OR 
>               (NOT(hasWNE) AND GetNextEvent(...)) THEN... (Main Loop)

Note that both WaitNextEvent and GetNextEvent could be called depending on 
how the compiler you use compiles AND and OR. The Pascal standard does not 
require short-circuit evaluation of AND and OR. THINK Pascal (at least, 
don't know about MPW) provides non-standard forms of AND and OR (I forget 
the syntax) that always result in short-circuit evaluation.

Herb Poppe                 National Center for Atmospheric Research (NCAR)
hpoppe@ncar.ucar.edu       1850 Table Mesa Dr.
(303) 497-1296             Boulder, CO  80303
Newsgroups: comp.sys.mac.programmer
From: d88-jwa@dront.nada.kth.se (Jon W{tte)
Subject: Re: Altering the TRAP dispatch table.
Originator: d88-jwa@dront.nada.kth.se
Organization: Royal Institute of Technology, Stockholm, Sweden
	<1548hiINN809@agate.berkeley.edu>
Date: Tue, 28 Jul 1992 21:41:52 GMT

@ocf.berkeley.edu (Elizabeth Wylie) writes:

   >I want to trap BlockMove to a version optimized for the 030, my SE has
   >a 030 card.

   Finally, good luck on beating apple's code.  They write _very tight_ assembly
   where it counts.  (Elsewhere they tend to do some rather wierd C++).


The ROMs in the SE are _not_ optimized for the 68030...

-- 
      Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden
                  h+@nada.kth.se    +46-10-141652

              My cat usually runs around on the roof.
Newsgroups: comp.sys.mac.programmer
Subject: Re: Commenting on unannounced products
From: tmaehl@vax1.umkc.edu
Date: Fri, 24 Jul 1992 12:04:37 GMT
Followup-To: comp.sys.mac.programmer
Organization: University of Missouri - Kansas City

In article <minow-140792132951@kip-6.apple.com>, 
  minow@apple.com (Martin Minow) writes:
> There are several reasons why it is unwise to comment on unannounced
> products:
> 
> -- The SEC (Securities and Exchange Commission) may consider this as
> an attempt to increase the value of a company's stock.
> -- If something changes and the unannounced product is not released on
> time, or never released, or does something other than the non-announcement,
> someone who made a decision based on the non-announcement may be 
> rightly annoyed.

Hasn't Apple been burned by this?? I recall reading that their stockholders
had sued them for talking about products (a harddrive for the Apple II??)
and then failing to bring them to market. The stockholders won their suit
if my failing memory doesn't deceive me.

> 
> -- The "Osborne Effect" (named after the first portable computer): if you
> announce the "Osborne 2," everybody stops buying the Osborne 1 and your
> cash-flow dries up.

Maybe in light of Ken Olson's "retirement" this should be  re-christened
the "Alpha Effect."

Jonathan/tmaehl@vax1.umkc.edu
Newsgroups: comp.sys.mac.programmer
From: hd12@ellis.uchicago.edu (hui  dong)
Subject: Think C 5.0 under sys7, help!!!
Reply-To: hd12@midway.uchicago.edu
Organization: University of Chicago Computing Organizations
Date: Sat, 25 Jul 1992 05:36:48 GMT

I am trying to use Think C 5.0 under sys7 to recompile a C code I wrote
using 4.0 under sys6. I get lots of errors, drive me crazy! It even complains
about GetNewCWindow(WINDOW_ID,0L,-1L), saying the last argument isn't valid.
Could someone tells me where can I get help? Thanks a lot!!!!!!



Newsgroups: comp.sys.mac.programmer
From: Jerome Chan <yjc@po.cwru.edu>
Subject: Apple Events, Restricting by User
Organization: Alethea, The Twilight World!
X-Useragent: Nuntius v1.1
Date: Fri, 31 Jul 92 20:27:58 GMT

  Is it possible under System 7.0 to restrict users from sending apple
events to only certain applications on a Macintosh?

  I only want to let members in User Group A to send AEs to Application A
and not Application B. Does the application itself have to verify the
apple event before processing or is there another way?

---
 The Evil Tofu

"No Lah! Sure or not one? Dunno leh! Nebber Mind! Like that one!
Terriblur Lah!"
Newsgroups: comp.sys.mac.programmer
From: mcnichol@terminator.psy.syr.edu (Brendan T. McNichols)
Subject: Function missing from MPW C library?
Reply-To: mcnichol@mailbox.syr.edu
Date: Thu, 23 Jul 92 13:27:49 EDT


Hi all,

I am getting the following error message when building a project using  
MPW C:

### Link: Error: Undefined entry, name: (Error 28) "str2dec"
  Referenced from: _doscan in file: Alliance Drive  
:Development:MPW:Libraries:CLibraries:CLib881.o
### Link: Errors prevented normal completion.
### MPW Shell - Execution of KLSyn88.makeout terminated.
### MPW Shell - Execution of BuildProgram terminated.

It seems to me that this means that the function "str2dec" is missing  
from the CSANELib881.o library.  (It is declared in SANE.h.)  I am new  
using MPW and I'm not sure if there's something here that I should have  
done but didn't.  Does anyone know how to fix this problem?  Is str2dec  
located in some other library?  Can I get the code for str2dec and  
include it in the CSANELib881.o library?

Thanks very much for any help,
Brendan 

--
Brendan T. McNichols, Computer Support                (315) 443-9902
Psyracuse U. Sychology Dept.             mcnichol@psy.syr.edu (NeXT)
430 Huntington Hall                                 mcnichol@syr.edu
Syracuse, NY 13244
Newsgroups: comp.sys.mac.programmer
From: jcav@quads.uchicago.edu (JohnC)
Subject: Re: Moving to the foreground after receiving an 'odoc' from the Finder
Reply-To: jcav@midway.uchicago.edu
Organization: The Royal Society for Putting Things on Top of Other Things
Date: Tue, 21 Jul 1992 23:11:24 GMT

In article <D88-JWA.92Jul21225659@dront.nada.kth.se> d88-jwa@dront.nada.kth.se (Jon W{tte) writes:
>.uchicago.edu> jcav@quads.uchicago.edu (JohnC) writes:
>   If you want to be absolutely sure you're in front, you can call
>   _SetFrontProcess (I think that's the name) with your own process serial #.
>   However, I suspect that if you handle your suspend/resume events by the
>   book, the other problems should "factor out".
>
>DO not change the front applications forcibly. Don't. No.
>(Well, I have a reason for doing it, but YOU shouldn't :-)
>
>You should call AEInteractWithUser when you "need" to get
>to the front and can't resort to posting a notification and
>waiting.

Point taken.  Mea culpa.


-- 
John Cavallino                  |  EMail: jcav@midway.uchicago.edu
University of Chicago Hospitals |         John_Cavallino@uchfm.bsd.uchicago.edu
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g++ k s++ e+ h- pv    |         Chicago, IL  60637
Newsgroups: comp.sys.mac.programmer
From: dstine@cisco.com (David S.A. Stine)
Subject: Re: Writing an external file system
X-Disclaimer: The views expressed in this message are those of an
	      individual at SRI International, and do not necessarily
	      reflect those of the company.
Organization: cisco Systems, Menlo Park, California, USA
Date: Tue, 21 Jul 1992 07:51:14 GMT

In article <2A5F456E.5AA5@intercon.com> amanda@intercon.com (Amanda Walker) writes:
>russells@ccu1.aukuni.ac.nz (Russell Street) writes:
>> Anyone got any idea how to write an external file system 
>> for the Macintosh?  IM only points me to Tech Support,
>> which apparently does not give much support (though I
>> have not tried there yet).
>
>The short answer is "it's not worth it."  The long answer is "it is possible,
>but extremely aggravating."  This is part of why Apple won't help you;
>you basically have to have carnal knowledge of the File Manager and the
>Finder(s) in order to do it righ, and even then it will make you crazy.
>You will swear at your Mac.  You will find yourself going to see Arnold
>Schwarzenegger movies just to watch things blow up spectacularly.

Indeed. I can second this, having had the pleasure of writing one...

>Basically, this is one of those areas of the Toolbox Jungle where, if you can't
>find your own way, you probably shouldn't be there :)...

As a pointer to find your own way, I would recommend that you break out your
copy of MacNosy (if you want to do this level of programming, you MUST have
Nosy) and disassemble the AppleShare client. It has an EFS contained within it
which translates the Finder HFS calls into AFP calls.


dsa

Newsgroups: comp.sys.mac.programmer
From: patf@netcom.com (pat flaherty)
Subject: what's happened to the stack under VM?
Date: Fri, 31 Jul 92 01:02:50 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Summary: stack behaviour seems to have changed under VM

A test application called "A-trap somethingorother" came with my copy of 
MacsBug 6.2.  You use the app and MacsBug to watch at the assembly level
as the app makes a trap call.  In particular you can watch as the stack
gets set up and then taken apart afterwards.  For traps that return a value
(say a pointer to a window dstruct), the first thing you do stack-wise
before going to the trap is CLR.L -(A7); effectively clearing a long word
on the stack where the return vluae value will be placed.  And you would
expect that this decrements the stack point by 4 right?  Under 6.X or 7.0
with VM _off_, this does decrement the stack pointer by 4.  Under 7 with
VM _on_, you leave a long word cleared but the stack pointer has been
_incremented_ by 2.  Huh, what's going on here?  Am I looking at this 
wrong?

			pat
Newsgroups: comp.sys.mac.programmer