<div class="gmail_quote">On Wed, Feb 18, 2009 at 2:11 AM, Roderick Colenbrander <span dir="ltr"><<a href="mailto:thunderbird2k@gmx.net">thunderbird2k@gmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="Wj3C7c">> On Mon, Feb 16, 2009 at 1:26 PM, Chris Robinson<br>
> <<a href="mailto:chris.kcat@gmail.com">chris.kcat@gmail.com</a>>wrote:<br>
><br>
> > On Monday 16 February 2009 9:38:19 am Seth Shelnutt wrote:<br>
> > > I had an interesting thought the other day, and that is to having some<br>
> > > built in support for forwarding windows dlls to linux .so's.<br>
> ><br>
> > IIRC, this kind of thing is generally discouraged, except in cases where<br>
> > needed (eg. opengl32). Part of the problem is internal differences.. for<br>
> > example, what would a Linux .so do if it's given a Win32 filename path?<br>
> > Other<br>
> > problems would be if the Linux equivalent wants a Window for a function<br>
> > argument and the DLL wants an HWND instead, or if the DLL has<br>
> > more/different<br>
> > functions (eg. CUDA on Win32 has functions for dealing with D3D objects;<br>
> > CUDA<br>
> > on Linux doesn't, and it wouldn't be straight forward to even implement<br>
> > them<br>
> > through wined3d).<br>
> ><br>
> > Something like OpenGL, and even OpenAL to some degree, would directly<br>
> > benefit<br>
> > from having the DLLs forwarded to their host equivalents as it provides<br>
> > better<br>
> > access to the hardware and better integration with the host system.<br>
> > Something<br>
> > like zlib or ogg/vorbis and stuff wouldn't though, since the code should<br>
> > largely be the same, and save for some bugs/inefficiencies in Wine<br>
> (which<br>
> > should be fixed), would work identically.<br>
> ><br>
> ><br>
> ><br>
> Does Wine yet have the capability to interface with HAL for Win32 hardware<br>
> access similar to NT? It looks like it doesn't from all this talk of<br>
> forwarding DLLs. What we should do instead of trying to forward DLLs,<br>
> which<br>
> is asking for more trouble than its worth, is try to get the NT layer to<br>
> connect to UNIX HAL so that DLLs can link directly to HAL and operate the<br>
> hardware.<br>
<br>
</div></div>This can't be done. You would be writing your own operating system and hardware can't be shared. It is not that hard to write wrapper libraries. Second even if libraries look similar between OSes take for instance Cuda it does offer OS-specific functionality like e.g. Direct3D integration.<br>
<br>
Roderick<br>
<font color="#888888">--<br>
Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL<br>
f�r nur 17,95 Euro/mtl.!* <a href="http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a" target="_blank">http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a</a><br>
</font></blockquote></div><br><div>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?</div>