Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rocky!rokicki
From: rokicki@rocky.STANFORD.EDU (Tomas Rokicki)
Newsgroups: comp.sys.amiga
Subject: Re: Conman strangeness
Message-ID: <760@rocky.STANFORD.EDU>
Date: Mon, 16-Nov-87 11:09:48 EST
Article-I.D.: rocky.760
Posted: Mon Nov 16 11:09:48 1987
Date-Received: Wed, 18-Nov-87 04:24:47 EST
References: <4218@garfield.UUCP>
Reply-To: rokicki@rocky.UUCP (Tomas Rokicki)
Distribution: na
Organization: Stanford University Computer Science Department
Lines: 39

> There is a puzzling bug in the very late beta version of Conman which I am
> wondering if it's present in the final version (I don't have that one).
> 
> My program fopen's a con: window, . . .
> 
> This has never given me any problems, yet when I ran it on a friend's machine
> *2* identical con: windows were opened.  . . .

Bill Hawes and I (and Willy Langweld) smashed this bug one afternoon some
long time ago, and it is indeed fixed in Conman 1.0 (and the latest beta.)
The way fopen() usually works is approximately this:

fopen(n)
char *n ;
{
	if (lock=Lock(n)) {
		Unlock(lock) ;
		Open(n) ;
	} else {
		Creat(n) ;
	}
}

or something very similar.  (Locks are faster than Open's if you
might not find the file.  There are more reasons to do this than
just that, though.)  In any case, the Lock() call was opening a
conman window, and the Unlock wasn't closing it.  The default
console handler does not open a window with a Lock() call.  Conman
has since been changed to not open a window on a Lock() call.

While we are on the subject, is there any way to get

	WaitForChar()

to return when EOF (control-backslash) is struck?  Conman does this
properly, returning from the WaitForChar() call; the standard console
handler does not.

-tom