6 ms·

Consider this. As we know, Tim Berners-Lee developed the first web browser on a NeXT computer, with Display Postscript to render HTML (and print it, too). Two y

• dboreham 7y ago
  Netscape succeeded because they had a 16-bit implementation. 16-bit postscript would have been a significant challenge.
  • DanielKehoe 7y ago
    Ah, yes, Netscape Navigator was available for 16 bit Windows 3.1. Even if NeWS was open source, the vast majority of personal computers at the time weren't powerful enough to run it. I only ever saw it running on a $10K Sun SPARCstation.
  • DonHopkins 7y ago
    That's a good point. PostScript needs floating point numbers and lots of memory. At one point in history, for the typical "Desktop Publishing" setup of a Mac and a LaserWriter, the LaserWriter actually had more CPU power and memory than the Mac! https://en.wikipedia.org/wiki/LaserWriter#Hardware https://en.wikipedia.org/wiki/LaserWriter#Hardware >The LaserWriter used the same Canon CX printing engine as the HP LaserJet, and as a consequence early LaserWriters and LaserJets shared the same toner cartridges and paper trays. PostScript is a complete programming language that has to be run in a suitable interpreter and then sent to a software rasterizer program, all inside the printer. To support this, the LaserWriter featured a Motorola 68000 CPU running at 12 MHz, 512 kB of workspace RAM, and a 1 MB frame buffer. >At introduction, the LaserWriter had the most processing power in Apple's product line—more than the 8 MHz Macintosh. As a result, the LaserWriter was also one of Apple's most expensive offerings. For implementation purposes, the LaserWriter employed a small number of medium-scale-integration Monolithic Memories PALs, and no custom LSI, whereas the LaserJet employed a large number small-scale-integration Texas Instruments 74-Series gates, and one custom LSI. The LaserWriter was, thereby, in the same form factor (for its RIP), able to provide much greater function, and, indeed, much greater performance, all within the very same LBP-CX form factor, although the external packaging was, for marketing purposes, somewhat different.
    • gnufx 7y ago
      The LaserWriter was also, at least in principle, faster than our super-minis at the time, as we only mused.
    • PaulDavisThe1st 7y ago
      ... and the LaserWriter's 68000 wasn't even top of the line for custom RIPs. I worked at a company in Seattle in the early 1990s that had a custom RIP engine based on the Motorola but faster, with more memory and better connectivity to the CPU. I don't remember it's name - I just had to write the device driver for Interactive Linux to make it work :)
