Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NeXTstep -- err, Mac OS X.

Thanks for all the good advice. Since this is veering "slightly offtopic", as a space saver, have condensed several replies into one message...

On Friday, May 30, 2003, at 12:48 PM, Chris Hanson wrote:
Who says you have to convert your entire application to Objective-C?

If your entire application is human interface code, that's understandable. But if it has proper model-view-controller separation, you can use C/C++ for your custom model objects, Cocoa for your view objects, and Objective-C for the controller objects to bind the two together and for any custom views.

In fact, that might be your best route on Windows as well: C/C++ for your custom model objects, Windows Forms for your view objects, C# for the controller objects to bind the two together and for any custom views.

It is a "weirder" situation than C++... About a half million lines, mostly object pascal.

I'm agnostic about languages, but the other two programmers are pascal zealots, so the code will likely remain mostly pascal for a long time. Doesn't matter to me-- IMO any "decent" language just makes the computer do the same old tricks. Pascal is still wonderfully supported on PC, and was well-supported on Mac until only the last couple of years. Sometime in the future, if pascal becomes completely unworkable on Mac, probably the only viable option will be to abandon the Mac market. Just too much code to convert.

Borland stuff on PC allows easy cooperation between C++ and pascal, so anything that is difficult in pascal just gets done in C++.

I programmed exclusively in Mac C/C++ from 1987 til 1997 (rather fight than switch). Since I started "splitting time" between Mac and PC, almost all the PC experience has been Borland Delphi and C++. Coming from Think C/Codewarrior into Delphi/C++ Builder, quickly got spoiled how easy and quick it is to finish a program using Borland RAD. Because it was so much easier to finish stuff on PC, began to slightly dread Mac programming.

Codewarrior 8 still works wonderfully with C++ and pascal (at least for CFM), so the same strategy on Mac-- anything that is difficult on pascal gets implemented in C++.

Haven't used Cocoa, but sounds like it is at least "as easy" as Borland RAD. If Cocoa was usable with Pascal, would probably explore it. OTOH, if Borland ever ports Kylix to Mac, I'll be among their first customers (GRIN).

On Friday, May 30, 2003, at 03:00 PM, Pietrzak, Bryan wrote:
Well, we just started porting our app here at work to Carbon. It's around
700,000 lines of code. It's a graphical drawing app and based on my
experiences doing other carbon work I don't see any huge hurdles (*) ahead.
There are three of us carbonizing (and modernizing!) and I'll be surprised
if it takes more than three to four months.

Our shared "non-platform-specific" code compiled easily on Carbon. Very few changes.

The main changes were numerous "spelling" changes on UI functions, with complete rewrite of some sections like File I/O and Printing.

Things yet-to-do include replacement of a few custom CDEFs, write a dynamic-link lib for OSX CoreMIDI, write a Dynamic-link lib for Classic OMS + FreeMIDI, and chase down numerous bugs introduced in the carbonization. But it is working well over 90 percent already.

The longest, most boring chore was getting far enough that the entire project would compile. A couple of months of blind-replacing a zillion functions with no feedback whether the changes were correct, except that the compiler reported fewer errors, working thru the project file-by-file. Codewarrior has wonderful features for that kind of work. Sometimes would have 10 or 20 "Find In Files" windows open, hunting back and forth among many files, trying to avoid doing more harm than good.

Here is a hint too obvious to even mention-- Every time I'd find an instance of a non-carbon function in the "current file", would do global search-replace and fix ALL instances of that function in the entire project. The first source files were rather time-consuming to get compiled (spending lots of time propogating fixes to the other files), but as it progressed, the "not yet compiled" files had fewer and fewer errors, and it became quicker to fix each new file.

A couple of weeks ago finally got the project to MAKE. Have spent most of the subsequent time, changing the control layout of about 200 DLOGs in Resourcerer. None of the dialogs had proper control spacing in OSX. Sounds awfully inefficient having to spend a couple of weeks editing DLOGs, but OTOH thats about 20 DLOGs a day (GRIN).

Am currently fixing up main window control spacings, and then on to the other tasks. With any luck, it will be finished in a month or two.

On Friday, May 30, 2003, at 03:22 PM, Laurence Harris wrote:
The work involved can vary tremendously. If your Mac OS 9 application is
already using all the latest technologies such as Navigation Services,
Appearance Manager, latest Menu Manager APIs, FSRefs and the latest HFS+
file manager APIs, and so on, your carbonizing work will be significantly
reduced. OTOH, if you have an old code base which *doesn't* use the latest
technologies, carbonizing is going to force you to have to update all that
stuff, increasing the work required exponentially.

We are more interested in adding new features than slavishly changing old code every time Microsoft or Apple releases some new software gizmo. Regarding "old technologies", we tend to have the attitude, "If it ain't broke yet, don't fix it yet."

But one can't party all the time. Sometimes one must stop to pick up the beer cans (GRIN). The "If it ain't broke" philosophy left us with a lot of homework to make Carbon happy.

It took me January and February to repair the program sufficiently to compile using the latest Classic Universal Headers. Then March thru May to compile for Carbon.

With luck, by mid-summer, will have an application identical-featured to the one we already had, except now it will have pretty blue buttons (GRIN).

James Chandler Jr.
_______________________________________________
carbon-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/carbon-development
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: NeXTstep -- err, Mac OS X. (From: Chris Hanson <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.