I am trying to build a mac(cocoa) app. I have a framework that I am trying to link with that has been compiled for iOS(the armv7 arch). I unfortunately no longer have the source code that I used to compile the original framework. Would it be possible to change the architecture of the framework(perhaps through decompilation and then recompilation) so that it can be compiled into my cocoa app?
So far I have looked into lipo and fat binaries as well as using optool to decompile but haven't made any direct progress towards converting architectures.
Thanks for your help.
No, there is no reasonable way to automate this conversion. Most C decompilers generate code that is a very literal translation of the assembly; it is usually not suitable for compilation.
(One good decompiler is the Hex-Rays plugin for IDA Pro. However, it is extremely expensive -- a license is over $2000. Unless your framework is particularly large and complex, it may be more cost-effective to work without this tool.)
If you have really lost the source code, your only real option will be to rewrite the framework. You can use the disassembly to guide your efforts, but you will need to fill in some of the details.
In theory, if the code doesn't use any POSIX system calls directly, it might be possible to create an Frankensteinian abomination:
Run the code on an arm64 emulator.
Replace all function call linkages into the Objective-C runtime (e.g. objc_msgsend) with emulator traps.
Abort if you find any other function call linkages.
For runtime function calls, call the equivalent runtime function on the x86-64 side.
For alloc calls, return an NSProxy object on the arm64 side that traps into the emulator.
For any objects passed via parameters, return values, or return parameters, pass an NSProxy object.
That said, in practice, unless the framework is insanely complex, it would be faster to rewrite the code. And realistically, even if it is insanely complex, if you know enough arm64 asm to pull this off, you can probably rewrite it from the asm more quickly. :-)
Related
This question pops up quite often here, even if just implicitly when users mistag their iOS questions. So, what’s the difference between Xcode, Objective-C and Cocoa?
Objective-C is a programming language. It could be said that it’s just a description of what valid Objective-C programs look like and what they mean. If you have a source code listing written in Objective-C, you need an interpreter or a compiler to put the listing to work. Languages like Objective-C are usually compiled, so most people use a compiler (like LLVM). Objective-C is almost exclusively used to develop for iOS and OS X, but there are other uses, too – as an example, some people write Objective-C for Linux.
You can use a text editor to write the sources and a compiler to turn them into an actual programs, but with modern technologies there’s much more to take care of, so that there is another program to make your job easier. These are called Integrated Development Environments, or IDEs. An IDE offers you a convenient way to edit the sources, compile them, debug the resulting programs, read the documentation, and many other things. Xcode is one such IDE. An important observation here is that Xcode does not compile your sources itself, it just calls the standalone compiler (LLVM). And Xcode is not the only IDE you can use to develop Objective-C apps – there’s AppCode, for example.
Writing iOS or OS X apps from scratch each time would be very time-consuming. That’s why Apple provides the developers with a good set of libraries. The libraries are simply a huge amount of source code written by Apple, and this source code takes care of most things that apps have in common. These libraries are called Cocoa.
Now, if you can’t figure out how to extend a class, you are most probably talking about Objective-C. It doesn’t have anything to do with Xcode or Cocoa, you could be very well writing some GNUstep code for Linux using Vim as an IDE and GCC as a compiler. On the other hand, if your Xcode build process fails because of some mysterious setting, or if you’re trying to build a static library in Xcode, that’s clearly an Xcode issue. And if you can’t figure out how to use some NSObject facility or the NSFileManager class, that’s Cocoa. (But it doesn’t have to be Xcode-related, as you could use AppCode or TextMate as your IDE!)
Originally available on my blog. Feel free to link to the blog post or this question when retagging or explaining the difference.
Xcode is the integrated development environment (IDE)—the application—that developers use to write software for iOS and/or OS X. It includes the editor, the build system (determining what to build to produce the desired target), and quite a few other things.
Objective-C is the main language that developers write such software in. They may write bits of it in pure C, use C++ or combine it with Objective-C (producing Objective-C++), or write some or all of the program in another language entirely, such as MacRuby, Java (with j2objc), or C# (with MonoTouch).
Xcode includes the Clang compiler, which turns code written in Objective-C, C, and a few other languages into executable code. Most error messages come from Clang, and Xcode relies heavily on it for search indexing, syntax highlighting, and name completion of Objective-C code.
Cocoa and Cocoa Touch are application frameworks. Each one is a suite of many individual frameworks (libraries stored in folders named blahblah.framework), such as:
Foundation (both): General object-oriented utilities, including NSString, NSURL, NSFileManager, etc.
Core Foundation (both): Mostly the same thing, but different, mainly in having a C-based API rather than Objective-C
Application Kit (Mac): Application and windowing framework
UIKit (iOS): Application and windowing framework
Core Graphics (both): Drawing
Core Animation (both): Sprite-management and animation framework
(and many, many more where they came from, especially on the Mac)
So:
You can use a framework besides Cocoa or Cocoa Touch, but you'll have to have some Cocoa/Cocoa Touch code, at some level, in order for your application to talk to the system, receive events, draw, etc. Frameworks that specifically target Mac and/or iOS will include the relevant wrappers for you, at varying levels of quality.
You can use a language besides Objective-C, but you'll have lots of syntactic awkwardness, as most of Cocoa and Cocoa Touch are designed for Objective-C's unique syntactic features (particularly selectors).
You can use an editor besides Xcode, and you can even use a build system besides Xcode (such as make), but Apple's App Stores expect apps built a particular way (especially with regard to code signing), so unless you're not targeting the App Stores, any other build system has to replicate what Xcode does or risk its users getting rejections.
A clear mistake is failing to differentiate Xcode from everything else. Xcode is the tool you are using to program in - to edit code, run code, etc. So if you are having trouble with the tool (e.g., the window doesn't show you your code properly, or you're having trouble drawing your interface, etc.), that's an Xcode problem.
If you don't understand why your code doesn't work, you're probably having an Objective-C problem or a Cocoa problem. But you won't necessarily know which.
It's an Objective-C problem if the root of your trouble is that you don't know how the language works (e.g. you don't know what the asterisk is for, or that declaration is not instantiation, or that messages to nil do not error out but don't do anything either).
It's a Cocoa problem if you don't grasp the delegate architecture or how a view controller works.
But my experience of the way people pose questions is that you may be ignorant of which of these you are ignorant of. I don't mean you personally, I mean all of us. This can make it difficult to pose the question properly because you don't know what exactly it is that you don't know — if you did, you'd know it and you probably wouldn't be having a problem (you'd be fixing the problem and on to the next thing).
There are lots of oop languages, but I couldn't find any that has conveniences like garbage collection, but compiles natively to machine code. Sort of like between C and java/c#. One interesting language I found was Vala, but that's limited to the GNOME platform and is not that well-known
Go is probably closest.
But why on earth do you want it natively compiled anyway?
JIT compilation of portable bytecode has proved to be an extremely effective strategy. It compiles down to native code at runtime (so you get up to the performance of native code after the first few iterations) and it avoids the issues of having to build and manage platform-specific compiled binaries.
Are you thinking about C++? That is in high usage and can be compiled on nearly any (major) platform.
In the case you want to use an oo language that compiles down to native code you will "always" have to use header files and stuff as the elf format doesn't support oo (There is no class information in elf).In case you want to use classes from external libs you need to make the compiler aware somehow about the fact that there are classes, functions, etc. that are declared outside of your project. In C++ this is solved by the use of header files. So that's, I think, a major drawback in native object oriented languages. To resolve that issue a few tweaks would need to be made to elf/loader/linker in order to support the kind of features (like "linking" against "classes") you might expect. Even though mechanism for garbage collection could be implemented even in native languages. But that seems no good for os implementation.
There are C++ libs to do that for userspace apps like:
Boehm collector
Smart pointers
I'm planing to write my algorithmic codes in Matlab. And I need to convert .m files into a format where Objective-C can access. When I try mcc, the following error appeared.
The -t switch is no longer supported; the Compiler no longer generates C/C++
source code for M-functions (it generates wrapper functions instead, see
the documenation for -W).
If mcc is not creating C source codes how can i generate wrappers? and do i have to copy both m file and the wrapper in order to make everything working?. And will those wrappers work in iOS??
MATLAB Compiler does not convert MATLAB code into C code, and has not done so for a long time now.
Instead, it archives and encrypts your MATLAB code and creates a wrapper (which could be an executable, a library or, if you have access also to any of the Builder products, a .NET assembly, a Java .jar file, or an Excel add-in). This wrapper dearchives and decrypts your MATLAB code, and executes it against the MATLAB Compiler Runtime, which needs to be included with your application (but is freely redistributable).
You are not going to be able to run the MCR on iOS - its footprint is just too big. If you are targeting another platform with Objective-C, you could produce a library using MATLAB Compiler and call that from your Objective-C.
MATLAB Coder (not the same as MATLAB Compiler) can convert a subset of the MATLAB language into C code. If you are targeting iOS this would be one approach, or you could alternatively run your MATLAB code remotely, and have your app access it via the web.
I'm a little confused by what you have written so I may not be answering your real question:
The Matlab documentation provides clear instructions on how to use the Matlab engine from C programs. Since Objective-C is just C with knobs on, I see no reason why you shouldn't call the engine from an Objective-C program. All that the Matlab engine will see when it is running are valid calls, it has no clue what language the calling program is written in.
I think that for your usage of mcc is irrelevant; what you need is an Objective-C compiler on your Mac. The Matlab documentation suggests that the compiler included in XCode up to v4.1 is OK for Matlab engine applications. In my experience, it may take a little fiddling with compiler options to make a more recent compiler work with your installation of Matlab, but no more than that.
If you plan to use Objective-C calling Matlab, you may not want to start by writing M-files for your algorithmic core. Actually, you probably will, but the Matlab engine doesn't really run M-files, it executes commands sent to it by an external program, such as your Objective-C program. Your development route might be (1) write M file to implement algorithm, then (2) write Objective-C program calling Matlab engine at critical steps when the Matlab functionality is required. You could write your application to make the engine run an M-file (I think) but this is outside my experience.
While you can use Matlab to run a compiler to build your programs, in this case you are probably better using XCode (or your preferred Mac IDE) to build your programs, taking care to ensure that the right linkages are made to the Matlab engine. Again, the documentation explains what you need to do.
No wrappers are involved. No M-files are required. And good luck getting the Matlab engine running on iOS !
I'm currently working on a framework for interfacing with a web service I wrote. To make life easier, I'm considering using a wrapper around CFNetwork, called ASIHTTPRequest.
That's all wonderful. But what happens if the user already added that class to their project? I'm sure the linker would throw up an error. Is there any way to 'constrain' classes to only exist in a specific framework, so the linker will ignore them outside of that framework/library? Alternatively, I can always use plain CFNetwork APIs, but that's just a pain and as we all know, programmers are lazy =P
Thanks for any ideas/suggestions.
No. There is absolutely no way to do this. You won't get a linker error if you do, but you'll get a runtime warning printed by dyld directly to the console on every single launch, and if the version of ASIHTTPRequest that you bundle differs in any meaningful way from the version the application uses, then you could get bad behavior or a crash.
HTTP really isn't that hard. Why would you use CFNetwork? Just use NSURLConnection.
I am trying to compile a library originally written for Cocoa. Things are good until it looks for the function marg_setValue(). It says there is a syntax error before char in
marg_setValue(argumentList,argumentOffset,char,(char)lua_toboolean(state,luaArgument));
(it's talking about the third argument, not (char) )
I am trying to port LuaObjectiveCBridge to the iPhone. It has two choices, either using Runtime or Foundation. I have discovered there are some problems with foundation so I am trying runtime. But the compiler is not co-operating.
Check to see if you can get rid of the marg_XXX macros:
they are deprecated and not considered as reliable.
marg_list is to be used with objc_msgSendv which is absent from modern runtime.
I suggest to go with NSInvocation. It is pretty simple to use, and powerful enough for a bridge. Check this entry for completeness.
The modern Objective-C ABI/API is available on Cocoa Touch. It lacks some of the legacy features of the 32-bit desktop runtime (namely, ones that were horrendously fragile).
marg_setValue() and friends are a part of that legacy runtime that is not supported in Objective-C 2.0. It was -- always was -- broken anyway. You aren't missing much.
The real question is: What are you trying to do?