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".
18 matches
Mail list logo
