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.
OS X app in plain C
91–100 of 157 posts
Re: OS X app in plain C
#92Richard J. Ross III did it a few years ago for iOS:
Re: OS X app in plain C
#93Earlier quoted context omitted.
> 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 impl…
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...
> Objective-C was a modification of the GCC developed by NeXT.
No. Objective-C started out as a set of C Macros, then an actual pre-processor was created, mostly to deal with uniquing selectors. Once the pre-processor was there it was used to create actual syntax.
Documented in "Object Oriented Programming: An Evolutionary Approach".[1] Still one of the best books on OO out there, because it treats OO as an architectural style with tradeoffs relative to other styles, rather than as a religion to be accepted (or nowadays as the devil to be cast into hell).
It also clearly describes the deliberate hybrid style that seems to be mostly forgotten now: object largely implemented in C, but connected via dynamic messaging. "Software-ICs".
I am somewhat surprised by seeing the 1986 release date, I guess I must have gotten it pretty soon after it was published. Used it as a template to implement an Objective-C pre-processor + runtime + basic classes on my Amiga (had just gotten a C compiler for it).
One of the reasons I got a NeXT was because NeXTStep was largely implemented in Objective-C, which to me meant they "got" it. And it also meant I could enjoy programming in Objective-C without having to maintain my own :-)
[1] http://www.amazon.com/Object-Oriented-Programming-Evolutiona...
Re: OS X app in plain C
#94Earlier quoted context omitted.
> 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. The same goes for C++ or Swift. Getting the function pointer for a method can be involved, but all functions adhere to the C ABI.
At least MSVC on x86 uses "thiscall" by default which puts the this pointer in ecx. You cannot call those functions from C without specific compiler support.
Sure you can.
Just write an asm stub to call, that sets up ecx and other things right.
Re: OS X app in plain C
#95Don'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"]; th…
>> 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
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.
Re: OS X app in plain C
#96Earlier quoted context omitted.
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…
Even on a platform that wasn't based on C, the C standard is flexible enough to match pretty much any native ABI. That's a small (and under-used) upside to all of that undefined behavior.
Most of the time, you will need a tiny bit of non-standard stuff in your compiler to do so.
For example, I don't think there is a portable way to let your compiler use Pascal calling conventions, or to pass information in specific registers or in processor flags.
As an extreme example, in classic Mac OS, you could register a function to be called for line breaking in text input boxes that had the ABI "Parameters are passed to the routine in registers A3, A4, and D0, and output is returned in the Z flag of the Status Register." (https://developer.apple.com/legacy/library/documentation/mac..., page 2-31 gives several other special-cased ABI's in Mac OS)
Browsing that, I also encountered "The routine follows the C calling conventions employed by the THINK C software development environment. Arguments are passed on the stack from right to left, and a result is returned in register D0."
(Aside: that compiler must have treated vararg functions differently)
So, apparently, one cannot even count on C compilers to push arguments from left to right. So, if your ABI says "push X first, then y", I don't think you can portably call that function from C.
Re: OS X app in plain C
#97I 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 d…
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
Re: OS X app in plain C
#98There 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" la…
not really. MS have had this with their C++ for a very long time... easily 20 years +
Re: OS X app in plain C
#99sorry, 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. :)
Re: OS X app in plain C
#100There 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" la…
> 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 impl…
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. :)