>> Exactly how advanced was NeXTstep in its time, compared to say Windows 95?

Keep in mind that the NeXT computers came out in 1988 and 1990, 7 to 5 years ahead of Win95. They were powered by Motorola 68030/40 CPU's, which were competitors to the Intel 80386/486, and they included 8-32MB of RAM. When Win95 came out a lot of machines only had 4MB still. They also had a 'megapixel' display with 1120 × 832 resolution. Most PC's were shipping with 640x480 VGA graphics at the time.

Price-wise, a NeXT machine had a base price of $4,995 and you could get a Win95 capable PC for $995. But this of course was years later.

A NeXT in 1988 was like getting a PC from 1995. The developer tools, os and network stack were like getting something from 2005. Aside the size of the box and monitor, it was a preview of the future. It took the PC industry seven years to come close... but still not quite match the NeXT. Display Postscript and a general purpose DSP (digital signal processor) made for some amazing capabilities (i.e. software driven modem, oscilloscope apps, etc...).

It was a great experience, I could only see a cube for the first time in 1999 as I had to port a particle engine from Objective-C/Renderman to Windows with Visual C++ and OpenGL.

But Windows 95 was away ahead from other UNIXes in terms of IDE and GUI development experience. Most had nothing more besides Motif + C to offer.

To this day Mac OS X is the only UNIX with SDK tools that can rival the likes of VB and Delphi in native development offered already in Windows 3.x.

> To this day Mac OS X is the only UNIX with SDK tools that can rival the likes of VB and Delphi in native development offered already in Windows 3.x.

If the Gnome foundation would focus on Gtk+Vala+Glade it could have been a fantastic development platform. I don't know much about the state of Vala today though, too bad because it's blazing fast and can use any Gobject library. Unfortunately the docs are just bad compared to Apple or MSDN, the need to find a better way to organise the information on their site or move to a new CMS...

I honestly still don't understand why MS didn't push their version of 'interface builder' they had with VB6 after they went .net. In my view .net was such a step backward - a huge library to load even though the OS comes from the same vendor, way more boilerplate than VB. Why not give VB6 decent networking and database capabilities instead?

The problem with free UNIX clones is that everyone does its own thing, as such you don't have a nice SDK that the community at large can enjoy and effort get scattered all over the place.

Picking Gnome as example, not only do you have what you have mentions, but you also have Anjuta and Builder.

Although Ubuntu now kind of has an SDK based on top of Qt/C++.

However none of them close to the developer experience that Delphi and C++ Builder used to have. Or nowadays the .NET and UWP stack have.

>To this day Mac OS X is the only UNIX with SDK tools that can rival the likes of VB and Delphi in native development offered already in Windows 3.x.

cough Lazarus cough.

Does Lazarus enjoy some kind of component eco-system as Delphi used to have?

Most definitely - admittedly not to the extent of the Delphi halcyon days, but nevertheless still extant.

