Fog Creek Software
Discussion Board

Cost of porting applications

Hi guys,

I have a Mac application that folks frequently ask me to port to Windows. Such a port would have to target all major windows installations - 95, 98, NT, and XP. I am busy with other projects and so if I do this I would hire the job out to someone with expertise in this work. But before I even think about it I need to estimate the cost of doing so and raise the money. I know that some shops will give nonsfixed estimates for this sort of work, but I need to know the actual cost rather than estimate that isn't tied down to anything.

The project is currently 120,000 non-comment non-blank LOC. It interfaces with over 1,000 hardware devices and has custom code for dealing with about 30 categories of them. It is real-time and has sub-millisecond latency requirements. The interface is fairly sophisticated, on par with programs like Photoshop.

Has anyone ever done such a port and has numbers for the actual final total cost? I am seeing estimates ranging from 10 cents per line to three dollars, meaning it would cost $12,000 to $360,000 to port which is a pretty big range. It seems like the most common time to port a project of this size is one year, but I personally think that with all the hardware and timing issues it will take at least two years -- the app represents about six man years of development time up to this point.

Also if anyone has had experience with outsourcing this sort of thing, are the companies that do this sort of work reliable? How much should I expect to spend on an attorney to draw up the necessary contracts? Will I have to hire someone fulltime on my own end to oversee this project? If so, what sort of person do I look for and what are his/her salary ranges?

And finally, is there anything I am overlooking?


outsourcing newbie
Tuesday, May 20, 2003

You didn't mention what languages and tools/libraries your application was written in. This makes a huge difference. 

The different flavours of Windows are fairly similar, so it should be only 1 port (or 2 see note in a minute) not one for each of 95, 98, etc.

The scariest part who would be the hardware stuff.  I would imagine this might almost be a rewrite. I have not looked at any driver type stuff since Windows 3.x but I understand the 9x and NT series of Windows device driver interfaces are fairly different.

Another thing that would make a big difference is if your application is already divided logically into say an engine and a UI as opposed to being one big app. In this case, the engine might be ported, and you virtually rewrite the UI (depending on the language). On the other hand if the stuff is all mixed up, it could be more difficult.

S. Tanna
Tuesday, May 20, 2003

Hi, thanks - yes an obvious omission.

The project is about 70% C, 30% C++, and a few hundred lines of assembler, with both 68k and a PPC versions.

It's currently a Metroworks project but does not use their framework -- it's an entirely custom framework that is not MVC unfortunately but rather derived from taming the vaguaries of the Mac toolbox API. The GUI code requires extensive refactoring at this point to be porting-friendly. I myself am doing a lot of that to deal with the OS X port, so the longer I wait on the Windows version, the easier the UI port will become.

The same external hardware will be communicated with on the PC, but the drivers are not just totally different but have different types of information available for querying and so just about all of the driver stuff will have to be almost totally written from scratch and some of it will likely force a bit of redesign. The hardware stuff is also intertwined with the UI in a bad way (but good from a customer standpoint since the capabilities are exposed to them) and will certainly end up affecting the UI.

Roughly, I'd say about 25% of the code deals with hardware and realtime, 10% with a large number of files supported (all of that uses c standard library calls so little work needs be done there). 20% is very specialized custom math routines that can be ported without any change, and the remaining 45% is UI stuff. Again, roughly.

Thanks again.

outsourcing newbie
Wednesday, May 21, 2003

Without giving the game away, what sort of application is it?

Geoff Bennett
Wednesday, May 21, 2003

Oh, forgot to mention - yes the driver stuff is different in NT and 95/98 according from what I've gathered, so that stuff will need twice the effort and might even affect the UI differently in each case. I'd like to skip the NT version altogether as there are fewer potential customers on that platform but my understanding is NT and XP are similar and people are migrating to XP so might as well test for it as long as having to do the XP version. So I guess there's really the 95 case and the XP case. I don't know much about what I'm talking about here, I did 95 development back in 96-97 but am very out of date now.

outsourcing newbie
Wednesday, May 21, 2003


A shrinkwrap music application. Any more there would give the game away!

outsourcing newbie
Wednesday, May 21, 2003


the hardware stuff is going to seriously bite you on the ass, dont believe any optimistic estimates of that cost you get.

