* The Business of Software

A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.

We're closed, folks!

Links:

» Business of Software FAQ
» The Business of Software Conference (held every fall, usually in Boston)
» Forum guidelines (Please read before posting!)

Moderators:

Andy Brice
Successful Software

Doug Nebeker ("Doug")

Jonathan Matthews
Creator of DeepTrawl, CloudTrawl, and LeapDoc

Nicholas Hebb
BreezeTree Software

Bob Walsh
host, Startup Success Podcast author of The Web Startup Success Guide and Micro-ISV: From Vision To Reality

Patrick McKenzie
Bingo Card Creator

porting from Windows to Mac

I'm a Windows developer, I don't know much about Mac. However, I'm thinking it might be a good idea to extend my market share by offering a Mac version of my Windows software.

Anyone's done that before? Care to share?

In particular I'm interested in how difficult would it be to translate a C++ application that uses MFC for GUI (althought there's a nice separation there and I can easily remove the MFC).
I would also like to know if it's possible to run MacOS in VMWare and if it's a good idea to do it like that.

I'm not 100% committed to the idea, I'm still trying to do a cost analysis, as you can see.

I hope some great souls here will excuse my ignorance when it comes to Mac and will provide some useful help, even if it's in the form of redirecting me to useful URLs.
Mike S
Friday, May 11, 2007
 
 
If you don't have a good reason to think your app will perform extremely well on Macs (very few competition and good demand) don't do it.

C++ and MFC are definitely not the ideal candidates to port. The port is always not trivial, even if the app is in Java you would still need to put some effort in it. And how do you support a platform you don't know well?!?

There are many easier ways to expand your market with 2% than porting for other platforms. Even making a Pocket PC version might make you more sales than OSX version.
Boris Yankov Send private email
Friday, May 11, 2007
 
 
Andy Brice has a good article about it.
Check out in his blog.
edddy Send private email
Friday, May 11, 2007
 
 
You'll want to read this webpage and the relevant linked articles:

http://developer.apple.com/referencelibrary/GettingStarted/GS_Porting/

You should also have a Mac and get used to using it.

If the ported application behaves like a Windows application on the Mac, you are unlikely to make much money unless there is a huge demand (and little competition) in the niche you are targetting.

It can be done, if built right.
Lyndsey
Friday, May 11, 2007
 
 
One more thing, regarding the language. If your MFC and C++ "Core" code are loosely coupled, then porting your application should not be difficult. The C++ code can be carried across (watch out for Byte Swapping issues for PowerPC Macs) and the calls into your MFC code can be instead made into Cocoa or Carbon (I recommend Cocoa).
Lyndsey
Friday, May 11, 2007
 
 
Boris,

The increase of a company's market share is not proportional to the market share of the OS, here 2%, but also a factor of the willingness of its users to pay for good software.
Karel Thönissen Send private email
Friday, May 11, 2007
 
 
It is likely that much of the app will need to be rewritten which will have the benefit of resulting in a real Mac app and not a ported feel if done correctly.

Cocoa is not very difficult to learn but if you'd like to farm it out, there are several good mac developers that may take an interest (my company does this sort of thing too).

What type of application is it?

Good Mac software tends to sell very well despite the "2% marketshare" reports.
Trygve Inda Send private email
Friday, May 11, 2007
 
 
You can't run an unmodified (ie, cracked) version of OS-X under vmware.

However, you can find reasonably inexpensive used G3 & G4 PowerMacs that can run OS-X. This gives you a relatively low-cost option if you are a good bargain hunter.
*myName
Friday, May 11, 2007
 
 
>Check out in his blog.

I haven't written anything explicitly about porting in my blog yet. I may well in future. But there I have posted plenty here about porting to Mac. Search the archives.

A few points:
-its much easier to port an app if you wrote it with that in mind in the first place
-you haven't got to port just the code, but also the help and installation (the vast majority of apps on Mac are just 'bundles' - no installer app required)
-the Mac marketplace is quite different in character to the Windows one
-Mac minis are quite cheap and fine for porting if you beef up the memory
Andy Brice Send private email
Friday, May 11, 2007
 
 
Most probably you are going to have to rewrite your app in Obj-C/Cocoa. If it was a java app it would be a different story and still mac users are very picky about the way an app looks. If it doesn't look native they'll complaint.

No, you can't run Mac OS X on VMWare. You need to get a Mac.

My .02

Friday, May 11, 2007
 
 
"Most probably you are going to have to rewrite your app in Obj-C/Cocoa."

