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

111–120 of 138 posts

Re: C-Macs – a pure C macOS application

#111

Post by AceJohnny2 »

extraduder_ire wrote: post #99
AceJohnny2 wrote: post #92

Earlier quoted context omitted.

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?

I suppose the difficulty of proving that, short of demanding source code, helped prevent it from happening.

Re: C-Macs – a pure C macOS application

#112

Post by johnnyjeans »

astrange wrote: post #73
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…

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

> Sloppiness /is/ Unix design, that's intentional. It's called "worse is better".

That's missing the point. It's about simplicity through well designed abstraction. Unix was a runaway game engine that became Bell Lab's standard for talking to computers because it was vastly simpler than the poorly engineered MULTICS and friends. That's why it won.

> On the other hand, nobody uses Plan9

I use Plan 9 every day. I'm replying to you from inside abaco. I run a tablet with it, have a whole network of machines (most of them virtual). I'm in the middle of a project to create a light fixture I can talk to in 9p. It's not the first DIY IoT thing I've made to control over a Plan 9 terminal. My grid also runs my email, my file servers, an LLM chatbot (though this is actually served from a Linux machine via Inferno tsk tsk.) The only reason I use anything else is due to my job requiring me to ship a product in C++ and OpenGL. For something that doesn't "actually work", I find that it actually works excellently.

Re: C-Macs – a pure C macOS application

#113

Post by pjmlp »

Koshkin wrote: post #98
ndiddy wrote: post #97

Earlier quoted context omitted.

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

Even then, MFC and C++/CX were the only productive ways to use it from Microsoft SDKs.

.NET isn't as convenient as VB 6 was, fully embracing COM as the VBX replacement model, technically introduced in VB5, but still some stuff was lacking.

Then there is Delphi and C++ Builder.

It beat me that having doubled down on COM since how Longhorn went down, and Windows team getting their way doing avoiding .NET to take over, they hardly managed to create nice tooling as the competition.

Editing IDL files with a Notepad like experience, manually merging generated code, and a couple of frameworks that barely go beyond yet another way to do AddRef/Release/QueryInterface and aggregation.

Meanwhile D-BUS, XPC and AIDL, provide much better dev experience.

Pity that Borland products are kind of tainted due to mismanagement decisions, otherwise maybe fixing COM dev experience would already been seriously taken by VS team.

Ah, nowadays WIL is probably the best approach when having only to consume COM.

https://github.com/microsoft/wil

Re: C-Macs – a pure C macOS application

#114

Post by pjmlp »

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…

Nah, this was already like this at NeXT.

The whole UNIX infrastructure was to get into the DoJ stuff that required POSIX compliance.

Just like with Microsoft, the approach was to allow UNIX software to come into NeXTSTEP, not to be created in NeXTSTEP and then leave it for other UNIX vendors.

All the relevant programs in NeXTSTEP used Objective-C, and even the drivers were written in Objective-C.

Apple was clever marketing OS X to the Desktop Linux crowd, that actually only cared about a POSIX experience and not so much about Linux itself.

Many of them helped Apple get out of red, into the company it is today.

This is how Microsoft finally understood how bad they did with POSIX on Windows NT linage, and out of Project Astoria ashes, WSL was born.

Had Microsoft actually kept POSIX subsystem up to date, and in parity with Win32 subsystem, and most likely Linux would never taken off, as everyone would have had their proper POSIX right there, without needing to look elsewhere.

Re: C-Macs – a pure C macOS application

#115

Post by pjmlp »

musicale wrote: post #107
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/

Kind of, yes there is, however it is suboptimal versus Objective-C or the Swift bindings.

It is mostly for engine writers to plug into Metal, instead of dealing directly with Objective-C++.

Re: C-Macs – a pure C macOS application

#116

Post by cellularmitosis »

lapcat wrote: post #78

This app uses objc_msgSend, which feels a lot like cheating, but if you simply want to avoid using nibs (while still using Objective-C or Swift), check out my NiblessMenu project and my "Working without a nib" blog series. https://github.com/lapcat/NiblessMenu https://lapcatsoftware.com/articles/working-without-a-nib-pa...

I just Ed to say thank you for keeping your nibless posts from 2007 online. Handy for those of us doing a bit of retro computing on Tiger and Leopard. https://forums.macrumors.com/threads/developing-for-tiger-an...

Re: C-Macs – a pure C macOS application

#117

Post by jsjohnst »

extraduder_ire wrote: post #99
AceJohnny2 wrote: post #92

Earlier quoted context omitted.

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?

> Is there any way to enforce that in a way that can't be worked around with a shim?

You can’t definitively prove something was written in Objective-C or Swift, but you can often definitively prove something was not written in either pretty easily just by looking at the assembly.

Re: C-Macs – a pure C macOS application

#118

Post by SpaghettiCthulu »

shrimp_emoji wrote: post #76
wil421 wrote: post #57

Earlier quoted context omitted.

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.

Beats using Java Think of it as exercise: it sucks up front but you won't end up an obese diabetic on the WALL-E ship later.

Java is only a nightmare when you have to follow corporate decade-old "best" practices

Re: C-Macs – a pure C macOS application

#119

Post by bheadmaster »

SpaghettiCthulu wrote: post #118
shrimp_emoji wrote: post #76

Earlier quoted context omitted.

Beats using Java Think of it as exercise: it sucks up front but you won't end up an obese diabetic on the WALL-E ship later.

Java is only a nightmare when you have to follow corporate decade-old "best" practices

In my experience, Java is a nightmare the moment you try to do anything beyond what C++ can (easily) do.

Re: C-Macs – a pure C macOS application

#120

Post by worewood »

johnnyjeans wrote: post #112
astrange wrote: post #73

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

> Sloppiness /is/ Unix design, that's intentional. It's called "worse is better". That's missing the point. It's about simplicity through well designed abstraction. Unix was a runaway game engine that became Bell Lab's standard for talking to computers because it was vastly simpler than the poorly engineered MULTICS and friends. That's why it won. > On the other hand, nobody uses Plan9 I use Plan 9 every day. I'm rep…

Hyperbole; "nobody" means an insignificant amount of people.
Post reply on HN