On a rather more trivial note, your best bet for porting the GUI might be to use something like wxWindows (*very* good framework).  wxWindows provides a x-plat gui for win32/mac platforms and you even get various *nix platforms as a bonus.

For this project though the hardware stuff will burn through the cost....if at all possible Id jump through many hoops to reduce the # of devices you have to support at the beginning, you can always add more later but to begin with Id try to go for as few as possible.

Wednesday, May 21, 2003

Oh, and it does do some platform abstraction -- for example everything using the Mac's pascal strings is wrapped and all string handling is done with zero-terminated C strings. There are other parts where there is an effort to abstract out the Mac way of doing things, but only the string handling is really -done-. Even so, it probably doesn't matter anyway since much of that code is moving data into and out of the Mac's API stuff and is going to have to be touched nonetheless.

outsourcing newbie
Wednesday, May 21, 2003

You don't work for (ex) emagic, do you... ;)

Well, that explains the hardware requirements. I'm guessing the UI would be fairly customised too (I was a professional musician - keyboards - so I have a pretty good idea of what you may have there, considering I routinely use the same sort of software).

I think the biggest problems will come from dealing with the hardware. The mac (I use a PC at home for music) seems to have nicer hardware support for things like audio, so I'd imagine (clueless really) that there would be a few more hoops to jump through on the PC.

A lot of the newer PC music software seems to use the DirectMusic/DirectX API.

I think you're a bit more bang on with the 2 years estimate, and I can't see this costing $12,000 to port. The stuff like the file format/in memory storage etc should be pretty straight forward, but the actual "engine" part of the code I feel will be significantly different. The UI is six of one. If there's a bit of custom drawing code in there, the logic for it should be able to come straight across, but obviously the base API will be different.

I feel you'd be much closer to the second cost estimate than the first. You may be able to employ a windows dev to handle it for you, but over two years I don't think you'll save a lot.

Did this start off as a hobby project for you that kind of blew out to something more? If so, you may be partial to taking a bit longer to do it and finding someone who has more than a financial interest in porting it.

Geoff Bennett
Wednesday, May 21, 2003

Thanks fullname, I'll look into the wx! Mayeb that can help with the OS X port too -- as a goal, I'd love to get this stuff as abstracted up as possible, ideally converting all the UI to MVC, but I have a long way to go there.

outsourcing newbie
Wednesday, May 21, 2003

Something I forgot to mention: If you do consider going with the DirectX API, you will abstract out a lot of the hardware issues straight away, but it does add problems of its own.

Although, it will open your app up to a world of FX plug ins.

Geoff Bennett
Wednesday, May 21, 2003

I think it also makes a huge difference whether your objective is to make a single set of sources (not all of which are used on each platform) to build the app, or if you don't mind ending up with 2 sets of similar source.  There are pluses and minuses to both

