wine-devel

wine-devel@winehq.org

10 participants
84486 discussions

RE: x11drv port to win32 possible ?
by Patrik Stridvall 09 Aug '01

09 Aug '01

[You know you replied in private? Hmm, it doesn't seem to be private. Including list again, others might be intrested] > Perhaps the subject needed to be > X11drv insite function port to win32 possible ? I'm not sure this new title makes it clearer. But never mind. > A graphic driver would display the full desktop and not a single > application. True. > 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'm not sure I quite with you, but never mind, see below. > 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. Possible, perhaps. However to me it just seems like a silly hack to use the X11DRV_ functions for that or at least to use them directly. Anyway, so what you really want to be able to compile Windows source code to a Windows binary that instead of using normal USER/GDI instead uses Wine's version of USER/GDI that using the X11DRV displays the application's Window(s) on a X-Terminal? Hmm. Intresting idea. Well, yes that would be possible to do with Wine, at least in theory. There is a lot a practical problems to be resolved for that to work. Just getting the non-core parts (especially USER/GDI and X11DRV) to compile and link to a DLL with the Windows headers will be an effort by itself. Actually getting it to work will be even worse, The USER (and to a lesser part even GDI) seems, eventhough I guess they can be made not to, to use the Wine server for some things, with means that you will either have to fix that or emulate the Wine server on Windows. It is propably not that hard to emulate it, but quite a lot of work regardless. Then you have the issue of getting the Windows versions of COMCTL32 and COMDLG32 DLL:s and similar DLL:s using your special versions of USER32 and GDI32 and not the Windows ones. I'm not sure Windows can be made to support this at all. It depends on exactly how library loading work. Hmm, perhaps it would be possible to "hook" LoadLibrary somehow. Anyway, I'm sorry to say that it will currently not, with the state Wine is now, be possible to do that without an enormous effort. Despite this I'm happy to say that I think it will be possible some day. However not until past Wine 1.0 or perhaps not even past Wine 1.x. Nice idea though.

1 0

RE: x11drv port to win32 possible ?
by Patrik Stridvall 09 Aug '01

09 Aug '01

> 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).

2 1

x11drv port to win32 possible ?
by Rudi De Vos 09 Aug '01

09 Aug '01

HI, 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? thxs Rudi

1 0

x11drv port to win32 possible ?
by Rudi De Vos 09 Aug '01

09 Aug '01

1 0

Re: Rewrite AFM parsing code
by Dmitry Timoshkov 09 Aug '01

09 Aug '01

"Ian Pilcher" <ian.pilcher(a)home.com> wrote: > Log message: > Ian Pilcher <ian.pilcher(a)home.com> > WINEPS: rewrite and separate AFM parsing code (no more [afmfiles]) [...] > +inline static BOOL IsWinANSI(LONG uv) > +{ > + if ((0x0020 <= uv && uv <= 0x007e) || (0x00a0 <= uv && uv <= 0x00ff) || > + (0x2018 <= uv && uv <= 0x201a) || (0x201c <= uv && uv <= 0x201e) || > + (0x2020 <= uv && uv <= 2022)) ^^^^ Shouldn't it be 0x2022? -- Dmitry.

2 1

Re: Remove redundant implementations
by Alexandre Julliard 09 Aug '01

09 Aug '01

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Remove redundant implementation of __get_cs,__get_ds,__get_es, > __get_fs,__get_gs,__get_ss,__set_fs,__set_gs. These are here to support compilers that don't have gcc-style inline assembly. This is admittedly a theoretical issue at this point, but there shouldn't be any harm in keeping them around just in case. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Remove redundant implementations
by Alexandre Julliard 09 Aug '01

09 Aug '01

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > Perhaps they should be protected from compiling under gcc? Why would you want that? They could conceivably be useful even with gcc in case it decides not to use the inline version. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: CS_PARENTDC with WS_CLIPSIBLINGS
by Alexandre Julliard 08 Aug '01

08 Aug '01

Ladislav Sladecek <lsla(a)post.cz> writes: > The function is called like this: > > 0806c1c8:Call GDI.38: ESCAPE(0x0000,0x000d,0x0000,0x00000000,0657:e8f4) ret=0ff7:4428 ds=1207 > > The in_data pointer is null but the code assigns to it, thats why it > crashes. I think that the result should be assigned to the output parameter. Yes of course, stupid typo on my part. Thanks for spotting it. -- Alexandre Julliard julliard(a)winehq.com

1 0

Some strange code in configure.in
by Lionel Ulmer 08 Aug '01

08 Aug '01

Hi all, By looking at some guy's config.log, I found out this in configure.in : dnl Check for GLU32 library. AC_CHECK_LIB(GLU,glBegin, X_PRE_LIBS="$X_PRE_LIBS -lGLU" GLU32FILES='$(GLU32FILES)' GLU32_DLL=glu32 ,, $X_LIBS $X_PRE_LIBS -lXext -lX11 -lm $X_EXTRA_LIBS ) My question is why do we test for 'glBegin' in GLU and not something better like, say, 'gluLookAt' ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Re: CS_PARENTDC with WS_CLIPSIBLINGS
by Alexandre Julliard 08 Aug '01

08 Aug '01

Ladislav Sladecek <lsla(a)post.cz> writes: > 2) The real reason for the crash is that the application calls Escape16 with > hdc equal to 0 and function equal to GETPRINTINGOFFSET. I do not understand > why, they did not even start to print. Maybe, this is an undocumented windows > function? After I temporarily disabled Escape16, the application began to > work. It's not supposed to crash even if the hdc is invalid. Do you have a backtrace of the crash? > 4) To fix Escape16, the 16bit printer driver is necessary. I need printing > either. I will try to work on it if you just give me a piece of advice. I think > that two ways are possible: > > A) To use the static table and to modify create_driver to work with it. > > B] To create a 16bit printer driver DLL similarly to the 32bit drivers. The static table is OK, but you'll need to add a number of functions that were done by escapes before (AbortDoc, StartDoc, etc.) And of course there is still the GDI lock issue so I don't know if you can actually print something even if you fix the initialisation. -- Alexandre Julliard julliard(a)winehq.com

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel