wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

[daniel: OpenGL bug in 20050930]
by Daniel 14 Oct '05

14 Oct '05

Hi, some combination of wine and my system seems to be triggering a strange bug: Every program that uses OpenGL or D3D crashes upon trying to initialize the graphics. Attached is a sample log of trying to run Starsiege Tribes. The other attachment is some system info (even though DRI is disabled, enabling ist changes nothing). Other apps have similar logs. If you want to try out Tribes in particular, search the web for 'tribes_fullgame.exe'; Fileplanet for example has it. greets, Daniel

3 4

DefDlgProc* broken for (at least) WM_GETTEXT
by Troy Rollo 14 Oct '05

14 Oct '05

The DefDlgProc16, DefDlgProcA and DefDlgProcW call CallWindowProc16, CallWindowProcA and CallWindowProcW to pass messages to the dialog procedures. The problem with this is that a dialog procedure is not a window procedure, despite having a similar signature. The dialog procedures return a BOOL rather than an LRESULT - the value that would be returned by a window procedure is returned by 'SetWindowLongPtrW( hwnd, DWLP_MSGRESULT, ... );' for a dialog procedure, and the return value of the dialog procedure is a BOOL indicating whether the message was processed. This causes problems for messages like WM_GETTEXT, where the return value of the message is needed for (and modified by) post-processing when calling across a W->A or A->W boundary. It seemed that the tidyest fix would be to create three new routines internal to dlls/user: "call_dialog_proc_a", "call_dialog_proc_w" and "call_dialog_proc16". These three routines would be substantially the same as CallWindowProcA, CallWindowProcW and CallWindowProc16, except that they would pass a flag to the 6 cross-call case handling routines to let the routine know it is calling a dialog procedure and needs to use the value for DWLP_MSGRESULT for its post-processing. The problem with this is that two of the cross-call handling routines (the 16->W and 16->A ones) are exported: __wine_call_wndproc_32A __wine_call_wndproc_32W They do not appear to be used anywhere outside of the file they are defined in, and it seems unlikely an app could ever have a legitimate use for them. Vitaliy suggested maybe they may have been inadvertently missed in a cleanup of cross-DLL calls. So, what I propose to do is: 1. make __wine_call_wndproc_32A and __wine_call_wndproc_32W static (and hence not exported) 2. Add a parameter to each of __wine_call_wndproc_32A, __wine_call_wndproc_32W, WINPROC_CallProc32WTo32A, WINPROC_CallProc32WTo16, WINPROC_CallProc32ATo16 and WINPROC_CallProc32ATo32W to indicate that the cross-call routine should get the LRESULT from (and set it into) the DWLP_MSGRESULT value. 3. Rename the existing CallWindowProc* routines to (static) call_window_proc*, add the flag parameter there as well, and create new CallWindowProc* and call_dialog_proc_* routines to call the renamed routines with the appropriate flag. Any objections?

2 6

dbghelp issue
by Saulius Krasuckas 14 Oct '05

14 Oct '05

I got this while running winedbg over deadlocked Gothic demo (v1.04d): | 7 0x7fd362e5 SuspendThread+0x1d(hthread=0xc0) [/usr/src/wine-cvs/wine/dlls/kernel/thread.c:348] in kernel32 (0x7aa8aaf8) | fixme:dbghelp_msc:codeview_snarf Unsupported symbol id 5 | fixme:dbghelp_msc:dump 00000000: 0a 00 05 00 50 01 00 00 01 00 00 00 ....P....... | err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols | 8 0x005d0d68 in gothic (+0x1d0d68) (0x7aa8ab48) Should I enter new bug?

1 0

Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back
by Mike Hearn 14 Oct '05

14 Oct '05

On Wed, 12 Oct 2005 21:16:05 +0000, Eddahbi Karim wrote: > Now the mouse problem comes back but the workarounds don't work this > time. It's not a regression, it's a bug enhancement. > > The old workaround for WineX still work according to gentoo-forums [2]. It seems Warcraft relies upon NULL-addressed VirtualAlloc starting allocation from above a certain range - possibly they're pulling some silly bit-twiddling hack or optimisation. The Cedega patch linked to on the forums basically hints to mmap that it should allocate at a fixed address in this case: http://lists.transgaming.org/pipermail/winex-devel/2004-May/000259.html Which for WoW they seem to set this hint to 256mb - is there some aspect of the NT kernel we're not correctly implementing here? Does Windows always allocate from 256mb upwards? Alexandre, Mike - does hinting to mmap in the port library as TransGaming do it seem like a good solution here or would it be better to adapt the preloader to block off the lowest $X megs? thanks -mike

