NeXTcommunity

@netdoll just shared these amazing undertakings from Turbolent (https://github.com/turbolent/) today:

Quote

• Simple package manager for OPENSTEP with some ports of common open source tools, including GCC 3 and a relatively recent OpenSSH: github.com/turbolent/openstep-pkg
• also figured out how to use OPENSTEP's private Interceptor framework: https://github.com/turbolent/openstep-interceptor-example[/color] (https://github.com/turbolent/openstep-interceptor-example). It was used in SoftPC for directly drawing the video output. Given it's private, there is basically no documentation for the NeXTSTEP and OPENSTEP APIs, and only some vague WWDC slides for the public Rhapsody variant (which has a different API). The only hint I could luckily find was in the Quake 2 code
• looks like Apple's GCC 3.1 from Mac OS X 10.2 Jaguar works on OPENSTEP 4.2:
  

  Quoteopenstep> gcc -v
  Reading specs from /usr/local/lib/gcc-lib/i386-next-openstep4/3.1/specs
  Configured with: ../configure --build=i386-next-openstep4 --host=i386-next-openstep4 --prefix=/usr/local --enable-languages=c,c++,objc --disable-shared
  Thread model: single
  Apple Computer, Inc. GCC version 1257, based on gcc version 3.1 20021003 (prerelease)

To get things out of the way—pTek will be disappointed to learn that all of this is for OPENSTEP 4.2 only and will not work on NEXTSTEP 3.3. Sorry, buddy.

The interceptor example is here: https://github.com/turbolent/openstep-interceptor-example

Interceptors are a framework for hooking/wrapping function calls after the main code is already written.

gcc 3.1 is part of the package manager repo, here: https://github.com/turbolent/openstep-pkg

This should mean that we can now compile stuff with a much newer x86 instruction set, since it's from OS X 10.2.

Looking through Turbolent's other repos, I noticed two drivers, both of which are quite young:

Driver for Bus Master IDE: https://github.com/turbolent/BusMasterIDE (3 weeks ago)
Driver for RTL8139 ethernet devices: https://github.com/turbolent/RTL8139 (2 weeks ago!)

I'm sure that'll save a few people a lot of pain.

Oh! this is so cool! thank you!

Good find.

Quote from: Rhetorica on May 18, 2026, 07:45 PMDriver for Bus Master IDE: https://github.com/turbolent/BusMasterIDE (3 weeks ago)

  Look at all those Intel PCI device strings  8)

"Auto Detect IDs" = "0x70108086 0x71118086 0x24db8086 0x29208086 0x1c008086 0x1c018086 0x1c088086 0x1c098086";

PIIX3, PIIX4, ICH5 IDE, ICH9 SATA, SATA IDE Mode, C200 Desktop SATA IDE Mode, C200 Desktop SATA Controller IDE Mode , C200 Mobile SATA Controller IDE Mode.

Uh, yeah, I should note that the drivers might work just fine on NS3.3, since OS4.2's dev environment literally can't produce drivers; NeXT continued using (and recommending) 3.3 systems for this purpose until x86 was deprecated in OS X Server 1.0. I suppose Turbolent might have used the 3.3 dev environment installed on 4.2, though, in which case actual usage on 3.3 would be untested...

Thank you for posting these projects here!

Regarding openstep-packages:

I wanted "modern" software on pre-Mac OS X systems. For Mac OS X several package managers exist, e.g. MacPorts, Fink, pkgsrc, Homebrew/Tigerbrew, leopard.sh / tiger.sh, etc. but I couldn't really find any for NeXTSTEP/OPENSTEP/Rhapsody. There are some separate ports of open-source projects from back in the day, but they're often very old and binary-only, i.e. the source patches needed to rebuild them are not provided.

The closest projects I could find that provided "modern" software including source patches were https://github.com/rjbrown99/next and https://github.com/rhaleblian/backstep. The former only had very few packages and no build instructions, and the latter had some more packages, but the build/installation scripts build all packages, so it's not really a package manager.

At first I had attempted to port pkgsrc, but bootstrapping required a significant number of packages to be built and there were many problems, so I abandoned it after a while. Then I found https://kisslinux.github.io/package-manager and wrote a similar script that works with the stock /bin/csh that ships with OPENSTEP.

QuoteTo get things out of the way—pTek will be disappointed to learn that all of this is for OPENSTEP 4.2 only and will not work on NEXTSTEP 3.3. Sorry, buddy.

As for compatibility with other operating system versions: My main system is OPENSTEP and so far I have only focused on that. These packages might also work on Rhapsody and even NeXTSTEP, I just simply haven't tried yet. Feedback (and patches) are very welcome!

Quotegcc 3.1 is part of the package manager repo, here: https://github.com/turbolent/openstep-pkg

This should mean that we can now compile stuff with a much newer x86 instruction set, since it's from OS X 10.2.

Unfortunately, Apple's GCC 3.1 didn't really work after all, it had internal compiler errors and crashed during garbage collection while e.g. building QuickJS.

Fortunately, I then tried Apple's GCC 3.3 and that version does work fine so far! So we've got an even more modern compiler available because of those bugs/crashers in 3.1 :-)

