Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!aramis.rutgers.edu!athos.rutgers.edu!rbthomas From: rbthomas@athos.rutgers.edu (Rick Thomas) Newsgroups: comp.os.minix Subject: Re: Important new program: cleanit.c Message-ID: Date: 11 Oct 89 04:52:10 GMT References: <3492@ast.cs.vu.nl> <3498@solo10.cs.vu.nl> <3539@ast.cs.vu.nl> <3554@solo2.cs.vu.nl> <3592@ast.cs.vu.nl> <3630@solo5.cs.vu.nl> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 34 > Job control. Henry Spencer wrote you didn't object to it *in principle*, > but to the POSIX standard. Perhaps some other scheme would do. Is total > conformance to 1003.1 *that* important to you? I'd rather see an OS with > some job control hooks, than a strictly conforming OS without it. > -- > Maarten Litmaath (mcsun!botter!maart) Wouldn't multiple login sessions -- each with its own screen image -- implemented in the console driver -- be a much better approach? (What I call "Poor man's windows") What I have in mind is the ability to be working away on something that can't be interrupted and I get an idea that I want to try out, so I hit some key combination like, say, -F1 and the current screen image is saved away in a RAM buffer. The executing program continues to execute, but it will be put into io-wait state if it attempts to print to the screen or read from the keyboard. I get a brand new clean screen with a "login:" prompt on it. I log in and do my thing. Then if I hit another key combination like, say, -F2, repeatedly I can cycle thru all the active sessions. Each time a session comes up, it gets it's screen image refreshed from its private RAM buffer. No fuss, no muss, and no need for all the complexity of POSIX job control. What do people think? It should be easy to do. Rick -- Rick Thomas uucp: {ames, att, harvard}!rutgers!jove.rutgers.edu!rbthomas internet: rbthomas@JOVE.RUTGERS.EDU bitnet: rbthomas@zodiac.bitnet Phone: (201) 932-4301