4 7

[dbghelp] continue dwarf support:try 2
by Raphael 13 Oct '05

13 Oct '05

Hi, On Monday 10 October 2005 09:06, Raphael wrote: > Changelog: > - begin of dwarf debug lines parsing > - better robustness > - support of unamed syms > - better traces > > TODO: > - find a clean way to handle forward declarations > - debug lines parsing > as Eric wanted: without type.c modification I'll try to improve it for next patch Regards, Raphael

1 0

Improve Bugzilla Query page usability by changing default state?
by Dan Kegel 13 Oct '05

13 Oct '05

Hey all, every time I do a Bugzilla query, I find the default value for State on the query page to be an annoyance. It would save me a lot of mouse clicks if the State field could either be totally unselected, or at least include the Unconfirmed state by default. This came up because a QA volunteer complained about how hard it was to start using the Bugzilla query page. This was an annoyance for him, too. Fixing this would simplify the Bugzilla quick start on my 'Wine needs YOU to triage bugs!' page, http://kegel.com/wine/qa/#tools How do people feel about the proposed change? Thanks, Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

9 26

Re: [dbghelp] continue dwarf support
by Eric Pouech 13 Oct '05

13 Oct '05

Raphael wrote: > Hi, > > Changelog: > - begin of dwarf debug lines parsing > - better robustness > - support of unamed syms > - better traces > > TODO: > - find a clean way to handle forward declarations > - debug lines parsing > > Index: type.c > =================================================================== > RCS file: /home/wine/wine/dlls/dbghelp/type.c,v > retrieving revision 1.12 > diff -u -r1.12 type.c > --- type.c 18 Apr 2005 15:34:10 -0000 1.12 > +++ type.c 10 Oct 2005 07:02:25 -0000 > @@ -204,8 +204,8 @@ > * the others (bit fields) > */ > BOOL symt_add_udt_element(struct module* module, struct symt_udt* udt_type, > - const char* name, struct symt* elt_type, > - unsigned offset, unsigned size) > + const char* name, struct symt* elt_type, > + unsigned offset, unsigned size) > { > struct symt_data* m; > struct symt** p; > @@ -220,7 +220,7 @@ > assert(m); > assert(m->symt.tag == SymTagData); > if (m->hash_elt.name[0] == name[0] && strcmp(m->hash_elt.name, name) == 0) > - return TRUE; > + return FALSE; > } > > if ((m = pool_alloc(&module->pool, sizeof(*m))) == NULL) return FALSE; I don't see the reason of changin the returnd value from TRUE to FALSE -- Eric Pouech

2 4

STI on wine: progress + help
by Damjan Jovanovic 13 Oct '05

13 Oct '05

Hi I've been working on an STI implementation for wine, and recently I made some progress. At present I've got a basic STI.DLL and I've made a Linux kernel module replacement of USBSCAN.SYS on Windows. I've only changed CreateFile() and NtDeviceIoControl(). When CreateFile() gets a devicepath "\\.\USBSCAN..." it opens the kernel module's device file using open(), and sends the file descriptor to the wine server using wine_server_fd_to_handle(). NtDeviceIoControl() checks the IOCTL code to see whether it is a scanner code, and if so, does an ioctl() call. The problem seems to be that after running for a couple of seconds, all the file system calls like ioctl() start failing with EBADF (bad file descriptor). Is there something other than wine_server_fd_to_handle() I have to do? The scanning application I am testing uses multiple threads and several processes. Thank you Damjan __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs

2 2

GoogleEarth issues
by Robbert Xerox 13 Oct '05

13 Oct '05

Hi, wouldn't it be great to get Googleearth more or less running before Wine 0.9 comes out. At least i think it would be great as is is top voted application and very popular. I did some investigation and found that GoogleEarth suffers from at least 4 bugs. However 3 of them can be bypassed for now by using native dlls. The bug that really makes it quite unusable is that that the menus are hidden by GoogleEarths's image. GoogleEearth's image is in the lower left corner whereas it should be in the upper right corner. The following patch seems to have caused this issue: http://www.winehq.org/pipermail/wine-cvs/2005-January/013739.html Maybe someone who is familiar with the x11drv code could have a look at it. More info in http://bugs.winehq.org/show_bug.cgi?id=3083 Thanks ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

