HDTenEightyP/NetNews huggingface dataset:
From: tcd@vax5.cit.cornell.edu
Newsgroups: comp.sys.mac.programmer
Subject: MacTCP (UDP) questions
Date: 19 Aug 92 17:33:03 EDT
Distribution: comp
Organization: Cornell University

     I am working on an application that needs to transfer a continuous,
high volume stream of data from one Macintosh to another.   Because we
can tolerate some amount of data loss/corruption it seemed like UDP
would be a better choice than TCP.  I have not seen much in the way
of discussion or sample code regarding UDP, and a number of questions
have come up.

1)  If I do my UDPRead calls asynchronously, where does the MacTCP driver
get the time to complete them?  Is much of the processing done on the
Ethernet card, or am I really just robbing Peter to pay Paul with 
the async calls?

2)  What happens if the receive buffer gets full?  Am I correct to assume
that incoming packets will be discarded, or do old ones get replaced?
Does the condition clear itself as soon as enough of the buffer has been
returned?

3)  Although packet order is not critical (otherwise I would use TCP), 
it would be nice for my application to get access to the packets in
the same order they arrive.  Can I assume that a UDPRead will return
the oldest packet in the buffer?

4)  Is there any advantage (or disadvantage) to keeping at least one
UDPRead call outstanding at all times?

5)  Where could I find the answers to these questions without asking
the net?  I have a feeling that debugging/optimizing this stuff is not
going to be easy, so I am trying to think this through clearly in advance,
rather than just jumping in.

Finally, it seems true that, in principal, UDP is going to provide
a much higher data transfer rate than TCP, as long I don't mind a little
corruption.  However, I wonder how true this will actually be in 
implementation on the Macintosh.  Even though I don't need the error
checking and acknowledgments of TCP, I do need some flow control, 
packet buffering, and some processing for partial "stream reconstitution".
Is it likely that (Mac)TCP does all of this (and more) better than I could
do with (Mac)UDP?  Thanks for any advice.

Tim Dorcey
Cornell Information Technologies
tcd@cornellc.cit.cornell.edu
my implementation 
   
Newsgroups: comp.sys.mac.programmer
From: pittenger-laurence@CS.YALE.EDU (Laurence Arthur Pittenger)
Subject: CDEF 0 color problems; help!
Organization: Yale University Computer Science Dept., New Haven, CT 06520-2158
Date: Mon, 17 Aug 1992 20:51:00 GMT

According to IM V, the check boxes and radio buttons are supposed to
draw their foreground and background colors according to the
associated color table in the auxiliary control record.  Well, it
ain't true.  At least I haven't been able to make it work.  In fact,
the only way I've managed to get its attention at all (re background
colors) has been to change the window's pixpat.  Which means that the
controls are drawing their background the old way, according to the
window's background, rather than the reputed new way, according to the
color table.

Any thoughts?...anybody...anybody...

thanks,
LP

-- 

Laurence A. Pittenger
CSNET  : pittenger-laurence@cs.yale.edu
BITNET : pitlaua@yalevm ,  pittenger-laurence@yalecs
From: tholland@pars.skidmore.edu (Anthony Holland)
Newsgroups: comp.sys.mac.programmer
Subject: 2-Page Monochrome monitor for MacIIci ADVICE WANTED
Keywords: monitor
Date: 13 Aug 92 01:35:42 GMT
Organization: Skidmore College, Saratoga Springs NY

Looking for a very clear, bright 2 page monitor for our new MacIIci.   
Recommendations on past experience for both hardware and vendors would be  
greatly appreciated.

Thanks

Anthony Holland
Skidmore
From: scott@mcl.ucsb.edu (Scott Bronson)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Accessing an INIT File after StartUp?
Date: 22 Aug 92 01:23:29 GMT

In <63766@cup.portal.com> Chewy@cup.portal.com (Paul Frederick Snively) writes:

>I'd also like to point out that there's a Toolbox/OS Code Snippet on various
>of the Developer CD series that contains a Snippet that I wrote, called
>KeepMeAround, that performs some admittedly sick jiggery-pokery with a
>one-shot patch to CloseResFile and some skullduggery with the resource chain
>that keeps the INIT's file open until the system is restarted.

