It would be nice to have something like this except for Metal. I'm unsure why Apple made Metal an Objective-C API when C + Core Foundation would suffice. One big advantage of a C API is it's easy to interop with other programming languages.
C-Macs – a pure C macOS application
91–100 of 138 posts
Re: C-Macs – a pure C macOS application
#92It would be nice to have something like this except for Metal. I'm unsure why Apple made Metal an Objective-C API when C + Core Foundation would suffice. One big advantage of a C API is it's easy to interop with other programming languages.
Apple is opinionated about which languages should be used on their platforms, and they enforce it with these kinds of decisions.
For example, there was a time where Steve Jobs threatened to forbid iPhone apps not written in Obj-C, which would have destroyed the cross-platform ecosystem, at Apple's expense. Luckily, he was talked down from being that extreme.
Re: C-Macs – a pure C macOS application
#93Re: C-Macs – a pure C macOS application
#94Earlier 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…
> 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 st…
Oh wow, employed since NeXT?
(There needs to be an "Apple/NeXT long-hauler oral history" or something. Chris Espinosa, hired 1976, is still around...)
Re: C-Macs – a pure C macOS application
#95Earlier quoted context omitted.
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.
Is there example how to do that on mac. Just happy to have an old emu ibm 5100 sun x program. Wonder I need to boot up a vm or can try squartz …
Re: C-Macs – a pure C macOS application
#96Earlier 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.)
Actually Micky is free.
Re: C-Macs – a pure C macOS application
#97I 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…
Win32 is straightforward and easy to use until you get to COM stuff: https://learn.microsoft.com/en-us/windows/win32/shell/common...
Re: C-Macs – a pure C macOS application
#98Earlier quoted context omitted.
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…
Win32 is straightforward and easy to use until you get to COM stuff: https://learn.microsoft.com/en-us/windows/win32/shell/common...
Yes, for COM programming you better switch to C++.
Re: C-Macs – a pure C macOS application
#99It would be nice to have something like this except for Metal. I'm unsure why Apple made Metal an Objective-C API when C + Core Foundation would suffice. One big advantage of a C API is it's easy to interop with other programming languages.
Apple is opinionated about which languages should be used on their platforms, and they enforce it with these kinds of decisions. For example, there was a time where Steve Jobs threatened to forbid iPhone apps not written in Obj-C, which would have destroyed the cross-platform ecosystem, at Apple's expense. Luckily, he was talked down from being that extreme.
Is there any way to enforce that in a way that can't be worked around with a shim? Demanding source code? Looking for signs of other languages in the binary and not allowing them in the appstore if detected?
Re: C-Macs – a pure C macOS application
#100Earlier quoted context omitted.
> 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 st…
Oh wow, employed since NeXT? (There needs to be an "Apple/NeXT long-hauler oral history" or something. Chris Espinosa, hired 1976, is still around...)
Avie Tevanian and Jon Rubenstein both have oral histories on the Computer History Museum website/YouTube.