QuoteLooking through Turbolent's other repos, I noticed two drivers, both of which are quite young:

Driver for Bus Master IDE: https://github.com/turbolent/BusMasterIDE (3 weeks ago)
Driver for RTL8139 ethernet devices: https://github.com/turbolent/RTL8139 (2 weeks ago!)

Regarding the drivers:

I recently came across Omores' video on how to run Rhapsody DR2 on a modern x86 system: https://www.youtube.com/watch?v=uE6qp94InBM. So I got the same Gigabyte mainboard and was able to recreate the setup: Both Rhapsody and also OPENSTEP run really well (NeXTSTEP probably too, but I haven't tried yet). Installation on this board works, because it can not only emulate SATA drives as IDE, but also in a way that NeXTSTEP/OPENSTEP/Rhapsody require, IRQ 14 for the primary IDE/ATA controller ("legacy IDE emulation").

However, I didn't have a compatible network card, so I bought a cheap RTL8139 network card (they're around ~$10) and wrote a new driver for it, taking inspiration from the Linux driver (github.com/torvalds/linux/blob/master/drivers/net/ethernet/realtek/8139too.c) and Apple's driver (https://github.com/apple-oss-distributions/AppleRTL8139Ethernet). However, I was stuck for a while: I kept getting only about 2 MB/s (!), no matter what optimizations I tried. After a week of debugging I finally realized that it wasn't the driver or the network card that was the bottleneck - it was the disk!

