August 2005 - Wine-Devel - list.winehq.org

Re: Googletalk and Wine

by James Hawkins

On 8/26/05, Andrew Neil Ramage <nrsc16850(a)blueyonder.co.uk> wrote: > Googletalk is a free chat program from Google with integrated VoIP. I > installed the program and received a message saying Googletalk required > Windows 2000, XP or 2003. The program started after installation and > almost immewdiately crashed. Here is the output. > This has been fixed in CVS. -- James Hawkins

Aug. 26, 2005

Re: The recent include/wine/wined3d_types.h changes

by Oliver Stieber

--- Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > The following patch to include/wine/wined3d_types.h > > triggers the following warning in IDirect3D8Impl_CreateDevice(): > > directx.c:670: warning: assignment from incompatible pointer type > directx.c:678: warning: assignment from incompatible pointer type > Ok, I'll send in a patch to fix this. > > Both D3DFORMAT and WINED3DFORMAT are enums, so indeed assigning one > to the other seems a bit strange, if not dangerous. Is the change > as such really correct? The problem is that Microsoft changes what D3DFORMAT are valid between Direct3D releases, DirectX 9 is missing some formats that are in DirectX 8 and DirectX 8 is missing some formats that are in DirectX 9. To work around this a new enum WINED3DFORMAT was created that includes all the types valid for DirectX 8 as well as those valid for DirectX 9. Because DirectX 8/9's D3DFORMATs are a subset of WINED3DFORMAT DirectX 8/9's D3DFORMAT can be cast to WINED3DFORMAT without any problems. Texture states are similar to this, except that when DirectX 8 is moved over to using wined3d a switch will be required to send those states that are sampler states in DirectX 9 to wined3d SetSamplerState instead of SetTextureStageState. > > Gerald > > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Aug. 26, 2005

Re: accessing WRT binaries on the web

by Paul Millar

Hi Saulius, On Thursday 25 Aug 2005 09:22, Saulius Krasuckas wrote: > * On Wed, 24 Aug 2005, Paul Millar wrote: > > The cross-building part needs patching so it knows about an additional > > part of the Win32 API. Nothing new there. > > Ok, but I perhaps do not understand, what the exact code is or looks like. We're using MinGW for cross-compilation. This has a few separate parts: binutils, gcc, w32api, run-time, ... The w32api is part of the MinGW distribution, describing the Windows API. The linker uses w32api to build the executable that will link correctly at run-time against Windows DLLs. > Is it available on the net? Yes, its available. The vanilla release are available from here: http://sourceforge.net/project/showfiles.php?group_id=2435 The w32api releases lag somewhat from what wine actually implements (and so, what gets tested). Because of this, to allow cross-compilation of winetest additional API calls need to be patched into w32api. Precompiled versions of this improved MinGW are maintained by Hans Leidekker and are available from: http://mirzam.it.vu.nl/mingw/ For somewhat obscure reasons, I've ended up using an independent script to generate the cross-compiler but it amounts to the same thing, especially as Hans, Stefan Leichter and myself share patches. > And are you working alone? No, not at all! All the patches against w32api have come from Hans or Stefan. > > [...] Once this is done, things should be up and running again. > > Thanks, Paul, for the clarification. No problem! OK, so it looks like crypt32_test.exe wasn't building due to missing CryptHashCertificate(a)28 definiton (should now be fixed), msi_test.exe due to missing MsiViewGetErrorA(a)12 (now fixed) and shell32_test.exe due to missing CLSID_FolderShortcut (again, fixed). But, dsound_test.exe is failing with: i686-mingw32msvc-gcc capture.o ds3d.o ds3d8.o dsound.o dsound8.o propset.o testlist.o -o dsound_test.exe -ldsound -lole32 -lversion -luser32 -lkernel32 -ldxguid -luuid -ldxerr8 /usr/local/mingw/lib/gcc-lib/i686-mingw32msvc/3.3.3/../../../../i686-mingw32msvc/lib/libdxguid.a(dxguid.o):/tmp/../../../w32api-3.3/lib/directx/dxguid.c (.rdata+0x570): multiple definition of `CLSID_DirectSoundPrivate' propset.o:/home/paul/Production/wine-cross-source/dlls/dsound/tests/propset.c:66: first defined here /usr/local/mingw/lib/gcc-lib/i686-mingw32msvc/3.3.3/../../../../i686-mingw32msvc/lib/libdxguid.a(dxguid.o):/tmp/../../../w32api-3.3/lib/directx/dxguid.c (.rdata+0x580): multiple definition of `DSPROPSETID_DirectSoundDevice' propset.o:/home/paul/Production/wine-cross-source/dlls/dsound/tests/propset.c:67: first defined here Is this some kind of conflict between the MinGW definitions and wine's own version? Cheers, Paul

Aug. 26, 2005

The recent include/wine/wined3d_types.h changes

by Gerald Pfeifer

The following patch to include/wine/wined3d_types.h revision 1.8 date: 2005/08/23 09:34:57; author: julliard; state: Exp; lines: +2 -2 Oliver Stieber <oliver_stieber(a)yahoo.co.uk> Tidy up d3d9 and finalize passing d3d9 calls to wined3d for now. @@ -401,7 +401,7 @@ typedef struct _WINED3DADAPTER_IDENTIFIE typedef struct _WINED3DPRESENT_PARAMETERS { UINT *BackBufferWidth; UINT *BackBufferHeight; - D3DFORMAT *BackBufferFormat; + WINED3DFORMAT *BackBufferFormat; UINT *BackBufferCount; D3DMULTISAMPLE_TYPE *MultiSampleType; DWORD *MultiSampleQuality; @@ -409,7 +409,7 @@ typedef struct _WINED3DPRESENT_PARAMETER HWND *hDeviceWindow; BOOL *Windowed; BOOL *EnableAutoDepthStencil; - D3DFORMAT *AutoDepthStencilFormat; + WINED3DFORMAT *AutoDepthStencilFormat; DWORD *Flags; UINT *FullScreen_RefreshRateInHz; UINT *PresentationInterval; triggers the following warning in IDirect3D8Impl_CreateDevice(): directx.c:670: warning: assignment from incompatible pointer type directx.c:678: warning: assignment from incompatible pointer type These two lines are localParameters.BackBufferFormat = &pPresentationParameters->BackBufferFormat; localParameters.AutoDepthStencilFormat = &pPresentationParameters->AutoDepthStencilFormat; and the two variables have the following types D3DPRESENT_PARAMETERS* pPresentationParameters (from include/wine/wined3d_types.h WINED3DPRESENT_PARAMETERS localParameters; (from include/d3d8types.h) Interestingly, I did not see this on SUSE Linux 9.3, but FreeBSD 4.11 (XFree86) and 5.4 (X.org). Both D3DFORMAT and WINED3DFORMAT are enums, so indeed assigning one to the other seems a bit strange, if not dangerous. Is the change as such really correct? Gerald

Aug. 26, 2005

Re: OpenGL windowing and wglMakeCurrent

by Vitaly Lipatov

В сообщении от 26 Август 2005 15:32 Lionel Ulmer написал(a): > On Wed, Aug 24, 2005 at 02:40:48PM -0700, Russ wrote: > > Under WINE, the subwindow graphics all get drawn in the > > lower left corner of the overall X11 window, and the entire X11 window's ... > So we have two possible solutions: > > = write our own GLX extension that exports to the user the clip-list ... > = use pbuffers for all GL renderings and use Wine's standard GDI functions ... > > Lionel Thank you for detailed description f the problem. I copied it into wiki, please check it at http://wiki.winehq.org/OpenGL -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Aug. 26, 2005

Re: Crash on glBegin() (Was: Help with debugging needed)

by Stefan Dösinger

Hi, > On Tue, Aug 23, 2005 at 12:35:16PM +0000, Stefan Dösinger wrote: > > I'll try to reproduce the behaviour and write a small test for this > > problem and the reference counting issue. However, this may take some > > time... > > Could you do a +ddraw,+tid trace and check that all DirectX calls are done > from the same thread ? If not, Wine is doing bad stuff that may lead to > crashes in the GL drivers depending on the way they handle TLS and then > your problem is a 'classical' one (for which the solution is still in the > 'need to be done one day' phase :-) ). As far as I can tell from a quick look, no. All ddraw calls are done from the same thread, there are only a few imm32 calls from another thread. Empire Earth uses at least 2 threads, one for the sound, and another one for the rest. Perhaps there's also a third one for the DirectMusic stuff, which I have disabled in the game's config. I have noticed that it creates multiple DirectDraw and Direct3D devices, some of them are freed, re-created and freed again. At the time of the crash due to reference counting, there are at least 2 DirectDraw and 2 Direct3D objects. Is this going to work? I'll try to solve the reference counting problem first, because my first "patch" only solved the symptom, but not the cause, and I'm not sure if there are no connections between the 2 crashes. Do you still want to see a +ddraw,+tid trace? I can upload one to my homepage. Stefan

Aug. 26, 2005

Re: Loading resources from wine dlls

by Alexandre Julliard

Michael Jung <mjung(a)iss.tu-darmstadt.de> writes: > Thinking about it again, there probably is no such thing as an ELF wrapped PE? No, the ELF linker cannot support everything we need, so parts of the PE header need to be generated at load time. So there's no way to access a real PE header without loading the dll. -- Alexandre Julliard julliard(a)winehq.org

Aug. 26, 2005

Re: wine/dlls/commdlg printdlg.c

by Alexandre Julliard

Vitaly Lipatov <lav(a)etersoft.ru> writes: > Dear Alexandre! > You are removed dm checking for NULL... But it can be NULL in some cases... I didn't touch that bit, I'm afraid it was that way in your patch... -- Alexandre Julliard julliard(a)winehq.org

Aug. 26, 2005

Re: DLL loading

by Alexandre Julliard

Bojan "ÿffff8aernek" <sinergitized(a)yahoo.com> writes: > I'd like to load a DLL from a memory buffer. The > regular Win32 API function to load DLLs, however, > takes a path name. So, I'm looking for resources about > this kind of thing, but it has to work both under > win32 and unix+wine. There used to be a web page about > just this thing, but I lost the link. > > Any ideas? The easiest is to dump the memory buffer to a temp file and load that... -- Alexandre Julliard julliard(a)winehq.org

Aug. 26, 2005

Re: wine/dlls/commdlg printdlg.c

by Vitaly Lipatov

В сообщении от 25 Август 2005 23:23 Alexandre Julliard написал(a): > Log message: > Vitaly Lipatov <lav(a)etersoft.ru> > Restore paper orientation when pagesetupdlg is initializing. > > Patch: http://cvs.winehq.org/patch.py?id=19818 Dear Alexandre! You are removed dm checking for NULL... But it can be NULL in some cases... <<<<<<< printdlg.c /* Set orientation radiobutton properly */ dm = GlobalLock(pda->dlga->hDevMode); if (dm && dm->u1.s1.dmOrientation == DMORIENT_LANDSCAPE) ======= /* Set orientation radiobutton properly */ dm = GlobalLock(pda->dlga->hDevMode); if (dm->u1.s1.dmOrientation == DMORIENT_LANDSCAPE) >>>>>>> 1.93 -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Aug. 26, 2005