If the original project has a governance process that's difficult to integrate with and that slows down progress, a fork has a better chance of hosting a vibrant ecosystem than the original.
I can't imagine how that could have gone differently. If Hurd was completed in the 90s, would anyone use a kernel that was slower than linux because it doesn't share data structures between parts of the kernel?
"Windows 11 security measures include Memory Integrity and Virtual Machine Platform (VMP) to protect against malware, which are features that can also disrupt gaming performance. If you choose to turn these features off before gaming, it can improve your performance and help you focus on the games at hand. Afterwards, it’s important to turn them on again since you are opening your PC up to risks while it’s less protected. For short periods, you might try turning off your Memory Integrity and VMP to see if you notice a difference."
> If Hurd was completed in the 90s, would anyone use a kernel that was slower than linux because it doesn't share data structures between parts of the kernel?
Perhaps in the server world where uptime is critical. After all, that is Linux’s largest market share.
As someone who was a child during the early days of KDE, GNUstep, and GNOME and who didn’t start using Linux until 2004, I’d like to learn more about Miguel de Icaza’s attempts to work with GNUstep; I’m familiar with much of GNUstep’s history but this is news to me.
No, if we had infinite resolution monitors we wouldn't need anti-aliasing.
You gotta bandlimit your signals or you'll see aliasing. That's just how signal processing works. Imagine if your audio player's output voltage jumped between 16bit levels instead of smoothly transitioning. It would sound horrible. That's how bad jaggies look to people who didn't grow up with slow computers
> if we had infinite resolution monitors we wouldn't need anti-aliasing.
Color is based on frequency. There's an inherent limit to the range of light colors our eyeballs can process.
> You gotta bandlimit your signals or you'll see aliasing.
When changing sampling rates. If the monitors resolution and the font resolution were identical, then would bandlimiting actually have any effect?
> Imagine if your audio player's output voltage jumped between 16bit levels instead of smoothly transitioning. It would sound horrible.
The brain processes sound logarithmically. Is the same true for vision? I mean, I watch movies at 24 frames per second, and yet, I'm usually incapable of perceiving this.
> That's how bad jaggies look to people who didn't grow up with slow computers
Anecdotally.. but if the computer is experiencing a limit in displaying full resolution data to me, I actually don't mind noticing that fact.
You know what I meant by "infinite resolution". Today's monitors are nowhere close to retina (human eye resolution) and even further from being diffraction limited (the color frequency stuff you're talking about)
> If the monitors resolution and the font resolution were identical
> I watch movies at 24 frames per second, and yet, I'm usually incapable of perceiving this
Film projectors flash the same image multiple times because humans can easily notice 24fps. The lamp flickers and that's why movies are called "flicks". Good monitors flash each frame for only 1ms for the same reason: https://blurbusters.com/faq/motion-blur-reduction/
Try the UFO test: https://www.testufo.com/. If you genuinely can't see the difference between 30/60/120 Hz, you should get an eye exam because that's not normal.
> Fonts are typically infinite resolution because they are small programs that you execute.
Vector fonts and vector graphics are two different things. Fonts define an outline. You can programmatically displace points on that outline but you are still limited in the types of outputs you can define due to this restriction and to the overall number of points per glyph the font system allows.
They're pretty far from "infinite resolution" and the errors between screen space and font space are not particularly large and are probably not best understood through signal processing metaphors, was my point.
I didn't even know GNUStep was being actively developed or maintained. I'd love to be able to use GNUStep as my primary workstation environment. Does anybody have any recent experience with attempting such a thing?
Probably not what you want to hear, but I used it/WindowMaker in the early 2000s, it was alright and worked well on my underpowered machine. Moved on to a more modern environment after maybe two or three years.
The bane of old X11 environments and UI toolkits is the DPI/resolution of modern screens. Usually the sweet spot for them is around 1600x1200, usable on Full HD, unusable on 2K. Windowmaker and GNUstep included.
I used Windowmaker with GNOME session running in background for years as a main driver, and went KDE Plasma due to the reasons above.
Windowmaker icons are 64x64 and while there might be a way to increase them, dockapps are rendered in 64x64 max. Devs used the display limit to achieve a certain style, such as LCD dockapps. Useful and charming but it's small and unusable at 2K or above.
So the first thing you're going to get yourself wrapped into are the fonts and font sizes in Windowmaker and GNUstep, and you'll never achieve the same look and feel as default on appropriate resolution.
I don't develop for GNUstep anymore, but I remember making scalable dock apps possible some decades ago.
You need to configure the size of icon windows in windowmaker WPrefs, the app then needs then to query the [[[NSApp iconWindow] contentView] bounds] that it was created with. There are almost certainly still some dockapps in existence that don't do that and just use hard coded sizes though. I know that the clock app AClock, implements it correctly.
Most of the dockapps I used do not use GNUstep. I peeked into two now, one is libdockapp based, the other has internal code, both of them assume a default size, because it's not trivial for them to query the configuration in GNUstep format without the libraries.
I'll try messing around Windowmaker in the next few days, this discussion fueled some old interest.
It is easier to just use `XGetIconSizes` on the `DefaultRootWindow` than try to pull it out of configs or doing some kind of plist parsing. Here is the function GNUstep uses... It should not be difficult to pull the relevant stuff out for use in C.
Unusable might be a tough word but I come from a viewpoint where I had wmaker install 10 years ago that could rival big desktop environments in usability and sleekness and looks but it was still NeXT-alike.
Big part of it was GTK2-GNUstep theme which made GTK apps feel "native" and there was something for QT too.
Can you put up some screenshots with GTK/QT "modern" apps floating around too?
Also I can't believe you are not finding that text size too small. I have 27" screen, great vision, sitting at a normal distance, everything is just too small. It's not unusable in strict sense but if you have problems with tiny text on big screen it would be.
P.S. for firefox stats I think we're mixing apples and oranges, OP asked about "workstation", and those are are worldwide client stats, so you have a lot of laptops and a lot of legacy computers in it
These are called "Renaissance apps" by GNUstep users. They are apps designed such that you can run them on both GNUstep and Cocoa. There used to be a tutorial out there, but the site is gone now. Here is an archive link to it: https://web.archive.org/web/20180125122828/http://www.gnuste...
I haven't followed gnustep in a long time, but I thought renaissance was a library that was an alternative to NIB files, with an XML format.
Back when I wrote some small apps, it was very easy to target Mac with the GNUstep makefile package. That could build on Mac without any extra work on the build side. I would sprinkle a lot with #ifdef __APPLE__ when the APIs differ, on a case by case basis. A lot of things (most?) work on both without modification, it just depends how new the API is.
I assume you meant to ask "how to build" and not "how to write", since writing the Objective-C code is trivial since it's all just AppKit and there's documentation on Apple's website for that.
Building for both GNUstep and macOS is difficult. The problem is, macOS wants you to use Xcode and GNUstep wants you to use their weird build system. In order to build software that is compatible with both GNUstep and macOS you will either need need to have two parallel build systems (one GNUmakefile and one Xcode project) or use a custom build system.
Personally I think GNUstep's build system is stupid, and I don't like using Xcode, so I lean more towards a custom build system. Sounds insane I know but it really isn't that bad. Compiling and running a Cocoa application on macOS pretty much boils down to this:
clang main.m -framework Cocoa
./a.out
I don't remember how to do it for GNUstep. It's been a few years. Their GNUmakefile thing is REALLY weird, they have all these Makefile macros you need to import and they try to abstract all of this stuff away. Using Makefile macros. It's horrible. I asked ChatGPT and it generated this:
include $(GNUSTEP_MAKEFILES)/common.make
APP_NAME = YourAppName
YourAppName_OBJC_FILES = main.m YourAppClass.m
YourAppName_RESOURCE_FILES = Info-gnustep.plist
include $(GNUSTEP_MAKEFILES)/application.make
I would make a basic GNUmakefile, then run it with `V=1` (or `VERBOSE=1`? i forgot the name of the environment variable) to get the actual terminal commands its running, extract those, put those in your one-liner custom build script and be done with it
MPWFoundation, Objective-S and related all build on both macOS and GNUstep without buildtool. Once you have the GNUmakefiles they are not that hard to keep in sync.
They're source-compatible, so if you write it for GNUStep you should also get a functioning macOS application if you build it with that target (you just won't get whatever they call Carbon and Cocoa nowadays).
Carbon is more or less dead (certainly for new apps, anyway), and GNUStep does indeed implement Cocoa. GNUStep doesn't implement a lot of other macOS frameworks, though.
I'm the developer of PikoPixel, a cross-platform Mac/Linux/BSD pixel-art editor.
PikoPixel was initially written for Mac, and GNUstep saved me a huge amount of work from having to completely rewrite it for Linux/BSD.
However, it was still a significant effort:
* GNUstep's an implementation of the Cocoa framework only, it doesn't include any other macOS frameworks.
* The same source-code & UI resources can produce different behaviors & visuals between the different platforms. This is due to different Cocoa implementations, some missing functionality on GNUstep, different system fonts, different window managers & desktop environments (Linux/BSD have many of them, each with their own quirks), etc.
A cross-platform Mac/GNUstep app is definitely doable - PikoPixel is now available in many Linux distro repositories (Ubuntu Studio even preinstalls it as a default graphics app) - but expect to spend significant effort correcting platform differences (depending on the app).
I'd suggest getting started by spinning up a VM, installing a GNUstep dev environment on it, then downloading some GNUstep app sources & building them.
PikoPixel's homepage links some build scripts for Debian & Fedora that will install both a GNUstep dev environment and PikoPixel:
https://twilightedge.com/mac/pikopixel/
> (Note: PikoPixel's fixes & workarounds for the platform differences on GNUstep are found in the various source files that begin with PPGNUstepGlue*).
This alone would be a nice standalone open source project that one could extend to offer more coverage.
KDE Plasma is great and actually seems to have inspired a bunch of Win11 approaches, so it is possible to get things looking good but there's definitely truth in the sentiment above: a huge chunk of OSS software looking terrible.
There's always the form vs function debate but it's a shame that more doesn't manage to have both form and function if the respective specialists could coordinate
i still use MacOS and windows from time to time, and i simply have to disagree. using MacOS has just as many WTF moments as i get with Gnome (and KDE too i think, but i haven't used that in a while) a windows just leaves me baffled every time i have to touch it. ( https://commadot.com/wtf-per-minute/ )
The one thing I think is great in Windows is the whatever the active apps bar at the bottom is (taskbar?). Hover, get thumbnails, etc. On mac, I find it kind of painful to juggle a few windows of the same application. Can say the same in Linux as well, some apps don't even show up at all, even though they're running in a window/viewport.
I genuinely like and dislike most OS UIs I've tried. They all have things that irk me. While windows settings has gotten more consistent, it's also all the more painful when you had gotten used to the "old way" of doing things and where to look. If MS executives could just get TF out of their own way on some of the stupidity and force-feeding.
Mac, just feels a bit dated at this point, but the touchpad integration across all apps is great. Not to mention the macbook touchpads being second to none in terms of usability.
Linux, I can shift to almost exactly what I want. There are rough edges and spots you cannot reach via UI, but it mostly works without issue. Been using Budgie as my DE for over a year, fairly customized and like it a lot.
discovery of hotkeys can be a challenge. despite having used gnome for years now i only recently learned that i can switch windows with alt-esc instead of alt-tab, which is much faster when you have multiple windows of the same app or want to switch back and forth between to windows. and i only found this while searching for an extension that would make switching windows easier.
the thing is that i would not even have thought of looking there. i was at "switching windows is a pain, how can i make it better" which is not "is there a hotkey to switch windows differently, because why would i even consider that there are multiple ways to switch windows, especially with gnome that kind of has a reputation of removing seemingly unneeded features.
It does have that reputation but I've found it very usable.
"Half-maximizing" windows with Super+Left and Super+Right is very handy when I need to see things side-by-side.
Moving windows from one screen to another by pressing Super and doing drag-and-drop, and moving windows across workspaces with Shift+Super+PgUp and Shift+Super+PgDown are also convenient.
Also, if you’re at the command-tab picker, the up arrow key will switch to windows of the currently selected app (and left/right arrows will change the currently selected app). The macOS command-tab switcher has a bunch of functionality built in.
Less polished in some areas too, though. It's slowly improving over time but for example fine UI/UX details like whitespace usage, control alignment/placement, and typography have always felt a bit… "off" in KDE as well in most software written with Qt, which I think probably boils down to Qt being more likely to be chosen by devs who are more technically inclined than design or UX inclined.
In my opinion GNOME and GTK apps generally get those details more "correct", though GNOME 3 and up goes way overboard on padding. Strip that padding down with a theme and its design is solid though, and Cinnamon, XFCE, and MATE get these right out of the box with no modifications necessary.
But that's why these "X has a better UI than Y" arguments are silly. I prefer KDE to any other DE because it worked (I now use MacOS and can't run other DEs) for me, and most people who prefer other DEs. That's OK. They all have different strengths and weaknesses (customization, resource usage, ability to run on certain OSes, high DPI support, etc).
The desktop and UI conventions are largely inspired from NeXTstep, which is from the late 1980s and was considered ahead of its time. However, there is nothing preventing the use of alternative designs. One example is the Etolie project from the late 2000s and early 2010s, which used the GNUstep API but didn't rely on NeXT-style UI conventions:
If GNUstep gains traction, there will almost certainly be a project to create a modern desktop. I personally like the NeXTSTEP UI, but I wouldn't mind something new.
every few years i go and search for a NeXTStep theme for gnome or kde. (i also look at GNUstep but switching the whole desktop environment is more effort, since the needed packages are not easily available, and the apps i use do not have GNUstep alternatives either, so i am struggling a bit not knowing how to proceed)
Also, some GUI on Mastodon showed how OSX would look without Aqua by patching some libraries, and it show up the same literal ugly interface from GNUStep/NextSTep. Literally the same, with the grey rectangles.
OSX it's as ugly as GNUStep/NeXTStep. Search for the Mastodon post on patching OSX to disable Aqua on MAC OS X < 10.5, and you'll see how they kept the exact same NeXTStep/GNUStep widgets. I am not trolling, Google/DDG it.
apart from calling it ugly i can confirm that. early OSX was 100% NeXTStep with a changed style. i loved it. MacOS now is really very much a modernized version of that.
well, the one positive thing about apple phasing out Objective-C is that enthusiasts may be more motivated to work on GNU Objective-C to catch up, also considering that doing so is no longer a runaway target.
The clang/LLVM Objective-C compiler is open source. You can use the same bleeding edge compiler for iOS 17 on Linux for example. So you can use features like Automatic Reference Counting, blocks, etc no problem.
The problem is the frameworks (Foundation, UIKit, AppKit, etc) are closed source. So you either need to create your own frameworks or use something like GNUstep.
Previous posts describe Swift in a state of flux, while Objective-C is more stable in most areas. It would not appear that phasing out Objective-C would even be possible.
> It’s not recommend for new code (in Apple land) and they’re already starting to make features Swift-only.
That's a real shame because FFI language bindings to Objective-C frameworks are amazingly simple to do with Objective-C. You basically create low-level C ABI bindings to objc_msgSend and about 40 other routines (e.g. class_getName). The latter bindings are principally for introspecting the class hierarchy and acquiring references to opaque class and method implementation pointers. method_getTypeEncoding returns a text-encoded type signature for a method. And objc_msgSend itself is a magical variable argument function for invoking arbitrary methods on arbitrary objects (including classes, which are objects themselves).
With that small set of C ABI bindings you can generate strongly typed bindings to all the many thousands of Objective-C framework and library interfaces, system and third-party. I did this for Lua and it works beautifully. And you can just as easily define new classes and methods and wire them up to the host language (Lua, Python, Java, Rust, etc), though I haven't needed to do that just yet. In my case this is all done dynamically at runtime, except for the ~40 required static C function bindings.
The only difficult part was binding objc_msgSend. You could use libffi, but in my case I wrote a script to statically generate a permutation of Lua/C binding functions with up to 6 arguments, any 2 of which could be doubles instead of scalars, and either a scalar or double return value. Atop those bindings sits a small Lua library which, using the other ~40 Lua/C function bindings, implements a type-safe bridge for the entire macOS Objective-C platform, GUI frameworks and all, modulo a small number of niche edge cases (e.g. IIRC there's a special Objective-C ABI for directly returning small structures which my objc_msgSend bindings don't implement, but I haven't run into those cases and my Lua bridge code would throw an error if I tried).
Because Objective-C itself uses reference counting, it plays well with any GC environment or lack thereof.
I'm sure Swift is a nice language, but there are many nice languages, and Objective-C makes language interoperability downright dreamy.
Almost. You could start the main loop ([NSApp run]), but the reverse bridge would need to be implemented as the 'run' method blocks so you need event callbacks to be able execute any Lua code within the main loop. And for event callbacks you basically need the ability to create C Blocks (Apple's bespoke C/C++ closure primitive) to forward calls into Lua, and I just haven't done that yet. (It's simple in principle.)
I originally had no inkling that Objective-C was so easy to write bindings for. I was vaguely familiar with its message passing architecture, but didn't appreciate the low-level implications--the potential ABI power (not just API) that came from foregoing static linking. I started my app hoping to not have to write many bindings to macOS interfaces, partly because I wanted to port it to Windows and Linux. I'm using the Yue GUI toolkit, which made it easy to bring up a simple Lua app without having to understand anything about platform GUI frameworks.[1] I wrote a whole slew of Core Foundation (plain C) Lua bindings for little things like property file integration, hoping to avoid dealing with Cocoa APIs. But eventually all the little limitations of Yue (many now resolved) and my need for deeper desktop integration forced my hand.[2]
My Lua bridge is definitely not the first, but most (all?) such projects are dead or dormant. Some might still be usable with some tweaking; I don't think out-of-the-box, though, which IIRC helped push me toward writing my own. My app is currently closed source. I've open source'd parts of it already (e.g. early version of a suite of LPeg parsers for X.509-based formats, posted to the Lua mailing list), but my Lua/Objective-C bridge is spread across several files (e.g. the objc_msgSend thunk permutation and code generator) and not something that can be easily dumped into a standalone form without a little refactoring. If I have the opportunity to do so, I may in the future. I just don't like publicly releasing anything that isn't usable out of the box. But if you contact me by e-mail I'd be happy to share the code: william@25thandClement.com or william@keymux.com.
[1] Yue also has JavaScript bindings, and both sets of bindings rely on a shared C++ framework, so Yue provides equal treatment to C++, JavaScript, and Lua applications.
[2] My app, KeyMux, is for integrating common open source toolchains and work flows with hardware-protected RSA and ECC keys, including the Apple T2 Secure Enclave, for which I had to write static C bindings to Apple's Security framework, the low-level public interfaces to which are straight C interfaces. So in truth I would have had to write Core Foundation bindings one way or another as Security heavily uses CFArray, CFDictionary, CFNumber, and CFString. But those bindings probably would have been much simpler and more basic if I knew I would be able to lean on the Objective-C frameworks (e.g. Foundation, AppKit) for other desktop integration tasks. All of this--the whole world of desktop GUI programming, not just Objective-C--was new territory for me, so at least I picked up a wealth of knowledge on my circuitous journey.
> Question: is Objective-C post 2.0 being actively maintained outside of Apple?
Yes as part of the GNUStep project [1]. You can compile Objective-C with Clang for any platform, including Windows, and link with the GNUStep Obj-C runtime. The big problem is outside of GNUStep and macOS you won't have any frameworks - not even NSString.
> I loved Objective-C very much (yes, really) and I'd like to continue using it after Apple phases it out
You're not alone. Unlike C++, Obj-C was a reasonable OO extension to C. It's a shame the language never received more love.
I would wish they'd pick something based on whiteish background instead of gray (white like the early Mac OS X versions would be nice, don't need pinstripes.)
Some people like dark themes, others like light themes, so gray is the middle ground :-P.
FWIW GNUstep is themable so it should be possible to customize it. Though i'm not aware of any that follows modern trends, but at least it is possible to make it kinda sorta like a broken telephone version of early Mac OS X using the Rik theme[0] (the screenshot also seems to be using a custom theme and setup for Window Maker too and judging from the shadows it most likely also uses Compiz as a compositor).
Some like it, but I believe its a big hinderance for wider adoption. Maybe as the older folks age out, there will be some motivation to update the theme again.
(Its a big reason why I stopped contributing to GNUStep, as the resistance to modernize at least a little bit was large).
What can a "modern" OS do than something like NextSTEP absolutely cannot? Aside from the chrome, and performance-bound things like video streaming and gaming, the functionality of what we can do with computers changed very little over the decades.
Most if not all systems had threads before POSIX Threads. POSIX Threads brought a standard interface to replace the chaos that reigned. It took many years for the ridiculous amount of thread API portability cruft in Unix ecosystem software to be excised. You saw something similar with atomics until C11 and C++11 atomics displaced old interfaces, though that switchover seemed to happen much quicker, perhaps because it was principally a userspace issue and you could bring newer toolchains and binaries to older platforms.
Well, Ive had to buy a fancy generator and powerful LED flashlights because my fly-over America town's infrastructure has terrible reliability.
Not that Im in a bad neighborhood: I just realized I might be the only one in my block that doesn't have a luxury vehicle. 8 year old Hyundai and 10 year old Golf for me in a sea of Mercs, BMW, Lariats and Lexuses.
Of course, I must be poor. I have a portable, Chinese clone 7000 kW gen that only feeds 6 circuits and sounds like a pneumatic gun. Half my neighbors have full-house automatic, natural gas fed GENERACs.
The cloud and browsers is a truly miserable paradigm. Serfdom and a thick client with an absurd amount of chrome and a dumb multitasking interface (tabs). What on Earth is enticing about any of this? I see people using Google Docs and/or Office in the browser, and they’re contending with a UI rendered underneath a browser UI and it all looks so cramped and of course eventually somebody instinctively clicks the back button to undo something and all hell breaks loose.
Theoretically you could build a self-contained browser and run it there.
In practice, even if you managed, say, to port a modern Firefox and all its baggage down to OpenSSL and even GCC to compile it in a mighty for of herculean effort, it would still likely die of a thousand paper cuts anyway because quite a lot of syscalls would be expected to have evolved since.
Had to be about a year ago - I pulled down the latest sources for gnu emacs and built them on my next slab running OpenStep 4.2 (I think? 3.3?) - I think I had to tweak one source file and I joked about how long it took to build ("this really feels like I'm getting something done!") but it worked. Not Firefox, obviously, but an impressive amount of backwards compatibility in that codebase.
Yeah, but that’s Emacs, they are known to keep compatibility with some odd Sun box running SunOS a greybeard contributor just won’t let go of.
But other modern codebases will want more modern syscalls without fallbacks and compromises (see those atomic file operations which solve some nasty vulnerabilities for an example).
Not much. I had a NeXT cube and the user + developer experience on my M1 Air is largely the same. More portable, obviously, and more colourful. Faster, but not nearly as much faster as it should be, IMHO. Well fortunately I write very little Swift, so at least compile performance is OK, and a lot of the user-noticeable speed improvements come from SSDs.
> video streaming
NeXTStep had NeXTtime, which IIRC was also important in sealing the Apple deal, as Be's big claim to fame was (multi-media) performance, with the for-the-time impressive demo of 4 videos playing simultaneously. Nobody had really thought of it before, but playing 4 videos was also not an issue in NT, so Be-blocked.
I only have experience with OpenStep 4.x on PC hardware, but I feel like you may be vastly underplaying the speed gain from then to now, unless NeXTstep on black hardware really felt that much faster than on one of the blessed 486 configurations. I mean, NeXT was not known for speed, and this was the age of slow spinning rust or, for NeXT, even slower MO drives.
I remember NeXTtime - it was essentially a prototype tech demo that could play some -- only some -- QuickTime movies in a very small window. I find it unlikely that it was significant in the deal. IIRC the Apple tech team wasn't that impressed with the interrupt latency of Mach, which later had to be fixed at Apple out of necessity.
> Not much. I had a NeXT cube and the user + developer experience on my M1 Air is largely the same.
I recently (3 years ago) started developing on iOS and MacOS.
I learnt programming on Mac Plus in the late 1980s early 1990s
Wow, what a change. In the 1988-92 Macs were the bees knees for development. Really good.
Now, definitely not. I regularly switch between Mac, Linux, and Windows for development.
Development on iOS and MacOS is deeply painful. The tools are flash, lots of features, and they mostly work, that is they do not really work.
Apple took US$99 from me for a license to write software for their machines, and now I cannot run my software on iOS unless I am connected to the Internet, so they can "verify" my license. (I never got the license - another sad story)
Many times, regularly, the "verification" process goes awry and I spend time trying to work out which particular string of gobeldy gook I need to enter n which obscure part of Xcode to get the equipment I (my boss) paid for to do anything other than be dead weight.
The flagship language (Swift) is half arsed. Some bits are OK, but the threading model is from the 1990s dressed in drag. Memory management by reference counting? Golly, how 1990s. Passing class parameters by reference as default, but not struct parameters - say what?
Distributing the software we write to the users that need to use it is immensely painful, not my immediate problem, but I watch people in my firm tear their hair out trying to make it work.
Parameters of class type aren't passed by reference, either. Both instances of structs and instances of class are passed by value, except in the latter case the value being passed/copy is the reference. To pass by reference, you need `inout`.
I think there a lot of niceties that make laptops and portable computing possible - suspend to disk, advances in scheduling, ubiquitous hotplug support - that I do appreciate, but also do take a bit of architecting.
Good question about the screens. Under OpenStep on PC hardware, I think you can do multiple monitors. I believe TCP/IP was native to NextStep, but doubtful about Unicode way back then.
I don’t remember what other multihead graphics cards existed at that time. For multiple video cards, you again had to reach for Matrox, since they were produced in both PCI and AGP variants and I’m unsure about other brands.
Yes, I built my first PC that could run OpenStep with a Matrox Millenium. Since I was new to Unix at that point I assumed that Netscape was available for OpenStep. I later found out that the Unix guru was running an X session from an SGI machine.
In 1990 you could have up to 4 displays on a NeXT Cube + 3 NeXTDimension 32bit colour boards. These were 1152x864 32bit colour displays at a time when people were using 80x25 16 colour text (likely, wordperfect/Lotus 123), or /maybe/ 640x480 16 colour graphics in windows 3.0.
NeXT had full ipv4 support from the start.
Unicode wasn't a thing until after Apple bought them.
One experiment I've done on my own NeXTStation turbo was run equivalent applications on both a NeXT and a modern Intel mac pro. Mathematica, email, Framemaker/affinity publisher all take roughly the same time to load and execute similar tasks.
Yes you can't do 3d, video, or AI on a 33 year old NeXT, and the image files would be smaller, but beyond that you could easily do your day to day work on such a system. It doesn't feel old at all.
But modern OSes added support for a luxury we call hotplugging. Would that work smoothly back in the day?
I’m not negating your experience and share the same sentiments, but there is also a bit of undeniable progress modern OSes made.
One such bit is high DPI and mixed DPI support (theoretically should be easy peasy with Display PostScript, but somehow I don’t think it would pan out well in practice).
Multiple monitor support had caveats, IIRC, that contemporary Macs did not. Possibly the bit depth of all of the monitors had to be identical, or you'd get dithering on some?
>Multiple monitor support had caveats, IIRC, that contemporary Macs did not
Considering that some M1 laptops didn't support multiple monitors because of the internal USB allocations, it's not like modern Macs don't have such caveats
Getting dithering on some is an acceptable compromise compared to getting dithering on all of them or some displays flat out refusing to work, but that’s just my opinion.
So if you don't care about Unicode because you're covered by ASCII, and only use one screen (or the laptop screen), and already had networking in 1991, not much?
Modern cryptography enters the chat. The way it has been implemented so far, it won't work as a drop-in replacement unless the whole stack is aware of all its capabilities. Typically a bump in crypto and HTTP libraries necessitates a whole browser update too, although I'd happily jump onto any project where URL handling and networking is fully decoupled from the rendering engine (won't happen because imagine all the ad-blocking possibilities!).
I'd go for XP or Windows 7 instead, it uses the NT kernel and is much, much better than 95 in every way (performance, security, multitasking, etc). Win 95 is still just a glorified DOS shell.
After win 7 the only innovation in windows has been incremental features mostly to upsell Microsoft services.
It is not so much a question of modern or legacy but of intended audience.
The OS(or more specifically the desktop environment) intended for a general audience will be more bland, uniform and legacy than the one made for a smaller more specific audience, perhaps it was made for the sole use of the author and they decided to share..
The general audience will have a preconceived expectation, you might say an intuition, about how the environment works, this mean, that an environment intended for such an audience cannot really have too much advancement or it will drift too far from expectation.
They are different and not mutually exclusive things. Window Maker is a window manager with a NeXTStep-like look. GNUstep is an application framework.
You can use GNUstep with Window Maker (and many do) but you can also use it with KDE, GNOME, XFCE, FVWM, IceWM, JWM or whatever window manager you like. AFAIK GNUstep also has a Wayland backend so you could also use it with Wayland compositors.
Similarly you do not have to use Window Maker with GNUstep or any ObjC runtime or libraries, just use it by itself as a window manager. Personally i do not use GNUstep at all but i use Window Maker.
(note that Window Maker does create/use a GNUstep directory in the home directory but that is a historical artifact and IIRC in recent versions it can be made to use a directory inside .config instead).
160 comments
[ 3.2 ms ] story [ 214 ms ] threadAs much as it's a lightweight DE, we're way past the point of CPU capability to render these basically for free, but it seems to be all over the place
Knowing how to pick your battles is a need in OSS development
Look at where they are and where Gnome is now.
Saddest story in all of open source.
Even today people disable isolation to improve performance even though our desktops are faster than old supercomputers: https://www.microsoft.com/en-us/windows/learning-center/opti...
"Windows 11 security measures include Memory Integrity and Virtual Machine Platform (VMP) to protect against malware, which are features that can also disrupt gaming performance. If you choose to turn these features off before gaming, it can improve your performance and help you focus on the games at hand. Afterwards, it’s important to turn them on again since you are opening your PC up to risks while it’s less protected. For short periods, you might try turning off your Memory Integrity and VMP to see if you notice a difference."
Perhaps in the server world where uptime is critical. After all, that is Linux’s largest market share.
HPE makes a ton of money out of their NonStop line of uncrashable machines.
I find it hilarious that we sharpened monitors so now we have to blur the rendering, because heaven forbid we see a pixel.
You gotta bandlimit your signals or you'll see aliasing. That's just how signal processing works. Imagine if your audio player's output voltage jumped between 16bit levels instead of smoothly transitioning. It would sound horrible. That's how bad jaggies look to people who didn't grow up with slow computers
Color is based on frequency. There's an inherent limit to the range of light colors our eyeballs can process.
> You gotta bandlimit your signals or you'll see aliasing.
When changing sampling rates. If the monitors resolution and the font resolution were identical, then would bandlimiting actually have any effect?
> Imagine if your audio player's output voltage jumped between 16bit levels instead of smoothly transitioning. It would sound horrible.
The brain processes sound logarithmically. Is the same true for vision? I mean, I watch movies at 24 frames per second, and yet, I'm usually incapable of perceiving this.
> That's how bad jaggies look to people who didn't grow up with slow computers
Anecdotally.. but if the computer is experiencing a limit in displaying full resolution data to me, I actually don't mind noticing that fact.
> If the monitors resolution and the font resolution were identical
Fonts are typically infinite resolution because they are small programs that you execute. Also see https://blog.mecheye.net/2012/12/bytecode/
> The brain processes sound logarithmically. Is the same true for vision?
If you're talking about brightness, it's a cube-root curve: https://en.wikipedia.org/wiki/Lightness#Relationship_to_valu...
> I watch movies at 24 frames per second, and yet, I'm usually incapable of perceiving this
Film projectors flash the same image multiple times because humans can easily notice 24fps. The lamp flickers and that's why movies are called "flicks". Good monitors flash each frame for only 1ms for the same reason: https://blurbusters.com/faq/motion-blur-reduction/
Try the UFO test: https://www.testufo.com/. If you genuinely can't see the difference between 30/60/120 Hz, you should get an eye exam because that's not normal.
Vector fonts and vector graphics are two different things. Fonts define an outline. You can programmatically displace points on that outline but you are still limited in the types of outputs you can define due to this restriction and to the overall number of points per glyph the font system allows.
They're pretty far from "infinite resolution" and the errors between screen space and font space are not particularly large and are probably not best understood through signal processing metaphors, was my point.
I didn't even know GNUStep was being actively developed or maintained. I'd love to be able to use GNUStep as my primary workstation environment. Does anybody have any recent experience with attempting such a thing?
People use it with WindowMaker but people can also use it with whatever other desktop environment they're using.
The bane of old X11 environments and UI toolkits is the DPI/resolution of modern screens. Usually the sweet spot for them is around 1600x1200, usable on Full HD, unusable on 2K. Windowmaker and GNUstep included.
I used Windowmaker with GNOME session running in background for years as a main driver, and went KDE Plasma due to the reasons above.
Windowmaker icons are 64x64 and while there might be a way to increase them, dockapps are rendered in 64x64 max. Devs used the display limit to achieve a certain style, such as LCD dockapps. Useful and charming but it's small and unusable at 2K or above.
So the first thing you're going to get yourself wrapped into are the fonts and font sizes in Windowmaker and GNUstep, and you'll never achieve the same look and feel as default on appropriate resolution.
You need to configure the size of icon windows in windowmaker WPrefs, the app then needs then to query the [[[NSApp iconWindow] contentView] bounds] that it was created with. There are almost certainly still some dockapps in existence that don't do that and just use hard coded sizes though. I know that the clock app AClock, implements it correctly.
I'll try messing around Windowmaker in the next few days, this discussion fueled some old interest.
https://github.com/gnustep/libs-back/blob/master/Source/x11/... (-iconSize)
I'm not sure what you find unusable but i'm using Window Maker at 2560x1440 (i assume that is what you mean with 2K) perfectly fine[0].
Though note that the overwhelming majority of monitors out there isn't 2K or greater but 1080p and 768p[1] :-P.
[0] https://i.imgur.com/yaU5OLn.png (my WM setup with a few utilities i made in a custom toolkit that has a WM/NS-like style)
[1] https://data.firefox.com/dashboard/hardware (scroll down to Display Resolution)
Big part of it was GTK2-GNUstep theme which made GTK apps feel "native" and there was something for QT too.
Can you put up some screenshots with GTK/QT "modern" apps floating around too?
Also I can't believe you are not finding that text size too small. I have 27" screen, great vision, sitting at a normal distance, everything is just too small. It's not unusable in strict sense but if you have problems with tiny text on big screen it would be.
P.S. for firefox stats I think we're mixing apples and oranges, OP asked about "workstation", and those are are worldwide client stats, so you have a lot of laptops and a lot of legacy computers in it
Back when I wrote some small apps, it was very easy to target Mac with the GNUstep makefile package. That could build on Mac without any extra work on the build side. I would sprinkle a lot with #ifdef __APPLE__ when the APIs differ, on a case by case basis. A lot of things (most?) work on both without modification, it just depends how new the API is.
Building for both GNUstep and macOS is difficult. The problem is, macOS wants you to use Xcode and GNUstep wants you to use their weird build system. In order to build software that is compatible with both GNUstep and macOS you will either need need to have two parallel build systems (one GNUmakefile and one Xcode project) or use a custom build system.
Personally I think GNUstep's build system is stupid, and I don't like using Xcode, so I lean more towards a custom build system. Sounds insane I know but it really isn't that bad. Compiling and running a Cocoa application on macOS pretty much boils down to this:
I don't remember how to do it for GNUstep. It's been a few years. Their GNUmakefile thing is REALLY weird, they have all these Makefile macros you need to import and they try to abstract all of this stuff away. Using Makefile macros. It's horrible. I asked ChatGPT and it generated this: I would make a basic GNUmakefile, then run it with `V=1` (or `VERBOSE=1`? i forgot the name of the environment variable) to get the actual terminal commands its running, extract those, put those in your one-liner custom build script and be done with ithttps://github.com/gnustep/libs-xcode
MPWFoundation, Objective-S and related all build on both macOS and GNUstep without buildtool. Once you have the GNUmakefiles they are not that hard to keep in sync.
https://gitlab.com/mpwmo/ObjectiveSmalltalk/-/blob/master/GN...
https://gitlab.com/mpwmo/MPWFoundation/-/blob/master/GNUmake...
https://gitlab.com/mpwmo/MPWFoundation/-/tree/master/GNUstep...
But I was looking for both things. Is there a tool to warn against partial or not implemented functionality that needs to be avoided?
Works perfectly fine, and I don't see how some external tool attempting to give a guess at this would be easier, never mind as accurate.
PikoPixel was initially written for Mac, and GNUstep saved me a huge amount of work from having to completely rewrite it for Linux/BSD.
However, it was still a significant effort:
* GNUstep's an implementation of the Cocoa framework only, it doesn't include any other macOS frameworks.
* The same source-code & UI resources can produce different behaviors & visuals between the different platforms. This is due to different Cocoa implementations, some missing functionality on GNUstep, different system fonts, different window managers & desktop environments (Linux/BSD have many of them, each with their own quirks), etc.
A cross-platform Mac/GNUstep app is definitely doable - PikoPixel is now available in many Linux distro repositories (Ubuntu Studio even preinstalls it as a default graphics app) - but expect to spend significant effort correcting platform differences (depending on the app).
I'd suggest getting started by spinning up a VM, installing a GNUstep dev environment on it, then downloading some GNUstep app sources & building them.
PikoPixel's homepage links some build scripts for Debian & Fedora that will install both a GNUstep dev environment and PikoPixel: https://twilightedge.com/mac/pikopixel/
You can also browse PikoPixel's sources online at the Debian GNUstep team's mirror repository: https://salsa.debian.org/gnustep-team/pikopixel.app
(Note: PikoPixel's fixes & workarounds for the platform differences on GNUstep are found in the various source files that begin with PPGNUstepGlue*).
This alone would be a nice standalone open source project that one could extend to offer more coverage.
Why is it that every OSS desktop has to look like a demo from the 70’s?
There's always the form vs function debate but it's a shame that more doesn't manage to have both form and function if the respective specialists could coordinate
Yeah, no. I don't think you use macOS/win at all if you say stuff like that. It feels and always has felt rough around the edges.
I genuinely like and dislike most OS UIs I've tried. They all have things that irk me. While windows settings has gotten more consistent, it's also all the more painful when you had gotten used to the "old way" of doing things and where to look. If MS executives could just get TF out of their own way on some of the stupidity and force-feeding.
Mac, just feels a bit dated at this point, but the touchpad integration across all apps is great. Not to mention the macbook touchpads being second to none in terms of usability.
Linux, I can shift to almost exactly what I want. There are rough edges and spots you cannot reach via UI, but it mostly works without issue. Been using Budgie as my DE for over a year, fairly customized and like it a lot.
https://i.stack.imgur.com/JDDku.png
To my knowledge, modern GNOME does not have this which is sad. There's this webpage instead:
https://help.gnome.org/users/gnome-help/stable/shell-keyboar...
"Half-maximizing" windows with Super+Left and Super+Right is very handy when I need to see things side-by-side.
Moving windows from one screen to another by pressing Super and doing drag-and-drop, and moving windows across workspaces with Shift+Super+PgUp and Shift+Super+PgDown are also convenient.
In my opinion GNOME and GTK apps generally get those details more "correct", though GNOME 3 and up goes way overboard on padding. Strip that padding down with a theme and its design is solid though, and Cinnamon, XFCE, and MATE get these right out of the box with no modifications necessary.
Because you haven't sent the patches that would make it prettier (e.g. ones that would make it as pretty as, say, Mac OS).
http://etoileos.com/etoile/
If GNUstep gains traction, there will almost certainly be a project to create a modern desktop. I personally like the NeXTSTEP UI, but I wouldn't mind something new.
I think that's backwards. They need to create a project for a modern desktop to gain traction.
You need some unixporn[0] in your life.
Also people have different tastes and preferences and like the NeXTStep or Win95 or OS/2 or BeOS or Classic Mac or whatever look.
[0] https://www.reddit.com/r/unixporn/
Can I use the new features that Apple added in cross platform projects or open source environment like this?
I loved Objective-C very much (yes, really) and I'd like to continue using it after Apple phases it out
The problem is the frameworks (Foundation, UIKit, AppKit, etc) are closed source. So you either need to create your own frameworks or use something like GNUstep.
https://news.ycombinator.com/item?id=35914330
It’s going to take them a long time to covert it. So I don’t see them dropping it anytime soon.
It’s not recommend for new code (in Apple land) and they’re already starting to make features Swift-only.
But they won’t stop shipping it any time soon.
That's a real shame because FFI language bindings to Objective-C frameworks are amazingly simple to do with Objective-C. You basically create low-level C ABI bindings to objc_msgSend and about 40 other routines (e.g. class_getName). The latter bindings are principally for introspecting the class hierarchy and acquiring references to opaque class and method implementation pointers. method_getTypeEncoding returns a text-encoded type signature for a method. And objc_msgSend itself is a magical variable argument function for invoking arbitrary methods on arbitrary objects (including classes, which are objects themselves).
With that small set of C ABI bindings you can generate strongly typed bindings to all the many thousands of Objective-C framework and library interfaces, system and third-party. I did this for Lua and it works beautifully. And you can just as easily define new classes and methods and wire them up to the host language (Lua, Python, Java, Rust, etc), though I haven't needed to do that just yet. In my case this is all done dynamically at runtime, except for the ~40 required static C function bindings.
The only difficult part was binding objc_msgSend. You could use libffi, but in my case I wrote a script to statically generate a permutation of Lua/C binding functions with up to 6 arguments, any 2 of which could be doubles instead of scalars, and either a scalar or double return value. Atop those bindings sits a small Lua library which, using the other ~40 Lua/C function bindings, implements a type-safe bridge for the entire macOS Objective-C platform, GUI frameworks and all, modulo a small number of niche edge cases (e.g. IIRC there's a special Objective-C ABI for directly returning small structures which my objc_msgSend bindings don't implement, but I haven't run into those cases and my Lua bridge code would throw an error if I tried).
Because Objective-C itself uses reference counting, it plays well with any GC environment or lack thereof.
I'm sure Swift is a nice language, but there are many nice languages, and Objective-C makes language interoperability downright dreamy.
I originally had no inkling that Objective-C was so easy to write bindings for. I was vaguely familiar with its message passing architecture, but didn't appreciate the low-level implications--the potential ABI power (not just API) that came from foregoing static linking. I started my app hoping to not have to write many bindings to macOS interfaces, partly because I wanted to port it to Windows and Linux. I'm using the Yue GUI toolkit, which made it easy to bring up a simple Lua app without having to understand anything about platform GUI frameworks.[1] I wrote a whole slew of Core Foundation (plain C) Lua bindings for little things like property file integration, hoping to avoid dealing with Cocoa APIs. But eventually all the little limitations of Yue (many now resolved) and my need for deeper desktop integration forced my hand.[2]
My Lua bridge is definitely not the first, but most (all?) such projects are dead or dormant. Some might still be usable with some tweaking; I don't think out-of-the-box, though, which IIRC helped push me toward writing my own. My app is currently closed source. I've open source'd parts of it already (e.g. early version of a suite of LPeg parsers for X.509-based formats, posted to the Lua mailing list), but my Lua/Objective-C bridge is spread across several files (e.g. the objc_msgSend thunk permutation and code generator) and not something that can be easily dumped into a standalone form without a little refactoring. If I have the opportunity to do so, I may in the future. I just don't like publicly releasing anything that isn't usable out of the box. But if you contact me by e-mail I'd be happy to share the code: william@25thandClement.com or william@keymux.com.
[1] Yue also has JavaScript bindings, and both sets of bindings rely on a shared C++ framework, so Yue provides equal treatment to C++, JavaScript, and Lua applications.
[2] My app, KeyMux, is for integrating common open source toolchains and work flows with hardware-protected RSA and ECC keys, including the Apple T2 Secure Enclave, for which I had to write static C bindings to Apple's Security framework, the low-level public interfaces to which are straight C interfaces. So in truth I would have had to write Core Foundation bindings one way or another as Security heavily uses CFArray, CFDictionary, CFNumber, and CFString. But those bindings probably would have been much simpler and more basic if I knew I would be able to lean on the Objective-C frameworks (e.g. Foundation, AppKit) for other desktop integration tasks. All of this--the whole world of desktop GUI programming, not just Objective-C--was new territory for me, so at least I picked up a wealth of knowledge on my circuitous journey.
Yes as part of the GNUStep project [1]. You can compile Objective-C with Clang for any platform, including Windows, and link with the GNUStep Obj-C runtime. The big problem is outside of GNUStep and macOS you won't have any frameworks - not even NSString.
> I loved Objective-C very much (yes, really) and I'd like to continue using it after Apple phases it out
You're not alone. Unlike C++, Obj-C was a reasonable OO extension to C. It's a shame the language never received more love.
[1] https://github.com/gnustep/libobjc2
I was beginning to really feel my age that no one had made that reference.
(It's from the movie "Treasure of the Sierra Madre", which is worth checking out!)
"Badgers? Badgers? We don't need no stinking badgers!"
The underlying architecture of NeXT was largely adopted into OS X and iOS.
The GUI appearance evokes nostalgia for those that used it (the very first web browser was written within NeXT).
https://en.wikipedia.org/wiki/NeXTSTEP
FWIW GNUstep is themable so it should be possible to customize it. Though i'm not aware of any that follows modern trends, but at least it is possible to make it kinda sorta like a broken telephone version of early Mac OS X using the Rik theme[0] (the screenshot also seems to be using a custom theme and setup for Window Maker too and judging from the shadows it most likely also uses Compiz as a compositor).
[0] https://github.com/AlessandroSangiuliano/rik.theme
(Its a big reason why I stopped contributing to GNUStep, as the resistance to modernize at least a little bit was large).
End users don’t use operating systems, they’re a burden of security vulnerabilities and compatibility issues.
If I had to round it out, the tech industry as a whole would prefer we all do everything in browsers over the cloud.
Disregarding freedom and privacy, I would prefer things to be that way.
Reliability too. The cloud is 99.9999 reliable until your power, therefore your internet cuts off.
Your local office, or emacs, or whatever, will gladly chug along until the M1's battery drains
Not that Im in a bad neighborhood: I just realized I might be the only one in my block that doesn't have a luxury vehicle. 8 year old Hyundai and 10 year old Golf for me in a sea of Mercs, BMW, Lariats and Lexuses.
Of course, I must be poor. I have a portable, Chinese clone 7000 kW gen that only feeds 6 circuits and sounds like a pneumatic gun. Half my neighbors have full-house automatic, natural gas fed GENERACs.
In practice, even if you managed, say, to port a modern Firefox and all its baggage down to OpenSSL and even GCC to compile it in a mighty for of herculean effort, it would still likely die of a thousand paper cuts anyway because quite a lot of syscalls would be expected to have evolved since.
But other modern codebases will want more modern syscalls without fallbacks and compromises (see those atomic file operations which solve some nasty vulnerabilities for an example).
> video streaming
NeXTStep had NeXTtime, which IIRC was also important in sealing the Apple deal, as Be's big claim to fame was (multi-media) performance, with the for-the-time impressive demo of 4 videos playing simultaneously. Nobody had really thought of it before, but playing 4 videos was also not an issue in NT, so Be-blocked.
https://www.paullynch.org/NeXTSTEP/AppleNeXT.htmld/present.h...
I remember NeXTtime - it was essentially a prototype tech demo that could play some -- only some -- QuickTime movies in a very small window. I find it unlikely that it was significant in the deal. IIRC the Apple tech team wasn't that impressed with the interrupt latency of Mach, which later had to be fixed at Apple out of necessity.
I recently (3 years ago) started developing on iOS and MacOS.
I learnt programming on Mac Plus in the late 1980s early 1990s
Wow, what a change. In the 1988-92 Macs were the bees knees for development. Really good.
Now, definitely not. I regularly switch between Mac, Linux, and Windows for development.
Development on iOS and MacOS is deeply painful. The tools are flash, lots of features, and they mostly work, that is they do not really work.
Apple took US$99 from me for a license to write software for their machines, and now I cannot run my software on iOS unless I am connected to the Internet, so they can "verify" my license. (I never got the license - another sad story)
Many times, regularly, the "verification" process goes awry and I spend time trying to work out which particular string of gobeldy gook I need to enter n which obscure part of Xcode to get the equipment I (my boss) paid for to do anything other than be dead weight.
The flagship language (Swift) is half arsed. Some bits are OK, but the threading model is from the 1990s dressed in drag. Memory management by reference counting? Golly, how 1990s. Passing class parameters by reference as default, but not struct parameters - say what?
Distributing the software we write to the users that need to use it is immensely painful, not my immediate problem, but I watch people in my firm tear their hair out trying to make it work.
How the mighty have fallen.
Classes are passed by reference.
I still have trauma
Support modern networking?
Support Unicode in all applications?
I don’t remember what other multihead graphics cards existed at that time. For multiple video cards, you again had to reach for Matrox, since they were produced in both PCI and AGP variants and I’m unsure about other brands.
NeXT had full ipv4 support from the start.
Unicode wasn't a thing until after Apple bought them.
One experiment I've done on my own NeXTStation turbo was run equivalent applications on both a NeXT and a modern Intel mac pro. Mathematica, email, Framemaker/affinity publisher all take roughly the same time to load and execute similar tasks.
Yes you can't do 3d, video, or AI on a 33 year old NeXT, and the image files would be smaller, but beyond that you could easily do your day to day work on such a system. It doesn't feel old at all.
I’m not negating your experience and share the same sentiments, but there is also a bit of undeniable progress modern OSes made.
One such bit is high DPI and mixed DPI support (theoretically should be easy peasy with Display PostScript, but somehow I don’t think it would pan out well in practice).
Considering that some M1 laptops didn't support multiple monitors because of the internal USB allocations, it's not like modern Macs don't have such caveats
Now Windows NT, on the other hand...
After win 7 the only innovation in windows has been incremental features mostly to upsell Microsoft services.
The OS(or more specifically the desktop environment) intended for a general audience will be more bland, uniform and legacy than the one made for a smaller more specific audience, perhaps it was made for the sole use of the author and they decided to share..
The general audience will have a preconceived expectation, you might say an intuition, about how the environment works, this mean, that an environment intended for such an audience cannot really have too much advancement or it will drift too far from expectation.
You can use GNUstep with Window Maker (and many do) but you can also use it with KDE, GNOME, XFCE, FVWM, IceWM, JWM or whatever window manager you like. AFAIK GNUstep also has a Wayland backend so you could also use it with Wayland compositors.
Similarly you do not have to use Window Maker with GNUstep or any ObjC runtime or libraries, just use it by itself as a window manager. Personally i do not use GNUstep at all but i use Window Maker.
(note that Window Maker does create/use a GNUstep directory in the home directory but that is a historical artifact and IIRC in recent versions it can be made to use a directory inside .config instead).