OS X app in plain C

https://github.com/jimon/osx_app_in_plain_c

by dmytroi • 10 years ago

249 151 10 years ago

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.

fbonetti• 10 years ago

C is a sane language?

nice_byte• 10 years ago

Yes.

ddoolin• 10 years ago

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.

hellofunk2• 10 years ago

I don't know who you've been talking to, but that's ridiculous. C++ is one of the most widely-used languages for writing native apps for any OS. Adobe products, Chrome, anything built with Qt, even the Swift language itself, all made in C++.

chillingeffect2• 10 years ago

This is a very particular crowd, largely into web software and ecosystems for rapid growth of SaaS. I wouldn't extrapolate this crowd into software languages in general. You should always use the best tool for the job.

Many people write quite excellent software in C/C++ every day. Just as many people use chainsaws, drive cars, fire guns and take pills every day. These are all productive activities with low floors and high ceilings. Anyone can jump in and make a mess. It takes care and attention to do them well.

Hydraulix9895• 10 years ago

Why recommend Objective-C over C/C++ though? It's more or less subject to the same "pitfalls" that go against C, PLUS it is a syntactical nightmare.

[whatTheHell:is this:shit];

Is ARC really that much of a savior here? At least method calls get resolved at compile time.

codemonkeymike• 10 years ago

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

ultramancool2• 10 years ago

Windows, X11 and Gtk would argue with you.

dmytroi7• 10 years ago

IMHO it depends, C/C++ work very nicely with immediate mode UI frameworks, for example nuklear [1], imgui [2]. Though retained mode C/C++ UI frameworks are also quite popular, for example Qt, wxWidgets, GTK.

- [1] https://github.com/vurtun/nuklear

- [2] https://github.com/ocornut/imgui

tosseraccount2• 10 years ago

Few languages have intrinsic GUI components.

marssaxman• 10 years ago

Ummm... I wrote plenty of GUI code in C and so did lots of other people back in the late '80s and early '90s. Quite common. I don't know what it would mean for it to have been "designed to create" GUIs; it's a general-purpose language.

cloudjacker• 10 years ago

that analogy though

beamatronic2• 10 years ago

I had a project once that required me to build a GUI in C using Motif. It was a joy to use. I recall there was a simple concept called RowColumn. All the GUI widgets were either in a Row or in a Column. It was highly orthogonal and allowed you to build good-looking UI's that acted in a reasonable way when resized, etc.

santaclaus2• 10 years ago

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

fit2rule2• 10 years ago

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

chillacy5• 10 years ago

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.

santaclaus2• 10 years ago

It started for me around on the Mountain Lion to Mavericks upgrade, so whatever changed then.

btrask10• 10 years ago

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

eridius• 10 years ago

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.

dmytroi7• 10 years ago

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

mikeash5• 10 years ago

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.

btrask10• 10 years ago

You're right and thanks for the correction. One point I'd add is that C generally encourages not using casts because casts themselves can be error-prone. So it's debatable whether it adds any real type-safety.

leonatan2• 10 years ago

I believe this is already the default for new projects.

radarsat1• 10 years ago

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.

umanwizard• 10 years ago

Not OP but I'm guessing they were referring to the fact that this stuff is platform-specific and not specified by the C standard.

msbarnett4• 10 years ago

The C standard specifies absolutely no "C ABI" standard. The two "standard" calling conventions you cite, cdecl and stdcall, are Wintel conventions.

However, since C is the low-level implementation language for almost every dominant operating system, a given platform's Operating System ABI is almost always locally synonymous with the C ABI on that platform, and people tend to speak of "being compatible with the C ABI" when what they really mean is that they're compatible with the OS's ABI.

But if you move to, say, a Mainframe OS, the OS ABI is dramatically different than the "C ABI" you're imagining from Wintel.

jheriko5• 10 years ago

there is no standard in theory... but in practice one exists.

its a subtle difference some devs will pull out when they want to boost their egos by talking about things that sound smart, but they don't realise it requires that special kind of "smart-yet-dumb naivete" to consider worth caring or talking about.

conradev4• 10 years ago

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.

dep_b• 10 years ago

I think it actually was a precompiler for C up til a point. Still Objective-C objects have underlying C functions that are being called whenever you try to call a method or anything on an Objective-C object. Theoretically you should be able to call functions on Objective-C objects from C.

valarauca1• 10 years ago

Objective-C was a modification of the GCC developed by NeXT. NeXT didn't publicly release their patches and the FSF/GNU threatened legal action. NeXT released their sources and the GCC now supports Obj-C.

Source: https://en.wikipedia.org/wiki/GNU_General_Public_License#Leg...

jheriko5• 10 years ago

you mean objective-c++? c++ has no idea about obj-c...

