GNUstep compatibility with macOS Catalina almost complete | Hacker News Reader

GNUstep compatibility with macOS Catalina almost complete

heronsperch.blogspot.com

169 pointspabs362 comments

My only experience with GNUStep is that 10 years ago, as a student, I needed to port a random CLI Cocoa app (that a different student wrote to learn Cocoa) to GNUStep.

There was a weird bug that took me forever to debug… and in the end, it was caused by some horrible bug in some map structure (NSDictionary? I think?) where a NSString unicode key did not map to the same value every time. Quite basic stuff. (It worked fine on Mac.)

As a student I didn’t really know how to report bugs, so I didn’t; I just wondered how did nobody catch it until now; but I just thought that probably nobody really uses GNUStep so that’s why.

It’s just anecdotal and I don’t really have access to the code anymore so I cannot tell you the details. (the original code was far from perfect too, maybe it was some unicode weirdness.)

This is my experience using open source in general, as a developer (who mostly uses open source).

Go to GitHub and file a reproducible issue. In this case it might be “here’s a shell loop that runs a test 10 times. On my system it fails about 40 perfect of the time”

Not complaining about moderation but I do wonder why someone would disagree with the advice above.

That’s concerningly bad luck, or an exaggeration. The entire Internet, hell, technology as we know it, operates on the premise that a bunch of open source code works ‘pretty well’.

It does work "pretty well" after you discover all of the quirks thorugh trial and error and then work around them :)

Can you list some references to bad software you are using perhaps? Someone else who also uses open source software might be able to suggest a different tool or fix you may of not known about.

Every software will be bad software if you use it often enough to the point you step into some specific usage that developer and tester never imagine about.

The point isn't whether it is good or bad. The point is nobody use it like that thus nobody knows it would break.

The good thing about open source software in general is: if you complain and give a detailed procedure of how it happens, there is much higher chance somebody might looks into it (or yourself if you will). Closed source software in the other end: good luck, find a workaround if you hope or just stuck with it.

That's why I'm asking what I'm asking, but Open Source is also not guaranteed to be funded.

Plenty of funded proprietary closed-source software are plagued with bugs too

The keyword here is 'much higher'. It is of course not guaranteed. As a developer, if somebody already done the trouble shooting or even root cause finding for you. You are more likely to fix the bug first because it will only cost you a little time compares to other completely non-investigated error report. And that also benefit the users because they got the bug affecting them fixed earlier. This don't happen in closed source softwares.

My personal experience mirrors yours. I remember when Swift announcement from Apple came that the main author of GNUStep (sorry I forgot the name) announced an open source impl the same day. My thoughts back then: „maybe make the last effort actually usable before jumping to the next big project“.

But I don‘t want to downplay the work and time put into this project. I would simply not use it in any project because of the number of compatibility bugs that haunts the project.

I used the project in production via Apportable’s crosscompile solution to port iOS native apps to android.

…didn’t really know how to report bugs, so I didn’t; I just wondered how did nobody catch it until now

Basically, that’s how.

You made think about digging old hard drives and trying to figure out where are all the files from 2013 again… I think I could find the actual underlying issue much faster now.

But, is it really worth the time?

Yes! It is worth it - please do :)

I wonder if GNUstep is going to follow in Apple's backwards compatibility breakage or they'll try and keep existing programs working.

Free Pascal and Lazarus devs also implement a language and API originally defined by some big company in the past and in general try to implement the new stuff Delphi adds, but they also try to avoid breaking existing code. In Free Pascal this is done by using compiler directives in the source code to opt-in for the Delphi stuff whereas in Lazarus they only implement things that do not break existing code - either way you can have code that works with both Delphi and FPC since they're 90% compatible but you need to use IFDEFs for that that last 10%.

Even though i'm using Window Maker and thus GNUstep apps would feel right at home (for the most part), i haven't actually bothered to look into it because Apple has a bad history with breaking existing applications (i got an iMac in 2009 and pretty much every single Mac OS X / macOS update broke some application that previously worked fine - until macOS itself stopped supporting my iMac) and GNUstep's "we're not implementing NextStep anymore, now we're doing Cocoa" stance gives me an impression of "we're going to break your apps just like Apple does".

(of course that is one reason, another is that when i tried some programs made with it years ago there were major glitches and bugs like the text editor widget locking up the entire program - admittedly that was years ago and it probably has been fixed but it did give me a bad impression since the project was already more than a decade old by then and already in a state where barely any developers worked with/on it)

Basically, what i wonder is, if i make a Linux binary today that links only against glibc and the GNUstep libraries (including the ObjC runtime), will it work in 10 years[0] even if it uses some API that in the meanwhile Apple decided to change or it'll break? Ignoring of course breakage forced on the project from outside forces they could do nothing about (e.g. for some unfathomable reason the C ABI itself changing or everyone switching to RISC-V with all x86 CPUs blowing up at the same time and every x86 emulator out there suddenly losing both its source code and any existing binaries).

I get the impression with ObjC having a very "dynamic" nature it should be possible to do that.

[0] obviously if it works in 10 years it'll also work in 20 years since in 20 years a binary made 10 years from now will still rely on the libraries being backwards compatible - the 10 years was an example to give a sense of scale

Is backwards compat a thing on osx? The kernel ABI is not stable, I don't know how often their libc equivalent changes. Glibc doesn't make much sense in that environment.

My guess would be that your hope is doomed by the platform whatever GNUstep does.

> Is backwards compat a thing on osx?

It really depends. I managed to get a universal intel 32/64-bit app compiled on OS X 10.5 run on Catalina, which is 10.15. But it was a very unremarkable app. Just a simple NSWindow and label. Nonetheless demonstrates you can technically have some backwards compatibility.

At one point in time (say 2004), you would've been able to launch Classic environment on a PowerMac G5 and emulate 68k software in Classic, all the while enjoying OS X software natively. That should span some decades worth of Macintosh software, but of course this era is simply gone now.

Last time I played with getting a moderately complex old (Jaguar/Panther/Tiger era) Obj-C/Cocoa OS X app building on modern macOS, fixing the build-stopper errors didn't take too long but there was a mountain of deprecation warnings, despite everything seemingly working as expected.

That was a few years ago though so I wouldn't be surprised if some of those deprecations have turned to errors in the meantime.

To an extent, they've removed things like Carbon (the Classic Mac OS descended API) and 32 bit support in general, but they don't go out of their way to gratuitously break the Cocoa API or libc. But they aren't Microsoft with the whole "Win32 must never break compatibility" mantra, so randomly stuff kinda breaks between versions more though neglect than intention?

Microsoft has long forgotten that mantra.

See .NET Core migration, Windows Runtime tooling, Xamarin/MAUI, UWP/WinUI 3.0,...

The folks that were responsible for that kind of backwards compatibility apparently are no longer there, replaced by younger blood without any knowledge of Windows development history.

Nowadays we even get CLI stuff instead of nice VS wizards.

Well, regardless of the newer stuff, at least they still stick with the "must never break Win32 compatibility".

See UDK 1.0 versus 2.0.

The first version used COM, while the second uses plain C API.

Windows has a Compatibility Mode with is unmatched by any Operating System maker. I've got Windows 10 running Visual FoxPro 3.0 from 1995 and Visual Basic 5. Try that on macOS or any linux system with any application with a GUI from source or binaries.

https://en.wikipedia.org/wiki/Compatibility_mode

Indeed, pity that the newer generations of Microsoft employees don't seem to care as much as their predecessors used to.

I doubt this will be something still going forward, now that Azure OS is what mostly matters, as proven by anything post Windows 8.

Try to run anything from Windows Runtime tooling introduced alongside Windows 8 on latest Windows 11. Or better yet, Windows Phone 7.

You mean running Mosaic from 1995 with libc5? Done.

OSS Audio? OSSPD, AOSS>

To the extent running 30 year old software is a feature at all, it can easily be done with an emulator.

I was referring to using GNUstep as a framework/toolkit for Linux, not macOS and the reason i asked that was exactly because macOS has issues with backwards compatibility and GNUstep has the goal of copying Cocoa - my question was, "to what extent?"

