macOS Beginning long arduous task of porting to Mac. Need tips.

[printf]

I've been programming windows for over a decade now.. when i hit the home or end key on a mac, i feel that tingle of frustration as the entire page scrolls to the very top or very bottom instead of the beginning/end of the line as i would expect... i'm once again a newbie - but this time i'm in a land where there doesn't seem to be mountains of resources to sift through - thousands of tutorials and loads of source code waiting to be Ctrl+C'ed and Ctrl+V'ed... hehe.. ahem...

To be honest I've been pouring through documentation for the last two days straight, and i already hate (read: loathe) mac programming. however, i have a large-scale desktop application that is just begging to be ported to the mac, and i am ready to jump in head first and learn a brand new operating system... from the inside out.

so, now as i embark on this journey, i humbly ask for a few things:

1) the end-all-be-all mac programming reference. in the win32 world we have the mighty msdn which has saved my skin more times than i can count. keyword here: reference - not tutorial/guide/how to.

2) THE mac programming forum. perhaps i'm already here? not many threads, so i'm assuming there's got to be something bigger, better?

3) best source for tutorials and umm.. source. kinda like thecodeproject.com maybe?


and now a more specific question:

in my windows applications i stay far away from wysiwyg gui drag/drop stuff. every visual element is created and controlled programmatically. see, in windows, it's not quite as gruesome as it may sound, and the benefits are enough to write a short book on.
is this possible in Carbon? (btw, yes, carbon is what i'll be writing all my ports in - not a fan of objective c or spending a decade porting 100,000 lines of code. i'd just rather reuse as much of my c/c++ as i can) if so, can anyone point me in the right direction for info on how to do this?

ps. i've already gone through most of the examples in the xcode examples directory.

if you can offer any tips for any of my questions, i'd be eternally grateful!!!


fact: i've hit the end key probably 20 times while writing this after each time i backspace to make a correction, only to be sent to the bottom of this lovely web page... sigh... go ahead... laugh

 

[plumbingandtech]

decade porting 100,000 lines of code. i'd just rather reuse as much of my c/c++ as i can

Obj C and C / C++ can be used together.

You will use cocoa as the front end with interface builder then start to connect your c++ code with obj C events like loads and button clicks?

 

[kainjow]

1) the end-all-be-all mac programming reference. in the win32 world we have the mighty msdn which has saved my skin more times than i can count. keyword here: reference - not tutorial/guide/how to.

http://developer.apple.com - that is the starting point for all of Apple's documentation.

2) THE mac programming forum. perhaps i'm already here? not many threads, so i'm assuming there's got to be something bigger, better?

There isn't any really. Your best bet for discussions/questions is using the mailing lists at http://lists.apple.com

Apple does have a developers forum but it's unofficial, and currently appears to be flooded with iPhone topics:
http://discussions.apple.com/category.jspa?categoryID=164

in my windows applications i stay far away from wysiwyg gui drag/drop stuff. every visual element is created and controlled programmatically. see, in windows, it's not quite as gruesome as it may sound, and the benefits are enough to write a short book on.
is this possible in Carbon? (btw, yes, carbon is what i'll be writing all my ports in - not a fan of objective c or spending a decade porting 100,000 lines of code. i'd just rather reuse as much of my c/c++ as i can) if so, can anyone point me in the right direction for info on how to do this?

Yes it's possible in Carbon.

I think you have a misconception about Cocoa though. You don't need to port everything over, just your UI (well, and other Win32 APIs). Cocoa/Obj-C can use C/C++ just fine. It may be a bit harder at first because you have to learn a new language and design patterns, but I believe it'd pay off in the end, since Apple won't be adding any new features to Carbon.

 

[lee1210]

Apple+left arrow == Home
Apple+right arrow == End

1. http://developer.apple.com/referencelibrary/Carbon/index.html
This is the source of reference materials. The framework documents are probably where you want to start.

2. I like to this this is a nice place. Most Mac development boards are going to be geared towards Cocoa, since Carbon is on the way to deprecation. There's been no announcement of such, but carbon's not going 64-bit, and essentially will no longer be improved/updated. There's probably at least 2 OS releases left for it, but Apple has not hesitated to make drastic changes to the environment when they deem it necessary.