another thing most people forget is that the entire programming community rejected obj-c as deficient in its very early days... it only persists thanks to the ego of former nextstep employees afaik. and now apple employees got lumped with it... which i'd suspect helped create the internal pressure for swift... so some good came at the end of it all. :)

gumby• 10 years ago

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

avar• 10 years ago

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

mintplant• 10 years ago

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

jheriko5• 10 years ago

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

chillacy5• 10 years ago

Unless MS has a custom C++ runtime that I'm not aware of, I wouldn't consider C++ a high level language like obj-c is, for better or worse. The benefits and drawbacks of runtime dispatch are highly debatable, but the amount of runtime metaprogramming you can do in ObjC is comparable to what you can do in a language like Ruby:

* Call any method (send message in objc parlance) based on the string name of the method * Add methods to existing classes you don't own * Swap existing method implementations of a class you do not own at runtime (method swizzling) * Get and set variables by their string name for subclasses of NSObject * Check if an object has a method with a given name (great for invoking methods conditionally)

http://genius.com/Soroush-khanlou-objective-c-isnt-what-you-...

themartorana2• 10 years ago

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.

josh64• 10 years ago

I feel the exact same way about it but hopefully it isn't going to go anywhere any time soon.

WWDC 2016 will hopefully have some nice objective C announcements just like last years did.

informatimago2• 10 years ago

Why miss it? Just go on using it! If important applications are written in Objective-C, that will motivate the spreading of Objective-C.

gcr2• 10 years ago

Is objective-C going away?

Also, are there any particular resources that you would recommend for beginners? I'm looking forward to reading this article since it might expose the low-level details of how, say, message passing works under the hood. Most of the guides are a bit too "beginner-oriented"; I'd love to find something that pulls up the carpets to reveal all the infrastructure underneath.

sigjuice• 10 years ago

I don't buy the "plain C" claim, given the gratuitous use of objc_msgSend().

juliangoldsmith• 10 years ago

What else would it be? objc_msgSend() is called as a C function, to interface with ObjC code.

msbarnett4• 10 years ago

...objc_msgSend() is a plain C function that grovels around in various runtime data structures to call the correct function pointer for GUI and OS functionality.

Any alternate method of finding and calling those functions would amount to simply reimplementing objc_msgSend()

sgt• 10 years ago

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.

mcmatterson• 10 years ago

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• 10 years ago

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>

wtallis• 10 years ago

I think those are all valid C header files. They just define typedefs and macros that are about ObjC, but themselves are plain C.

tosseraccount2• 10 years ago

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

icodestuff• 10 years ago

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.

hunterwerlla• 10 years ago

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.

thought_alarm• 10 years ago

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• 10 years ago

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

0x0• 10 years ago

Relevant: "Let's build objc_sendmsg()"

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

chris_wot6• 10 years ago

Would love to see this annotated.

conradev4• 10 years ago

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)

justsaysmthng• 10 years ago

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

deanCommie• 10 years ago

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.

elsurudo• 10 years ago

I think it's obvious that this is an academic exercise (or "just because I can" sort of thing), which makes the GP's comment quite unnecessary.

dmytroi7• 10 years ago

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

btrask10• 10 years ago

I haven't looked at tigr yet (it seems interesting!) but could you just use '#ifdef __OBJC__'?

fit2rule2• 10 years ago

For the record, this isn't a new trend - its been fashionable in C for decades to create single-header 'library' drop-ins and is pretty much par for the course ..

bluedino• 10 years ago

> 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

OJFord• 10 years ago

Well, sure. But only in the same way that the first C compiler was a "machine code converter".

* Or B, perhaps, if we're to be really pedantic.

bdrool2• 10 years ago

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• 10 years ago

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.

bdrool2• 10 years ago

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

beamatronic2• 10 years ago

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.

leonatan2• 10 years ago

So build programmatically. But use Objective C or Swift.

sdegutis• 10 years ago

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.

dmytroi7• 10 years ago

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/

pps43• 10 years ago

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

justinlardinois2• 10 years ago

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

seabrookmx• 10 years ago

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

userbinator3• 10 years ago

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.

justinlardinois2• 10 years ago

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.

mayoff• 10 years ago

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

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

jheriko5• 10 years ago

sorry, but mediocre at best, full of mistakes at worst.

i'm sure it was a good exercise in learning objective-c but this is not an amazing achievement. i'd expect much better from someone competent reading the god awful docs and reverse engineering by inspection.

don't give up though. doing things like this over and over, especially in the face of nay saying arses like me, is what makes great programmers. :)

gcr2• 10 years ago

As a beginner to Objective-C, I found reading the source here highly informative, because it gives you a rare peek at the actual machinery underneath everything that's going on.

userbinator3• 10 years ago

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• 10 years ago

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.

chillacy5• 10 years ago

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 :)

whitehat2k9• 10 years ago

Well, that looks rather unpleasant.

OS X app in plain C

Related Stories