Linux is backwards compatible going back decades and glibc also largely maintains backwards compatibility as long as you are not using hidden APIs - and realistically if you stick with the common C stuff you should be fine in most systems (AFAIK outside of Linux, most Unix systems treat the C library as their "stable" API).

Backwards compatibility on macOS is quite good. Whenever Apple breaks compatibility, they give a lot of notice, mark the functions in the headers as deprecated, then wait a fair amount of time before actually removing them. For apps that are continuously maintained, it’s not too huge of a burden to keep up with most of the time. For apps that are no longer in development, it can suck, for sure, to not be able to use an app after a breaking change, though.

>Is backwards compat a thing on osx?

There was a time when it was --- there was a "Missile Command" game written for the 128K Mac which still ran fine in the Mac OS environment running the last version of MacOS on PowerPC machines:

http://www.mrob.com/pub/comp/missile20.html

and the previous version of Rosetta was for running PowerPC apps on Intel machines (and before that it was for handwriting recognition).

and I've always regretted that Macromedia Freehand didn't get re-written so as to run for longer --- that's one of the reasons I've pretty much switched to a Windows machine (using a Samsung Galaxy Book 3 Pro 360, which replaced a Book 12, which replaced a Toshiba Encore 2 Write 10, which replaced an Asus Vivotab Note 8, which replaced a Fujitsu Stylistic ST-4110, which replaced an ST-2300, &c.) I use a Wacom One w/ my MacBook, but it's just not the same.

> will it work in 10 years[0] even if it uses some API that in the meanwhile Apple decided to change or it'll break?

Is 10 binary or decimal? Do you mean 2 years, or actually 10 years in base-10?

That was hexadecimal, i meant 16 years in base-10 :-P

Base 10? We're always using base 10! :)

An explanation of what GNUstep is (and what it is not):

https://gnustep.github.io/information/aboutGNUstep.html

This is informative. I was thinking I was familiar with GNUStep when in fact I was thinking about WindowMaker.

I'd love to run GNUStep on my Linux machine simply because The NeXT heritage brings with it the only sane keyboard shortcut / keybinding system on the Linux desktop. Before I go on a tangent, let me link to NEXTSPACE [1] which is a CentOS based GNUStep OS. Sadly, since the author is from the Ukraine, all development has halted since last February :( I hope he is ok.

Now the keybinding tangent: If you're not rolling VIM keybindings in the whole desktop (which is tricky for non-modal interfaces and alienating a large amount of users), the next best ergonomic keybinding scheme is the Emacs / Gnu Readline system [2]. It allows moving the cursor without having to move hands around (e.g. going to the arrow keys, coming back to the alphabetical keys). It is one of the base tenets of unix systems. Every terminal supports it. Yet, the whole bunch of Linux Desktop systems completely ignored these keybindings and copypastaed the Windows concept instead, coming up with a weird chimera of readline in some places, and half-windows, half-self-invented in others.

Gnome used to have an Emacs compatibility mode that was somehow off by default and had to be enabled in a tweak. It was removed with GTK 4 however. If you want to do that in KDE, you have to run a weird python daemon, and half the apps constantly stop working because they key codes are being messed with.

MacOS on the other hand, supports these keybindings in every input dialog, it is a pleasure to use. Even more so, to have the same keybindings in every app and not having to learn new ones on a per-app basis.

Of course, running weird python key code daemons runs into the other problem that macOS & Gnustep solved in a much nicer way: By copying the shortcut system from Windows and patching it on top of Readline, many shortcuts have double entries. Printing is CTRL-P, but so is readline "Previous Line". macOS and Gnustep solve this by having a separate key for app actions: Command (or Hyper or Alt). So print is Command+P. Everywhere. Previous line is CTRL-P. This is always my go-to Linux joke where "Copy" is "CTRl-C" everywhere, except in the Terminal, where it's CTRL-SHIFT-C because yeah, CTRL-C has another meaning. Talk about a sane shortcut system if apps have to use different ones per shortcut because the amalgamation of Windows Shortcuts + Readline is a match made in hell.

[1]: https://github.com/trunkmaster/nextspace [2]: https://en.wikipedia.org/wiki/GNU_Readline

>arrow keys

