Am Mittwoch 10 Januar 2007 16:53 schrieb Chetan Venkatesh:
Basically, what we are trying to do is run native Windows applications on a remote X desktop; we feel that the best way to do this would be to use wine as a base to develop a Windows to X translator/mapping, and then export the X calls over the network. It looks like wine should already implement much of the needed functionality in order to run Windows applications on Linux, so a windows port of the display code tied into an Xserver seems to make the most sense as a way forward.
This sounds interesting, but I am not sure how much you can gain with that compared to running wine on Linux. I think those are the DLLs of which you will have to run the Wine version and the Windows version won't work: gdi, user, winex11.drv, opengl32, ddraw, d3d8, d3d9, kernel. Shell32 and advapi are not really related to the X server, but the use of wine's kernel32.dll may require them. Of course you won't need opengl or d3dX if you don't plan to use 3d graphics.
On top of those libs you can use native windows libraries of course. But you can do that equally well on Linux, MacOS or Windows. The advantage of windows will be of course that the libraries are already available and you don't get license issues(well, IANAL). And of course it would be very tempting to port Wine completely to Windows. Higher level DLLs can be compiled for and used on windows already, but they are pretty pointless(appart from debugging). These are mostly the same dlls where the windows version can be used on wine. And we plan to port our Direct3D to Windows to get d3d10 on windows xp(once wine has d3d10)