3. Really not sure for carbon code. I'm sure there's things out there, but the last few years has really been focused on Cocoa development.

Since you're going the carbon route, you won't have Interface Builder at your disposal. It sounds like you're pleased about that, so it shouldn't be an issue. Someone else will have to point you in the right direction on setting up windows and controls in carbon.

Also, why so glum? This is an opportunity to learn something new, and expand your horizons. It shouldn't be torture, after 10 years it seems to me that it'd be nice to shake things up. Sure, you won't have your bearings right away, but it should make the "a-ha!" moments that much better.

-Lee

 

[printf]

plumingandtech,

i was hoping to do something a little more simple. for instance, in windows you can use CreateWindow to create a button and then in the parent window's callback proc, you'd capture the message that translates into a windows button-click, verify the hwnd (reference) is the same and process accordingly. if i must use interface builder to tie in the gui, then i will. from the mac developer documentation i've read so far and the sample source distributed with xcode i've perused, that's the preferred way.

kainjow,

you're probably right - i'm sure i have several misconceptions this early on. i do understand about what needs to be ported, but unfortunately, the win32 api's make up a HUGE portion of my application. that's the part that severely scares me. the only thing that scares me about objective c, is the unfamiliar syntax, and that it's not procedural-friendly. it's an old style, i know - but i've spent significantly more time in my life writing new code than having to maintain code, so i've never completely adopted all the latest MVC-type design patterns/methodologies into my coding practices. and from what i've heard, objective c, and mvc go hand in hand, to the point of being inseparable.

lee1210,

i hear you about using avoiding soon-to-be-forgotten technologies. i was actually making this choice partly because of apple's win32 porting documentation:

http://developer.apple.com/documentation/Porting/Conceptual/win32porting/win32porting.html

"However, Carbon is a good choice when your application is already implemented in C or C++ code that has been written in a procedural (as opposed to object-oriented) style."

as i mentioned in my response to kainjow, my coding style is largely procedural, and all my code is c/c++, so this path seemed quite logical.

also, you're right - i am kind of excited about learning something new! however, there's just a certain level of frustration in not being able to just jump in and knock out an entire feature in one sitting - now, my goals are a bit more simple.. like writing formatted text to the screen!



and thanks to everyone for the feedback so far! i already feel a little less overwhelmed!

 

[kainjow]

What will be your targeted OS? Carbon has been modernized a bit in Leopard and Apple made it a lot easier to integrate Cocoa UI into a Carbon app, so even if you do use Carbon, you'll still be able to use all the modern Cocoa controls if you target 10.5 and higher, which I would recommend (since by the time you complete the port, 10.6 will probably be shipping).

I've done a bit of Win32 here and there (wrote my senior project for college as a cross-platform app in Win32 and Cocoa), and I've dabbled with Carbon, so feel free to post questions and I'm sure if someone doesn't know the answer, we'll be able to point you in the right direction.

As for your CreateWindow example, you can use HIWindowCreate/CreateNewWindow in Carbon.

 

[Catfish_Man]

Apple should really update their win32 porting guide :/ They shouldn't be recommending Carbon anymore, since they're recommending against it elsewhere.

 

[Sander]

Two things.

First, remember how long it took you before you were proficient in Windows. It's easy to forget your initial struggles there.

Second, I feel that judging MSDN on its sheer size is not fair. I know I spend a lot of time in MSDN to figure out why a certain piece of code won't work, reading about strange exceptions, having to fill in large structs with data which doesn't mean anything to me etc., and often end up simply copy-pasting stuff. When reference documentation is (or rather, needs to be) so big, I consider that a drawback and not an advantage!

Where I grew up (on BeOS) development was much different. Once I grasped the concepts, I could often implement things purely on intuition, because the frameworks made sense. I rarely needed to look things up.

I recently picked up Cocoa programming, and whereas the Objective-C stuff needed some getting used to, it feels like the frameworks are pretty well thought out too. You can freely mix and match C/C++ (with a few exceptions) and that works pretty nicely, too.

 

[TheFuel]