sane people will just use hjkl even on readline with ~/.inputrc and 'set -o vi' in ksh.

I miss the GNUStep live CD. Sometimes I wish Gnome wasn't created as a libre KDE alternative and a GNUStep/WMaker based DE would grow up.

Why not go further, and just use Haiku? Then you're not even using anything as mainstream as Linux!

> As the much villified theme for star trek enterprise says "its been a long road getting from there to here"

Off topic, but I actually really like Russell Watson's 'Faith of the Heart'. I mean, how can you not?! https://www.youtube.com/watch?v=M6bumUQwQIU

So does that mean that macOS Catalina apps can run in a GNUstep environment or that GNUstep apps can run in macOS Catalina?

I think it’s about source code level compatibility: macOS software can be compiled for GNUstep.

Of course Swift is now almost a decade old, so it's increasingly rare to find a pure Objective-C codebase

Does anybody know why they show scrollbars at the top and left of the scrolling area, unlike any other UI ?

In Smalltalk-80 they're on the left side, see e.g. https://github.com/rochus-keller/Smalltalk

As is known, Jobs was inspired by the Smalltalk GUI.

I recall reading that the reason is that the mouse pointer is more likely to already be near the left of the window, because more of the text is on the left, especially in a programming language.

GnuStep uses WindowMaker, which shows scroll bars on bottom and left because that’s where they were on nextstep.

It actually doesn’t use WindowMaker. GNUstep is a reimplementation of core Apple frameworks, and can run in any DE (including Windows)

WindowMaker is its own thing that just so happens to be trying to recreate software from the same ecosystem as GNUstep, but they don’t depend on each other.

Combining them tho does give you that genuine experience

Note that Window Maker is a completely separate project with its own GUI toolkits (WINGs - it literally means "WINGs Is Not GNUstep" :-P).

That's where they were on NeXTStep:

http://toastytech.com/guis/ns332.html

And it's actually a pretty good place. Just like the whole "a menu is just a window with a list of buttons" idea was great.

If we lose that website, we will lose so much computer history and knowledge.

.. serveral 'ours layter ...

Thanks for that rabbit hole of nostalgia, just remembered how wild Mac OSX 10.1 in its first release was. It was a real game changer, and looked great (albeit a bit slow on my poor G4 Cube).

As others mentioned, this is due to the NextStep theme which is the default. However GNUstep supports other themes and can have the scrollbars at the right position too.

Catalina is no longer receiving updates

“The reason this is still significant is because Apple hasn't made many changes to either the Foundation or AppKit APIs since then.”

And to be honest, I expected GNUstep to chase Lion or something, I had no idea there has been so much progress lately. Did anyone here use it?

Three years ago I had passing interest in GNUstep, and in the past there have already been demos of so-called "Renaissance apps", which can compile against either AppKit or GNUstep. The GNU Mail program is one such program.

Wait till you learn Clozure Common Lisp has an Objective-C bridge and features a Mac IDE written with it. Unfortunately it has bitrotted over time as Apple constantly changes AppKit and some Objective-C internals, but it's able to run on Catalina just fine, and it works even better on older versions of OS X.

> Wait till you learn Clozure Common Lisp has an Objective-C bridge and features a Mac IDE written with it.

LispWorks has that, too. Without the bitrot. It's running natively on current Apple Silicon Macs.

See the manual: LispWorks Objective-C and Cocoa Interface User Guide and Reference Manual

http://www.lispworks.com/documentation/lw80/objc/objc.htm

too bad ccl has no plans to be ported to arm afaik

Naturally, with exception of Metal and Driver Kit, all new toys are based on Swift, or frameworks shared with iOS.

Foundation is going to be redone in Swift.

https://www.swift.org/blog/future-of-foundation/

It seems Apple isn't immune to the "rewrite entire codebase from scratch". I'm not saying it is a good thing or a bad thing, but it is a trope of software companies.

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Both true and false. The OS is not receiving updates, but Catalina and newer have a built-in malware scanning tool that does continue to receive updates from apple. You can read about that here.

https://eclecticlight.co/2022/11/01/everything-you-need-to-k...

Reply on news.ycombinator.com