Tuesday, June 28, 2005

Xcode can't remember?

In CodeWarrior, BBEdit (and MPW before that), when you open a text file, and then close it, the editor remembers a bunch of stuff about the file. Things like:

1) The position of the window.
2) The position of the text in the window (how far down/over you have scrolled the window.
3) The selected text

This is really cool, because when you re-open a source file, you are "right back" where you were when you closed it. You can arrange frequently opened files on the screen, and know that they'll be in the same place when you come back to work tomorrow, and the same piece of code that you were working on is still visible.

Apparently, Xcode doesn't do this :-(


Off to learn how to use BBEdit as an external editor, I guess.

Succeeded with one error

I was building a project of mine in Xcode yesterday, and I got an interesting message in the build results window.

My build, it seems, had "Succeeded with one error"

This, it seems to me, is "a definition of succeeded that I was previously unaware of" (with apologies to Douglas Adams).

I've got a screen capture of the bottom of the xcode:

Friday, June 24, 2005

Customizing Xcode's documentation window

Xcode's online documentation is quite handy. However, if you have a powerbook, it's also somewhat of a pain, because the documentation window is large, and multi-paned, and full of large text and images. It reminds me of old parodies of Microsoft Word, where there would be so many toolbars and sidebars that there was no room for the actual text.

I don't know of any way to fix that problem, but you _can_ make the text smaller, adjust the fonts used, etc in the Xcode documentation window.

Since most of the docs are lifted (repurposed) from Apple's web site, they're all HTML files, and they all share common (CSS) style sheets. You can edit the style sheets (they're just text files) and change the appearance of the window.

The main one to edit is "/Developer/ADC Reference Library/documentation/Resources/CSS/frameset_styles.css", but there are many css files in the /Developer hierarchy. You can look for styles that contain stuff like "font-size: 24px", and change them.

Explore! Have fun!

Monday, June 20, 2005

Application sizes: CW vs Xcode

So, this weekend I built my small application with both Xcode and CodeWarrior, looking to quantify the differences in the executable sizes. I found that after deployment, the Xcode executable was 808KB, while the CodeWarrior one was only 364KB (60% smaller). So I went looking in the files too see where the differences were. If the differences are inn the code generation, and Xcode applications are in general 120% bigger than CodeWarrior ones, then that's a serious problem. On the other hand, if the differences are all overhead, and don't change as the applications get bigger, then that's much less of a problem (although still a PITA)

Ok. Here's what I've found out so far:
The __TEXT segment of the Xcode executable is much larger than the CW one (557K vs. 212K). Most of this extra stuff is in two sections that don't exist in the CW executable "__textcoal_nt" (256K) and "__eh_frame" (136K).

Also, the __LINKEDIT section of the Xcode executable is much larger than the CW one (243K vs 124K).

Together, these three chunks alone make the Xcode executable half a megabyte (512K) bigger than the CW one. Without those, the sizes are quite comparable (the Xcode one would even be smaller).

Now, to figure out what those sections are for!

Thursday, June 16, 2005

It's what you don't know that can hurt you

One of the "one step forward, two steps back" part of converting to Xcode is discovering where the assumptions are different.

I understand how CodeWarrior works; I've been using it for 10+ years. Xcode may look (superficially) similar, but deep down, it is radically different.

Here's an example: A default CodeWarrior project contains two targets, named " Debug" and " Final". You debug using the debug target, and then build the final target and ship what comes out. A default Xcode project also contains two targets, called "Debug" and "Release". You debug using the debug target, and then build the release target. But YOU DON'T SHIP THE RESULTS OF BUILDING THE RELEASE TARGET!

See what I mean?
If you're a CodeWarrior user, you're probably thinking "What is he smoking? Of course you do!". But with Xcode, that's not the case. You "deploy" it first. One of the steps in deploying involves running "/usr/bin/strip" on the executable, which removes debugging information that the linker put there. This is a good thing, because this makes your executables _much_ smaller.

[ Thanks to Chris E. for setting me straight on this. ]
Next up - side by side comparison of binaries.

Wednesday, June 15, 2005

Executable sizes

I have a simple application built with Nitrogen. It's called "DragPeeker X", which replaces the venerable Apple application DragPeeker, which was distributed with the "Drag and Drop Toolkit" in 1994, when the Drag Manager was new.

I got it building and running using Xcode, and it seems to work just fine.

However, I did a "Get Info" on the new app, and I was shocked - the application was about 3.2 MB in size! I went back and looked at the CodeWarrior executable, and it was about 600KB - much more reasonable. (But still too big for what it does)

I'm using gcc4, so that I am linking against the libstdc++.dylib, so the app should be smaller than before, right? (Since I don't have to carry around a copy of the C++ standard library).

