wine-devel

wine-devel@winehq.org

2 participants
84479 discussions

Getpagesize in libwine port.c on windows target
by Steven Edwards 15 May '02

15 May '02

I have two fixes for missing getpagesize on windows. Once this is done the only thing that is stopping me from building libwine is the missing refrences to _assert and _errorno. 1. In xemacs they #define getpagesize() 4096 and it seems to work. 2. The other fix would be to use getsystem_info. I just can't make the Getsystem_info workaround to work right. Here is a example. /* getpagesize for windows */ long getpagesize (void) { static long g_pagesize = 0; if (! g_pagesize) { SYSTEM_INFO system_info; GetSystemInfo (&system_info); g_pagesize = system_info.dwPageSize; } return g_pagesize; } "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

1 0

More GDI heap problems: How to report this as bug ?
by Gregor Hoffleit 15 May '02

15 May '02

I try to run the Brockhaus multimedial encyclopedia with Wine (Debian package 0.0.20020411-1). At a certain point (when an article is going to be displayed), the program continuously spits out these messages about the GDI heap being full: ... err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 1048 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 1048 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 1048 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 880 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 1048 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 20 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 20 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 1048 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 20 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 20 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 20 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 20 bytes err:region:CombineRgn Invalid rgn=0000 err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 1048 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 1048 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 20 bytes err:region:CombineRgn Invalid rgn=0000 err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 20 bytes err:region:CombineRgn Invalid rgn=0000 ... The application nearly comes to a hold: with much luck, portions of the display still get updated. I've seen previous reports about this problems, and appearently they are indications of leaks either in Wine's GDI objects or in some other component. How can I help tracking down these specifc leaks ? The leaks are very obvious and very good reproducable. They happen almost immediately after opening the article. I tried "--debugmsg +relay,+local", but after a few seconds, the log file filled up 100MB! I'm no Windows programmer, and I've only little experience with Wine, but if somebody could tell me how to make a proper and helpful bug report and what else could help to track down the problem, I'd be very glad. Please keep me cc'ed, since I'm not subscribed to wine-devel for the moment. Thanks, Gregor

4 5

Component owners 2
by Andriy Palamarchuk 15 May '02

15 May '02

Thanks everybody for the very active feedback. List of developers who contacted me: * Guy L. Albetelli - common controls * Robert 'Admiral' Coeyman - DOS * Huw Davies - TrueType support, printing, gdi * Francois Gouget - Winelib, Winemaker, headers, icmp * Dustin Navea - wine tools * Mike McCormack - file system, serial port, named pipes, SMB * Marcus Meissner - COM, OLE * Andreas Mohr - documentation, installers, memory handling * Andriy Palamarchuk - wine applications * Juergen Schmied - console, file open dialog Developers who has not confirmed nor declined suggestion to own a component: * Alexandre Julliard - wineserver, kernel, IPC * Laurent Pinchart - copy protection * Dmitry Timoshkov - NLS, Unicode, keyboard I/O * Martin Wick - sockets Still available components: * DDE * loader * msvcrt * x11drv * window handling Some developers are interested by areas which are not components per se. For example - Andreas Mohr worked a lot on installers issues and would like installer bugs forwarded to him. The issue will be forwarded to a person who is the most interested in an issue. Everybody else is also welcome to give me your particular areas of interest even if they do not match component boundaries. All the developers, QA engineers who is going to work with Bugzilla, please create an account and request privileges to change bugs status at bugs(a)codeweavers.com. You do not need to subscribe to wine-bugs if you are not planning to work in the first line of the bugs hanlding (handling of bugs with status UNCONFIRMED). Please, let me know if I missed anybody. Other comments are welcome too. Andriy __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

5 8

Re: PlaySound and al.
by tijs＠connectux.com 15 May '02

15 May '02

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > this patch is a rewrite of the playsound functions those were a bit > buggy and proved to fail in some multi-threaded environments the > attached patch should take care of that >snip When selecting a menu-item in MSVC++ 6.0, the loop in MULTIMEDIA_PlaySound() never ends on my system (Debian unstable, no soundcard) as well as on another system (Debian unstable, soundblaster installed). Things worked fine with revision 1.51 of mmsystem.c. Unfortunately, I haven't been able to trace exactly what is going wrong. I will, of course, supply more details when I find something remarkable. Should I report bugs with respect to patches using Bugzilla, or is wine-devel sufficient? I noticed Bugzilla only allows me to select real Wine releases, i.e. 20020509, and not a CVS revision of a certain file. Regards, -- Tijs van Bakel, ConnecTUX, <tijs(a)connectux.com>

3 2

Bugzilla responsibilities (Was Component owners 2)
by Andriy Palamarchuk 15 May '02

15 May '02

I decided to define not also list of component owners, but also people, responsible for triaging and application owners. This additional information will be important for those who work with Bugzilla. I'm going to submit these lists for publishing on Wine Bugzilla pages for easy access. Owners of Components and areas of interest: * Guy L. Albetelli - common controls * Robert 'Admiral' Coeyman - DOS * Chuck Crayne - richedit * Huw Davies - TrueType support, printing, gdi, x11 gdi * Francois Gouget - Winelib, Winemaker, headers, icmp * Alexandre Julliard - wineserver, kernel, IPC, loader, x11drv * Dustin Navea - wine tools * Mike McCormack - file system, serial port, named pipes, SMB * Marcus Meissner - COM, OLE * Andreas Mohr - documentation, installers, memory handling * Andriy Palamarchuk - wine applications * Eric Pouech - multimedia, winedbg, wineconsole, DDE * Juergen Schmied - shell (shell32.dll and shlwapi.dll), file open dialog * Lionel Ulmer - OpenGL, DirectX, Direct3D * Martin Wilck - sockets People in the list below are responsible for fixes confirmation, bugs confirmation, initial research, distribution to developers, prioritization. Please, let me know if you plan to actively work in this area - I'll include you in the list. Bugs triaging: * Tony Lambregts * Andreas Mohr (SWAT team ;-) * Dustin Navea * Andriy Palamarchuk Contributors are wanted! Application owners can provide help in confirming bugs, fixes, assisting developers who do not have access to the application in bugs fixing. Application owners: * Michael Cardenas - Microsoft Office, AOL Application owners are wanted! As always I appreciate your comments. Andriy __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 0

