BeOS PowerPC: a sad tale of Apple hardware

The next struggle is making a new install as the R5 install I have is messed up. The CD drive is very unhappy and won’t read or boot from the R5 install CD (it’s an original) and even installing GoBe Productive from the CD was a bit fraught (the installer seems a bit corrupt, but did install something that seems to more or less work.)

I’ve extracted the R5 PPC image from an ISO I found online. This was using ISOBuster. I’m hoping it will mount or maybe I can write it to a partition. I did get a burned copy to mount once, but I then decided to try to boot from it and it never mounted again. The drive can read the ISO9660 part, but the raw BFS images are blowing its mind. Weirdly my R4.5 CD (also original) mounts and I can see the BFS images. I guess something is different about the R5 version?!

I’ll let you know how it goes after I’ve FTP’d it on to the Mac.

EDIT: so, ISOBuster managed to pulloff the data, but the nly way I could get it to mount was to use the “convert to user data to iso”. That mounted in BeOS PowerPC and I could get at the files.

1 Like

So, on a mission to get more stuff ported to PowerPC, I found my copy of CodeWarrior for Windows. It has a PowerPC compiler and linker and in the past I’ve used it to build simple BeOS PowerPC apps. My plan is to see if I can get some simple command like apps compiled. (I do have the Mac version, but I think I don’t have a Mac that would run it - well maybe an old G3 Wallstreet Powerbook, but that runs at best Panther through XPostFacto.) I really want to get VSCode working as I did a bunch of cross compilation for the PSP using it recently and it is easy to set up with a new tool chain.

I need to see if I can get Git or something like that working to do source control. Or it’s CVS at best… no one deserves to have to use CVS…

Slightly off-topic, but related to PPC. This guy found and fixed a long standing Ram bug in Sheepshaver. I haven’t dusted off my BeOS modded PPC to test it yet.

1 Like

Nice! My Mac only has 120MB RAM so I feel like this isn’t going to hit me… good to know though.

So - I manages to get a newer version of CodeWarrior under MacOS X (10.2.8, yes, shudder!) to compile a BeOS basic app. It is mainly about configuring the project “stationary” settings and copying the right headers and libs from BeOS.

I don’t yet know if it runs… but I do remember doing this before and it working.

signal-2021-05-19-091358

CodeWarrior is almost identical to BeIDE in many of the ways it does stuff, so that is a bonus!

Plan is to use this setup to bootstrap some code that is otherwise quite hard to compile, given the BeOS version of mwcc stopped being updated a decent while before this version of CodeWarrior.

Oh… and the warnings we get even on BeOS. So yeah, it looks like it works tome so far.

Yesterday I managed to test the exe being built…

IMG_1341

And, yes - it works. Not too much of a surprise, I had this working before in the 2000’s. But great to see again.

Next I tries something a little more taxing. I took the “HelloWorld” source code from the R5 examples (it is in the “Intro” directory in the samples) and built and ran it under BeOS:
signal-2021-05-19-232837

signal-2021-05-19-232918

Zipping that up and moving it to the Mac, I started a new BeOS project (yes, I got the template to work, so I can now create a new project easily.) I then added the source code:

signal-2021-05-19-232814

Anyone who knows BeIDE will see that looks a lot like a PowerPC BeIDE project :wink: Well, long story short - it compiled. So I copied it back to BeOS and, yep - it also runs!

signal-2021-05-19-232931

The main issue is that it seems like the tool that deals with BeOS resource files is Be specific, and so I need to probably run a script on BeOS to add the resource file to the app for now. But other than that - it works!

7 Likes

When I investigated PPC BeOS I found that it use Preferred Executable Format (Joy!peff, documentation). I have not yet added support for it in my PE Decoder project, but I already have NE (Win16) and LE (VxD, OS/2), PE, ELF formats support.

Is it possible to produce PEF by some modern compiler or at least compiler that can run on Haiku/Linux/Windows?

Would also be my choice. But as far as I know, GCC does not support PEF. macOS (PPC) can only load PEF executables (it is also used by System 9 a.k.a. Classic macOS). I am unsure if Xcode can create PEF for Carbon applications.

Well, I don’t remember trying it, but there is a version of the Metrowerks compilers that ran on R5 X86 BeOS, and I guess should therefore run on 32bit Haiku. I believe you can get the from here: http://bebits.irixnet.org/beos/experimental/tools/develop_ppc_x86.zip (no, not this one) or http://bebits.irixnet.org/beos/experimental/tools/develop_x86_ppc.zip (this one). I forget which one is which… one should be ggc IA232 cross compiler for PowerPC, the other is a mwcc (and tools) PowerPC cross compiler for IA32. The names are not very helpful. But the one that contains mwcc, mwld etc is the one you want to try.

If you just want a general compiler than makes PEF, there is also Retro68. It can be configured to produce PEF executables for PowerPC. But it needs to be ported to build BeOS exes, and it seems like a bit of a hack and I doubt the C++ name mangling it produces will be compatible with BeOS/mwcc.