Yes, but PLEASE don't use this technique to keep your file open forever
for something as menial as a dialog box.  Just imagine if every INIT you
had kept its file open--even though FCBs are dynamically allocated, we'd
still be inviting problems.  The original poster said he wanted to keep
a dialog box around.  How about creating only the DITL, setting its
system bit, loading and detaching it, then calling NewDialog() passing
it your detached DITL handle?  Just make sure that your DITL doesn't use
any PICT, ICON, or CNTL resources--those must all be user items.

	- Scott
From: Thad.Humphries@p950.f70.n109.z1.fidonet.org (Thad Humphries)
Sender: Uucp@blkcat.UUCP
Newsgroups: comp.sys.mac.programmer
Subject: FoxBASE+/Mac
Date: Tue, 18 Aug 1992 21:15:27 -0500

to: mk46+@andrew.cmu.edu (Matthew E. Kowalczyk)

re your question:

> Does anyone know how to create a folder using FoxBase+/Mac? I am able to
> set a path name, but I cannot actually create a folder. I tried calling
> Fox and I was put on eternal hold, so any help would be greatly
> appreciated. I don't read the bboards that much so please mail any
> responses directly to me at mk46+@andrew.cmu.edu  

I would just look for a good XCMD or XFNC and use that to create the folder.
I've often found that that is the only way to do some of the things a good
program should have to do.  (I've 2 1/2 years Fox/Mac experience, 1 year Clipper
before that.  I hate Fox and reach for THINK C whenever I have the excuse!)
From: pollansw@cse.fau.edu (Warren Pollans)
Newsgroups: comp.sys.mac.programmer
Subject: C function bookkeeping tool?
Date: 21 Aug 92 20:16:44 GMT
Organization: Florida Atlantic University, Boca Raton, FL, USA


Is there an "accepted" way of keeping track of functions in a long
C program.  All I could think of is keeping a list (another file)
of functions with: the files in which they're located, the variables
 they need, the functions they call, the
global variables used and changed, etc.  I'm sure that someone must
have already figured out a good way to do this.


Thanks,

 Warren

(pollansw@cse.fau.edu)
Newsgroups: comp.sys.mac.programmer
From: rbaderts@zeus.calpoly.edu (Rick L Badertscher)
Subject: Profiling/Coverage testing tools?
Organization: California Polytechnic State University, San Luis Obispo
Date: Sat, 15 Aug 1992 17:48:46 GMT

Hi,

Does anyone know of any profiling or coverage testing tools for the
mac?  I'm working in MacApp 3.0.

Thanks,
Rick Badertscher.


Newsgroups: comp.sys.mac.programmer
From: sold@kit.uni-kl.de (Christoph Sold)
Subject: Re: Australian Mac systems
Organization: Universitaet Kaiserslautern
Date: Fri, 14 Aug 1992 20:52:59 GMT

In article <1992Aug12.165059.10056@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:
>Subject: Re: Australian Mac systems
>From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
>Date: 12 Aug 92 16:50:59 +1200
>In article <1992Aug12.093523.3242@otago.ac.nz>, a certain Woody Allen lookalike
>writes:
>
>> I am trying to detect in my application whether or not the user is in Australia
>> - which includes New Zealand in a remarkably insensitive slight to my country -
>> and I have been doing The Right Thing: calling IUGetIntl(0) and checking the
>> intl0Vers field to see what version of the system is running.
>>
>> I have just discovered that this won't work for most of my Australian/NZ  users
>> who are using their Macs as they came out of the box, not unreasonably. (The
>> first thing I always do with a new Mac is repartition the hard disk to pick up
>> the extra 2-4 megabytes and reinstall the system). But if you leave it alone,
>> that standard Australian Mac is set to verUS! The Australian international
>> resources are there, but the International control panel isn't. So most users
>> will just carry on and occasionally wonder why the day and the month in their
>> dates are the wrong way round.
>>
>> What I'm going to have to do is check directly for the presence of the
>> Australian itl0/itl1 resources in the System file. Which is not exactly the way
>> things ought to be. Why don't new Macs come properly configured?
>
>I've bitched about this too. I think the fault lies with Apple Australia
>(who I assume are the ones responsible for creating "Z" versions of systems).
>The installer script for *every* Z system I've ever seen will install the
>right resources, but will leave the region setting (and date format) at 0
>(US) instead of 15 (Austral[as]ian). To add insult to injury, when you update
>your system to a newer version, the Installer will change the region code
>back to 0, if you had it configured to something else! And of course the
>installer script leaves out the "International" control panel for some reason...
>
>Perhaps Aussies are getting used to things American. After all, Keating
>heads the "Labor" party, doesn't he?
>
>In which case, maybe it's time for an NZ-specific system...
>
>Lawrence
>living in what is probably still the second-most loyal of Britain's former
>colonies (after the Falkland Islands...)

