wine-devel December 2002

wine-devel@winehq.org

132 participants
377 discussions

Direct3D8 regression/bug
by Roderick Colenbrander 03 Dec '02

03 Dec '02

Hi, Just to see how well Wine's Direct3D8 support is working, I played with some some simple d3d8 demos. (that are the tutorial examples Jason Edmeades used when he started Wine's Direct3D8 implementation) A few weeks ago all those demo's worked. Perhaps some things where not rendered correctly but they worked. A few days ago I rechecked those demo's but now all d3d8 apps I try crash. Immedeately winedbg is launched. The app seems to crash in libGL.so.1. Here's the error with a backtrace: Unhandled exception: page fault on read access to 0x00000008 in 32-bit code (0x40bf4a06). In 32-bit mode. 0x40bf4a06 (_end+0xf6a9a in libGL.so.1): movl 0x8(%eax),%eax Wine-dbg>bt Backtrace: =>0 0x40bf4a06 (_end+0xf6a9a in libGL.so.1) (ebp=00000001) Lionel suggested that his OpenGL patches may have caused this problem. He had the same crashes on his pc. I reversed his patches but it still had problems. (perhaps I made some misstakes somewhere ..) Perhaps the problem is related to the OpenGL drivers. I'm using Nvidia's OpenGL drivers (1.0-3123). I hope this helps a bit, Roderick Colenbrander

2 2

WIN_FindWndPtr
by Dustin Navea 03 Dec '02

03 Dec '02

Hey just out of curiosity, now that we are working toward v1.0 (not like we werent before) shouldnt this error be changed over to a fixme? It doesnt seem like all that much needs to be done (aside from marshalling and whatnot). Just wondering if we were planning on fixing it before v1.0, as it would be a big boon to have it still there in v1.0... -Dustin

1 0

bug (regression) in ddraw/d3d
by J. Hoffmann 03 Dec '02

03 Dec '02

Hi, I wanted to play around with the improvements to ddraw/d3d, and tried to run Final Fantasy 8 which worked before in software rendering mode with the native direct music dlls. Unfortunately FF8Config (and FF8 itself) crashes now with the recent changes. The patch which introduces the regression is: http://www.winehq.com/hypermail/wine-cvs/2002/11/0231.html (cvs version just before the patch works, applying the patch results in a pagefault.) The problem appears to be that GL_IDirect3DImpl_3_CreateDevice gets called with an rclsid = IID_D3DDEVICE2_OpenGL instead of IID_D3DDEVICE3_OpenGL, so that an D3DDevice2 gets created for the Direct3D3 interface (which results in a pagefault later, when the device is used.) See traces below. Im still trying to find the bug (and then a fix :-), but it would help me a lot, if someone could tell me where the GL_IDirect3DImpl_3_CreateDevice gets called from. (I see that it is an entry in the vtable but haven't found the function there it gets gets called yet..) regards, Jens Hoffmann ** trace for the old version: (cvs 11/24/02 16:14:09 CST) ** ... trace:ddraw:Main_DirectDraw_QueryInterface (0x403a4568)->({bb223240-e72b-11d0-a9b4-00aa00c0993e},0x40852 3cc) trace:ddraw:direct3d_create creating implementation at 0x403a5380. trace:ddraw:Main_DirectDraw_QueryInterface returning Direct3D3 interface at 0x403a5384. trace:ddraw:Main_DirectDraw_AddRef (0x403a4568)->() incrementing from 2. trace:ddraw:GL_IDirect3DImpl_3_CreateDevice (0x403a5380/0x403a5384)->({31416d44-86ae-11d2-822d-a8d53187cafc},0x403a4e28,0x408523d0) trace:ddraw:d3ddevice_create creating OpenGL device for surface = 0x403a4e28, d3d = 0x403a5380 trace:ddraw:d3ddevice_create visual found trace:ddraw:d3ddevice_create context created (0x80a0260) trace:ddraw:d3ddevice_create setting current context err:ddraw:set_context This function should not be called in the current state of the code... trace:ddraw:d3ddevice_create current context set trace:ddraw:d3ddevice_create creating implementation at 0x403a5770. trace:ddraw:create_device_helper returning OpenGL D3DDevice3 (nil) trace:ddraw:Thunk_IDirect3DDeviceImpl_3_EnumTextureFormats (0x403a5774)->(0x405393,0x42e014) thunking to IDirect3DDevice7 interface. ... ** trace for cvs head: ** ... trace:ddraw:Main_DirectDraw_QueryInterface (0x403a4540)->({bb223240-e72b-11d0-a9b4-00aa00c0993e},0x408523cc) trace:ddraw:direct3d_create creating implementation at 0x403a54b0. trace:ddraw:Main_DirectDraw_QueryInterface returning Direct3D3 interface at 0x403a54b4. trace:ddraw:Main_DirectDraw_AddRef (0x403a4540)->() incrementing from 2. trace:ddraw:GL_IDirect3DImpl_3_CreateDevice (0x403a54b0/0x403a54b4)->({31416d44-86ae-11d2-822d-a8d53187cafb},0x403a4f18,0x408523d0) trace:ddraw:d3ddevice_create creating OpenGL device for surface = 0x403a4f18, d3d = 0x403a54b0 trace:ddraw:d3ddevice_create visual found trace:ddraw:d3ddevice_create context created (0x809f818) trace:ddraw:d3ddevice_create setting current context trace:ddraw:set_context glxMakeCurrent 0x80690c0, 62914563, 0x809f818 trace:ddraw:d3ddevice_create current context set trace:ddraw:d3ddevice_create creating implementation at 0x403a55e8. trace:ddraw:create_device_helper returning OpenGL D3DDevice2 0x403a55f0 trace:ddraw:Thunk_IDirect3DDeviceImpl_2_NextViewport (0x403a55f0)->(0x405393,0x42cb40,00000000) thunking ...

