I suddenly found Xcode have very poo support for view the C API docs.
Suppose if you want to find the definition for fopen, you can't find any meaningful info for this function expected the declare.
So any workaround for this?
Edit according to Mark Szymczyk's suggestion.
My problem is when I Option click the function, it just show this function is declare in stdio.h, no more explanation to this function like other cocoa APIs.
And when I search in the documentation viewer, it shows something like this, this will cost a little time to figure out it.
There is no solution for you with Xcode. Apple's top priority with Xcode is developers of apps on Apple's platforms using Apple's technologies. That priority also applies to documentation. For standard C language APIs, Apple supplies man pages. If that is not good enough, you're out of luck.
A possible solution is to use Dash, a documentation viewer app. If you can find a comprehensive documentation set for the C language APIs, you could import it into Dash and read it from there.
Related
I have a piece of old Mac OS X code that I'm to recompile for the modern version of the OS. The code uses functions like GetIntlResource or SysBeep and the compiler complains that they have been deprecated long ago (in Apple years, apparently). I'd be happy to replace the calls with something more modern, but I cannot find any docs on these functions. (I expect the docs to say something like “deprecated, use FooBar instead.”) Same for functions like CreateWindowFromNib and such; these are worse than deprecated, they are not even there. Searching developer.apple.com or Google produces no useful results.
Is there a way to find documentation on old Apple APIs to understand at least what they were doing?
Update: Found what they call a legacy library; not searchable (e.g. you cannot search by a function name), but it's better than nothing.
Update 2: The thing was originally compiled for Mac OS X v10.4, I think. If I configure the build to target that version, it works fine without any warnings. Naturally, a 64-bit build is not possible, but that is expected. I guess it's OK to close this question, since I found the cold storage myself.
The particular calls you mention date from before OS X. At that time, the core of Mac programming documentation was the Inside Macintosh series of books. These are available in the "retired documents library" that you linked, however the search bar there seems to skip over them.
Try using Google queries like "Inside Macintosh" SysBeep. It's not foolproof, but you can find the given APIs here:
SysBeep in Inside Macintosh: Macintosh Toolbox Essentials
GetIntlResource in Inside Macintosh: Text
Essentials serves as a sort of in-depth overview and refers to other books… these were written before the Internet took off. The library of books is pretty much self-contained, but it only captures a snapshot of the mid-1990's. I don't suppose that a rehashed version for OS X 10.4 survives, if it ever existed. I only recall them publishing lists of pre-OS X routines that were blessed for forward compatibility.
I imagine the Swift language has gotten the attention of a boatload of iOS programmers - many of whom never wrote a single line of Objective-C in their life.
For example I have dozens of apps on the app store, written in Titanium.
In the Titanium world every property and event available is documented, for example like this for UILabel:
http://docs.appcelerator.com/titanium/3.0/#!/api/Titanium.UI.Label
Is there an Apple equivalent? I read the Apple iBook on Swift - it discusses the core language, it doesn't list out the methods available in the Cocoa touch framework, and leaves it to the programmer to intuitively guess based on their Objective-C experience.
Is that a fair assessment, that that you have to learn Objective-C first and then use that as a bridge language to Swift - or is Swift intended to be stand-alone? If so, where is the documentation of Cocoa Touch, in swift?
The documentation is included in Xcode6 (or can be downloaded). You can currently access it by going to Window -> Documentation and API Reference. (or by pressing shift, command & 0)
You will then have full access to search and find resources here. You can also option click on something in Xcode to pull up the docs for that specific thing.
As you will see it shows you the declarations for Obj-C and Swift together. This technically isn't Swift documentation (it is the iOS8 library documentation) but it should be similar to what you were looking for.
Note: this post originally included screen shots but I removed them as developers are not supposed to post screen shots of pre-released software.
The Cocoa Touch APIs and frameworks are the same between Swift and Objective-C. There are only minor syntax differences used when you call the APIs. The framework documentation is currently pre-release, so if you aren't a registered developer then you can't see it yet.
I'm writing code specific for MountainLion so I want to try to avoid to use deprecated APIs.
I use FSFileOperationCreate to receive information about copy progress (kFSOperationBytesCompleteKey, kFSOperationThroughputKey, kFSOperationTotalBytesKey) but documentation says
Creates an object that represents an asynchronous file operation.
(Deprecated in OS X v10.8. At the Foundation layer, use
copyItemAtURL:toURL:error: instead. At the POSIX/BSD layer, use
copyfile(3) OS X Developer Tools Manual Page instead.)
Using copyItemAtURL:toURL:error and NSFileManagerDelegate seems impossible to obtain same informations.
How can I obtain same behaviour in 10.8 without rewriting code myself?
Does Apple know now it is simple awful to make same thing?
Might not be the answer you wish to hear[1], but wrap copyfile(3) in your own Obj-C wrapper. You should be able to calculate all you need using the callbacks, in particular the progress one. HTH.
[1] Quite a few APIs in this general area have been deprecated, and while some new APIs have been introduced they seem incomplete. Reasonable guess might be more is coming in 10.9...
There were changes between 10.5 and 10.6 in the way AudioUnits are handled. One of them (at least according to Apple's documentation) was the addition of Audio Component Services. Among other places it is documented at:
http://developer.apple.com/library/mac/documentation/AudioUnit/Reference/AudioComponentServicesReference/AudioComponentServicesReference.pdf
I'm putting together some code to handle input and output units, and am having trouble figuring out how to use these calls. As a starting point I put in a call to AudioComponentCount, and the linker can't find it. I've added CoreAudio.Framework and CoreAudioKit.Framework, but that does not help. It is declared in AudioComponent.h.
Any suggestions on how to get this code to link properly?
Thanks for any help you can bring to bear on this!
When I look up AudioComponentCount in Xcode's documentation, it shows me a page entitled "Audio Component Services Reference". When I scroll to the top, it says it's from the AudioUnit framework. So, try linking against that.
Would be usefull to see how things work but not sure on the legality of it
Most Mac apps are written using Cocoa in Objective-C; which, while it is a compiled language, means that there is a fair bit of information left over that could be used by a decompiler.
I'm not sure if there are a lot of decompilers out there that leverages this information, at least I haven't heard of any.
However, there are also another option; F-Script.
F-Script can be used to attach to an executable and explore its interfaces, while not as good as source, it can give you a pretty clear idea of how the executable is built, and how it operates.
As for the legality issue:
IANAL, but as far as I know, reverse-engineering for the purposes of compatibility is legal in many jurisdictions, and I can't imagine that decompiling an executable to look at its code is illegal, unless the specific EULA specifically prohibits it.
Edit: WRT Steam specifically, it is probably NOT written in Cocoa, but C# with some manner of .NET compatibility layer; and it's probably not a good place to start if you want to learn how to make applications for Mac OS X.
By far, the best Mac OS X disassembler I've used is Hopper available here:
http://www.hopperapp.com/
It will also convert the assembly to C pseudo code as best it can. It will generate code flow diagrams with blue lines (true blue, love it) for true and red for false paths.
It's The Mac OS reverse engineering tool. There are even Youtube videos that will show you how to use it.
If it's an open-source app, yes. Otherwise it's possible through decompilation but the output will be a real pain in the ass to look at. If you just want the protocols and the interfaces of categories and classes, have a look at class-dump.
I'm not aware of a nib decompiler.
Whether decompilation is legal: ask a lawyer. This may (and probably does) differ per jurisdiction.
Is it possible to view the source of a mac app?
Realistically, no. Sure, you might be a able to use a decompiler to get a peek, but the kind of output you'll get won't be easy to read. If you're asking this question, this route probably isn't going to be helpful to you.
Specifically interested in GUI and how the steam app for mac works
It's a good bet that it works about the same way that most other applications work. It might use custom controls to look different from a typical application that mostly uses the standard Cocoa controls. But underneath, just about any GUI application written for MacOS X will use the run loops, responder chain, and view hierarchy that Cocoa provide. The main exceptions would be applications that are built mostly using an alternate framework like OpenGL or WebKit.
Figure out what, specifically, the Steam application does that you'd like to do. Take a look at the tools that Cocoa provides to see if you can figure it out yourself; if not, ask about it here.