1 0

How Do I launch a Native Linux application from Within Wine
by Craig macLeod 13 Oct '05

13 Oct '05

As the subject says, I have a Windows application and I wish to run a native linux application from withing it. The main Win32 API calls for running another apllication are ShellExecute WinExec CreateProcess I have tried calling a native linux program with these (nautilus) and it consistently fails. Do I need a fully specified path (nautilus is in the search path mind you)? It either does nothing or hangs Wine when I try calling these applications. I assume Wine is running the application as if it is a Windows app and failing. Thanks for any help in advance.

3 2

Re: Fix for #3464
by Jakob Eriksson 13 Oct '05

13 Oct '05

Can I create b: on the fly, allocate 1.44 megabyte RAM, do all copies there and then copy it back? Am I on crack? regards, Jakob Eric Pouech wrote: > It turns out that DOS' ioctl 0x440F (set logical drive map) was > strangely implemented. From the doc I have, this ioctl is responsible > for setting the logical drive to access a physical drive. This is used > for example, on a single floppy PC when implementing the copy a:foo > b:bar command, where a: and b: refer to the same physical device (the > floppy), and this ioctl is called to toggle the access from a: or b: > to the physical device. > This implies that this ioctl is not responsible for creating the > mapping of a: and b: to the same physical device. > The current implementation was trying to achieve this goal and > moreover it was done in the wrong way :-/ > The attached patch removes altogether the support for logical drive > map in int21h (and fixed Myst BTW). > > A+ > >------------------------------------------------------------------------ > >Name: int21_mapdrv >ChangeLog: ioctl 440F only returns non mapped drives (for now) >License: X11 >GenDate: 2005/10/12 18:41:20 UTC >ModifiedFiles: dlls/winedos/int21.c >AddedFiles: >RemovedFiles: >=================================================================== >RCS file: /home/cvs/cvsroot/wine/wine/dlls/winedos/int21.c,v >retrieving revision 1.81 >diff -u -u -r1.81 int21.c >--- dlls/winedos/int21.c 18 Sep 2005 11:11:36 -0000 1.81 >+++ dlls/winedos/int21.c 12 Oct 2005 18:40:47 -0000 >@@ -2627,19 +2627,12 @@ > break; > > case 0x0f: /* SET LOGICAL DRIVE MAP */ >- { >- WCHAR dev[3], tgt[4]; >+ TRACE("IOCTL - SET LOGICAL DRIVE MAP for drive %s\n", >+ INT21_DriveName( BL_reg(context))); > >- TRACE("IOCTL - SET LOGICAL DRIVE MAP for drive %s\n", >- INT21_DriveName( BL_reg(context))); >- dev[0] = 'A' + drive; dev[1] = ':'; dev[2] = 0; >- tgt[0] = 'A' + drive + 1; tgt[1] = ':'; tgt[2] = '\\'; tgt[3] = 0; >- if (!DefineDosDeviceW(DDD_RAW_TARGET_PATH, dev, tgt)) >- { >- SET_CFLAG(context); >- SET_AX( context, 0x000F ); /* invalid drive */ >- } >- } >+ /* FIXME: as of today, we don't support logical drive mapping... >+ */ >+ SET_AL( context, 0 ); > break; > > case 0x11: /* QUERY GENERIC IOCTL CAPABILITY */ > > >------------------------------------------------------------------------ > > > >

1 0

Re: [d3d8] Fix cobe texture update support [bug-3550]
by Raphael 13 Oct '05

13 Oct '05

On Wednesday 12 October 2005 21:09, Oliver Stieber wrote: > Hi, > This patch allows cube textures to be updated fixing one of the problems > in BUG 3550 > > Oliver. Good catch (for a long time i was trying to find what happened) Regards, Raphael

1 0

Winefile change - Where do I request one
by Craig macLeod 13 Oct '05

13 Oct '05

