Mac Development
-
We are currently being pressured by a relatively small group of customers to produce Mac versions of our products. The problem is we are a tiny development house, with effectively no Mac experience and we want to do it with minimal impact on our more important (and lucrative) development efforts. We code in C++ with fairly heavy use of MFC and we really do not want to maintain more code than is absolutely necessary (well duh!) Any suggestions or hard won experience? Paul Hooper If you spend your whole life looking over your shoulder, they will get you from the front instead.
I'm pretty sure Microsoft used to provide Mac versions of MFC. Not sure if they still do, and I can't find it in MSDN (but there are lots of mac references) -- Help me! I'm turning into a grapefruit!
-
I've been there, done part of it ... ( no longer work for that company! ), here's what we did. first and foremost, you need to decide which 2 technologies you want to use, either ObjectveC or C++, the Apple dev. tools ( ProjectBuilder and InterfaceBuilder, offers the 2, but the UI works with ObjectiveC; or CodeWarrior with PowerPlant (C++). We chose the first one, even thought the application is written in C++ with MFC/Win32, why? because we wanted to stay a close as possible to Apple technologies. And now to the code and work related stuff. You need to clean up your code, remove, replace and substitute every non GUI code that are Windows specific to portable code, replacing stuff like CString with STL std::string, CRect with your own version of Rect, removing all of the hard-coded strings and put them in format that can be used by both platforms, we found out that File access usually must be re-written, ... all of them. Once you application works normally with a much portable code as possible, it's time to start splitting code appart, split core functionnalities from UI, make bridges where available, use interface<->controller patterns; for example, a dialog needs to be split in 2, one part is the interface ( UI ) with native code, buttons, lists, ... and the controller is the code part with portable code that contains all of the logic; so the UI talks to the controller to get/fetch it's data no more, no less. That's the easy part, the harder we found was to build the replacement for the mainframe because we have a lot of custom messaging and stuff like that. Hope this helps a bit. Max.
And don't forget endian issues (oh joy) -- Help me! I'm turning into a grapefruit!
-
We are currently being pressured by a relatively small group of customers to produce Mac versions of our products. The problem is we are a tiny development house, with effectively no Mac experience and we want to do it with minimal impact on our more important (and lucrative) development efforts. We code in C++ with fairly heavy use of MFC and we really do not want to maintain more code than is absolutely necessary (well duh!) Any suggestions or hard won experience? Paul Hooper If you spend your whole life looking over your shoulder, they will get you from the front instead.
Decide now if you are going to run two development efforts eg Main product on Windows and the Mac version being a version or so behind. You could try #IFDEF statements to distinguish between MAC and PC code but that will get messy and that would also mean that everyone would have to develop for 2 platforms at the same time. Get some good source control as you will end up with two different branches that you will want to merge time and time again. Cost it right! eg get yourself a MAC, (beg/steal/borrow) now and try to port a smal part (preferably a reasonably complex UI bit). To give you an idea on the timescales. Do not underestimate the cost of doing this to satisfy the customer unless it is going to be a loss leader (eg bring in more work), (but I am not going to teach my gran to suck eggs.) Keep the team small and concentrated on the effort, you can't have them bouncing between products while they are still learning the porting process. Else outsource it to someone/company that has already done this sort of work in the past - that way when it you test it and it doesn't work you can annoy someone else. With this one get weekly source deliverables that you compile and test (eg backup in case they fold or abandon) this way they get 90% of the hardwork done while your team learns from what has been done. It may seem a simple port but from anecdotal (eg 2nd hand in pub) evidence it never is even if you are using MFC.
Stupidity dies. The end of future offspring. Evolution wins. - A Darwin Awards Haiku
-
I'm pretty sure Microsoft used to provide Mac versions of MFC. Not sure if they still do, and I can't find it in MSDN (but there are lots of mac references) -- Help me! I'm turning into a grapefruit!
There's Visual C++ 4 Cross Development Edition by MS that will compile MFC stuff on older Macs, but MS quit with this line. So, AFAIK you can't get a newer version. Jeremy Falcon Imputek "C# is the answer to a question nobody asked." - Chris Losinger
-
I've been there, done part of it ... ( no longer work for that company! ), here's what we did. first and foremost, you need to decide which 2 technologies you want to use, either ObjectveC or C++, the Apple dev. tools ( ProjectBuilder and InterfaceBuilder, offers the 2, but the UI works with ObjectiveC; or CodeWarrior with PowerPlant (C++). We chose the first one, even thought the application is written in C++ with MFC/Win32, why? because we wanted to stay a close as possible to Apple technologies. And now to the code and work related stuff. You need to clean up your code, remove, replace and substitute every non GUI code that are Windows specific to portable code, replacing stuff like CString with STL std::string, CRect with your own version of Rect, removing all of the hard-coded strings and put them in format that can be used by both platforms, we found out that File access usually must be re-written, ... all of them. Once you application works normally with a much portable code as possible, it's time to start splitting code appart, split core functionnalities from UI, make bridges where available, use interface<->controller patterns; for example, a dialog needs to be split in 2, one part is the interface ( UI ) with native code, buttons, lists, ... and the controller is the code part with portable code that contains all of the logic; so the UI talks to the controller to get/fetch it's data no more, no less. That's the easy part, the harder we found was to build the replacement for the mainframe because we have a lot of custom messaging and stuff like that. Hope this helps a bit. Max.
Maximilien wrote: removing all of the hard-coded strings and put them in format that can be used by both platforms Just as an extra FYI for Paul, Macs use Pascal-style strings (length in front) and not C-style strings (null-terminated). Jeremy Falcon Imputek "C# is the answer to a question nobody asked." - Chris Losinger
-
Maximilien wrote: removing all of the hard-coded strings and put them in format that can be used by both platforms Just as an extra FYI for Paul, Macs use Pascal-style strings (length in front) and not C-style strings (null-terminated). Jeremy Falcon Imputek "C# is the answer to a question nobody asked." - Chris Losinger
I'm not sure that's still true, since most of the API in OSX is unix/c based, and the toolkits are modern! Max.
-
We are currently being pressured by a relatively small group of customers to produce Mac versions of our products. The problem is we are a tiny development house, with effectively no Mac experience and we want to do it with minimal impact on our more important (and lucrative) development efforts. We code in C++ with fairly heavy use of MFC and we really do not want to maintain more code than is absolutely necessary (well duh!) Any suggestions or hard won experience? Paul Hooper If you spend your whole life looking over your shoulder, they will get you from the front instead.
If you have no experience with the platform it would make a lot of sense to outsource...No matter how good you guys are...first project means first mistakes. tomaz
-
We are currently being pressured by a relatively small group of customers to produce Mac versions of our products. The problem is we are a tiny development house, with effectively no Mac experience and we want to do it with minimal impact on our more important (and lucrative) development efforts. We code in C++ with fairly heavy use of MFC and we really do not want to maintain more code than is absolutely necessary (well duh!) Any suggestions or hard won experience? Paul Hooper If you spend your whole life looking over your shoulder, they will get you from the front instead.
Ah, Macs. Those things are so cute. Can you still get software for them? :-D Actually, there's an additional option that's not any less ugly than porting your C++ code. You could use a cross platform development library. I once used one called Zapp (pronounced "Crap" by the developers), I think Rogue Wave owns it now. It's probably not bad, really, it's just that I hate cross platform libraries - you have to design to the lowest common denominator, meaning if one platform does a Cool Thing that none of the others do, forget about it. Any way you shake it, you're in for some major rewrites. Implementing your product in a cross platform tool is probably easier for maintenance down the line. Writing native #ifdef C++ code allows the best feature set for each platform. Both solutions will have your developers looking for open windows on the fifth floor. A third alternative, which would take quite a bit of selling, would be to convince them that you should develop new, standalone apps for the Mac, and dedicate a resource to that project. In summary, Yuck! Good luck, man! Chistopher Duncan Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
-
We are currently being pressured by a relatively small group of customers to produce Mac versions of our products. The problem is we are a tiny development house, with effectively no Mac experience and we want to do it with minimal impact on our more important (and lucrative) development efforts. We code in C++ with fairly heavy use of MFC and we really do not want to maintain more code than is absolutely necessary (well duh!) Any suggestions or hard won experience? Paul Hooper If you spend your whole life looking over your shoulder, they will get you from the front instead.
While this suggestion may seem obvious, people still stumble on it: Separate the UI from the rest of your code. Do NOT attempt to port the UI. For that I strongly suggest hiring a Mac UI guru. The more he/she hates Windows, the better (yes, they'll drive you nuts like all OS bigots, but they'll insist on doing things "The Mac Way" which is what your customers will want.) (A Mac UI guru will also know which Macisms are now passe. Don't want something akin to those old Borland OK/Cancel buttons showing up in your dialog boxes.)
-
I'm not sure that's still true, since most of the API in OSX is unix/c based, and the toolkits are modern! Max.
I don't believe it is for OS X either, but I've never done any dev for X yet so I can't say for sure. It's always been that way for the classic Mac OSes however because the internals for the Mac OS had a lot of crap written in Pascal way back in the day before switching to C. Jeremy Falcon Imputek "C# is the answer to a question nobody asked." - Chris Losinger
-
We are currently being pressured by a relatively small group of customers to produce Mac versions of our products. The problem is we are a tiny development house, with effectively no Mac experience and we want to do it with minimal impact on our more important (and lucrative) development efforts. We code in C++ with fairly heavy use of MFC and we really do not want to maintain more code than is absolutely necessary (well duh!) Any suggestions or hard won experience? Paul Hooper If you spend your whole life looking over your shoulder, they will get you from the front instead.
Where I used to work we ported MFC to Mac and used a lot of #ifndef mac... We also wrote our own tools to help port the resources from Win to Mac. We couldn't re-write the code completely because we'd still be doing that as we speak! ;) So we tried to keep the code clean as much as possible but we didn't have to different streams for each platform. If your app isn't too big, he's what I'd do: - Identify the differences between the two platforms (endian is an important one!) and the stuff that work similarly on each platforms and that you could exploit. - Seperate the functionnalities from the UI to create a framework that is usable on both platforms. Create wrappers that will help you use functionnalities from both platforms seamlessly. You could then have two different DLLs for each platforms and your developers could use those libraries to develop without thinking about the platform they are working on. What I mean is to create a layer between the app itself and the platform. - Create platform dependent UI that relies on the framework (layer) you created. It is a lot of work, but on the long run it's worth it if there's actually a demand for you app on Mac. :) --------------- http://www.edovia.com