Porting msvc code to Android/ios - android

I have a pretty large project written in C++ for Windows, with some MSVC-specific fancy things, like __declspec(property), usage of SEH, extra template and macro flexibility, intrinsics and etc.
In a nutshell it consists of various applications and a shared library (lib), which is a pretty large "algorithmic" code. It's written entirely in plain C++ (MSVC's version of it, as I said), not dependent on any 3rd-party, all the code is "hand-made", no stdlib, STL, Boost or etc.
Now this code needs to be ported to mobile platforms, namely Android and iOS.
The code should be platform-independent. No explicit dependence on OS, besides the very basic things, like heap memory allocation. It does depend on some Windows-specific things: SEH, TLS, but those are the things I can sacrifice, if they can't be replaced.
And I'm thinking about how to deal with it. Cleaning the whole code from MSVC-specific stuff is possible, but not convenient. I'd prefer to keep them, and definitely I don't want to keep several codebases for different platforms.
So, what are the options at my disposal?
As I understood, there are C++ compilers for Android (part of NDK), but they are probably standard C++ compliant. Anyway, iOS development is based on Objective-C, which is a superset of plain C.
This led me to an idea to "compile" the existing MSVC-specific C++ code into a plain C. There is an option in MSVC compiler to generate "listing" files, containing the assembler code. I guess if there's an option to create appropriate listings containing C-code. Or alternatively MSVC-compliant 3rd party C++ -> C converters.
Any thoughts?

So, what are the options at my disposal?
Write portable C or C++ code.
I've got C and C++ libraries that run on Android, iOS, Windows Phone, Windows, BSD, OS X and Linux. The library is written once and it runs everywhere.
While the "core library" is portable C/C++, the next layer up is not. That's where the libraries integrate with the platform. For example, the iOS test suite driver has a Cocoa/CocoaTouch UI on Apple platforms, and an MFC test suite drive on Windows and Windows Mobile. And the test suite drivers on Linux are command line because I don't waste time with GTK or Qt.
The routines to seed the random number generators are platform specific. I consider them a core function, so its in the core library and guarded by platform specific #defines.
Don't make the mistake of re-implementing your core library on every platform it runs on. That means you will need 4x to 8x the development cycles to duplicate the code and behavior. And there will always be small, hidden behavioral bugs that you waste countless hours tracking down.
And I'm thinking about how to deal with it. Cleaning the whole code from MSVC-specific stuff is possible, but not convenient.
Yes, do this. Pay the tax once and enjoy the benefits for the remainder of the code's life.
This led me to an idea to "compile" the existing MSVC-specific C++ code into a plain C.
No, I would not do this. Remove the platform specific stuff from the core library. Make the core library portable.

MSVC++ to C compilers come in the "if you have to ask, you can't afford it" category. Just too small a market.
A more realistic chance would be to wait what Microsoft is doing. They're seriously looking into targeting additional mobile platforms with MSVC 2015.
TLS is probably the easiest, as that is standard C++ (thread_local). SEH should be mapped to regular C++ exception handling, which means you need to trap pointer bugs before they happen. MSVC isn't exactly known for extra template flexibility, it's in fact rather inflexible. x86 intrinsics obviously are right out on ARM.

Related

Are there cross-compilable OpenGL examples made with Oxygene?