Hi, I would like a change to the Winefile application to add the ability to parse the commandline for it. Mainly so you can pass in a startup folder. eg winefile c:/temp will open the selected path under /.wine/ folder. This feature would be useful so an application can open a browse folder option. This is not a bug as such and I am not sure is bugzilla is the appropriate place to request this. Could someone let me know where I should request the small change. Thanks in advance.

2 1

Bugzilla administration policies
by James Hawkins 13 Oct '05

13 Oct '05

Hi, I really appreciate the effort everyone has put into cleaning out the old bugs in our bugzilla recently; however, I do have an issue with the way we're closing some of the bug reports. The ultimate outcome of wine is to enable a user to run windows apps just as they would in windows, so if a user has to run the app with a native dll or follow special instructions to make it work, then there is a bug in wine that needs to be fixed. Quite a few bugs have been closed recently referring the user to the instructions in the AppDB or to a list of dll overrides that makes the app work. Recommending a dll override can be useful to the end user as a temporary workaround, but the bug hasn't been fixed. Cleaning out the bugzilla is well appreciated, but we must keep up due diligence in order to keep wine's bugzilla as a reliable status of wine's bugs. I offer this as the beginning of a discussion of bugzilla administration policies. Any thoughts, comments, and ideas are welcome. -- James Hawkins

8 20

Re: RICHED20: fix bug# 3541 (crash in EM_POSFROMCHAR when offset>=text length)
by Jonathan Ernst 12 Oct '05

12 Oct '05

You forgot to attach the patch... thanks. Le mercredi 12 octobre 2005 à 12:58 -0700, Krzysztof Foltman a écrit : > I'm still surprised how could I overlook that - luckily, the library of > test cases is growing :) > > ChangeLog: > * fix unnecessary (and harmful) repeated statement > -- Jonathan Ernst <Jonathan(a)ErnstFamily.ch>

1 0

New themes question
by Matevz Jekovec 12 Oct '05

12 Oct '05

Now that Wine supports different theme packs for Windows, would it be possible to render Windows widgets using the native current desktop KDE/Gnome theme? Also other stuff like font size, name and colors for Windows widgets, could they all be unified? That would *really* be something:). Big thanks to all developers, that drove Wine so far and best wishes for the future! - Matevž

1 0

