> On Mon, Feb 16, 2009 at 1:26 PM, Chris Robinson
> <
chris.kcat@gmail.com>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 discouraged, except in cases where
> > needed (eg. opengl32). Part of the problem is internal differences.. for
> > example, what would a Linux .so do if it's given a Win32 filename path?
> > Other
> > problems would be if the Linux equivalent wants a Window for a function
> > argument and the DLL wants an HWND instead, or if the DLL has
> > more/different
> > functions (eg. CUDA on Win32 has functions for dealing with D3D objects;
> > CUDA
> > on Linux doesn't, and it wouldn't be straight forward to even implement
> > them
> > through wined3d).
> >
> > Something like OpenGL, and even OpenAL to some degree, would directly
> > benefit
> > from having the DLLs forwarded to their host equivalents as it provides
> > better
> > access to the hardware and better integration with the host system.
> > Something
> > like zlib or ogg/vorbis and stuff wouldn't though, since the code should
> > largely be the same, and save for some bugs/inefficiencies in Wine
> (which
> > should be fixed), would work identically.
> >
> >
> >
> Does Wine yet have the capability to interface with HAL for Win32 hardware
> access similar to NT? It looks like it doesn't from all this talk of
> forwarding DLLs. What we should do instead of trying to forward DLLs,
> which
> is asking for more trouble than its worth, is try to get the NT layer to
> connect to UNIX HAL so that DLLs can link directly to HAL and operate the
> hardware.