Has anyone already try to compile it with VC++.
Using the win32X11 port from http://sources.redhat.com/win32-x11/ and microsoft visual C++ 6.0 I was able to compile some parts: tsx11 and wineclipsrv.exe.
The intention is to create a dll that exports the winapi graphic functions for X11: X11DRV_CreateWindow,X11DRV_InitKeyboard,.. see x11drv.spec.
1)If we can compile that dll, can we recompile a win32 app so it runs on a pc and display on a X-terminal? 2)Can multiple users run the same app on win95/98 and display on diff X-terminals?
I think what I think you are proposing is currently entirely out of the scope of the Wine project. Wine is currently not designed for this.
Compiling some of the non-core DLL:s like COMCTL32, COMDLG32 and others might be meaningful for test purposes, but the core stuff like the is simply not possible and it is not needed since Windows already has its own implementation of them that can used in the testing the non-core DLL:s.
In short, what you are proposing is intresting but it has currently little to do with the Wine project. What you want to do is the write a Windows "graphic card" driver that display the result on an X-Terminal.
While you certainly can (and are indeed legally allowed to do) use part of the x11drv to do this, I think most of the X11DRV is to high level to be useful.
Sure someday when your "graphic card" driver works good we might consider redesigning Wine to use the Windows "graphic card" driver interface, but it will certainly not not be done before Wine 1.0 or even Wine 1.x. Perhaps Wine 2.0 might be a good point to merge such things with Wine, assuming of course that you or somebody else implements such a thing and releases it under an acceptable license (preferably the Wine license, the new one that is).
Perhaps the subject needed to be X11drv insite function port to win32 possible ?
A graphic driver would display the full desktop and not a single application. And wine is not needed to display anything. This is currently used with the sunpci (intel coprocessor card in the sparc boxes). The video driver display the pc-screen as a xwindows or native on a second monitor.
I want to create equivalent functions, but it seems that the functions (X11DRV_...) make also use of the ntdll, userdll ... I just want to know if it would be possible to recompile the x11drv part against the native dlls ( on win32 ). Not the full x11drv, but only the functions mentioned in the x11drv.spec file. So I would be able to change the functions in win32 source code and recompile with the X11DRV_.. functions.
Thxs for the replay
Patrik Stridvall wrote:
Has anyone already try to compile it with VC++.
Using the win32X11 port from http://sources.redhat.com/win32-x11/ and microsoft visual C++ 6.0 I was able to compile some parts: tsx11 and wineclipsrv.exe.
The intention is to create a dll that exports the winapi graphic functions for X11: X11DRV_CreateWindow,X11DRV_InitKeyboard,.. see x11drv.spec.
1)If we can compile that dll, can we recompile a win32 app so it runs on a pc and display on a X-terminal? 2)Can multiple users run the same app on win95/98 and display on diff X-terminals?
I think what I think you are proposing is currently entirely out of the scope of the Wine project. Wine is currently not designed for this.
Compiling some of the non-core DLL:s like COMCTL32, COMDLG32 and others might be meaningful for test purposes, but the core stuff like the is simply not possible and it is not needed since Windows already has its own implementation of them that can used in the testing the non-core DLL:s.
In short, what you are proposing is intresting but it has currently little to do with the Wine project. What you want to do is the write a Windows "graphic card" driver that display the result on an X-Terminal.
While you certainly can (and are indeed legally allowed to do) use part of the x11drv to do this, I think most of the X11DRV is to high level to be useful.
Sure someday when your "graphic card" driver works good we might consider redesigning Wine to use the Windows "graphic card" driver interface, but it will certainly not not be done before Wine 1.0 or even Wine 1.x. Perhaps Wine 2.0 might be a good point to merge such things with Wine, assuming of course that you or somebody else implements such a thing and releases it under an acceptable license (preferably the Wine license, the new one that is).