<< >>
justin = { main feed , music , code , askjf , pubkey };
[ <<< last (older) article | view in index | next (newer) article >>> ]

February 14, 2008
to my love, OS X.

JUST KIDDING. Quite the opposite in fact. It's been really exhausting porting stuff to OS X. Here are some reasons why:

1) Poor (and often hard to find) documentation-- Yes, some of the newer APIs are decently documented, but dig in and try to use ATSU to render text, and it's a world of pain. Looking through header files that all seem to assume you know what to do. This is tolerable, though, with enough digging you can find what you want.

2) The AudioUnits SDK-- the API for AudioUnits is defined in a header, but not documented. So to use AU, you'd have to either just use the SDK (with EXTENSIVE amounts of code), or reverse engineer it to figure out what calls you need to do to control the plug-ins yourself. Someone obviously spent a lot of time defining an extensible plug-in API, why the fuck don't they document it?! I mean, really, just a "first, call this, then, call that, then, when you're ready to process X, do Y." If this info is somewhere, someone please let me know... (see the next point)

3) The previous two points might to be related to the fact that Apple seems to assume that as a Mac developer, I've been developing for macs continuously since 1984, and have religiously read the developer mailing list since whenever it was created. Apple: for the love of god find some way of getting those mailing list posts linked to/from the relevant documentation pages.

4) There are WAY too many ways to accomplish similar things. The classic example which I bitch about a lot is text rendering--last I checked, there is CoreText (apparently awesome, but 10.5 only), CoreGraphics text functions (seem nice, but lots of limitations including non-functioning text measuring), HITheme rendering (which is nice but doesnt give you much for font style selection), AppKit NSString/NSAttributedString drawing (great, but slow), ATSUI (seems to be the best all around but takes a bit to get to the point where you get what's going on). I understand that there are historical reasons for these APIs, but again, this can be fixed with proper documentation (perhaps a page describing all of the APIs and their benefits and drawbacks).

5) Addition of new APIs in new OS versions. I know Apple wants to sell new OS versions, but from a developers standpoint, it's really difficult to properly support multiple versions of OS X. I'd like to use new OS features if available, but fall back to old versions if not. If there's a clean way to do this, I'd love to hear about it -- on Windows we usually just load the appropriate DLLs if available..

6) Performance on OS X for basic graphics drawing seems terrible. Perhaps if you take advantage of the highly OS X specific stuff, you can get around some of this, but as an example I made two native projects, one for OS X and one for Win32, that create a 640x480 window and try to draw at about 30fps. They fill the background black and draw white lines. On Windows basic double buffering is used, on OS X the system buffers the drawing. The OS X version uses Cocoa and CoreGraphics to draw, and the view is opaque.

The source code which you can build is here (VC6/win and Xcode2.4+ for OS X required).

Results: on the same Core2 hardware: OS X: 11% CPU use. WinXP: 1% CPU use. In fairness to OS X, it was drawing pretty antialiased lines, however when I disabled AA on the OS X build, the CPU use went _UP_ to 20%. Go figure. It's not really the line drawing, either--make it draw just one line the numbers dont change much...

February 14, 2008
and Windows...


Well I don't have anything to really bitch about Windows right now, but I'm really disappointed with all of the VC++ builds after VC6. The issues are a plenty, but it makes it hard to upgrade. All dynamic linking uses msvcrt71.dll etc which even MS doesnt distribute anymore, so you end up having to static link. Bleh.

I guess most people don't care about the size of their software, but for us keeping the program size down is also part of keeping the development process fast and efficient. If I have to upload a 30mb installer and everybody has to download one to test...






14 Comments:
Posted by TW on Tue 19 Feb 2008 at 02:30 from 118.208.121.x
Sorry Justin, but isn't your rant about lack of documentation just a little hypocritical? Maybe the developers you're referring to don't spend time documenting their code for the same reason you don't spend time documenting Reaper.

Just a thought ...


Posted by Jesse Donat on Wed 20 Feb 2008 at 15:50 from 74.33.26.x
I for one appreciate the keeping of the size down. As for the other stuff, the majority of my dev work has been vb.net so I can't say much


Posted by Justin on Thu 21 Feb 2008 at 12:41 from 66.171.198.x
Documenting APIs you expect people to implement applications with is different from documenting the use of the application itself! :)

But yes, I'm guilty of not documenting APIs as well (WDL for example lacks a lot of documentation), but then again I'm not making an OS that I expect people to write for.


Posted by Marketing on Thu 21 Feb 2008 at 14:35 from 208.64.186.x
Not making an OS YET....hint hint


Posted by Dandruff on Tue 26 Feb 2008 at 19:58 from 217.235.118.x
justin, don't you switched to the intel compiler lately? or are the microsoft one is still required for some parts? just curious ...


Posted by Dandruff on Tue 26 Feb 2008 at 19:59 from 217.235.118.x
sorry for the bad english :)


Posted by Justin on Wed 27 Feb 2008 at 21:01 from 64.81.54.x
ICC integrates with the MS dev environment, Dandruff...


Posted by Dandruff on Wed 27 Feb 2008 at 22:34 from 217.235.110.x
what's this mvcrt71.dll needed for?


Posted by memson on Fri 29 Feb 2008 at 03:50 from 84.201.181.x
mvcrt71.dll - Microsoft visual c runtime 7.1 dynamic link library. i.e. the thing that makes Visual Studio 2005 native C/C++ executables work ;-)

Justin, though not entirely related (as it's MFC being discussed), did you see how Raymond Chen feels about the developer vs Microsoft wrt DLL availability? Basically, the onus is on the developer to provide the DLL's required to run their apps apparently. As to how we know what is part of the OS and what "just happens to have been installed" is beyond me!

blogs.msdn.com/oldnewthing/archive...


Posted by Justin on Sun 02 Mar 2008 at 10:41 from 64.81.54.x
yep.. that's why we still use VC6.. msvcrtXX.dll doesnt ship with all windows, whereas msvcrt.dll does for everything since win95b.


Posted by Gio on Sat 08 Mar 2008 at 06:33 from 62.103.65.x
hmm, there are rumors from Herb Sutter that VC10 is going to be the new six! :)


Posted by Matt on Fri 09 May 2008 at 08:26 from 136.159.168.x
As crappy as it is shipping msvcrtXX.dll with your project, I found the IDE itself in VS 2008 to be much improved over previous versions. Just little things like Intellisense working better.

PS I've only ever seen 1 API that had good documentation(FMOD Sound System), the rest are always adequate or horrible(PhysX).


Posted by ank on Tue 02 Dec 2008 at 15:02 from 203.26.177.x
Why do you bother targeting mac os x at all? Are your customers going to be apple users? Isn't the Windows customer base enough? Or are you just looking for the "cool" factor? Or is it that you expect Microsoft to die? or what?

cheers
- ank


Posted by ank on Tue 02 Dec 2008 at 15:02 from 203.26.177.x
Why do you bother targeting mac os x at all? Are your customers going to be apple users? Isn't the Windows customer base enough? Or are you just looking for the "cool" factor? Or is it that you expect Microsoft to die? or what?

cheers
- ank


Add comment:
Name:
Human?: (no or yes, patented anti crap stuff here)
Comment:
search : rss : recent comments : Copyright © 2024 Justin Frankel