- Welcome to NeXTcommunity.
News:
The NeXT Computer is now 37 years old!
Recent posts
#91
General Discussion / Re: Layered.work NeXTSTEP Nami...
Last post by Rhetorica - Dec 17, 2025, 10:40 PMIt's interesting to trace down the genealogy of these articles based on their mistakes.
I think the first must be the kevra.org list, which originates the claim that "NextStep" was never an official stylization. In reality, it was always an unofficial stylization used inside NeXT, and when the NEXTSTEP name was first announced at the NeXT Event in Oct 1988, Steve's own slides called the operating system "NextStep."
This other article (from the NEXTSPACE GitHub repo, found by @ZombiePhysicist) seems to repeat the kevra.org errors, but also adds in the spurious stylization of "OPENSTEP for MachOS." There are a handful of citations for "MachOS" that go back to 1996, shortly after OPENSTEP was officially adopted as the name for the operating system product, but no NeXT product ever used this; the actual name is "OPENSTEP for Mach." Presumably "MachOS" is an invention of zealous enthusiasts who thought it was flattering to make "Mach" and "Mac OS" look as similar as possible.
I went over the mistakes in the above two articles here.
The layered.work article you posted above seems to be downstream of the NEXTSPACE article, as it repeats all of the above errors but has an additional corruption: it refers to OPENSTEP for Mach as OPENSTEP for MacOS, which is patently untrue and could only be the product of a major typo.
Although the possibility of an OpenStep API running on Classic Mac OS (a reverse "Blue Box" situation) was a common object of speculation—particularly since NeXT had managed to port OpenStep to Windows 95, another severely deficient consumer operating system—no such product was ever announced, and there is no mention of it in the January 1997 proclamations from Gil Amelio et al. that are on the Neue Horizonte CD.
We should probably reach out to these people and try to get their material fixed.
I think the first must be the kevra.org list, which originates the claim that "NextStep" was never an official stylization. In reality, it was always an unofficial stylization used inside NeXT, and when the NEXTSTEP name was first announced at the NeXT Event in Oct 1988, Steve's own slides called the operating system "NextStep."
This other article (from the NEXTSPACE GitHub repo, found by @ZombiePhysicist) seems to repeat the kevra.org errors, but also adds in the spurious stylization of "OPENSTEP for MachOS." There are a handful of citations for "MachOS" that go back to 1996, shortly after OPENSTEP was officially adopted as the name for the operating system product, but no NeXT product ever used this; the actual name is "OPENSTEP for Mach." Presumably "MachOS" is an invention of zealous enthusiasts who thought it was flattering to make "Mach" and "Mac OS" look as similar as possible.
I went over the mistakes in the above two articles here.
The layered.work article you posted above seems to be downstream of the NEXTSPACE article, as it repeats all of the above errors but has an additional corruption: it refers to OPENSTEP for Mach as OPENSTEP for MacOS, which is patently untrue and could only be the product of a major typo.
Although the possibility of an OpenStep API running on Classic Mac OS (a reverse "Blue Box" situation) was a common object of speculation—particularly since NeXT had managed to port OpenStep to Windows 95, another severely deficient consumer operating system—no such product was ever announced, and there is no mention of it in the January 1997 proclamations from Gil Amelio et al. that are on the Neue Horizonte CD.
We should probably reach out to these people and try to get their material fixed.
#92
General Discussion / Layered.work NeXTSTEP Naming
Last post by jeffburg - Dec 17, 2025, 05:11 AMDid someone already post this?
https://layered.work/nextstep-naming/
https://layered.work/nextstep-naming/
QuoteFor decades, the precise naming and capitalization of NeXT's operating systems have been a source of endless confusion. Was it NeXTstep, NeXTStep, or NEXTSTEP? The answer often changed depending on the specific version, the architecture, or the marketing strategy of the time.
#93
Software / Re: Doom history
Last post by ZombiePhysicist - Dec 16, 2025, 07:52 AMhttps://groups.google.com/g/comp.sys.next.advocacy/c/cHm9_2qeoZc/m/2SwHF9kRrCkJ
This thread seems to talk about it not being out in January of 94. I must have been imagining it because I could swear we had an early version. I wonder if next employees might have gotten an early peek. More likely, I'm just misremembering.
This thread seems to talk about it not being out in January of 94. I must have been imagining it because I could swear we had an early version. I wonder if next employees might have gotten an early peek. More likely, I'm just misremembering.
#94
Software / Re: Doom history
Last post by Rhetorica - Dec 16, 2025, 02:14 AMThis page lists all of the DOS Doom alphas that are known to have been leaked prior to the release of 0.99 on 12/10/1993: http://toastytech.com/dooma/index.html
All of the pre-releases are very distinctive and have changes to their HUDs that would be impossible to confuse with the finished product, even in vague memories. The dates are:
Alpha 0.2 (Technology Preview): 2/4/1993 (big helmet HUD)
Alpha 0.3: 02/28/1993 (big helmet HUD)
Alpha 0.4: 04/02/1993 (HUD is empty bar with green background)
Alpha 0.5: 05/22/1993 (HUD is small bar with blue text)
Beta (Press Release Preview): 10/16/1993 (score system, lives system, text shows in bottom-right)
As far as I know the NeXT release of 0.99 was basically simultaneous with the DOS release. However the oldest files I can find are much later, from 1995.
Absolutely no binaries existed for Doom in 1992. Tom Hall's Doom Bible is dated to 11/28/1992. For those familiar with the internal history of Doom's development, his departure was in August of 1993, and led to a bunch of changes to the game in terms of scaling back the plot and lore of the setting; his original vision for game development was much more cinematic, and even Rise of the Triad (the project he went on to do at Apogee) fell short of it in its final released form.
Had the Bible been followed without changes, then FPSes would have jumped forward 5 years ahead in terms of norms and fashion; the game would have played like Half-Life or Doom 3—the player is present during a major industrial disaster involving portal technology and has to work through the process of fixing it, ultimately passing into the other world to defeat the boss of the invaders. It called for interactive NPCs and even marine bots that would accompany you through levels, which are hallmarks of Half-Life and its expansions.
John Romero's autobiography Doom Guy is really good for giving detail on the development process aside from what I've already noted here. In terms of "strange anomalies from 1993," ShadowCaster deserves mention; its engine has some of the limitations removed from Wolfenstein but isn't as powerful as Doom, and Carmack wrote it.
All of the pre-releases are very distinctive and have changes to their HUDs that would be impossible to confuse with the finished product, even in vague memories. The dates are:
Alpha 0.2 (Technology Preview): 2/4/1993 (big helmet HUD)
Alpha 0.3: 02/28/1993 (big helmet HUD)
Alpha 0.4: 04/02/1993 (HUD is empty bar with green background)
Alpha 0.5: 05/22/1993 (HUD is small bar with blue text)
Beta (Press Release Preview): 10/16/1993 (score system, lives system, text shows in bottom-right)
As far as I know the NeXT release of 0.99 was basically simultaneous with the DOS release. However the oldest files I can find are much later, from 1995.
Absolutely no binaries existed for Doom in 1992. Tom Hall's Doom Bible is dated to 11/28/1992. For those familiar with the internal history of Doom's development, his departure was in August of 1993, and led to a bunch of changes to the game in terms of scaling back the plot and lore of the setting; his original vision for game development was much more cinematic, and even Rise of the Triad (the project he went on to do at Apogee) fell short of it in its final released form.
Had the Bible been followed without changes, then FPSes would have jumped forward 5 years ahead in terms of norms and fashion; the game would have played like Half-Life or Doom 3—the player is present during a major industrial disaster involving portal technology and has to work through the process of fixing it, ultimately passing into the other world to defeat the boss of the invaders. It called for interactive NPCs and even marine bots that would accompany you through levels, which are hallmarks of Half-Life and its expansions.
John Romero's autobiography Doom Guy is really good for giving detail on the development process aside from what I've already noted here. In terms of "strange anomalies from 1993," ShadowCaster deserves mention; its engine has some of the limitations removed from Wolfenstein but isn't as powerful as Doom, and Carmack wrote it.
#95
Software / Re: Doom history
Last post by ZombiePhysicist - Dec 16, 2025, 01:33 AMThis talk made me think about it, and I could swear something might have been out for public viewing on NeXT even as early as 1992, but perhaps I'm misremembering?
https://www.instagram.com/reel/DR1ArULDL2u/
The reason it's relevant is if there were public releases prior to Sega Yu Suzuki Virtual Fighter/Daytona/Virtual Cop (Martin Marietta flight simulator derivatives) releases, it re-writes a bit of 3D gaming history.
https://www.instagram.com/reel/DR1ArULDL2u/
The reason it's relevant is if there were public releases prior to Sega Yu Suzuki Virtual Fighter/Daytona/Virtual Cop (Martin Marietta flight simulator derivatives) releases, it re-writes a bit of 3D gaming history.
#96
Software / Doom history
Last post by ZombiePhysicist - Dec 16, 2025, 01:30 AMSo everyone knows that Doom was released on MSDOS on December 10, 1993.
But I vaguely remember getting a NeXT release before then. Does anyone know when the NeXT releases came out?
But I vaguely remember getting a NeXT release before then. Does anyone know when the NeXT releases came out?
#97
Hardware / Re: NeXTDimension VRAM error
Last post by KennyPowers - Dec 13, 2025, 10:57 PMI'm still plugging away at this. Using these schematics, I've now verified continuity and checked for shorts between nearly every component involved with addressing the VRAM (VRAM chips, memory controller, all of the buffer chips, some various logic gates, all the way back to the SIMM slots). Annoyingly, those schematics use reference designators for each component, but those designators aren't actually printed on the board. So, I've labeled each component here as I've figured out which one is which...thought this might be useful to someone trying to use those schematics in the future:
Unfortunately, I haven't found any bad connections or shorts, so I'm growing increasingly confident that there's a bad chip or component somewhere. Using the NeXT> prompt to inspect the VRAM contents, I see errors throughout the entire VRAM address range, so I don't think it's a bad VRAM chip. There are also separate pairs of buffer chips for each VRAM bank (U33, U35, U55, U78), so I doubt one of those is the culprit since the errors seem to occur across the entire address range (unless the two VRAM banks are addressed in an interleaved fashion...I don't know). So basically, I'm stuck. I can't discern a pattern to the errors, except that if reading a VRAM address is going to return an incorrect value, that address seems to always end in 0 or 8, but not all such addresses read as the wrong value. Still, maybe that narrows it down to the VRAM chips that handle bits 0-31 of the board's 64bit memory bus, or signals/components specific to them? It's hard to poke at this thing with an oscilloscope without assembling the cube outside of its shell somehow...maybe that's what I need to try next
If one or more of those 13 buffer chips is bad, then I don't know of a source for replacements other than a donor board. I think there might be room to socket them, but then there's still the problem of finding replacements. Anyone out there have a working ND board they wanna sell me? This big bright 21" Color MegaPixel is sitting here sad and unused 
Unfortunately, I haven't found any bad connections or shorts, so I'm growing increasingly confident that there's a bad chip or component somewhere. Using the NeXT> prompt to inspect the VRAM contents, I see errors throughout the entire VRAM address range, so I don't think it's a bad VRAM chip. There are also separate pairs of buffer chips for each VRAM bank (U33, U35, U55, U78), so I doubt one of those is the culprit since the errors seem to occur across the entire address range (unless the two VRAM banks are addressed in an interleaved fashion...I don't know). So basically, I'm stuck. I can't discern a pattern to the errors, except that if reading a VRAM address is going to return an incorrect value, that address seems to always end in 0 or 8, but not all such addresses read as the wrong value. Still, maybe that narrows it down to the VRAM chips that handle bits 0-31 of the board's 64bit memory bus, or signals/components specific to them? It's hard to poke at this thing with an oscilloscope without assembling the cube outside of its shell somehow...maybe that's what I need to try next
If one or more of those 13 buffer chips is bad, then I don't know of a source for replacements other than a donor board. I think there might be room to socket them, but then there's still the problem of finding replacements. Anyone out there have a working ND board they wanna sell me? This big bright 21" Color MegaPixel is sitting here sad and unused 
#98
Virtualization / Re: What version of MS Windows...
Last post by Rhetorica - Dec 12, 2025, 08:49 PMAh, yes, this long-lost thread strikes back. Right, so.
I've been able to get NXHosting to work on versions as late as Windows 2000 (and maybe XP? I don't quite recall.)
It's no problem to run OPENSTEP Enterprise on modern Windows:
The tricky part on almost all versions past NT4 is that you have to modernize the Services entries. I've attached next-daemons.reg which does this for you. (Verdraith figured it out first, independently of me, but I only discovered that later.) Also attached is a classic Windows color scheme that uses the correct gamma to match NXHosting.
Beware that NXHosting to Windows isn't officially supported (documentation claims it's impossible.) In particular, drag-and-drop won't work, and if you're using a VM to run Windows with clipboard integration, then copying text on the host won't carry over into NXHosted apps (WindowServer does check for clipboard updates on the Windows guest, but doesn't know how to deal with other programmatic updates to the clipboard.)
Also, OSE likes to stomp on the PATH environment variable. I've had cases where Previous couldn't compile because NeXT helpfully inserted gcc 2.7.2.1 into my toolchain, which didn't know how to make sense of all those newfangled language features!
See installation media here: http://cdrom.nextcommunity.net/windows/
I've been able to get NXHosting to work on versions as late as Windows 2000 (and maybe XP? I don't quite recall.)
It's no problem to run OPENSTEP Enterprise on modern Windows:
The tricky part on almost all versions past NT4 is that you have to modernize the Services entries. I've attached next-daemons.reg which does this for you. (Verdraith figured it out first, independently of me, but I only discovered that later.) Also attached is a classic Windows color scheme that uses the correct gamma to match NXHosting.
Beware that NXHosting to Windows isn't officially supported (documentation claims it's impossible.) In particular, drag-and-drop won't work, and if you're using a VM to run Windows with clipboard integration, then copying text on the host won't carry over into NXHosted apps (WindowServer does check for clipboard updates on the Windows guest, but doesn't know how to deal with other programmatic updates to the clipboard.)
Also, OSE likes to stomp on the PATH environment variable. I've had cases where Previous couldn't compile because NeXT helpfully inserted gcc 2.7.2.1 into my toolchain, which didn't know how to make sense of all those newfangled language features!
See installation media here: http://cdrom.nextcommunity.net/windows/
#99
Virtualization / What version of MS Windows do ...
Last post by ptek - Dec 12, 2025, 12:34 AMHi.
What version of Microsoft Windows do you use for emulation of WebObjects and OpenStep Enterprise. I managed to get OSE up and running on my Windows XP Pro SP3 box with a bit of effort. Wanted to know how people are running WebObjects.
Thanks
What version of Microsoft Windows do you use for emulation of WebObjects and OpenStep Enterprise. I managed to get OSE up and running on my Windows XP Pro SP3 box with a bit of effort. Wanted to know how people are running WebObjects.
Thanks
#100
Software / Re: Window Maker Live (Linux d...
Last post by wmlive - Dec 11, 2025, 02:35 PMQuote from: Rhetorica on Dec 10, 2025, 08:42 PMI'm glad El Reg is still keen on your work! With Trixie dropping IA32 support it seems to me that WMlive has a bigger market than ever.To tell the truth, i made sure the author receives a free password for the 7z archives before he even pondered writing a follow up article for the one he already wrote in 2023.I'm wondering if there's a way we could get it showcased by someone on YouTube—there are a lot of channels that do 32-bit PC builds, and a low-demand distro that offers Pale Moon and WM's distinct aesthetic might hit the sweet spot for them.
I'm wondering if there's a way we could get it showcased by someone on YouTube—there are a lot of channels that do 32-bit PC builds, and a low-demand distro that offers Pale Moon and WM's distinct aesthetic might hit the sweet spot for them.The author is a well known NeXSTEP fan and an external advocate of the GNUstep project, while at the same time watched with caution by the latter's developer crowd due to irreconcilable differences regarding the perceived goals of the GNUstep project. It is not easy to get the fantasizing theorists and the realist practitioners under one hat...
There have been videos about former wmlive releases on Youtube before and, quite frankly, most were more concerned with the theming capabilities and the "retro approach" of the desktop than the underlying technical features and merits. Nobody ever really bothered to have a discerning look under the hood to verify how wmlive stands as rescue and administration tool. So far, these videos were next to useless to get an informed overview and probably did more harm than good to kindle any interest.
Other than that it's probably just time to simply accept that there is no point in riding a dead horse anymore. As a Linux distribution, wmlive is simply too idiosyncratic to be ever of interest to the larger crowd of users, most of which born only after Linux started to blossom. Only very few have had the chance to experience the heterogeneous UNIX landscape before the ultimate rise of the mainstream business operating systems dominating the market. Among the majority of the younger ones there is no historic awareness of the evolution of operating systems and software that people like us are so fond of to retrace.
Most of the younger generation grew up with so many shiny choices, that out of human inertia to choose the path of least resistence (contradicting Robert Frost's approach) they grew accustomed to the more convenient offerings covering standard consumer needs. Most people don't want tools, they primarily want entertainment and convenience. Impossible to pique such people's curiosity.
The upstream development and maintenance of the Window Maker window manager has basically ceased and we should probably consider it being an abandoned project by now. With the advent of Wayland slowly becoming mainstream, the fate of Window Maker basically is already sealed and the Wayland based wlmaker simply is still not as capable as its role model. Riding a dead horse probably applies here too.
GNUstep is too slow moving due to the lack of capable developers and absence of any modernization efforts. For example, it is rather annoying that GWorkspace's nice Miller columns are restricted to an insufficient maximum width. By enlarging the main window to full screen size we don't get wider columns but just more of the same insufficiently wide columns added, instead. This directly sabotages the possibility of using long descriptive file names in Linux by making them inaccessible. The only file manager universally usable remains being console based Midnight Commander, IMHO.
The same applies to the standard file chooser dialog box which, to add insult to injury, usually can't even be resized and is stuck at a size destined for an ancient screen resolution of 1024x768, as if we were still in 1995, and that nobody uses anymore. Same also for the WINGs based widgets of Window Maker.
Then there is the shortcoming of GWorkspace being unable to just launch a standard Linux binary by double click. Instead, it just opens it in a text editor which just states "Can't load the file". To actually launch gimp, to use a popular example, it is required to create a cumbersome GNUstep compliant app-wrapper to enable launching it.
This is needlessly a complete backwards approach and GNUstep's GWorkspace would become magnitudes more useful if it had the capability to discern and launch non-GNUstep program formats. The way it is now, it just covers its own niche use case instead of becoming a more universal file manager.
Regarding donations, there is no way around having to acknowledge that human nature of end users doesn't lend itself to enable independent developers to ever make at least a minimum living of their work. We appear condemned to waste the scarce time of our live to earn a meager income by working for non-sharing money harvesting companies, leaving only our limited free time to work on anything more worthwhile than our awful day job. And on top of that we are expected to cover the unavoidable infrastructure costs ourselves.
To get an idea about what kind of user expectations contributes to this self-defeating support for open source software developers, feel free to read the exchange with the Puppet Linux people when recently introducing the wmlive project there.
To add more positive news, i am happy to report that the arm64 based wmlive finally is able to properly install and run on the Pinebook Pro ARM laptop. It is just great that the same operating system works almost the same on this platform as it does on my trusty old Thinkpads.