RE: Unhandled exception in old DOS application
by Medland, Bill 15 May '02

15 May '02

> -----Original Message----- > From: M.H.VanLeeuwen [mailto:vanl@megsinet.net] > Sent: Monday, May 13, 2002 7:33 PM > To: wine-devel(a)winehq.com > Subject: Unhandled exception in old DOS application > > > Hi, > > I hope this is the correct place to ask... > > Up until the 20020411 wine release my old DOS application > worked well...for the > last ~2 years. (Thanks all of you!) > With both 20020411 and 20020509 releases the wine issues an > Unhandled exception > report and starts the debugger. > > bash-2.05$ wine cardload.exe -- -a340 > -f"c:\\\winapps\\\winphone\\\cardload.hex" > Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: > Warning: unprotecting the first 64KB of memory to allow > real-mode calls. > NULL pointer accesses will no longer be caught. > wine: Unhandled exception, starting debugger... > err:int:DOSVM_Loop MsgWaitForMultipleObjects returned > unexpected value. > > This application just downloads firmware (cardload.hex) to an > old ISA card. > > What can be done to fix this, where should I begin looking to > fix it, who The first thing I'd do is see which "fix" broke it. That requires getting the code out of the cvs itself. Basically I do an almost binary search between when I know it "worked" and when I know it failed and what area of code was affected. >From your post I presume you don't get the code from the cvs. Do you compile yourself or dowload rpms? Bill

2 1

conflicting types for `usleep' in wine/port.h and libwine/port.c
by Steven Edwards 14 May '02

14 May '02

I don't guess we are building libwine.dll on mingw but I was playing with it just the same when I came to this. Is this to be expected? gcc -mno-cygwin -c -I. -I. -I../include -I../include -D__MINGW__ -D_WINDOWS -DW INE_NOWINSOCK -Wall -mpreferred-stack-boundary=2 -D__WINE__ -DDLLDIR="\"/usr/loc al/lib/wine\"" -D_REENTRANT -o port.o port.c port.c:65: conflicting types for `usleep' ../include/wine/port.h:299: previous declaration of `usleep' Port.h: #ifndef HAVE_USLEEP int usleep (unsigned int useconds); #endif /* !defined(HAVE_USLEEP) */ Port.c: #ifndef HAVE_USLEEP unsigned int usleep (unsigned int useconds) { #if defined(__EMX__) DosSleep(useconds); return 0; #elif defined(__BEOS__) return snooze(useconds); #elif defined(HAVE_SELECT) struct timeval delay; delay.tv_sec = useconds / 1000000; delay.tv_usec = useconds % 1000000; select( 0, 0, 0, 0, &delay ); return 0; #else /* defined(__EMX__) || defined(__BEOS__) || defined(HAVE_SELECT) */ errno = ENOSYS; return -1; #endif /* defined(__EMX__) || defined(__BEOS__) || defined(HAVE_SELECT) */ } #endif /* HAVE_USLEEP */ "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

1 0

Winelib apps and PATH
by Sylvain Petreolle 14 May '02

14 May '02

Hi, Testing wine's control.exe replacements makes me show this : If i remove/rename original control.exe, I can do : $ control and I have the Wine Control Panel as it has been installed in /usr/local/bin. But I cannot do: $ wine control wine: cannot find 'control' So if one app calls for example notepad, the app will try to launch "wine notepad" and fail. Shouldn't we provide a default drive for /usr or /usrlocal/bin in the config file ? This would solve the "can't load winedbg 123456" issue that users usually include in their first reports. (the debugger cannot be launched because it's in /usr/local/bin) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

3 3

configure.in
by Ian D. Stewart 14 May '02

14 May '02

Howdy Folks, I'm walking through 'IMPLEMENTING A NEW DLL' in DEVELOPER-HINTS. Step 3 reads: Add the directory (and the generated .o file for the module) in: + ./configure.in (in AC_OUTPUT macro at the end of the file to trigger the Makefile generation), + ./Makefile.in (in LIBSUBDIRS and LIBOBJS macros) + ./dlls/Makefile.in (in SUBDIRS macro) Far as I can tell, there is no configure.in. The closest I could find is configure.ac. Is this the file that needs to be edited, or am I missing something? Thanx, Ian

3 4

Global Wine configuration file not consulted?
by Gerald Pfeifer 14 May '02

14 May '02

I noticed that in the absence of ~/.wine/config Wine simply refuses to start, and truss (on FreeBSD) and trace (on GNU/Linux) reveal that no other location is consulted for a config file. Even explictly Using ETCDIR or `configure --sysconfdir` doesn't seem to make a difference, even though the documentation indicates otherwise: http://www.winehq.com/Docs/wine-pkg/pkg-nonstatic.shtml#WINERC ETCDIR/wine.conf This is the global Wine configuration file. It is only used if the user running Wine has no local configuration file. % ls -la $ETCDIR/wine.conf -r--r--r-- 1 root wheel 7616 Mar 11 13:59 /usr/local/etc/wine.conf % ls -la /home/pfeifer/.wine/config ls: /home/pfeifer/.wine/config: No such file or directory % wine Can't open configuration file /home/pfeifer/.wine/config Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

3 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