To me it doesn't seem like it. Of course I don't have sources of Foundation, but in case of GNUStep, take this example.
They have a NSArray code like this
https://github.com/gnustep/libs-base/blob/master/Source/NSArray.m
Nowhere in the source do they refer to CFArray.
https://github.com/gnustep/libs-corebase/blob/master/Source/CFArray.c
Same goes for all CF counterparts.
Why?
GNUstep's Foundation classes do not use Core Foundation. GNUstep started out as a free, open source implementation of the OpenStep specificiation. The Foundation and AppKit classes are both derived from the OpenStep specification. While GNUstep's goal is to catch up with current versions of Cocoa (according to GNUstep's Wiki it pledges compatibility with Mac OS X Tiger, and some classes and methods from newer versions of macOS have been added to GNUstep), my understanding is GNUstep does not have any Core Foundation dependencies. I found an interesting 2005 mailing list post discussing why GNUstep does not use Core Foundation.
When Apple announced its Mac OS X strategy in 1998, it provided two APIs for developers: Cocoa, which was an updated version of the Foundation and AppKit libraries, and Carbon, which were C APIs derived from the classic Macintosh Toolbox that were updated to be suitable in an operating system with preemptive multitasking and protected memory. Both Carbon and Cocoa were built on top of Core Foundation, which provided a common bridge for both APIs. Carbon and Cocoa were equal peers in Mac OS X, with neither API being favored over the other.
So, in a nutshell, Core Foundation was added to Mac OS X as a compatibility bridge between Cocoa and Carbon. But GNUstep is essentially modern OpenStep, and OpenStep never had Core Foundation, and thus GNUstep's Foundation does not use Core Foundation.
GNUStep is not the same as Apple's Foundation. I don't know much about how GNUStep is implemented, but in Apple's Foundation, NS and CF counterparts are very closely linked indeed. As you say, we don't have the source for Foundation, but there are still many ways to detect integration between the two. One really easy-to-spot one is just to inspect the class of many Foundation objects:
NSMutableString *string = #"Foo".mutableCopy;
NSLog(#"%#", NSStringFromClass(string.class));
This little program outputs __NSCFString, a clue that CFString's implementation is indeed being used under the hood. Specifically, NSString and CFString (as well as NSArray and CFArray, NSDictionary and CFDictionary, and many other Foundation and CF types) are toll-free bridged—this means that their internal structures are designed to be exactly the same, such that you can actually convert one to the other with a simple typecast, with no expensive conversion process. So NSArray doesn't just use CFArray, it actually is a CFArray.
Of course, since it's allowed to make your own private subclasses of classes like NSString, NSArray, et al., this means that for the bridging to work, the CF functions need to be able to handle the case where what looks like a CF object is actually an Objective-C subclass, and use the Objective-C implementation if it is. And for that reason, CoreFoundation objects, which we do have much of the sources to, do actually make many references to their NS equivalents, such as the CFArray source linked below, which contains references to NSArray.
https://opensource.apple.com/source/CF/CF-1153.18/CFArray.c.auto.html
Related
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.
When coding MacOS, there are several options I can use. Core Services, Core Foundation, and Core Data. What's the difference between them? Are they pure C++ code?
They all perform different things and are implemented in either C or Objective-C:
Core Services:
This collection of documents provides the API reference for the Core
Services framework, which encompasses many fundamental operating
system services used by Carbon applications.
Core Foundation:
Core Foundation is a framework that provides fundamental software
services useful to application services, application environments, and
to applications themselves. Core Foundation also provides abstractions
for common data types, facilitates internationalization with Unicode
string storage, and offers a suite of utilities such as plug-in
support, XML property lists, URL resource access, and preferences.
Core Data:
This collection of documents provides the API reference for the Core
Data framework. Core Data provides object graph management and
persistence for Foundation and Cocoa applications. For more details,
see “Core Data Basics”.
Look at Apple's diagram:
You can see right away that Core Services is a layer in the MacOS software ecosystem that includes Core Foundation plus much more. Core Foundation is C-based, so you can of course call it easily from C++, but not all the frameworks in the Core Services layer have C-only API's.
Core Data is another framework in the Core Services layer, and is a good example of a Core Services API with an Objective-C API. Core Data and Core Foundation do completely different things -- neither is a suitable substitute for the other.
These are libraries which you can link against and use in your code. The code apple uses in them is intentionally obscure from us, and usually you would use Objective-C to consume them (one presumes they are written in Objective-C, but there are some C++ libs). You can link against these and many other Apple libraries. See Apples Core Services Documentation for a description of the frameworks. There are many, and they are diverse and too large in scope to describe here.
They are all quite different, actually-and they are written in Objective-C, not C++. You can't access the code inside them anyway, only the interfaces they expose to you, so that's actually irrelevant.
The Apple developer docs are an excellent resource:
Core Services
Core Data
Core Foundation
I need to write a DLL (dynalib, whatever) for OS X 10.6 (Snow Leopard) or later The DLL reads and writes a binary file. (It's the company's proprietary format.) It'll be used by an app that's all Cocoa (AFIK). Everything 64 bit only.
From reading Apple's docs, books, and asking questions here, I still don't have a clear and confident idea as to the good, proper way to deal with binary files. I have the impression I can't use the standard unix/C fopen(), fread() or open(), read() etc. Or I can but I'd be asking for trouble. Is this true? Should I be using something else, and just what?
I have the impression I can't use the standard unix/C fopen(), fread()
or open(), read() etc.
The POSIX/BSD personality is fully supported by the operating system. Feel free to write standards compliant C.
Foundation Kit has Objective-C classes and messages you can use (NSData, NSFile, etc), however they are often more of a pain to use especially when you are maintaining portable code amongst platforms. There is also the side-effect of Objective-C being somewhat easier to reverse engineer than straight C (a trait shared by all higher-level languages).
Depending on the needs of your library, you can consider wrapping it into a Framework as opposed to a naked dylib.
Is there is a Cocoa framework for windows or a interface builder for windows like we have in mac?.
Thanks.
You might look into Cocotron,
an open source project which aims to implement a cross-platform Objective-C API similar to that described by Apple Inc.'s Cocoa documentation. This includes the AppKit, Foundation, Objective-C runtime and support APIs such as CoreGraphics and CoreFoundation.
…
The general goal is to provide complete support on any viable platform, the project is intended to be as portable as possible. However, most of the work at this time is focused on providing support for Microsoft Windows. In particular the NT based versions, 2000 up to Vista.
No. You can install Objective-c on windows and you can install some of the old the NextStep APIs but you can't get the Cocoa Frameworks or other Apple APIs.
In the wikipedia article on Cocoa it says:
There are also open source implementations of major parts of the Cocoa framework that allows cross-platform (including Microsoft Windows) Cocoa application development, such as GNUstep, Cappuccino, and Cocotron.
Yet when I looked into whether Mac application Tweetie was available for windows the developer had ruled it out:
Windows doesn't have Cocoa, the programming environment that Tweetie is made in, as such, it seems like a poor possibility.
I'd like to have an answer to point the Tweetie developers (and as a resource for other cocoa developers) which would tell them:
Which implementation is the most suitable for getting a cocoa app running on windows?
How much work is it likely to take to get the app running under windows?
How easy/hard is it to maintain a common code base for Mac and Windows?
(any other considerations I've missed?)
Of course if it would be too much work I'd like to know that too before suggesting it and potentially sending someone else on a fruitless search.
Don't forget:
“Major parts of the Cocoa frameworks” is not the same as “the entirety of the Cocoa frameworks”. Tweetie could be using something that's missing.
Tweetie could be (very probably is) using APIs from the non-Cocoa frameworks, such as Core Foundation, Core Services, Core Graphics, and Core Animation. A port of the Cocoa frameworks alone won't include any of these APIs, and even a more complete Mac-API-emulation framework will not include all of them.
These frameworks are eternally chasing Apple. Even if they catch up, they'll be instantly behind again as of the next Mac OS X release. Mac developers already put off using new APIs in new Mac OS X releases while they wait for users to upgrade to those new releases; now you're asking atebits to also wait for the other-framework developer to catch up to Apple again.
Any second implementation of an existing API will have bugs that the first implementation doesn't, and vice versa. These differences will cause development and support problems.
You're asking atebits to add a third platform to an application that already exists on two. Supporting one platform is a lot of work. Supporting two platforms is a hell of a lot of work. Supporting three? Now you're getting into big-company territory.
So, even with these Cocoa-like frameworks, the answer is: Hard.
Among GNUstep, Cappuccino and Cocotron, Cocotron is only possible choice to port a Mac application to windows.
Cappuccino is for web and GNUstep only runs on top of cygwin or mingw, which means the GUI looks nothing like native windows apps.
It is theoretically possible to build cocoa windows apps using Cocotron. However, the reality is that it is still very hard to use, and it is still quite limited in the Cocoa API.
Therefore, two possible solutions:
Try hard to remove the codes that are not supported by Cocotron in the original code base and do the cross compilation. Maintaining common code base will be painful.
Start a new GUI at all, no common code base. two choices here
Start a cross platform project with cross application framework such as Qt, or Java.
Start a windows only project. There are a lot of choices here, .Net WinForm application, MFC, etc.
There are Windows compilers for Objective-C (the programming language used to write cocoa apps). However, Cocoa includes the frameworks for presenting the GUI. These visual frameworks are specific to Mac OS X because they use OS X only windows and other controls. So someone would need to re-implement the controls in Cocoa to use Windows controls.
Also, I am fairly certain that Tweetie uses Mac OS X only technologies like Core Animation. This does not exist on Windows, so the nice animation effects present in the apps would have to be implemented in a completely different way.