• DonHopkins 7y ago
  We certainly fought hard to convince Sun to make NeWS free. James Gosling fought very hard for NeWS, but in the end failed to convince Sun to do the right thing. He was optimistic when he talked me into going to Sun to work on NeWS after I'd already given up on it by 1990, saying that Sun had turned over a new leaf, and was soon going to announce their commitment to NeWS: Date: Tue 6 Mar 1990 08:37:51 PST From: James Gosling <jag@Eng.Sun.COM> Subject: Re: Sun's response to the net To: Don Hopkins <don@cs.UMD.EDU> In-Reply-To: Don Hopkins's message of Tue, 6 Mar 90 05:03:31 -0500 > When is the message from Sun coming out? Will it be from you, or > someone else who will be believed? It'll be from me, and it'll come out today or tomorrow. > Will it mention the possibility of Sun putting xnews in the public > domain, or is it too early to say anything about that? It's too early to say. It looks good so far, but there are still some possible legal problems that we need to check out. > How are the changes at Sun related to making xnews free? Is it a > central point or just a side issue? It's a pretty central issue. > I'm afraid that a renewed commitment to NeWS or internal changes at > Sun just won't mean that much to me or the rest of the world, unless > Sun does something substantial that will benefit everyone, like making > xnews free. As long as Sun keeps NeWS proprietary, any effort they put > into it will just be seen as self serving... We'll get it out, even if I have to spill some real blood on the floor. > What do you think of the theory about DEC making unlimited funds > available for shooting down NeWS? If there's any merit to that, would > they try to keep the X Consortium from accepting the donation of xnews > server source code?? I'm sure DEC couldn't do anything to keep Sun > from donating GNeWS/X11 to the Free Software Foundation, and I know > FSF would take it. (I suspect DEC would much rather NeWS die a slow > painful proprietary death, dragging Sun down with it.) It has been very clear for a long time that DEC explicitly targeted NeWS as something to be trashed. That was probably the major reason for giving NeWS such a ridiculously low profile. There were folks at sun who didn't want to give DEC a bigger target. The folks running the show now have more guts. James. But in the end Sun redefined the meaning of the word "free" by announcing that OpenWindows source code was "Free for $1000": it cost $1000 for the tape media, and nobody was allowed to put it on an FTP server. Here is a link to my flamey-poo on that sensitive topic, followed by the official announcement to which I was reacting. I'll include some choice excerpts, and a couple more links on the topic. https://www.donhopkins.com/home/archive/NeWS/flame.txt https://www.donhopkins.com/home/archive/NeWS/flame.txt >I have been following the messages on the network in the aftermath of the OWPS "free for $1000" disaster... The big problem was not the $1000. It was the word "free". >In short: If you were a slave, what how would you feel if your master announced you could go "free", but he really meant he was selling you down the river for a media cost of only $1000? >[...] For years, we (customers, software developers, and employees) have been asking Sun to make Open Windows available for free, in such a way that it could be distributed on the X11R4 tape or through other public channels, but that has not happened yet. Our biggest concern is not that we don't have to pay money!! The most important thing is that we can make changes to the source code, and give copies of it to anyone who wants it, using any media or distribution channel. But we can't, so it doesn't matter how cheap it is. >Package Includes Window System and Toolkits >MOUNTAIN VIEW, Calif. -- November 13, 1990 -- Sun Microsystems announced today that the source code for its OpenWindows(TM) application development environment will now be available free of charge (cost of media only -- $995). This means that hardware and software developers will now have a cost-effective way to incorporate OpenWindows -- including the easy-to-use OPEN LOOK(R) graphical user interface -- into applications developed or ported to many platforms from different vendors. >The package includes code for the X11/NeWs(TM) Window System, OPEN LOOK toolkits, and OpenFonts(TM) with its TypeScaler(TM) technology. Before today, only OpenWindows binaries were available from Sun. >"Offering free source code for the industry's most advanced, comprehensive window environment demonstrates our ongoing commitment to open systems," said Ed Zander, vice president of marketing at Sun. >[bla bla bla] >Availability >OpenWindows source code will be available January 1, 1991 on magnetic tape for $995 (which includes the cost of media and documentation) through Sun distributors. The source license is included at no cost. There are no royalties for distributing applications developed with OpenWindows. Hardware vendors will pay nominal royalties for systems they resell that run the OpenWindows environment. I left Sun because they asked us to lie to our customers that Sun was going to continue supporting NeWS, but we knew that was not true. Here's a personal apology and explanation I wrote to one of our customers: https://www.donhopkins.com/home/archive/NeWS/Explanation.txt https://www.donhopkins.com/home/archive/NeWS/Explanation.txt >Knut, I just quit my job at Sun because Sun's managment is living a lie. Their words say they support NeWS, but their actions testify to just the opposite. There are many people in Sun who want quite badly to kill NeWS, and they have been trying to do that while at the same time giving lip service to NeWS, so they don't get fired. McNealy and other top level executives say they support NeWS, and say they will fire anyone who tries to kill it. So everyone pretends to be behind it to keep their job, while continuing to sabotage it. It is a very unpleasant and unfortunate situation. And we had a lot of internal discussion about how NeWS fit into Sun's window system strategy. We developed a prototype X11 window manager in NeWS, to prove how much better NeWS can handle seamlessly integrated NeWS and X window management much better than X can manage its own windows. The next step we wanted to take was to write a user-extensible HyperCard-like window manager using HyperNeWS/HyperLook. But Sun management wasn't having it. They actually wanted to do the worst-possible upside-down solution and put NeWS applications inside of X-Windows managed by OLWM, precluding the possibility of arbitrarily shaped windows, tabbed windows, pie menus, all stuff we'd been doing for years with NeWS that we'd have to give up in the name of X interoperability, after we'd already proven we had a working better solution with "owm". https://donhopkins.com/home/archive/NeWS/owm.ps.txt https://donhopkins.com/home/archive/NeWS/owm.ps.txt https://www.donhopkins.com/home/archive/NeWS/sevans.txt https://www.donhopkins.com/home/archive/NeWS/sevans.txt Steve> I could ask you the same question, "If you want NeWS to be a commercial success, why has NeWSTech been so subborn in the sense of resisting trying to fit into the X environment." Don> That's not the same question. We want NeWS to be a commercial success, but "commercial success" is not a standard defined by the X Consortium. I think OWM can do a beautiful job of fitting the X environment into NeWS. If you find that concept terrifying, then you know how we feel about the inverse, knowing that we will have to give up many goals we designed for and successfully achieved, in order to accomodate a half assed "fallback" solution to satisfy some of our customers who want to run our competitors' software (because we aren't allowed to make our software good enough for them to want to run). >We have had a great deal of trouble trying to fit into the X environment. It has taken a huge amount of PostScript code to deal with many X interoperability issues ranging from undocumented selection protocols that XView and OLIT can't even agree on, to input focus grabbing kludges to work around OLWM's incorrect focus tracking behavior, to the fullscreen.ps hack to keep X from grabbing the pointer when NeWS is tracking it. Then there are problems we could do nothing about, like the system locking up when OLWM grabs the server (grabbing the pointer after grabbing the server, and not checking the return value). Many of these problems should have been addressed by fixing X programs or the server, but they were not, instead we had to code around them in PostScript when we could. Window manager flames: https://www.donhopkins.com/home/catalog/unix-haters/x-windows/i39l.html https://www.donhopkins.com/home/catalog/unix-haters/x-window... Who Should Manage the Windows, X11 or NeWS? This is a discussion of ICCCM Window Management for X11/NeWS. One of the horrible problems of X11/NeWS was window management. The X people wanted to wrap NeWS windows up in X frames (that is, OLWM). The NeWS people wanted to do it the other way around, and prototyped an ICCCM window manager in NeWS (mostly object oriented PostScript, and a tiny bit of C), that wrapped X windows up in NeWS window frames. Why wrap X windows in NeWS frames? Because NeWS is much better at window management than X. On the surface, it was easy to implement lots of cool features. But deeper, NeWS is capable of synchronizing input events much more reliably than X11, so it can manage the input focus perfectly, where asynchronous X11 window managers fall flat on their face by definition. Our next step (if you'll pardon the allusion) was to use HyperNeWS (renamed HyperLook, a graphical user interface system like HyperCard with PostScript) to implemented a totally customizable X window manager! Some notes about OWM OWM is the "Open Window Manager" we prototyped in NeWS. We enhanced the NeWS window frames so they sported indexing tabs, pie menus, rooms, and a scrolling virtual desktop. Many of our enhancements were separatly developed, and plugged together orthogonally like legos. All NeWS applications could use these fancy frames, and the Open Window Manager wrapped X clients in the same frames that NeWS windows got! This way, factoring the window frames out as a part of the toolkit, and implementing the X window manager separately, NeWS applications don't have to know a thing about X window management, and X clients can go on doing the same nasty things they've always done, and everybody get the benefits of dynamic extensibility, and a consistent user interface, by using the default window class! I39L window management complicates pinned menus enormously. TNT menus pin correctly, so that when you push the pin in, the menu window simply stays up on the screen, just like you'd expect. This is not the case with XView or even OLWM. Under an I39L window manager, the Open Look pinned menu metaphor completely breaks down. When you pin an X menu, it dissappears from the screen for an instant, then comes back at a different place, at a different size, with a different look and feel. If you're not running just the right window manager, pinned menus don't even have pins! There is no need for such "ICCCM compliant" behavior with TNT menus. When they're pinned, they can just stay there and manage themselves. But were TNT windows managed by an external I39L window manager, they would have to degenerate to the level of X menus. Under the OWM solution, pinned TNT menus work correctly, and they inherit their pinned window behavior from ClassPopupWindow, the same class managing pinned X menus. The look and feel is high quality, consistant, maintainable, and intentionally extensible. If I39L window management has such a negative impact on pinned menus, how else will it impact other parts of the toolkit and applications? Will it effect popup notices? Since they need keyboard input for the buttons, will they have to play the I39L window management game? How do we get the notice tail (a separate canvas) to line up, if the window manager decides to wrap a frame around the notice window? It is impossible to know how it will effect TNT applications, because the toolkit was specifically designed to be subclassed and extended in areas that overlap with I39L window management. NeWSRoom and the TNT virtual window manager are examples of simple, interesting extensions to the window class that are in direct conflict with I39L window management. We would be giving up a lot of actual and potential functionality, that we designed the toolkit to support in the first place. We need to redesign the window class for greater flexbility and easier subclassability, but those goals are at odds with I39L window management. The result of a cross of these two opposing goals would be massivly complex and would sacrifice most of the important advantages of the TNT approach. However, the OWM approach to window management, wrapping X windows in instances of the TNT window class, synergizes with extensions to the window classes. As an extreme example, you can make OWM wrap window frames with title tabs that pop up pie menus full of handy window management functions around all your X windows. There are several other technological advantages of managing X windows internally with NeWS, over managing them externally with X. By an external window manager, I mean one that is in a separate address space as the windows. Relative to the server, all windows are internal, all X "Xlib" and NeWS "wire service" clients are external, and NeWS canvas objects and light weight processes are internal. But an external X window manager is in a different address space must try to manage many shared resources at a distance, an intrinsicly difficult task, imposing limitations on the whole system and unavoidably restricting the user interface possibilities. The management of arbitrarily shaped windows becomes very complicated under an I39L window manager. In contrast, PizzaTool has a popup pizza preview window, whose shape is a rectangular frame around a round (or semi-circular, depending on your appetite) pizza window, with the space between the inside of the frame and the pizza cut out. It was very easy to implement, by subclassing ClassPopupWindow and overriding the /path method to cut out the inside of the frame and ask the center pizza client to add its shape to the path. When you move or stretch the window, you see a rubber-band preview of the actual shape the window will take when you release the button. The pizza path procedure knows to maintain a 1:1 aspect ratio (no oval pizzas), that centers the round pizza in the frame as you drag the resize corner around. The shape of a TNT window is not simply defined by curves or bitmaps -- it is defined by a method of the window object, which can apply constraints and may depend on the state of other objects in the system, like the size or number of slices of the pizza inside the frame. All this nice interactive feedback is totally trivial to implement with TNT, and is completely impossible with an I39L window manager. And even if an I39L window manager could be programmed to perform such custom feedback, it would still have to grab the server and lock out all other animation in the process, instead of using nondestructive overlays like TNT. X11 window managers must grab the server in order to animate rubber-band feedback over the screen when resizing and moving windows. This grabbing causes many problems with NeWS synchronous interests, that can be demonstrated by pressing the "Help" key while dragging out a rectangle on the root background. NeWS can do a much better job at managing global resources in the server because it is in the same address space and it has facilities like the overlay plane specifically designed to implement such window management functions, without even grabbing the server. This antisocial server grabbing behavior is just one symptom of a general class of problems with external X window management, including other important issues such as keyboard and colomap focus. If NeWS alone manages the input focus, it can manage it perfectly. An X window manager alone cannot, because it runs in a foreign address space, and is not in a position to synchronously block the input queue and directly effect the distribution of events the way NeWS is. But even worse is when an X window manager and NeWS both try to manage the input focus at once, which is the situation we are in today. The input focus problem could be solved in several ways: OWM solves the problem elegantly, as PSWM did in the past; OLWM could be made NeWS aware, so that when our own customers run our own external X window manager on our own server that we ship preinstalled on the disks of our own computers, OLWM could download some PostScript and let NeWS handle the focus management the way it was designed. It's criminally negligent to ship a product that is incapable of keeping the input focus up to date with the cursor position, when you have the technology to do so. Your xtrek has paged the window manager out of core, and the console beeps and you suddenly need to move the cursor into the terminal emulator and type the command to keep the reactor from melting down, but the input focus stays in the xtrek for three seconds while the window manager pages in, but you keep on typing, and the keys slip right through to xtrek, and you accidentally fire off your last photon torpedoe and beam twelve red shirt engineers into deep space!