We have a working OpenGL project made for PC (works on MacOS and Linux under Wine as well) which we want to try to cross-compile to tablets. Delphi XE2/XE4 offers iOS support, but there's no Android yet and judging from iOS implementation history it might take 1-2 years. Now we start looking into other possibilities which will allow us to keep the majority of Pascal codebase (80k lines). So here's the question for the Oxygene:
Are there any examples of OpenGL applications made with Oxygene that can be cross-compiled to work on PC/MacOS/iOS/Android ?
If not, what alternatives are there (except Lazarus)?
AFAIK there is none.
Even the low-level Sugar cross-platform RTL is not finished. It would be a first mandatory step to be done before accessing higher level libraries in a cross-platform way (i.e. with identical source code), like OpenGL.
So with Oxygene, you have a great cross-compiler, but you are tied to use the RTL available on each platform.
You can compare with two object-pascal compilers:
With FreePascal, which has built-in OpenGL units, and already several libraries over it - one of the most powerful/known is GLScene;
With SmartMobileStudio, which has built-in WebGL support and can do amazing things on modern browsers - WebGL is a translation of the OpenGL API/concepts in HTML5.
Oxygene doesn't attempt to be source compatible with Delphi. What's more the runtime libraries used by the various Oxygene flavours differ entirely from those used by Delphi. So you won't find any serious libraries that have single source that can compile on Oxygene and Delphi.
The way that RemObjects have developed Oxygene on different platforms is quite interesting and radically different from the approach taken by Embarcadero with Delphi.
With Delphi the goal is that you can single source development for all the platforms. That is made possible by the FireMonkey framework which presents a common interface to all platforms. Obviously you need to vary some elements of an app to account for device differences.
With Oxygene, each platform is targetted separately. So for Windows, the runtime is .net. For Java it is the JVM and for Apple platforms you target Cocoa.
All this means that you cannot expect to write a GUI app in Oxygene and have it work on multiple platforms.
So not only can you single source your app between Delphi and Oxygene, you cannot readily single source multiple Oxygene targets.
Now, you can probably port to Oxygene or FPC without too much trouble. But maintaining single source is liable to mean a lot more effort. Whether that's worth the effort is debateable. In the long run you'll want a codebase in one of Delphi, FPC, Oxygene, or even something radically different. But you won't want your code spread out over multiple languages.
You can write or own OpenGL layer in Oxygene with the usage of mapped types like it is used in the sugar open source project.
It sounds pretty cool. In your code you have just to use one class which is during compiling direktly mapped to the underlying platform class method, without an overhead of that layer.
IMHO, when Oxygene is growing, we will then find a lot of such "suger" layers and write once compile anywhere will come closer :)
Edit:
Using OpenGL with .Net
OpenGL Java Tuturial

What are the most important POSIX functions not available in Android?

I'm about to port a large C++ project (some sort of Library Project, it contains absolutely no GUI) to Android. It's actually a Visual C++ project, but it will be ported to Linux as intermediate step. I know that Android is not a "full" Linux and does not claim to provide all POSIX functions, but I also know there are a lot of "POSIXish functions" on Android by using the NDK.
Now my actual question is:
Which are the biggest/most important functions that are NOT available on Android compared with the full POSIX set? So that I can keep that in mind when doing the porting from Visual C++ to Linux GCC.
I tried to find something on Google, but found nothing really helpful, just here and there some stuff that mentioned that there are some POSIX functions on Android...
Bionic a recode by Google. It is small but optimized for Android.
The only big thing I know of that it lacks is indeed the pthread_cancel() function.
My experience is that if you port it successfully to GNU/Linux, without pthread_cancel() calls, then you should be mostly ok.
BTW, what kind of library are you trying to build? What does it uses? Network, threads...
PS: Even Linux is not fully POSIX.
Bionic Wikipedia page
https://en.wikipedia.org/wiki/Bionic_(software)#Differences_from_POSIX
Also has some interesting info:
Although bionic aims to implement all of C11 and POSIX, there are still (as of Oreo) about 70 POSIX functions missing[8] from libc. There are also POSIX functions such as the endpwent/getpwent/setpwent family that are inapplicable to Android because it lacks a passwd database. As of Oreo, libm is complete.
Some functions deliberately do not conform to the POSIX or C standards for security reasons, such as printf which does not support the %n format string.[9]
Official Bionic in tree documentation quote
https://android.googlesource.com/platform/bionic/+/37ad9597839c70a7ec79578e5072df9c189fc830/docs/status.md
Run ./libc/tools/check-symbols-glibc.py in bionic/ for the current list of POSIX functions implemented by glibc but not by bionic. Currently (2017-10):
aio_cancel
aio_error
aio_fsync
aio_read
aio_return
aio_suspend
aio_write
lio_listio
pthread_cancel
pthread_mutex_consistent
pthread_mutex_getprioceiling
pthread_mutex_setprioceiling
pthread_mutexattr_getprioceiling
pthread_mutexattr_getprotocol
pthread_mutexattr_getrobust
pthread_mutexattr_setprioceiling
pthread_mutexattr_setprotocol
pthread_mutexattr_setrobust
pthread_setcancelstate
pthread_setcanceltype
pthread_testcancel
wordexp
wordfree
libm
Current libm symbols: https://android.googlesource.com/platform/bionic/+/master/libm/libm.map.txt
0 remaining missing POSIX libm functions.
The most obvious feature missing is pthread_cancel().
This blog has some additional details: http://codingrelic.geekhold.com/2008/11/six-million-dollar-libc.html
Good overview of Bionic: https://android-platform.googlegroups.com/attach/0f8eba5ecb95c6f4/OVERVIEW.TXT?gda=HWJaO0UAAAB1RXoVyyH5sRXFfLYnAq48KOFqr-45JqvtfiaR6gxIj4Qe8cBqW3BaWdSUPWi_jHqO3f1cykW9hbJ1ju6H3kglGu1iLHeqhw4ZZRj3RjJ_-A&view=1&part=4
shared memory is also something you might find differently implemented in android. was hit hard while trying to work with shm_open and shm_unlink on android kernel. Android implements asynchronous shared memory (ashmem).

Creating a dll for Objective-c and java functions

I would like to create a dll that would contain definition for some functions. I would be able to use the functions in both Objective-c and java environnement.
Is it even possible to do this?
Thanks!
Write in C or C++. You'll be able to link that to Objective C/Cocoa via the magic of Objective C++, and to Java on Android via NDK and JNI. That's what I do in my project. The compiler is GCC in both cases, the RTL is not identical but similar enough.
Avoid hairy data structures in the interface, stick to primitives and primitive arrays. And, naturally, you'll probably need to abstract away some of the platform.
You might want to compile your code with -fshort-wchar. It happens so that short is the native character format in both Cocoa and JNI. You'll lose widestring functions of the RTL though, but they're no use with Cocoa strings and Java strings anyway. Or you can use UTF-8 on the library/platform boundary. Conversion overhead on every call, yadda yadda.
Note: if you just want to reuse some minor helper functions, it's just easier to write them twice, or copy/paste then adjust the syntax. Debugging NDK code is notoriously tricky. Only go this way if the shared bits constitute 25-30% of the project or more. In my case, it's more like 60% shared.
EDIT: if you go this way, some further porting to other mobile platforms will be a snap and some - not so much. Specifically:
Samsung bada - snap (also C++ with GCC, yay)
Mobile Qt (Meego, etc) - snap (same as above)
Windows Mobile 6.5 and under - relatively easy (compiler difference between GCC and MSVC might get in the way)
Windows 8 tablets (AKA WinRT, Metro) - same as above
Blackberry Playbook - possible in theory, never tried
Old school Blackberry - impossible, it's all Java
Windows Phone 7 - impossible, it's all C#/VB.NET
If you want to create an application for iOS and Android and you want to reuse the business logic of your application (not the UI), take a look to Xamarin.
You can develop with C# and create Android and/or iOS apps.
From Xamarin web site:
Save time by sharing data structures and non-UI code between iOS and
Android.
Hope it helps.

Programming for Android in a 100% C++ Environment?

I've been working on a game engine runtime environment in C++ for my future games, and have started to consider android as a platform. I noticed that it was tightly bound to Java and uses Java VMs heavily.
But is it possible to sustain a full C++ runtime environment in Android NDK? I have nothing against Java and am prepared to use it if I have to, but performance is one of my prime concerns (I intend for my games to be resource-intensive), especially on phones.
And if a full C++ environment is possible, how exactly would I implement it in Eclipse Indigo CDT? Would I be able to create a compiled game executable for Android ahead of time for maximum performance? And would there be any additional plugins I'd need to install in Eclipse? Could I use MinGW for compiling my games, or would I need to use a different compiler? If I had to use Java in one way or another, would compilation of the C++ code even be required? These are all questions I'd like to answer to get a sturdy development environment going in the Eclipse IDE.
Please know that I'm still fairly new to Android development, and multiplatform programming in general. My goal is to create a game engine that'll take the most advantage of the new hardware out there, especially on phones!
Thanks for any advice you guys can give!
NativeActivity, added in Android 2.3 (API 9) might be what you're looking for in terms of writing Android games using only C++. http://developer.android.com/reference/android/app/NativeActivity.html
However since you say you're new to this you may want to start with one of the currently available Android game engines instead of writing your own right away. Mobile devices have a very different set of constraints than other platforms. A phone isn't very useful if the battery dies mid-afternoon, so starting a project with the stated goal of being "resource-intensive" is already getting off to a bad start. Few people will want to play your games for 20 minutes here and there if it means they won't be able to make a phone call in the evening.
If what you meant is that you are shooting for high-end graphics, keep in mind that devices have a wide range of capability in this area and targeting only the high end limits your audience. Different GPUs have very different strategies and performance characteristics and all have cases where they shine or lag behind. The most successful mobile games aren't the ones with the highest polycounts or the most complex lighting shaders, they're the games that achieve a consistently smooth framerate and have a distinctive style.
Have a look at some of the existing game engines for Android and try them out. Write a couple small games to take them for a test drive and see where they do and don't mesh with what you're trying to do. If you find yourself feeling limited with what's available, take what you've learned and try to write your own engine that fits with the types of games you want to make.
Here are some links to get you started. These engines power some very popular games on Android Market and many developers have found them useful:
http://www.andengine.org/ andengine is written in Java and is open source.
http://unity3d.com/ Unity is based on C# and Mono.
http://www.madewithmarmalade.com/ Marmalade, formerly Airplay SDK is based on C++.
The answer you want to pay close attention to is #adamp's. Ignore his answer at your own peril.
To address a couple of other points in your question, though:
Would I be able to create a compiled game executable for Android ahead of time for maximum performance?
No, insofar as Android does not use "compiled game executables". Your C/C++ code will be compiled into a Linux shared object (.so) file and packaged with other stuff (like your manifest) in an APK file. Compiling the .so will be ahead of time, though.
Could I use MinGW for compiling my games would I need to use a different compiler?
I get the distinct impression that you will claw your eyes out trying to do NDK development in Cygwin on Windows. I heartily encourage you to do your NDK development on OS X or Linux. At least set up a VirtualBox with Ubuntu or something in it to do your NDK compiles.
Regardless, the NDK comes with its own GCC compiler. AFAIK, MinGW is not a cross-compiler, and most Android devices are not running on x86 CPUs.
If I had to use Java in one way or another, would compilation of the C++ code even be required?
Yes. Now, for Honeycomb, you have the option of using Renderscript for OpenGL work -- that amounts to a C99 environment whose code you will not need to compile with the NDK.
I've tried a bunch of them, and one of the best I found that cross compiles instantly to a bunch of other devices and let's you program your goodies in HTML5/C++ combo (sweeeeet) is MoSync (http://www.mosync.com/) and another little known one that is a little more setup friendly is MotoDev by Motorola (http://developer.motorola.com/tools/motodevstudio/?utm_campaign=mhp01092012&utm_source=mhp&utm_medium=mws)
I've noticed there is some virtual machine images and tutorials you can use to prevent the setting up hassle.

Running a Haskell program on the Android OS

Forenote: This is an extension of the thread started on /r/haskell
Lets start with the facts:
Android is one awesome Operating System
Haskell is the best programming language on the planet
Therefore, clearly, combining them would make Android development that much better. So essentially I would just like to know how I can write Haskell programs for the Android OS. My question is:
How can I get a Haskell program to execute/run on the Android OS?
How you do it is by first getting a Haskell compiler which can target C with the android NDK which comes with a GCC port for ARM architectures. JHC can trivially do this with a very small inf style file which describes the platform (word size, c-compiler, etc) I've done this with the Wii homebrew dev kit and it was quite easy. However jhc still has some stability issues with complex code such as using a monad transformer stack with IO but jhc has been improving a lot over the last 6 months. There is only one person working on JHC I just wished more people could help him.
The other option is to build an "unregistered" port of GHC targeting the ndk gcc, this is a lot more involved process because GHC is not a true cross-compiler at the moment and you need to understand the build system what parts you need to change. Another option is NHC which can cross-compile to C, like GHC you need to build nhc targeting a C compiler, NHC does not have many Haskell extensions like GHC.
Once you have Haskell compiler targeting NDK GCC, you will need to write bindings to either the android NDK JNI glue code framework (added since android 2.3) or you must write JNI glue code between Java-C-Haskell, the former option is the easier solution and if I remember correctly might actually be backwards compatible with previous versions of Android below 2.3.
Once you have this you must build Haskell code as shared library or static library which gets linked into the NDK java glue code (which itself is a shared library). As far as I'm aware you can not officially run native executables on android. You could probably do it with a rooted phone, thus I assume this means you can not distribute native executables on the app store even when the NDK gcc port can generate native executables just fine. This also probably kills the option for using LLVM unless you can get the NDK JNI working with LLVM.
The biggest hurdle isn't so much of getting a Haskell compiler for android (which is still a big hurdle) the biggest problem is that some one needs to write binding APIs for NDK libraries which is a huge task and the situation is worse if you need to write android UI code because there are no NDK APIs for this part of the android SDK. If you want to do android UI code in Haskell somebody will have to write Haskell bindings to Java through JNI/C. Unless there is a more automated process to writing binding libraries (I know there are some, they are just not automated enough for me) then chances of some one doing it are quite low.
L01man: Is there a tutorial about how to do this? For the
first part, I understand I have to download JHC. What do I have to
write in the inf file and how to use it?
Please note before I answer this question I haven't used jhc for quite sometime since I originally wrote this and newer versions have been released since so I do not know how stable jhc currently is when it comes to code generation of more complex Haskell programs. This is a warning to anyone before you consider making a large Haskell program with JHC, you should do some small tests before you go full on.
jhc does have a manual http://repetae.net/computer/jhc/manual.html and a section on setting-up cross-compilation and .ini file with options: http://repetae.net/computer/jhc/manual.html#crosscompilation.
L01man: The second part is an alternative to the first. I don't know how to do what you said in the
third.
Before you begin you should have some knowledge of C and be comfortable with using the Haskell foreign function interface (FFI) and tools such as hs2c. You should also be familiar with using the Android NDK and building .apk with shared libraries. You will need to know these to interface between C-Haskell, Java/C-Haskell and develop Haskell programs for Android that you can officially distribute/sell on the market store.
L01man: I understand that its goal is to create a binding for the
Android API. But... does the 4th part says we can't make .apk with
Haskell?
.apk is just an app package file format and is built with the tools that come with the Android SDK (not NDK), this has very little to do building the binaries itself. Android packages can contain native shared libraries, this what your Haskell program will be and the native shared/static libraries are generated via the Android NDK.
A language that has recently come to my attention is Eta.
Eta's compiler is a fork of GHC 7.10 which has a JVM backend. It is possible to use the generated JAR files to write Android apps and even use its Foreign Function Interface to call native Android Java libraries.
Brian McKenna has written a blog post about how to configure an Android Studio project to use an Eta library.
There is https://github.com/neurocyte/android-haskell-activity demonstrating Haskell code running.
I once came across the same Reddit thread, but it was old, and comments were closed. I sent a message to the OP, but am not sure whether it reached the recipient. My suggestion here (may work for older Androids where native activities were not possible).
I (developed in Haskell some time ago, but currently switched to Smalltalk) am currently developing a port of Squeak VM to Android. The way I am doing this is similar to what might be dealt with in a haskell-on-android project: a lump of C code which needs to be called from Java part of the application (basically all that can be done in Android is to handle various events; an application cannot poll for events itself and does not have any event loop). In my case the code is generated by the Squeak VM building tools, in the case of haskell on android this will be output from GHC of JHC or whatever front end used. This repo may be worth looking at:
http://gitorious.org/~golubovsky/cogvm/dmg-blessed/trees/master/platforms/android/project
Under "src" there is the Java code which provides for user events interception and sending them to the native code (see the CogView class). The C code of the VM itself is not completely there (see squeakvm.org, the Cog branch for that), but one may get the idea. One also might look under http://gitorious.org/~golubovsky/cogvm/dmg-blessed/trees/master/platforms/android/vm which is the C frontend to the interpreter (including user events handling, some timekeeping, etc.)
Hope this helps.
Dmitry
There is https://github.com/conscell/hugs-android a port of HUGS Haskell interpreter to Android.
I think the general answer should come from source->source transformations, since loading specially compiled shared objects seems to be a bit of a kludge (involving ghc->c and a c->java step in the answers above). This question thus falls under the heading of Haskell on the JVM, which has been tried (with one step as a Java intermediate representation) and discussed at length. You could use frege if the libraries you need compile there. The only remaining steps would be the beginnings of the Android framework API translated into IO() actions and maybe a wrapper for building the manifest xml and apk.

Categories

Resources