Source Code

[Riccardo Spagni]

Hi all,

   We have an interesting predicament. One of our clients has asked us to develop a cross-platform application, and we've opted to use MoSync for this. They want to retain the source code of the application, but since it is in our own interests to retain the C/C++ source code (ie. what we create in MoSync) we're trying to find a middle ground. Is it possible to produce source code as an output, so that we can retain the C/C++, and deliver the compiled binaries PLUS we can deliver source code for J2ME/iOS/Blackberry/Symbian/Android? That way we retain the IP of the code we write (and make ourselves invaluable when it comes to adding new features etc.), but *if* our relationship with them broke down they could get someone else to take over iOS development (or any of the other platforms, for that matter).

Thanks,
   Riccardo

[ander...@mobilesorcery.com]

Hi!

The closest we can get is to provide the generated C++ code which is generated when you build for iOS. This file can be found at <project>/Output/Release/iphoneos/1/xcode-proj/Classes/rebuild.build.cpp . The path to the actual file depends on you your build configuration.

This rebuilded file is a direct mapping of what MoSync Intermediate Language looks like when it's described in a way which a C/C++ compiler could compile. It uses internal registers and is filled with gotos and labels. For iOS this is a solution since the xcode project is all you need to build the application. For all the other platforms we use a binary representation which we call MoSync byte code. This is then loaded into the runtime and can be executed by a virtual machine, line by line, or it can be recompiled by the runtime into ARM byte code. On those platforms we can't provide a simple solution which consists only of source code which your client can compile by them self since the current implementation depends on compiled MoSync byte code. 

A quick explanation of how a MoSync application is built:

Our bundled version of GCC takes your project C/C++ files and our custom backend generates MoSync Intermediate Language (MSIL). This is a textual representation of your source code which looks like assembler. The MSIL code is then being sent to pipe-tool which takes your code and the libraries and generates MoSync Byte Code (MSBC). Some people could argue that pipe-tool is a linker but it does a lot of other things as well and not just linking. At this stage pipe-tool has some flags which could make it generate other things than MSBC. It can also output C++, Java or C# representations of the MSIL code. The C++ output is used for the iOS platform and the C# output is used for the coming Windows Phone 7 MoSync runtime. No platform today is using the Java output but we are thinking about fixing the Blackberry runtime so that it can use that. For iOS and Windows Phone 7 all the source code is then compiled through Xcode or Visual Studio and a binary is produced. For the other platforms the MSBC is bundled with the application and then gets loaded on start up. Some platforms recompiles the MSBC directly to ARM byte code at the loading stage.

 

[Samuel Pickard]

Just a quick question then, why does the WP7 version produce C#
instead of CIL?

[Samuel Pickard]

"thinking about fixing the Blackberry runtime"

Yeah - do that!

[Patrick Broman]

It's easier to maintain and debug, and you get the benefit of whatever
optimizations Microsoft's compiler can perform when generating the
CIL.

/Patrick

On 1 November 2011 10:05, Samuel Pickard

<samuel....@mobilesorcery.com> wrote:
> Just a quick question then, why does the WP7 version produce C#
> instead of CIL?
>

--
Patrick Broman
Head of architecture
Twitter: http://twitter.com/patrickbroman
Mobile: +46703256756
e-mail: pat...@mosync.com
www.mosync.com