Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!samsung!brutus.cs.uiuc.edu!apple!well!svc
From: svc@well.UUCP (Leonard Rosenthol)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Opening the serial driver.
Message-ID: <15278@well.UUCP>
Date: 1 Jan 90 21:40:54 GMT
References: <3903@atr-la.atr.co.jp>
Reply-To: svc@well.UUCP (Leonard Rosenthol)
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 84

In article <3903@atr-la.atr.co.jp> alain@atr-la.atr.co.jp (Alain de Cheveigne) writes:
>
>
>I'm updating some code according to TN 249 to use OpenDriver() instead
>of RamSDOpen().  I hope in this way to detect when some other terminal
>program has opened the line, to avoid opening twice.  The code I use is:
>
>	short refnum = aoutRefNum;
>	result = opendriver("AOut",&refnum);
			    ^^^^^^
	I don't use MPW C, but at least in Think C, that would look more like
"\pAOut" so that the compiler knew you wanted a Pascal string. Even if that
call to opendriver took a C string, you would then be missing the NULL. Since
the name opendriver is getting is probably some form of garbage, you get a
fnfErr since it can't open it.

>	if (result == portInUse) {		/* port already open */
>		dont_close_serial = true;	/* no need to close on exit */
>		return;
>	} 
>
	This may be a problem.  When changing MicroPhone II over to use the
OpenDriver call instead of RAMSDOpen, we discovered (much to our dismay) that
we were no longer getting back a 'portInUse' error!   MacDTS has confirmed for
us that they is indeed the case that OpenDriver does not know anything about
'ports in use' and therefore does not return this error code. The solution, of
course (according to DTS) - Use the Comm Toolbox!

>Questions:
>
>1) What am I doing wrong?
>
	See above.

>2) If I get OpenDriver() to work, should I still use SerSetBuf(),
>SerHShake(), SerReset(), etc., or are they also superseded?
>
	The rest of your code stays the same, you are simply doing your own
open.  All RAMSDOpen did was a special case of OpenDriver (like GetIcon is
a special call to GetResource) and so you bypass the middle man, and make 
yourself more compat for the future.

>3) If I don't get it to work, is there any objection to keeping with
>RamSDOpen()?  
>
	At least under System 6.x, it works fine.  I can not say for 7.0

>4) If the port is already open, I don't need to open, and I don't
>close on exit.  I expect other programs to act the same.  What happens
>if I opened first, then the other program starts, then I quit.  Is
>there anyway of knowing if the other program still needs the port?
>
	You would be doing the right thing by not opening, if already in use.
Others might not be so nice and will steal your port, which may/will give you
OSErrs when trying to read or write to the port.
	There is currently no form of 'port contention' handling under System
6.x, but I know that the CTB team has been working with the IAC group so that
apps will be able to talk to each other and handle port contentions in the
future.

>5) My program works fine over serial lines.  I'd like it to work over
>ethernet, and maybe AppleTalk.  Is there any chance that someone will
>come out with a piece of software that will emulate a serial port over
>ethernet or AppleTalk?  It would open a window, establish a connection
>to a host and let me log in, and from then on the serial port (A or B)
>would be redirected through this channel.  I wouldn't need to modify
>my code.  
>
>Is this in the CTB?  If so, is there something I should do to be
>compatible?  Or shall I really have to modify my code?
>
	Welcome to the CommToolbox!  This is probably the most important of
the functions of the CTB and that is to make the transport mechanism of data
more transparent to applications.  This means that given the proper tools, you
app could speak serial, ADSP, Telnet, LAT, etc. and now care!
	It will require you to change many parts of your code and there all
new routines and new calling conventions.  I would suggest that you get yourself
a copy of the CTB from ADPA and get playing!

-- 
+--------------------------------------------------+
Leonard Rosenthol        |  GEnie : MACgician
Lazerware, inc.          |  MacNet: MACgician
UUCP: svc@well.UUCP      |  ALink : D0025