Started by gsyoungblood, October 18, 2006, 10:04:35 PM
Quote from: "gsyoungblood"I'm pretty surprised how close you say they are.If the difference between NS and OS are that great, but from OS to MacOSX are not as great, then perhaps that's the starting point. Get OS gui, etc. working on top of Darwin (open source) first. Once that's done, try to add NS support second.At the very least, it would open up new hardware options to keep OS running longer, whether on power pc or intel.
Quote from: "gsyoungblood"I'm pretty surprised how close you say they are.
QuoteIf the difference between NS and OS are that great, but from OS to MacOSX are not as great, then perhaps that's the starting point. Get OS gui, etc. working on top of Darwin (open source) first. Once that's done, try to add NS support second.
QuoteAt the very least, it would open up new hardware options to keep OS running longer, whether on power pc or intel.
Quote from: cuby on October 19, 2006, 02:05:07 AMOne still more interesting thing would be possible: creating a wrapper that runs OpenStep binaries on OS X/x86 and translates system and library/framework calls to their OS X equivalents or reimplements them. I'm actually working on this in my spare time.One problem is supporting NS as well as OS binaries, since the mechanisms for loading shared libraries have changed between NS and OS. Another is decoding and converting the nib files, since this format has changed significantly (there are still more problems around, but these are two of the most obvious).But running FrameMaker and similar NeXT software on OS X would be great. Actually, I have some m68k NeXT command line binaries running in emulation (CPU emulation combined with system call translation) on Linux and OS X at the moment, but this is highly experimental.
Quote from: pTeK on June 21, 2023, 05:13:39 PMHow is this coming along?
QuoteWould it be possible to convert 68K to x86 assembler and redirect the system calls to the NeXTSTEP x86?
Quote from: spitfire on June 23, 2023, 09:59:53 PMAs you mentioned NS was statically linked, whereas OS was dynamically linked. Given all the apps people care about are NS, that would make sense as the target. Do we restart work getting command line apps going again?
Quote from: gtnicol on June 24, 2023, 12:53:41 PMThat seems like a fruitful path. It would be interesting to see how much it'd take to get graphic apps running. I'd expect display postscript to be needed.
Quote from: cuby on June 24, 2023, 04:03:27 PMFor graphic apps, we need support for emulating Mach ports, as there is communication between the AppKit and WindowServer (and more) going on. Some details can probably be extracted from the NetBSD compat_darwin( code - they tried to get OS X 10.2 WindowServer to work (on a PPC NetBSD machine, no binary translation involved).
Quote from: cuby on June 24, 2023, 04:03:27 PMAFAIK, most of the communication between AppKit and WindowServer is not documented. But I would love to hear everyone's opinion on the right way to approach m68k NeXT user mode emulation...Update: I remember I read somewhere that the 1.0 protocol was documented in a file "WindowServerProtocol.wn", see this old usenet posting.Does anyone have a copy of that file?
Quote from: spitfire on June 24, 2023, 05:16:59 PMI can do you one better. We have the source code for the display postscript server. In the NeXT source coe thread there's a link to NeXTDPS repo, that's it. I'm not sure if GNUStep or OSX are the right path to go down. GNUStep emulates the openstep API so might be a little closer (has postscript, etc), but OSX will have mach binary support and tooling around m68K still somewhat intact. I have to admit I'd get a thrill running framemaker and quantrix/improv on OSX. I've been missing those things for *ages*.
Quote from: gtnicol on June 24, 2023, 05:45:27 PMI'll look for the WindowServerProtocol.wn file - I probably have it here somewhere. The Dimension uses similar messages from memory.