January 2003 - Wine-Devel - list.winehq.org

Re: WIP RPC test code (RFC): rpc_K01-pre2.diff

by Alexandre Julliard

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > what about an environment variable ? > we already use something like this for the wineserver (WINESERVER), > the wine console (WINECONSOLE)... why not rpcss (WINERPCSS) ? I don't think we want a separate environment variable for every single Wine program. Simply setting the correct WINEDLLPATH should be enough (and runtest should be doing that already AFAICS). -- Alexandre Julliard julliard(a)winehq.com

Jan. 5, 2003

Re: console handling

by Dimitrie O. Paun

On January 5, 2003 02:45 pm, Eric Pouech wrote: > 6/ send me the output from both terms In the gdb terminal: [dimi(a)dimi bin]$ gdb GNU gdb Red Hat Linux (5.2.1-4) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux". (gdb) file /home/dimi/dev/wine/wine/miscemu "/opt/dimi/dev/wine/wine/miscemu": not in executable format: Is a directory (gdb) file /home/dimi/dev/wine/wine/miscemu/wine Reading symbols from /home/dimi/dev/wine/wine/miscemu/wine...done. (gdb) set debug remote 1 (gdb) target remote localhost:47175 Remote debugging using localhost:47175 Sending packet: $Hc-1#09...Sending packet: $Hc-1#09...Ack Packet received: OK Sending packet: $qC#b4...Ack Packet received: OK Sending packet: $qOffsets#4b...Ack Packet received: QC081ad0c8 Couldn't establish connection to remote target Malformed response to offset query, QC081ad0c8 (gdb) In the winedbg terminal: [dimi(a)dimi bin]$ winedbg -- --gdb --no-start visual-mingw.exe.so using wine_path: wine target remote localhost:47175 081ad010:081ad0c8: create process 'F:\dev\wine\visual-mingw.cvs\bin\visual-mingw.exe'/0x400eea00 @40562000 (0<0>) 081ad010:081ad0c8: create thread I @40562000 081ad010:081ad0c8: loads DLL C:\WINDOWS\SYSTEM\ntdll.dll @40050000 (0<0>) 081ad010:081ad0c8: loads DLL C:\WINDOWS\SYSTEM\kernel32.dll @40ac0000 (0<0>) 081ad010:081ad0c8: loads DLL C:\WINDOWS\SYSTEM\advapi32.dll @40a70000 (0<0>) 081ad010:081ad0c8: loads DLL C:\WINDOWS\SYSTEM\gdi32.dll @40a10000 (0<0>) 081ad010:081ad0c8: loads DLL C:\WINDOWS\SYSTEM\user32.dll @40900000 (0<0>) 081ad010:081ad0c8: loads DLL C:\WINDOWS\SYSTEM\comctl32.dll @40850000 (0<0>) 081ad010:081ad0c8: loads DLL C:\Windows\System\ole32.dll @65f00000 (0<19251>) 081ad010:081ad0c8: loads DLL C:\Windows\System\MSVCRT.DLL @78000000 (0<0>) 081ad010:081ad0c8: loads DLL C:\Windows\System\SHLWAPI.DLL @70bd0000 (0<7222>) 081ad010:081ad0c8: loads DLL C:\WINDOWS\SYSTEM\shell32.dll @40bd0000 (0<0>) 081ad010:081ad0c8: loads DLL C:\WINDOWS\SYSTEM\winspool.drv @40c30000 (0<0>) 081ad010:081ad0c8: loads DLL C:\WINDOWS\SYSTEM\comdlg32.dll @40b50000 (0<0>) 081ad010:081ad0c8: loads DLL C:\WINDOWS\SYSTEM\x11drv.dll @40ca0000 (0<0>) 081ad010:081ad0c8: exception code=80000003 Packet: Hc-1 Reply : OK Packet: Hc-1 Reply : OK Packet: qC Reply : QC081ad0c8 Packet: qOffsets Reply : Text=407c2e3c;Data=420749be;Bss=00000038 [dimi(a)dimi bin]$ -- Dimi.

Jan. 5, 2003

Re: [RFC] __WINESRC__ & public headers

by Dimitrie O. Paun