2 3

Re: Wine 0.9 TODO v0.6
by Z_God 03 Dec '02

03 Dec '02

First, would it be an idea to say at least *insert any number* of Windows apps should be working perfectly with Wine before it is called 0.9? For example, we at least want to have 200 known perfectly working apps. And why not start at version 0.6 or something and calling Wine beta software instead of alpha when these TODOs are done? Then it would be possible to work towards a great 1.0 release. Just look at Mozilla, they post-poned their 1.0 release more than a year to become really great. Keep up the great work!! Z_God Op maandag 2 december 2002 19:40, schreef Dimitrie O. Paun: > Hi folks, > > Version 0.6 of the TODO for Wine 0.9 is available at: > http://www.dssd.ca/wine/Wine-0.9-TODO-0.6.html > As always, you can find the work-in-progress one here: > http://www.dssd.ca/wine/Wine-0.9-TODO.html > > As a departure from previous release, this time I'm only going > to include a small summary of changes since the last release: > -- A4: New screenshots page is available for comment > -- A5: New FAQ is done, waiting to be promoted to WineHQ > -- D2: Alexandre got rid of the rsrc directive in .spec files > -- E4: Lionel made OpenGL detection dynamic > -- E9: New TODO item for fixing header location as discussed on > wine-devel > > Enjoy!

2 1

Programs to test D3D
by J C 02 Dec '02

02 Dec '02

Hi all, I've been following the recent work on D3D and decided I would give a couple of benchmarks/demos I had around a go. Pleasantly I found that they actually start up now and display some stuff on screen! Before the recent patches they would fail completely when starting the actual D3D stuff. I'm not sure if you're aware of these programs or not but I figured I would pass on the URLs to you as they might be of help. This first is a demo called Bleam: http://www.bluespoon.com/banjoh/ This page has a binary of the demo and source code as well. The second is an older benchmark/demo called Tirtanium: http://www.tirtanium.de/prog3d.html The homepage doesnt seem to have the binary anymore so here's a direct link to a mirror: http://public.planetmirror.com/pub/3dfiles/tweakfiles/benchmark/tirta190.zip Both display stuff on screen and will run through to the end with no crashes. Justin Chevrier PS. Great work guys! _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

W->A calling and 32->16 calling
by Rolf Kalbermatter 02 Dec '02

02 Dec '02

While going through the shell32 sources I found several issues with respect of this and at least one of them I couldn't find in the Janitorial list. ExtractIconW calls ExtractIconA which is mentioned but ExtractIconA calls InternalExtractIcon16 which is a 16 bit undocumented but exported function. I guess this should also go into the 32->16bit list somehow. I have worked on some fix for this but have to admit that this seems a little bit tricky. InternalExtractIcon16 also tries to open the file name with LoadLibrary16 so if it is a 16bit DLL the requested icons will still be extracted. PrivateExtractIcon and friends which are similar but also can handle negative icon indices which indicates that it should be treated as icon identifier, do as far as I can see not deal with 16bit libraries (they ultimatively call ICO_ExtractIconExW. This of course poses the question if the 32bit function ExtractIcon is supposed to return icons for 16bit libraries and if so, ExtractIconEx may actually also be required to do so. Below is a first attempt for a patch which does most probably not try to load resources from 16bit libraries yet. Also how about going with InternalExtractIcon16? Any comments to this? Rolf Kalbermatter Index: dlls/shell32/shell32_main.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/shell32_main.c,v retrieving revision 1.108 diff -u -r1.108 shell32_main.c --- dlls/shell32/shell32_main.c 21 Nov 2002 23:56:42 -0000 1.108 +++ dlls/shell32/shell32_main.c 2 Dec 2002 20:43:23 -0000 @@ -544,19 +544,18 @@ * FIXME * if the filename is not a file return 1 */ -HICON WINAPI ExtractIconA( HINSTANCE hInstance, LPCSTR lpszExeFileName, - UINT nIconIndex ) -{ HGLOBAL16 handle = InternalExtractIcon16(HINSTANCE_16(hInstance),lpszExeFileName,nIconIndex, 1); - TRACE("\n"); - if( handle ) - { - HICON16* ptr = (HICON16*)GlobalLock16(handle); - HICON16 hIcon = *ptr; - - GlobalFree16(handle); - return HICON_32(hIcon); - } - return 0; +HICON WINAPI ExtractIconA(HINSTANCE hInstance, LPCSTR lpszFile, UINT nIconIndex) +{ + HICON ret; + INT len = MultiByteToWideChar(CP_ACP, 0, lpszFile, -1, NULL, 0); + LPWSTR lpwstrFile = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); + + TRACE("%p %s %d\n", hInstance, lpszFile, nIconIndex); + + MultiByteToWideChar(CP_ACP, 0, lpszFile, -1, lpwstrFile, len); + ExtractIconW(hInstance, lpwstrFile, nIconIndex); + HeapFree(GetProcessHeap(), 0, lpwstrFile); + return ret; } /************************************************************************* @@ -564,18 +563,21 @@ * * FIXME: if the filename is not a file return 1 */ -HICON WINAPI ExtractIconW( HINSTANCE hInstance, LPCWSTR lpszExeFileName, - UINT nIconIndex ) -{ LPSTR exefn; - HICON ret; - TRACE("\n"); +HICON WINAPI ExtractIconW(HINSTANCE hInstance, LPCWSTR lpszFile, UINT nIconIndex) +{ + HICON hIcon = NULL; + + TRACE("(%p %s %d\n", hInstance, debugstr_w(lpszFile), nIconIndex); - exefn = HEAP_strdupWtoA(GetProcessHeap(),0,lpszExeFileName); - ret = ExtractIconA(hInstance,exefn,nIconIndex); + if (nIconIndex == -1) + return (HICON) PrivateExtractIconsW(lpszFile, -1, 0, 0, NULL, 0, 0, 0); - HeapFree(GetProcessHeap(),0,exefn); - return ret; + ExtractIconExW (lpszFile, nIconIndex, &hIcon, NULL, 1); + if (hIcon) + return hIcon; + return (HICON)1; } + typedef struct { LPCSTR szApp;

1 0

Re: Wine 0.9 TODO v0.6
by Hetz Ben-Hamo 02 Dec '02

02 Dec '02

> As a departure from previous release, this time I'm only going > to include a small summary of changes since the last release: > -- A4: New screenshots page is available for comment I looked at the screenshots. Looks very impressive but very problematic.. Why problematic? simple: most of those applications requires many tweaks to run. Example: try to install Office 2k on the latest wineHQ. You'll have lots of problems installing it, and even if you install, you'll need to do "reboot" - which is not available unless you have CrossOver office. Same goes to many applications which have screenshots there.... So think what will happend if users will download wine-snapshot and won't be able to install the apps that appears in the screenshots? lots of anger, flames, false bug reports, you name it ;) Thanks, Hetz

2 1

Re: Cabinet update
by Alexandre Julliard 02 Dec '02

02 Dec '02

