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