Of course, you can do it the hard way: Assuming the user has set up the 
right location in the Map control panel, you can ask the system for its 
location. See Inside Macintosh, Vol VI, Worldwide Software (or something the 
like).
 -Christoph

Christoph P. Sold                   CATS Software GmbH
                                    Mussbacher Landstr.2
                                    W-6730 Neustadt (Weinstrasse)
ger.xse0035@applelink.apple.com     Germany

"If an apple is fun, what the heck is an appletree?"
From: sold@kit.uni-kl.de (Christoph Sold)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MultiFinder Programmer's Guide?
Date: 14 Aug 92 20:28:12 GMT
Organization: Universitaet Kaiserslautern

In article <6sTaPB2w164w@uuisis.isis.org> rrwood@uuisis.isis.org (Roy Wood) writes:
>Subject: MultiFinder Programmer's Guide?
>From: rrwood@uuisis.isis.org (Roy Wood)
>Date: Mon, 10 Aug 92 16:18:29 GMT
>Since APDA no longer lists the Programmer's Guide to MultiFinder, I take it
>that that document has been superseded by another document (perhaps IM VI?). 
>Could someone please inform me as to what the current definitive source of
>documentation is for MultiFinder compatibility?
>
>Many thanks in advance....
>
>-Roy
You said it -- IM VI. There are some TechNotes on that thing, too.
-Christoph

Christoph P. Sold                   CATS Software GmbH
                                    Mussbacher Landstr.2
                                    W-6730 Neustadt (Weinstrasse)
ger.xse0035@applelink.apple.com     Germany

"If an apple is fun, what the heck is an appletree?"
Newsgroups: comp.sys.mac.programmer
Subject: Re: Map (was: Australian Mac systems)
From: stanger@otago.ac.nz (Nigel Stanger)
Date: 23 Aug 92 15:01:03 +1300
Organization: University of Otago, Dunedin, New Zealand

sold@kit.uni-kl.de (Christoph Sold) writes:
> I wrote, re the Map Control Panel:
>>
>>So is there _any_ documentation on this anywhere?
> 
> Here in Germany, the Map control panel is documented in a "Readme" file 
> sitting next to it on the installation disk.

Damn, you got me all excited there for a minute :) I just checked
my disks, and couldn't find any mention of it anywhere. So much
for that idea...

----------------------------------------------------------------------
Nigel Stanger,                  Internet: stanger@otago.ac.nz
University of Otago,            Phone: +64 3 479-8179
Dunedin, NEW ZEALAND.           Fax:   +64 3 479-8311
"ResEdit development is an oxymoron." -- Jon Pugh
Newsgroups: comp.sys.mac.programmer
From: Roland Mansson <roland.mansson@ldc.lu.se>
Subject: TextEdit bug in 7.0
Organization: Lund University Computing Center
X-Useragent: Nuntius v1.1
Date: Fri, 14 Aug 1992 20:46:28 GMT

I think I've found a bug in TextEdit in System 7. I've verified it by
booting of the System Tools disk (S-7.0.1) and running TeachText (S-7.0).

The bug is that sometimes when moving the insertion point with the left
arrow key, the insertion point ends up in a wrong position.