Years ago I had good experiences porting from Win16 to Mac using the MS cross compiler, and to UNIX using MainWnd (actually I didn't do the work, but somebody in my group did)

From inter-UNIX ports, I might add, do not understimate the importance of things like byte ordering.  In a low level app (or sometimes a high level one in C/C++) stuff like this can really bite, - even if you get em all, months after you release some obscure bug gets discovered that is caused by this.

From where you are now - Realistically I would say you'd be looking at least as much effort as doing the whole app again, this time on Windows, and more if you want the sources to be shared across platforms.

S. Tanna
Wednesday, May 21, 2003

> - Realistically I would say you'd be looking at least as much effort as doing the whole app again, this time on Windows, and more if you want the sources to be shared across platforms.

By this I mean, you might get a head start because you have some routines that come over. But if the source is getting messy already, it might not be nearly as much help as you think.

S. Tanna
Wednesday, May 21, 2003


Yes these are my concerns. There are both audio and MIDI issues involved and both are very different from Windows.

My 96-97 work involved among other things writing vxds and dlls and very early DirectMusic drivers for audio hardware, but I didn't keep up or even keep it in memory. I remember enough to know it would be better to find someone else who is up on it.

I think you're right about the cost -- my intuition was that the low end of the range probably covers projects where some batch script in basic is run through a converter to make it into c and then tested. A lot of the code is going to have to be looked at, understood and thought about before deciding what to do and I think that is going to be expensive. I know it would cost me more than those estimates to do it myself. I wanted to run the numbers past you guys with experience in such matters to see what you thought and I'm glad I did.

Yes, it started as a personal project to solve some of my own needs; I took it commercial about three years ago after seeing there was some demand and sales and interest have steadily increased. I often get inquiries about a Windows version, sometimes pointing out to me things about the 90% market share of Windows, although I am pretty sure that the music market is evenly divided between the mac and the PC so I think it would be fair to expect sales to double with a Windows version.

Am I understanding your advise on taking longer to possibly mean save money and reduce effort by continuing to refactor to MVC on the UI as part of the OSX port (which also requires completely abstracting the MIDI routines too, the audio in OSX looks about the same as in classic...) and then, by delaying a windows version, make it much easier to port and not have to pay twice? Hm, even if you weren't saying that it sure sounds like the right thing to do now that I am saying it.

Could you expand on what you mean by 'finding someone who has more than a financial interest in porting it'? I am not sure what you mean here. What I was thinking is to round up a venture capitalist with $ or find a commercial company wanting to license it or something like that and present them with sales figures and projected costs of the port and then do up some sort of arrangement with them, while retaining 100% ownership and control on the Mac side of things, making that a separate thing.

outsourcing newbie
Wednesday, May 21, 2003

My goodness, twice in the one day I've head the words "i think you're right", and "Geoff" in the same sentence! :)

As far as market share, I think you'll still find professionally it falls more toward the Mac than the PC. As creative as many musicians are, they see the Mac as a creative platform, and the PC as a business platform. I have friends who opted for the PC/Cakewalk avenue only to later regret not going for a Mac. Not that there's anything wrong with the PC avenue, and god knows it's infinately better than 5 years ago, but it's more of a "If XXX is using one, maybe I should be too".

I think the issue you'll have is Cakewalk's dominance on the PC platform. Although, they are now basically up with the Logic/Cubase level of pricing and features. Something almost as powerful for less cash could make inroads.

Now, if I read correctly, the Darwin base of OSX is more or less BSD. Linux is lacking in the music software area something chronic. If you were to spend the time porting to OSX while improving the code structure with MVC, proper modularity etc it may be very easy to port to one of the Linux flavours, seeing as you would pretty much only have to alter the UI side of things.

So hopefully, two easy ports for the price of one (sort of...). Although, not having written software for either platform, I am just hazarding an educated guess.

As far as taking longer, I meant the actual port would take longer than a year - closer to two. It was almost a couple of years (IIRC) between Cakewalk 9 and Sonar 1, and they had a windows code base to start off with. What I was suggesting was, that by hiring a windows developer yourself, you may save money versus paying profit overheads of a third party company. You'd be wearing more of the risk of development, however. So to that end, it may save you some money if you were willing to try it.

What I meant by finding someone who has more than a financial interest was actually scouting for a windows developer who would be interested in being part of the project from the same point of view as you. More of an emotional buy-in, over financial buy in. Someone you mightn't actually have to pay to do the work (so it may take longer - thus allowing for the refactoring for OSX as well), but your costs would be significantly lower up front, and then maybe you cut them in for a percentage of the net, or something. I'm not implying myself here, either. :) I would be kidding myself and doing a gross injustice to you to even pretend that I would be capable of something of this magnitude. But there are people out there who would be more than capable of doing it.

Geoff Bennett
Wednesday, May 21, 2003

"Thanks fullname, I'll look into the wx! Mayeb that can help with the OS X port too -- as a goal,"

Thats how Id use it, depending on how far you have got with the osx port Id think seriously about making it a wxWindows port instead, focusing on the osx build. 
Once you have that working you should then have one codebase for both classic and osx (wxWindows does this very well, I have been very impressed with its macintosh functionality for both osx and classic).

From there you would have the win32 GUI pretty much working, bound to be a few tweaks needed of course but again Ive found wxWindows to be verra good here.
Which leaves you with 'only' the backend/hardware stuff to do...the nice thing being that you get to focus more on the important/difficult stuff.

Wednesday, May 21, 2003

