Crazy that this has to be a thing .. Why does Objective C even exist anyways??
C-Macs – a pure C macOS application
51–60 of 138 posts
Re: C-Macs – a pure C macOS application
#52I found this repo while looking for an equivalent to Win32 hello world[0] as a learning exercise during a long flight (with my work MacBook instead of my personal Windows machines). That's something I really like about Windows APIs — I can pick a new programming language I want to play with, as long as there is a way to interface with C I can try to port the Win32 hello world then play around. 0: https://learn.micros…
The WIN32 API is somewhat ugly. I hate how all types are capitalized and their short abbreviations in arguments are sometimes weird. I hate how they have their own version of lots of standard C types that you have to be careful about (they weren't standard at the time, to be fair).
But it's quite straightforward and easy to use. Any language that has FFI can call into it and build GUI apps, I've made a windowed Hello World in PHP with it.
And it has been that way for 30+ years at this point. It's quite remarkable, really!
Re: C-Macs – a pure C macOS application
#53Draw 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?
Re: C-Macs – a pure C macOS application
#54Very nice. In similar fashion, a few years back I set out to create Wuhoo.
Wuhoo loosely stands for W indows U sing H eaders O nly. It is an attempt to create a single-header library (in the spirit of STB) for graphics related window management, compatible with both C and C++.
It works on Windows, Linux and Mac.
Re: C-Macs – a pure C macOS application
#55Earlier quoted context omitted.
MacOS apps are typically written in either Objective-C or Swift as these are the officially supported languages for the MacOS APIs. The code in this template is interfacing with the Objective-C runtime but with pure C.
That has always been possible. Also, under the ObjC layer, is good ol' ANSI C (FreeBSD Unix). There's a number of apps that run on modern Macs, that were written in C, but it is unusual to see ones that leverage the GUI. That said, it's possible to walk from Boston to Portland (OR), but I'd rather take a plane.
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 vaguely "correct" to have main() be your actual application entry point and have it manage whatever main loop you need yourself. I see that this project doesn't actually quite get there either. It's the same kind of voodoo: boilerplate code, and then cmacs_void_msgSend(NSApp, sel_getUid("run")); hands over the reigns.
Re: C-Macs – a pure C macOS application
#56As 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.
> 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 rpaths. Not a huge deal, and one that's hidden from you if you only ever know xcode, but it's one of many very sloppy things I noticed coming from a strong Unix background to Mac. There's a lot of really weird incongruence where the deeper you go into the system, the more everything feels covered in dust and neglected. I was always sold on Macs having really great top-to-bottom integration and have all the polish and attention to detail you can expect out of a corporate Unix-like, but that's not what I found. It's more like a really shiny superstructure bolted on top of an ancient, rust-eaten BSD. Don't get me started on how a lot of the "newer" stuff at that low level tends to be some of the absolute worst takes on a concept. The "App Sandbox" might be the most disgusting, slap-dash design for process isolation I've ever seen bolted onto a kernel.
I get Apple's target market is quite literally the opposite kind of user that I am. That being said, 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. It feels like the more you try to use a Mac like you would any other Unix machine, the more you have to fight it. Often it doesn't feel any different to trying to wrangle Windows with WSL. I had less hiccups and trip-ups learning Plan 9 than I did coming to terms with macOS.
Re: C-Macs – a pure C macOS application
#57> 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.
Re: C-Macs – a pure C macOS application
#58No license typically means copyright with all rights reserved in the U.S. Perhaps you want to release this into the public domain (see SQLite)?
I’d say the license is: “ Use it at your own risk, and don't blame me if anything bad happens. Oh, and if you extend it, make sure there isn't any Objective-C in it!” I’d classify it as Open Source.
It’s definitely not Open Source with that Objective-C restriction. Though it does fit the attitude of the project.
Re: C-Macs – a pure C macOS application
#59> 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.
I love this project (from 2014?) and perhaps my favorite part other than the f-u of the whole thing is the commit message "complete refactoring".
Re: C-Macs – a pure C macOS application
#60Earlier quoted context omitted.
That has always been possible. Also, under the ObjC layer, is good ol' ANSI C (FreeBSD Unix). There's a number of apps that run on modern Macs, that were written in C, but it is unusual to see ones that leverage the GUI. That said, it's possible to walk from Boston to Portland (OR), but I'd rather take a plane.
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…
It has to hand over the reigns to the Objective-C runtime to allow for all the messages being passed between objects.
I’m not sure you want to spend your time rewriting what NSApp is doing!