Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Jubadub]

No idea if anyone would care for any of this, but I'm currently on a phase of just randomnly grabbing various Mac projects and trying to compile them until I pull it off, in particular for software that has source code available, but no distributed binaries.

Think of it as "binge watching" something, but instead you just compile, compile, compile.

First one was SDL 1.2.15. The latest officially-distributed binaries were for 1.2.13 instead of .15, but Mac OS is still listed as supported etc., and changes between those versions were apparently also minimal. Nonetheless, I wanted the final version of SDL 1.2 (and 1.x overall) to be easily available as a binary for any Mac user / developer.

SDL 2.0 drops support for the vast majority of previously-supported platforms, even PPC OS X (although they say, for early 2.x versions, PPC OS X could probably be viably patched back in), so I decided not to even bother with it for now. SDL 1.2.15 should be sufficient for anything one could want to be done when compared against SDL 2.0, so I find little incentive in even considering that for porting/compilation.

Following official build instructions (you can find a link to them from the Garden page for SDL 1.2.13), it turns out they were insufficient and out-of-date. It needed 3 extra steps to complete a build via MPW: 1. Copying some OpenGL SDK headers and putting them next to other SDL source files, 2. copying some OpenGL SDK binary into some Interfaces folder of the used MPW installation and 3. changing the creator/type code of one particular file that had lost its resource forks to "TEXT" type. I plan to put the detailed, exact build instructions in the SDL 1.2.13 Garden page (and rename that page to SDL 1.2.x).

Next, I compiled Mini vMac 3.5.8 for non-Carbon PPC Mac, as well as even 68k. Both run on OS 9. Trying to type in ":minivmac" as the name of my build target on MPW, at first, did NOT work for compiling things (no idea why), which sent me on a looooong ride in trying to figure out why that wasn't working, and made me dig up the entire Gryphel website for whatever nuanced I might have missed from the docs (spoiler: none). Eventually, though, I realized I just needed to stick with the ":minivmac" name without changing anything else, and that's it. Next, I will try building with more compiler flags, then trying compiling the latest 2 versions of Mini vMac (36 and 37). Then upload it to everyone else interested, since the Gryphel website LONG stopped providing the "build service" for generating Mac-OS-9-compatible versions for NO reason, and even did away with older binaries and with documentation useful for previous versions (thank goodness archive.org came to the rescue for the docs at least, although not for many of the binaries). Geez.

I also revisited Bochs, the legendary PC virtual machine program, but after much poking around, it was clear to me that the path forward with it is to craft our own CW project files from scratch (or makefiles for MPW), and only use the extremely-outdated included CW project file as a partial guiding reference. Otherwise, compiling Bochs won't work. (The accompanying disk image creation tool, bxImage, compiles as a separate project just fine, though.)
I decided to look into Bochs only after I'm done compiling everything else I want to see compiled, for the time being.

Finally, there's MacZip. In MacZip's case, I'd like to compile it myself so that I can tinker with its source code, and see if I can use it to further develop it. Ambitious plan for my knowledge set, but hopefully I can get somewhere with this, very slowly.

I will share the SDL and Mini vMac binaries here later on in this thread. Running out of time right now.

Everyone else please feel free to hijack this thread with your own compiling, porting or even hacking attempts over any kind of Mac software (preferably real Mac OS, not OS X), and share your results away. Maybe someone else gets also in the mood of "binge compiling", or "binge porting". That could be fun.

[Jubadub]

SDL 1.2.15 attached here.

Note that the file's "Version" property is still set with a value of "1.2.13", instead of the actual version number (1.2.15). It would seem the SDL team simply did not bother to bump up, or overlooked bumping up, the version number string.

You can still tell it's a different binary from file size alone: when I compiled 1.2.13, I got about (or exactly?) the same size as the official binary, but for 1.2.15 it's a bit bigger.

By the way, checksums don't seem to always match each time I build, so it doesn't seem they can be relied upon here. Perhaps building it is including some timestamp of when the build took place, thus changing the checksum sometimes?

I doubt anyone will actually use this, but of course, I cannot guarantee my build is actually good, and it is not tested, so use it at your own risk blah blah blah

[Jubadub]

In case anyone wants to try compiling Mini vMac 3.4.1 (latest functional/stable Mac OS version) or 3.5.8, I made a single GIF to show anyone can do it. You don't need to know anything about programming at all. It's a bunch of very easy, simple drag'n'drop procedures, and a single Copy+Paste.

