I'm currently analyzing the OPENSTEP kernel.

[onionmixer]

https://github.com/onionmixer/openstep-kernel-remade


Right now, I've only done a minimal analysis of OPENSTEP 4.2 across Intel, m68k, and sparc. It probably won't move forward very quickly... but my ultimate goal is to implement the OPENSTEP 4.2 kernel in C/Obj-C, fix a few limitations within the kernel, and secure a more complete kernel source code.

By cross-referencing Mach 2.0, open-source Mach 4, and XNU version 0.1, I plan to first reproduce a kernel that closely matches OPENSTEP 4.2's behavior, and then tackle fixing any kernel issues afterwards.

To make this work possible, I've brought qemu-NeXT up to a fairly complete, working state. Analyzing QEMU HDD images is no longer a barrier for AI... and as long as I don't give up on this project, I believe I can obtain usable kernel sources for all three platforms.

I do worry about how publishing an unfinished project might look to folks in the community—like it lacks credibility or commitment. However, after trying out various miscellaneous OPENSTEP-related tasks with AI, I am confident that with enough time invested, it's entirely feasible.

The main reason I'm sharing work-in-progress stuff like this anyway is because, in the AI era, duplicating similar efforts might just be a waste of time. If there's already a project out there that's further along than mine, I'll gladly stop and contribute my efforts to that project instead.

I realize there are people who view AI negatively. Still, I have this vague hope that this will ultimately end up helping someone out. I'm crossing my fingers that I can successfully wrap up this project too

[ZombiePhysicist]

That's great. Every bit of effort teaches all of us something. It's super cool you're sharing your progress!

[Rhetorica]

We actually have a source tree for an earlier version of NEXTSTEP (3.x). It is mostly complete, though there are some files that got damaged or lost during archival due to filename truncation. This includes kernel source. For various reasons it cannot be distributed publicly.

Once you get to the validation stage, I can send you a copy of these kernel files for further comparison. I expect that many of the differences between 4.2 and Darwin 0.1 will have attestations in the 3.x source.

Please keep us updated on your progress! This is really cool!

[onionmixer]

We actually have a source tree for an earlier version of NEXTSTEP (3.x). It is mostly complete, though there are some files that got damaged or lost during archival due to filename truncation. This includes kernel source. For various reasons it cannot be distributed publicly.

Once you get to the validation stage, I can send you a copy of these kernel files for further comparison. I expect that many of the differences between 4.2 and Darwin 0.1 will have attestations in the 3.x source.

Please keep us updated on your progress! This is really cool!

Ooh... now that's some interesting news. I'll give it a solid shot. I completely understand for whatever reason

As a side note... while writing VGA drivers (Matrox previously, and now Radeon), I've gotten a rough idea of how VRAM and window managers work under the hood. To be honest... what I'd love to try next is something like reading the window manager's draw buffer and handling it remotely—maybe building something that handles the RDP protocol instead of VNC? I've been kicking that idea around a bit.... Though honestly... I'm still not entirely sure yet

[onionmixer]

That's great. Every bit of effort teaches all of us something. It's super cool you're sharing your progress!

Don't mention it... the project will only truly matter if I can see it through to the end. Even if it takes a while, I'll keep pushing through

[ptek]

When I was trying to find the VESA VBE code in the OS4.2 patched kernel the Darwin 0.3 kernel sources helped me a lot.

[itomato]

When I was trying to find the VESA VBE code in the OS4.2 patched kernel the Darwin 0.3 kernel sources helped me a lot.

The GhidraMCP is a hoot also.

[onionmixer]

The GhidraMCP is a hoot also.

I'm using Ghidra and IDA with MCP for my work (I'm using these for driver development and game engine development too). And since IDA has limitations with m68k and sparc, I'm using Ghidra as an IDA plugin (which is another separate project by itself).

Where there's a will, there's a way, right? I still have a long way to go, though, haha.

[onionmixer]

When I was trying to find the VESA VBE code in the OS4.2 patched kernel the Darwin 0.3 kernel sources helped me a lot.

I'm asking because I'm not entirely sure... are XNU and Darwin very different?

[ptek]

When I was trying to find the VESA VBE code in the OS4.2 patched kernel the Darwin 0.3 kernel sources helped me a lot.

I'm asking because I'm not entirely sure... are XNU and Darwin very different?

I don't know. I just used Darwin 0.3 as that was the only source I had access to and it was better than nothing. Also found that Darwin provide the source to otool which supported m68k, i386, hppa, sparc and ppc. I can't remember if fdisk, mkfs and disk were updated.

[onionmixer]

I don't know. I just used Darwin 0.3 as that was the only source I had access to and it was better than nothing. Also found that Darwin provide the source to otool which supported m68k, i386, hppa, sparc and ppc. I can't remember if fdisk, mkfs and disk were updated.

Oh!!! That is genuinely great information... It'll be super helpful as a reference for my upcoming work. Thank you so much for sharing!