Someone has patched NCSA Mosaic to run on modern Linux systems (if that's not an oxymoron).I couldn't get it to build on OSX because of Motif (and port install openmotif didn't help). I dug in a bit but then the smell of gasoline and burning flesh drove me away.
It's not entirely clear to me why this "port" was necessary, since the last time I checked (which was five years ago) it was still possible to run the old NCSA and NSCP binaries on modern Linux systems just by installing the a.out kernel module and a couple other files.
Lesstif on OS X is the way to go. We use it for a Motif program older than Mosaic.
I did this around 10 years ago so that I could make the screen captures at http://www.splode.com/img/www-old-browsers/ .
Getting mosaic to build on linux from source was completely trivial.
Necessary because tons of kernels don't include a.out support anymore, especially on 64-bit (where you need not only 32-bit compat, but a.out compat for 32-bit).
Also, this port appears to be 3 years old. It probably wouldn't even build on a recent Linux system without some fuckery with the linker flags and possibly much more. Irony at its finest!
Linux®: "backwards compatibility? but why would anyone upgrade if we stayed compatible?"
I suppose it's possible that a 32 bit kernel would be required to load the old a.out support, but my link above includes the no-longer-shipped a.out kernel modules and libraries you need.
Oh, you can do it on 64-bit, if you have the correct modules (32-bit compat and a.out 32-bit compat). It'll probably work just fine (note, I have not tested it; will get around to doing so later today, so if it doesn't, oops!).
Also, beware including kernel modules when it comes to Linux, as they don't believe in kernel ABI stability and even have a document justifying the reasoning behind it (I'll save you the pain - the reasoning is FREEEEEEEDOM!).
Elizabeth, there's a bit of difference between kernel driver and userspace interfaces. Linus Torvalds' view is that userspace interfaces are set in stone and changes are not tolerated, while driver interfaces are intended to change so that you have further incentive to give up your code into the hands of the wider community.
http://www.kroah.com/log/linux/stable_api_nonsense.html is Greg Kroah-Hartman's words about driver API's and the ensuing ABI. That's the part where your code is wanted in the Linux tree, so making it hassle to hold on a separate tree is to the benefit of everyone who uses a mainline kernel.
https://lwn.net/Articles/292769/ is Linus' words about userspace compatibility - because the arms-length stuff you and I build to run against today's Linux kernel must work further down the line.
K3n.
This winds up matching what the other halfway decent general purpose operating system team did too, albeit their kernel ABI mutates somewhat more slowly. Raw NT or Win32 programs from the nineties still run, and the only reason Win16 programs don't run is that everybody has a 64-bit CPU and the 64-bit long mode disables 16-bit 8086 compatibility. But the drivers, just like on Linux, have to live with ABI changes between versions.
Look, I'm sorry, but you are crazy if you believe Linux "matches" what other general purpose systems offer. Linux deliberately avoids having a driver or kernel module ABI. The policy on record (endorsed by Torvalds, Greg K-H, and more) is that they reserve the right to change such interfaces at any time for any reason. They want all drivers to be in-tree, so that when they get a whim to change an interface, they can just hack all affected drivers to match. (Even when they don't have hardware to test and are just hoping that warning-free compilation equals a functional driver.)
If your driver isn't in the tree and they yank the rug out? Your fault, get fucked.
Operating systems like Windows and OS X actually do have intentionally stable driver interfaces. Yes, they aren't as stable as userland-facing APIs, but the commercial vendors are worlds away from the Linux "we spit upon driver API/ABI stability" mentality.
For example, Vista drivers are generally compatible with Windows 7 and Windows 8. The biggest compatibility break Microsoft's had in recent memory was from XP to Vista, and as I understand it that was mostly due to the introduction and enforcement of driver signing, not a big interface change.
In an era of unit test suites and integration testing at compile time, the 'if it compiles, it must work' test is embarrassingly inadequate (yeah, I know - open source so I should show you the code to overcome that problem). Also, the driver models did change for video from XP to Vista - moving out of a kernel privilege level so that bad graphics drivers can be restarted without bluescreening the box; sound drivers were also required to work with a new model.
K3n.
I don't see the upside for them. They'd be stuck supporting the bug for bug, half broken implementation of it in closed source drivers that randomly crashed the kernel.
How is any major kernel developers life made easier by having a stable ABI? Especially given what fun things like closed source video drivers and VMwares drivers have been.
And there you have it: design decisions based on "what makes the developer's life easier" instead of "what's right", "what's maintainable" or "what makes the customer best able to solve their problems."
Ladies and Gentlemen: Linux.
These four properties aren't mutually exclusive.
Then again, I use FreeBSD so what the fuck do I know? We're not a great example of the "Software Freedom uber alles" mentality.
bitchen ... i love testing sites i build in older browsers. thx jwz. (digging your "live comment preview")
My diagnosis (below) suggests the "porting" is just for new versions of lipng.
So blame them.
And yes, the statically-linked binaries work just fine on modern Linux systems (In my case, Linux 3.5.7 x86_64).
-----
Although the commits in that repository are not very enlightening. The only ones that aren't munging the README file are either deleting the configure scripts or changing some libpng stuff:
- ret = png_check_sig(buf, 8);+ ret = png_sig_cmp(buf, 0, 8);
- if(!ret)
+ if(ret)
However, an old version of the README does say
but that URL 404s. However, Wayback Machine suggests this is patch (not available in the Wayback machine) is just more fixes for newer versions of libpng.
Yeah, it took the libpng team a long time to learn the basics of shared library ABI compatibility. When I first started negotiating with them they were basically taking the attitude that every program should have its own private copy of libpng statically linked. They used (and documented) explicit structures which were allocated by the caller and accessed by the callee, and these structures could not only be extended in new versions, but even re-ordered (to "tidy them up") so that you couldn't be sure version N+1 would put anything in the same place in memory as version N.
After a stern talking to they began to create APIs that look like you'd expect, with opaque handles for things whose implementation might change, and allocation handled by the same library that's scribbling in the structures. They still had a few things to learn (like, you can't just rename a bunch of functions in your library and expect old code to magically guess the new names) but they began to make progress from somewhere around the start of the century.
Today you can write a libpng program using the new-style API, compile it, and expect it to stay working even when they ship a new version.
What the fuck is Mosaic doing using PNG? And how do I get an iPod dock for my covered wagon?
In line with the typical commenter here:
Herp derp derp herp herpy derp*.
*: trans. "I got a dock put on my horse. And spinners."
I got it to compile on OS X: http://i.imgur.com/ODurMMK.png
After installing LessTif and libjpeg (through Homebrew with brew install lesstif libjpeg) and applying the following patch, things seem to work. The changes are needed because OS X for some bizarre reason doesn't have malloc.h and PNG support causes all sorts of struct-related errors. I might tidy it up and submit a PR later tonight.
https://gist.github.com/4628854
I don't know if you know -- or care -- but CDE and Motif, real genuine original Motif, are now actual LGPL Free Software.
http://www.marutan.net/cde/
(I wrote about this last here, here.)
[Sigh]
Last year, here. It's late, I'm tired...
Yeah... that would have been really helpful of them... like 15 or 20 years ago.
Geez, the shit I had to go through with Lucid Emacs because of Motif.
IKWYM. I'm unsure there's any relevance or use to it today, but at least the Open Group is showing willing.
The news did make a certain set of old-time (and not-so-old-time) Unix programmers rather happy - I think the Reg was very surprised by how well my article did, given that it was about something really rather obscure.
I know that project lead Peter Howkins, a friend of mine, was pleased with the noticeable bump in interest after the article went up.
I await with interest the Ubuntu CDE remix.
By the way, someone recently asked me if I had a screenshot of the "examine certificate" window from Netscape, the one with the scrollwork borders, to use in a talk. I don't currently have the stomach to try and get the emulators up and running again, but if any of you have them handy and can get that screen shot, I'm sure it would be appreciated!
Oh god, now want to see WTF this is all about.
No dice here, I'm afraid; I can't actually find any site where Netscape 3 doesn't fail to agree with the server on an encryption algorithm.
(Also it's in a Windows 3 VM, so may not have that decoration. Can't remember. What it does do is lock up the UI state if you go to Google because Netscape spawns twenty-billion JS error windows then does something weird with window focus.)
Ah, "Annotate." Someday I'll get back to my "public annotations" implementation.