I've ported a shrinkwrap from Mac OS to Windows(all versions). The lines of code were almost the same as yours. Before porting I had to investigate a lot for about 4 months and have my specs ready. After that it took 3 people 4 months to release the Windows version.
On Mac we had used MPW and on windows CodeWarrior. But even Visual studio will do fine. We had our own framework in C which we had to port to windows and then port our application code. For GUI we used Windows tools which we thought will be not worth the effort of porting. There is only one code base for both the compilations. So now any chnges made in future versions will be reflected in both versions i.e Windows , Mac OS 9 and X.
So before you outsource be careful if the person has enough expertise on both platforms. Decide which things you want to port and which ones to rewrite. If you want any more info feel free to mail me.

Wednesday, May 21, 2003

I'd be very carefull with this one. This is no ordinary port as it involves a lot of very platform specific stuff. e.g. The realtime behavior of the Mac and PC are very different.
My guess is you'd be probably almost looking for a complete rewrite, with the Mac version as the spec, with the exception of some of the algorithms of course.

Drop the 95/98/NT requirements from the list completely and focus on XP. Yes, there are still a lot of 98 installations out there, but they do not spend money on buying new apps. NT 4 has 0% market share for the type of app you describe. Don't even think of earning money from Linux for this.
Forget about the wxWindows interfaces for this. Too generic. You want a much more "creative" and responsive interface style for this type of market. People write custom GUI toolkits in DirectX for these applications.

Look for people with specific, demonstratable experience in realtime music applications on the XP platform.
I can get you in contact with some European company specialized in this field, but then we would be talking serious investments, beyond the simple "can someone quickly port this for me".

Just me (Sir to you)
Wednesday, May 21, 2003

Hi JustMe,

"I'd be very carefull with this one. This is no ordinary port as it involves a lot of very platform specific stuff"
I totally agree, I vaguely considered offering a quote myself but to be honest Id rather crawl over broken glass on my hands and knees than offer a set quote to get this upclose and personal with windows hardware drivers again :)

"Drop the 95/98/NT requirements from the list completely and focus on XP"
makes some sense for the initial version....Im not convinced you are entirely correct about xp though, Im not sure its been adopted as widely as this implies.  Id look at maybe 98 and xp versions first and look at doing the rest later.
Since you have to do one of those first moving on xp to begin with makes some sense.

"Forget about the wxWindows interfaces for this. Too generic. "
with respect I must totally disagree, the wxWindows widgets are native for each platform it is deployed on, and as with any other c++ framework the interface itself is not required to be generic or unresponsive unless its written that way.

Wednesday, May 21, 2003

On the 98 issue:
Considdering we are looking at a product release around june 2004, keep the following in mind:

"Mainstream support for Windows 98/98 SE ended on June 30th 2002, and no-charge incident support and extended hotfix support ends on June 30th 2003."

Trust me, you do not want to bother with 98. Concentrate on XP, after that, concentrate on Microsoft's next release for the client OS.

I did not want to say anything bad about wxWindows. I appologize it came out that way. What I wanted to convey is that in this market, people do write there own GUI toolkit, for the same reason they do for games. Even though MFC, WinForms and a gazillion of others are available. The interface is crucial and very different from a form based business app paradigm.

Just me (Sir to you)
Wednesday, May 21, 2003

Hi JustMe,

"I did not want to say anything bad about wxWindows. I appologize it came out that way. What I wanted to convey is that in this market, people do write there own GUI toolkit"

I actually realised I had mis-read your post just after I replied.
By 'generic' you meant more 'common' <g> or something like in 'it would be better to design your own gui toolkit from scratch and use that'

Depending on how complex his current GUI is and how much time he wants to spend doing so its not a bad idea.
<g> although Id argue that he could do that more quickly in wxWindows than in many other frameworks...

but putting that aside..

building an entire GUI widget set from scratch is fraught with difficulties and usually not really necessary or desirable, when its done it can take a long time to get right (how long did it take mozilla to include standard key shortcuts in their text fields?) and often never really meets the level of consistency users prefer to have.....<g> although you could argue that level is not verra high on the win32 platform...
Usually its overkill anyway, more often you can achieve the look you want by having a small # of custom widgets and mixnmatching them with a standard set, giving a verra good overall effect but still letting you give the app its own feel.

Im not going to argue any further regarding the 98/XP side....your point about writing for 2004 was a good one, and certainly I fully agree that at the very least beginning with XP is a good plan, time enough to decide the next step once that is complete :)

Wednesday, May 21, 2003

This isn't really an outsourcing project. You need a software house, or an excellent software engineer or three.