On January 5, 2003 06:38 pm, Alexandre Julliard wrote: > "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > -- Why do we need this undef? > > include/objidl.h:#ifdef __WINESRC__ > > include/objidl.h-#undef GetObject > > include/objidl.h-#endif > > Because GetObject is a WINELIB_NAME_AW #define, and these cause a > (deliberate) syntax error when building Wine. Which means this ifdef is OK, it will not cause problems with other headers. > > -- Why are these Wine specific? > > include/winbase.h:#ifdef __WINESRC__ > > include/winbase.h-#define GetCurrentProcess() ((HANDLE)0xffffffff) > > include/winbase.h-#define GetCurrentThread() ((HANDLE)0xfffffffe) > > include/winbase.h-#endif > > That's simply an optimization; maybe we could use an inline function > instead. Ditto, right? > > -- This one's a bugger. It make no sense to define these things > > conditionally on the -- version of the compiler. One's code is written > > one way or another. -- I suggest we remove these completely, and we > > defined the NONAMELESS* explicitly -- in the files that need them. > > The idea is that you can then use the NONAMELESS defines to write more > portable code, without having to duplicate the compiler checks. So the > user's code can do something like: > > #include <winnt.h> > #ifdef NONAMELESSUNION > #define U(x) u.x > #else > #define U(x) x > #endif Right. But it seems to me the NONAMELESS* names are a bit overloaded: on one hand, they are used to signal how some structures are defined, on the other they describe the capabilities of the compiler. For example, what if one decides to use names on _all_ gcc versions? This thing gets in the way, no? What about all the other things I've mentioned? Should we do anything about them? And if yes, what? -- Dimi.

Jan. 5, 2003

Re: [d3d7/patch #1] firstimpl for (Get|Set)ClipPlane for d3d7

by Lionel Ulmer

> case D3DRENDERSTATE_CLIPPING: /* 136 */ > - /* Nothing to do here... Even if what we receive is already clipped by the application, > - we cannot tell OpenGL to not re-clip it. */ > + case D3DRENDERSTATE_CLIPPLANEENABLE: /*152*/ > + { > + GLint i; > + DWORD mask, runner; > + > + if (dwRenderStateType==D3DRENDERSTATE_CLIPPING) { > + mask = ((dwRenderState)?(This->parent.state_block.render_state[D3DRENDERSTATE_CLIPPLANEENABLE-1]):(0x0000)); > + } else { > + mask = dwRenderState; > + } > + for (i = 0, runner = 1; This->parent.max_clipping_planes; i++, runner = (runner<<1)) { You forgot the 'i < ' before the 'This->parent.max_clipping_planes'. > + if (mask & runner) { > + glEnable(GL_CLIP_PLANE0 + i); > + } else { > + glDisable(GL_CLIP_PLANE0 + i); > + } > + } > + } > break; > (...) > -HRESULT WINAPI > -Main_IDirect3DDeviceImpl_7_GetClipPlane(LPDIRECT3DDEVICE7 iface, > - DWORD dwIndex, > - D3DVALUE* pPlaneEquation) > +HRESULT WINAPI > +Main_IDirect3DDeviceImpl_7_GetClipPlane(LPDIRECT3DDEVICE7 iface, DWORD Index, D3DVALUE* pPlaneEquation) And here, you renamed the dwIndex (the official MSDN sanctionned variable name) to Index :-) (...) > HRESULT WINAPI > -Main_IDirect3DDeviceImpl_7_SetClipPlane(LPDIRECT3DDEVICE7 iface, > - DWORD dwIndex, > - D3DVALUE* pPlaneEquation); > - Usually, we keep the Main declaration even if we never use it and replace it with a GL one. This is always to help an hypothetical new driver. (...) > +HRESULT WINAPI > +GL_IDirect3DDeviceImpl_7_SetClipPlane(LPDIRECT3DDEVICE7 iface, DWORD Index, CONST D3DVALUE* pPlaneEquation) Same comment for Index here too. Otherwise, looks good :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

Jan. 5, 2003

#include directives

by Francois Gouget

Our 'winspool.h' contains: #include "windef.h" #include "winbase.h" #include "wingdi.h" This means you can write a C file that just contains '#include <winspool.h>' and it will work. But that would fail on Windows because in the Windows sdk 'winspool.h' contains none of these #include directives. I don't really like headers that require you to #include other headers first. So I like our winspool.h better than the Windows one. But should we 'fix' it anyway? To avoid people writing tests that compile in Wine but not on Windows for instance? ;-) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.

Jan. 5, 2003

Wineboot

by Matthew Davison

Regarding the wineboot currently implemented in Wine, would it be feasable to use the registry code from the original wineboot (minus the config options), or is there some reason why this should not be included. -- Matthew Davison <m.davison(a)virgin.net>

Jan. 5, 2003

Re: looking for tester on NT

by Francois Gouget

Hi, On Sun, 5 Jan 2003, Stefan Leichter wrote: > Hello, > > before Christmas i did some check on an NT4 system at work that leads to the > attached tests. But currently i am not at work and have no windows system > available. > > Can someone please build and run the attached tests on a windows system > (NT4 prefered) and report the results. It works on NT4. However I get the following failures on Win95 so it still needs some work: info.c:35: Test failed: expected result == 0, got 1 info.c:36: Test failed: last error set to 87 instead of ERROR_INVALID_USER_BUFFER info.c:41: Test failed: expected result == 0, got 1 info.c:42: Test failed: last error set to 0 instead of RPC_X_NULL_REF_POINTER info.c:47: Test failed: expected result == 0, got 1 info.c:48: Test failed: last error set to 87 instead of RPC_X_NULL_REF_POINTER Also, to compile it on Windows you have to include wingdi.h before including winspool.h. I'm checking out why this isn't necessary in Wine. (and msvcmaker needs a trivial fix which I'll post shortly) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

Jan. 5, 2003

Re: enhancement request - can msvcmaker generate a Makefile?

by Francois Gouget

On Sun, 5 Jan 2003, Dimitrie O. Paun wrote: [...] > There is a request somewhere (and IIRC Patrik said he'll look into it > when he gets a chance) for instrumenting winemaker to convert .dsp > files into Makefiles, which is what you want, no? But when will this > happen -- I don't know :) The goal of winemaker would be to take a .dsp and generate a Winelib makefile, not an MSVC40 makefile. The two are completely different and incompatible. So thie would not help. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

Jan. 5, 2003

Re: Agent File Access

by Oliver Sampson

Aha. I couldn't find it in my email archive, because it was from back I accessed the users' list via USENET. Thank you, google! > http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&threadm=tps71ucv4b9tlpqvq… Oliver On Sun, 05 Jan 2003 17:05:36 +0000, Oliver Sampson <olsam(a)quickaudio.com> wrote: >Howdy, >I'd like to (finally) get around to fixing something that Agent does >that's really annoying. When launching programs, it sends a string >with backslashes for directory markers instead of forward slashes. > >Anyhow, if I'm going to start looking at the problem, could someone >point me at the right file to begin looking at? I think I asked this >some time ago, but I can't seem to find the email. (I remember >looking at the code, and since it was a *real* simple fix, it sorta >just fell by the way side.) > >Thanks, >==================================================== >Oliver Sampson >olsam(a)quickaudio.com >http://www.oliversampson.com > ==================================================== Oliver Sampson olsam(a)quickaudio.com http://www.oliversampson.com

Jan. 5, 2003

Re: CorelDraw 4 almost working

by Claudiu Costin

Hi Dimitri, Thank's for your patch. Applied, show it's stub, but CORELDRW.EXE crash on something strange. Is Wine missing something simple or require lot of work to fix? Attached: wine-coreldrw-crash.txt.gz I executed CORELPNT.EXE many times (even some months ago) and it crash on "stricmp" in NTDLL.DLL. I know this is a very important function. In ntdll.spec is declared as: @ cdecl _stricmp(str str) strcasecmp mapped on the libc. Attached: wine-corelpnt-crash.txt.gz Here is my output from console : clau(a)clauc:PROGRAMS$ wine CORELPNT.EXE err:module:PE_fixup_imports Module (file) tsd32.dll (which is needed by C:\Windows\System\TSSOFT32.ACM) not found err:win32:PE_LoadLibraryExA can't load C:\Windows\System\TSSOFT32.ACM err:win32:_EnterSysLevel (0x400dbac8, level 1): Holding 0x40866f24, level 3. Expect deadlock! err:win32:_EnterSysLevel (0x400dbac8, level 1): Holding 0x40866f24, level 3. Expect deadlock! err:win32:_EnterSysLevel (0x400dbac8, level 1): Holding 0x40866f24, level 3. Expect deadlock! err:win32:_EnterSysLevel (0x400dbac8, level 1): Holding 0x40866f24, level 3. Expect deadlock! err:win32:_EnterSysLevel (0x400dbac8, level 1): Holding 0x40866f24, level 3. Expect deadlock! err:win32:_EnterSysLevel (0x400dbac8, level 1): Holding 0x40866f24, level 3. Expect deadlock! err:win32:_EnterSysLevel (0x400dbac8, level 1): Holding 0x40866f24, level 3. Expect deadlock! err:win32:_EnterSysLevel (0x400dbac8, level 1): Holding 0x40866f24, level 3. Expect deadlock! err:win32:_EnterSysLevel (0x400dbac8, level 1): Holding 0x40866f24, level 3. Expect deadlock! wine: Unhandled exception, starting debugger... On Dum 05 Ian 2003 19:20, Dimitrie O. Paun wrote: > On January 5, 2003 12:32 pm, Marcus Meissner wrote: > > These are getting passed pointers to 32bit interfaces, but need 16bit > > ones. > > Darn! :) I knew I was missing something... What about this one: > kind regards, -- Claudiu Costin, claudiuc(a)kde.org Linux-KDE Romania http://www.ro.kde.org

Jan. 5, 2003