There are also command line tools for Windows. You will need to acquire a version of Metrowerks Codewarrior that runs on Windows, but I believe there might be a version on the Wayback machine archive. The Metrowerks tools are probably quite antiquated now. You need to make sure the version you install supports at least Carbon to get PEF, as the later versions only supported Mach-o. I think the version I have is version 6, but I think 8 or 9 had it them too.

I think the simplest would be the original dross compiler though, and I don’t see why it would not work under Haiku 32bit.

Edit: having downloaded the zip, (develop_x86_ppc.zip), looks like it has the compiler, linker and associated BeOS libs and headers. It also has the disassembler. It doesn’t have pefdump though, but if you look at the Retro68 project, he has a few extra PEF tools.

Edit2: The one weird thing about the MetroWerks compiler for BeOS is that all the static libs are in a MetroWerks specific format. It is based on their object file format. If you can find a copy of BeIDE, in the docs folder, the binary format is described quite well. If you do look at the PEF format, adding MW Object format would also be cool. I started writing a decompiler ages ago in C#, and started looking at it again but this time in C. https://github.com/memsom/mwobdec - I can send you the docs if you want them and can’t get access.

I have a feeling that the stuff under Project Builder/XCode was a different format. I also don’t think there was ever an X86 version of XCode that made apps that targeted Classic. I can take a look at PowerPC. I have Project Builder installed under Jaguar.

Edit: Okay, I checked… apparently Project Builder builds Mach-o exes and I guess, there is a loader somewhere in MacOS 9.22 (maybe earlier) that can load them. PEFViewer under Jag can’t open the app I just made in Project Builder (it says the “Magic Cookie” is wrong, I assume the magic word in the header) and mwdis seems to only work with Mach-o and complains that the header on a PEF exe is not a Mach-o header…

I confirmed that it is running on Haiku and produce object files. Complete binary compilation fails because of missing symbols, I haven’t looked at details. Maybe can be used to compile Haiku system libraries for PPC.

UPDATE: I managed to compile minimal GUI application for BeOS PPC.

Yeah, you need 3 extra object files (glue-noinit.a, start_dyn.o and term_init_dyn.o), which I guess you found. They define 3 symbols the linker needs, __start, and I forget the other two, but it is an init and deinit routine. There are always 2 warnings about redefining symbols in libbe.so.

Great you got it compiling :slight_smile:

I started writing decoder of PEF executable format. It seems to use same C++ mangling as GCC2.

screenshot61

7 Likes

That’s amazing work! How would I get a copy of the code once you have made more progress? Is it on github?

The name mangling makes some sense. I don’t know if it was a MetroWerks thing or not, but as the compiler from MacOS will build BeOS executables with C++ that run, I am guessing the MW compiler in general implements the same scheme. It might be an Apple thing, because the Mac targets use the Apple Universal Headers. Though, I don’t know how much C++ was in those.

I progressed a bit more: I implemented relocation decoder, data section unpacker and initial PowerPC disassembler. BlackBox is needed to run, currently run only on 32 bit x86. It may be difficult to run program if not familiar with Oberon systems. Project PE Decoder is located on GitHub. I have not uploaded WorkPefDecoder and WorkDecPPC yet.

Do you have idea how R2 register is initalized? Always set to beginning of section 1? This don’t work for libtracker.so, PLT entries (or how it is usually called in PEF) have negative offsets to R2.

screenshot62
screenshot63

3 Likes

No, I don’t know much about the PEF format myself. I was mainly looking at making the MW Object Format decompiler, with an idea to make tools that can generate valid object files that mwld can link. I originally wanted to get VASM generating raw machine code blocks that I could plumb in to an object file. I do know that although the BeOS shared objects are PEF, The PEF tools under OS X really do not like them and the PEF Viewer crashed opening them. It can open the app I build under OS X. I haven’t tried any of the BeOS exes. It might be the fact that they are Shared Objects rather than exe files?

I did Delphi for 10+ years and some ADA 83 at University in the 90’s, so BlackBox and Oberon are not a complete mystery, But my Delphi is quite a long time out of use now.

The other thing I was going to say - the mwcc and mwld are identical in most ways to the MacOS versions… it could be that this is something Mac specific that BeOS does too by convention. If so you might more info from the Classic Mac documents. By implementing PEF you are getting Classic Mac PowerPC executable files for “free” too… though, the Mac HFS file system is funky and I don’t know if moving a Mac exe to non HFS will destroy the resource/data forks beyond usability.

I don’t see differences except NULL entry point for .so files. But I looked only BeOS PEF files. PEF has 3 entry points: main, init, term.

Yes. I think the Mac only uses main. I can get you a simple Mac exe quite easily, but I don’t know what will happen with the resource/data forks on a non HFS file system.

You may find cfmtool.py useful, it extracts various data from PEF file (section data, import/export symbol list etc.).

The main issue will be that my PowerBook is running 10.2.8, and my only other MacOS X install is a MacBook Pro with the new apple file system… I don’t know if that handles old Mac files. I doubt python 3 will run under Jaguar.