- Wine-Devel - list.winehq.org

wine hangs in ddraw/d3dtexture.c (d3dtexture_create)
by Michael Schlüter March 20, 2004

March 20, 2004

Hi, the whole yesterday I was hunting a problem when staring a program with wine. Now I'm at a point I don't know what to do next. May be somebody can give me an hint? Here are the last lines of the trace+ddraw output: trace:ddraw:Main_DirectDrawSurface_Lock (0x40405b50)->Lock((nil),0x408bf960,00000001,00000000) trace:ddraw:Main_DirectDrawSurface_Lock - locking flags : DDLOCK_WAIT trace:ddraw:d3ddevice_lock_update copying back buffer to main memory with rectangle (0x0) - (800x600). trace:ddraw:Main_DirectDrawSurface_Lock locked surface returning description : - DDSD_CAPS : DDSCAPS_BACKBUFFER DDSCAPS_COMPLEX DDSCAPS_FLIP DDSCAPS_3DDEVICE DDSCAPS_VIDEOMEMORY DDSCAPS_LOCALVIDMEM - DDSD_HEIGHT : 600 - DDSD_WIDTH : 800 - DDSD_PITCH : 1600 - DDSD_LPSURFACE : 0x5f0d0000 - DDSD_PIXELFORMAT : ( DDPF_RGB , RGB bits: 16, R f800 G 07e0 B 001f) trace:ddraw:Main_DirectDrawSurface_Unlock (0x40405b50)->Unlock((nil)) trace:ddraw:DIB_DirectDrawSurface_Blt (0x403f5768)->(0x61885c,0x40405b50,0x61886c,01000000,(nil)) trace:ddraw:DIB_DirectDrawSurface_Blt destrect :0x0-800x600 trace:ddraw:DIB_DirectDrawSurface_Blt srcrect :0x0-800x600 trace:ddraw:DIB_DirectDrawSurface_Blt flags: DDBLT_WAIT trace:ddraw:d3ddevice_blt using direct buffer to buffer copy. trace:ddraw:upload_surface_to_tex_memory_init initialized texture upload for level 0 with conversion 0. trace:ddraw:Main_DirectDraw_CreateSurface (0x403f5418)->(0x61741ba0,0x60d0aedc,(nil)) trace:ddraw:Main_DirectDraw_CreateSurface Requesting surface desc : - DDSD_CAPS : DDSCAPS_TEXTURE DDSCAPS2_TEXTUREMANAGE - DDSD_HEIGHT : 128 - DDSD_WIDTH : 256 - DDSD_PIXELFORMAT : ( DDPF_ALPHAPIXELS DDPF_RGB , RGB bits: 16, R 7c00 G 03e0 B 001f A 8000) trace:ddraw:HAL_DirectDrawSurface_Construct (0x60f501b8,0x403f5418,0x61741ac0) trace:ddraw:DIB_DirectDrawSurface_Construct (0x60f501b8)->(0x403f5418,0x60f503b4) trace:ddraw:Main_DirectDrawSurface_Construct (0x60f501b8)->(0x403f5418,0x60f503b4) trace:ddraw:DIB_DirectDrawSurface_Construct (256x128, pitch=512) trace:ddraw:create_dib DIBSection at : 0x62100000 trace:ddraw:d3dtexture_create GL texture created for surface 0x60f501b8 (private data at 0x60f50058) The appropriate source code: ENTER_GL(); if (surf->mipmap_level == 0) { glGenTextures(1, &(private->tex_name)); if (private->tex_name == 0) ERR("Error at creation of OpenGL texture ID !\n"); TRACE(" GL texture id is : %d.\n", private->tex_name); private->__global_dirty_flag = (at_creation == FALSE ? SURFACE_MEMORY_DIRTY : SURFACE_MEMORY); private->global_dirty_flag = &(private->__global_dirty_flag); } else { private->tex_name = ((IDirect3DTextureGLImpl *) (main->tex_private))->tex_name; TRACE(" GL texture id reusing id %d from surface %p (private at %p)).\n", private->tex_name, main, main->tex_private); private->global_dirty_flag = &(((IDirect3DTextureGLImpl *) (main->tex_private))->__global_dirty_flag); } LEAVE_GL(); A printf showed me, that the call of glGenTextures didn't come back. That's strage because d3dtexture_create and glGenTextures are called a lot of times before without problems? If I delete glGenTextures it works but... Bye, Michael

3 8

Re: Win32 packages released on sourceforge
by Ivan Leo Murray-Smith March 19, 2004

March 19, 2004

> Can you please post the list of errors to wine-devel, so people are aware of the > problems (and hopefully send patches to fix them :))? Complete compile error log is attached. > Now that we have this build, can we get rid of: > Wine programs for Windows > from the "Support Files" package? Done. Ivan.

5 5

Re: urlmon: Implement FindMimeFromData
by Juan Lang March 19, 2004

March 19, 2004

Kevin, you said: IMHO we should really keep the list that is checked to a minimum (being the list Windows checks) as this code is basically doing "If a web server reports a MIME type in this list, ignore it and make our own guess" which is totally wrong standards-wise and a major cause of many problems under IE on Windows.. (Apologies for the lack of quoting.) According to that appendix, IE should only be overriding MIME types that are text/plain, application/octet-stream, or empty. It does so because it considers these "ambiguous". I think your patch may be useful for the small set of types you suggest, but shouldn't you only override in these cases too? --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com

3 2

wine.inf
by Ivan Leo Murray-Smith March 18, 2004

March 18, 2004

