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

41–50 of 138 posts

Re: C-Macs – a pure C macOS application

#41

Post by CodeWriter23 »

rankam wrote: post #9
williamcotton wrote: post #8

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

Does this mean that, theoretically, this could lead to the ability to build MacOS apps in higher languages that interoperate well with C such as Python? I know you can build MacOS apps with Python now, but does this potentially improve the experience?

There’s already PyCocoa and pretty sure *Cocoa exists for a variety of languages.

Re: C-Macs – a pure C macOS application

#42

Post by ChrisMarshallNY »

LeoNatan25 wrote: post #37
jonhohle wrote: post #27

Earlier quoted context omitted.

It has, but there was also Carbon until around the Intel transition.

Full Carbon was there until the 64bit transition officially, but much of it remained and still remains until now. For example, Apple only started using AppKit to draw menus in Sonoma; it was Carbon until now.

I think it’s cool that a lot of NextStep stuff is still there (all those “NSXXX” calls).

Re: C-Macs – a pure C macOS application

#44

Post by flohofwoe »

Here's something similar by Garrett Bass:

https://github.com/garettbass/oc

...I also experimented a bit with parsing macOS system headers via clang-ast-dump and then code-generating C and Zig bindings but that didn't get far:

https://github.com/floooh/objc-ast-experiments

...with a bit of effort and maybe using libclang instead of clang-ast-dump that's definitely feasible though.

I guess a similar approach is used by the official C++ bindings for Metal:

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

...also shameless plug: the sokol headers allow to write simple macOS applications (just a Metal canvas in a window) in various non-Apple languages (currently C, C++, Zig, Rust, Odin, Nim):

https://github.com/floooh/sokol

...I'm cheating though and use ObjC under the hood to talk to Cocoa and Metal ;)

Re: C-Macs – a pure C macOS application

#45

Post by cancerhacker »

electroly wrote: post #39
anamexis wrote: post #36

Earlier quoted context omitted.

The OP says it is Cocoa-less in the readme, is that not true?

It's not. Open up any of the .c files and you'll see lots of references to Cocoa. One of the comments refers to Cocoa by name! This is using objc_msgSend to call into Cocoa. You'd have to squint your eyes pretty hard for the claim in the readme to be true. What it doesn't have is Objective-C code, which is different than not having Cocoa.

check out the clang objc rewriter - basically c++front for objc. https://www.jviotti.com/2023/12/01/understanding-objective-c...

Re: C-Macs – a pure C macOS application

#46

Post by flohofwoe »

rankam wrote: post #9
williamcotton wrote: post #8

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

Does this mean that, theoretically, this could lead to the ability to build MacOS apps in higher languages that interoperate well with C such as Python? I know you can build MacOS apps with Python now, but does this potentially improve the experience?

You can already do this in the traditional way by building an ObjC shim which exposes a C API. The solution shown here just skips ObjC and talks directly to the ObjC runtime (which has a C API but is not as convenient to use as doing the same thing in ObjC or Swift).

In a highly simplified way you can think of Objective-C as preprocessor which replaces the ObjC syntax sugar with C function calls into the ObjC runtime (it's not how it works in reality, but how it could work).

Re: C-Macs – a pure C macOS application

#48

Post by ranger_danger »

actionfromafar wrote: post #19
williamcotton wrote: post #16

Earlier quoted context omitted.

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…

In most jurisdictions almost everything is under copyright, until it expires. (Which is approximately right before the heat death of the universe, after Disney get their way. Or 70 years after the authors death, or something like that.)

https://arstechnica.com/tech-policy/2021/04/how-the-supreme-...

Re: C-Macs – a pure C macOS application

#49

Post by dgellow »

I 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.microsoft.com/en-us/windows/win32/learnwin32/y...

Re: C-Macs – a pure C macOS application

#50

Post by mycall »

williamcotton wrote: post #8
9dev wrote: post #6

As 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.

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.

> officially supported languages for the MacOS APIs

How often do you need to get support assistance from Apple? Just do what you want. If it means using Obj-C or Swift for ease, do that. If it means integrating another language, do that.

Post reply on HN