- Wine-devel - list.winehq.org

Re: wineserver.pid
by Alexandre Julliard 10 Aug '01

10 Aug '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > Hi all, > > some guy was running several different versions of wineservers for one > account via wrapper scripts. > And of course he had a hell of a hard time figuring out which wineserver to > kill for which application ;-) Why would you want to do that? Just kill the app and it will die on its own (and save everything too). I don't think encouraging people to kill the wineserver is a good idea. -- Alexandre Julliard julliard(a)winehq.com

1 0

winelib application debugging
by Vitaly Kuznetsov 10 Aug '01

10 Aug '01

Is there currently any way to debug winelib application? I read winedbg doc, but there are only samples for windows executables. -- Vitaly AKA Vitty mailto: vitty(a)dts.ru NetMail:2:5015/133.41

2 1

Today's CVS hangs on startup
by Ian Pilcher 10 Aug '01

10 Aug '01

The good news is that --debugmsg +all actually stops producing anything. Hopefully someone can look at the output below and figure out what's going on. Anyone else seen this? ... 080689c0:trace:dosfs:DOSFS_FindUnixName (/home/pilcher/wine,Eudora\EUDORA.EXE) -> Eudora (EUDORA) 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:heap:HeapFree (403a0000,00000002,403c36c8): returning TRUE 080689c0:trace:dosfs:DOSFS_FindUnixName /home/pilcher/wine/Eudora,EUDORA.EXE 080689c0:trace:heap:HeapAlloc (403a0000,00000002,0000022c): returning 403c36c8 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:dosfs:DOSFS_FindUnixName (/home/pilcher/wine/Eudora,EUDORA.EXE) -> EUDORA.EXE (EUDORA.EXE) 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:heap:HeapFree (403a0000,00000002,403c36c8): returning TRUE 080689c0:trace:dosfs:DOSFS_GetFullName returning /home/pilcher/wine/Eudora/EUDORA.EXE = C:\EUDORA\EUDORA.EXE 080689c0:trace:string:lstrcpynA (0x405f68e8, "C:\\EUDORA\\EUDORA.EXE", 260) 080689c0:trace:string:lstrcpynA (0x405f68ea, "/Eudora/EUDORA.EXE", 258) 080689c0:trace:module:GetModuleFileName16 01cf -> 'C:\Eudora\EUDORA.EXE' 080689c0:trace:heap:HeapAlloc (403a0000,00000002,0000004c): returning 403c3480 080689c0:trace:reg:NtOpenKey (0x80000002,L"Software\\Wine\\Wine\\Config\\AppDefaults",f003f,0x405f6820) 080689c0: open_key( parent=-2147483646, access=000f003f, name=L"Software\\Wine\\Wine\\Config\\AppDefaults" ) Open key ERROR 080689c0: open_key() = OBJECT_NAME_NOT_FOUND { hkey=0 } 080689c0:trace:reg:NtOpenKey <- 0x0000 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"display",(nil),(nil),0x405f68f0,0x405f6818=268) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"display",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"display" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"Managed",(nil),(nil),0x405f68e8,0x405f6814=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"Managed",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"Managed" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"Desktop",(nil),(nil),0x405f68e8,0x405f6810=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"Desktop",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"Desktop" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"DXGrab",(nil),(nil),0x405f68e8,0x405f680c=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"DXGrab",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"DXGrab" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"UseDGA",(nil),(nil),0x405f68e8,0x405f6808=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"UseDGA",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"UseDGA" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"ScreenDepth",(nil),(nil),0x405f68e8,0x405f6804=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"ScreenDepth",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"ScreenDepth" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0:trace:reg:RegQueryValueExA (0x20,"Synchronous",(nil),(nil),0x405f68e8,0x405f6800=276) 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 080689c0:trace:reg:NtQueryValueKey (0x20,L"Synchronous",2,0x405f6688,256) 080689c0: get_key_value( hkey=32, offset=00000000, name=L"Synchronous" ) 080689c0: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, len=0, data={} } 080689c0:trace:heap:HeapFree (403a0000,00000002,403c3480): returning TRUE 080689c0: close_handle( handle=32 ) 080689c0: close_handle() = 0 { fd=-1 } 080689c0:trace:heap:HeapAlloc (403a0000,00000002,00000018): returning 403c3480 -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

[Fwd: Re: x11drv port to win32 possible ?]
by Ian Pilcher 09 Aug '01

09 Aug '01

Rudi De Vos wrote: > > The intention is to create a dll that exports the winapi graphic > functions for X11: X11DRV_CreateWindow,X11DRV_InitKeyboard,.. > see x11drv.spec. > Someone can correct me if I'm wrong, but I believe that Wine's built-in graphics drivers -- x11drv, ttydrv, and wineps -- interface with Wine's GDI code in a non-standard way. Alexandre has made some changes in this area recently, but I don't believe they've changed that fundamental fact. So to do what you're proposing, you would first have to modify Wine's GDI code to support one of Microsoft's 32-bit graphics driver interfaces. (Different Microsoft 32-bit OSes have different driver interfaces, BTW.) You could then update x11drv to use this interface. As Patrik pointed out, this is really outside the scope of the Wine project, but I do think that it would be valuable. In addition to the reasons you give above, it would be helpful in improving both the Wine driver code and the Wine GDI code. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

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

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

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