It turns out that the generic EIDE drivers that ship in OPENSTEP (and I think also in Rhapsody), e.g. "Primary/Secondary (Dual) EIDE/ATAPI Device Controller", only support slow PIO modes (see https://www.idc-online.com/technical_references/pdfs/data_communications/Ata_Ide_And_Eide.pdf). Only the PIIX driver ("Intel PIIX PCI EIDE/ATAPI Device Controller") supports fast transfers via (bus-master) DMA! So BTW, if you are running OPENSTEP/Rhapsody in a VM, make sure to replace the Primary/Secondary driver with the PIIX driver after installation, and tick "Bus Master DMA".

Only some old mainboards have a PIIX chip, so I couldn't use the PIIX driver on the modern mainboard. I then realized that the modern mainboard doesn't just support legacy IDE emulation, but it also supports bus-master DMA!

So I investigated how to get bus-master DMA support added to the EIDE driver. Though we don't have the original sources of the OPENSTEP EIDE driver, I found newer sources in the Darwin 0.3 open source SDK (https://github.com/evolver56k/Darwin-0.3/tree/master/drvEIDE-1/EIDE.drvproj). While they unfortunately didn't build on OPENSTEP, the PIIX sources showed how to implement bus master DMA (which isn't PIIX-specific). With the help of https://wiki.osdev.org/PCI_IDE_Controller and https://web.archive.org/web/20230225074319/http://www.bswd.com/pciide.pdf I then wrote a new EIDE driver. I've been running it for a while and haven't had any problems yet. I'm using one of those cheap "M.2 SSD SATA Adapter 2 in 1 16GB" (they're around ~25$) and everything is very snappy :-)

QuoteI should note that the drivers might work just fine on NS3.3, since OS4.2's dev environment literally can't produce drivers; NeXT continued using (and recommending) 3.3 systems for this purpose until x86 was deprecated in OS X Server 1.0. I suppose Turbolent might have used the 3.3 dev environment installed on 4.2, though, in which case actual usage on 3.3 would be untested...

Yes, the drivers might also work on NeXTSTEP, I just haven't tested that yet. I'll try to set up NeXTSTEP on the machine I got and see if the drivers and the package manager work there, too.

I also read somewhere that OPENSTEP supposedly can't produce drivers - but found it not to be true: I have an OPENSTEP 4.2 system with Developer Tools and Patch 4 installed, and that's all that is needed to build the two drivers.

@turbolent thanks for all your hard work here. this is amazing! I haven't tried building my own white hardware, but I did invest some time into getting the experience to be good in VirtualBox. I added widescreen resolutions to the VirtualBox VGA driver.

The main thing that is pretty bad in VirtualBox is the mouse driver situation. VirtualBox just does not do a good job emulating a PS2 mouse at this point (especially when running in retina resolution on a Mac). So I wanted to see if I could use the VMWare OpenStep driver to work on VirtualBox so we would have per pixel point precision, but I didn't get very far. Now granted this was before Vibe Coding AI... so I should probably give it another try.

But anyway, your recent work is a huge inspiration! Keep it up!

You should definitely give it another try! AI assistance has been a game changer, without it, none of this would be possible (it would probably take me years, given these are just side projects).

For both drivers I first used 86Box (but VirtualBox or VMWare should work the same) and a Telnet MCP server (https://github.com/turbolent/telnet-mcp), with a raw disk image. The AI can run commands in the VM and transfer files with FTP (both telnet and FTP servers are set up by default already). Then once the new driver code is copied over and built and the new driver installed (small script helps), cycle and try it out.

Then once the driver is working in the VM, I used dd and a cheap SATA to USB adapter to transfer that same raw disk image, and booted it up on the real hardware. Took me a few hundred tries, but persistence is key :-D

At some point I considered automating it more, but didn't end up having the time.

One thing I wanted to have, but I couldn't figure out, and don't even know if possible: Get boot logs on serial output. If anyone has any hints on how this could be done, please let me know.

Quote from: turbolent on May 24, 2026, 10:56 PM

QuoteTo get things out of the way—pTek will be disappointed to learn that all of this is for OPENSTEP 4.2 only and will not work on NEXTSTEP 3.3. Sorry, buddy.

As for compatibility with other operating system versions: My main system is OPENSTEP and so far I have only focused on that. These packages might also work on Rhapsody and even NeXTSTEP, I just simply haven't tried yet. Feedback (and patches) are very welcome!

  The RTL drive compiled straight away with NS3.3, the EIDE driver I had to use #ifdef  DRIVERKIT_VERSION_330 around the __private_extern__ calls around your code to get it compiled. I still have to try the EIDE driver.

Quote from: turbolent on May 24, 2026, 10:56 PM

QuoteLooking through Turbolent's other repos, I noticed two drivers, both of which are quite young:

Driver for Bus Master IDE: https://github.com/turbolent/BusMasterIDE (3 weeks ago)
Driver for RTL8139 ethernet devices: https://github.com/turbolent/RTL8139 (2 weeks ago!)

Regarding the drivers:

I recently came across Omores' video on how to run Rhapsody DR2 on a modern x86 system: https://www.youtube.com/watch?v=uE6qp94InBM. So I got the same Gigabyte mainboard and was able to recreate the setup: Both Rhapsody and also OPENSTEP run really well (NeXTSTEP probably too, but I haven't tried yet). Installation on this board works, because it can not only emulate SATA drives as IDE, but also in a way that NeXTSTEP/OPENSTEP/Rhapsody require, IRQ 14 for the primary IDE/ATA controller ("legacy IDE emulation").

It turns out that the generic EIDE drivers that ship in OPENSTEP (and I think also in Rhapsody), e.g. "Primary/Secondary (Dual) EIDE/ATAPI Device Controller", only support slow PIO modes (see https://www.idc-online.com/technical_references/pdfs/data_communications/Ata_Ide_And_Eide.pdf). Only the PIIX driver ("Intel PIIX PCI EIDE/ATAPI Device Controller") supports fast transfers via (bus-master) DMA! So BTW, if you are running OPENSTEP/Rhapsody in a VM, make sure to replace the Primary/Secondary driver with the PIIX driver after installation, and tick "Bus Master DMA".

Only some old mainboards have a PIIX chip, so I couldn't use the PIIX driver on the modern mainboard. I then realized that the modern mainboard doesn't just support legacy IDE emulation, but it also supports bus-master DMA!

So I investigated how to get bus-master DMA support added to the EIDE driver. Though we don't have the original sources of the OPENSTEP EIDE driver, I found newer sources in the Darwin 0.3 open source SDK (https://github.com/evolver56k/Darwin-0.3/tree/master/drvEIDE-1/EIDE.drvproj). While they unfortunately didn't build on OPENSTEP, the PIIX sources showed how to implement bus master DMA (which isn't PIIX-specific). With the help of https://wiki.osdev.org/PCI_IDE_Controller and https://web.archive.org/web/20230225074319/http://www.bswd.com/pciide.pdf (https://web.archive.org/web/20230225074319/http://www.bswd.com/pciide.pdf) I then wrote a new EIDE driver. I've been running it for a while and haven't had any problems yet. I'm using one of those cheap "M.2 SSD SATA Adapter 2 in 1 16GB" (they're around ~25$) and everything is very snappy :-)

  I think the NeXT EIDE drivers only went up to ATA-2 standard (Or was it ATAPI-2 standard?) because that is when it started to get the HDD information from the HDD instead of the BIOS. Don't forget to use the idemodes program that is supplied with the Darwin 0.3 EIDE driver. By editing it can read and display the correct LBA and sectors for over 8GB.

  I'm glad you managed to make a compilable as I was not looking forward to starting from stretch and copying and posting code from the drv-EIDE as I can play with your one instead.

Quote from: turbolent on May 24, 2026, 10:56 PM

QuoteI should note that the drivers might work just fine on NS3.3, since OS4.2's dev environment literally can't produce drivers; NeXT continued using (and recommending) 3.3 systems for this purpose until x86 was deprecated in OS X Server 1.0. I suppose Turbolent might have used the 3.3 dev environment installed on 4.2, though, in which case actual usage on 3.3 would be untested...

Yes, the drivers might also work on NeXTSTEP, I just haven't tested that yet. I'll try to set up NeXTSTEP on the machine I got and see if the drivers and the package manager work there, too.

I also read somewhere that OPENSTEP supposedly can't produce drivers - but found it not to be true: I have an OPENSTEP 4.2 system with Developer Tools and Patch 4 installed, and that's all that is needed to build the two drivers.

This was because it was difficult to compile the example drivers with Project Builder on OS4.2. If you did not convert the driver with Project Builder and just copied them to a local folder and used gnumake in the terminal then the driver would compile.