What happens is that (sometimes) when the insertion point is between char
1 and 2 of a line and you press the left arrow key, the insertion point
moves to the end of the previous line (ie not to before char 1 on the
current line, as it should).

To test it, enter a few lines like these below in TeachText (press return
at the end of each line):

bbxxbgf
gfgfgfgf
gfgfgffg

Put the insertion point somewhere in the middle of line 2 or 3, and press
the left arrow key to see what happens. (If it works, try again. The bug
seems to appear 1 time in 10 or so).

Is this a know bug? Is there a workaround? My main concern is not
TeachText, but I have the same problem in my own app.
-----
Roland Mansson, Lund University Computing Center, Box 783, S220 07 Lund,
Sweden
Phone: +46-46107436   Fax: +46-46138225   Bitnet: ROLAND@SELUND
Internet: roland.manssonEldc.lu.se   or  
roland.mansson%ldc.lu.seEuunet.uu.net
UUCP: {uunet,mcvax}!sunic!ldc.lu.se!roland.mansson    AppleLink: SW0472
Newsgroups: comp.sys.mac.programmer
From: joagre@meryl.csd.uu.se (Joakim Greben|)
Newsgroups: comp.sys.mac.programmer
Subject: DinkClass vs MacApp and TCL
Summary: OOP library
Date: 19 Aug 92 21:37:17 GMT
Organization: UDAC, Uppsala, Sweden

Has anybody used the DinkClass (OOP-library) by Applied Technical Software
as an application platform with MPW C++ or THINK C 5.02.
A demo version resides on the sumex archive and the readme file says
among other things:
 
 We developed DinkClass because the other available class libraries either
 lacked inspiration or where complex without good enough documentation for
 mere mortals to comprehend and use. How many months of evening effort have
 you put into understanding ThinkClass or MacApp enough to develop an
 application with them? It wasn't until I landed a full time job developing
 an MacApp/C++ commercial application developer that I got the idea behind
 these class libraries. I hope that DinkClass will help others to make the
 leap into OOP and using these more sophisticated class libraries possible
 for more programmers and hobbyists.  
 
An alternative to MacApp and TCL?
 
Opinions, Suggestions?