hi printf,

Once you get used to the platform subtleties you'll be fine. I was in your position about 4 years ago. Of course I had prior MacOS experience, circa 1996. You can imagine how much help that was (hint: none). Due to my work I frequently switch back and forth between Windows and OSX dev, staying up to date is a full time job in and of itself.

kainjow and the others have given you good advice. However I would like to encourage you to invest in Cocoa & Objective-C/C++. IMO you'll get the biggest productivity gains here, besides there's more information available. Focus on the fundamentals first; know that Cocoa and Objc are conventions base.

Probably the single most useful site I've found is CocoaDev, a wiki for Mac developers.

The biggest 'forums' are Apple's own development lists. The archives are great resources and most people are friendly.

...the benefits are enough to write a short book on

Short indeed... The last Win32 Petzold book was 1000+ pages. The first half (the code half) of "App = code + markup" is over 500. Raymond Chan's "The Old New Thing", devoted to windows lore, 500+. Yuan's "Windows Graphics Programming:...", an astounding 1200+.

Because it sounds like you want to jump right in and write code I recommend picking up Cocoa Programming for Mac OS X 3rd Ed, and work through it. With your experience it should take you less than a month, if you treat it like a full time job probably a week. You may not be comfortable but that comes in time.

Good luck!

 

[Cromulent]

Second, I feel that judging MSDN on its sheer size is not fair. I know I spend a lot of time in MSDN to figure out why a certain piece of code won't work, reading about strange exceptions, having to fill in large structs with data which doesn't mean anything to me etc., and often end up simply copy-pasting stuff. When reference documentation is (or rather, needs to be) so big, I consider that a drawback and not an advantage!

Exactly. I've never understood why so many people like MSDN so much. It is poorly organised and when you do find the relevant pages it just ends up referencing other pages. It is basically impossible to get all the information you need on one page.

 

[hhas]

Another possibility would be using Qt/wxWidgets as your application framework instead of Carbon/Cocoa. While you lose some of the niceties of developing directly in Cocoa you can still produce a reasonably Mac-like application. The APIs should fit better with your existing codebase and programming style, and because they're cross-platform you could do much of your porting work on Windows before hauling it over to Mac for testing and finessing.

 

[gnasher729]

Carbon is better for porting than Cocoa. Unfortunately, Carbon is also being on its way out. There will never be a 64 bit version of Carbon, and in a few years time you won't be able to compile Carbon code anymore (it will take longer until it stops running). So I would recommend to start using Cocoa.

The biggest problem is when you have an application that doesn't separate user interface and the internal operations of the application properly. Unless your Windows developers had an unusual amount of foresight, that is likely not the case. So you would likely work on the Windows application and the Mac port simultaneously, kicking the Windows code into shape to make it more easily portable, while building the Mac user interface on the other side.

For interfacing between C or C++ and Objective-C: Objective-C is a superset of C, so you can write plain C functions in Objective-C. So for some user interaction that you need to create, you write a C function prototype that is system independent. On the Windows side, you implement it as usual and call it when needed. Then on the Macintosh side, you write Objective-C code to implement it, including one C function that acts as the interface to the rest of the code. You don't have to use Interface Builder if you don't want to, but it will make life easier for you.

 

[whooleytoo]

i was hoping to do something a little more simple. for instance, in windows you can use CreateWindow to create a button and then in the parent window's callback proc, you'd capture the message that translates into a windows button-click, verify the hwnd (reference) is the same and process accordingly. if i must use interface builder to tie in the gui, then i will. from the mac developer documentation i've read so far and the sample source distributed with xcode i've perused, that's the preferred way.

You don't have to use Interface Builder if you don't want to. If you're more comfortable with creating and 'hooking' up the UI programmatically, go for it.

For OSX reference, everything you need is in Xcode. The Documentation window has both API/framework references and introductory guides; and the Research Assistant is a great time saver for showing API calls & parameters as you type.

For tutorials, I've found
Cocoadevcentral and
Macdevcenter

to be among the best.

For forums, here is pretty good. I found the guys on the Usenet forums excellent as well, (comp.sys.mac.programmer.*). Also, check out the mailing lists at lists.apple.com. For specialised help, they can't be beat.

 

