It seems from my initial reading there are two options for assembly on Mac OS X.
- C libraries
- BSD System Calls.
- Something with Objective C
Is there an equivalent of the Win32 API on Mac OS X?
Apple uses Objective C heavily; how much does Objective C add on that changes using it in assembly?
Apple's CoreFoundation seems to be abandoned or not heavily used instead Apple choosing to go with Objective C and not regular C libraries.
Mac OS X seems to use the NASM assembler.
This is all coming from someone who has most of their experience in MASM and the Win32 API. I hope I am horribly informed here as it seems right now assembly on the Mac is bleak.
As I view it, using Objective-C is only really necessary for writing GUI apps using Cocoa, though it can be used for other applications as there exists many mapping from Core Foundation functions to the Objective-C methods.
The CoreFoundation is certainly alive and kicking, especially as some parts of OSX don't use Objective-C, such as kernel extensions, which are exclusively C++ and the kernel itself is mostly C.
I would say that the Core Foundation libraries are the closest match to the Win32 API, but if you're looking to using Cocoa (GUI Widgets), then Objective-C is what you need to use, unless you want to opt for something like the Qt framework.
As for ASM with Objective-C, Objective-C is a superset of the C language, so you can happily write C functions with embedded ASM, if that's what you want to do. Or just write pure assembly code, obeying the OSX ABI function call guide.
Related
Now that swift has been released by Apple I have have been thinking the posibility of using gobject as a runtime for existing languages such as rust or even swift.
My main concern is that while vala does this, it compiles to c before and needs language bindings even if the library that you are trying to use already uses gobject and even then somehow vala cant use features that c doesn't support such as function overloading, while objective-c doesn't support it, but swift does and can still be used with it.
On the good side both runtime systems have many similarities, such as using reference counting, having signals and being more dynamic than the average
You can view GObject (and in extension GLib and the ecosystem of GLib based libraries) as a common language runtime for several languages:
Vala / Genie
Gjs (then GNOME version of ECMAScript / JavaScript)
C
C++
Python (through PyGObject)
Probably others, really any language that can talk to the C API
Actually it really is an extension to the C runtime (which is the core common language runtime of most Operating Systems) that adds OOP support.
There are other such technologies like the Java JVM the .NET CLR and as you describe Apple is using the Objective C runtime now for multiple languages as well.
There is (in principle) nothing that prevents someone to write a Rust or Swift compiler that does something similar to Vala (emits C code and uses GObject as it's object system).
About your concern:
Vala could as well emit object code directly (without the intermediate "compile to C" step).
There are some advantages to the concept the valac is written at the moment though:
You can take the emitted C files and use them in a C program without the need to have valac installed
It's much easier for Vala to consume C files and
The foreign function interface (called VAPI in Vala) was designed to make it easy to consume C libraries and abstract from common C idioms (like zero terminated strings, passing array with a length parameter, etc.)
The generated C code can be optimized by the C compiler
Standard C tools can be used to inspect the generated C code
You can actually read the C code to see what Vala does internally (big plus for people that already know C)
Vala uses C as a higher level "assembly" language.
I'm going to write a software using Rust:
core written in Rust
native Mac OS GUI written in Rust (preferably) or other language
Which setup allows that? Is it possible at all?
P.S. I never programmed nor with Rust nor with Cocoa/etc before.
GUIs designed in Interface Builder work best if you use bindings, but bindings assume Objective-C. For this reason I'm writing GUI part in Objective-C and core part in Rust.
The two can communicate via an obj-c library (article about this), but the languages are quite different, so it's a bit awkward.
Rust can easily generate C-compatible static library which can be linked to an Objective-C program. You can even add Makefile target in Xcode to build the whole thing without leaving Xcode.
I'm an experienced Linux programmer, familiar with POSIX, stdio.h and so on, but totally new to Mac programming. This week I'm attempting to get a piece of source code written by someone else a few years ago to work on 64-bit Snow Leopard. It's a Photoshop plugin originally for CS3, now to be made to work with CS5. (Don't ask me about CS4.) This plugin is built at the command line with a handwritten makefile using gcc.
The main roadblock today is the compiler complaining about several undeclared functions: FSRead, FSWrite, SetFPos, GetFPos, and more, all having to do with files. I'm pretty sure I have the right paths, options etc.
After two days grepping headers, googling, and trying to cheap hacks, I am stuck. Where are these functions defined? Are they standard Mac OS X library functions, or Photoshop SDK functions? Some google results suggest these functions are obsolete, "deprecated" but I guess by now truly gone. If that's the case, what should I be using instead?
After two days grepping headers, googling, and trying to cheap hacks, I am stuck. Where are these functions defined? Are they standard Mac OS X library functions, or Photoshop SDK functions?
They are old Carbon APIs. You can use the Carbon framework, however Carbon is not ported to 64-bit systems. As Photoshop is 64bit, this simply won't work.
I'm not familiar with how Photoshop plugins are handled, but if you are looking for a direct replacement you would look at Core Foundation, a C API. In reality, you can also use the POSIX APIs. If Photoshop uses Cocoa and Objective-C, you can use the Foundation and AppKit family of APIs.
If I want to write applications that use the Mac OSX UI, is Objective-C the only choice that I have to take advantage of all the frameworks that Apple provides?
Can I use Java, which is installed with Mac OS X?
I think Objective-C will provide the best coverage, yes, but if you want to consider portability and the possibility of getting your applications running under Windows and/or Linux, then choose Qt and C++.
The frameworks for native UI applications on Mac OS X (collectively known as Cocoa) are written in Objective-C so Objective-C is probably the best choice for writing your own applications, although there are bindings for Python and Ruby.
There are other toolkits that can be used (Mac OS X is a *nix system after all) but unless you are writing cross-platform apps, most people will advise you to use Objective-C and Cocoa.
MacRuby, an implementation of Ruby 1.9 on top of Mac OS X Objective-C runtime and Foundation framework, is another way to go.
You still need a deep knowledge of Cocoa and a good understanding of Objective-C.
It will be provided with Mac OS X 10.7 Lion as a private framework. It already integrates very well in XCode 4 workflow, with templates for all type of application (including windowed, it goes without saying).
(MacRuby makes RubyCocoa, the Cocoa binding for Ruby, obsolete.)
The JVM for Java under Mac OS X is no longer provided by Apple, but by Oracle (see here).
I guess Objective-C is the best choice for native OS X Applications. But if you want your Applications to run under other OSs (like Windows or Linux), you'll most likely use C++ and some GUI-Toolkit which supports all of them.
If you come from the Perl world, here is Sherm's CamelBones too.
I've been learning Objective-C and Cocoa by working my way through the Hillegass book and it occurs to me that I might be better off using Objective-C++. Objective-C seems like the clear choice for developing UIs but I have a very strong C++ background and would love to develop application back-ends in C++ and use Objective-C++ to do the UI integration.
But I wonder if Apple will keep developing Objective-C++ or will it become a dead end.
Is anyone out there using Objective-C++?
Disclaimer: I don't work or speak for Apple, so this is my opinion:
I can't speak for the major dev shops, but in my small group, we've used Objective-C++ both for integrating C++ libraries, and as you propose for writing backends in C++. As #alxp mentions, things like exception handling across the language boundary are painful, but with a little planning, most of these pains can be avoided. For experienced C++ devs, the gains can be well worth the pain.
In terms of support, I think you can assume that support in its current state won't go away any time soon. It's part of the GCC code base and the Clang toolchain (Apple's next compiler toolchain) fully supports Objective-C++. On the other hand, there isn't any official guarantee that Apple will continue to develop the integration—fixing some of the warts, for example.
For current projects, I would say that if using Objective-C++ provides benefit, it is safe to rely on the existing support and you should use it.
The only times I've used ObjC++ was to port libraries to make them accessible from my ObjC code. The clashes between how ObjC++ and ObjC handle things like exceptions and class creation and destruction just made it too much of a headache to juggle the two languages in one project.
I don't think support will go away soon as happened with Cocoa / Java since it is pretty solidly part of GCC, and the fact that Objective-C++ compiles down to straight C++ in the same way that Objective-C can compile down to straight C, but I still don't find it a very pleasant environment to build software in compared with Objective-C and being able to comfortably fully use the OS X-provided frameworks.
Objective-C++ is likely to remain supported as long as Objective-C is. Obj-C++ is a basic goal for clang, which is expected to eventually replace gcc as Apple’s preferred compiler. Usage is likely to rise as Carbon applications are moved to Cocoa front ends.
Of course, the word “likely” appears twice above because Apple is so excitingly unpredictable. :-)
I suspect Apple will continue to support Objective C++ for a while, as I don't see any significant recurring effort required by Apple to maintain Objective C++ as Apple updates Cocoa and Objective C++.
The other day I was surprised when I attempted to refactor some Objective-C code that was within an Objective-C++ file using Xcode's refactoring support. Even though the menu items are enabled I got the "Can’t refactor Objective-C++ code. Xcode can only refactor C and Objective-C code." error message. So while compilation of Objective-C++ will continue to function indefinitely I suspect Objective-C++ will be a second class citizen within Xcode.
I took it out of all my code. No .mm files.
But you need .cpp files to talk to .m files. The solution is a .c/.h file that keeps the blood brain barrier intact.
C++ with objective-C is usually just too much baggage.
Objective-C is really just a bunch of C code that emulates objects in the C language, and it still uses the C compiler including the Objective-C header files. Using Objective-C++ uses the C++ compiler and include the Objective-C headers as C code, since C++ will run C code. Objective-C++ is essentially just C, C++, and Objective-C (which is really just C)