Just to explain things better, I found great sample of calling Obj-C API within pure C program: http://www.smipple.net/snippet/moriyoshi/Using%20Objective-C%20ABI%20from%20... .
This is basic application that just displays a single window, and YES it works! BUT it is 400 lines of code, it is totally obscure. Having it natively in Obj-C would be ~50 lines of small clean code. So this is what a call a "nightmare", or maybe "happy coding".
Or maybe job security. However, we have a requirement that any code submitted to the Wine project be either c or C++. ObjC cannot be included, however. I would like to see it 'wrapped' so that it could not be compiled and then the world would be upright (and this is how several other projects do this as well.)
James McKenzie
On Thu, 9 Jul 2009, James Mckenzie wrote: [...]
Or maybe job security. However, we have a requirement that any code submitted to the Wine project be either c or C++. ObjC cannot be included, however.
Actually C++ is strictly forbidden in Wine. The only language that is allowed is C; and then perl or sh for build scripts, etc.
On Mon, Jul 13, 2009 at 5:05 AM, Francois Gouget fgouget@free.fr wrote:
On Thu, 9 Jul 2009, James Mckenzie wrote: [...]
Or maybe job security. However, we have a requirement that any code submitted to the Wine project be either c or C++. ObjC cannot be included, however.
Actually C++ is strictly forbidden in Wine. The only language that is allowed is C; and then perl or sh for build scripts, etc.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Dieu dit: "M-x Lumière". Et la lumière fut.
Why is only C allowed in the first place? And isn't Obj-C supposed to be "a true superset" of C? However, even if you build with C or Obj-C, you still would have to build the Mac driver on Mac OS X. Unless you are willing to grab the Cocoa libraries and headers to use with GCC on Linux.
King InuYasha [mailto:ngompa13@gmail.com] wrote:
Why is only C allowed in the first place? And isn't Obj-C supposed to be "a true superset" of C?
One of the reasons is that the source base of Wine is already large enough with many parts that tend to bit rot since there is nobody that wants to take ownership of it after an initial code drop (and sometimes some limited time support).
Alexandre has stated that he does not want any other code than standard C in the Wine project. I think it is a measure to guarantee that there are some people (including himself) who can at least support such code in some way if that should be necessary at some point. Obj-C is very unlikely to be known by many others once the initial submitter disappears from family or other obligations.
I've looked at Obj-C code. It looks impressive but I would not attempt to understand what the different syntax elements mean.
Rolf Kalbermatter
On Mon, 13 Jul 2009, King InuYasha wrote: [...]
Actually C++ is strictly forbidden in Wine. The only language that is allowed is C; and then perl or sh for build scripts, etc.
[...]
Why is only C allowed in the first place?
The reason why C++ was forbidden is that its ABI was not very stable with g++. That is a C++ compiled on one Linux machine was unlikely to run on another if the C++ libraries were of a different version. Besides the gcc C++ ABI was incompatible with the Microsoft C++ ABI so g++ did not have the argument of making it easier to implement these MS APIs.
I think the ABI stability is somewhat fixed now (though only time will tell), but I believe this still put quite a damper on introducing new languages in the Wine codebase.
And isn't Obj-C supposed to be "a true superset" of C?
I've seen some Obj-C code and it looks really weird. Of course I've never 'learned' to program it so it's probably normal. But it's certainly the case that only developpers who know Obj-C can work on it. Contrast this with the current situation where as soon as you know C you can work on any area of Wine.
That said, from the sound of it it does really look like Apple is pushing Obj-C so maybe we don't have much choice in the matter.
Francois,
I've seen some Obj-C code and it looks really weird. Of course I've never 'learned' to program it so it's probably normal. But it's certainly the case that only developpers who know Obj-C can work on it. Contrast this with the current situation where as soon as you know C you can work on any area of Wine.
Look, anyway Obj-C is supposed to be used in Wine only for Mac support, and not for anything else. Any developer that knows how to program Mac knows Obj-C so there's nothing wrong with constraint that only developers that know Obj-C can work on it, because those are guys that know how to program Mac. Or by contradiction... even if the code was written in pure-C, non-Obj- C developers wouldn't be able to work on it anyway because they wouldn't know OSX API and wouldn't have Mac machine for development :)
That said, from the sound of it it does really look like Apple is pushing Obj-C so maybe we don't have much choice in the matter.
It's not really about Apple pushing Obj-C, but about Obj-C being a foundation of the OSX and Next operating systems, while not being as popular as C++ just because Macs doesn't share so much of the market as Windows, where C++ gained its popularity, thanks to MFC, Borland, etc.
I'd gladly help writing native Wine Mac support, but I don't want really do it hard way using obscure excessive C code, but do it in Obj- C. I do respect my own time and pure-C way is in opposition for that.
Regards,
On Tuesday 14 July 2009 7:26:39 am Adam Strzelecki wrote:
Look, anyway Obj-C is supposed to be used in Wine only for Mac support, and not for anything else. Any developer that knows how to program Mac knows Obj-C so there's nothing wrong with constraint that only developers that know Obj-C can work on it, because those are guys that know how to program Mac.
Except you don't *need* Obj-C to code on Mac. The regular C code for X11 works, too. Granted, using Apple's X implementation isn't very optimal, but it does work. Sticking with C allows all those developers to code "for Mac" as well, with no Obj-C knowledge needed.
Has Apple ever commented on making C, or even C++, bindings? Maybe some enterprising coder could make something. Personally, it'd seem more beneficial to provide C bindings, instead of forcing app developers to use a specific language or to go through a sub-optimal X implementation.
Chris Robinson [mailto:chris.kcat@gmail.com]
On Tuesday 14 July 2009 7:26:39 am Adam Strzelecki wrote:
Look, anyway Obj-C is supposed to be used in Wine only for Mac support, and not for anything else. Any developer that knows how to program Mac knows Obj-C so there's nothing wrong with constraint that only developers that know Obj-C can work on it, because those are guys that know how to program Mac.
Except you don't *need* Obj-C to code on Mac. The regular C code for X11 works, too. Granted, using Apple's X implementation isn't very optimal, but it does work. Sticking with C allows all those developers to code "for Mac" as well, with no Obj-C knowledge needed.
I see the same issue here. Rather few Mac users are programming themselves and not every Mac program is created using Obj-C. So the already small coder base is divided up even more in Obj-C and non Obj-C programmers. This means there will be even much less developers interested to work on Wine Obj-C code. And while an Obj-C programmer can understand and fix standard C code this same thing can not be said about the reverse. From what I have seen about Obj-C code I saw little resemblence with C and it could for my feeling have been Lisp, Smalltalk or any other programming language I have no clue about.
I've been programming a little for Macs in the past. Nothing serious but simply porting some existing (standard C) library code and the bindings to a platform independent programming language we use here. It was all standard C and it worked but it was not doing GUI (the platform independent programming language is used for all GUI related things). So I can't say if doing GUI on OSX without Obj-C is feasable. (I do think that the programming environment we use does use little if any Obj-C itself since its origins are from pre OS-X days and I doubt they changed the entire graphic interface code completely when introducing the OS-X support. They do however use an internal architecture where they have so called interface code that is platform dependant to provide an internal common API and the entire rest of the system is programmed almost completely platform independent in C and in more recent years mostly C++.)
I do know that the Mac API is certainly a very different API to deal with compared to Windows. There are all kinds of remainders from the old Classic Mac OS showing through and with every new version some of those APIs get depreciated but sometimes there is no obvious or even non-obvious way to do non-standard things without using those APIs.
So I do see a good reason to request Wine code being standard C (Yes, I haven't gotten befriended with C++ either so far eventhough I attended some courses and can understand it to some degree.)
Those pushing for a better integration with Wine on OS-X should maybe first come up with a good design that limits the Obj-C code to an absolute minimum and create a working proof of concept outside of the project. And going that route may even show that the actual C to Obj-C bindings are really the smallest part of the work and that writing a good graphics driver is actually hard to do both in C and Obj-C. But when done in C many more people in the Wine project can participate even if they do not know much about the Mac API.
Rolf Kalbermatter
I see the same issue here. Rather few Mac users are programming themselves and not every Mac program is created using Obj-C.
Have a look at: http://osx.iusethis.com/ There're really plenty of Mac applications and plenty of Mac developers. And all because of there're many great publications and tutorials on Mac programming. I can even right a thesis that there may be more Cocoa/Obj-C programmers than pure X11 programmers around the world.
But in general you are right. For services, console tools you don't need to even know that such thing as Obj-C exists.
But in case of GUI applications released nowadays for Mac, most of them are Obj-C/Cocoa, rest are QT, wxWidgets, Java. I don't think anybody now releases Carbon (OSX C API) based app.
I've been programming a little for Macs in the past. Nothing serious but simply porting some existing (standard C) library code and the bindings to a platform independent programming language we use here. It was all standard C and it worked but it was not doing GUI (the platform independent programming language is used for all GUI related things). So I can't say if doing GUI on OSX without Obj-C is feasable.
That's it. Mac minus GUI is regular Unix (full POSIX compatible) system, that's why it can easily run all popular (in Linux) WebServers, console tools, etc. Again not every Linux/Unix programmer is X11 programmer and can fix & dig inside Wine X11 video driver.
Those pushing for a better integration with Wine on OS-X should maybe first come up with a good design that limits the Obj-C code to an absolute minimum and create a working proof of concept outside of the project.
Hmmm? Isn't it what winequartz.drv is about? (Which is a subject of this discussion)
And going that route may even show that the actual C to Obj-C bindings are really the smallest part of the work and that writing a good graphics driver is actually hard to do both in C and Obj-C. But when done in C many more people in the Wine project can participate even if they do not know much about the Mac API.
How do you imagine anybody digging in some OS related code without having no freaking idea about its API?
It would be better if Wine went into a direction of decoupling video, font and audio drivers completely from its core. AFAIK winequartz except the driver DLL itself has to do quite many modifications (apply patches) in Wine core itself in order to run, which is pretty bad. And requires updating anytime someone updates Wine sources.
I can imagine having X11, OSX or maybe even DirectFB drivers as completely interchangeable backends for Wine that can live their life inside official releases or outside. But right Wine doesn't provide such interface since it is too much coupled with X11, FreeType, so Emmanuel (or any future maintainer) has to update winequartz.drv all the time to follow official modifications.
Regards,
Except you don't *need* Obj-C to code on Mac. The regular C code for X11 works, too. Granted, using Apple's X implementation isn't very optimal, but it does work. Sticking with C allows all those developers to code "for Mac" as well, with no Obj-C knowledge needed.
You can run X11 app on Windows as well, as there're several X11 servers. But none would appreciate that ;) And none would say you don't have to use WinAPI to program Windows. Btw. note that X11 on Mac is optional (even it is free, you need to install it youself), doesn't run all the time, and X11 apps do not have their own icons and do not resemble native Mac applications at all.
Has Apple ever commented on making C, or even C++, bindings? Maybe some enterprising coder could make something. Personally, it'd seem more beneficial to provide C bindings, instead of forcing app developers to use a specific language or to go through a sub-optimal X implementation.
Already mentioned here, there's Carbon which is pure-C API for Mac. But IMHO this won't make things easier, since it is legacy compatibility library, since you need to know its API to use it anyway, and it is far less popular that Cocoa, so has less developers. Finally there's no 64-bit Carbon and it can be taken out from futures OSX releases.
I can see real paradox here. Being against using Objective-C is supposed to bring wider support to the code (right?), but implies requirement of using either Carbon or Mac OpenGL + Core libraries, which are far LESS popular, have far LESS active programmers and LESS tutorials and books than Cocoa and Objective-C.
So forcing C for Mac support, you drastically limit possible developers that could work on the code :>
Regards,
"Adam Strzelecki" ono@java.pl wrote:
I can see real paradox here. Being against using Objective-C is supposed to bring wider support to the code (right?), but implies requirement of using either Carbon or Mac OpenGL + Core libraries, which are far LESS popular, have far LESS active programmers and LESS tutorials and books than Cocoa and Objective-C.
Which is true for low level system programming which Wine absolutely requires. The more low level API it is - the better.
So forcing C for Mac support, you drastically limit possible developers that could work on the code :>
Now you know why Wine developing is so much hard.
On Wednesday 15 July 2009 2:40:08 am Adam Strzelecki wrote:
You can run X11 app on Windows as well, as there're several X11 servers. But none would appreciate that ;) And none would say you don't have to use WinAPI to program Windows.
Actually, I know quite a few that would say you don't need to use the WinAPI to program for Windows. There are libs (eg. Qt and wxWindows), that let you create Windows apps without touching any WinAPI code directly. Such libs tend to be too heavy of a dependency for Wine to use, though.
Already mentioned here, there's Carbon which is pure-C API for Mac.
That doesn't seem to be the same thing as C bindings. As I understand it, Carbon is a legacy API that came from MacOS 9, and was brought into OSX to help with getting OS9 apps ported. Proper C bindings would have you calling Cocoa, but using a C API instead of an Obj-C API.
On Tue, 14 Jul 2009, Adam Strzelecki wrote:
Francois,
I've seen some Obj-C code and it looks really weird. Of course I've never 'learned' to program it so it's probably normal. But it's certainly the case that only developpers who know Obj-C can work on it. Contrast this with the current situation where as soon as you know C you can work on any area of Wine.
Look, anyway Obj-C is supposed to be used in Wine only for Mac support, and not for anything else. Any developer that knows how to program Mac knows Obj-C so there's nothing wrong with constraint that only developers that know Obj-C can work on it, because those are guys that know how to program Mac. Or by contradiction... even if the code was written in pure-C, non-Obj-C developers wouldn't be able to work on it anyway because they wouldn't know OSX API and wouldn't have Mac machine for development :)
I have never done any OpenGL programming, and yet I can detect and fix issues in the OpenGL or Direct3D code, such as make functions static, avoid unneeded forward dependencies, fix compilation warnings, etc. But I don't think I could do this type of thing if the code were Objective-C.
So no, even if the code is only for Macs, writing it in Obj-C will cut you off from some developpers. And yes, I have a Mac (and I'm as good at Mac development as I am at OpenGL development).
-
Adam Strzelecki -
Chris Robinson -
Dmitry Timoshkov -
Francois Gouget -
James Mckenzie -
King InuYasha -
Rolf Kalbermatter -
Rolf Kalbermatter