Not true. Carbon/C++ is just fine.
Frederik Slijkerman
Friday, May 11, 2007
 
 
Here's a thought - note the tech is beta/alpha right now, but this is a longer term move.

1. Convert from C++ to .NET C# (Not being a C programmer, I have no idea whatsoever how hard/easy that is. What is with all the {{{}}} stuff anyway?)
2. IF (some research needs to be done here by you) the parts of the CLR you need are in Silverlight 1.1, your core is good to go.
3. Go where? To any PC or Mac that can run current versions of FF, Safari (Mac) or IE as a managed, server served, running on the client app.
4. Write a new UI in Silverlight/WPF (XAML). You have to write a new UI anyway - why not write in what IMO will be the standard across all .NET in the next 6-12 months?

Advantages: Can create amazing UI's connected to .NET code with local (persistent) data storage. totally support Mac/PC. Server based <> piracy. Supports multiple revenue models (tradition buy once, subscription, ad), one codebase across both PC and Mac, <10 second install.

Disadvantages: total alpha/beta/cutting edge bits, 3rd party controls are alpha/beta as well, Silverlight lacks noticeable chunks of the .NET namespace by design (they will never be there.)

I don't mean to piss off Mac programmers (my new pc is a MacBook Pro), but Silverlight means a few million .NET programmers can now write Mac apps, within the context of FF or Safari. Expect disruption.
Bob Walsh Send private email
Friday, May 11, 2007
 
 
>Carbon/C++ is just fine.

Many Mac users will turn their noses up a Carbon based apps because they look dated - different tabs for example. Just the same as Windows 98 style controls look 'old' on Vista.
Andy Brice Send private email
Friday, May 11, 2007
 
 
Most standard controls look the same between Carbon and Cocoa, with a few exceptions. The real pain when using Carbon is that Mac UI layouts have changed slightly (but noticibly) since the olden days when most Carbon apps were designed. The Cocoa dev environment does a better job of defaulting to the 'modern' tack for many of these niggles.

If there's any competition at all in the niche an app targets, a 'modern' UI will play a large part in deciding your success. Cocoa is, to some extent, a better choice for developing more modern UIs, and with Objective-C++, you can mix your backend C++ code and a front-end Objective-C/Cocoa interface. There may have been some updates since Mac OS X v10.1, but there's some basic information about mixing Objective-C and C++ at http://developer.apple.com/releasenotes/Cocoa/Objective-C++.html .

Also, while you may not need to use both, keep in mind that Cocoa and Carbon are not exclusive, and apps can easily use both APIs if necessary. Mac users tend to associate Carbon with 'port', and 'port' with 'bad port', so if you choose to use non-trivial amounts of Carbon APIs, don't draw too much attention to the fact.

Friday, May 11, 2007
 
 
Some things still require Carbon, but it is quite easily integrated into Cocoa. Cocoa offers a much more rapid development cycle and most developers having made the move to Cocoa wonder why they didn't do it sooner.

Carbon will be around for a long while (a good thing), but for new apps, I would absolutely use a Cocoa front end.
Trygve Inda Send private email
Saturday, May 12, 2007
 
 
wxWidgets is the closest library that resembles MFC. For most of the MFC classes, you have the equivalent in wxWidgets. The wxDialog editor, Dialogblocks, can even import RC files from a MFC project.
SomeOne
Saturday, May 12, 2007
 
 
There appears to be no shortage of  technical advice, but can anyone comment from experience on the business of porting from Windows to Mac?
From my own experience, I would have a hard time ever justifying doing this again.  The ROI just isn't there.
If you have written Win32 apps (i.e., not MFC but your own code), then Carbon is not all that bad once you get past the subpar documentation.  Rewrites, regardless of the language, are expensive.  I don't think Objective-C is a silver bullet.  If you include the opportunity cost of porting to the Mac in the calculation, then it's hardly worth it based on my experience.

Has anyone made good on their investment in doing a Mac port and care to comment?

Monday, May 14, 2007
 
 
>Many Mac users will turn their noses up a Carbon based
>apps because they look dated - different tabs for
>example.

Wow. I consider myself a Mac UI snob ;-) and I hadn't even noticed there was a difference.

It's true that Mac users will reject an ugly port unless it does something completely unique and indispensable, but possibly users who get exercised about Carbon/Cocoa are vocal but unrepresentative? I mean, I really couldn't tell you which apps I use are Carbon and which are Cocoa, and I'm the sort who would notice if it made much difference...
Tom H Send private email
Friday, May 18, 2007
 
 
I'm well aware which ones are Classic however :-)
Tom H Send private email
Friday, May 18, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz