I still don't see what the harm is in having support for .so's. I mean even
if it brings partial compatibility to the dlls vs so's isn't it worth it?
That is more than we have right now in Wine. What was the last version to
have the built in support? I'd like to see if I can't update it, and port i
>
> Gentoo users still have to set the +opengl use flag... That's where most of
> the complaints came from.
>
> The other aspect is that even software GL isn't available when you're using
> Xvnc or similar servers.
>
>
>
To be honest, I prefer the second argument over the first one :-)
> This might be a silly question, but isn't MESA here just for it :
> providing openGL functionality to sytems that don't have good hardware?
> And wasn't it planned somewhere to split together wined3d and winex11
> (not related to the question here, but just curious :) )
Gentoo users still have to
Stefan Dösinger a écrit :
> Am Mittwoch, 18. Februar 2009 23:47:47 schrieb Jérôme Gardou:
>
>> As of ddraw, wouldn't it be possible to write it on top of d3d9, as it
>> is already done with wined3d.
>>
> That will screw non-opengl ddraw rendering, which the VNC/remote X/old
> card/bad driv
Am Mittwoch, 18. Februar 2009 23:47:47 schrieb Jérôme Gardou:
> As of ddraw, wouldn't it be possible to write it on top of d3d9, as it
> is already done with wined3d.
That will screw non-opengl ddraw rendering, which the VNC/remote X/old
card/bad driver users will not really like. WineD3D currentl
Henri Verbeet a écrit :
> 2009/2/18 Jérôme Gardou :
>
>> Out of curiosity, would moving to this sort of architecture
>> http://msdn.microsoft.com/en-us/library/ms799715.aspx be possible? That
>> may give manufacturer the possibility to develop wine-direct3d drivers
>> and support what wine does
2009/2/18 Jérôme Gardou :
> Out of curiosity, would moving to this sort of architecture
> http://msdn.microsoft.com/en-us/library/ms799715.aspx be possible? That
> may give manufacturer the possibility to develop wine-direct3d drivers
> and support what wine does not support. This would require a m
Stefan Dösinger a écrit :
> Am Mittwoch, 18. Februar 2009 10:06:03 schrieb King InuYasha:
>
>> So it wouldn't be possible to hook Wine's Direct3D implementation into
>> Gallium3D on Linux and use the hardware directly instead of translating it
>> to OpenGL and then sending it to the hardware?
>>
Am Mittwoch, 18. Februar 2009 10:06:03 schrieb King InuYasha:
> So it wouldn't be possible to hook Wine's Direct3D implementation into
> Gallium3D on Linux and use the hardware directly instead of translating it
> to OpenGL and then sending it to the hardware?
Possible yes. I don't know if its gain
On Wed, Feb 18, 2009 at 2:11 AM, Roderick Colenbrander <
thunderbir...@gmx.net> wrote:
> > On Mon, Feb 16, 2009 at 1:26 PM, Chris Robinson
> > wrote:
> >
> > > On Monday 16 February 2009 9:38:19 am Seth Shelnutt wrote:
> > > > I had an interesting thought the other day, and that is to having
> som
> On Mon, Feb 16, 2009 at 1:26 PM, Chris Robinson
> wrote:
>
> > On Monday 16 February 2009 9:38:19 am Seth Shelnutt wrote:
> > > I had an interesting thought the other day, and that is to having some
> > > built in support for forwarding windows dlls to linux .so's.
> >
> > IIRC, this kind of thi
On Mon, Feb 16, 2009 at 1:26 PM, Chris Robinson wrote:
> On Monday 16 February 2009 9:38:19 am Seth Shelnutt wrote:
> > I had an interesting thought the other day, and that is to having some
> > built in support for forwarding windows dlls to linux .so's.
>
> IIRC, this kind of thing is generally
On Monday 16 February 2009 9:38:19 am Seth Shelnutt wrote:
> I had an interesting thought the other day, and that is to having some
> built in support for forwarding windows dlls to linux .so's.
IIRC, this kind of thing is generally discouraged, except in cases where
needed (eg. opengl32). Part o
"Roderick Colenbrander" writes:
> Years ago we had this functionality is Wine. Next to 'builtin',
> 'native' we had an option 'so'. It worked for glide2x/glide3x but for
> the rest not for much other libs. It was dropped during some debugging
> rewrite if I rememeber correctly. I don't remember i
Hi,
Wine once had a feature like this. In addition to load a DLL as builtin or
native, there was a third option called "so", which loaded a native linux lib
and looked for the symbols in there.
It was removed because it didn't really work. The main problem were +relay
logs I think. The other is
> I had an interesting thought the other day, and that is to having some
> built
> in support for forwarding windows dlls to linux .so's. A while back, I had
> worked on the CUDA wrapper, which basically just transfers the calls from
> the dll to so. At that point I didn't work on a CAL wrapper bec
I had an interesting thought the other day, and that is to having some built
in support for forwarding windows dlls to linux .so's. A while back, I had
worked on the CUDA wrapper, which basically just transfers the calls from
the dll to so. At that point I didn't work on a CAL wrapper because there
17 matches
Mail list logo
