10 Jul
2009
10 Jul
'09
7:50 a.m.
On Thursday July 09, 2009 5:32 PM Chris Robinson wrote:
it.
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.
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 COM objects have to interface with existing Windows
code, and so need
to be setup in memory in a specific way.
Not entirely sure where your "It has too" is pointed at. If it is about COM
code being written in C then it is not entirly true. All the MS examples
about COM nowadays are completely in C++ and some newer API headers seem to
not even include the C part. But of course that code is meant to be compiled
with Visual C++ and I could see trouble trying to get the exact binary
layout with gcc. This is maybe not such a problem with newest gcc but was
certainly a problem with older versions.
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.
I think this is in fact the major issue here. There is certainly interest in
starting such a project but maintaining it is a completely different beast.
Rolf Kalbermatter
12 Jul
12 Jul
12:06 a.m.
Rolf Kalbermatter wrote:
On Thursday July 09, 2009 5:32 PM Chris Robinson
wrote:
This may be AJ's major concern. I don't know of many Obj-C programmers
on this project.
James McKenzie
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.
I think this is in fact the major issue here. There is certainly interest in
starting such a project but maintaining it is a completely different beast.
8:46 a.m.
On Sun, Jul 12, 2009 at 2:06 AM, James
McKenzie<jjmckenzie51(a)earthlink.net> wrote:
Rolf Kalbermatter wrote:
Just something else. I think that the amount of obj-c code could be
limited if we delegate as much of the work we can to OpenGL. That way
we directly have a modern GPU accelerated GDI renderer like on
Windows7. Yes perhaps older Intel Macs don't have great OpenGL drivers
but I wouldn't consider that an issue as they could still use X11. I
think that mostly we need OSX-code for window management and input
(keyboard/mouse).
Even in Winex11 we aren't that far away from switching to OpenGL.
Right now I'm adding more XRender acceleration but the same (and even
much more) can be done using OpenGL. In case of Winex11 we could use
GLX_EXT_texture_from_pixmap and render stuff for which OpenGL isn't
suited to a pixmap and then blit it using a texture.
Roderick
On Thursday July 09, 2009 5:32 PM Chris Robinson
wrote:
This may be AJ's major concern. I don't know of many Obj-C programmers
on this project.
James McKenzie
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.
I think this is in fact the major issue here. There is certainly interest in
starting such a project but maintaining it is a completely different beast.
5427
days inactive
5429
days old
2 comments
3 participants
participants (3)
-
James McKenzie -
Roderick Colenbrander -
Rolf Kalbermatter