http://bugs.winehq.org/show_bug.cgi?id=34188
--- Comment #1 from Ken Thomases ken@codeweavers.com 2013-08-01 17:41:18 CDT --- The problem has to do with the use of the Core Text API (CTFontDescriptor, in particular) in gdi32. If that happens before Cocoa is loaded, then Cocoa blows up when it tries to access fonts, such as the font used in window title bars.
Although this is not a public part of the API, CTFontDescriptor and the Cocoa NSFontDescriptor class are assumed to be toll-free bridged (interchangeable with just a type cast) in the bowels of Cocoa. However, this bridging support is only enabled if Cocoa has been loaded into the process when CTFontDescriptor is first used.
Cocoa messages a CTFontDescriptor object as though it were an NSFontDescriptor object, by sending the -symbolicTraits message. When the bridging support is not enabled, this results in the crash.
For any given Wine session, at most one process enumerates the fonts (in gdi32's initialization). It caches the font details in a volatile registry key and subsequent processes read from that cache. So, only that process uses CTFontDescriptor. I think in almost all cases, that's wineboot.exe.
With an existing, up-to-date wineprefix, wineboot doesn't show any windows. Therefore, it doesn't cause Cocoa to access fonts, and doesn't crash.
However, when it is creating or updating a wineprefix, it shows a window and, boom, down it goes.
I'm developing a workaround. I plan to make gdi32 load the graphics driver (and thus, when using the Mac driver, Cocoa) before enumerating fonts. Or, if it's not feasible to load the graphics driver at that point, I'll make gdi32 load Cocoa directly if it's going to use the Mac driver.