3 ms·

Author of the answer in question here.. Feel free to ask me any questions you'd like about this! I also did the same thing in ARMv7 assembly, if you're interes

Author of the answer in question here.. Feel free to ask me any questions you'd like about this! I also did the same thing in ARMv7 assembly, if you're interested in that: https://github.com/richardjrossiii/iOSAppInAssembly https://github.com/richardjrossiii/iOSAppInAssembly

userbinator 12y ago
Reminds me of writing Win32 applications in C + Asm, although it looks even more difficult because the documentation is lacking and there's more stuff that has to be done. I find the fact that a simple, "do nothing" native iOS app is much bigger than some very featureful apps on other platforms somewhat sad... I don't know of any 64k/4k demos on iOS either. Great work for trying it though. Are all those bytes actually needed? E.g. I see a lot of "restore VFP/Advanced SIMD registers" when you don't seem to be using those at all. It would be interesting to see how much you can cut out, as currently it looks more like a mostly mechanical ObjC -> C -> Asm translation, like a compiler would do, instead of a human. As a point of reference, on Win32 an app that just shows a window with some text in it requires <1KB of binary.
- richardjrossiii 12y ago
  The only reason I'm storing the VFP registers is because that is the 'official' iOS ABI, and yes, I could probably trim it down significantly, however, the binary itself currently sits at about 63k when compiled in debug mode, so I didn't deem it necessary to trim that further at that time. Some good ideas though, and one day I may just go ahead and do it!
aninteger 12y ago
Well done.. I'm curious about whether this would be possible in Android. I'm not talking about OpenGL and using the ndk but creating Android activities. Would it be much much more difficult?
- zachlipton 12y ago
  Well I suppose the Android equivalent would be writing raw Dalvik bytecode. Certainly possible, but probably not a lot of fun. It wouldn't be nearly as informative about the underlying architecture in any case.
- richardjrossiii 12y ago
  I'm not sure how the JNI works on Android, but theoretically, yes. I am not a huge android fan however, so I probably won't be the one to attempt it.
- Ologn 12y ago
  "I'm not talking about OpenGL and using the ndk but creating Android activities" I'm not really sure what you mean. Any program for Android which is 100% C code is going to be using the NDK in most cases. Including ones creating an activity natively ( http://developer.android.com/reference/android/app/NativeActivity.html http://developer.android.com/reference/android/app/NativeAct... ).
- speeder 12y ago
  Seemly Marmalade SDK create android apps without using NDK... Seemly what it do is compile a valid ARM code using arm abi (not even the linux abi), and then there is a component that do use android OS stuff to load in the memory the code you compiled for arm abi... Funky stuff. And patended. (Marmalade website make VERY CLEAR that their "Secret sauce" is their loaders, that are also very much patended...)

userbinator 12y ago

Reminds me of writing Win32 applications in C + Asm, although it looks even more difficult because the documentation is lacking and there's more stuff that has to be done. I find the fact that a simple, "do nothing" native iOS app is much bigger than some very featureful apps on other platforms somewhat sad... I don't know of any 64k/4k demos on iOS either. Great work for trying it though. Are all those bytes actually needed? E.g. I see a lot of "restore VFP/Advanced SIMD registers" when you don't seem to be using those at all. It would be interesting to see how much you can cut out, as currently it looks more like a mostly mechanical ObjC -> C -> Asm translation, like a compiler would do, instead of a human. As a point of reference, on Win32 an app that just shows a window with some text in it requires <1KB of binary.

richardjrossiii 12y ago
The only reason I'm storing the VFP registers is because that is the 'official' iOS ABI, and yes, I could probably trim it down significantly, however, the binary itself currently sits at about 63k when compiled in debug mode, so I didn't deem it necessary to trim that further at that time. Some good ideas though, and one day I may just go ahead and do it!

aninteger 12y ago

Well done.. I'm curious about whether this would be possible in Android. I'm not talking about OpenGL and using the ndk but creating Android activities. Would it be much much more difficult?

zachlipton 12y ago
Well I suppose the Android equivalent would be writing raw Dalvik bytecode. Certainly possible, but probably not a lot of fun. It wouldn't be nearly as informative about the underlying architecture in any case.
richardjrossiii 12y ago
I'm not sure how the JNI works on Android, but theoretically, yes. I am not a huge android fan however, so I probably won't be the one to attempt it.
Ologn 12y ago
"I'm not talking about OpenGL and using the ndk but creating Android activities" I'm not really sure what you mean. Any program for Android which is 100% C code is going to be using the NDK in most cases. Including ones creating an activity natively ( http://developer.android.com/reference/android/app/NativeActivity.html http://developer.android.com/reference/android/app/NativeAct... ).
speeder 12y ago
Seemly Marmalade SDK create android apps without using NDK... Seemly what it do is compile a valid ARM code using arm abi (not even the linux abi), and then there is a component that do use android OS stuff to load in the memory the code you compiled for arm abi... Funky stuff. And patended. (Marmalade website make VERY CLEAR that their "Secret sauce" is their loaders, that are also very much patended...)