From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 4-JAN-1991 01:17:27.95 To: MRGATE::"ARISIA::EVERHART" CC: Subj: VMS integrated POSIX (was Re: XtAddInput and VMS DEC Windows) Received: by crdgw1.ge.com (5.57/GE 1.80) id AA14336; Fri, 4 Jan 91 01:04:08 EST Received: From UCBVAX.BERKELEY.EDU by CRVAX.SRI.COM with TCP; Thu, 3 JAN 91 15:59:32 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA25745; Thu, 3 Jan 91 15:42:08 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-vax@kl.sri.com (info-vax@kl.sri.com) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Jan 91 20:50:36 GMT From: maverick.ksu.ksu.edu!deimos.cis.ksu.edu!mccall.com!tp@uunet.uu.net (Terry Poot) Organization: The McCall Pattern Co., Manhattan, KS, USA Subject: VMS integrated POSIX (was Re: XtAddInput and VMS DEC Windows) Message-Id: <1991Jan3.145036@mccall.com> References: <487@decvax.decvax.dec.com.UUCP>, <1990Nov20.184509.3252@objy.com>, <52.2772c5f0@xmws.uucp> Sender: info-vax-request@kl.sri.com To: info-vax@kl.sri.com In article <487@decvax.decvax.dec.com.UUCP>, evans@decvax.DEC.COM (Marc Evans) writes: >This brings up an interesting problem. DEC claims that VMS is going to be >POSIX.1 compliant in a future version. DEC also claims that full binary backward >compatibility will be preserved. Now then, according to the X specification for >XtAddInput, on POSIX compliant systems, the source argument must be a valid file >descriptor. How is VMS going to deal with this situation? One of the two claims >will have to be dropped, at least from my perspective. Any comments? My guess would be that at first they will take advantage of the cop-out that POSIX doesn't include X, thus POSIX compliance isn't an issue. I don't know if XPG3 branding requires an X interface, or what constraints it would put on such a thing. They will eventually support XPG3 compatibility. I hope they don't do this, but from the presentation at DECUS, it was fairly obvious that to deliver this any time soon, they are going to have to stick _strictly_ to POSIX compliance initially. Other bells and whistles will come later. As far as a real solution, my guess would be separate DECwindows shareable images for POSIX and non-POSIX programs. They are already doing this for the C run-time library. Note that (at least in the first release), POSIX compliance is a modal type of thing. You are either in POSIX mode or VMS mode (the names weren't set yet). A POSIX program must be run in POSIX mode, non-POSIX programs must not be. You will be able to switch back and forth at will, of course, either for a single command, or for the session. If you are running DCL, you aren't in POSIX mode, if you are running the shell, you are. They are going to make as many VMS facilities as possible available in POSIX mode, but some things just won't cut it. If I remember correctly, there is no attempt to make POSIX facilities available from VMS mode. In fact, several people were asking about that, and the POSIX developer said that he was unaware of any effort to do this at this time. Thus extensions to VMS needed to do the POSIX compliance may only be available (at least initially) in POSIX mode. I was impressed by the session, and by what they are doing. They are attempting to go beyond compliance to useability, which is something I had wondered about. For instance, a fork() will be much faster than a lib$spawn or sys$creprc. POSIX mode will use special "light-weight" processes that can be forked quickly. BTW, one example that he mentioned is that many VMS system services are simply incompatible with fork(), since it would copy things like lock-id's. This is an example of a situation where all VMS facilities wouldn't be available to all POSIX programs. It seems that the final decisions on what to do about things like this haven't been made. He said probably if any of these system services had been called, the fork would fail (i.e. any outstanding locks or other resources that can't be cloned). Personally, I can't wait to get it. -- Terry Poot The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA