Tag Archives: IOS

17 Years of Porting Software… Finally Solved

A History of Porting Software

I’ve been involved in creating and maintaining commercial and open source software for as long as I can remember, reaching back to 1996 when the world wide web was in its infancy, and Java wasn’t even a year old.

I was attracted to the NetBSD project because of its focus on having its software run on as many hardware platforms as possible.  Its slogan was, and remains “Of course it runs NetBSD”.

Although the NetBSD team worked tirelessly for its operating system to work across every imaginable hardware platform; much of the new open-source software development was talking place in for the i386 focused GNU/Linux operating system, not to mention the huge volume of Windows-only software that Wine tried, and mostly failed, to make available to people on non-Windows operating systems.

Advocates of cross-platform software like me were then constantly choosing between recreating or porting this software depending on its licenses terms and source availability just so we can use it on our platform of choice.

Some of the early of my open source contributions that are still available to download demonstrate this really well such as: adding NetBSD/OpenBSD support to Afterstep asmem in early 2000.  Or allowing CDs to be turned into MP3s on *BSD platforms with MP3c in the same year.

In 2002 when the large and ambitious KDE and GNOME desktops started to dominate the Linux desktop environments, I worked on changes to the 72 separate packages needed bring GNOME 2 and to NetBSD and became the primary package maintainer for a number of years.

As an early adopter of C# and the Microsoft .NET Framework I also worked through 2002 and 2003 to make early versions of the Mono project execute C# code to FreeBSD, NetBSD, and OpenBSD too.

The #ifdef solution

How was software ported between platforms back in those days?  Well to be honest, we cheated.

We would find the parts of the code that were platform specific and add #ifdef and #ifndef statements around them with conditions instructing the compiler to compile, or omit, different sections of code depending on the target platform.

Here is an example of read_mem.c from asmem release 1.6:

 * Copyright (c) 1999  Albert Dorofeev <Albert@mail.dma.be>
 * For the updates see http://bewoner.dma.be/Albert/
 * This software is distributed under GPL. For details see LICENSE file.

/* kvm/uvm use (BSD port) code:
 * Copyright (c) 2000  Scott Aaron Bamford <sab@zeekuschris.com>
 * BSD additions for for this code are licensed BSD style.
 * All other code and the project as a whole is under the GPL.
 * For details see LICENSE.
 * BSD systems dont have /proc/meminfo. it is still posible to get the disired
 * information from the uvm/kvm functions. Linux machines shouldn't have
 * <uvm/vum_extern.h> so should use the /proc/meminfo way. BSD machines (NetBSD
 * i use, but maybe others?) dont have /proc/meminfo so we instead get our info
 * using kvm/uvm.

#include <stdio.h>
#include <errno.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>

#include "state.h"

#include "config.h"

/* sab - 2000/01/21
 * this should only happen on *BSD and will use the BSD kvm/uvm interface
 * instead of /proc/meminfo
#include <sys/types.h>
#include <sys/param.h>
#include <sys/sysctl.h>

#include <uvm/uvm_extern.h>
#endif /* HAVE_UVM_UVM_EXTERN_H */

extern struct asmem_state state;

#define BUFFER_LENGTH 400
int fd;
char buf[BUFFER_LENGTH];
#endif /* !HAVE_UVM_UVM_EXTERN */

void error_handle( int place, const char * message )
	int error_num;
	error_num = errno;
	/* if that was an interrupt - quit quietly */
	if (error_num == EINTR) {
		printf("asmem: Interrupted.\n");
	switch ( place )
	case 1: /* opening the /proc/meminfo file */
		switch (error_num)
		case ENOENT :
			printf("asmem: The file %s does not exist. "
			"Weird system it is.\n", state.proc_mem_filename);
		case EACCES :
			printf("asmem: You do not have permissions "
			"to read %s\n", state.proc_mem_filename);
		default :
			printf("asmem: cannot open %s. Error %d: %s\n",
				state.proc_mem_filename, errno,
	default: /* catchall for the rest */
		printf("asmem: %s: Error %d: %s\n",
			message, errno, sys_errlist[errno]);

#ifdef DEBUG
/* sab - 2000/01/21
 * Moved there here so it can be used in both BSD style and /proc/meminfo style
 * without repeating code and alowing us to keep the two main functions seperate
#define verb_debug() { \
       printf("+- Total : %ld, used : %ld, free : %ld \n", \
                       state.fresh.total, \
       printf("|  Shared : %ld, buffers : %ld, cached : %ld \n",\
       printf("+- Swap total : %ld, used : %ld, free : %ld \n",\
#define verb_debug()
#endif /* DEBUG */

/* using kvm/uvm (BSD systems) ... */

#define pagetok(size) ((size) << pageshift)

int read_meminfo()
      int pagesize, pageshift;
      int mib[2];
      size_t usize;
      struct uvmexp uvm_exp;

      /* get the info */
      mib[0] = CTL_VM;
      mib[1] = VM_UVMEXP;
      usize = sizeof(uvm_exp);
      if (sysctl(mib, 2, &uvm_exp, &usize, NULL, 0) < 0) {
        fprintf(stderr, "asmem: sysctl uvm_exp failed: %s\n",
          return -1;

      /* setup pageshift */
      pagesize = uvm_exp.pagesize;
      pageshift = 0;
      while (pagesize > 1)
              pagesize >>= 1;

      /* update state */
      state.fresh.total =  pagetok(uvm_exp.npages);
      state.fresh.used = pagetok(uvm_exp.active);
      state.fresh.free = pagetok(uvm_exp.free);
      state.fresh.shared = 0;  /* dont know how to get these */
      state.fresh.buffers = 0;
      state.fresh.cached = 0;
      state.fresh.swap_total =  pagetok(uvm_exp.swpages);
      state.fresh.swap_used = pagetok(uvm_exp.swpginuse);
      state.fresh.swap_free = pagetok(uvm_exp.swpages-uvm_exp.swpginuse);
      return 0;

/* default /proc/meminfo (Linux) method ... */

int read_meminfo()
	int result;
	result = lseek(fd, 0, SEEK_SET);
	if ( result < 0 ) {
		error_handle(2, "seek");
		return -1;
	result = read(fd, buf, sizeof buf);
	case 0 : /* Huh? End of file? Pretend this did not happen... */
	case -1 :
		error_handle(2, "read");
		return -1;
	default :
	buf[result-1] = 0;
	result = sscanf(buf, "%*[^\n]%*s %ld %ld %ld %ld %ld %ld\n%*s %ld %ld %ld",
	case 0 :
	case -1 :
		printf("asmem: invalid input character while "
			"reading %s\n", state.proc_mem_filename);
		return -1;
	return 0;

#endif /* (else) HAVE_UVM_UVM_EXTERN_H */

int open_meminfo()
	int result;
	if ((fd = open(state.proc_mem_filename, O_RDONLY)) == -1) {
		error_handle(1, "");
		return -1;
#endif /* !HAVE_UVM_UVM_EXTERN_H */
	return 0;

int close_meminfo()
#endif /* !HAVE_UVM_UVM_EXTERN_H */
	return 0;

It wasn’t neat.  It increased code complexity and maintenance costs, but it worked.  And we all accepted it as the best we had for now.

Hopes of a Brave New World

Like many cross-platform advocates, I had big hopes for Java and C# with the Microsoft .NET Platform.  But sadly we never saw the fulfilment of their “platform independent” coding promises.  Too many times we have to choose between a GUI toolkit for a platform and looking out of place.  Other times we had to P/Invoke to native APIs to get at functionality not exposed or reproduced by the frameworks.  Even now the GUI toolkit Gtk# is recommended over standard Windows’ System.Windows.Forms on Mono when creating C# programs for Linux or *BSD.

Cross Platform Toolkits such as SWING for Java and Qt for C++ sprung up to abstract the user from the platform they were working with.  But they were primarily GUI toolkits and their APIs only went so far, and eventually, like it or not, all but the most simple applications ended up with a native API call or two wrapped in an #ifdef style condition.

How Web Development Made it Worse

With the rapid increase in Web Development many saw this as finally the way to deliver software across multiple platforms.  Users accessed software via a web browser such as Netscape Navigator and didn’t need the code to work on their own PC or operating system.

Of course behind the scenes the CGI programs were still platform specific or littered with #ifdef statements if they needed to work on more than one server OS.  But the experience of the end user was protected from this, and it looked like a solution may be in the pipeline.

But then the Netscape vs Internet Explorer browser wars happened.  Browsers competed for market share by exposing incompatible features and having sites marked as “recommended for Netscape” or “works best in IE”.  People wanting to support multiple browsers started having to litter their code with the JavaScript equivalents of #ifdef statements.  The same happened again CSS as it became popular.  Nothing really changed.

Enter the Mobile

Then along came the iPhone, and made a bad situation even worse.

Those who went for a native implementation had to learn the rarely used Object-C language.  This helped Apple to avoid competition as developers scrambled to be part of the mobile revolution, but deliberately made portability harder rather than easier.  That still remains part of their strategy today.

People turning again to the web for solutions found that accessing web sites carefully formatted to look great on 1024×768 screens, now being viewed on a tiny mobile phone screen in portrait orientation – was ugly at best, but more often unusable!  And it wasn’t just about text size.  Touch and other mobile specific service meant users expected a different way of interacting with their applications, and browser based software felt more out of place than ever. Yes Responsive Web design and HTML 5 go a long way towards solving some of these web specific mobile issues, but it doesn’t take us away from the #ifdef style logic that has become an accepted part of web application development as it did C and C++ development before it.

So What is to be Done?

Most of this article has been about a history of failures to tackle cross-platform software head on.  Each attempt did bring us a little closer to a solution, but throughout we resigned ourselves to the fact that #ifdef style code was still ultimately necessary.

As application designers and developers we had to choose between how native our applications felt and limiting users from using our software in situations we didn’t plan for.

For almost two decades I’ve been involved in trying to overcome this cross-platform problem.  Now the landscape is more complicated than ever.  Can the same software really run without compromise both inside and outside the browser?  Can we really have a native look and feel to an application on a mobile, tablet, and as desktop PC, is wearable computing going to be the next spanner in the works?

All this is why to move forward, we went back to basics.  We thought first about how software was designed, rather than the libraries and languages that we used.  We first made the Mvpc design pattern, and only then did we make there reference libraries and the commercial Ambidect Technology (soon to be known as Ambicore).  Its fair to say that our many years of experience led us to be able to finally learn from the past we had been so involved with, rather than allowing ourselves to repeat our mistakes again and again.

Because Ambicore provides access to the whole .NET Framework gives a complete cross-platform API that’s developers already know.  Use of C# as our first reference language gives us access to the great thinking that went into creating the Java JVM and Microsofts IL environments that really can abstract us from the operating system and help us avoide #ifdef statements.

Providing native GUI interfaces for each platform means applications using the platforms own recommended toolkit helps applications look and feel native everywhere – simply because they are native to each platform.

Providing a design pattern that works equally well in request-response stateless environments and in rich state-full environments allows us from day one to provide a browser based experience for those who want or need it, as well as a native rich client experience for those wanting to get more from their Windows PCs, phones, tablets, Macs, Linux, *BSD, or…

Its taken 17 years of personal involvement, and recognising and listening to visionaries in the industry.  But by standing on the shoulders of others we re-thought the problem, knowing #ifdef statements were as much part of problem as they were a solution.  We redesigned the development pattern to be portable by default, not as an after thought.  And we based our reference libraries on trusted platforms from market leaders such as Microsoft to make our technology available to the largest pool of developers possible in a language, framework, and IDE they already know.

We are stepping into a new chapter of software development where the platform and device is there to enable, not restrict, the end user from the software they want.  And just as we stood on the shoulders of giants to get here – we want you to join us in the new world too.

What is Mvpc and Where did it Come From?

Introducing Mvpc

Mvpc (Model View Presenter Command) is a new design pattern and reference library for designing and building software applications and mobile apps.  The design pattern has been in circulation for a little while, but its true impact is only beginning to be understood and as the creator of Mvpc I’ve been asked a number of times to explain its origins, why a new approach was required, and how we arrived at the breakthrough.

Over the coming weeks and months we’ll take a look at specific usage of the pattern and each of it layers and techniques in detail; but this post is designed to lay out the basics and help you understand where the thinking behind the new pattern came from.

If you want to look at the reference implementation of the technology contact me or anyone at Ambidect.

The Origins of Mvpc – The Multi-device future

Whenever you are faced with a problem you should always look at how others have approached the problem before, and see what lessons can be learnt from these previous attempts, however successful or otherwise.

One of the biggest problems facing the software industry at present is: how do you create software that can run on any device, without having to build separate programs or apps for each platform?

It used to be that everybody expected to do “real work” on a Windows PC.  But now people want to do real work anywhere, and everywhere.  It started with the advent of smart phones first, and then doubled as tablets started to dominate the living room computing experience.  And those changes have had unexpected and unpredictable impacts on business impact with the establishment of BYOD polices and the significant growth in Macs returning to the workplace.

This all means that not only can we now not expect a single type of operating system, but we can’t specify a minimum screen size any more, or even assume a keyboard or mouse are available.  With new devices hitting the market every day has the problem  significantly worse; and if left unaddressed would become a threat to the entire software industry, not just individual companies.

Businesses buying software are left in a position of having to predict which devices they will want to use three or five years from now and tie the success of their business into those platforms.  How can they make an investment decision with such uncertainty?  Can they even find two experts that agree on which devices will still be around ten years from now?

Businesses wanting to reach a large audience are having to spend large amounts of money, often with different developers or development companies, to keep up with the demand of consumers.  With many people now having access to two or three devices of different types and wanting to access your service on whichever one happens to be closest to them right now.

Software developers and companies are being forced to specialise in an individual platform to be able to hire and train staff efficiently enough to keep ahead of a demanding changing environment.  This gives a growth to a growing number of small development companies specialising only in one platform. iPhone App development companies, Web Development companies, Linux Developers, Windows Phone Specialists and the list goes on.

This proliferation means businesses are being forced to repeat the same work with multiple companies at great expense.  And just when the development feels complete, the combined quotes for the first major enhancement brings the eye-watering reality of the unsustainability of the approach.

Despite all of this, us as users are constantly expecting more and more from each device we carry.  We are frustrated when our phone can’t open an attachment to an email because the program isn’t available.  We feel restricted when we sit at a Mac and try to do our accounts.  We get asked “can you put this on my iPad” and have to spend hours trying to explain why its not possible because the great application just doesn’t work on iOS yet.

Mvpc is designed to solve this.  Its designed to change the way people look at software development.  As its principles get adopted across the software development industry it will allow one development to be undertaken that does run on all platforms.  It will reduce development costs without reducing your potential market.

Most importantly of all, it will put the power back in the end user’s hands.  When you find the right piece of software, you won’t even ask if it will work on your new phone, tablet, friends PC, or at an internet café in an airport; because in our vision of the future everything will work everywhere.

We genuinely believe that one day all software will be developed using the principles that drove us to put together the Mvpc design pattern.  I hope we’ll look back to the days of awkward single-platform development with same nostalgia, some look back at Assembler, Smalltalk, and Windows 3.1.  Each was a significant in the way it got us to the next page of the technical future, and we are about to turn another page to a world where software is independent of device.  A future where users make the choice on how, when, and where to use a service, not developers, and not budgets.

What Others have Tried and Failed

People have been trying to solve the problem for years, even before we all got so many devices around us.  All these attempts I have come across however can be grouped together under three broad categories:

  1. Creating applications that execute on a server and use a web browser to connect and view information.
  2. Providing a cross-platform GUI toolkit.
  3. Encouraging libraries to be built with reusable methods, and then trying to keep the platform dependent code as small as possible.

Each of these approaches have a lot of good in them, and can be useful.  But on their own they provide significant drawbacks.  I’ll address a few of the pros and cons of each here briefly, but in time I’ll add individual posts that go into the details of the points made here:

Creating browser based applications

Responive Web Design is becoming a very popular buzzword in the technical and marketing industries right now with a growing number of browser applications that are appearing in the SaaS arena but the idea of solving the problems of platform independence with a web browser predates even the start of “the end” of Microsoft’s monopoly on the devices we use.  Going back five to ten years, many IT departments decided to adopt a “browser only” policies to introducing new software.  What has this experience taught us?  How does this mean response web design if left alone will manage?


  • Existing skills can be used to create screens that are easier to use on different screen sizes.
  • Browser compatibility can be checked with the new software, rather than checking OS compatibility.
  • Can be used from any PC or device with a reliable internet connection.


  • Application can’t be used and data loss can result if connection to the internet is interrupted or unavailable.
  • As the number of users grow server farms and load balancing are required to handle the growing demands as all processing takes place on the server.
  • Developers are required to learn to work with an ever increasing complexity of pre-built scripts, techniques, languages, and browser oddities, to try and make the user experience as rich as possible over the limited stateless request-response drive technology.
  • Applications do not feel native on any platform.
  • Applications have to be tested on all browser platforms and version before release which can be costly.  More often they tend to end up branded with “Best viewed in Internet Explorer 8 or above” or “For best results use Firefox” as each browser comes with its own set of limitations and problems.  At its most extreme I’ve seen whole IT departments unable to upgrade from IE4 or IE6 because its the only browser all the historical application work reliably under.  This also limits the ability to adopt new applications that understandably require newer browser versions.

Providing a cross-platform GUI toolkit

For people not satisfied with the limitations of a web browser, the primary approach has then been to look at  creating a common API across all platforms.  Sometimes this is done by creating a whole environment and GUI toolkit, as was done with Java and swing, others have focused primarily on the GUI such as Qt and Gtk+ only later extending to non-GUI operations.

To date these tend to focus on the desktop rather than mobiles, although some do exist for mobiles.  At their heart they often require the learning of a specific object model, and the creation of code that is heavily tied into the toolkit via inheritance.


  • Application runs natively on the device and does not require constant internet connectivity.
  • Application works identically on each platform with all features available.
  • The GUI toolkits tend to be quite larges and provide a good selection of controls to build custom interfaces they way you want them.


  • Application often doesn’t feel native on any platform or feels built to other platforms GUI guidelines (what platform does GIMP feel native on for example?)
  • Cross platform experience works across the desktop, but doesn’t address tablets, or mobile well.
  • Can’t be used from a friends PC or internet café as most require installation of the application and its toolkit.
  • Developers are restricted in the libraries they can use to provide underlying functionality to avoid introducing a tie back to a single platform again.

Encouragement to keep GUI code minimal

Another way of trying to solve the problem is to accept that the GUI and some base functionality is always going to need to be built separately for each platform.  Teams of developers are encouraged to keep the platform specific code as small as possible and usually need to be organised into groups based on the platforms they can work on.

Its normal that the platform with the biggest initial target market tends to get the majority of developments, with other platforms playing catch up (for example have noticed the difference between using Skype on Windows or on Linux?).  In fact often features simply never make it to these “second class” platforms.

Generally by choosing this approach the decision is made at the start to either target a stateless environment such as the web, or a state-full environment such as a native GUI client.  Once made this decision is hard to reverse.


  • Developers creating a version for a specific platform can use all the tools available for the platform.
  • Applications both look and feel native to the platform they are running on.
  • Code that is able to ignore the GUI and file system altogether can be shared across platforms as a cross-platform library.


  • Development team needed for each platform and sharing of code between platforms is limited.  With mobile becoming increasingly important and competitive, and Macs making a come back in business that means four full development teams are required just to handle Windows, Mac, iPhone/iPad, and Android before you even look at platforms like Windows Phone, Surface, Windows 8 and RT applications, Linux, and blackberry.
  • Usually development takes place against the primary platform, often Windows, or iPhone depending on the nature of the program.  Users using other platforms often feel second class and unimportant and many times migrate to an alternative that targets their platform as its primary platform.
  • Every development and enhancement needs to be performed and tested on every platform making it very expensive to enter the market and keep your product updated.

So why is Mvpc Different?

To understand why Mvpc is different you both have to understand what it does, and also what it doesn’t try to do.

Mvpc Does Not

Mvpc does not try to repeat the mistakes of the past by creating a new library or a specialist way of development that requires full retraining of developers and the throwing away of old code and applications.

Mvpc does not try to compete with the three previous approaches in the hope of having a longer “pro” list and a shorter list of “cons”.

Mvpc Does

Instead with Mvpc what we tried to do is embrace how developers already want to work and how users already want to use their devices; and look instead at the fundamental question of how we understand the software design and development process.

Mvpc actually embraces all three of the above described ideas as part of a successful solution, rather than a past failure.

Applications built for example with Mvpc work both natively and are also available separately in a browser.  This means they are available online and offline.  Giving the best of browser based and native applications.

Not only is the GUI completely responsive in its design.  But the application can automatically make use of platform specific features such as GPS or click to dial capabilities.

By following Mvpc 80 to 95% of the code you write will work across all platforms and all device types out of the box.

As the reference implementation of Mvpc (licensed commercially as Ambidect Technology) is built with C# and compatible with any Microsoft .NET language letting you use the skills you already have in your team without significant retraining.

A cross-platform toolkit libraries is included alongside the Mvpc reference library, giving you the benefits of cross-platform libraries, but without forcing you to use a foreign looking GUI as there are built in native GUIs for each platform that can be expanded using the normal platforms GUI toolkit, not a custom one.

Because of this you will be able to use your existing .NET libraries, and applications and most cases port substantial portions of them to be cross platform.

You can access the full native API safely when you are working on a platform specific enhancement, and know that you will be protected from those APIs when working in the portable code.

Using Rapid Prototyping, as is built into the Mvpc design from the ground up, you will be able to create working applications in days not months, and see how applications work on every platform from day one.

Using our Cross-Build-it service you will be able to produce native clients for every platform from a single code base as well as a separate fully functional web site version.

Because your apps are native you can publish them through the Apple iTunes App Store, Windows Store, Mac Store, and various Androids stores.  This opens your apps for maximum discoverability and the most native feel possible.

Mvpc Embraces Existing Design Patterns

Once developers realise the benefits of Mvpc and want to use it for themselves I often get asked “how does Mvpc compare to MVC” or “I’m used to MVVM and I don’t want to waste all the time I’ve put into learning the pattern and toolkits.”

Many platforms use a GUI toolkit that not only works better with a specific design pattern, but now days require it.  With Mvpc we don’t try to fight against this, and we don’t want to loose or ignore existing skills that you have worked hard to gain.

The Rapid Prototype and native GUIs we provide are all built using the native design pattern of the GUI.  You will also use the toolkit and pattern you are already familiar with for the GUIs you provide for yourself.  This is possible because Mvpc is completely compatible with the MVC, MVP, and MVVM design patterns.  If you are used to working in any of those patterns, you can continue to code pretty much as you have before.  With just a little bit of learning and thinking the extra features of Mvpc become available to you and the transition into fully portable software will be very natural.

As you can imagine at this point the developer talking to me lets out a big sigh of relief knowing Mvpc is not about forgetting what you know, its about learning a new way of positioning the puzzle pieces you already have.

Why is Mvpc Succeeding Where Others Failed?

I believe Mvpc is succeeding because it hasn’t tried to compete with others but views all past approaches as stepping stones that when positioned correctly form part of the best possible solution.

Rather than providing a strange new design pattern and asking you to forget your past learning, we’ve designed the new pattern so it follows all the core principles of the leading design patterns developers already use, but helps position the logic correctly to automatically create portable software.

Rather than joining the decade long argument of the pros and cons of native applications vs Response Web Design and browser based solutions; we claim both sides are right, and ensure your application is available both: natively, and as a responsive web application.

Rather than creating a new language, or asking you to learn an obscure toolkit or pre-processor built on top of C or C++; our reference implementation library adopts Microsoft flagship development environment the .NET Framework.  We give you the choice of language with C#, VB.NET, J#, F#, and managed C++ all supported; and thereby keep all the existing libraries for those languages and platforms available to you.

Rather than asking you to carefully pick from a list of pros and cons and hope your customer or developer agrees, we put the choice back where it belongs: You to develop the way you like to develop.  Your customer uses the software however and on whatever they want to.

If you stop and think about it, we shouldn’t be asking why Mvpc is succeeding; the real question is why has it taken so long for our industry to understand two very simple principles:

The end user should have the choice of what they do with their software, and the developer should also have the choice of how they develop the software.  These two things are not mutuality exclusive as we have been told in the past, but part of a win-win solution.

Second, we shouldn’t complete with failed passed attempts based on their “cons”.  Instead we should combine them based on their “pros” so they can make up for each-others weaknesses.

You see Mvpc, as great as it is, isn’t really some magic new way of doing things.  Its the simple idea letting you make a choice that’s right for you, and making sure your choice doesn’t restrict somebody else’s freedom to choose in the future.