OS X app in plain C

[btrask]

There was a thread the other day where people were talking about languages that were easily interoperable with the "C ABI" (although there is no such thing). Languages listed included C++, Rust, and maybe a few others--but no mention of Objective-C.

The ability to use a high-level, dynamic language (ObjC), C, and even inline assembly in a single source file is unique to Objective-C (at least among the "mainstream" languages), and something I think is often under-appreciated.

One comment on the code here: for message calls returning type 'id' (object type), you don't need to cast the dispatch function. It would make the code much more readable. For other return types, you need a cast, but I'd wrap it in a macro. You could even use a C11 generic macro to handle floating point return values (unfortunately necessary).

[mikeash]

You should still cast the dispatch function even when your return type is id.

For one, C vararg type promotion makes it impossible to pass certain types in as parameters otherwise. For example, you can't pass a float.

It's also easy to make mistakes because of type mismatches. For example, if you pass `42` to a CGFloat parameter, this works fine when you cast msgSend to the right type, but will fail amusingly if you rely on varargs to make it through.

Perhaps most importantly, vararg calls aren't guaranteed to be compatible with a non-vararg target (as most/all methods you call will be), and you'll see this in action on ARM64.

Currently, you can #define OBJC_OLD_DISPATCH_PROTOTYPES 0 to have the compiler enforce this requirement. (This declares the functions to take (void) rather than (id, SEL, ...).) It's likely that Apple will eventually make this the default.

[conradev]

> The ability to use a high-level, dynamic language (ObjC), C, and even inline assembly in a single source file is unique to Objective-C (at least among the "mainstream" languages), and something I think is often under-appreciated.

You can even use C++, too, which is awesome. Putting Objective-C objects in C++ structs "just works" thanks to ARC.

One thing most people don't know is that Objective-C was originally implemented as a precompiler for C.

[themartorana]

I'm going to miss Objective C terribly. It is, hands down, still my favorite language (and ecosystem). It's interoperability with C got me into C. It was insanely powerful and fun.

I know not many people agree with me. I liked the square braces and crazy long function names. I know Swift is decent... It's not the same.

Oh well. Lamenting my path to software engineering doesn't mean much for anyone else. But I really am going to miss it.

[radarsat1]

So I will bite. Why does the C ABI not exist?

C calling conventions (cdecl, stdcall) and memory layout is pretty well standardized. So I'm not sure what else you could be referring to here.

[avar]

    > The ability to use a high-level, dynamic language (ObjC),
    > C, and even inline assembly in a single source file
    > is unique to Objective-C (at least among the
    > "mainstream" languages)[...]

Well Perl is mainstream enough to be installed on every *nix box, here's examples of assembly and C functions interoperating with Perl in the same source file: https://metacpan.org/pod/distribution/Inline-ASM/ASM.pod#SYN... & https://metacpan.org/pod/distribution/Inline-C/lib/Inline/C....

    > The "C ABI" (although there is no such thing)

Of course if you do this in Perl every one of your calls will need to go through a foreign function interface where Perl's structures are translated back & forth between its idea of datastructures and the OS's idea, avoiding that is what people really mean when they talk about the "C ABI".

[dmytroi]

Thanks for the comment!

On OS X if OBJC_OLD_DISPATCH_PROTOTYPES is not defined, you will get this declaration with zero arguments: void objc_msgSend(void /* id self, SEL op, ... */ ), which is possible to call from C without cast by using implicit function declaration, but this call will fail if compiled as Objective-C code with error "too many arguments to function call", I've decided to write in a style that compiles as C and Objective-C code.

PS. Would be nice to be able to use functions from clang Objective-C runtime [1], but for some reason they are not exposed in the public headers.

- [1] http://clang.llvm.org/docs/AutomaticReferenceCounting.html#r...

[mintplant]

Haskell has support for inline C [1] and inline Objective-C [2] implemented as libraries.

[1] https://github.com/fpco/inline-c/blob/master/README.md

[2] https://hackage.haskell.org/package/language-c-inline

[gumby]