Patrik Stridvall <ps(a)leissner.se> writes: > *** cabinet > > * include/fci.h, > include/fdi.h, > dlls/cabinet/Makefile.in, > dlls/cabinet/fci.c, > dlls/cabinet/fdi.c, > dlls/cabinet/main.c: > - Added previously forgotten file main.c. There is no reason to have a stub DllMain, it only slows things down and makes no difference for the app. We should only add it if/when we really need it. -- Alexandre Julliard julliard(a)winehq.com

1 0

Winelib - MFC application
by Ronald MALLET 02 Dec '02

02 Dec '02

I'm currently trying to build an MFC based-applications using Winelib. I (almost) successfully compiled the MFC, and get an mfc.dll.so file. Here are the few troubles I had or still have: First for compiling the MFC: --------------------------------------- - I had to uncomment PSH_WIZARD97 in /wine/prsht.h - The packing pragmas looks handled by gcc-3.2.1, so we may remove all modifications made by winemaker - I had to force winnt.h to use nameless struct and unions - I added #define EDEADLOCK EDEADLK in /wine/msvcrt/errno.h - I linked _alloca() to alloca() function - There was a conflict on HKEY type between <afxres.h> and <wine/windef.h> - Some little others syntax issues like: __try __expect, asm {}, unsigned short(x), (LPCTSTR)CString ==> it worked then, using some additional defines as suggested in the Winelib documentation page. Then for my MFC-based application: ------------------------------------------------- - Winemaker tries to link with libmfc.so, but by default we have a dll, so i just symlink it to mfc.dll.so - I first tried winemaker default settings on my app, but it creates two targets with the same name (the dll and the executables), so I had to override this using interactive mode - Then I encountered the MFC initialization problems (a crash in dllname() when loading my application .so), so I added the wrapper using winemaker - Even when using the wrapper, it crashes at startup when trying to load my application dll. - The backtrace is something like dllname (from libmfc.so) operator new ... Init (from /gcc-3.2.1/libstdc++-v3/src/ios.cc:211) ___static_initialization_and_destruction_ ... _dl_open ... WinMain (from myapp.exe_wrapper.c:83) __wine_exe_main (from myapp.exe.spec.c:129) start_process call_on_thread_stack - Winelib must have been initialized, but the problem stills here ? Any suggestion ? - I then tried to remove linking with libmfc.so but using only the mfc.dll.so (I had to fill the mfc.dll.spec file to export all the symbols, using weird mangling rules), but it then hook in the msvcrt.dll in an infinite _lock loop ? I'm a bit lost with this error, as it's not in an easy-to-debug code area.... Any advices are welcomed !

3 3

RE: strcat+strcat+strcat == baaad
by Medland, Bill 02 Dec '02

02 Dec '02

> -----Original Message----- > From: wine-devel-admin(a)winehq.com > [mailto:wine-devel-admin@winehq.com]On > Behalf Of Alexandre Julliard > Sent: Monday, December 02, 2002 9:03 AM > To: Shachar Shemesh > Cc: David Laight; David Fraser; Shachar Shemesh; Francois Gouget; > wine-devel(a)winehq.com > Subject: Re: strcat+strcat+strcat == baaad > > > Shachar Shemesh <winehebhaim(a)sun.consumer.org.il> writes: > > > I suggest implementing strlcat and strlcpy, as in OpenBSD. > I can write > > them, but I'm not sure where to place them. They should either be > > inlined (as in - implemented in an include file as a static > func), or > > in some library that will be linked (statically, I hope). Ideas? > > We don't need that, there are Windows API functions like lstrcpyn that > can be used for that. And in any case the right approach to writing > correct and secure code is not to truncate every string in sight to > some fixed buffer size; it's to make sure you allocate buffers of the > right size, and then you can use standard strcpy/strcat/sprintf/etc. > without worrying about lengths. I think this statement has to be tightened. I am sure you know exactly what you mean, Alexandre, and I believe that I and many others do. However I think we need to mention that one needs to consider that the strings passed in may be bad, e.g. unterminated. Either one uses that actual measured lengths of the strings when allocating or one checks the lengths of the strings against the allocated space. In particular one DOES NOT allocate on the basis of some wishy-washy documentation statement or a hard-coded constant that the caller may well have ignored. > > -- > Alexandre Julliard > julliard(a)winehq.com > > Bill Medland

3 2

Jump to page:

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 December 2002