On Sun, Feb 7, 2010 at 22:47, David Gerard wrote:
> No idea, sorry. Xsun is on extended (life-)support with Sun moving to
> Xorg (and Alan Coopersmith from Sun being one of the main Xorg
> developers). Xming is Xorg compiled for mingw
Xming: An ancient version of Xorg (at least for the free versi
On 7 February 2010 20:23, Gert van den Berg wrote:
> On Sun, Feb 7, 2010 at 21:40, David Gerard wrote:
>> As I understand it, current Xorg does OpenGL in software on any video
>> chipset it supports ... eeerrryyy ssslllooowwwlllyyy, but it does
>> it.
> But what about other X servers, such
On Sun, Feb 7, 2010 at 21:40, David Gerard wrote:
> On 7 February 2010 15:40, Reece Dunn wrote:
>
>> 1/ Does this mean that OpenGL is required for all GDI calls, not
>> just D3D? If so, it will exclude people who don't have OpenGL support
>> (e.g. are using the vesa, nv, or nouveau drivers).
>
On 7 February 2010 15:40, Reece Dunn wrote:
> 1/ Does this mean that OpenGL is required for all GDI calls, not
> just D3D? If so, it will exclude people who don't have OpenGL support
> (e.g. are using the vesa, nv, or nouveau drivers).
As I understand it, current Xorg does OpenGL in software
Roderick Colenbrander wrote:
> On Sun, Feb 7, 2010 at 6:41 PM, James McKenzie
> wrote:
>
>> Correct. But why keep the old stuff around? It might be confusing to
>> the Wine beginner.
>>
>>
>
> The new style driver would only work on modern hardware like windows7 does.
>
>
That makes s
Roderick Colenbrander wrote:
>> Emmanuel's code is available from Sourceforge. It is a good starting
>> point for this. If you want, send me what you have so far for testing
>> purposes. It would be great to have a native MacOSX windowing system.
>>
>> James McKenzie
>>
>>
>
> The design of
On Sun, Feb 7, 2010 at 4:40 PM, Reece Dunn wrote:
> On 7 February 2010 15:02, Roderick Colenbrander
> wrote:
>>> Emmanuel's code is available from Sourceforge. It is a good starting
>>> point for this. If you want, send me what you have so far for testing
>>> purposes. It would be great to ha
On 7 February 2010 15:02, Roderick Colenbrander wrote:
>> Emmanuel's code is available from Sourceforge. It is a good starting
>> point for this. If you want, send me what you have so far for testing
>> purposes. It would be great to have a native MacOSX windowing system.
>>
>> James McKenzie
>
> Emmanuel's code is available from Sourceforge. It is a good starting
> point for this. If you want, send me what you have so far for testing
> purposes. It would be great to have a native MacOSX windowing system.
>
> James McKenzie
>
The design of the old quartz driver is not correct. I remem
Stefan Dösinger wrote:
>> The problem is that there can't be any Objective-C code in Wine. At all.
>> Or C++. Or Fortran. Or Pascal. Or Ada. Or Java. Or C# or VB. Or any
>> language other than pure, procedural C.
>>
> Alexandre has said that you can put objective C code into wine, but only if
Charles Davis wrote:
> C.W. Betts wrote:
>
>> Is is just because of the Objective-C code? Would it be safe to make C
>> functions that would call Objective-C? Such as:
>> cheader.h:
>> typedef struct struct1 struct1;
>> cfuncCreate(struct1 *s);
>> cfunc1();
>> cfunc2();
>> cfuncDestroy (struct
C.W. Betts wrote:
> Is is just because of the Objective-C code? Would it be safe to make C
> functions that would call Objective-C? Such as:
> cheader.h:
> typedef struct struct1 struct1;
> cfuncCreate(struct1 *s);
> cfunc1();
> cfunc2();
> cfuncDestroy (struct1 *s);
>
> cfile.m:
> @interface WHQ
> The problem is that there can't be any Objective-C code in Wine. At all.
> Or C++. Or Fortran. Or Pascal. Or Ada. Or Java. Or C# or VB. Or any
> language other than pure, procedural C.
Alexandre has said that you can put objective C code into wine, but only if
this code is properly abstracted fr
C.W. Betts wrote:
> Is is just because of the Objective-C code? Would it be safe to make C
> functions that would call Objective-C? Such as:
> cheader.h:
> typedef struct struct1 struct1;
> cfuncCreate(struct1 *s);
> cfunc1();
> cfunc2();
> cfuncDestroy (struct1 *s);
>
> cfile.m:
> @interface WH
Is is just because of the Objective-C code? Would it be safe to make C
functions that would call Objective-C? Such as:
cheader.h:
typedef struct struct1 struct1;
cfuncCreate(struct1 *s);
cfunc1();
cfunc2();
cfuncDestroy (struct1 *s);
cfile.m:
@interface WHQFunc
{
}
-(id)init;
-(void)dealloc;
@e
On 7 February 2010 01:45, James McKenzie wrote:
> C.W. Betts wrote:
>> An idea that popped into my head when I was thinking about a Quartz (OS X)
>> driver that perhaps there could be separate drivers for Quartz (OS X) and
>> X11. Such drivers would include OpenGL and DirectX "Drivers".
>>
>>
>
C.W. Betts wrote:
> An idea that popped into my head when I was thinking about a Quartz (OS X)
> driver that perhaps there could be separate drivers for Quartz (OS X) and
> X11. Such drivers would include OpenGL and DirectX "Drivers".
>
>
>
This has been shot down time and time again by Alexa
An idea that popped into my head when I was thinking about a Quartz (OS X)
driver that perhaps there could be separate drivers for Quartz (OS X) and X11.
Such drivers would include OpenGL and DirectX "Drivers".
An idea that popped into my head when I was thinking about a Quartz (OS X)
driver that perhaps there could be separate drivers for Quartz (OS X) and X11.
Such drivers would include OpenGL and DirectX "Drivers".
19 matches
Mail list logo