--
joagre@student.docs.uu.se
--
Newsgroups: comp.sys.mac.programmer
From: msadler@amhux1.amherst.edu (Michael S. Adler '92)
Subject: Remote Access through 9600 bps modem pool to 2400 bps modem
Organization: Amherst College, Amherst MA
X-Newsreader: Tin 1.1 PL5
Date: Mon, 17 Aug 1992 17:21:00 GMT


I'm trying to get Remote Access to use a 2400 Multitech modem from a
9600 bps internal LAN (not appletalk) and Remote Access bombs.  This may
be because Remote Access may want flow control, or it may be because
Remote Access can't deal with a second connection.  Does anyone out
there have any idea what the problem here is, and if so, what the
solution might be?  (Would writing a CCL script help?  If so, what would
the script have to include?)
	Feel free to email Msadler@amherst.edu, or post a reply.
Thanks.
	M.
From: klaus@diku.dk (Klaus Ole Kristiansen)
Newsgroups: comp.sys.mac.programmer
Subject: Map (was: Australian Mac systems)
Date: 18 Aug 92 10:55:06 GMT
Organization: Department of Computer Science, U of Copenhagen

hammett@sbsu1.aukuni.ac.nz (Tim Hammett) writes:

>sold@kit.uni-kl.de (Christoph Sold) writes:
>>Of course, you can do it the hard way: Assuming the user has set up the 
>>right location in the Map control panel, you can ask the system for its 
>>location. 

>This won't work for two reasons:

>1. Most users don't bother to set their location in the Map control panel.

I certainly haven't. Is there any advantage in doing so?

Klaus O K
Newsgroups: comp.sys.mac.programmer
From: oster@well.sf.ca.us (David Phillip Oster)
Subject: Re: Disabling Access to Edit Text Items?
Organization: Whole Earth 'Lectronic Link
Date: Sun, 16 Aug 1992 05:10:39 GMT

In article <Bt1u2r.I2H@gpu.utcs.utoronto.ca> farm@gpu.utcs.utoronto.ca (B. Munroe) writes:
>what is the best way to disable access to an edit text item in a dialog

I do a GetDItem, SetDItem to change the type from an edittext item to
a static text item. This solves the problem of the tab key trying to
make it the active field. I do a SelIText if necessary first to make be
a non-active field.

My update procedure does the following after the system has drawn the 
static text items:
Paintrect() with patBic as the PenMode, and "gray" as the PenPat. This
grays out the text.  Then I draw an appropriate FrameRect around the
static text item so it looks like a grayed out edittext item.
From: John_Shepardson.esh@qmail.slac.stanford.edu (John Shepardson)
Newsgroups: comp.sys.mac.programmer
Subject: Re: CDEF Sample Source Code
Date: 21 Aug 92 16:36:42 GMT
Followup-To: comp.sys.mac.programmer
Distribution: comp.sys.mac.programmer
Organization: slac


> Can anybody help me locate some sample CDEF source code, or suggest
> a better way to do this?  Please e-mail me any replies.  Thanx.
> 
> MeatHead

Appmaker is a fine tool that includes source for several of their cdefs. 
Try it!  Mactutor also has source in Sep 88, Jan Jun & Nov 89
-------------------------------------------
John_Shepardson.esh@qmail.slac.stanford.edu
From: dan@hpnmdla.sr.hp.com (Dan Pleasant)
Date: Thu, 20 Aug 1992 19:53:38 GMT
Subject: Can't rename disk under system 6?
Organization: Hewlett-Packard, Santa Rosa, CA
Newsgroups: comp.sys.mac.programmer

Here's a strange situation, but I'll bet that somebody has run across
it before...

I'm calling PBHGetVolInfo to get a floppy disk's volume info.  Then I
change the ioNamePtr field to a different name (and set the
ioCompletion field to NULL) and call PBSetVolInfo.  This should change
the name of the disk, right?

Well, under system 7 it works like a champ.  Under system 6.0.7/multifinder
it doesn't work.  Actually, PBSetVolInfo returns noErr, but the name of
the floppy disk never gets changed anyway!

Anybody know what's going on here?

Thanks to all responses,

Dan Pleasant
From: u_banzai@mcl.ucsb.edu (Marc Tamsky)
Newsgroups: comp.sys.mac.programmer
Subject: Conflict: HAM 1.0, PopUpFuncs, MPW Shell 3.2, BBEdit, FileSaver.
Date: 21 Aug 92 11:09:39 GMT
Organization: Banzai Institute for Strageic Information & Biomedical Engineering
NNTP-Posting-Host: dial-slip43.ucsd.edu
X-UserAgent: Nuntius v1.1.1d7
X-XXMessage-ID: <A6BA1CE6FD060B2B@dial-slip43.ucsd.edu>
X-XXDate: Fri, 21 Aug 92 04:09:10 GMT

I recently noticed when using a copy of PopUpFuncs and HAM 1.0 at the
same time within MPW Shell 3.2, every time you click on the funny ball
in the menubar it goes out to disk twice and produces a noticeable
delay in drawing the menu. This delay is longer, and has more disk
activity when FileSaver from Norton Utilies is installed and active.
(I traced this problem down with InitTracker which is a great utility,
kudos to Andrew Welch for making this.)

I have since turned off FileSaver.  HAM I love and don't want to get
rid of it.   Is there something I can do to fix this?

(Also BBEdit seems to do the same disk-access thing with FileSaver
installed whenever I open a document. Now get this: There are about 3
seconds of disk access when I open a document using BBEdit, when BOTH
BBEdit AND the DOCUMENT are on RAMDISK!!!! [FileSaver Installed] What
gives?  FileSaver bug I have to guess....!)

Any help...please followup.

----------
u_banzai@mcl.ucsb.edu    	  KB6JWE		 Marc Tamsky

In New Salem, ND stands the worlds largest Holstein Cow.
12000#, 38' H, 50' L.....	it's fiberglass!
Newsgroups: comp.sys.mac.programmer
From: raffuj@aix.rpi.edu (Jose A. Raffucci)
Subject: Re: Killing UpdateEvents
Organization: Rensselaer Polytechnic Institute, Troy, NY
Distribution: usa
Date: Fri, 21 Aug 1992 00:25:05 GMT

thanks for the replies, I let my update routine handle it all, and it works   

just fine.  I'll give the file stuff that was posted a shot...

-hOz

-- 
X/\/\/\/\/\/\/\/\__/\__/\/\/\/\/\/\__/\__/\/\/\/\/\/\/\--:OO  _________________|
  //  The Amigoids from hell,     raffuj@rpi.edu     Ren & Stimpy (SNICK) 
\X/   Renssepolyinstatechnitute                 New Episodes! Aug 15, 7:00 pm   
Oh my beloved Ice Cream Bar!  How I love to lick your creamy center!  ChowwmP!
Newsgroups: comp.sys.mac.programmer
From: zben@ni.umd.edu (Charles B. Cranston)
Subject: Re: Simple Question:  Getting the vRefNum and DirectoryID
Followup-To: comp.sys.mac.programmer
Organization: UM Home for the Terminally Analytical
Distribution: usa
Date: Wed, 12 Aug 1992 21:42:01 GMT

In article <1992Aug11.185456.10885@nntp.uoregon.edu>,
eric_gorr@coglab_psych.uoregon.edu (Eric Gorr) wrote:

> Let's say that I have a valid path stored in a varable defined as:
> char    *thePath;
> The String in the path would look something like:  "P300:mydir"  with
> P300 being the volume and mydir (obviously) being the directory.
> What I need is the volume reference number and the id for this directory.

This is a little more complicated than it first seems, since the
GetCatInfo call is not documented to return the vRefNum.  Best
scheme I can think of is:

1. Temporarily save the length byte of the path string.
2. Scan the path string searching for the first colon.
3. Stuff the index into the length byte so just the volume
   name and colon are in the string.  For the example P300:mydir
   above we would have saved 10 in step 1, we now set the length
   byte to 5 so the string says P300: only.
4. Do a GetVolInfo on the string (ioVolIndex zero) and obtain the
   desired vRefNum from ioVRefNum.
5. Restore the saved length byte from step 1.
6. Do a GetCatInfo on the string (ioVRefNum, ioDirID, ioFDirIndex zero)
   and obtain the DirectoryID from ioDirID.

What do we do if a colon is not found in step 2?  Do a GetVol and
use the result (current default volume) as vRefNum?

zben@ni.umd.edu     -KA3ZDF
Newsgroups: comp.sys.mac.programmer
From: heksterb@cs.utwente.nl (Ben Hekster)
Subject: Re: Porting code using fork() to the Mac
Organization: University of Twente, Dept. of Computer Science
Date: Sun, 16 Aug 1992 08:36:56 GMT

In article <1992Aug16.001018.26666@reed.edu> orpheus@reed.edu (P. Hawthorne) writes:
>  In the docs, there is some interesting discussion of a scheme for marking
>all unused code resources purgeable. The idea was to mark all code
>resources purgeable with the obvious exception of one resource, followed by
>a walk of the stack looking for anything resembling a return address, so
>that the relevant resources could be marked as non-purgeable.

Hey, I do this!  And you say this scheme is actually documented
somewhere?  It's exactly as you describe-- I keep all but a few 'CODE'
segments purgeable, and install a grow zone function that scans the
stack for addresses within these segments.  Any segment that
isn't referenced from the stack is unloaded from the gz function.
I know it sounds skanky but it works great!

	Obvious advantages:  I never ever have to worry about calling
UnloadSeg again, so I can resegment my applications at any time without
having to worry about whether I'm doing UnloadSeg calls in the right
order and in the right place, and since I'm also not doing UnloadSeg
in the main event loop on every CODE segment, there is zero overhead,
if you have enough memory.

	Disadvantage:  Could fail under Pink.

-- 
Ben `Hackster' Hekster		| "He bides his time and thinks,
heksterb@cs.utwente.nl		|  'There must be more to life than this!'"