ferguson@BKNLVMS.BITNET (02/09/88)
My Apollo installation has gotten pretty handy with good ole Aegis over the years, and I'm getting a bit nervous about SR10. I didn't get a seat on the non-disclosure sessions in San Fran, so I only heard a little bit from some pals. Also, the Dialog sessions scared me. Is Apollo going to go all out Unix and X windows? Are they going to do this before GMR3D is completely re-implemented with X server calls? GMR 3D is absolutely fabulous, and I thank the graphics group for the good work. I'd really like to keep using GMR3D, even if it's on an X window background. But from what I heard at the conference, it seems like the graphics group is just jamming on making what works better, and the operating system and user interface people are taking away what works and replacing it with what looks like a Sun workstation. Are we allowed to openly discuss this yet? I want to be ready when my socks are knocked off. Scott Ferguson ferguson@bknlvms.bitnet Bucknell University CAED Center
speyer@apollo.uucp (Bruce Speyer) (02/10/88)
<From: ferguson@BKNLVMS.BITNET (ferguson @ The Internet) < <My Apollo installation has gotten pretty handy with good ole <Aegis over the years, and I'm getting a bit nervous about <SR10. I didn't get a seat on the non-disclosure sessions in <San Fran, so I only heard a little bit from some pals. < <Also, the Dialog sessions scared me. I thought you might be refering to the presentation I gave at ADUS. I didn't want to present the usual marketing hype so I instead talked about how to use Dialogue intelligently. Some of management were a little worried about this topic because it is much safer to say given window system XYZ your user environment problems are solved. Its not that simple whether XYZ is dialogue or open / dialogue, SUNView, MAC windows, etc. The neat thing about these systems is that they take the object-oriented approach to windowing and therefore are incrementally buildable. If you get it wrong the first time you don't have to throw it out and start over, change a template (inheritance) rearrange some windows, reduce or increase the number of techniques, etc. As you improve your system you will gain experience. All the talk tried to do was to pass on some experience that I have with Dialogue. Software systems are scary when just looking at them as a whole, but approached in an incremental and structured fashion there is no reason to fear especially in this case. <Is Apollo going to go all out Unix and X windows? Are they <going to do this before GMR3D is completely re-implemented <with X server calls? Yes and yes, already fully support and distribute X/V11. I'm a CAD application engineer and do not know the answer to your GMR3D question. The DM and AEGIS will still be supported and available. Its your choice which version of UNIX or AEGIS you wish to run or any combination along with your choice for native window manager. <GMR 3D is absolutely fabulous, and I thank the graphics group <for the good work. I'd really like to keep using GMR3D, even <if it's on an X window background. < <But from what I heard at the conference, it seems like the graphics <group is just jamming on making what works better, and the <operating system and user interface people are taking away what works <and replacing it with what looks like a Sun workstation. There is a strong committment behind PHIGS and PHIGS-II. I've been using SR10 and do find that I need a low-level awareness of UNIX even from the AEGIS environment. Need to have some idea what /etc and /usr is now, backslash must be replaced by /.., need an understanding of UNIX protection, etc. I'm not the appropriate person to go into details on SR10 changes. All and all I believe these changes are good because these days you can't avoid using UNIX on Apollos even if you prefer AEGIS due to third party software and the need to work in an hetergenous computer environment which interacts with components such as UNIX, TCP/IP, NFS, etc. I'm bouncing around all the time between BSD, SYS5, and AEGIS. At SR10 the AEGIS environment is better unified. <Are we allowed to openly discuss this yet? I want to be ready when <my socks are knocked off. < <Scott Ferguson <ferguson@bknlvms.bitnet <Bucknell University CAED Center I believe the SR10 project, including its NCS underpinnings, was announced at UNIFORUM this week so there should be aplenty coming over the net soon! Select beta-sites are not too far off either. Bruce Speyer - speyer@apollo.UUCP
oj@apollo.uucp (Ellis Oliver Jones) (02/11/88)
In article <8802090007.AA09431@ELI.CS.YALE.EDU> ferguson@BKNLVMS.BITNET writes: >Is Apollo going to go all out Unix and the X Window System? If what I'm assigned to is any indicator, the answer is yes, Apollo's going to offer seamless support for the X Window System, in *addition* to the graphics interfaces that we have been offering for a long time. Are you asking whether Apollo is going to either abandon GMR and GPR, or force them to work through X's network links? I sure don't see any sign of us doing that. As Joe Bowbeer explained in his talk at the X Window System symposium last month, we're working on integrating X with Apollo's existing graphics packages so they can coexist on the same screen. That is *not* the same thing as layering the existing packages on top of X. As you no doubt have noticed, it doesn't make sense, performance-wise, to *force* GMR3d operations (or GPR) to go through X. The graphics software group (in which I work) is working hard to offer Apollo users more good choices, not fewer. We're working to add a top-quality X implementation to our graphics software product line, not abandon the G?R packages or layer them on X. >I'd really like to keep using GMR3D... A lot of us here think we're going to be improving and extending GMR3D for years to come. Ollie Jones Disclaimer: I donn't claim to represent Graphics Software Engineer official Apollo positions or Apollo product plans. I can only speak for myself.
benoni@ssc-vax.UUCP (Charles L Ditzel) (02/11/88)
In article <8802090007.AA09431@ELI.CS.YALE.EDU>, ferguson@BKNLVMS.BITNET writes: > and replacing it with what looks like a Sun workstation. We should be so lucky. :) I too have not attended any of the non-disclosure meetings, however, their have been some announcements from Apollo. Their Uniforum announcements (according to InfoWorld,etc) state that they will be releasing System V.3 and Berkeley 4.3 version of their operating system. Vague discussions that the OS also allows for parallelism was also mentioned. I have no idea if *this* is SR10. i think not. by the way SR10 is rumored to still have Aegis...i believe Aegis is here to stay (on Apollos). On another track ... Apollo will not support Sun's NeWS (Network Extensible Windowing System) protocol...despite the intent of AT&T (and Sun) to offer NeWS/X in the standard Unix distribution. This is rather disturbing. A large number of computer companies will accept NeWS - an example is Silicon Graphics (others include AT&T, Ridge, Raster, Parallax, Acorn, Celerity, Alliant Ameristar, etc. - these companies are expected to release NeWS products). While Suns will be enjoy three windowing systems (NeWS/X/SunView - actually they are enjoying it *now*) that live together (i.e...you can pull up a NeWS, X, and SunView windows under NeWS), Apollo will limit its customers by simily denying Sun's existence. Since it may be advantageous to have NeWS on the Apollo (say you also have Suns or Silicon Graphics machines) why not? NeWS would open up a number of opportunities on the Apollo. For starters NeWS is based on Postscript - it includes extensions to Postscript that Adobes dismally dispointing Display Postscript does not provide. A recent discription of NeWS (if you are not familiar with it) was recently provided on the net by Don Hopkins@ ucbvax!BRILLIG.UMD.EDU!don in response to the news that Apollo will not support NeWS (EXCERPT) >> Apollo currently has no plans to support the NeWS product. Apollo's window >> strategy is based on the X Window System. > .... > Apollo's Open Dialogue UIMS, along with other recent developments such as > Adobe's Display PostScript product, address the issues of user interface > development and PostScript capabilities under X in a manner we feel to be > superior to NeWS. NeWS has extensions to the PostScript language that allow for programs (light weight processes), running in the display server, to receive input events on behalf of NeWS clients (other programs running on the same computer, or at some remote site). They may process input locally (on the same machine and in the same process where the events are happening), without consuming any communications bandwidth. This is a big advantage, if you want fast, responsive graphical feedback. NeWS processes can communicate with each other by manipulating shared data structures, and by sending messages through the event queue. They can receive low level input events ("The left mouse button was released at location (X,Y) in window W at time T"), and give graphical feedback ("erase the old slider, redraw it at its new position, and fill the border with bright red"). They can translate input from the user into high level, application specific events, which are sent to the client ("set the volume of the CD player to 100%"). NeWS processes can run autonomously in the server, without a connection to a client, providing "desk accessories" such as a calculator, event journaling, menus, and control panels. According to the fellow from Adobe who talked at the PostScript BOF at the X conference, Adobe's Display PostScript provides output capabilities, but has no facilities for receiving input directly from of the X event queue. As I understand his explanation, the X server must send X events over the IPC link (network, shared memory, modem, or whatever) to the client, which must then translate the events into PostScript commands, and send them back over the link to be executed by Display PostScript. Because there is no way for PostScript programs to read events off of the X event queue, the client must process input events behalf of the display server. Messages must go on a round trip, from the X server, to the client, and back to the Display PostScript extension in the server, to produce any graphical output on the screen. In answer to a question, the Adobe representative said that Display PostScript does not go through the X GC (graphics context), but instead, uses its own graphics libraries. I'd like to know just how device dependent these libraries are, and how much work is involved in porting the Display PostScript extension to a new piece of hardware? At the X conference, in her talk about Sun's merged X11/NeWS server, Robin Schaufler explained that X11/NeWS, which will be Sun's enhanced and supported X11 server, consists of two parallel protocol interpreters, on top of the same graphics library. The X11 protocol interpreter and the NeWS "PostScript based" language interpreter are both written in C. They both use the same event queue, and the same "forest" of windows. (A forest of windows is a group of trees of nested windows, on different displays, controlled by one server.) NeWS processes can draw on X "windows" and X clients can draw on NeWS "canvases", because windows and canvases are the same thing. NeWS and X clients can communicate with each other through the single event queue. NeWS processes communicate over IPC links with X clients by using special primitives to encode and decode X events. The NeWS "Lite" user interface toolkit is written entirely in PostScript. Menus, buttons, windows, sliders, scroll bars, and even terminal emulators, are implemented as device independent PostScript programs, in NeWS's object oriented PostScript programming environment. Since the toolkit can run in the server, clients can share the same code, and a copy of the toolkit does not have to be linked into each client. It's easy to modify and customize the NeWS toolkit and user interface, and NeWS clients can use the modifications without having to be changed, recompiled, or relinked. Since you at Apollo seem to feel that that Display PostScript under X11 is a better alternative than Sun's X11/NeWS merge, I'd like hear how it is that you think Display PostScript can support the type of user interface development environment that NeWS does. And if you've got a better idea, I'd sure like to hear about that, too! > Another advantage is that X is a public-domain window > system, making it accessible to the entire industry. Will Adobe's Display PostScript be in the public domain? I sure doubt it! How available will the source code be? And how much will it cost? Will there be educational discounts? How will it be distributed? The X11/NeWS server will be distributed by AT&T as part of their normal source distributions, and no license with Sun will be required. That's certainly accessible if you ask me! I would dearly love to see both NeWS *AND* Display PostScript end up in the public domain, where they belong! But both companies have a bunch of very good people putting a lot of hard work into development and support. But Sun's sure not making a lot of money by selling NeWS binaries at $100 a pop. Besides a tape and a NeWS manual, they include two of Adobe's very own books on PostScript, the Red and Blue PostScriptures. > Most important of all it the fact that the marketplace has chosen X as the > industry standard window system. > > > Ross Chapman, Apollo Computer > !decvax!apollo!chapman_r That's exactly why Sun is supporting X11. The NeWS/X merge didn't happen over night, ya know! -Don (END OF EXCERPT) what don didn't add was that the extensions to Postscript include : -process (lw) -color -path -object - oriented programmatical interface -windows of *any* shape etc.... News also includes a Postscript previewer, Postscript shell, a customizable user interface, international windows, etc. NeWS goes beyond X and provides leading edge features not found in X...but most important NeWS/X provides the best of the two worlds...Apollo seems to have closed that door... So while I commend Apollo on achievments like GMR3D and Dialog. I do not commend them on being closed - minded about offering NeWS/X. -------------------------------------------------------------------- Naturally, the opinions expressed are my own. Charles Ditzel --------------------------------------------------------------------
mishkin@apollo.uucp (Nathaniel Mishkin) (02/17/88)
In article <1670@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: >I too have not attended any of the non-disclosure meetings, however, >their have been some announcements from Apollo. > >Their Uniforum announcements (according to InfoWorld,etc) state that >they will be releasing System V.3 and Berkeley 4.3 version of their >operating system. Vague discussions that the OS also allows for >parallelism was also mentioned. > >I have no idea if *this* is SR10. >i think not. > >by the way SR10 is rumored to still have Aegis...i believe Aegis >is here to stay (on Apollos). DOMAIN/OS is sr10. Lest anyone got too pumped up by the DOMAIN/OS press release and is feeling deflated by this statement of fact, fear not, the changes made at sr10 are worthy of a naming refinement. Some things worth pointing out: Many people have gotten the impression, and still have the impression that Apollo's Unix support is an side interest for R&D. I won't deny that in the (now fairly distant) past, this was the case. I want to stress that now, this impression is definitely wrong. Unix is not an "optional product". Everyone gets Unix. We do Unix. All of R&D "does Unix". We changed an enormous number of things at sr10 to make DOMAIN work "like Unix" (where it wasn't before). We don't do things differently from Unix if there's no extraordinarily good reason to. We may not do Unix exactly the way other people do (i.e. by starting with a port of the BSD or ATT kernel code) and that may make some people unhappy, but we continue to believe that our Unix (a) is what the market wants/needs, and (b) is the best basis for extending Unix functionality. Now I know that there may not be many "Aegis" diehards out there in this audience, but for those that are, well, don't worry. DOMAIN/OS has some changes that may irk you, but we broke nothing that didn't have to be broken. We have compatibility support so that virtually all "old" programs will run, un-changed, un-recompiled, un-relinked. "Aegis" has not gone away. From my perspective, it's really sort of funny to think that way. To most people in R&D, "Aegis" simply means the OS kernel. GPR, the DM, the compilers, the "/com/sh" -- are not "Aegis"; they're libraries and programs. The tons of system interfaces we've defined -- they're not Aegis -- not in the sense that they can't be used from "Unix programs". (There aren't "Aegis programs" and "Unix programs". There are just programs written in one language or another that use some set of system services or another. The choice of language and set of system services may determine portability to other "Unix systems".) I like to think of things like this: We have some base set of functionality, expressed through procedural interfaces. Some of the procedures are implemented directly by the OS kernel proper, and some are implemented in user space (some in global libraries and some in private libraries). Some of the base functionality pays attention to whether the user/program wants System V behavior or BSD behavior. On top of this base functionality are a number of higher level access points. These are what users see: the various shells (csh, Bourne shell, "/com/sh") and the various standard commands (in "/usr/bin", "/com", "/etc", etc.) If you want to think that Aegis is "/com/sh" and the contents of "/com", and that somehow, that's a separate universe, feel free, but I think you get the picture that it's best to look at things as I've just described. Just trying to make sure people have a clear picture... -- -- Nat Mishkin Apollo Computer Inc. Chelmsford, MA {decvax,mit-eddie,umix}!apollo!mishkin
rich@eddie.MIT.EDU (Richard Caloggero) (02/18/88)
In article <3a569abe.c366@apollo.uucp> mishkin@apollo.UUCP (Nathaniel Mishkin) writes: >Now I know that there may not be many "Aegis" diehards out there in this >audience, but for those that are, well, don't worry. DOMAIN/OS has some >changes that may irk you, but we broke nothing that didn't have to be >broken. We have compatibility support so that virtually all "old" programs >will run, un-changed, un-recompiled, un-relinked. "Aegis" has not gone >away. From my perspective, it's really sort of funny to think that way. >To most people in R&D, "Aegis" simply means the OS kernel. Well, ok, so AEGIS hasn't gone away, but what of its distinctive features (acls, object-oriented file system, protected subsystems, nice linker and object library handling...); have these things changed? I would venture to guess that most of these things would not *have* to change in order to implement the various system interfaces on top of them. What of it! Can anyone from Apollo post a list of the changes made to the kernel at SR10? Now, a question/plea!!! I've sent mail to various people at Apollo about this before, but I'm not sure if I've ever posted to this group on this topic, so bare with me if this is an old flame! I'm blind, and thus can't use the DM. I thus log in via an SIO line (siomonit/siologin). Csh likes this arranhment just fine, but various other programs (emt is the bigest culprate) act strangely (differently) when run from an sio line. Also, the tty driver itself is not fully implemented ("stty -tabs ctlecho prterase" is effectively a no-op). Actually, emt works fine if it is run from the node on which you are attached , implying that the node must have at least 2 sio ports on it. Since we have no such node, I must crp to another, and run emt there. Now, everything is fine till you go into remote mode. At that point, emt checks its input, and if it is a crp mailbox, it sends down a special record which is intended to be interpreted by the frob who is passing characters to crp (in most cases the dm). This record says "put the primary input device in raw mode with no echo" so the remote host can do its own input processing. The dm pays attention to such "spm escape sequences" and handles them properly. However, the sio driver does not handle these control messages. Thus, my question is: does anyone have a frob which will take care of this problem (how about a hacked up tty driver). Is their an *easy* (nothing is ever easy) way of doing this (maybe using pty's -- having siologin run some frob that just forks of a csh, and handles these spm escape sequences ...). Thanx for putting up with my ramblings! -- -- Rich (rich@eddie.mit.edu). The circle is open, but unbroken. Merry meet, merry part, and merry meet again.