Apple provides many programming resources for creating MacOSX applications, and which one you choose depends upon your needs, preferences, and constraints. If you are unfamiliar with the MacOSX platform, the process of choosing the right approach can be time-consuming and confusing. The purpose of this Guide is to get you started porting an existing procedural Win32 application written in C or C++ to MacOSX.
Porting to Mac OS X from Windows Win32 API
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
The problem is, that the majority of windows-software written in C++ uses the mfc, not the pure win32 api. IMHO Apple should also publish “Porting to Mac OS X from MFC” or does this already exist ?
That many Windows programs aren’t written in C++
Many Mac programs are not written in C++.
Do some research at apples site (ADC= Apple Developers Site) to find what you need to know instead of complaining about things you don’t even know about for sure.
at least on the very begining
I rarely use Visual Basic, so ….
Hey, use VB Cleaner and import your VB apps into REALbasic (http://www.realsoftware.com). RB compiles into Mac Classic, Mac OS X and Windows applications.
The easiest way for windows programmers using MFC to move to the Mac and keep Windows compatability is to use wxWindows. http://www.wxwindows.org
Sean Long
Hailstone Software
http://www.hailstonesoftware.com
is to exercise proper MVC separation and rewrite the View code for each platform. While certainly not the easiest, this will give the developer the most control and if developed properly will result in the best end user experience.
If this seems like too much work, might I suggest Qt? The API isn’t to my tastes (I prefer callbacks to inheritance any day) but it seems like a good solution, provided you’re willing to shell out money to Troll Tech for your commercial applications.
True, MVC is the way to go for most GUI apps, not just those intended for multiple platforms. But the Controller in MVC is just the glue that binds the Model to the View, so you’ll end up re-writing that, too.
No big deal, though, since most of the work of the application is in the Model anyway. And MacOS X makes ‘writing’ the View easy– you can do it all with just the mouse in Interface Builder.
I’ve made my money as a Windows developer for almost ten years, using VB, C++/MFC, Delphi, even Python and tkinter — and now C#. Although I’m familiar with it, I’ve never once seen a production Win32 program written using the “raw” Win32 API in C. Who would want to?
By the way, I don’t even own a Windows machine at home. I’m posting this from my flat-panel iMac.
Phuqker, any application which needs performance isn’t written in MFC. That includes all games, all desktop enhancers (ObjectDesktop and WindowBlinds and such), and probably all graphical apps (CorelDraw and Photoshop).
You can also reduce file size drastically by using win32 (and even more by dumping the CRT, and yes, you can still do C++, just write your own “new” and “delete”).
I have not found any word about OS X to Win 32 function mapping, or Cocoa to MFC mapping. This is only an OS X begining programming article.
IMHO the best way for OS X take a bite to Windows abundant applications is to implement .net for OS X as MONO is doing with Linux.
Win32 API is so mess and big to be completely implemented (with Apple is economical resources).
I’ve never once seen a production Win32 program written using the “raw” Win32 API in C. Who would want to?
Raises hand. I’m responsible for a real time communications simulator (embedded systems), and I need the fastest speed windows can give me. No MFC, no CWindows etc, just plain old Win32 (the others are just wrappers for it). Its a nightmare to maintain and structure, but alas, its here to stay. It’s long overdue for refactoring.
“You can also reduce file size drastically by using win32 (and even more by dumping the CRT, and yes, you can still do C++, just write your own “new” and “delete”).”
maybe add purecall for virtual function catching
#pragma intrinsic (memset, memcpy)
#pragma comment(linker, “/entry:MyEntry”)
I did a few straight SDK/win16/win32 apps, one of them probably
is still crunching plastic cards like those in your
wallet, another one is controlling millions of set-top
boxes somewhere in the world.
I recall a small pet project I did for File Manager
that’s only 512 bytes written in C/Win16 SDK.
Until recently, C++ compilers still couldn’t get
rid of Data Abstraction Penalty.
And now it is a whole new game to minimize java’s
grabage collection penalty.
After all these years, an average PC often still
act like a 386 with 4MB running win3.1, only you got
more shinny skins, better looking fonts and alpha
blending background and nice looking shadows.
OS X is really cool, however the responsiveness
is nothing to be impressed – every thing is draw
like sort of a PDF – PostScript is not famous for
speed.
this is off topic, but the new update 10.2.3 certainly improves responsiveness in OSX by a big margin. I think it installs OpenGl 1.4
IMHO the best way for OS X take a bite to Windows abundant applications is to implement .net for OS X as MONO is doing with Linux.
Funny, the MONO project folks are looking for volunteers to help with that effort. There shouldn’t be too much work needing to be done, as their FAQ reports they’ve got MONO running on FreeBSD, already… OpenLink’s Virtuoso has been running on Mac OS X since the first Preview Release, too, so most of the infrastructure you want is ready to rock! See these pages for more details —
http://go-mono.com/faq.html#portability
http://www.ximian.org/about_us/press_center/press_releases/index.ht…
Be seeing you,
Ted Thibodeau Jr
Niche Consultant
OpenLink Software
I think that Apple should push Mainsoft to port their MainWin system over to OS X. This system works very well for a lot of companies who try and port their Windows code to other platforms without changing code bases.