[comp.sys.amiga] Conman strangeness

john13@garfield.UUCP (John Russell) (11/15/87)

--
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, immediately locks IBase and grabs the
FirstScreen->FirstWindow pointer (this may not be failsafe, but it's not
vital that the correct window be found, just convenient). While IBase is
locked it redirects stdio from the 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. The second one had its own cursor and
all, but it didn't receive or transmit any i/o to the program and remained
after the program exited and the other con: window closed. We identified
conman as the cause of this behaviour.

Could this be due to a non-implemented packet in conman, like the "no memory
in MORE" bug from a while back? And for anyone with release 1.0 or higher of
conman, have you ever seen a similar problem?

John

PS Anyone who mailed asking for my Panasonic printing program and hasn't
received it by the time you read this, please let me know by mail. I had
trouble reaching a few people, and tried under more than one path in some
cases. In particular wuphys!lel, Mike Schwager and Rick from QUCDNAST.BITNET.

rokicki@rocky.STANFORD.EDU (Tomas Rokicki) (11/16/87)

> 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