wine-devel June 2004

120 participants
231 discussions

by Eric Pouech

Jon Griffiths a écrit : > Hi, > > Some overly long stabs cause crashes when debug tracing is enabled. > > Cheers, > Jon > > +dlls/dbghelp/stabs.c > Prevent the debug buffer from overflowing on long stabs You shouldn't use debugstr_an with a fixed value, since all strings are '\0' terminated. Either fix dlls/ntdll/debugtools.c to handle properly those long string conditions (and remove the ugly call to abort()), or use min(256, strlen(ptr)) as the actual length of the string in debugstr_an calls. I'd prefer the first solution. A+

19 years, 10 months

Re: wine/loader preloader.c

by Mike Hearn

On Sat, 2004-06-26 at 08:25 -0500, Mike McCormack wrote: > I think a better fix is to define it if it's missing. This commit by Alexandre should fix the segfaults people have been seeing on Fedora Core 2. Either of the two patches just sent are correct BTW, Red Hat 9/Fedora Core 1 do not place AT_SYSINFO* headers in the ELF startup auxiliary vector. thanks -mike

19 years, 10 months

Wine causing a Segmentation Fault

by David Lee

I am using the CVS wine as of 6/22/04 and when I run the compiled binary of wine, I get a Segmentation Fault. In fact, most of the wine* binaries located in /usr/local/bin give me a Segmentation Fault. I have tried a manual compile: ./configure, make depend && make, su -c make install. and using the wineinstall tool. I'm running fedora 2 and using the sources. RPMs don't work either. -- David Lee

19 years, 10 months

Re: !LOSTWAGES! site misc updates

by Ivan

> Do you really think we need to switch from American to English spelling? A common solution is to spell the same word in A.E. in some places and in B.E. in others, and that's what my patch does. Apart fomr that, it's not only a spelling patch. Ivan.

19 years, 10 months

Re: wine/loader preloader.c

by Michael Stefaniuc

Hello, On Fri, Jun 25, 2004 at 07:12:20PM -0500, Alexandre Julliard wrote: > ChangeSet ID: 12717 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2004/06/25 19:12:20 > > Modified files: > loader : preloader.c > > Log message: > Remove the AT_SYSINFO and AT_SYSINFO_EHDR values if the sysinfo page > is in one of our reserved ranges. On Red Hat Linux 9 there is no AT_SYSINFO_EHDR in /usr/include/elf.h thus breaking compilation there. I've attached a trivial patch to fix this. > > Patch: http://cvs.winehq.org/patch.py?id=12717 > > Old revision New revision Changes Path > 1.6 1.7 +62 -20 wine/loader/preloader.c bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

19 years, 10 months

Re: !LOSTWAGES! site misc updates

by Dimitrie O. Paun

On Fri, Jun 25, 2004 at 07:35:23PM +0200, Ivan wrote: > As in subject. Jeremy, please let me know if there's anything wrong in this patch. Do you really think we need to switch from American to English spelling? What if someone else is sending a patch to convert back to American? I think the spelling is fine the way it is now. -- Dimi.

19 years, 10 months

Chasing Galactic Civilizations Unhandled Exception

by Mike Kost

After sucking it up and realizing I'd have to learn how to navigate winedbg, I started playing around with the Galactic Civilizations unhandled exception. Some documentation and a few trips through winedbg later, it appears that Gal Civ is throwing a divide-by-zero -----------<snip>--------------- First chance exception: divide by zero in 32-bit code (0x40f2cda8) -----------<snip>--------------- I did a 'bt' next: -----------<snip>--------------- =>1 0x40f2cda8 send_mouse_event+0xc8(hwnd=0x10024, flags=0x8001, posX=0x1fb0000, posY=0x1df, data=0x0, time=0xef3d) [mouse.c:135] in x11drv (0x406cfbb0) 2 0x40f2e010 X11DRV_MotionNotify+0x60(hwnd=0x10024, event=0x406cfc4c) [mouse.c:613] in x11drv (0x406cfbdc) 3 0x40f24e90 .L79+0xa in x11drv (0x406cfc3c) ... stuff ... -----------<snip>--------------- and then did an 'info local' and got: -----------<snip>--------------- send_mouse_event: struct HWND__* hwnd = 0x00010024 (parameter) long unsigned int flags = 0x00008001 (parameter) long unsigned int posX = 0x01fb0000 (parameter) long unsigned int posY = 0x000001df (parameter) long unsigned int data = 0x00000000 (parameter) long unsigned int time = 0x0000ef3d (parameter) unsigned int state = 0x0000004c (local in register ECX) unsigned int state = 0x0000004c (local in register ECX) struct HWND__* hwnd = 0x01faffff (local in register EAX) long unsigned int data = 0x01faffff (local in register EAX) long unsigned int time = 0x0000ef3d (local in register EDI) struct tagINPUT input = 0x40f61028 (local) int width = 0x00000000 (local in register ESI) int height = 0x00000000 (local) -----------<snip>--------------- After digging around in dlls/x11drv/mouse.c (see the bt output), I found: -----------<snip>--------------- int width = GetSystemMetrics( SM_CXSCREEN ); int height = GetSystemMetrics( SM_CYSCREEN ); /* Relative mouse movements seem not to be scaled as absolute ones */ posX = (((long)posX << 16) + width-1) / width; posY = (((long)posY << 16) + height-1) / height; -----------<snip>--------------- The posX and poxY calculations are the only divides in the send_mouse_event function (pointed to by the bt as the stack location when the divide-by-zero occurred). The 'info local' confirms that width and height are indeed 0. My problem is that I do not think GetSystemMetrics should be returning 0. The display is quite chorked up by the time the unhandled exception occurs, so I'm pretty sure something bad has already happened; I just don't know what. If any x11drv experienced folk can provide pointers or insight, I'd greatly appreciate it. Mike Kost mike -at- tashcorp.net

