Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C-Macs – a pure C macOS application

github.com

Post reply on HN
Print view View original

101–110 of 138 posts

Re: C-Macs – a pure C macOS application

#101

Post by billforsternz »

ryandrake wrote: post #55
ChrisMarshallNY wrote: post #10

Earlier 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…

I agree. I recall the Windows API and the official Hello World. I'm sure they could have got to the same place in a slightly reorganised way that kept main() as the starting point and interfaced with the event loop and the entire windowing system via some API calls that hid the cruddiest parts of the boilerplate crud (apt phrasing, thank you) away in headers and libraries. Then progressively reveal the details when they're really necessary for more elaborate applications.

Re: C-Macs – a pure C macOS application

#102

Post by mattl »

williamcotton wrote: post #16
actionfromafar wrote: post #13

Earlier quoted context omitted.

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 open source but it is still under copyright. There are notices in the source file: https://github.com/CodaFi/C-Macs/blob/master/CMacs/View.c#L5... I would definitely ask permission and encourage the author to change the license before using this code. Since API calls are purely functional and not covered by copyright you can mimic the behavior here but you'll need to rewrite everything from scratch, notably the…

I’d call it source available not open source. It doesn’t meet the open source definition.

Re: C-Macs – a pure C macOS application

#103

Post by eyesee »

Reminds me of an app I built ~20 years ago now.

We wanted a cross-platform C++ layer and native Cocoa front end. Objective C++ wasn’t a thing then, and having built a plain C shim previously I didn’t want to repeat the experience.

We built our own bridge by registering our C++ classes with the Obj-C runtime, generating selectors for all the methods so you could send messages to (carefully constructed) C++ objects using Obj-C syntax, or even subclass from C++ to Obj-C.

It was a pretty neat trick, but would’ve been difficult to port to the Obj-C 2 runtime.

Re: C-Macs – a pure C macOS application

#105

Post by userbinator »

Uses under 1.5 MB of memory at any one time (most of it is used for drawing the window).

Unfortunately there is no screenshot and I have no access to a Mac at the moment, but if View.c is where things actually happen, that is a huge amount of memory just for a (resizeable?) window with a little filled rectangle in it. The memory usage of a trivial app like this should be measured in kilobytes.

Comparing applications written in the same language across platforms is IMHO a good gauge of their relative efficiency. From what I've seen, Win32 and Linux (Xlib) are pretty close but Mac is clearly very "think different". I'm sure the liberal use of string constants here doesn't help either.

Here's a related interesting comparison: https://zserge.com/posts/fenster/

Re: C-Macs – a pure C macOS application

#107

Post by musicale »

JKCalhoun wrote: post #15

I did a straight C++ app for MacOS but 1) I used SDL2 and 2) it was a full-screen game so no Cocoa UI needed. It was kind of fun though in a retro-computing way. (I'm a big fan of SDL now.)

Looks like there's a C++ interface to Metal as well.

https://developer.apple.com/metal/cpp/

Re: C-Macs – a pure C macOS application

#109

Post by quelsolaar »

We used the same technique to port our C applications to Apple platforms, but to do so we wrote an automated tool that created a C wrapper for any cocoa API we need. It works on all current Apple platforms we have tried it on iOS,iPadOS, and Apple Silicon Macs.

Its open source:

https://felixk15.github.io/posts/c_ocoa/

Re: C-Macs – a pure C macOS application

#110

Post by johnnyjeans »

saagarjha wrote: post #69
johnnyjeans wrote: post #56

Earlier quoted context omitted.

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…

App bundles have no fixed layout. How would rpaths work if you didn’t specify them yourself?

They do if you want them to be signed.
Post reply on HN