Draw a line through this 12+-year-old effort from Robert Widmann and his 8-year-old exercise in type-lifting Swift [1] and ask yourself: what is he doing now at Apple? [1] https://github.com/typelift/Swiftz
You can peek at his GitHub
C-Macs – a pure C macOS application
71–80 of 138 posts
Re: C-Macs – a pure C macOS application
#72For an iOS attempt, I've often gone back to this wonderful StackOverflow post: https://stackoverflow.com/a/10289913
Re: C-Macs – a pure C macOS application
#73Earlier quoted context omitted.
> why this is significant? Ultimately, because new people keep being born and missed the years where this was pretty common and haven't yet bumped into the corners where it still is. The repo and the SO discussion it was inspired by are themselves 11 years old and seem to be rooted in a new generation of iOS app developers starting to get more deeply curious about the system they're running on and how else it might b…
The funny thing is, Apple themselves seems to have forgotten about the whole BSD-rooted operating system. Anybody who ventures off the beaten path of developing software for a modern Mac will inevitably encounter a lot of cobwebs. One of my favorites: When Apple implemented app bundles, they never updated dyld's search paths to be aware of the app bundle directory structure, meaning you have to manually patch your rp…
> When Apple implemented app bundles, they never updated dyld's search paths to be aware of the app bundle directory structure, meaning you have to manually patch your rpaths.
Typically things like this have binary compatibility reasons. (It wouldn't be because they forgot, actually I happen to know the same person has worked on dyld since the 90s.)
> but it's one of many very sloppy things I noticed coming from a strong Unix background to Mac
Funny thing to complain about. Sloppiness /is/ Unix design, that's intentional. It's called "worse is better".
On the other hand, nobody uses Plan9 because it's too well-designed to actually work.
Re: C-Macs – a pure C macOS application
#74As someone with no experience in native application development, could someone explain to me why this is significant? I have a rough idea, but I would like to understand it properly.
I guess it's normally impossible to write a GUI application for mac os without objective-c libraries doing the talking to the OS, but what do I know.
You can write one in X11 if you like, if you make people install Xquartz.
Re: C-Macs – a pure C macOS application
#75Crazy that this has to be a thing .. Why does Objective C even exist anyways??
Because Brad Cox liked Smalltalk.
Re: C-Macs – a pure C macOS application
#76> A little bit of this also has to do to stick it to all those Luddites on the internet who post "that's impossible" or "you're doing it wrong" to Stack Overflow questions... Requesting permissions in the JNI "oh you have to do that in Java" or other dumb stuff like that. I am completely uninterested in your opinions of what is or is not possible. This is computer science. There aren't restrictions. I can do anything…
I like this guys spirit. Once I had to pick up old code from a guy with this spirit and it was f-ing horrible.
Beats using Java
Think of it as exercise: it sucks up front but you won't end up an obese diabetic on the WALL-E ship later.
Re: C-Macs – a pure C macOS application
#77Earlier quoted context omitted.
I knew this was possible, but I had never actually seen it implemented before. And to think, the project is over 10 years old! When I first started programming Cocoa, I was always kind of miffed that the happy-path was: "Use Objective-C and main() should just hand-off the reigns to NSApplicationMain()". Kind of like the happy-path on Windows is "WinMain plus a bunch of boilerplate crud". It's always felt somehow vagu…
Why would you want to manage your own runloop? It's both not interesting and possible to get wrong.
Sometimes there are conflicting things you need to do in the same main thread.
Re: C-Macs – a pure C macOS application
#78This app uses objc_msgSend, which feels a lot like cheating, but if you simply want to avoid using nibs (while still using Objective-C or Swift), check out my NiblessMenu project and my "Working without a nib" blog series.
https://github.com/lapcat/NiblessMenu
https://lapcatsoftware.com/articles/working-without-a-nib-pa...
Re: C-Macs – a pure C macOS application
#79Earlier quoted context omitted.
> why this is significant? Ultimately, because new people keep being born and missed the years where this was pretty common and haven't yet bumped into the corners where it still is. The repo and the SO discussion it was inspired by are themselves 11 years old and seem to be rooted in a new generation of iOS app developers starting to get more deeply curious about the system they're running on and how else it might b…
The funny thing is, Apple themselves seems to have forgotten about the whole BSD-rooted operating system. Anybody who ventures off the beaten path of developing software for a modern Mac will inevitably encounter a lot of cobwebs. One of my favorites: When Apple implemented app bundles, they never updated dyld's search paths to be aware of the app bundle directory structure, meaning you have to manually patch your rp…
> I always find it curious that people still tout Mac as this kind of "Super Polished Desktop/Workstation Unix" and often cite the Unix certification
I've always understood people to mean that it's a polished desktop operating system (though that's becoming increasingly questionable these days) that also happens to run the same CLI stuff they're used to using on Linux servers.
Pre-WSL just that was a pretty nice selling point by itself.