On Mon, 7 Jul 2008, Adam Strzelecki wrote: [...]
It was just said once that winequartz.drv won't go into official Wine, and the top reason was Objective-C and this was just a bizarre decision for me. Objective-C is almost as old as C++ and it was just chosen for an object model of OSX (NextStep previously) in opposition to pure C messaging of Windows and C++ for COM interfaces, etc.
Hehe. If it can comfort you, code submissions in Cobol and Fortran would be refused too, even though these languages are older than C++. As far as I know only C is accepted for the Wine core, and for support scripts and development tools Bourne shell and Perl scripts are accepted too. There are at least three reasons for that: * The first and probably most important reason is that we want to avoid a proliferation of languages which would make it harder to compile Wine (multiple tool chains), and also harder for developpers to understand the code. Currently if you write a test or modify notepad and you get a crash in winex11, you will be able to look at the winex11 code and hopefully figure out the reason for the crash. If winex11 was written in C++ you would first have to understand C++ in order to figure things out. The same goes with an Objective-C winequartz driver. * Additional languages may also be causing trouble for winedbg. I'm not entirely sure about that one but I believe additional code is needed to properly parse the C++ debug information and thus produce proper backtraces, be able to inspect the contents of objects, etc (actually I'm not sure winedbg supports C++ right now). Adding code in Objective-C would probably entail another round of extensions. * Finally, at least for C++, there was an issue with ABI stability. It used to be that a C++ program compile with a version of g++ (e.g. 3.3) would not be able to use a C++ library compiled with an older or newer version of g++ (2.95 or 4.x). Things may have become a bit more stable on that front. Also this may not apply to Objective-C on Mac OS X (presumably Apple does not want to break all the 3rd party applications everytime they upgrade they upgrade the standard compiler).
So IMHO no for Objective-C means no for decent Mac OSX support, period.
Is it really technically impossible to access the Quartz APIs or write Mac applications using C?