Warblade runtime error (Warblade install error cont'ed)
by Sebastien Fievet 12 Oct '05

12 Oct '05

Hi all, I grabbed a CVS snapshot yesterday, and while the builtin COMCTL32 doesn't work, with the native one, i finally managed to install Warblade (as previously reported by Marcus Meissner), whereas wine-20050930 crashed. Now that i moved one step further, a new error appears, when launching the game : err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to dispatch exception. According to Marcus it may be copy protection related... Any little help is fairly welcome! Regards, Seb.

1 0

Ping
by Daniel 12 Oct '05

12 Oct '05

Is there anyone that actually receives my mails? confused, Daniel

5 5

D3D7 -> WineD3D, 2nd attempt
by Stefan Dösinger 12 Oct '05

12 Oct '05

Hello, I am trying again to Implement Direct3D 7 using WineD3D, and I've made some progress. The D3D7 Device implementation seems to initialize correctly, with the correct surfaces. My solution looks like this: * DirectDraw is unmodified, and it remains in ddraw.dll. * Direct3D7 uses generally the Direct3D9 interface of WineD3D. The only changes made to WineD3D are in WineD3DDeviceImpl_Release and a little change in WineD3DSurface. * WineD3D Surfaces can be attached to DDraw Surfaces, and they receive the properties of their parents, including the memory reserved for the surface * The D3D7 implementation creates a SwapChain and a RenderTarget from the DirectDrawSurface it's attached to, as well as a DepthStencil WineD3D surface to make WineD3D happy I've made the following changes to WineD3D so far: * Make WineD3D handle dxVersion 7, generally with the same code as with dxVersion 7 * A new parameter to WineD3DDevice_Create: a pointer, which specifies an existing surface memory. If != NULL is passed, no memory is reserved by WineD3D, and it's not Released on WineD3DSurface_Release * When releasing the WineD3DDevice, don't release the parents of the RenderTarget, the DepthStencilBuffer, BackBuffer and FrontBuffer, because ddraw.dll needs it's surfaces. Instead, release the WineD3DSurfaces only. The whole thing is far from beeing useable, if anyone is interested in the code, I can send it, but be warned, it's quite a mess at the moment. My plan is to get some games running, and then I'll send small and clean patches for CVS commit and upload a big patch somewhere for prior testing. Stefan

3 10

winelib .so change in 20050930?
by Michael Ost 12 Oct '05

12 Oct '05

With the advent of 20050930 wine can no longer load the shared libraries used by my winelib app. Are there any docs or descriptions about how to deal with this change? I have an app that gets built into, say, ./app/app.exe.so. It uses a shared library, say ./lib/liblib.so, that uses win32 APIs. To build ./lib/liblib.so I just compiled and linked using gcc. To build app.exe.so I would use winebuild to scan the object files at ./app/*.o and ./lib/*.o. That created wrappers for all the win32 functions both in ./app and ./lib. The wrappers code from winebuild gets linked in to app.exe.so. Wine used to be able to deal with this. With 20050930 wine complains that the win32 references in liblib.so can't be resolved and quits. I am guessing that something about wine dll loading has changed, so that the function wrappers for a wine DLL have to be in the file itself. That is, I would have to run winebuild on the lib object files, create lib.dll.so and then link app.exe.so against that. I started down this path with some success and then realized that, gulp, I would have to create a spec file for my libraries. Hundreds of C++ functions in several libraries. If this is indeed required, is there any help in building a spec file? Is it possible to export C++ functions as opposed to straight C? Winelib has always been the wild and woolly frontier. We haven't been bitten in a while; I guess we were due! ... mo

2 6

Re: Can you reproduce this bug on wine-20050930 like me?
by Jonathan Ernst 12 Oct '05

12 Oct '05

Le mardi 11 octobre 2005 à 23:45 -0700, Hiji a écrit : > --- Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > > > Tuesday, October 11, 2005, 9:00:49 PM, Hiji wrote: > > > Can you reproduce this bug? Follow these steps: > > > 1. Install Filezilla: > > > > > > http://prdownloads.sourceforge.net/filezilla/FileZilla_2_2_16_setup.exe?dow… > > > 2. FTP into the server of your choice > > > 3. Click and drag files from the server to your > > local > > > machine (to copy them) > > > 4. Realize now that even though the files have > > been > > > copied to your machine, you are still dragging the > > > files around > > > If you can replicate this serious bug, can you fix > > it? DVD Shrink exibits the same issue. Thanks -- Jonathan Ernst <Jonathan(a)ErnstFamily.ch>

2 1

Wine in the news
by Jonathan Ernst 12 Oct '05

12 Oct '05

October issue of Tuxmagazine has an article on Wine and Cedega and Wine is mentionned on the frontpage. http://new.tuxmagazine.com/node/1000155 Free subscription required but you can use my email address to download it. Regards. -- Jonathan Ernst <Jonathan(a)ErnstFamily.ch>

1 0

Re: Wine patch
by Stefan Dösinger 12 Oct '05

12 Oct '05

> Hi Stefan, did you ever get any comment on this patch, > as why it hasn't been committed?? > > http://www.winehq.org/hypermail/wine-patches/2005/03/att-0504/01-x11drv.dif >f > > It seems as if it fixes quite a few bugs (e.g. Steam) > . Was it ever discussed further? Regards Louis No, it was not discussed in detail. I think this patch is incorrect, it fixes some apps, but it breaks others, the QuickTime Player for example behaves incorrect with this patch. One suggestion was to fix non-managed windows instead, but according to some Documentation this is not possible because every window manager behaves differently with non-managed windows. Maybe someone has a better solution Cheers, Stefan

2 2

(no subject)
by Vishal Gakhare 12 Oct '05

12 Oct '05

can anybody tell me the logic of follow. files advapi.dll kernel32.dll advpack.dll

1 0

Can you reproduce this bug on wine-20050930 like me?
by Hiji 12 Oct '05

12 Oct '05

Can you reproduce this bug? Follow these steps: 1. Install Filezilla: http://prdownloads.sourceforge.net/filezilla/FileZilla_2_2_16_setup.exe?dow… 2. FTP into the server of your choice 3. Click and drag files from the server to your local machine (to copy them) 4. Realize now that even though the files have been copied to your machine, you are still dragging the files around If you can replicate this serious bug, can you fix it? Hiji P.S. This is for bug 3148, and I have been able to reproduce it on both Filezilla and AbsoluteFTP __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

2 2

Jump to page:

2025

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