So, what's going on here?
A little digging around shows lots of differences, but the big difference is the "LINKEDIT" section of the Mach-O binary. The CW binary has a section size of about 400K, but the Xcode LINKEDIT section is 2.6 MB!

In both cases the LINKEDIT section dwarfs the code actually in the application, but I don't know why the Xcode one is so much bigger (maybe it _is_ because of libstdc++.dylib)

Apparently I can't spell

Chris Espinosa, a friend of mine (and Manager, Developer Tools Productivity at Apple) informs me that the correct spelling is "Xcode", not "XCode".

Sorry about that, Chris.
I will try to do better in the future.

Tuesday, June 14, 2005

Whilst at WWDC (2)

Though it seems like I'm slagging on XCode, I'd like to point out that it seems to be a reasonable IDE; it just has some rough edges.

More edges:

1) If you control-click on a word to bring up a contextual menu, it doesn't select the word under the cursor.

2a) If you do a multiple-file find, the results have two panes, the top pane shows the files+lines where the match occurred,
and the bottom shows the file that you've got selected in the top pane. Well, if you do a find, look at a couple of files, and then do another find, the results of the second find are put in the top pane, but the bottom pane still shows whatever file you were looking at in the last set of find results.

2b) If, on the other hand, you use the documentation browser to search for stuff, it gives you a similar two-pane result window. However, in this case, clicking on one of the "hits" in the top pane shows the result in the bottom pane _and_ moves the focus back to the bottom pane. So, you can't arrow through the results.

3) Sometimes XCode gets into a state where it fails to save changed files. You can hit cmd-S, or choose Save from the menu, but it won't save the file, and it doesn't give you an error. (The little UI indications that the file is 'dirty' stay lit, and building will use the old contents of the file). This seems to happen more often if you interrupt a build before it's done.

4) XCode compiles really, really, fast - if you've got a whole lab full of fast machines to distribute compile jobs to.

Whilst at WWDC (1)

While I was at WWDC last week, my friend Lisa and I attempted to port a medium sized chunk of code (Nitrogen - available on Sourceforge) from CodeWarrior to XCode, and then to do some surgery on the code. We found a few bugs in the code - it's always good to run C++ code through a different compiler, and found some XCode oddities along the way.

Here's a couple associated with drag and drop text editing:

1) You can't just select a bunch of text in an XCode window and drag it somewhere. You have to select the text, click somewhere in the selected text, wait, 1, 2, and _then_ start dragging. If you don't wait, it will just start a new selection. I talked to one of the Cocoa text engineers later about that, and he said that this was because people would pick up their selected text and move it just a few characters/lines, when they didn't want to do that.

I think that's an inadequate reason. That's what undo was invented for. If you make a mistake, just undo.

2) Open up the "Find in Project" window. The "Find" text field is probably selected. Try to drag some text to the "Replace" text field. Can't do it. Apparently when a NSEditText item is disabled, it's really, really disabled.

More as I go over my notes.


My name is Marshall, and I am a Mac developer. I am in the process of switching over from CodeWarrior to XCode, and I thought that I would share what I found as I went.