With this, you can configure Mini vMac to work with whatever configuration you set it to. This page has the source code of all the versions we could find, and can guide you overall.

This is great for running B&W Mac software that is "too old" to run directly in Mac OS 9. Or to run some things in B&W if you want to.

[Matej]

SDL is indeed easy to compile, but by default it's not fully optimized, as I noted here: http://matejhorvat.si/en/mac/mpw/
Whether it actually makes a difference or not, I can't tell.

[Jubadub]

@Matej That's a very nice page to help compile things for Mac OS, thank you! I had no idea about the optimization flag for SDL, that's good to know about. It also gives some encouragement to get more familiar with developing on MPW directly.

[Jubadub]

So... did anyone take a jab at compiling MacZip?

I'm trying the full 1.06 (beta 1?) source, and I find it quite a mess... The official website states CodeWarrior Pro 5 was used to compile, so I went with that... However, the main project could not find some of the other project files during compilation, and it fails.

Admitedly, I only spent some minutes with this attempt. But before I got into this rabbit hole, I decided to ask here if anyone already poked at or is willing to poke at it, as well.

I might just be better off starting with a blank project, and learning how to ZIP/UNZIP in a very basic fashion from scratch, though... Because it seems I'm too green for MacZip right now, and I could use some learning by trying to do it myself. But someone with more experience might fare better at compiling this. Any takers?

[cluster_fsck]

Wow, I thought I was the only one who did this type of thing

Last year, I did dive into the MacZIP with a goal of modernizing it (basically, upgrading it to use Navigation Services, a more modern UI, and a couple of optimizations to improve speed with larger files) but I was also an idiot and lost it when the SD card in my BlueSCSI freaked out. That said, I do want to get back to that one.

The other app I’ve been able to work on locally is `ssheven`, a SSH client for Mac OS 7/8/9. I had to compile some of the dependencies using Retro68 and then move it all over to my PowerMac running CodeWarrior.

I need to spend some time getting an old school CVS server running my Raspberry PI that’s hosting my AppleShare server so I can more easily check code in and out and have a local backup.

[sentient06]

I'd be very interested in getting ZLib compiled and perhaps set up as a static library. Do you think you can do it? 

https://www.zlib.net/

(Also, if you could do that on Retro68, even better!)

[cluster_fsck]

Why as a static lib? To embed in an app versus calling dynamically through a Shared Library?

[sentient06]

Why as a static lib? To embed in an app versus calling dynamically through a Shared Library?

Exactly!

Of course, if you figure out the funky bits one has to change to make it compile, I suppose the generation of a shared lib and a static lib would be pretty similar anyway.

[Jubadub]

I'd be very interested in getting ZLib compiled and perhaps set up as a static library. Do you think you can do it? 

https://www.zlib.net/

(Also, if you could do that on Retro68, even better!)

Thoughts on 7-Zip / LZMA2 over ZLib?

Btw, static libraries perform better and are faster than shared/dynamic ones AFAIK, so I second the motion. In fact IIRC the famous LibMoto Math lib from Motorola for Macs in the '90s were officially distributed both ways, but stated to be faster in static library form inherently. Makes sense when you think about it.

[cluster_fsck]

I don't know if a static lib would necessary execute code any faster than a shared lib, but I can see scenarios where loading the code from a shared lib is definitely slower. Might execute slower if it's a large shared library and the code can't all fit in memory or something.

[laulandn]

Technically, at a very low level, they will always be "slower", especially on older operating systems which weren't designed from the start to support them, or where the implementation is a bit of kludge.  It is, however, debatable if the difference is actually human perceptible.

The reason is, with static linking, the calls to the functions in the lib are the same (or very very similar) to calls to the functions in the main code itself.  Just for a start they can use shorter/faster jump instructions.  With a shared library, there is likely at least one jump table, could be more than one, context and stack changes, and maybe even more going on behind the scenes.  i.e. static can be a "local call", where shared can be a "far call".

Again, whether this is even noticeable depends highly on the code, and how often it is called.

Personally, even on modern Linux, in my code I prefer doing things static where I can, just for simplicity of linking, and having the entire program all in one file.  But then that particular binary is stuck with whatever version you hard coded into it, and doesn't take advantage if a user has a newer version, etc etc.  So there are always good reasons to do shared.