Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!ogicse!milton!hlab From: erich@eecs.cs.pdx.edu (Erich Stefan Boleyn) Newsgroups: sci.virtual-worlds Subject: Re: VR OS wish list (was Re: Update rate, and the C-words) Message-ID: <1991Apr9.040134.11502@milton.u.washington.edu> Date: 8 Apr 91 21:49:48 GMT References: <1991Apr3.060218.4122@milton.u.washington.edu> <1991Apr8.042424.2392 Sender: hlab@milton.u.washington.edu (Human Int. Technology Lab) Organization: Human Interface Technology Lab, Univ. of Wash., Seattle. Lines: 68 Approved: cyberoid@milton.u.washington.edu almquist@brahms.udel.edu (Squish) writes: >How does this thought sound? Why don't we create a virtual reality >system based on a efficent computer solution that has been working for >a while? What could that be? How about Operating Systems? Why >don't we create a VR OS - ie. a kernel that would handle in addition >to usual operating system responsibilities (ie. memory management, >file system, etc.) it would handle VR related tasks (ie. high speed >I/O information, 3D sound, interactive 3D graphics, etc). Nothing >new with this idea, many people have come to the same conclusion. ...[deleted]... >who said that they wanted to be able to have sound coming from >ttyX and the graphic texture map info coming from ttyY etc. Using >this concept why can't we get physical simulation info from ttyZ? >If I/O is being established between VR kernel and DataGloves, why >couldn't we establish a connection between mathematica and objects in ...[deleted]... >breakthroughs in fiberoptics, who knows. SO, where has this posting >lead us? What's in YOUR wish lists? What kinds of abilities would >you think a kernel should have? What kinds of problems could we >solve? How useful would our cheap VR systems be? How could we make >them more useful? Inquiring minds wanna-know. (-: This sounds a bit like some of the arguments to take object-oriented design and carry out some of the programming models into the kernel, so that there is a distributed idea to the whole mess. Well, on *my* wish-list is some of the generalized ideas that would give us the specific ones you asked for... like: 1) Data-flow like model. This already exists somewhat in the concept of UNIX pipes and sockets. Unfortunately, it is still only partially utilized. The idea of having a place to connect (device, whatever) mostly needs the work done, but would be nice to have a uniform structure present under it. It would also be nice to make the connections independent of the machine that they are on, i.e. you would have no problem executing a bunch of processes (in pipes, whatever) across several machines, and it would be syntactically pretty much identical to doing it on one machine. 2) Machine independence of implementation for code and data models. This also exists already to some extent. the few a.out formats for UNIX are documented (and for the variants thereof), and data-space tends to be allocated in a uniform fashion. This could be extended, and a framework provided for code migration, whatever. It would be nearly essential to have this kind of thing for mutiple interacting sessions. 3) Uniform (or at least interfaceable) management method for managing data and code pieces, and what is being used by what user, etc. It seems that the UNIX (& DOS & VMS) idea of a process is breaking down with all of the work being done on new operating systems like Mach and especially the distributed systems. Why not break out of the concept altogether? It seems to be a big stopgap in the code migration idea, even though it provides nice methods of isolation and data protection. Coupled with some resource-scheduling methods for the above, constrained based on performance, seems like an interesting idea. Erich "I haven't lost my mind; I know exactly where it is." / -- Erich Stefan Boleyn -- \ --=> *Mad Genius wanna-be* <=-- { Honorary Grad. Student (Math) }--> Internet E-mail: \ Portland State University / Phone #: (503) 289-4635