2 Mar
2008
2 Mar
'08
5:14 p.m.
Hi,
I know that CodeWeavers supports quite nicely Mac builds of Wine, and
CrossOver for Mac, yet all of them are X11.
There was also once Darwine - an effort to provide Carbon Wine UI
driver and Mac optimizations & L&F.
Pretty many of those were merged back to Wine, but not winequartz.drv.
Do you guys think about reviving winequartz.drv?
This would greatly improve Wine on Mac as we could have native Mac
fonts handling that's faster than FreeType, Dock icons for Wine
applications, and few others.
There's still old copy of the it hanging around, but it is abandoned,
and no longer compiles with Wine.
Or I think it would be cool to write new winecocoa.drv or sthing like
that, as Apple officially states that Carbon is deprecated.
While it is not well documented, it is pretty easy with Cocoa to make
console non-bundled process to be UI foreground process and handle
events and Dock:
(This code is copyrighted by myself ;P)
int main(int argc, const char * argv[]) {
ProcessSerialNumber psn = {0, kCurrentProcess};
OSStatus returnCode = TransformProcessType(&psn,
kProcessTransformToForegroundApplication);
SetFrontProcess(&psn);
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[NSApplication sharedApplication];
NSImage *icon = [NSImage imageNamed:@"NSApplicationIcon"];
[NSApp setApplicationIconImage:icon];
[NSApp finishLaunching];
NSWindow *window = [[NSWindow alloc]
initWithContentRect:NSMakeRect(0, 0, 100, 100)
styleMask:NSTitledWindowMask|
NSClosableWindowMask|NSMiniaturizableWindowMask|NSResizableWindowMask
backing:NSBackingStoreBuffered defer:NO];
[window center];
[window setTitle:@"Test"];
NSButton *button = [[NSButton alloc]
initWithFrame:NSMakeRect(10, 10, 80, 80)];
[button setTitle:@"What?"];
[button setBezelStyle:1];
[[window contentView] addSubview:button];
[button release];
[window makeKeyAndOrderFront:NSApp];
while(1) {
NSEvent *event = [NSApp
nextEventMatchingMask:NSAnyEventMask
untilDate
:[NSDate distantFuture]
inMode:NSDefaultRunLoopMode
dequeue:YES
];
if(event) [NSApp sendEvent:event];
}
[pool release];
return 0;
}
BTW. I heard that someone previously working for Wine project is now
in Apple, it is true?
Regards,
--
Adam Strzelecki |: nanoant.com :|
2 Mar
2 Mar
5:50 p.m.
Am Sonntag, 2. März 2008 18:14:45 schrieb Adam Strzelecki:
I know that CodeWeavers supports quite nicely Mac
builds of Wine, and
CrossOver for Mac, yet all of them are X11.
There was also once Darwine - an effort to provide Carbon Wine UI
driver and Mac optimizations & L&F.
Pretty many of those were merged back to Wine, but not winequartz.drv.
Do you guys think about reviving winequartz.drv?
I think everyone would greatly
welcome efforts to continue it, and in fact
Steven Edwards is currently trying to bring the old driver up to date.
So the short answer: We accept (well written) patches!
The long answer: This isn't an easy undertaking. For one part, Wine's display
driver model(how gdi32, user32, opengl32 and d3d talk to winex11.drv) still
needs a bit of cleanup, currently some abstraction layers are at the wrong
place. The other issue is that *a lot* of implicit knowledge is encoded in
winex11.drv. To add to this, the gain of a native quartz/cocoa/whatever
driver is rather limited:
* Faster font handling: Maybe, although I personally never had an app that had
font performance problems. My view is rather limited though
* Dock integration: Crossover has that, despite using winex11.drv. This is an
entirely different story and comes down to the different ideas what
an "Application" is at user interface level.
What we would gain:
* No mess with X11 servers. Apple's X11 is rather broken. No Exposé
headbanging with quartz_wm. No messing with Apple X11's opengl
* No need for a DIB engine on MacOS. MacOS can give us everything we need.
* No troubles with relative mouse movements, like we have them on X11 even on
Linux
6:53 p.m.
Hi,
On Sun, Mar 2, 2008 at 12:50 PM, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
Am Sonntag, 2. März 2008 18:14:45 schrieb Adam
Strzelecki:
There is a public branch where the Wine quartzdrv will go even if its
not accepted in to Winehq. I have been from time to time bringing in
infrastructure changes from the old winequartzdrv however the current
tree is empty as the developer of the prior editions, Emmanuel
Maillard, is in the process of overhauling it from recent changes to
the Wine driver model.
Keep an eye on
http://wiki.winehq.org/MacOSX/QuartzDriver
And hopefully in the next few weeks we will have a newer patch in the
winequartzdrv tree for a more recent version of Wine. I am not sure
what design changes Emmanuel is wanting to make but hopefully they
will be more to Alexandre's liking and can eventually go in to normal
winehq. If you want to work on quartzdrv with Emmanuel, send him an
email to get an idea of what he needs and what the design will be,
then apply for write access to http://repo.or.cz and I will add you to
the winequartzdrv branch.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Do you guys think about reviving winequartz.drv?
I think everyone would greatly welcome efforts to continue it, and in fact
Steven Edwards is currently trying to bring the old driver up to date.
9 p.m.
Keep an eye on
http://wiki.winehq.org/MacOSX/QuartzDriver
Oh, that's awesome! How did I missed this.
And hopefully in the next few weeks we will have a
newer patch in the
winequartzdrv tree for a more recent version of Wine. I am not sure
what design changes Emmanuel is wanting to make but hopefully they
will be more to Alexandre's liking and can eventually go in to normal
winehq. If you want to work on quartzdrv with Emmanuel, send him an
email to get an idea of what he needs and what the design will be,
then apply for write access to http://repo.or.cz and I will add you to
the winequartzdrv branch.
There're very neat Wine Mac builds made on http://www.kronenberg.org/darwine/
Do you have contact with the maintainer? I believe you can work out
great Mac distro together especially once quartz is ready.
Cheers,
--
Adam Strzelecki |: nanoant.com :|
9:13 p.m.
Keep an eye
on
http://wiki.winehq.org/MacOSX/QuartzDriver
Oh, that's awesome! How did I missed this. 
3 Mar
3 Mar
3 a.m.
"Adam Strzelecki" <ono(a)java.pl> wrote:
There're very neat Wine Mac builds made on
http://www.kronenberg.org/darwine/
Do you have contact with the maintainer? I believe you can work out
great Mac distro together especially once quartz is ready.
"Neat" is what sense? It's not clear what additional functionality they
provide,
what's the status of quartz.drv in their sources, and why they don't send patches
to WineHQ. Besides that sites claims that "Darwine and wine are released under
the gpl", that's plain wrong.
Could you please remove the "Reply-To:" header when posting to Wine lists?
--
Dmitry.
3:24 a.m.
"Dmitry Timoshkov" dmitry(a)codeweavers.com wrote:
The following notice in the upper right corner on that site makes it clear why :-)
"Bevore You install, please make sure:
Tiger users: install X11 from your Tiger Installation DVD"
--
Dmitry.
There're
very neat Wine Mac builds made on http://www.kronenberg.org/darwine/
Do you have contact with the maintainer? I believe you can work out
great Mac distro together especially once quartz is ready.
"Neat" is what sense? It's not clear what additional functionality they
provide,
what's the status of quartz.drv in their sources, and why they don't send
patches
to WineHQ.
3:26 a.m.
On Sun, Mar 2, 2008 at 10:00 PM, Dmitry Timoshkov
<dmitry(a)codeweavers.com> wrote:
"Neat" is what sense? It's not clear
what additional functionality they provide,
what's the status of quartz.drv in their sources, and why they don't send
patches
to WineHQ. Besides that sites claims that "Darwine and wine are released under
the gpl", that's plain wrong.
Could you please remove the "Reply-To:" header when posting to Wine lists?
Dude chill with the hostility. Winehq currently provides no
functionality for Mac users...see here
http://www.winehq.org/site/download
No one is currently offering officially blessed Winehq builds whenever
Alexandre tags a release. There is no need in anyone to send patches
to Winehq for code that we know Julliard is going to reject. He stated
it to us during the Mac discussion at Wineconf in Redding that he
viewed Darwine as a separate project and should do its only bundling.
Basically anything done in Objective C he does not want in the tree
which includes half of the current winequartzdrv, the Darwine launcher
and Doc code and just about everything else.
If you want to review a patch, look at the patch for 0.9.48
http://sourceforge.net/tracker/?group_id=69890&atid=526089
And help further abstract user32/x11drv like has been done for Window
creation and Window positioning.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
3:45 a.m.
"Steven Edwards" <winehacker(a)gmail.com> wrote:
On Sun, Mar 2, 2008 at 10:00 PM, Dmitry Timoshkov
<dmitry(a)codeweavers.com> wrote:
I have no idea why you're treating asking the questions as a "hostility".
This is the developers list, not the list for user complaints. Sending
the patches is a usual activity here, not vague reasoning.
"Neat" is what sense? It's not
clear what additional functionality they provide,
what's the status of quartz.drv in their sources, and why they don't send
patches
to WineHQ. Besides that sites claims that "Darwine and wine are released under
the gpl", that's plain wrong.
Could you please remove the "Reply-To:" header when posting to Wine lists?
Dude chill with the hostility. Winehq currently provides no
functionality for Mac users...see here
http://www.winehq.org/site/download
No one is currently offering officially blessed Winehq builds whenever
Alexandre tags a release.
Feel free to provide/suggest one.
There is no need in anyone to send patches
to Winehq for code that we know Julliard is going to reject. He stated
it to us during the Mac discussion at Wineconf in Redding that he
viewed Darwine as a separate project and should do its only bundling.
Basically anything done in Objective C he does not want in the tree
which includes half of the current winequartzdrv, the Darwine launcher
and Doc code and just about everything else.
If you want to review a patch, look at the patch for 0.9.48
http://sourceforge.net/tracker/?group_id=69890&atid=526089
And help further abstract user32/x11drv like has been done for Window
creation and Window positioning.
Aren't you supposed to work on that according to
http://wiki.winehq.org/MacOSX/QuartzDriver?
Looks like you overreacted, http://www.kronenberg.org/darwine/ has nothing
to do with darwine except using its name.
--
Dmitry.
4:13 a.m.
Dmitry Timoshkov wrote:
Looks like you overreacted,
http://www.kronenberg.org/darwine/ has nothing
to do with darwine except using its name.
Actually, I have Mike's code and it uses the Darwine build system and
applies two patches to it. One brings in FontForge so that Apple Native
fonts will work in Wine, and this is discussed on the Building Wine for
MacOSX web page. The other fixes a known problem for Leopard's handling
of screen location (it does not always use :0.0 for security
reasons). I will suggest that he bring back into the Darwine project
his fixes. I think he already has tried but received no response from
the Project.
As to the rest, AJ has stated, repeatedly, that he wants no Obj-C in the
Wine tree. This prevents bringing in some Mac specific code, and
completely eliminates the winequartz.drv project. I'm not going to
argue with his reasoning, but this forces a Native version of Wine to be
a continuous fork with fixes in Wine requiring fixes (if winex11.drv is
changed) in the code.
As to support for the Mac, I have been doing what some Mac users are
doing now: Building my own. Unfortunately, I do not have a place to
put my builds where the public can download them. Also, they contain
code that has not been approved for the main Wine build and may contain
'dangerous' code. I'm willing to risk my system's stability to test,
but not others.
James McKenzie
5 a.m.
Any developer that wants to maintain source and/or binaries on the
Darwine project at SF.net is welcome to do so.
I have responded to every such request that I have seen, which isn't to
say of course that someone hasn't sent such a message that I haven't
seen. Folks should be aware that you must subscribe to the list to post
(although I do manually review posts from non-subscribers and try to put
through any that are actually about Darwine and not male enhancement or
get rich quick...). It is true that questions from users trying to run
application X may not get much help other than being told Darwine isn't
ready for end users.
Of course folks are also welcome to host their own builds, and I'd be
happy if someone came along and just fixed the web site (which suffered
greatly in the move back to SF.net from opendarwin.org - I didn't want
to leave SF.net in the first place...), so we could point other folks to
those builds.
It was never my intention that Darwine be a fork of Wine, but rather a
friendly haven for Mac developers working on Wine. If that means doing
more for users such as hosting binaries, then I'm fine with that too.
Geeze. I just looked at the download stats and folks are pulling almost
300 copies a day (nearly 7GB). It would be nice if they were using that
bandwidth to get something useful...
Jim White
http://darwine.sf.net/
James McKenzie wrote:
Dmitry Timoshkov wrote:
Looks like you overreacted,
http://www.kronenberg.org/darwine/ has nothing
to do with darwine except using its name.
Actually, I have Mike's code and it uses the Darwine build system and
applies two patches to it. One brings in FontForge so that Apple Native
fonts will work in Wine, and this is discussed on the Building Wine for
MacOSX web page. The other fixes a known problem for Leopard's handling
of screen location (it does not always use :0.0 for security
reasons). I will suggest that he bring back into the Darwine project
his fixes. I think he already has tried but received no response from
the Project.
As to the rest, AJ has stated, repeatedly, that he wants no Obj-C in the
Wine tree. This prevents bringing in some Mac specific code, and
completely eliminates the winequartz.drv project. I'm not going to
argue with his reasoning, but this forces a Native version of Wine to be
a continuous fork with fixes in Wine requiring fixes (if winex11.drv is
changed) in the code.
As to support for the Mac, I have been doing what some Mac users are
doing now: Building my own. Unfortunately, I do not have a place to
put my builds where the public can download them. Also, they contain
code that has not been approved for the main Wine build and may contain
'dangerous' code. I'm willing to risk my system's stability to test,
but not others.
James McKenzie
9:39 a.m.
James McKenzie wrote:
As to the rest, AJ has stated, repeatedly, that he
wants no Obj-C in
the
Wine tree. This prevents bringing in some Mac specific code, and
completely eliminates the winequartz.drv project. I'm not going to
argue with his reasoning, but this forces a Native version of Wine
to be
a continuous fork with fixes in Wine requiring fixes (if winex11.drv
is
changed) in the code.
That means no good for Mac users. With Leopard release Carbon (pure C)
is more-less deprecated API, Apple pushes all new functionality only
to Obj-C Cocoa, also there's is no 64-bit Carbon at all.
I don't want to argue what's wrong with Obj-C that it cannot go into
Wine code-base, but staying out of it won't ever bring full Wine
support for Mac users.
Dmitry Timoshkov wrote:
This is the developers list, not the list for user
complaints. Sending
the patches is a usual activity here, not vague reasoning.
That's bizarre, but OK, every society has its own rules. I raised here
subject about implementation (or call it development) of some Wine
module (winequartz.drv), so I thought it is more adequate to post it
here, but if you call it user complaint alright, this list is "sending
patches" (even I thought wine-patches is the one) I cut this chit-chat.
--
Adam Strzelecki |: nanoant.com :|
P.S. What was wrong with "Reply-To" header? I call it normal habit at
other lists.
4:47 a.m.
On Sun, Mar 2, 2008 at 10:45 PM, Dmitry Timoshkov
<dmitry(a)codeweavers.com> wrote:
I have no idea why you're treating asking the
questions as a "hostility".
This is the developers list, not the list for user complaints. Sending
the patches is a usual activity here, not vague reasoning.
Sorry I misread one of your statements. There is no point in sending
the patches when we already know they are going to be rejected.
Feel free to provide/suggest one.
There is a script posted here to make it less of a hassle to build a
stock Winehq release on OS X.
http://www.wine-forum.org/showthread.php?t=16
I'm happy to start making builds of Winehq snapshots for OS X. I just
don't see the point when the Darwine packages are better for the end
user experience. With Winehelper you get Doc integration and a partial
menu system. The stock X.org on OS X is broken and has inherit
overhead that will always be present, being able to write directly to
the native Windowing system seems like a much more logical long term
solution rather than trying to keep Xorg from breaking and or
developing hacks to work around X and its tricky interaction with
Quartz.
Aren't you supposed to work on that according to
http://wiki.winehq.org/MacOSX/QuartzDriver?
I have been but I've put my work on it on hold pending a new round of
patches from Emmanuel. My point was that you asked for patches, there
is one for your pleasure. I welcome your thoughts and I am sure
Emmanuel does as well. I know Pierre seemed to get disappointed when
he wanted to develop quartzdrv in winehq but could not get a clear
idea of what Julliard really wanted. What do you want/think quartzdrv
in winehq should look like? How should it be implemented? What
infrastructure changes should be made?
Looks like you overreacted,
http://www.kronenberg.org/darwine/ has nothing
to do with darwine except using its name.
Sorry like I said I mis-read the other email. My point was that it
does not seem that anyone wants to provide real solutions. I don't
think Emmanuel or Pierre really knew what Julliard wants in Quartzdrv.
I don't know know what you want in it. I know there is a certain level
of abstraction that needs to be done in user32 and I was glad to see
Julliard started working on it, thats what made me interested in
bringing some life back in to quartzdrv. It would be nice if those
people that are the experts on the Wine driver model would speak up
and say would needs to be done before we can have this driver.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
5:04 a.m.
"Steven Edwards" <winehacker(a)gmail.com> wrote:
I have been but I've put my work on it on hold
pending a new round of
patches from Emmanuel. My point was that you asked for patches, there
is one for your pleasure. I welcome your thoughts and I am sure
Emmanuel does as well. I know Pierre seemed to get disappointed when
he wanted to develop quartzdrv in winehq but could not get a clear
idea of what Julliard really wanted. What do you want/think quartzdrv
in winehq should look like? How should it be implemented? What
infrastructure changes should be made?
Alexandre has moved a lot of things to user32 that previously were needed
to be implemented on the driver side (SetWindowPos, ShowWindow, DCE) which
should greatly simplify the quartzdrv efforts.
--
Dmitry.
6 Mar
6 Mar
2:08 p.m.
Hi,
I post a new quartzdrv patch for wine-0.9.56 on Darwine SF patches
page :
http://sourceforge.net/tracker/index.php?func=detail&aid=1908759&gr…
It's not fully update to wine changes (SysCommandSizeMove didn't be
reviewed)
and don't contain all changes I initially planned but will be next time.
Cheers
Emmanuel
Le 2 mars 08 à 19:53, Steven Edwards a écrit :
Hi,
On Sun, Mar 2, 2008 at 12:50 PM, Stefan Dösinger <stefan(a)codeweavers.com
wrote:
Am Sonntag, 2. März 2008 18:14:45 schrieb Adam Strzelecki:
There is a public branch where the Wine quartzdrv will go even if its
not accepted in to Winehq. I have been from time to time bringing in
infrastructure changes from the old winequartzdrv however the current
tree is empty as the developer of the prior editions, Emmanuel
Maillard, is in the process of overhauling it from recent changes to
the Wine driver model.
Keep an eye on
http://wiki.winehq.org/MacOSX/QuartzDriver
And hopefully in the next few weeks we will have a newer patch in the
winequartzdrv tree for a more recent version of Wine. I am not sure
what design changes Emmanuel is wanting to make but hopefully they
will be more to Alexandre's liking and can eventually go in to normal
winehq. If you want to work on quartzdrv with Emmanuel, send him an
email to get an idea of what he needs and what the design will be,
then apply for write access to http://repo.or.cz and I will add you to
the winequartzdrv branch.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Do you guys think about reviving winequartz.drv?
I think everyone would greatly welcome efforts to continue it, and
in fact
Steven Edwards is currently trying to bring the old driver up to
date.
4:12 p.m.
Hi,
On Thu, Mar 6, 2008 at 9:08 AM, Emmanuel Maillard <mahanuu(a)free.fr> wrote:
I post a new quartzdrv patch for wine-0.9.56 on
Darwine SF patches
page :
http://sourceforge.net/tracker/index.php?func=detail&aid=1908759&gr…
It's not fully update to wine changes (SysCommandSizeMove didn't be
reviewed)
and don't contain all changes I initially planned but will be next time.
It looks really good. With the most recent changes I can start Office
2003 applications such as Excel and Winword
http://steven-edwards.kicks-ass.org/~sedwards/quartzdrv/excel2.png
http://steven-edwards.kicks-ass.org/~sedwards/quartzdrv/excel3.png
http://steven-edwards.kicks-ass.org/~sedwards/quartzdrv/excel4.png
http://steven-edwards.kicks-ass.org/~sedwards/quartzdrv/excel5.png
http://steven-edwards.kicks-ass.org/~sedwards/quartzdrv/winword.png
The only problem I have is that the windows are not being managed. It
looks like MainMenu.nib is not being created properly by the
patch/script. Is this a known issue or is that SysCommandSizeMove
problem?
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
13 Mar
13 Mar
3:38 a.m.
Emmanuel Maillard wrote:
Hi,
I post a new quartzdrv patch for wine-0.9.56 on Darwine SF patches
page :
http://sourceforge.net/tracker/index.php?func=detail&aid=1908759&gr…
It's not fully update to wine changes (SysCommandSizeMove didn't be
reviewed)
and don't contain all changes I initially planned but will be next time.
Cheers
Emmanuel
Thank you. I also noticed there are new .nib files available.
James McKenzie
4 Jul
4 Jul
10:37 a.m.
Hi Emmanuel, hello Wine developers,
Latest WineQuartz.drv patch is 0.9.58. Is there any change for more
recent release? I tried this patch with 1.0-1 however it has too many
conflicts.
It would be most convenient if you had just update
http://repo.or.cz/w/wine/winequartzdrv.git
to match 1.1.0 somehow and include Quartz.
Since Wine passed 1.0 (woohoo!) maybe someone from the direction can
revise Mac support? Even there're numerous Emmanuel efforts to provide
Mac UI driver instead of X11, it will be always pushed aside, and
sentenced to death, because it is not in official sources.
I know Alexandre Julliard's decision about NOT taking any Objective-C
sources (.m) into the Wine, but maybe this can be revised, anyway
all .m rules will be only present on Mac platforms. Using Objective-C
is only way to make fair support for Mac OS GUI, as those whole GUI
system is objective.
Moreover then what's the point of keeping winex11.drv and all GUI
driver infrastructure in Wine if nothing else but X11 is NOT accepted
into official source?
Forgive me what I say now, but I just it would be more fair if someone
from Codeweavers just said that Wine's official support for Mac OS X
is against their business with CrossOver and this is the real reason
they reject winequartz.drv from Emmanuel Maillard.
Frankly I'd really pay for CrossOver or Wine, if it was what 1.0-1 is
but with native Mac UI, so each wine process has it's own dock icon,
and no X11 is needed and native Mac font system.
Regards,
--
Adam Strzelecki |: nanoant.com :|
12:22 p.m.
2008/7/4 Adam Strzelecki <ono(a)java.pl>pl>:
Hi Emmanuel, hello Wine developers,
Latest WineQuartz.drv patch is 0.9.58. Is there any change for more
recent release? I tried this patch with 1.0-1 however it has too many
conflicts.
It would be most convenient if you had just update
http://repo.or.cz/w/wine/winequartzdrv.git
to match 1.1.0 somehow and include Quartz.
Someone needs to do the work to resolve the conflicts that you just
mentioned. Do you expect that to just magically happen with no work?
Since Wine passed 1.0 (woohoo!) maybe someone from the
direction can
revise Mac support? Even there're numerous Emmanuel efforts to provide
Mac UI driver instead of X11, it will be always pushed aside, and
sentenced to death, because it is not in official sources.
I know Alexandre Julliard's decision about NOT taking any Objective-C
sources (.m) into the Wine, but maybe this can be revised, anyway
all .m rules will be only present on Mac platforms. Using Objective-C
is only way to make fair support for Mac OS GUI, as those whole GUI
system is objective.
While I don't know how complete the code is or how well it work, once
a reasonable set of applications work the same or better with
winequartz.drv as they do with winex11.drv then there will likely be
enough demand to overcome the objection or an alternative solution
will be found.
Moreover then what's the point of keeping
winex11.drv and all GUI
driver infrastructure in Wine if nothing else but X11 is NOT accepted
into official source?
Huh?
Forgive me what I say now, but I just it would be more fair if someone
from Codeweavers just said that Wine's official support for Mac OS X
is against their business with CrossOver and this is the real reason
they reject winequartz.drv from Emmanuel Maillard.
Oh yeah, sure...
Frankly I'd really pay for CrossOver or Wine, if
it was what 1.0-1 is
but with native Mac UI, so each wine process has it's own dock icon,
and no X11 is needed and native Mac font system.
And that is why your conspiracy theory is complete and utter rubbish -
because CodeWeavers would get many more customers with a working
quartz driver. The real reasons are technical. If they weren't then
you would already find CrossOver 7.0 shipping with winequartz.drv,
which it doesn't.
--
Rob Shearman
8:49 p.m.
Hi,
Le 4 juil. 08 à 12:37, Adam Strzelecki a écrit :
Hi Emmanuel, hello Wine developers,
Latest WineQuartz.drv patch is 0.9.58. Is there any change for more
recent release? I tried this patch with 1.0-1 however it has too
many conflicts.
It would be most convenient if you had just update
http://repo.or.cz/w/wine/winequartzdrv.git
to match 1.1.0 somehow and include Quartz.
I resolved conflicts for wine-1.0, but didn't take a look yet for
wine-1.1.0, i just know that's some changes in user32 and winex11.drv
have to be update in winequartz.drv too.
I will see this week end if i can find free time to make a new patch
for winequartz.drv and send it to SourceForge.
(OpenGL is broken in winequartz.drv actually, because of a lack of
time to fix it)
Since Wine passed 1.0 (woohoo!) maybe someone from the
direction can
revise Mac support? Even there're numerous Emmanuel efforts to
provide Mac UI driver instead of X11, it will be always pushed
aside, and sentenced to death, because it is not in official sources.
I know Alexandre Julliard's decision about NOT taking any Objective-
C sources (.m) into the Wine, but maybe this can be revised, anyway
all .m rules will be only present on Mac platforms. Using Objective-
C is only way to make fair support for Mac OS GUI, as those whole
GUI system is objective.
Moreover then what's the point of keeping winex11.drv and all GUI
driver infrastructure in Wine if nothing else but X11 is NOT
accepted into official source?
Forgive me what I say now, but I just it would be more fair if
someone from Codeweavers just said that Wine's official support for
Mac OS X is against their business with CrossOver and this is the
real reason they reject winequartz.drv from Emmanuel Maillard.
Frankly I'd really pay for CrossOver or Wine, if it was what 1.0-1
is but with native Mac UI, so each wine process has it's own dock
icon, and no X11 is needed and native Mac font system.
Regards,
--
Adam Strzelecki |: nanoant.com :|
Cheers
Emmanuel
9:25 p.m.
Emmanuel Maillard wrote:
Hi,
Le 4 juil. 08 à 12:37, Adam Strzelecki a écrit :
Good to read from you.
Hi Emmanuel, hello Wine developers,
Latest WineQuartz.drv patch is 0.9.58. Is there any change for more
recent release? I tried this patch with 1.0-1 however it has too
many conflicts.
It would be most convenient if you had just update
http://repo.or.cz/w/wine/winequartzdrv.git
to match 1.1.0 somehow and include Quartz.
I resolved conflicts for wine-1.0, but didn't take
a look yet for
wine-1.1.0, i just know that's some changes in user32 and winex11.drv
have to be update in winequartz.drv too.
Please contact me off-list when this is complete. I would like to get
this into Darwine and see what needs to be fixed. I would like to see
Darwine become a more complete Mac application and to leave X11 behind.
Not that the current program is not complete, but Mac users tend to not
like to look at and use X11 based applications.
I will see this week end if i can find free time to
make a new patch
for winequartz.drv and send it to SourceForge.
(OpenGL is broken in winequartz.drv actually, because of a lack of
time to fix it)
The rumor was that OpenGL was broken in Mac OS X and not in
winequartz.drv. Thank you for the clarification.
I for one, support your ongoing efforts to support the Quartz interface
for Mac OS X applications, like Wine.
James McKenzie
3 Jan
3 Jan
3:14 a.m.
Emmanuel Maillard wrote:
Hi,
Le 4 juil. 08 à 12:37, Adam Strzelecki a écrit :
Emmanuel:
What is the status of winequartz.drv? It looks like your last patch was
for 1.1.2.
James McKenzie
Hi Emmanuel, hello Wine developers,
Latest WineQuartz.drv patch is 0.9.58. Is there any change for more
recent release? I tried this patch with 1.0-1 however it has too
many conflicts.
It would be most convenient if you had just update
http://repo.or.cz/w/wine/winequartzdrv.git
to match 1.1.0 somehow and include Quartz.
I resolved conflicts for wine-1.0, but didn't take a look yet for
wine-1.1.0, i just know that's some changes in user32 and winex11.drv
have to be update in winequartz.drv too.
I will see this week end if i can find free time to make a new patch
for winequartz.drv and send it to SourceForge.
(OpenGL is broken in winequartz.drv actually, because of a lack of
time to fix it)
Since Wine passed 1.0 (woohoo!) maybe someone
from the direction can
revise Mac support? Even there're numerous Emmanuel efforts to
provide Mac UI driver instead of X11, it will be always pushed
aside, and sentenced to death, because it is not in official sources.
I know Alexandre Julliard's decision about NOT taking any Objective-
C sources (.m) into the Wine, but maybe this can be revised, anyway
all .m rules will be only present on Mac platforms. Using Objective-
C is only way to make fair support for Mac OS GUI, as those whole
GUI system is objective.
Moreover then what's the point of keeping winex11.drv and all GUI
driver infrastructure in Wine if nothing else but X11 is NOT
accepted into official source?
Forgive me what I say now, but I just it would be more fair if
someone from Codeweavers just said that Wine's official support for
Mac OS X is against their business with CrossOver and this is the
real reason they reject winequartz.drv from Emmanuel Maillard.
Frankly I'd really pay for CrossOver or Wine, if it was what 1.0-1
is but with native Mac UI, so each wine process has it's own dock
icon, and no X11 is needed and native Mac font system.
Regards,
--
Adam Strzelecki |: nanoant.com :|
Cheers
Emmanuel
7 Jan
7 Jan
5:11 p.m.
Le 3 janv. 09 à 04:14, James McKenzie a écrit :
Emmanuel Maillard wrote:
Hi,
I didn't really work on winequartz.drv since this patch, start a new
version at the beginning of October,
but more or less waiting for DIB engine.
Emmanuel
Hi,
Le 4 juil. 08 à 12:37, Adam Strzelecki a écrit :
Emmanuel:
What is the status of winequartz.drv? It looks like your last patch
was for 1.1.2.
James McKenzie
Hi Emmanuel, hello Wine developers,
Latest WineQuartz.drv patch is 0.9.58. Is there any change for
more recent release? I tried this patch with 1.0-1 however it has
too many conflicts.
It would be most convenient if you had just update
http://repo.or.cz/w/wine/winequartzdrv.git
to match 1.1.0 somehow and include Quartz.
I resolved conflicts for wine-1.0, but didn't take a look yet for
wine-1.1.0, i just know that's some changes in user32 and winex11.drv
have to be update in winequartz.drv too.
I will see this week end if i can find free time to make a new
patch for winequartz.drv and send it to SourceForge.
(OpenGL is broken in winequartz.drv actually, because of a lack of
time to fix it)
Since Wine passed 1.0 (woohoo!) maybe someone
from the direction
can revise Mac support? Even there're numerous Emmanuel efforts
to provide Mac UI driver instead of X11, it will be always
pushed aside, and sentenced to death, because it is not in
official sources.
I know Alexandre Julliard's decision about NOT taking any
Objective- C sources (.m) into the Wine, but maybe this can be
revised, anyway all .m rules will be only present on Mac
platforms. Using Objective- C is only way to make fair support for
Mac OS GUI, as those whole GUI system is objective.
Moreover then what's the point of keeping winex11.drv and all GUI
driver infrastructure in Wine if nothing else but X11 is NOT
accepted into official source?
Forgive me what I say now, but I just it would be more fair if
someone from Codeweavers just said that Wine's official support
for Mac OS X is against their business with CrossOver and this is
the real reason they reject winequartz.drv from Emmanuel Maillard.
Frankly I'd really pay for CrossOver or Wine, if it was what
1.0-1 is but with native Mac UI, so each wine process has it's
own dock icon, and no X11 is needed and native Mac font system.
Regards,
--
Adam Strzelecki |: nanoant.com :|
Cheers
Emmanuel
13 Jan
13 Jan
3:09 a.m.
Emmanuel Maillard wrote:
Le 3 janv. 09 à 04:14, James McKenzie a écrit :
Well, I hope your wait will not be long for the DIB engine.
I await the next winequartz.drv release and will keep checking here.
James McKenzie
Emmanuel Maillard wrote:
Hi,
I didn't really work on winequartz.drv since this patch, start a new
version at the beginning of October,
but more or less waiting for DIB engine.
Emmanuel Hi,
Le 4 juil. 08 à 12:37, Adam Strzelecki a écrit :
Emmanuel:
What is the status of winequartz.drv? It looks like your last patch
was for 1.1.2.
James McKenzie
Hi Emmanuel, hello Wine developers,
Latest WineQuartz.drv patch is 0.9.58. Is there any change for
more recent release? I tried this patch with 1.0-1 however it has
too many conflicts.
It would be most convenient if you had just update
http://repo.or.cz/w/wine/winequartzdrv.git to match 1.1.0 somehow
and include Quartz.
I resolved conflicts for wine-1.0, but didn't take a look yet for
wine-1.1.0, i just know that's some changes in user32 and winex11.drv
have to be update in winequartz.drv too.
I will see this week end if i can find free time to make a new
patch for winequartz.drv and send it to SourceForge.
(OpenGL is broken in winequartz.drv actually, because of a lack of
time to fix it)
Since Wine passed 1.0 (woohoo!) maybe someone
from the direction
can revise Mac support? Even there're numerous Emmanuel efforts
to provide Mac UI driver instead of X11, it will be always pushed
aside, and sentenced to death, because it is not in official sources.
I know Alexandre Julliard's decision about NOT taking any
Objective- C sources (.m) into the Wine, but maybe this can be
revised, anyway all .m rules will be only present on Mac
platforms. Using Objective- C is only way to make fair support for
Mac OS GUI, as those whole GUI system is objective.
Moreover then what's the point of keeping winex11.drv and all GUI
driver infrastructure in Wine if nothing else but X11 is NOT
accepted into official source?
Forgive me what I say now, but I just it would be more fair if
someone from Codeweavers just said that Wine's official support
for Mac OS X is against their business with CrossOver and this is
the real reason they reject winequartz.drv from Emmanuel Maillard.
Frankly I'd really pay for CrossOver or Wine, if it was what 1.0-1
is but with native Mac UI, so each wine process has it's own dock
icon, and no X11 is needed and native Mac font system.
Regards,
--
Adam Strzelecki |: nanoant.com :|
Cheers
Emmanuel
4 Jul
4 Jul
9:43 p.m.
Comments on Adam's message
Adam Strzelecki wrote:
Hi Emmanuel, hello Wine developers,
Since Wine passed 1.0 (woohoo!) maybe someone from the direction can
revise Mac support? Even there're numerous Emmanuel efforts to provide
Mac UI driver instead of X11, it will be always pushed aside, and
sentenced to death, because it is not in official sources.
Mac OS X support is really not on the radar, from what I can determine.
Remember the original goal of Wine was to allow Windows programs to run
on a Windows API for Linux and UNIX. Mac OSX switched from a
proprietary system to FreeBSD/OpenBSD after the project started. Also
add that a parallel project was started to allow Windows32s programs to
run on OS/2.
I know Alexandre Julliard's decision about NOT
taking any Objective-C
sources (.m) into the Wine, but maybe this can be revised, anyway
all .m rules will be only present on Mac platforms. Using Objective-C
is only way to make fair support for Mac OS GUI, as those whole GUI
system is objective.
There are several reasons why ObjC code is not allowed in the Wine
project. First, the code cannot be examined by Alexandre. He does not
have the desire to build it. I don't know if he does or does not own a
Mac. The second is that Wine is and continues to be written in 'c'.
ObjC code may cause problems with 'straight' c compilers, like those
that are included with Linux. This happens even if ObjC code is wrapped
in selection statements as the compiler must 'read' through all of the code.
Thus, all Mac specific code has to reside outside of the main Wine
project. I highly recommend that we revive the Darwine project and
place Emmanuel's and others code into this project's add-on code. We
can also help with the PowerPc to X86 emulator that is needed by the
older processors to properly work with X86 code.
Moreover then what's the point of keeping
winex11.drv and all GUI
driver infrastructure in Wine if nothing else but X11 is NOT accepted
into official source?
Because there may be additional code to support the Windows GUI
framework, which is within the scope of the Wine project. One purpose
of Wine is to emulate the API of an older version of Windows without the
need to have virtual machines.
Forgive me what I say now, but I just it would be more
fair if someone
from Codeweavers just said that Wine's official support for Mac OS X
is against their business with CrossOver and this is the real reason
they reject winequartz.drv from Emmanuel Maillard.
Maybe this could be further queried as: "What is CodeWeaver's offical
stance on supporting a Mac OS X native user interface when the code
becomes stable and supportable?" and "Would CodeWeavers consider
bringing Emmanuel on as a paid employee at that time to ensure that the
code is maintained?"
Frankly I'd really pay for CrossOver or Wine, if
it was what 1.0-1 is
but with native Mac UI, so each wine process has it's own dock icon,
and no X11 is needed and native Mac font system.
I would also do such a thing, even if it were in the future plans of
CodeWeavers. I would like to see a more programs be given a native Mac
OS X GUI 'wrapper'. However, this may take years (as in the
OpenOffice.org and NeoOffice.org projects) or be found not practical;
this is the case for several projects. Keep in mind that what we want
may not be possible or financially reasonable.
James McKenzie
10:16 p.m.
On Fri, Jul 4, 2008 at 5:43 PM, James McKenzie
<jjmckenzie51(a)sprintpcs.com> wrote:
Maybe this could be further queried as: "What is
CodeWeaver's offical
stance on supporting a Mac OS X native user interface when the code
becomes stable and supportable?" and "Would CodeWeavers consider
bringing Emmanuel on as a paid employee at that time to ensure that the
code is maintained?"
I can't speak for CodeWeavers, being a former employee now running a
competing business but I plan on looking at the new 1.0 Quartzdrv and
if the performance is acceptable (it was not in prior versions),
building a custom version of Bordeaux for OS X. Not that I expect it
to make much money, Bordeaux for Linux has not brought in that much
yet, but if it does, I'm willing to try to help fund development.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
10:57 p.m.
Steven Edwards wrote:
On Fri, Jul 4, 2008 at 5:43 PM, James McKenzie
<jjmckenzie51(a)sprintpcs.com> wrote:
Steven:
Great. I would like to see more development work with Emmanuel's work.
Of course, Emmanuel's code will never be incorporated into the main Wine
master because it contains ObjC code.
James McKenzie
Maybe this could be further queried as:
"What is CodeWeaver's offical
stance on supporting a Mac OS X native user interface when the code
becomes stable and supportable?" and "Would CodeWeavers consider
bringing Emmanuel on as a paid employee at that time to ensure that the
code is maintained?"
I can't speak for CodeWeavers, being a former employee now running a
competing business but I plan on looking at the new 1.0 Quartzdrv and
if the performance is acceptable (it was not in prior versions),
building a custom version of Bordeaux for OS X. Not that I expect it
to make much money, Bordeaux for Linux has not brought in that much
yet, but if it does, I'm willing to try to help fund development.
5 Jul
5 Jul
4:21 a.m.
Hi,
Maybe this could be further queried as: "What is
CodeWeaver's offical
stance on supporting a Mac OS X native user interface when the code
becomes stable and supportable?" and "Would CodeWeavers consider
bringing Emmanuel on as a paid employee at that time to ensure that the
code is maintained?"
We are very interested in Wine having a more native OS X interface.
However, our analysis is that the task is difficult and will require a
long time to stabilize and get right. I am excited by and interested in
Emmanuel's work, but I am told not to be too excited, that it's not
a magic bullet, and that the bulk of the hard work is still ahead.
We have a long history of hiring proven Wine developers and thereby
sponsoring
their work. We do that as much as our income will allow, gated by peoples
ability and willingness to work with us.
To answer the seemingly implied question: "Are we deliberately crippling
Wine for Mac OS X
to serve our own nefarious ends", the answer is no. That's in no small
part because our main
nefarious end is to improve Wine :-).
Did we make a decision to focus on an X11 based solution for Mac OS X?
Yes,
for the time being. The advantages are that it's here now, works now,
and that most
of what we do now also benefits Linux and other platforms. The
disadvantage, apparently,
is that people suspect us of all kinds of nefarious plots...
And, on a final note, just so its clear: the contract between
CodeWeavers and Alexandre
is very explicit: CodeWeavers gets *no* say in what does or does not go
into Wine.
We probably curse his decisions as much or more than any Wine developer,
and whether
or not Objective C
Cheers,
Jeremy
1:53 p.m.
We probably curse his decisions as much or more than
any Wine developer,
and whether
or not Objective C
*blush* Teach me to send email late at night on a foreign computer.
The point is that CodeWeavers has no control over whether or not Emmanuel's code goes
into Wine. That's entirely Alexandre's decision.
Cheers,
Jeremy
7 Jul
7 Jul
9:41 a.m.
We are very interested in Wine having a more native OS
X interface.
However, our analysis is that the task is difficult and will require a
long time to stabilize and get right. I am excited by and
interested in
Emmanuel's work, but I am told not to be too excited, that it's not
a magic bullet, and that the bulk of the hard work is still ahead.
But it is fairy complete, since a long while. It lays in the front of
your eyes so why don't put it into the Wine's repository, as it is the
most obvious way for the others to polish and stabilize it.
We have a long history of hiring proven Wine
developers and thereby
sponsoring
their work. We do that as much as our income will allow, gated by
peoples
ability and willingness to work with us.
Look, I don't think you need to hire anybody. There're numerous
talented developers as Emmanuel or Mike that did great Wine packaging
at kronenberg.org that would help to put all the code together. I
shouldn't speak for them, but just note that both of them do all their
work already for free.
I'm willing to help too, I'd be happy if I could send some patches
improving Mac support.
To answer the seemingly implied question: "Are we
deliberately
crippling Wine for Mac OS X
to serve our own nefarious ends", the answer is no. That's in no
small part because our main
nefarious end is to improve Wine :-).
Very well, my previous mail was intentionally perversive just to cheer
up everybody for Mac discussion.
Did we make a decision to focus on an X11 based
solution for Mac OS
X? Yes,
for the time being. The advantages are that it's here now, works
now, and that most
of what we do now also benefits Linux and other platforms. The
disadvantage, apparently,
is that people suspect us of all kinds of nefarious plots...
Well it would be me then :) So why just not put Emmanuel's work into
Wine repository, while there're lot of other incomplete modules. Let's
give it a chance.
And, on a final note, just so its clear: the contract
between
CodeWeavers and Alexandre
is very explicit: CodeWeavers gets *no* say in what does or does
not go into Wine. We probably curse his decisions as much or more
than any Wine developer, and whether or not Objective C
(...)
The point is that CodeWeavers has no control over
whether or not
Emmanuel's code goes into Wine. That's entirely Alexandre's decision.
OK, I'm sorry. I don't want to accuse anybody, I just made a false
equation between Alexandre and CodeWeavers taken from About Us page.
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. So
IMHO no for Objective-C means no for decent Mac OSX support, period.
Best regards and thank you all for your replies,
--
Adam Strzelecki |: nanoant.com :|
9 Jul
9 Jul
6:27 a.m.
On Mon, Jul 7, 2008 at 5:41 AM, Adam Strzelecki <ono(a)java.pl> wrote:
OK, I'm sorry. I don't want to accuse anybody,
I just made a false
equation between Alexandre and CodeWeavers taken from About Us page.
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. So
IMHO no for Objective-C means no for decent Mac OSX support, period.
I don't know if having the quartzdrv in Winehq, even if was written in
pure C would be a good idea. I think there is a lot of pressure on him
to accept it (I've pestered him about it enough before) but he needs
to be free to break the driver interface from time to time to improve
it and its really forcing him to do work twice if quartzdrv and x11drv
are both in the winehq repo.
I think everybody would be better served if there was a "blessed"
branch or git repo that quartzdrv was maintained in, where it could be
done in Objective-C or however its maintainer wanted to do it, and
Winehq could recommend users wanting it to go there. If the maintainer
does not do a good job keeping it stable, fast and passing all of the
wine tests, Alexandre could always revoke his blessing. I created a
branch on repo.or.cz to do this but it needs more attention than I've
been able to give it lately. If we just accept that quartzdrv might
never be merged its not a big deal. Winehq users, CodeWeavers and
anyone else can still pull from it and or throw resources at it to
make it better, without adding more work on Julliard.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
10 Jul
10 Jul
12:34 p.m.
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?
--
Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/
It really galls me that most of the computer power in the world
is wasted on screen savers.
Chris Caldwell from the GIMPS project
http://www.mersenne.org/prime.htm
1:22 p.m.
Is it really technically impossible to access the
Quartz APIs or write
Mac applications using C?
Well it is possible, for example iTunes is non Objective-C Carbon
(API) app AFAIK. Problem is that Carbon (pure C interface) is
considered as deprecated by Apple and may disappear from future
releases of OSXes at all, most 98% of applications are Objective-C
Cocoa anyway. Moreover most of the functionality introduced in 10.5 or
10.4 went just into Cocoa, and never was backported to Carbon.
So it isn't matter that it isn't possible, but it is IMHO more
reasonable to do it in Objective-C.
Best regards,
--
Adam Strzelecki |: nanoant.com :|
2 Oct
2 Oct
6:16 p.m.
Sorry for the lag,
* On Thu, 10 Jul 2008, Adam Strzelecki wrote:
Then what about some thunking from carbonic source code to binary
Objective-C code?
Well, I have found some text [1] on the web about bridging D (not C) [2]
with ObjectiveC:
| So basically, since the whole Objective-C runtime is accessible from C
| calls, it’s pretty easy to do whatever we want with it.
If that's true, then some MacOSy hacker should give it a try. The bigger
task here probably would be implementation of some callback stuff in C
with the right calling convention / ABI (as ObjC seems to send some kind
of "messages" back).
Somewhat scary part may be bridging of exception handling, but if Wine did
this for WinAPI, with gobjc/libFoundation present and with Apple docs
given [3] it should be doable also.
I googled a bit more. There are at least two ways of achieving this
mentioned in the docs of libFoundation: by using XML-RPC call and by
wrapping classes in ANSI-C APIs. [4]
And the last -- I found libffi for Unix-like systems which seems to be
used on the MacOS X [5]:
| On Mac OS X libffi is commonly used with BridgeSupport, which provides
| programming language neutral descriptions of framework interfaces, and
| Nu which binds direct Objective-C access from Lisp.
HTH.
[1] http://michelf.com/weblog/2007/d-objc-bridge/
[2] http://en.wikipedia.org/wiki/D_(programming_language)
[3] http://www.google.lt/search?q=+objectivec+abi+site:developer.apple.com
[4] http://www.opengroupware.org/en/devs/languages/ansic/index.html
[5] http://en.wikipedia.org/wiki/Libffi
Is it really technically impossible to access the
Quartz APIs or write
Mac applications using C?
Well it is possible, for example iTunes is non Objective-C Carbon
(API) app AFAIK. Problem is that Carbon (pure C interface) is
considered as deprecated by Apple and may disappear from future
releases of OSXes at all, most 98% of applications are Objective-C
Cocoa anyway. Moreover most of the functionality introduced in 10.5 or
10.4 went just into Cocoa, and never was backported to Carbon.
So it isn't matter that it isn't possible, but it is IMHO more
reasonable to do it in Objective-C. 
3 Oct
3 Oct
8:52 a.m.
Am 02.10.2008 um 20:16 schrieb Saulius Krasuckas:
* On Thu, 10 Jul 2008, Adam Strzelecki wrote:
Then what about some thunking from carbonic source code to binary
Objective-C code?
While the above is correct, modern Cocoa, in opposite to it's
precedessor NeXTstep/OpenStep, is based on Quartz and CoreFoundation,
both of which are plain C APIs. There's no need for neither Carbon
nor Cocoa nor Objective-C to get some basic graphics to the Mac OS X
screen.
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
Is it
really technically impossible to access the Quartz APIs or
write Mac applications using C?
Well it is possible, for example iTunes is non Objective-C Carbon
(API) app AFAIK. Problem is that Carbon (pure C interface) is
considered as deprecated by Apple and may disappear from future
releases of OSXes at all, most 98% of applications are Objective-C
Cocoa anyway. Moreover most of the functionality introduced in
10.5 or
10.4 went just into Cocoa, and never was backported to Carbon.
So it isn't matter that it isn't possible, but it is IMHO more
reasonable to do it in Objective-C.
11:09 a.m.
I googled a bit more. There are at least two ways of
achieving this
mentioned in the docs of libFoundation: by using XML-RPC call and by
wrapping classes in ANSI-C APIs. [4]
Well actually you can easily access all Obj-C features trough the
following pure C API:
http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Ref…
While the above is correct, modern Cocoa, in opposite
to it's
precedessor NeXTstep/OpenStep, is based on Quartz and
CoreFoundation, both of which are plain C APIs. There's no need for
neither Carbon nor Cocoa nor Objective-C to get some basic graphics
to the Mac OS X screen.
You are right, however what we all want to have is probably some Wine
seamless integration with OSX GUI at higher level than Quartz which is
just equivalent of WinGDI, and for this you need to somehow use
HIToolkit of Carbon extra to do windows management, font handling etc.
for example:
http://developer.apple.com/documentation/Carbon/Reference/Window_Manager/Re…
/apple_ref/c/func/CreateNewWindow
.. to create new window.
The problem here is that HIToolkit from Carbon is a bit pushed away by
Apple in favor of Cocoa, and the reason is that Carbon has its roots
in Mac OS 8, and Cocoa is the new API for Mac OS X NextStep based
system, moreover there's no 64-bit HIToolkit (which doesn't matter for
Wine now, but may matter in the future).
There's nice discussion here:
http://www.lazarus.freepascal.org/index.php?name=PNphpBB2&file=printvie…
I believe if pure C source is a constraint for Wine, one should try to
make winequartz.drv to be Quartz API for all WinGDI like stuff + some
HIToolbox for Window management and CoreText for text display.
Regards,
--
Adam Strzelecki
7 Apr
7 Apr
2:42 a.m.
Adam Strzelecki wrote:
What is the status of work on this project?
James McKenzie
I googled a
bit more. There are at least two ways of achieving this
mentioned in the docs of libFoundation: by using XML-RPC call and by
wrapping classes in ANSI-C APIs. [4]
Well actually you can easily access all Obj-C features trough the
following pure C API:
http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Ref…
While the above is correct, modern Cocoa, in
opposite to it's
precedessor NeXTstep/OpenStep, is based on Quartz and
CoreFoundation, both of which are plain C APIs. There's no need for
neither Carbon nor Cocoa nor Objective-C to get some basic graphics
to the Mac OS X screen.
You are right, however what we all want to have is probably some Wine
seamless integration with OSX GUI at higher level than Quartz which is
just equivalent of WinGDI, and for this you need to somehow use
HIToolkit of Carbon extra to do windows management, font handling etc.
for example:
http://developer.apple.com/documentation/Carbon/Reference/Window_Manager/Re…
/apple_ref/c/func/CreateNewWindow
.. to create new window.
The problem here is that HIToolkit from Carbon is a bit pushed away by
Apple in favor of Cocoa, and the reason is that Carbon has its roots
in Mac OS 8, and Cocoa is the new API for Mac OS X NextStep based
system, moreover there's no 64-bit HIToolkit (which doesn't matter for
Wine now, but may matter in the future).
There's nice discussion here:
http://www.lazarus.freepascal.org/index.php?name=PNphpBB2&file=printvie…
I believe if pure C source is a constraint for Wine, one should try to
make winequartz.drv to be Quartz API for all WinGDI like stuff + some
HIToolbox for Window management and CoreText for text display.
Regards,
6 Jul
6 Jul
4:13 a.m.
Adam Strzelecki wrote:
Adam:
Is this still true? I would like to convert what work we do have into c
level code so that it will pass AJs 'c' scan and to avoid using ObjC code.
In addition, if an exported Carbon/Cocoa library exists, this would help
move the project along.
James McKenzie
I googled a
bit more. There are at least two ways of achieving this
mentioned in the docs of libFoundation: by using XML-RPC call and by
wrapping classes in ANSI-C APIs. [4]
Well actually you can easily access all Obj-C features trough the
following pure C API:
http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Ref…
1:18 p.m.
On 06.07.2009, at 06:13, James McKenzie wrote:
Adam Strzelecki wrote:
Adam:
Is this still true? I would like to convert what work we do have
into c
level code so that it will pass AJs 'c' scan and to avoid using ObjC
code.
In addition, if an exported Carbon/Cocoa library exists, this would
help
move the project along.
James McKenzie
Hi James,
I think You don't need any ObjC at all to replace X11. Apples modern
CoreGraphics API is mostly C. And OpenGL can be accessed in C anyway.
There is also a C API for the window manager. I do a lot of CG
programming, if you have a task for me, just drop a line ;)
There is a drawback with CG or OpenGL with Apples current APIs:
Manipulating individual pixels live in the screenbuffer. This was fast
& possible with the old (now depreciated & partly defunct) QuickDraw
API.
With Apple window server, based fully on Quartz, this API is of no use
now, as the underlaying system is already fully OpenGL. The once
direct access to the fb is now just as you would manipulate a texture
and flush it to the viewport in OpenGL. We did a lot of testing on
this topic when we changed the qemu vga output from QuickDraw to
OpenGL/Quartz on OS X. We finally changed the whole output to OpenGL,
as it was the fastest and most compatible with the future freely
scaleable UI ideas of Apple (and others ;).
This way, all 2d pixelmanipulation is taking place in a texture and if
it comes to 3d, half of the environment is already set.
Mike
I googled
a bit more. There are at least two ways of achieving this
mentioned in the docs of libFoundation: by using XML-RPC call and by
wrapping classes in ANSI-C APIs. [4]
Well actually you can easily access all Obj-C features trough the
following pure C API:
http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Ref…
8 Jul
8 Jul
11:22 a.m.
James,
Those functions allow pure C code call and work on Objective-C
(shortened to Obj-C later) object pointers. While it gives you
possibility to write an Obj-C Cocoa based pure-C extension for Wine,
IMHO this would be a nightmare. Because of few reasons: (1) You'd need
to write lot more code than writing Obj-C, (2) This code would be
suboptimal (Obj-C isn't translated to C, it is separate compiler), (3)
You can expect lot of problems with memory allocation and freeing that
is done more less automatically with Obj-C memory pools, etc.
Well actually
you can easily access all Obj-C features trough the
following pure C API:
http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Ref…
Is this still true? I would like to convert what work we do have
into c
level code so that it will pass AJs 'c' scan and to avoid using ObjC
code. In addition, if an exported Carbon/Cocoa library
exists, this would
help
move the project along.
As I previously mentioned Carbon is pure-C UI/graphics library for Mac
OS X that is legacy and partial compatible with older versions such as
Mac OS 8 & 9. Since it is legacy, all new features doesn't go into
Carbon so Carbon doesn't expose all OSX functionality, also there's no
64-bit Carbon.
So, Yes you can write Wine OSX support using pure-C Carbon library,
but beware that it is LEGACY and Apple doesn't recommend you to use
it. Moreover it can be discontinued at some 10.x release, so all your
work will be wasted.
Cocoa is the proper Obj-C API for OSX UI & graphics. OSX is NextStep
based objective oriented GUI & OS. And Obj-C is a basement of both
NextStep and OSX. So if you want to write OSX GUI application properly
you have to use Obj-C, same as C++ & KDE and so on.
So forcing constraint that all Wine source files have to be C is
simply unreasonable in this case. You can easily achieve that only OSX
dependent source files will be Obj-C, while having OS independent code
to be pure-C - as C is a subset of Obj-C, and Obj-C is backwards
compatible with C. So from the other OSes point of view Wine will be
still pure-C program.
Cheers,
--
Adam
9 Jul
9 Jul
8:46 a.m.
Adam Strzelecki [mailto:[email protected]]
Cocoa is the proper Obj-C API for OSX UI &
graphics. OSX is
NextStep based objective oriented GUI & OS. And Obj-C is a
basement of both NextStep and OSX. So if you want to write
OSX GUI application properly you have to use Obj-C, same as
C++ & KDE and so on.
With the same argument you could say that writing COM objects has
to be done in C++. Yet Wine has lots and lots of COM code written
all in standard C.
Agreed, writing object oriented code in C is not exactly trivial and
often quite tedious and the difference with Object-C might be even
bigger as it is likely using more advanced techniques.
Rolf Kalbermatter
11:18 a.m.
Rolf,
See my comments below.
With the same argument you could say that writing COM
objects has
to be done in C++. Yet Wine has lots and lots of COM code written
all in standard C.
You're wrong. COM isn't a full C++ interface, it uses/exposes limited C
++ subset - just to be C and other languages compatible. You never
create a COM class instance C++ way by name (like "= new
Direct3DTexture" or "Direct3DTexture tex;"), you never use ctors/
dtors, you always query/ask for GUID, your COM objects are always
pointers which has to be explicitly freed. You don't link to C++ libs
where are methods and class are C++ mangled using C++ lib naming.
And finally it is opposite situation, it is Wine that implements some
COM interfaces, so it is you that write the COM interface and create C
compatible API too.
I don't think there any place where Wine hooks to existing (external) C
++ library like QT. AFAIK wine uses C POSIX functions and Xwindow API
that is pure C too.
Moreover I didn't say that wrapping Cocoa can't be done in pure-C,
already said that there's a C API to call Obj-C methods etc. (look at
the link below)
All I say it will be a nightmare for a program that uses more than 2
classes and 10 method calls, and implementing video/GUI driver will
trigger much more of them for sure.
Image, you'd need to implement Wine video driver with QT/Kde which is
full C++ interface and all you get from them is C++ headers and C++
libraries.
You couldn't link just to QT lib, because pure C wouldn't understand C+
+ naming, you'd need to use a lot of *dlopen* & *dlsym*s, void
pointers, etc.
Agreed, writing object oriented code in C is not
exactly trivial and
often quite tedious and the difference with Object-C might be even
bigger as it is likely using more advanced techniques.
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%2…
.
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".
Regards,
--
Adam
9:31 p.m.
On Thu, Jul 9, 2009 at 7:18 AM, Adam Strzelecki<ono(a)java.pl> wrote:
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%2….
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".
The link seems to be malformed. Can you resend it? I am really
interested in looking at this.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
9:37 p.m.
The link seems to be malformed. Can you resend it? I am
really
interested in looking at this.
The trick, it seems, is to include the dot in the end. Interesting URL scheme(and
snippet)...
//Nicklas
10:48 p.m.
Steven Edwards wrote:
On Thu, Jul 9, 2009 at 7:18 AM, Adam
Strzelecki<ono(a)java.pl> wrote:
Link is fine, but mind the dot at the end of the link, it is a part of
the link, even your mail client says it isn't.
Sorry I spotted it too late once I sent this mail that Mail.app omits
trailing dot when underscoring the URL.
Regards,
--
Adam
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%2…
.
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".
The link seems to be malformed. Can you resend it? I am really
interested in looking at this.
11 Jul
11 Jul
2:28 a.m.
Adam Strzelecki wrote:
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%2….
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".
Ugly, but if this will work, it works. I don't like code obfusicusion
just to have it there. I like clean, commented, understandable code.
Unfortunately, we have to stick with c/C++ code here.
I'm wondering if there is a C++ to ObjC library interface that would be
cleaner.
James McKenzie
9:44 a.m.
I'm wondering if there is a C++ to ObjC library
interface that would
be
cleaner.
Never encountered any. I doubt it is possible since Obj-C is
dynamically typed (binded) language, which means you can pass any kind
of msg to any kind of obj and it will compile/run. Either you will
receive an "method not found" exception or "nil" as return. It is very
close to what Ruby is. Actually both Ruby & ObjC as based on Smalltalk
idea.
Of course there's wxWidgets for example which wraps Cocoa as one of
its backends, but the wrapper is C++ & ObjC mixture.
I really don't understand why Obj-C is treated as evil, even it would
be part only of Mac platform of Wine and even it is supported by GDB
and GCC on any possible platform :/
Once I thought when moving to Mac that its doggy idea to force some
Obj-C on Mac, while other part of the World speak C/C++, but now I
know that Obj-C is what defined OSX actually and way the whole system
works. So wondering who of Obj-C dislikers at Wine HQ really uses Mac
and really did any of native apps on Mac.
Regards,
--
Adam
9:21 p.m.
Adam Strzelecki wrote:
Never encountered any. I doubt it is possible since
Obj-C is
dynamically typed (binded) language, which means you can pass any kind
of msg to any kind of obj and it will compile/run. Either you will
receive an "method not found" exception or "nil" as return. It is
very
close to what Ruby is. Actually both Ruby & ObjC as based on Smalltalk
idea.
Now I understand. It is very interesting that Obj-C is based upon
something that I actually have an idea of how it works...
Of course there's wxWidgets for example which
wraps Cocoa as one of
its backends, but the wrapper is C++ & ObjC mixture.
I really don't understand why Obj-C is treated as evil, even it would
be part only of Mac platform of Wine and even it is supported by GDB
and GCC on any possible platform :/
Need to convince AJ of that. It would be nice
to be able to do Mac
builds on Linux and vice versa. I don't like the problems that are
encountered using mingw32 for the testsuite when building it on Linux.
Once I thought when moving to Mac that its doggy idea
to force some
Obj-C on Mac, while other part of the World speak C/C++, but now I
know that Obj-C is what defined OSX actually and way the whole system
works. So wondering who of Obj-C dislikers at Wine HQ really uses Mac
and really did any of native apps on Mac.
Don't know. I know that Austin English does use a Mac. I don't know if
he builds programs on it, however. I would like to see at least one
FOSS project use Obj-C code to support the Mac rather than using c wrappers.
James McKenzie
9:30 p.m.
On Sat, Jul 11, 2009 at 4:21 PM, James
McKenzie<jjmckenzie51(a)earthlink.net> wrote:
No, I don't have one. I have ssh access to one, but that's it. I'd
like to see more testing done on the Mac, but until I get one
personally, that won't happen for a while.
--
-Austin
Adam Strzelecki wrote:
What problems are you referencing?
I really don't understand why Obj-C is
treated as evil, even it would
be part only of Mac platform of Wine and even it is supported by GDB
and GCC on any possible platform :/
Need to convince AJ of that. It would be nice
to be able to do Mac
builds on Linux and vice versa. I don't like the problems that are
encountered using mingw32 for the testsuite when building it on Linux. Once I thought
when moving to Mac that its doggy idea to force some
Obj-C on Mac, while other part of the World speak C/C++, but now I
know that Obj-C is what defined OSX actually and way the whole system
works. So wondering who of Obj-C dislikers at Wine HQ really uses Mac
and really did any of native apps on Mac.
Don't know. I know that Austin English does use a Mac. I don't know if
he builds programs on it, however. I would like to see at least one
FOSS project use Obj-C code to support the Mac rather than using c wrappers.
9:45 p.m.
Austin English wrote:
No, I don't have one. I have ssh access to one, but that's it. I'd
like to see more testing done on the Mac, but until I get one
personally, that won't happen for a while.
There is nothing like owning one....(I have three, my partner two, just
for the record, I also own a Thinkpad A22p, that was the last PC I will
buy unless Apple disappears.)
As to testing, what needs to be done? I would like to see a native
version of Wine for the Mac, vice the requirement to use X11. That of
course, may be years away (I worked with both the NeoOffice.org and
OpenOffice.org projects with this. It was a multi-year adventure.)
James McKenzie
On Sat, Jul 11, 2009 at 4:21 PM, James
McKenzie<jjmckenzie51(a)earthlink.net> wrote:
The fact that the test suite was not working properly if built using
mingw32 vice building it with MS tools. If this has been overcome, good
work for the devs.
Adam Strzelecki wrote:
What problems are you referencing?
I really don't understand why Obj-C is
treated as evil, even it would
be part only of Mac platform of Wine and even it is supported by GDB
and GCC on any possible platform :/
Need to convince AJ of that. It would be nice to be able to do Mac
builds on Linux and vice versa. I don't like the problems that are
encountered using mingw32 for the testsuite when building it on Linux.
Once I
thought when moving to Mac that its doggy idea to force some
Obj-C on Mac, while other part of the World speak C/C++, but now I
know that Obj-C is what defined OSX actually and way the whole system
works. So wondering who of Obj-C dislikers at Wine HQ really uses Mac
and really did any of native apps on Mac.
Don't know. I know that Austin English does use a Mac. I don't
know if
he builds programs on it, however. I would like to see at least one
FOSS project use Obj-C code to support the Mac rather than using c wrappers.
10:01 p.m.
On Sat, Jul 11, 2009 at 4:45 PM, James
McKenzie<jjmckenzie51(a)earthlink.net> wrote:
Austin English wrote:
It *IS* built daily by mingw32/64. Building on windows (last I
checked), doesn't fully work yet, though the test suite it much closer
than full wine (obviously).
On Sat, Jul 11, 2009 at 4:21 PM, James
McKenzie<jjmckenzie51(a)earthlink.net> wrote:
The fact that the test suite was not working properly if built using
mingw32 vice building it with MS tools. If this has been overcome, good
work for the devs. Adam Strzelecki wrote:
What problems are you referencing?
I really don't understand why Obj-C is
treated as evil, even it would
be part only of Mac platform of Wine and even it is supported by GDB
and GCC on any possible platform :/
Need to convince AJ of that. It would be nice to be able to do Mac
builds on Linux and vice versa. I don't like the problems that are
encountered using mingw32 for the testsuite when building it on Linux.
>> Don't know. I know that Austin English
does use a Mac. I don't know if
>> he builds programs on it, however. I would like to see at least one
>> FOSS project use Obj-C code to support the Mac rather than using c wrappers.
>>
>
> No, I don't have one. I have ssh access to one, but that's it. I'd
> like to see more testing done on the Mac, but until I get one
> personally, that won't happen for a while.
As to testing, what needs to be done? I would like to
see a native
version of Wine for the Mac, vice the requirement to use X11. That of
course, may be years away (I worked with both the NeoOffice.org and
OpenOffice.org projects with this. It was a multi-year adventure.)
Daily building from git, reporting broken compiles/compiler warnings
and running the test suite daily would do a lot of good. I've asked
this multiple times on wine-users and mentioned it it pretty much
every OS X related thread on -devel, but no one (with a mac) has done
anything about it.
--
-Austin
9 Jul
9 Jul
12:54 p.m.
On Thu, Jul 9, 2009 at 4:46 AM, Rolf
Kalbermatter<r.kalbermatter(a)hccnet.nl> wrote:
With the same argument you could say that writing COM
objects has
to be done in C++. Yet Wine has lots and lots of COM code written
all in standard C.
Agreed, writing object oriented code in C is not exactly trivial and
often quite tedious and the difference with Object-C might be even
bigger as it is likely using more advanced techniques.
While we are on the subject, could anyone point me to a reference that
would show how I can create a mib file using C?
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
1:02 p.m.
Steven Edwards wrote:
While we are on the subject, could anyone point me to
a reference that
would show how I can create a mib file using C?
You meant Nib? It is binary format which is some Mac equivalent of
Windows RES format.
So this is not a source code.
Nib can be created from Xib source files (XML files) via "ibtool".
Cheers,
--
Adam
4:05 p.m.
On Thu, Jul 9, 2009 at 9:02 AM, Adam Strzelecki<ono(a)java.pl> wrote:
Steven Edwards wrote:
Thanks, thats what I need.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
While we are on the subject, could anyone point
me to a reference that
would show how I can create a mib file using C?
You meant Nib? It is binary format which is some Mac equivalent of Windows
RES format.
So this is not a source code.
Nib can be created from Xib source files (XML files) via "ibtool". 
3:32 p.m.
On Thursday 09 July 2009 1:46:59 am Rolf Kalbermatter wrote:
Adam Strzelecki [mailto:[email protected]]
It has to, because the class vtable layout and calling convention can be
different in Windows than how the host system's compiler will generate it. COM
objects have to interface with existing Windows code, and so need to be setup
in memory in a specific way.
By contrast, an OSX-specific driver can use Obj-C without consequence to
existing Windows code. As long as said driver can expose a C-only interface
for gdi32 or whatever, the Obj-C code is entirely self-contained and anything
outside the app is none-the-wiser.
If OSX will always have Obj-C support, and the Obj-C code can be restricted to
OSX-only code, then the only sticking point, in my eyes, would be how
maintainable it is. After all, if only one or two people can work with Obj-C
code, it can bit-rot that much more quickly.
Cocoa is the proper Obj-C API for OSX UI &
graphics. OSX is
NextStep based objective oriented GUI & OS. And Obj-C is a
basement of both NextStep and OSX. So if you want to write
OSX GUI application properly you have to use Obj-C, same as
C++ & KDE and so on.
With the same argument you could say that writing COM objects has
to be done in C++. Yet Wine has lots and lots of COM code written
all in standard C. 
5 Jul
5 Jul
8:46 a.m.
On Friday 04 July 2008 23:43:11 James McKenzie wrote:
Comments on Adam's message
Adam Strzelecki wrote:
Also, I'm not sure how many wine devs own macintels. I own a mac, but it's a
PPC, and I'm not going to spend more money on macs any time soon.
Cheers,
Kai
--
Kai Blin
WorldForge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/
--
Will code for cotton.
Hi Emmanuel, hello Wine developers,
Since Wine passed 1.0 (woohoo!) maybe someone from the direction can
revise Mac support? Even there're numerous Emmanuel efforts to provide
Mac UI driver instead of X11, it will be always pushed aside, and
sentenced to death, because it is not in official sources.
Mac OS X support is really not on the radar, from what I can determine.
Remember the original goal of Wine was to allow Windows programs to run
on a Windows API for Linux and UNIX. Mac OSX switched from a
proprietary system to FreeBSD/OpenBSD after the project started. Also
add that a parallel project was started to allow Windows32s programs to
run on OS/2.
5407
days inactive
5903
days old
55 comments
20 participants
participants (20)
-
Adam Strzelecki -
Austin English -
Chris Robinson -
Dmitry Timoshkov -
Emmanuel Maillard -
Francois Gouget -
James McKenzie -
James McKenzie -
Jeremy White -
Jeremy White -
Jim White -
Kai Blin -
Markus Hitter -
Mike Kronenberg -
Nicklas Börjesson -
Rob Shearman -
Rolf Kalbermatter -
Saulius Krasuckas -
Stefan Dösinger -
Steven Edwards