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

61–70 of 138 posts

Re: C-Macs – a pure C macOS application

#61

Post by dgellow »

tredre3 wrote: post #52
dgellow wrote: post #49

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

Also, UTF-16 (or WTF-16 as defined by https://simonsapin.github.io/wtf-8/#wtf-16)

Re: C-Macs – a pure C macOS application

#64

Post by cornstalks »

If you want to optimize this (and you enjoy pain), you can eliminate the dependency on objc/* headers and use compiler attributes and link sections to compile your code to the same(ish) assembly that Objective-C compiles to. I don't have a C example on hand, but here's a Rust example that's pretty easy to translate to C: https://github.com/objrs/objrs/blob/master/HOW_IT_WORKS.md

Re: C-Macs – a pure C macOS application

#65

Post by QuercusMax »

tredre3 wrote: post #52
dgellow wrote: post #49

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

I remember ages ago when I was about 12, I got a copy of Turbo C++ for Windows 3.1 for my birthday. (I had only written in Basic before, and wanted to learn a "real" programming language. My dad was a Fortran programming physicist, and had heard that C++ was what everyone was using then-a-days.) I mostly wrote simple console programs, and it came with the Borland ObjectWindows library with a fun GUI builder, but there was a section in the manual talking about how to write directly using the Windows API.

I didn't really understand any of what I was reading, but I typed in the whole basic sample complete with HWNDs and all that nonsense. I can't remember if I could even get it to compile, but the idea of an event-loop was beyond my comprehension as a 12yo. I'm sure if I went back it would make a lot more sense to me, but back in 1994 it seemed like dark magic, especially compared to the much simpler and more understandable OWL components.

Re: C-Macs – a pure C macOS application

#66

Post by saagarjha »

williamcotton wrote: post #60
ryandrake wrote: post #55

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

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!

The runtime knows how to do that already. -[NSApplication run] sets up the runloop to drain events among other things.

Re: C-Macs – a pure C macOS application

#67

Post by astrange »

cancerhacker wrote: post #45
electroly wrote: post #39

Earlier quoted context omitted.

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

Doesn't work anymore, especially because it doesn't support ARC.

Re: C-Macs – a pure C macOS application

#68

Post by saagarjha »

ChrisMarshallNY wrote: post #42
LeoNatan25 wrote: post #37

Earlier quoted context omitted.

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 “NS XXX ” calls).

Wait until you see the NX* APIs ;)

Re: C-Macs – a pure C macOS application

#69

Post by saagarjha »

johnnyjeans wrote: post #56
swatcoder wrote: post #26

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

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

Re: C-Macs – a pure C macOS application

#70

Post by astrange »

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…

Why would you want to manage your own runloop? It's both not interesting and possible to get wrong.
Post reply on HN