SVR4 specified standard-conformant calling conventions (stack layout, register use etc). IIRC VMS went one "better" and tried to specify a standard calling convention that was supposed to apply to all programs (sadly, there's more to interoperability than calling convention).

[eridius]

You do actually need to cast the dispatch function, because there is no guarantee for all platforms that the ABI for calling a variadic function is the same as the ABI for calling a non-variadic function with the same arguments.

[jheriko]

not really. MS have had this with their C++ for a very long time... easily 20 years +

[justsaysmthng]

Don't do this at home. It looks so ugly because it's dangerous and vice-versa.

If you really want to write (and read) code like this:

id titleString = ((id ()(id, SEL, const char))objc_msgSend)((id)objc_getClass("NSString"), sel_registerName("stringWithUTF8String:"), "sup from C");

((void (*)(id, SEL, id))objc_msgSend)(window, sel_registerName("setTitle:"), titleString);

instead of this

[window setTitle:@"sup"];

then I guess it would be easier to write a Objective-C to C converter (if there isn't one already) and convert your Objective-C app into C for added coolness. I

[dmytroi]

One practical example would be tigr [1] - a cross platform window framework for making simple applications, could be compiled as one header drop-in only lib. You simply cannot make it one header without making calling ObjC runtime from C. Why it's necessary to make it work as one drop-in header? Well it's a new trend in C libraries, which allows using libraries with the least resistance possible, it's like a package manager but nicer - you only have one file! Great example of modern one header libs is probably the famous stb package [2].

- [1] https://bitbucket.org/rmitton/tigr/src

- [2] https://github.com/nothings/stb

[deanCommie]

Seriously, I don't know who's downvoting you. This needs a huge "for academic purposes only disclaimer". Higher level abstractions exist for a reason.

[bdrool]

> a Objective-C to C converter (if there isn't one already)

Incidentally, that's pretty much how the language got started -- as a pre-processor add-on for plain C:

https://en.wikipedia.org/wiki/Objective-C#History

[david-given]

There are Objective-C to C converters.

http://users.telenet.be/stes/compiler.html

However, the dialect this one implements is very different from Apple's, and it doesn't quite produce ANSI C (the generated code does some things which you can usually get away with but are technically illegal, like casting object pointers to function pointers). It's mainly of historical interest now.

[bluedino]

>> I guess it would be easier to write a Objective-C to C converter

That's what the first Obj-C (and C++ compilers) were

[santaclaus]

> For some reason if we run the app from command line than menu is not accesible by mouse at first time

This happens with Qt apps on OS X, as well, and it drives me bonkers. If you launch from the command line you have to command tab away and back for the menu to work

[fit2rule]

Its because of the missing .app bundle and appropriate Info.plist. I just submitted a pull request to fix this - maybe its useful for you too, check it out:

https://github.com/jimon/osx_app_in_plain_c/pull/1

[chillacy]

Strangely this happens on my cocoa app too... but it hasn't always been the case and I've had this thing for about 5 years now, so I suspect that somewhere, something got messed up.

[0x0]

Relevant: "Let's build objc_sendmsg()"

https://www.mikeash.com/pyblog/friday-qa-2012-11-16-lets-bui...

[bdrool]

This is what Objective-C looks like if you "unroll" it to plain C. Not too surprisingly, it's very verbose. Other than as an exercise, there's no reason to do this, particularly given that Objective-C is a strict superset of C.[1]

[1] http://stackoverflow.com/questions/19366134/what-does-object...

[userbinator]

As someone who has done a lot of Win32 programming in plain C, I can recognise some common patterns like an event loop and window creation, but it's quite amazing how much extra "cruft" there is just to deal with what appears to be the contortions of OOP'ing everything. All those string constants are rather surprising too. The interesting thing is, the few times I've had to use a Mac the GUI didn't feel quite as responsive as Windows on the same hardware --- it wasn't jerky/stuttering, just what I'd describe as "smooth but sluggish", and the binaries were noticeably larger, and I now wonder if this increased abstraction and complexity has anything to do with it.

For comparison, a similar Win32 app in plain C:

http://www.winprog.org/tutorial/simple_window.html

X Windows app in plain C:

http://www.paulgriffiths.net/program/c/srcs/helloxsrc.html

...and just for fun, the same simple Win32 app from above in Assembly language:

http://win32assembly.programminghorizon.com/tut3.html

Looking at the code again, if I were forced to write an OS X app in plain C, there would be plenty of macro usage around objc_msgSend.

[barrkel]

Windows is effectively already an OO system; you "override" methods (message codes) in your window procedure, with the base implementation provided by the default window procedure. Windows even uses the terminology of window classes to describe the behaviour of window instances.

Personally, I'd blame UI latency more on a deeper composition stack and rendering sophistication rather than object orientation. Unless you're using late bound method calls for pixel-level drawing primitives, they shouldn't be a significant percentage of the event dispatch loop that turns input into visual results.

[chillacy]

This example is extremely contrived, of course it's going to be a nightmare in C. GUI latency probably has little to do with the overhead of objC message sending and more to do with tuning how things respond for UX purposes. For instance it's well known among gamers that on OSX the mouse has acceleration which makes it smother but less responsive in gaming. I wouldn't be surprised if this carried over to scrolling, animations, etc.

> If I were forced to write an OS X app in plain C, there would be plenty of macro usage around objc_msgSend

You will have re-invented the early versions of Objective C which were all done in the preprocessor :)

[Hydraulix989]

It's amazing and sad for computing that somehow managing to use a sane language to develop software for a very commonly used platform is seen as a serious feat of accomplishment.

[codemonkeymike]

C was not designed to create gui's. So its a feat of accomplishment as opening a bottle with your teeth.

[fbonetti]

C is a sane language?

[ddoolin]

Really? I don't write systems software but it seems most here would not recommend writing in C/C++ unless it's absolutely the best choice.

[sgt]

If you compile it, you'll see that the ObjC executable with no ARC and the C-only executable are exactly the same size stripped. The ObjC version with ARC is 392 bytes bigger.

[conradev]

And introduced in OS X 10.10 is the ability to build an OS X app in pure JavaScript:

http://tylergaw.com/articles/building-osx-apps-with-js

(Atwood's Law in action)

[mcmatterson]

A few years ago I dove into the idea of trying to make a C only iOS app (well actually, it was a quick exploration of how hard it would be to build your own UI kit without using UIKit). The dive bottomed out pretty quickly, as I couldn't figure out a way to access windows without resorting to UIWindow methods, and `UIGraphicsGetCurrentContext()` acted super wonky calling it without 'proper' bootstrapping around it. I was expecting more, given the usual layered approach that Apple takes with their system libraries.

[eyeareque]

I'm not a developer, but does it count when they use objc header files?

#include <objc/objc.h> #include <objc/runtime.h> #include <objc/message.h> #include <objc/NSObjCRuntime.h>

[mayoff]

Richard J. Ross III did it a few years ago for iOS:

http://stackoverflow.com/a/10290255/77567

[tosseraccount]

As a side note: http://stackoverflow.com/questions/525609/use-c-with-cocoa-i...

A commenter at stackoverflow provides some code that "shows how to access Cocoa GUI from pure C/C++ and build a truly functional GUI application"

He notes that you must "link against Cocoa framework".

[sdegutis]

My interest in this comes from wanting to build Objective-C based OSX-UIs using scripting languages that are only embeddable in C, like Lua. When (if?) that day comes, I'll be like a kid in a candy store all over again.

[dmytroi]

I would recommend you to try CodeFlow from celedev [1], it's a dynamically generated Lua binding to Objective-C. Plus a nice editor with hot reloading support and other cool features.

- [1] https://www.celedev.com/en/codeflow/

[icodestuff]

I don't buy it. Yes, the language may be C, but if you're linking the ObjC runtime and frameworks, all you're really avoiding here is the nib-loading machinery.

To be fair, I think that's a perfectly reasonable goal in and of itself - showing how to set up an OS X app "from scratch" is definitely something I'm interested in - but we shouldn't pretend this isn't strongly relying on Objective-C to actually get things done.

EDIT: indeed, the makefile copies main.c to main.m before invoking clang, which means it's using the Objective-C compiler.

What would be much more impressive is if this used only the C Core* frameworks (Core Foundation and Core Graphics in particular) to do the same thing.

[thought_alarm]

Look at the makefile again. It builds five different binaries from the same source file, one of which using a C compiler.

This is no different than writing a COM application in C. Both COM and objc runtimes provide similar dynamic OO services over a plain C API.

[convivialdingo]

I just ran the code through clang (Apple LLVM version 5.1) with no problems. You don't have to rename the source - but perhaps there are issues in other configurations.

clang -framework Foundation -framework OpenGL -framework Cocoa -o test test.c

[hunterwerlla]

So obviously it's impossible to write a linux app in anything pure but C because the kernel is written in C. That makes no sense.

[justinlardinois]

I'm sure the Windows version would be just as bad. Most of the useful parts of the Windows API don't have a C interface, so you have to use COM, which essentially means editing vtable-like structures by hand.

https://en.wikipedia.org/wiki/Component_Object_Model

[userbinator]

I've been programming Windows GUI apps for over a decade. Most of the Windows API, i.e. Win32, is not COM.

I have also used COM from C, and while it's not as pleasant as the pure Win32 API, it doesn't involve the massive amounts of function pointer casting shown here. vtables are involved but they can be defined as C structures, whereas this example seems to show objc_msgSend() returning a very large number of different possible function pointer types.

[seabrookmx]

You wouldn't have to use COM for this at all. You could use the Win32 API directly, which is a C API and would be much less code. In fact I'll link a comment from above that shows this: https://news.ycombinator.com/item?id=11641545

[justinlardinois]

The two replies to my comment both need a response, so I'll make this a sibling.

Looks like I was wrong, and I was working harder when I wrote Windows C programs than I needed to. The Windows API documentation is sort of confusing and I got the impression that only the CRT functions have a C interface.

[pps43]

That's a lot of boiler plate code. Is there a way to make it smaller? For example, if all I need is to open and process a file with no GUI (maybe a progress bar).

[beamatronic]

Outstanding! I have been wanting to see this for a long time. I really want to build OS X apps but I personally prefer to build GUIs programatically.

[leonatan]

So build programmatically. But use Objective C or Swift.

[whitehat2k9]

Well, that looks rather unpleasant.

[chris_wot]

Would love to see this annotated.