There are several aspects of this project that expose you to high risk, and for which you should thus hire the best people you can find:

- It's a big Windows project
- it involves hardware issues and probably byte ordering and so on
- it's esoteric and, to cap it all,
- the development effort has to first understand your existing code base and
- probably to try to maintain compatibility with it.

Wednesday, May 21, 2003

Music is a big hobby of mine so music software is a topic near and dear to me.  Also, I'm a professional Windows developer with a little experience with developing music-related apps for personal use.  One of the first major projects that I worked on involved porting a Mac app (that had a fairly extensive UI and involved some special hardware) to Windows.  In other words, I have a lot to say about this!

First of all, I'd recommend looking into hiring a developer rather than outsourcing the work.  After the port is done, you're going to have to maintain it and update it.  Having them work close to you will give them the opportunity to ask you quick questions about Mac programming, or hardware specifics, or specifics about your code.  It'll also give you the opportunity to see that they're doing things as intended and to get instantaneous feedback on progress.  I'm guessing you probably have a ton of recording hardware sitting around for developing and testing with.  If you outsource, you're going to have to deal with getting hardware to them and thus either shipping back and forth often or funding purchases.

I agree with targeting 2000/XP if you can get away with it.  It's much nicer from a development standpoint and from a user standpoint (particularly when dealing with large memory and file sizes such as with digital audio).

One BIG recommendation I have for you is to avoid duplicating Mac user interface idioms on Windows.  Ports from Macs to Windows often are horrible for this reason.  The developers decide to mimic the Mac user interface which makes life hell for people used to Windows.  Your tool bars, message popups, dialog boxes, etc. should act like Windows.  I use Sonar over some of the Mac ports (Pro Tools, Logic) simply because the Mac ports try to mimic a Mac UI and thus are horrible for someone used to Windows.  Little things like having the OK and Cancel buttons on a message popup in different places (or with different names) can make using an interface very annoying.

Working from a common source base should be possible.  Obviously, if you follow my UI recommendations, you'll have differences in the top level application code, and given the hardware differences, you'll have different hardware code, but most of the code should be shareable.  We used a common source base for the port I worked on and managed to share pretty much everything down to the main event loop.  It makes the code much more maintainable in the future since you can fix bugs and add new features in one place.

I'm hoping that the software we're talking about has the initials D.P.!

Wednesday, May 21, 2003

My first real programming job was for a company that specialized in porting applications from Windows to the Macintosh and vice versa (by the time I left, the Macintosh segment collapsed to the point that we were mostly porting from Mac to Windows, but that's another matter).

There are a huge number of variables in the cost equation, and I would be very, very wary of anyone who says "$x per line".

Anyone giving a decent estimate would have to spend time going through your source, checking where abstractions are violated, what modules access the operating system or hardware, what modules access the GUI, what modules access binary files, etc.

With a well structured application, different libraries can be ported one at a time. Unit tests can be modified (or written, as the case may be), and you will have a good idea of how much effort would be required per module, what modules are better to rewrite etc.

A poorly structured application... I would not port for a fixed price. It often ends up becoming writing a cross-platform application with the same feature set.

Because Windows and Macintosh have very different user interface idioms, you may find it easier to maintain two separate GUI modules rather than work with a portabile GUI layer. You'll likely get a more natural look and feel... (I could be wrong about that, though, since I haven't looked at them in 5 or 6 years)

The very short answer: porting is about twice as expensive as you would expect.

Gustavo W.
Wednesday, May 21, 2003


Nine to 18 months with two or three first class developers. Cost $300,000 to $500,000. Inexperienced people and outsourcers would promise you lower prices but would not finish and certainly would not deliver a smoothly working product.

If you're getting VC, get decent funding.

Wednesday, May 21, 2003

" Inexperienced people and outsourcers would promise you lower prices but would not finish and certainly would not deliver a smoothly working product"

LOL nice move...any lower quote is therefore obviously being made by an inexperienced or incompetent person.

Frankly anyone who would presume to make a bid on this project based on the information we currently have available to us is very likely either inexperienced or incompetent ;) 
Before doing so at the very least you should see the current working application, and ideally have an opportunity view carefully selected and isolated areas of the code.

Wednesday, May 21, 2003

*  Recent Topics

*  Fog Creek Home