mattiasb@dront.nada.kth.se (Mattias Berglund) (01/09/91)
I have written an application which makes use of MacTCP, and never had
the problems you described. (Other problems, yes, but not these :-)).
A few suggestions:
* Don't use strcpy to copy pascalstrings as they are not null-terminated.
If you must use PBOpen, try "paramBlock.ioNamePtr = (StringPtr) "\p.TCP";"
* Do use OpenDriver, I use the following in my code:
#define TCPDRIVER "\p.IPP"
static short gRefNum;
OSErr OpenMacTCP(void)
{
OSErr err;
err = OpenDriver(TCPDRIVER, &gRefNum);
return(err);
}
I hope this helps you. If you get by this problem I can give a few hints
about upcoming problems, the ones I stumbled on - more specifically in the DNR
package:
* The routine OpenOurRF has a bug: if the application sits on a volume
different from the boot volume, the OpenResource-call will fail with
a resNotFound. Bracket that call, or even the while loop, with GetVol/SetVol;
or maybe use OpenRFPerm.
* In the include file "AddressXlation.h" the struct hostInfo misses a
vital field:
typedef struct hostInfo {
int rtnCode;
char cname[255];
short numAddrs; /*** Ooops, someone missed this one... ***/
unsigned long addr[NUM_ALT_ADDRS];
};
I don't know if these errors are found i the Pascal interfaces also.
Mattias Berglund
JOB Systemintegration AB
P.O. BOX 34072
S-100 26 STOCKHOLM
SWEDENbernard@boulder.colorado.edu (Bernie Bernstein) (01/10/91)
In article <1991Jan9.140919.2757@nada.kth.se>, mattiasb@dront.nada.kth.se (Mattias Berglund) writes: > > * In the include file "AddressXlation.h" the struct hostInfo misses a > vital field: > > typedef struct hostInfo { > int rtnCode; > char cname[255]; > > short numAddrs; /*** Ooops, someone missed this one... ***/ > unsigned long addr[NUM_ALT_ADDRS]; > }; > typedef struct hostInfo { long rtnCode; /*** This is all I needed to do to fix it ***/ char cname[255]; unsigned long addr[NUM_ALT_ADDRS]; }; I haven't had problems with the hostInfo struct except for the int. These C libraries should use short and long instead of int for the obvious reasons. I like to have code that can work in Think C or in MPW. Bernie Bernstein bernard@boulder.colorado.edu
mattiasb@dront.nada.kth.se (Mattias Berglund) (01/11/91)
The reason I suspect there should be a 'numAddrs' field in the struct is how else do I know how many adresses were found by the StrToAddr call? Looking at the struct with the debugger after a call seemed to confirm this. On the other hand, you are quite right about an 'int' in MPW C should be declared as a 'long' in THINK-C, so now I'm confused. Could someone at Apple explain? Mattias Berglund JOB. Systemintegration AB P.O. BOX 34072 S-100 26 STOCKHOLM SWEDEN
ksand@Apple.COM (Kent Sandvik) (01/14/91)
In article <1991Jan11.092214.28245@nada.kth.se> mattiasb@dront.nada.kth.se (Mattias Berglund) writes: > >On the other hand, you are quite right about an 'int' in MPW C should be >declared as a 'long' in THINK-C, so now I'm confused. Could someone at >Apple explain? The beautiful language we call "C" does not define the sizes of types, only gives directions such as a long should be bigger than a short and so on. Many compiler developers have their ideas about int sizes, 16 or 32 bits. You have the same confusion in the PC world. The most elegant way is to avoid ints totally, and use long or short. Regards, Kent Sandvik -- Kent Sandvik, Apple Computer Inc, Developer Technical Support NET:ksand@apple.com, AppleLink: KSAND DISCLAIMER: Private mumbo-jumbo Zippy++ says: "C++, anything less is BCPL..."