I like to think about that possibility, sometimes .. in my alternative universe, Steve stayed at Apple, Microsoft became more like Sun (fizzled out in the late 90's), and SGI end up being the one to make the tiBook in all its lovely glory, ushering in an era where the sgiPhone is what we all have in our pockets ..

Things like InfiniteReality architecture and visual-area networks were pretty wild. A nice pdf for you:

https://diglib.eg.org/bitstream/handle/10.2312/EGGH.EGGH97.0...

I'd have loved to have cheaper and cheaper versions of NUMAlink in my desktop with stuff like their FPGA boards and graphics pipes. NUMAlink cards instead of PCI cards. Microsecond latency with almost 80GB/s speeds. Cellular IRIX-style splitting of system along multiple boards for max reliability and efficiency. Nice, alternate reality. :)

That was a nice PDF, thank you. It hurts to see SGI go the way of the Dodo, but it enlightens me to realize that this is The Way in computers. Not all who excel, persist.

(BTW, I'd have been quite happy with an SGI Indy laptop, y'know .. like the one we saw in the movies, a year or so before Steve did the tiBook..)

Multiuser Unix with full preemptive multitasking, memory protection, and with a security model, vs. single-user DOS shell with only partial preemptive multitasking, no memory protection and no security model.

Most of that stuff didn't matter for the single user use case of Windows back then.

Also unless you are speaking about Windows 3.x, your statement about prempemptive multitasking and memory protection is wrong.

I develop software for Windows since the 3.0 version.

> Most of that stuff didn't matter for the single user use case of Windows back then.

It mattered just as much as it matters now, and it will always continue to matter. People didn't know that it mattered because people didn't know anything better. After all, for the vast majority of people crappy DOS-based Windows from Microsoft was the only thing they could afford to use (in every sense of the word, not just financial sense).

> Also unless you are speaking about Windows 3.x, your statement about prempemptive multitasking and memory protection is wrong.

No. 16-bit software was cooperatively scheduled, and there was a lot of 16-bit software in the Windows 95 era. Even significant components of the first version of Windows 95 were 16-bit. Hell, lots of drivers were real-mode drivers!

Software used virtual memory, but there was zero, nada, nil memory protection. In fact it was pretty standard for programs to stomp over each other's memory as a "feature".

> I develop software for Windows since the 3.0 version.

Who cares.

> Who cares.

Whoa. This breaks the HN guidelines. Please edit personal nastiness out of your comments here.

Your comment would be so much better without that last bit.

No, his mention of his experience working with Windows 3.0 is completely irrelevant in this discussion. It's just a very weak attempt at appeal to authority. And if you look in his message history, it's something he does consistently.

Even assuming all that is true, it doesn't change the requirement that you (i.e. everyone) be civil when posting here.

Ah, the Win16Mutex. My personal favorite however (especially when discussing the OS/2 2.0 fiasco) is how the continued dependence on DOS allowed Caldera lawsuits to continue.

I'd love to hear more about that!

Not everyone was running old 16-bit software.

As for who cares, the customers that value my detailed knowledge of how the Windows stack works, since I don't mix technology with OS religion.

> Who cares.

Looks like someone hit a nerve there. Downvoted.

It depends on what "advanced" means. Windows 95 ability to provide backwards compatibility was almost certainly a significantly greater technical challenge than any problem that NeXTstep solved all on its own.

NeXTstep is interesting, but it was largely an integration of existing systems in a greenfield landscape. For example, CUPS remains a useful design today. Back in the days of NeXTstep, it required a high end printer. Windows 95 would [for practical purposes] print to any device or from any application that DOS or Windows 3.x would.

Which is to say that "advanced" depends on whether being able to use an existing impact printer with a new operating system is advanced or if not being able to is.

> CUPS

Hmm...CUPS came way after NeXTStep, way after the NeXT's acquisition of Apple acquisition in fact (wikipedia says 1999). NeXT itself just used lpr/lpd, that was it.

Of course, being Unix, you could hook into the lpd system and add your own filters. NeXT itself did this, using the on-board DPS to RIP for the NeXT Laser Printer (a Canon laser engine) and the NeXT Color Printer (a branded version of the Canon 360 dpi bubblejet). There was a quite a bit of trickiness involved, contacting the WindowServer from a background process and using high-resolution/high-bit-depth rasterising, but it was doable.

Third parties could also do this, for example I made drivers for anything from low-end Epson, HP and Canon ink jet printers (including a more advanced driver for the NCP) all the way to high end proof printers, film recorders and color laser copiers ( $50-90K items at the time). Others hooked up phototypesetters. So you definitely could print to anything as well, and everything would then come out in beautiful Postscript Level 2, with amazing WYSIWYG fidelity.

While the straightforward approach of doing this did require a printer with a raster interface, most low-end printers had that and when there was a print-head, a line of buffering was sufficient. It was more the mid-level laser printers that were a problem, because lasers required a full-page buffer and some just didn't have that much memory.

One time there was a Mission Critical Custom App (MCCA) deployment at a large pharmaceutical company that was in peril because they had several hundred (or thousand? I don't remember) IBM laser printers that did not have enough memory for a raster bitmap...and no-one had thought of that beforehand. Oops. No worries, I created a driver that extracted the text (they were only interested in the text) and precise positioning information and then sent commands in the printer's command language (not PCL or anything else that was well-known) to position/output that text.

Of course, Adobe didn't like all of that printing, and so they continued to tighten the license agreement and hike the fees for print-use of DPS.

OS X didn't start using CUPS until 10.2. I don't remember if the 10.0/10.1 printing architecture was a carryover of the NeXT stuff or something new, but I don't remember it being well liked.

I'm a bit dismayed to hear backwards compatibility - solving problems of an organizations own making - compared favourably with new functionality.

Consumers like being able to run their old software, and in the nineties (and more recently) that meant running software dating back to the 16-bit era of computing. "Solving problems of an organizations own making" is a very goofy way of characterizing that.

I was commenting specifically on Windows 95, and the idea that its ability to run its predecessor's software as being an achievement rather than something one should just naturally expect. Especially considering many of the successive difficulties in this respect were due to short-sightedness in design of the original APIs and then successive generations of API changes, each set meant to replace the last

I've used Quickbooks for my business accounting since 1998. Double entry accounting hasn't changed but I upgraded to Quickbooks 2004 when TurboTax stopped importing older versions with the 2003 Federal Tax season [but that's not where I am going with the API thing]. I still run TurboTax 2004 [see the aforementioned nature of double entry accounting][1].

Anyway where I was going is that as a user, I don't give a shit about API's and the quality of their design. I care about working software. The agile manifesto didn't invent the idea. Just pointed it out in order to change a world where "there are two types of people: programmers and their victims."

But as Faulkner might say, the past isn't even past.

[1]: It gets its own Win2k VM since it has some 16k code for backward compatibility. The VM doesn't connect to the internet because the world has changed.

I see your point about API design, but it's worth pointing out that everybody else was fighting a new revolution every five minutes and leaving behind heaps of the compatibility dead during that era. I imagine NeXT was probably the best of the lot when it came to making a lasting API and not breaking backward backwards compatibility, but perhaps someone who used it (and OS X) more could comment on that.

From the standpoint of business logic, existing working systems tend not to reduce to values equivalent to problematic. Conversely, spending money to replace one system with a more expensive system that provides equivalent value often does reduce to such values.

Well, the Internet was invented on a NeXT machine.

The web, not the internet.

Exactly, the old internet was already available in Xerox PARC.

No, Xerox PARC introduced Ethernet, not the Internet.

Man, so glad we have historians.

Slightly off topic, but this made me look at the efforts to preserve video game history in a whole new light.

Somebody has to become the historians of the early era of video games before it all bit rots away.

I was thinking about the concept of workstations connected over the network protocols, email, remote printers and file servers when I wrote it.

Advanced in what respect? Since I was an undergrad when Windows 95 came out, the thing that leaps to mind is that you could put together a Windows 95 computer for what you'd pay for some little doodad or minor software program for the NeXT platform. And if you spent a little more you'd have room for a Linux partition...

> Advanced in what respect?

As a platform to use and develop for, basically.

Well, it's funny. NeXT was obviously a pretty great platform to develop for (others can speak to that more than I can) but the tools on the PC side at the time were pretty good. Borland and Microsoft were still in a legitimate competition to deliver good tools at a low cost. Delphi wasn't terrible.

The big problem was that Windows 95 was such a crippled platform. In a lot of cases you'd want to do your real development and debugging on an NT machine and simply target Windows 95. (it was not in any way, as someone else stated, a "DOS shell" but it was still pretty bad)

From a user point of view, well, a lot of people thought the NeXT environment was pretty great. Windows 95 was easy to use but it was just MSFT's first step out of the primordial ooze. I'm not sure how much difference it truly made if you spent your whole day in Photoshop or PageMaker or Mathematica or whatever, except you'd expect the Windows 95 machine to crash a lot more often.

Lack of user accounts meant we could kill user32.exe, that had to be followed up by a reboot.

It'd be interesting to go back and run some of the software from the Windows 95 era (and the OS) on a higher-quality machine. I and most of my friends were using low-quality 486s and Pentium clones and it's certainly possible a lot of the problems had to do with hardware quality.

I honestly remember the later Windows 98 experience as being almost crash-free, and since the architecture was basically the same a lot of that probably has to do with higher quality hardware (and better drivers, of course). That was the golden time of the Intel 440lx and 440bx and ECC RAM support on desktop motherboards, when just about every blue screen could be attributed to those newfangled AGP graphics accelerators...

If your PC is faster than a certain speed Win95 won't boot.

This bit us at VMware, since it was common to want to run old Win95-only software in a VM on fast machines. We ended up having the VMM (Virtual Machine Monitor) patch up the bug when it did binary translation.

> If your PC is faster than a certain speed Win95 won't boot.

That's interesting. What's the threshold there?

300Mhz. But you can work around that...

http://virtuallyfun.superglobalmegacorp.com/2011/01/10/windo...

The difference in the price of the hardware that ran the NeXTstep and Windows 95 was still so large that I don't think having the Mac brand would have made a huge difference.

And given what Jobs said about his experience leaving Apple, I don't think a lot of NeXT would have even been made at the time had he stayed. The focus probably would have stayed on Mac and Mac OS. And unless Jobs was somehow able to dramatically change the outcome of that platform, that would have actually resulted in Microsoft being ahead, as Apple wouldn't have OS X, but Microsoft would have Windows NT, which could have ended up being the most sophisticated mainstream desktop OS.

We might have been living in a world where something resembling Vista and Windows Mobile 6 dominated the market...

By the time Windows 95 was released, Nextstep ran on PC hardware.

While this is technically true, it's practically false. I got NeXTstep 3.3 running on a machine in the office by building it from the parts of no less than 4 other machines to get the system to meet requirements. And then it was only in (2-bit) grayscale mode.

Other than hardware compatibility, the OS and Objective-C + InterfaceBuilder development environment was far ahead of the mainstream.

There were a few vendors who sold "certified" NEXTSTEP compatible PCs. They were more expensive than a generic clone PC, but far cheaper than the NeXT hardware. This eliminated the guessing game on device support and typically the component quality was better than generic.

Had NeXT's software pivot been more successful, there would have been more incentive for hardware vendors to pick up DriverKit and write a driver for it.

They were still aiming for high quality, when there should have been an emphasis on quantity.

The implication seemed to be that Nextstep required some inherently expensive hardware to run which it didn't. If in some parallel universe Microsoft had come up with Nextstep, they could have launched it as 'Windows 95'.

The original version of NS for PC (3.1) required 16MB RAM and recommended 24 (32 in 3.2). The software itself cost $800. In 1993-94 there was a massive RAM shortage caused by a factory fire in Taiwan. RAM spiked to over $50/meg. The additional RAM to run NS alone would have been worth on the order of $1000 even in 1995 by which time prices had gone down.

All told, a NS system would cost around 3x the cost of a Windows system.

Yes, this is all true if I'd said 'NS 3.x as it was then, developed by Next, could have been a drop-in replacement for Win 95'. Which I didn't.

No way. Even if Microsoft had been prepared to throw out Windows 3.1 and DOS compatibility (or engineer it in at substantial expense), NeXTStep would never have run acceptably on the low-end target machines.

It was a decade after the '95 release before optimization and hardware advancement had a NeXTStep-derived OS running 'snappily' on consumer desktops.

Nextstep ran on 68030s. Had it been a Microsoft product (since the late 80s) there's nothing inherent in it that couldn't have made it a consumer OS by 1995.

I think one of the problems is the RAM prices back then, which also affected Windows NT sales. 4Mbit DRAM chips was for example costing more than $10 a piece.

That's true but the original Next machine shipped with 8 megs which by 1995 was the recommended amount for Windows 95. There are lots of reasons Nextstep was a commercial failure, I just don't think 'hardware requirements' is fundamentally very high on the list. 1995 was just at the beginning of a rapid decline in DRAM prices, to boot.

MS spent a lot of effort trying to fit Win95 into 4 megs for a reason. I don't think NeXTStep with only 8 megs were a popular configuration, many was upgraded to 16 megs.

Win95 didn't fit in 4 megs all that well. But that's neither here nor there since we're in a parallel universe in which MS started working on Nextstep in 1985 and released a consumer OS based on it in 1995. This seems totally plausible. Next Inc was never really making a consumer OS. In 2007, Apple shipped a Nextstep derivative that ran in 128 megs while its desktop (and consumer) counterpart wasn't really happy with anything less than a couple of gigs.