19 years, 10 months

problem with linkage of so under RHEL3

by Bill Medland

Guys (I'll be looking into it tomorrow but I thought I'd see if anyone already knows) Command line application opens a dll using LoadLibrary. That Dll links to odbc odbc uses unixODBC to link to the new Oracle 10g Beta ODBC client. That client so access rather a lot of Oracle libraries Relocation error occurs /usr/local/bin/wine-pthread: relocation error: /opt/oracle/product/10.1.0/client_1/lib/libsqora.so: undefined symbol: SQLGetPrivateProfileString The application can also be built under Linux, as can "That Dll" and link directly to unixODBC. Under that configuration it works fine. In all the messing about with the threading etc can anyone think immediately of where we might have messed up the linking? (Wine is rather old - cvs compile of about 20040408) -- Bill Medland mailto:[email protected] http://webhome.idirect.com/~kbmed

19 years, 10 months

FW: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier

by Krishna Murthy

Alexandre, Is these changes looks good? Do I have to submit this patch to 'wine-patches(a)winehq.org' ? Thanks, Krishna -----Original Message----- From: Krishna Murthy Sent: Tuesday, June 22, 2004 2:56 PM To: 'Alexandre Julliard'; Krishna Murthy Cc: wine-devel(a)winehq.org Subject: RE: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier Alexandre, Please find attached modified patch. The method DEFDLG_SetDefButton() now accepts the BOOL bSetDefID parameter to adapt for both DM_SETDEFID and WM_NEXTDLGCTL. Thanks, Krishna -----Original Message----- From: Alexandre Julliard [mailto:[email protected]] Sent: Friday, June 18, 2004 10:30 AM To: Krishna Murthy Cc: wine-devel(a)winehq.org Subject: Re: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier Krishna Murthy <Krishna.Murthy(a)guptaworldwide.com> writes: > No, it is required. The DEFDLG_SetDefButton() is also called from > message DM_SETDEFID. In this case idResult should set to the default > button ID passed. And the current logic of DEFDLG_SetDefButton() does > what is required for DM_SETDEFID. Well, of course you'd need to adapt the DM_SETDEFID handling to the change. I think that's better than sending duplicate messages. -- Alexandre Julliard julliard(a)winehq.org

19 years, 10 months

does wineshelllink work for use with GNOME?

by Santosh Siddheshwar

Hi, Does anybody know of the issues when making shortcuts on the main menu on GNOME (redhat 9)? It seems to me that the .desktop files are created under the right folder ($HOME/.gnome/apps) but the shortcuts dont appear on the menu. As far as I could figure the way to go about adding to the main or system menu is to make entries in the Applications.directory file in /etc/X11/desktop-menus and then have your app .desktop files in /usr/share/applications. Why dont the .desktop files under $HOME/.gnome/apps show up on the menu? Any other ideas? Similarly on redhat 9 for KDE the shortcuts seem to be required to be under $HOME/.kde/applnk-redhat but wineshelllink puts them in applnk folder. Is this correct? Thanks in advance! Santosh Siddheshwar ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

19 years, 10 months

← Newer
1
2
3
4
5
6
7
8
...
24
Older →

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 June 2004