sfalken@mondo.engin.umich.edu (Steve Falkenburg) (04/25/91)
XferIt 1.3, my Macintosh FTP client, has just been released. For those not familiar with it, it's FTP with a graphical user interface. This new version adds scripting capability, along with the ability to send and retrieve entire directory trees. XferIt is shareware. A single-user license is $10, for one AppleTalk zone is $45, and for an AppleTalk internet site license costs $175. Details, including a pseudo-license agreement are included in the archive. -steve falkenburg Cyberite Systems sfalken@mondo.engin.umich.edu
sfalken@mondo.engin.umich.edu (Steve Falkenburg) (04/25/91)
> XferIt 1.3, my Macintosh FTP client, has just been released. For those not > familiar with it, it's FTP with a graphical user interface. > > This new version adds scripting capability, along with the ability to > send and retrieve entire directory trees. > > XferIt is shareware. A single-user license is $10, for one AppleTalk > zone is $45, and for an AppleTalk internet site license costs $175. > Details, including a pseudo-license agreement are included in the > archive. > > -steve falkenburg > Cyberite Systems > sfalken@mondo.engin.umich.edu > Oh, and XferIt 1.3 is available by anonymous ftp from mondo.engin.umich.edu (141.212.68.14) and is located in /pub/XferIt.sea.hqx
bernard@cs.colorado.edu (Bernie Bernstein) (04/26/91)
In article <1991Apr24.231416.16415@engin.umich.edu>, sfalken@mondo.engin.umich.edu (Steve Falkenburg) writes: > > > XferIt 1.3, my Macintosh FTP client, has just been released. For those not > > familiar with it, it's FTP with a graphical user interface. > > > > -steve falkenburg > Oh, and XferIt 1.3 is available by anonymous ftp from mondo.engin.umich.edu > (141.212.68.14) and is located in /pub/XferIt.sea.hqx I had a problem at first using this version of the program under 7.0 but Steve solved it. Most people have MacTCP in the System Folder ROOT with an alias to it in Control Panels. That is because the programs (Eudora, etc) search for the TCP file in the System Folder. Newer programs (XferIt 1.3) search for MacTCP in the Control Panels folder (if running 7.0). If you have MacTCP in the System Folder with an alias in Control Panels, the XferIt 1.3 will fail to find MacTCP. So you should put MacTCP in the System Folder AND in Control Panels (not an alias) so MacTCP will work with all programs that search in either place for it. Eventually, all programs will work with MacTCP in just the Control Panels folder (maybe). So we are now in the changover process where we need to accommodate programs that work either way until they are all recompiled using the newer libraries. o, ,, , | Bernie Bernstein | , ,, L>O/ \,/ \ ,| University of Colorado at boulder |/ \,,/ \ O./ ' / . `, / | office: (303) 492-8136 | / ` \ ,. ,/ / , ' | email: bernard@cs.colorado.edu | / '' \
rae@alias.com (Reid Ellis) (04/30/91)
Bernie Bernstein <bernard@cs.colorado.edu> writes: >If you have MacTCP in the System Folder with an alias in Control Panels, >the XferIt 1.3 will fail to find MacTCP. So you should put MacTCP in >the System Folder AND in Control Panels (not an alias) so MacTCP will >work with all programs that search in either place for it. > >Eventually, all programs will work with MacTCP in just the Control Panels >folder (maybe). So we are now in the changover process where we need to >accommodate programs that work either way until they are all recompiled >using the newer libraries. It should be pointed out that there are calls to resolve aliases under system 7 -- will XferIt be adding these calls anytime soon? Or is this buried in the guts of the Mac TCP libraries linked into the program? Reid -- Reid Ellis 1 Trefan Street Apt. E, Toronto ON, M5A 3A9 rae@utcs.toronto.edu || rae@alias.com CDA0610@applelink.apple.com || +1 416 362 9181 [work]
resnick@cogsci.uiuc.edu (Pete Resnick) (04/30/91)
rae@alias.com (Reid Ellis) writes: >It should be pointed out that there are calls to resolve aliases under >system 7 -- will XferIt be adding these calls anytime soon? Or is >this buried in the guts of the Mac TCP libraries linked into the >program? Actually, Apple provided the code that only looks in the System Folder. All of use who use the MacTCP DNR could go back and change Apple's source that is provided with MacTCP, but it will mean sending out a new version when we all get our hands on 7.0. There is some hope that a new version of MacTCP will come out with 7.0, but noone knows whether that will even solve the other problems with the MacTCP DNR, let alone sending us new source that works. The DNR is definitely the weak link in the chain from a programmer's (that is to say, my) perspective. pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet/ARPAnet/EDUnet : resnick@cogsci.uiuc.edu BITNET (if no other way) : FREE0285@UIUCVMD
Jim.Matthews@dartmouth.edu (Jim Matthews) (05/01/91)
MacTCP apps will have to be rewritten, or at least relinked; there's no
getting around the fact that MacTCP now belongs in the Control Panels
folder, and existing apps will not look there. Requiring two copies of
MacTCP is a kludge that users shouldn't have to put up with.
In that spirit, here's my rewrite of the offending routine in dnr.c.
It looks in the Control Panels folder first, then in the regular system
folder, and is not fooled by aliases (but it doesn't resolve them either).
It requires the MPW 3.2 Interface.o (or Think C 4.0.4 MacTraps) for the
Gestalt glue; otherwise it only works under 6.0.4 and later. And it requires
7.0 interfaces (from either the 7.0b1 CD or the 7.0b4 CD) for the
definitions of the Gestalt and Folder manager constants. Hopefully Apple
and Symantec will make the new interfaces and libraries available for FTP
once 7.0 ships.
Enjoy,
Jim Matthews
Dartmouth Software Development
---
short OpenOurRF()
{
SysEnvRec info;
HParamBlockRec fi;
Str255 filename;
long gestalt_response;
short refnum;
OSErr osstat;
osstat = Gestalt(gestaltFindFolderAttr, &gestalt_response);
if ((osstat == noErr) &&
(gestalt_response & (1 << gestaltFindFolderPresent)))
{
short cp_vref;
long cp_dirid;
/* the folder manager is there -- ask about the Control Panels folder */
osstat = FindFolder(kOnSystemDisk, kControlPanelFolderType,
kDontCreateFolder, &cp_vref, &cp_dirid);
if (osstat == noErr)
{
fi.fileParam.ioCompletion = nil;
fi.fileParam.ioNamePtr = (StringPtr) &filename;
fi.fileParam.ioVRefNum = cp_vref;
fi.fileParam.ioDirID = cp_dirid;
fi.fileParam.ioFDirIndex = 1;
while (PBHGetFInfo(&fi, false) == noErr) {
/* scan system folder for driver resource files of specific
type & creator */
if (fi.fileParam.ioFlFndrInfo.fdType == 'cdev' &&
fi.fileParam.ioFlFndrInfo.fdCreator == 'mtcp') {
/* found the MacTCP driver file? */
refnum = HOpenResFile(cp_vref, cp_dirid,
(StringPtr) StripAddress(&filename), fsRdPerm);
if (GetIndResource('dnrp', 1) == NULL)
CloseResFile(refnum);
else
return refnum;
}
/* check next file in system folder */
fi.fileParam.ioFDirIndex++;
fi.fileParam.ioDirID = cp_dirid;
}
} /* Found Control Panels folder */
} /* Folder Manager there */
SysEnvirons(1, &info);
fi.fileParam.ioCompletion = nil;
fi.fileParam.ioNamePtr = &filename;
fi.fileParam.ioVRefNum = info.sysVRefNum;
fi.fileParam.ioDirID = 0;
fi.fileParam.ioFDirIndex = 1;
while (PBHGetFInfo(&fi, false) == noErr) {
/* scan system folder for driver resource files of specific type &
creator */
if (fi.fileParam.ioFlFndrInfo.fdType == 'cdev' &&
fi.fileParam.ioFlFndrInfo.fdCreator == 'mtcp') {
/* found the MacTCP driver file? */
refnum = OpenRFPerm((StringPtr) StripAddress(&filename),
info.sysVRefNum, fsRdPerm);
if (GetIndResource('dnrp', 1) == NULL)
CloseResFile(refnum);
else
return refnum;
}
/* check next file in system folder */
fi.fileParam.ioFDirIndex++;
fi.fileParam.ioDirID = 0;
}
return(-1);
} sfalken@mondo.engin.umich.edu (Steve Falkenburg) (05/01/91)
In article <1991Apr30.172718.11744@dartvax.dartmouth.edu>, Jim.Matthews@dartmouth.edu (Jim Matthews) writes: > > MacTCP apps will have to be rewritten, or at least relinked; there's no > getting around the fact that MacTCP now belongs in the Control Panels > folder, and existing apps will not look there. Requiring two copies of > MacTCP is a kludge that users shouldn't have to put up with. The real solution is to have the authors of the _offending_ apps upgrade. Making new MacTCP programs look in 2-3 different places for MacTCP is a kludge. A fix for Eudora would solve most of people's problems. > In that spirit, here's my rewrite of the offending routine in dnr.c. > It looks in the Control Panels folder first, then in the regular system > folder, and is not fooled by aliases (but it doesn't resolve them either). > It requires the MPW 3.2 Interface.o (or Think C 4.0.4 MacTraps) for the > Gestalt glue; otherwise it only works under 6.0.4 and later. And it requires > 7.0 interfaces (from either the 7.0b1 CD or the 7.0b4 CD) for the > definitions of the Gestalt and Folder manager constants. Hopefully Apple > and Symantec will make the new interfaces and libraries available for FTP > once 7.0 ships. > XferIt does everything this does... _except_, it is fooled by aliases. Guess I'll add an alias check. You know, it seems like this stuff should be already written and working when it comes shipped from Apple... Oh well, steve falkenburg sfalken@mondo.engin.umich.edu
dorner@pequod.cso.uiuc.edu (Steve Dorner) (05/01/91)
In article <1991May1.153943.5808@engin.umich.edu> sfalken@mondo.engin.umich.edu (Steve Falkenburg) writes: >The real solution is to have the authors of the _offending_ apps upgrade. >Making new MacTCP programs look in 2-3 different places for MacTCP is >a kludge. A fix for Eudora would solve most of people's problems. I refuse to write a single line of code for 7.0 until I have 7.0 *and documentation*, *and glue*. (And a separate hard disk to run it on, of course, since 6 & 7 can't coexist...) It's *Apple's* resolver, *Apple's* MacTCP, and *Apple's* implementation of aliases that caused the problem, not I. You may argue that all of Apple's choices were reasonable; fine. Just don't tell me I have an "offending" application :-). Besides, "MacTCP may not be modified, improved, or adapted by the developer." >I'll add an alias check. You know, it seems like this stuff should be >already written and working when it comes shipped from Apple... Novel idea. You know, there is almost nothing in Eudora that checks what it's being run on; obviously, System 7 is going to change that in a big way... -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
ajb@cs.brown.edu (Atul Butte) (05/02/91)
If people are using their own dnr code, I would also like to suggest not just looking in the System Folder for MacTCP... it would be great to also search the application's own directory for it as well. This way, schools blessed with having Macintoshes with only a single floppy drive can also use MacTCP applications (i.e. use InitShare to load the drvr code at INIT time, then put another MacTCP in the app's directory to get the dnr resource). Flexibility in the placement of the MacTCP is key here: if developers can find ways around having to fit MacTCP on a 800K startup disk, they are going to have better luck in university clusters... It would also be great if MacTCP developers could, if the TCP driver itself could not be found, to load it and open it from a MacTCP file in the app's directory... this would eliminate the need to have to put MacTCP on startup disks or deal with InitShare... While we're making a wish list, it would be great to have MacTCP set itself to the current LocalTalk zone instead of having to set it and reboot every time one moves to another LocalTalk zone. Atul Butte Brown University atul@brownvm.brown.edu ajb@cs.brown.edu
veizades@apple.com (John Veizades) (05/02/91)
The new version of MacTCP will handle all problems with System 7.0 and the Folder Manager. I do not encourage MacTCP developers to use the code Jim Matthews posted to the network since it may or may not work with the new version of MacTCP. The new version of MacTCP will be backwards compatible with old applications and systm 6.0.x (where x is greater than 5). Cevelopers that are interested in the new version of MacTCP shoucl come to my presentation at ethe World Wide Developers Conference where I will go into more details about the functionality of MacTCP 1.1. John Veizades... MacTCP Engineering Manager Apple Computer, Inc.
sfalken@mondo.engin.umich.edu (Steve Falkenburg) (05/02/91)
In article <1991May1.161827.23293@ux1.cso.uiuc.edu>, dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: > > I refuse to write a single line of code for 7.0 until I have 7.0 *and > documentation*, *and glue*. (And a separate hard disk to run it on, of > course, since 6 & 7 can't coexist...) You'll have to take that up with your employer. The B4 CD glue with Think C works fine for me. > It's *Apple's* resolver, *Apple's* MacTCP, and *Apple's* implementation of > aliases that caused the problem, not I. You may argue that all of Apple's > choices were reasonable; fine. Just don't tell me I have an "offending" > application :-). You're right on with that one. I also am angry about the way Apple has handled this one. It's ridiculous that a re-compilation will be necessary for ALL MacTCP programs, but it will be. This is one case where even following all of Apple's "rules" doesn't help with compatibility with future systems. I certainly hope the code they release with the new version of MacTCP addresses these problems fully, but based on the style of the previous versions, I HIGHLY doubt it. For starters, they could make there #include and .c/.h files work with both Think C and MPW. It wouldn't be too tough, and hey, why not throw interfaces in for Pascal programmers? > You know, there is almost nothing in Eudora that checks what it's being run > on; obviously, System 7 is going to change that in a big way... That's what _Gestalt is for. Kind of painful to use, but now Apple has made it necessary. > Steve Dorner, U of Illinois Computing Services Office > Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner Just to make myself perfectly clear, I'm not blaming authors of MacTCP applications for them not working under 7... I'm just saying that even though it wasn't their fault, the code will have to be revved. -steve falkenburg sfalken@mondo.engin.umich.edu
myhui@bnr.ca (Michael Hui) (05/02/91)
In article <13275@goofy.Apple.COM> veizades@apple.com (John Veizades) writes: > I do not encourage MacTCP developers to use the code Jim Matthews > posted to the network since it may or may not work with the new version > of MacTCP. Do you know WHY it may not or may work ? More details would be nice. >John Veizades... >MacTCP Engineering Manager >Apple Computer, Inc. Michael MY Hui Ottawa Canada myhui@bnr.ca
jln@casbah.acns.nwu.edu (John Norstad) (05/02/91)
In article <1991May1.215732.11589@engin.umich.edu> sfalken@mondo.engin.umich.edu (Steve Falkenburg) writes: > In article <1991May1.161827.23293@ux1.cso.uiuc.edu>, dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: > > > > I refuse to write a single line of code for 7.0 until I have 7.0 *and > > documentation*, *and glue*. (And a separate hard disk to run it on, of > > course, since 6 & 7 can't coexist...) > > You'll have to take that up with your employer. The B4 CD glue with Think C > works fine for me. It's a shame that Steve hasn't had a chance to work with 7.0 yet. UIUC should have been able to arrange this. Eudora works just fine under 7.0, by the way. I've been using them together for many months. John Norstad Academic Computing and Network Services Northwestern University j-norstad@nwu.edu
jln@casbah.acns.nwu.edu (John Norstad) (05/02/91)
In article <13275@goofy.Apple.COM> veizades@apple.com (John Veizades) writes: > Developers that > are interested in the new version of MacTCP should come to my presentation at > the World Wide Developers Conference where I will go into more details about > the functionality of MacTCP 1.1. I'll be there. I'm holding my breath. Any chance you could post a summary here now? How about a new domain name resolver? I had horrible problems with the 1.0.1 version frequently hanging - my resolver result proc was called with the return code still set to cacheFault - no ip address, no error code, no nothing. I finally had to write my own resolver for my most recent program. I've noticed the same problems in other programs that use MacTCP - domain name resolutions sometimes seem to just hang. Please take my complaints as a compliment - if MacTCP wasn't so great, and if I didn't rely on it so much, I wouldn't care about its problems. I look forward to your presentation, and to MacTCP 1.1. John Norstad Academic Computing and Network Services Northwestern University j-norstad@nwu.edu