Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!sun-barr!ccut!titcca!kddlab!atrpost!atr-la!alain
From: alain@atr-la.atr.co.jp (Alain de Cheveigne)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Opening the serial driver.
Message-ID: <3904@atr-la.atr.co.jp>
Date: 3 Jan 90 07:00:35 GMT
References: <3903@atr-la.atr.co.jp>
Organization: ATR International,Japan
Lines: 91
In-reply-to: alain@atr-la.atr.co.jp's message of 31 Dec 89 07:06:27 GMT


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:
[code deleted]
>The result of opendriver() is always -43, which corresponds to fnfErr
>in Errors.h of CInterfaces.  I don't know what that means.  I tried
>installing the SERD resources in the program file, with no success.

Thanks to all who answered my queries.  The trouble was with the driver
names, which I took from the October version of the tech note.  This code
works:

	/* test to see if another program owns the serial port */
	if (SerStatus(OREF,&status) == noErr) {	/* already open */
		dont_close_serial = true;	/* don't close on exit */
		return;
	} /* else */

	/* open serial port drivers */
	refnum = aoutRefNum;
	result = opendriver(".AOut",&refnum);

	[test result for portInUse, portNotCf] [and do what ?]
	[test for other errors]
	[open .Ain]

I use the MPW C 3.0 lower-case version of the opendriver() call, which
accepts C strings.  The standard and probably preferable version would
be: OpenDriver("\p.Aout",&refnum).

The December version of TN 249 corrects the spelling of the drivers.
But the spelling of the constants, and the way they're used in the
call (a pointer to a constant?) are off, at least for MPW C.  And
OpenDriver() doesn't answer portInUse when the port is in use.  Tech
note writers: keep up the good work, you're almost there!

The status call technique suggested by Tim (see code) works.

>Questions:
>[...]
>2) If I get OpenDriver() to work, should I still use SerSetBuf(),
>SerHShake(), SerReset(), etc., or are they also superseded?

They're still ok.

>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?

There seems to be no way.  A pity.  Would be easy if the drivers kept
a count of the number of times they are "opened".  The count would
decrement at each "close", and the driver would close when the count
reaches 0.

The reason for this is to allow several terminal programs to share the
port.  For example, I'm working on a specialized terminal program.  I
don't want to redo a vt-100 or tektronix emulation.  Even if I did, it
would never be as good or complete as Versaterm.  Versaterm is never
going to offer the services my program offers.  I'd like the user to
have both, switching from one to the other under Multifinder.

This model works fine (I use it every day) if a) the programs refrain
from swiping bytes from the background, and b) their interaction with
the host is simple enough.  I'll elaborate if anyone is interested.

By the way, I've just tried removing the RAMSDClose() from my program.
It leaves the port open on exit.  No ill effects yet.  Any objections?


>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.  

Many people recommended the CTB, but it seems it is not exactly the
simple "adaptor" I had in mind.  Seems I can use it only if I modify
my code.  I'll investigate as soon as I can get my hands on it.

I'm a bit disappointed.  I wish I could plug in any off-the-shelf
terminal program (including my own) into an ethernet.


Alain de Cheveigne,
alai@atr-la.atr.co.jp