[printf]

"What will be your targeted OS?"

Good question! I was hoping to target all versions that support the new Intel-based architecture - which I believe is Tiger and up?



"I feel that judging MSDN on its sheer size is not fair"

Haha, yeah - but even in chaos, there is order. I guess I've gotten to the point where I only use it to remind myself of obscure api aruguments, like those style enumerations that you need once in a blue moon. I google the api, and the first hit is always the msdn link. Then I get my info and I'm done.




The Fuel, thanks for your comments. Funnily enought, I happened to pick up the book you recommended before even reading your response - but it really had more to do with the fact that, that was THE ONLY book Barnes and Noble had on it's shelf related to Mac programming. Unfortunately, a few pages in, I've realized that it covers XCode 3.0, which won't run on Tiger (which is what I currently am running - with XCode 2.5). Perhaps I need to go back an edition? And on a side note, those tomes you mention have proven quite invaluable - as a reference, mind you - in my years of win32 development. A comparable Mac reference would be worth it's weight in gold!





gnasher729. Initialy my idea was to use the same codebase, and write a generic wrapper for all platform-specific calls, and use preprocessor directives such as: #if defined(__WIN32__) #elif defined(__APPLE__) && defined(__MACH__) to determine which platform to build for at compile-time. Any comments on this approach?





My most recent thoughts on this port:

This is a huge project - and one that is very time sensitive as several clients and business partners are anxiously awaiting the Mac release - and more importantly, I have a competitor that has a head start on me with a Mac version of their product already on the shelf!

And though I'm already hearing the persuasive convictions from the do-it-right-the-first-time developers encouraging me to do otherwise, I'm seriously considering a quick port using Carbon, and then coming back and doing it the right way a few months down the road (I know, I know). This includes any time savers I normally might avoid, like using Interface Builder, for instance.

What would you do?

 

[kainjow]

"What will be your targeted OS?"

Good question! I was hoping to target all versions that support the new Intel-based architecture - which I believe is Tiger and up?

Yes. It was 10.4.4 I believe that added Intel support.

Initialy my idea was to use the same codebase, and write a generic wrapper for all platform-specific calls, and use preprocessor directives such as: #if defined(__WIN32__) #elif defined(__APPLE__) && defined(__MACH__) to determine which platform to build for at compile-time. Any comments on this approach?

You should checkout Transmission's source. It's a cross platform BitTorrent client (don't think it runs on Windows though) and it has a native Cocoa UI while running on Linux and BeOS. It might help you understand how to structure your code.

And though I'm already hearing the persuasive convictions from the do-it-right-the-first-time developers encouraging me to do otherwise, I'm seriously considering a quick port using Carbon, and then coming back and doing it the right way a few months down the road (I know, I know). This includes any time savers I normally might avoid, like using Interface Builder, for instance.

I'm not really sure if Carbon will be easier. I don't think much (or any) of the Win32 APIs are compatible/similar to Carbon. Cocoa provides extremely simple ways of handling UIs and events, while Carbon doesn't so much. I'm sure you could pick it up quickly since you already know Win32, but if you gave me a screenshot of your app and then tried to port it to Carbon, I could do the same in Cocoa in possibly 1/10 the amount of code.

What would you do?

Rewrite it in Java

 

[TheFuel]

Perhaps I need to go back an edition?

I think the older edition covers 2.x but you'll always find difference in each Xcode release. You are correct though Xcode 3 is sufficiently different (especially with regard to IB - interface builder) that following along could prove difficult. Check out your local library or 1/2 price books. If you have an ACM membership you can pick it up through Safari books free.

And on a side note, those tomes you mention have proven quite invaluable - as a reference, mind you - in my years of win32 development. A comparable Mac reference would be worth it's weight in gold!

Indeed I refer to the GDI book as Tome of +1 Windows Graphic Knowledge. There are books that cater to specific areas of OSX, e.g. Quartz/Core Animation. Early next year there's a book on Cocoa Design Patterns coming out, which if I'm not mistaken covers the patterns used throughout Cocoa. You can pick up betas here.