Hi list, I've installed wine.inf, but the system.reg file is very short, it only contains font information and computer name, this isn't exactly what I got with winedefault.reg I need this because I'm going to release a new version of winesetuptk that doesn't add the "Filesystem" parameter to the drive config, as AJ has removed it, and the winesetuptk build tree wants system.reg, user.reg and userdef.reg. But system.reg, well, I've described it, userdef.reg is empty and user.reg only contains the Control Panel\\Colors and Control Panel\\International entries. Am I doing something wrong? Ivan.

1 0

urlmon: Implement FindMimeFromData
by Kevin Koltzau March 18, 2004

March 18, 2004

Here is an implementation of FindMimeFromData, based off of MSDN http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.a… There is lots of debate on the 'net regarding this "feature" in IE, most of it suggesting this is a bad idea.. One possible change that would work more "standards compliant" rather then "Windows like" would be to return the proposed MIME type unchanged if one is given, otherwise go through the detection methods..let me know if that would be a preferred solution Changelog Implement FindMimeFromData

2 2

Re: [RESENT] TIME_GetBias
by Alexandre Julliard March 18, 2004

March 18, 2004

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Changelog: > wine/dlls/ntdll/time.c: TIME_GetBias > Calculate the Bias before calling gmtime This cannot be right, the bias is supposed to be the difference between local time and GMT, so you have to use gmtime() not localtime(). -- Alexandre Julliard julliard(a)winehq.org

5 15

Re: Re: PLT pointer destroyed problem when loading IR32_32.DLL (Indeo codec)
by Christian Costa March 18, 2004

March 18, 2004

> Message du 18/03/04 00:51 > De : Marcus Meissner > A : Christian Costa > Copie à : wined > Objet : Re: PLT pointer destroyed problem when loading IR32_32.DLL (Indeo codec) > On Wed, Mar 17, 2004 at 10:37:01PM +0000, Christian Costa wrote: > > Hi, > > > > When executing the DllMain of the native IR32_32.DLL (VFW), Wine crashes. > > After some investigations, I found that a part of the code uses the EBX > > register at one point without saving > > and restore it afterwards. Since this register contains the PLT pointer > > for standard unix functions like libc ones, this > > does not take a long time for Wine to crashing. > > I tested with the ugly hack attached that saves and restores the EBX > > register between the call to DllMain and that fixed the problem and > > the DLL works fine then. > > This might happen. That ebx can be scrapped? > > Your fix is not really ok, you must not modify the stackpointer in asm statements. > > Try using: > __asm__ __volatile__ ("":::"ebx"); > > after entry(), which tells the compiler that ebx has been scrapped. Thanks for this! :-) Christian

2 1

Re: Re: PLT pointer destroyed problem when loading IR32_32.DLL (Indeo codec)
by Christian Costa March 18, 2004

March 18, 2004

> Message du 18/03/04 00:50 > De : Mike Hearn > A : wine-devel(a)winehq.com > Copie à : > Objet : Re: PLT pointer destroyed problem when loading IR32_32.DLL (Indeo codec) > On Wed, 17 Mar 2004 22:37:01 +0000, Christian Costa wrote: > > When executing the DllMain of the native IR32_32.DLL (VFW), Wine crashes. > > After some investigations, I found that a part of the code uses the EBX > > register at one point without saving and restore it afterwards. > > What calling convention is the entrypoint declared with? How can I retreive this info from the dll? I guess it is stdcall like it should be. > I thought EBX was > a register that had to be saved/restored according to the ABI and the > windows compilers would always do that? > I don't know but that would explain what is happening altough if it was the case I wonder why noone has encountered this problem yet. Bye, Christian

2 1

Re: PLT pointer destroyed problem when loading IR32_32.DLL (Indeo codec)
by Christian Costa March 18, 2004

March 18, 2004

> Message du 18/03/04 01:02 > De : Alexandre Julliard > A : Christian Costa > Copie à : wined > Objet : Re: PLT pointer destroyed problem when loading IR32_32.DLL (Indeo codec) > Christian Costa writes: > > > When executing the DllMain of the native IR32_32.DLL (VFW), Wine crashes. > > After some investigations, I found that a part of the code uses the > > EBX register at one point without saving > > and restore it afterwards. Since this register contains the PLT > > pointer for standard unix functions like libc ones, this > > does not take a long time for Wine to crashing. > > Is the dll really modifying ebx explicitly? Isn't it rather a > consequence of a stack overflow or some similar bug? Yes, ebx is modified explicity and not poped from the stack. There is no save/restore statements. Bye, Christian

1 0

wineinstall hangs
by Fabian Cenedese March 18, 2004

March 18, 2004

Hi I just tried on a new computer to checkout wine from cvs and do a install. Compilation worked fine, but there was again a problem with the regedit: --- snip --- Preparing to install default Wine registry entries... Installing default Wine registry entries... Warning: Language 'us' was not recognized, defaulting to English. Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: Xlib: extension "GLX" missing on display ":1.0". fixme:urlmon:URLMON_DllRegisterServer (void): stub wine: Unhandled exception (thread 0009), starting debugger... Warning: Language 'us' was not recognized, defaulting to English. Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: (hang, CTRL-C) Registry entries successfully installed. err:seh:setup_exception nested exception on signal stack in thread 0009 eip 40108aa6 esp 40031c28 stack 0x405a0000-0x406a0000 Installation complete for now. Good luck (this is still alpha software). If you have problems with WINE, please read the documentation first, as many kinds of potential problems are explained there. --- snip --- But after that I could start wine regedit and the keys seem to have been generated. So I don't know what really failed. bye Fabi

3 4