wine-devel

wine-devel@winehq.org

10 participants
84459 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

Bug 677 - gather more information on initial bug submission
by Andriy Palamarchuk 14 May '02

14 May '02

I suggest set of changes to use bugzilla more efficiently and gather more detailed information on initial bug submission. See: http://wine.codeweavers.com/bugs/show_bug.cgi?id=677 Part of the suggestions is a form to gather detailed information: http://wine.codeweavers.com/bugs/showattachment.cgi?attach_id=95 Andriy __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

2 1

PATCH: Property sheet bugfixes (Odin)
by Sander van Leeuwen 14 May '02

14 May '02

Changelog: - Center property sheet page during creation (padding) (some applications rely on this behaviour when resizing the page) - Mask away WS_THICKFRAME page style Author: Sander van Leeuwen/Odin (sandervl(a)xs4all.nl) Changelog: - Page navigation by resource id Author: Unknown. (Corel Wine or very old Wine version)

1 0

wwn doesn't work in konq
by Michael Cardenas 14 May '02

14 May '02

I guess that JeremyN, or whoever it is that does WWN, reads it in IE under wine. ;-) This weeks issue isn't readable in konqueror 2.2.2. The boxes with the content are cut off on the right hand side.

3 2

Re: Fix for commdlg on Mingw
by Dmitry Timoshkov 14 May '02

14 May '02

"Steven Edwards" <Steven_Ed4153(a)yahoo.com> wrote: > Changelog: Fix for commdlg. Mingw stdlib.h defines wcstol so we check > for it and use it else we use the normal wine one. I don't think that it's a good idea. Apparently Mingw uses msvcrt.dll as its C run-time library and wcstol is imported from there. It would be much better to use functions provided by Wine dlls as much as possible. Especially in the cases when wcstol is imported by kernel, user or gdi, which certainly could not import msvcrt.dll, but must rely on the functionality provided by ntdll instead. By the way, do you have a plan for using low level functionality provided by an underlying system such as selector management, process and thread creation and similar things? -- Dmitry.

4 8

Breakdown and Status of wine/dlls on the mingw port
by Steven Edwards 14 May '02

14 May '02

Ok folks here is the break down of the results from my attempt build most of wine/dlls on mingw. You can build almost all of the object files for every wine/dll but cannot link currently due to the Makefiles looking for a ntdll and libwine import. I did not attempt to build any of the low-level wine dlls like msvcrt,crt,gdi,user or ntdll as it would pointless right now. Also I didnt waste my time on any dlls that were just stubs so one of them may import ntdkk.h and suffer from the prototype conflict problem. You have 3 sets of Results. 1. prototypes conflict - wcstol is the main problem. _wtoi is the only other problem. Who is the current libwine_unicode person to talk to about making the changes Alexandre suggested? 2. "unixisms" - I'm not going in to the debate about how to work around this yet. 3. No Problems (all objects compile with no errors/warnings) I'm not counting the (snprintf warning)'s or the TWAIN.DLL warnings as a bug because I will be fixing those problems in my next set of patches. 1)----------------prototypes conflict---------------------------------------------- comctl32 - (snprintf warning) comctl32undoc.c:70: conflicting types for `_wtoi' /usr/include/mingw/stdlib.h:284: previous declaration of `_wtoi' make: *** [comctl32undoc.o] Error 1 In file included from ipaddress.c:31: ../../include/ntddk.h:762: conflicting types for `wcstol' /usr/include/mingw/stdlib.h:290: previous declaration of `wcstol' make: *** [ipaddress.o] Error 1 commdlg - (snprintf warning) In file included from filedlg95.c:59: ../../include/ntddk.h:762: conflicting types for `wcstol' /usr/include/mingw/stdlib.h:290: previous declaration of `wcstol' filedlg95.c: In function `FILEDLG95_HandleCustomDialogMessages': filedlg95.c:799: warning: implicit declaration of function `snprintf' make: *** [filedlg95.o] Error 1 ole32 - In file included from stg_stream.c:32: ../../include/ntddk.h:762: conflicting types for `wcstol' /usr/include/mingw/stdlib.h:290: previous declaration of `wcstol' make: *** [stg_stream.o] Error 1 oleaut - In file included from tmarshal.c:43: ../../include/ntddk.h:762: conflicting types for `wcstol' /usr/include/mingw/stdlib.h:290: previous declaration of `wcstol' make: *** [tmarshal.o] Error 1 psapi - In file included from ../../include/wine/server_protocol.h:11, from ../../include/wine/server.h:27, from psapi_main.c:24: /usr/include/mingw/stdlib.h:290: conflicting types for `wcstol' ../../include/ntddk.h:762: previous declaration of `wcstol' setupapi - In file included from parser.c:30: ../../include/ntddk.h:762: conflicting types for `wcstol' /usr/include/mingw/stdlib.h:290: previous declaration of `wcstol' make: *** [parser.o] Error 1 2)-----------"unixisms" below --------------------------------------------------------- shell32 - (snprintf warning) shelllink.c: In function `IPersistFile_fnSave': shelllink.c:687: warning: implicit declaration of function `fork' shelllink.c:719: warning: implicit declaration of function `execvp' shelllink.c:723: warning: implicit declaration of function `waitpid' netapi32 - netapi32.c:37: sys/ioctl.h: No such file or directory mpr - wnet.c:24: pwd.h: No such file or directory rpcrt - rpcrt4_main.c:43: sys/ioctl.h: No such file or directory 3)-----------No Real Problem thus far--------------------------------------------------- twain32 - twain.h:59: warning: `WIN32' redefined *Initialization*:1: warning: this is the location of the previous definition twain.h:60: warning: `_WIN32' redefined *Initialization*:1: warning: this is the location of the previous definition twain.h:61: warning: `__declspec' redefined *Initialization*:1: warning: this is the location of the previous definition msacm - All Objects compile (snprintf warning) serialui - All Objects compile (snprintf warning) msdmo - All Objects compile msvideo - All Objects compile odbc32 - All Objects compile urlmon - All Objects compile version - All Objects compile shlwapi - All Objects compile tapi32 - All Objects compile shdocvw - All Objects compile rasapi - All Objects compile richedit - All Objects compile ddraw - All Objects compile dinput - All Objects compile dplayx - All Objects compile dsound - All Objects compile imagehlp - All Objects compile imm32 - All Objects compile lzexpand - All Objects compile mapi32 - All Objects compile olecli - All Objects compile oledlg - All Objects compile olesrv - All Objects compile

1 0

Rebuilding configure
by Ian D. Stewart 14 May '02

14 May '02

Howdy Folks, Still working through 'IMPLEMENTING A NEW DLL'. Step 4 states: You can now regenerate ./configure file (with 'make configure') and the various Makefiles (with 'configure; make depend') (run from the top of Wine's tree). You shall now have a Makefile file in ./dlls/<MyDll>/ Problem is, there is no 'configure' rule in the top-level Makefile. According the comments at the top of configure.ac, the proper way to generate a new configure script is to run autoconf. In order to bring DEVELOPERS-HINTS up-to-date, should I replace 'make configure' in Step 4 with autoconf, or should I add a 'configure' rule to Makefile.in that depends on configure.ac and calls autoconf? Thanx, Ian

1 0

Update 'IMPLEMENTING A NEW DLL' in DEVELOPORS-HINTS
by Ian D. Stewart 14 May '02

14 May '02

The attached patch updates Step 3 of 'IMPLEMENTING A NEW DLL' in DEVELOPERS-HINTS with the correct files (and sections of those files) to be modified. Regards, Ian

1 0

Unhandled exception in old DOS application
by M.H.VanLeeuwen 14 May '02

14 May '02

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 knows if there is a fix already, any ideas how to fix it? I can send the cardload.exe file if anyone is interested, its 48K. Martin ------------------------------------------------------------------------------------ wine --debugmsg +mmsys,+module,+int21 --managed cardload.exe gives: Major SNIP... trace:int21:ioctlGetDeviceInfo (1) trace:int21:DOS3Call returning: AX=4400 BX=0001 CX=7fea DX=0945 SI=36d7 DI=0448 DS=14b2 ES=102f EFL=000b0286 trace:int21:DOS3Call AX=4400 BX=0000 CX=7fea DX=0945 SI=36d7 DI=0448 DS=14b2 ES=102f EFL=000b0286 trace:int21:ioctlGetDeviceInfo (0) trace:int21:DOS3Call returning: AX=4400 BX=0000 CX=7fea DX=0945 SI=36d7 DI=0448 DS=14b2 ES=102f EFL=000b0286 trace:int21:DOSVM_Int21Handler GET INTERRUPT VECTOR 0x1c wine: Unhandled exception, starting debugger... trace:module:CreateProcessA app (null) cmdline "/usr/local/bin/winedbg 134675656 76" trace:module:get_file_name trying '/usr/local/bin/winedbg' -------------------------------------------------------------------------------------- debugger for cardload.exe in the gives me: WineDbg starting... on pid 806fcc8 No debug information in 32bit DLL 'F:\wine' (0x0804a000) Can't find file for ELF '/home/mhvl/wine' (0x00000000) No debug information in 32bit DLL 'NTDLL.DLL' (0x4005a000) No debug information in 32bit DLL 'KERNEL32.DLL' (0x407c4000) No debug information in 32bit DLL 'ADVAPI32.DLL' (0x40822000) No debug information in 32bit DLL 'GDI32.DLL' (0x40740000) No debug information in 32bit DLL 'USER32.DLL' (0x40629000) No debug information in 32bit DLL 'WINMM.DLL' (0x405b3000) No debug information in 32bit DLL 'X11DRV.DLL' (0x40883000) No debug information in 32bit DLL 'WINEOSS.DRV' (0x40b93000) No debug information in 32bit DLL 'MSACM32.DLL' (0x40bb7000) No debug information in 32bit DLL 'MSACM.DRV' (0x40bac000) No debug information in 32bit DLL 'MIDIMAP.DRV' (0x4036b000) No debug information in 32bit DLL 'WINEDOS.DLL' (0x40ce5000) Unhandled exception: page fault on write access to 0x3c8900b0 in 32-bit code (0x40cf12eb). In 32-bit mode. 0x40cf12eb (WINEDOS.DLL.LoadDosExe+0x113b): movb %al,0x0(%edx) Wine-dbg>bt Backtrace: =>0 0x40cf12eb (WINEDOS.DLL.LoadDosExe+0x113b) (ebp=40e26858) 1 0x40cf1435 (WINEDOS.DLL.LoadDosExe+0x1285) (ebp=40e26890) 2 0x40cec388 (WINEDOS.DLL.EntryPoint+0x2c28) (ebp=40e268b0) 3 0x40ced0d0 (WINEDOS.DLL.EntryPoint+0x3970) (ebp=40e268cc) 4 0x40ce969f (WINEDOS.DLL.GetTimer+0x11f) (ebp=40e268e4) 5 0x40ce85e2 (WINEDOS.DLL.ASPIHandler+0x1132) (ebp=40e26904) 6 0x40ce91df (WINEDOS.DLL.ASPIHandler+0x1d2f) (ebp=40e26934) 7 0x40068495 (NTDLL.DLL.__wine_exception_handler+0x45) (ebp=40e26958) 8 0x40067dc5 (NTDLL.DLL.wine_dbg_log+0x165) (ebp=40e2698c) 9 0x400680ef (NTDLL.DLL.RtlRaiseException+0x147) (ebp=40e26a20) 10 0x40071b0f (NTDLL.DLL.RtlConvertSidToUnicodeString+0x109f) (ebp=40e26b64) 11 0x40ce9359 (WINEDOS.DLL.ASPIHandler+0x1ea9) (ebp=40e26c2c) 12 0x40cf0527 (WINEDOS.DLL.LoadDosExe+0x377) (ebp=40e26f14) 13 0x400d8d5a (KERNEL32.DLL.RestoreThunkLock+0x59a) (ebp=40e26f38) 14 0x400d806c (KERNEL32.DLL.WaitForMultipleObjectsEx+0x44c) (ebp=40e26ff4) Wine-dbg>info stack Stack dump: 0x40e26840 (WINEDOS.DLL.LoadDosExe+0x136690): 40e26848 40e2684c 00007754 000040cf 0x40e26850 (WINEDOS.DLL.LoadDosExe+0x1366a0): 40cf7754 40cf6e0c 40e26890 40cf1435 0x40e26860 (WINEDOS.DLL.LoadDosExe+0x1366b0): 0000003c 00006830 000040e2 0000a60d 0x40e26870 (WINEDOS.DLL.LoadDosExe+0x1366c0): 00000000 3c106630 00006830 000040e2 0x40e26880 (WINEDOS.DLL.LoadDosExe+0x1366d0): 00006840 000040e2 40cf7754 0000003c 0x40e26890 (WINEDOS.DLL.LoadDosExe+0x1366e0): 40e268b0 40cec388 0000003c 00000001 0x40e268a0 (WINEDOS.DLL.LoadDosExe+0x1366f0): Wine-dbg>info reg Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0257 GS:0000 EIP:40cf12eb ESP:40e26840 EBP:40e26858 EFLAGS:00010202( R- 00 I - - 1 ) EAX:0000003c EBX:40cf7754 ECX:00006830 EDX:3c8900b0 ESI:0000003c EDI:00000400 Wine-dbg>

1 0

Re: [PATCH] FIXME: Explain how to un-tar, compile, and install Wine from a tarball.
by Tony Lambregts 14 May '02

14 May '02

william stinson wrote: >Hi > >this is my first patch for wine. It is for the documentation > FIXME: Explain how to un-tar, compile, and install Wine from a tarball. > >I compiled the documentation html and it looks OK (no warnings) > >Best regards >William Stinson (wstinson(a)infonie.fr) > >--- wine-20020509/documentation/getting.sgml Mon May 13 23:00:16 2002 >+++ wine-local/documentation/getting.sgml Mon May 13 23:00:34 2002 >@@ -201,7 +201,22 @@ > one. > </para> > <para> >- FIXME: Explain how to un-tar, compile, and install Wine from a >tarball. >+ To install Wine from a tarball you need to first un-tar the archive. >This >+ will create a subdirectory containing the Wine sources. Using the cd >+ command change the current directory to the top level wine directory >+ and finish the installation using the wineinstall command. >+ A typical installation might look like this: >+ <screen> > cut out the next two lines >+$ su - >+<emphasis><Type in root password></emphasis> > **** >+# cd /home/user >+# tar -xvzf Wine-20020310.tar.gz >+# cd wine-20020310 >+# ./tools/wineinstall >+ </screen> >+ More detailed step by step instructions can be found in the README file >+ in the top level wine directory. Note that to install wine you must be >+ logged in as root. > </para> > > <para></para> > > > > This is wrong as of the last two months. wine is not installed as root, in fact ./tools/wininstall will not run as root . I would suggest this as an alternative. --- wine-20020509/documentation/getting.sgml Mon May 13 23:00:16 2002 +++ wine-local/documentation/getting.sgml Mon May 13 23:00:34 2002 @@ -201,7 +201,22 @@ one. </para> <para> - FIXME: Explain how to un-tar, compile, and install Wine from a tarball. + To install Wine from a tarball you need to first un-tar the archive. + this will create a subdirectory containing the Wine sources. Using the + cd command change the current directory to the top level wine directory + and finish the installation using the wineinstall command. + </para> + <para> + A typical installation might look like this: + </para> + <screen> +# cd /home/user +# tar -xvzf Wine-20020310.tar.gz +# cd wine-20020310 +# ./tools/wineinstall + </screen> + <para> + More detailed step by step instructions can be found in the README file + in the top level wine directory. Note: During Installation you will be + asked for the root password. </para> <para></para> Thankyou for bringing this up. Tony Lambregts

1 0

shortcuts doesn't work under wcmd
by Insyde 13 May '02

13 May '02

Hi, I have a system that's working ok except for one more thing (Property sheet is under tests since Guy sends a patch): It execute an external .pif file. I've noticed that it doesn't work, old stuff, but it still works under win2k. It's used to call a bat. I've compiled wcmd to substitutes cmd as it is a link to a .bat file. I made as a test 3 .bat (1.bat, 2.bat and 3.bat) 1 calls 2 2 calls 3 3 prints "DONE!", pause if i execute $wcmd /c 1 it works just the same as win/dos I have a 123.pif that is a link to 1.bat. I execute: $wcmd /c 123.pif wcmd prints: invalid executable. What could it be? Wasn't .pif support implemented? If not, will it? Thanks, Ricardo.

2 1

RFC: CommDlg changes for bug#344
by Ann and Jason Edmeades 13 May '02

13 May '02

Hello, The attached patch resolves the 4 issues raised in bug #344 plus lots more. However, before submitting to wine-patches I would like comments it. One particular area of concern is that the behaviour of commdlg should be different depending on what release of windows is currently being run. Also attached is the program I used to test it with (commenting out various parts as applicable) What is the correct way of handling this? Should I do this? The msdn talks about win2000 behaviour and win98 behaviour. I have no experience with winME to know how this would work so I assumed 98 behaviour. Same with WinXP, so I assumed Win2K behaviour. The code currently does this: win95 isWin98plus = false isWin2Kplus = false win98 isWin98plus = true isWin2Kplus = false winME isWin98plus = true isWin2Kplus = false win2k isWin98plus = true isWin2Kplus = true winxp isWin98plus = true isWin2Kplus = true Fixed: 1. InitialDir handling and InitialFile handling now agrees with MSDN description, and testing on win2000 appears to agree 2. Filename field not cleared when directory selected/clicked on 3. ofNoValidate field no longer causes traps, and appears to behave as per w2k Comments please? No comments within a few days I'll submit to wine-patches and see how many people I can break! Thanks Jason

1 0

Bug tracking organization
by Andreas Mohr 13 May '02

13 May '02

Hi all, I think our bug tracking is still a bit too chaotic. Thus I intend to get some info on what bug tracking should look like. So far, we've got "Wine 0.9.0 TaskList" and "Wine 1.x WishList" as the two main metabugs. IMHO Wine 0.9.0 TaskList is the main bug for all development work up to Wine 1.0. And Wine 1.x WishList is everything that will definitely not be included in Wine 1.0 (and possibly even more). Now how about the layout of Wine 0.9.0 TaskList ? I'd suggest the following layout: 0.9.0 Presentation metabug Documentation Website Stable packaging (.deb, .rpm, .tar.gz) programs metabug (what WineLib programs to supply ?) GUI metabug window management metabug messaging metabug common controls metabug shell namespace fonts/printing metabug multimedia metabug dsound winmm directx (direct3d etc.) opengl video DLL separation metabug RPC/wineserver metabug OLE metabug (ok, not 100% correct, but main hole is DCOM RPC stuff) lowlevel metabug file system metabug registry profile lzexpand memory management metabug loader metabug PE NE DOS metabug comm metabug winsock wininet, icmp, url, urlmon, snmpapi, mapi32, netapi32 serial TAPI "developer stuff" metabug WineLib winedbg regression testing/test suite metabug msvcrt, msvcrt20, crtdll Misc. metabug (for other stuff) twain, winaspi "others" metabug (in order to deposit bug reports of "alien" wine packages here) Is this structure ok ? How should it be reorganized, what should be changed ? If we get to a final result, then I'll make sure the 0.9.0 bug gets to look like that. OK, on to the next topic: How should we organize the bug work ? We need tons of people to take UNCONFIRMED bugs and make sure that they reach enough quality in order to be reassigned as NEW (I expect ~ 30% of all bugs to get dropped right away). The second line of bug tracking would be experienced developers that are mainly responsible for certain areas (like we already started to discuss). There might even be a third line of "emergency" people for the really tough cases... BTW, I'm currently subscribed to wine-bugs. I guess I'll stay subscribed for a while, and once the initial bug tracking structure is solid and doesn't need special attention, I'll be able to concentrate on specific areas, and then I'll probably unsubscribe. Any comments ? -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.arcor.de/andi.mohr/

5 5

Attn: component owners list
by Andriy Palamarchuk 13 May '02

13 May '02

Please, take a minute to review the list of component owners and give me a feedback privately or throught the mailing list. We need to define component owners to assign bugs to. These people do not necessarily have to fix the bugs forwarded to them, but will have more detailed knowlege about the status of the component, overview progress in bugs fixing. The component owners will receive bugs after they will be processed by the first line of bugs handling, confirmed, probably already researched, with detailed information. Goal of the whole process is to reduce load on you more experienced developers. You won't have to tell "update your Wine distribution" in 100'th time. A few contributors are already doing this for you ;-) So far only a few people took ownership over separate components: * Guy L. Albetelli - common controls * Dustin Navea - wine tools * Andriy Palamarchuk - wine applications List of candidates: * Alexandre Julliard - wineserver, kernel, IPC * Andreas Mohr - documentation, X11 driver * Dimitrie O. Paun - GUI * Laurent Pinchart - copy protection * Hidenori TAKESHIMA - quartz, DirectShow (is the scope too narrow?), DirectX (?) * Dmitry Timoshkov - NLS, Unicode, keyboard I/O * Francois Gouget - COM, OLE * Martin Wick - sockets * Huw Davies - TrueType support, printing Available components: * DOS support * multimedia * console * files * gdi * loader * net Let me know what you would like to work on, if you agree or not agree to own the component, change scope, know good candidates. I don't want to send bug reports to "black hole", assigning them to a person which is not going to work on them. Look forward for your responses. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Mother's Day is May 12th! http://shopping.yahoo.com

12 19

Re: Fix for commdlg on Mingw
by Marcus Meissner 13 May '02

13 May '02

On Sun, May 12, 2002 at 10:45:08PM -0400, Steven Edwards wrote: > I didn't think wcstol should be moved out of ntddk and in to port.h so I > did the patch this way. If this is another thing that we shouldn't work > around I will add it to the bitch list for the mingw developers that I > am sending them in a week or two. If they don't fix things shortly after > that then I submit my end-all-be-all mingw buggy fix patch to you. > > There are only one or two more places where I will need to do this. > > Changelog: Fix for commdlg. Mingw stdlib.h defines wcstol so we check > for it and use it else we use the normal wine one. Unfortunately wcstol exists in Linux. However it is implemented differently. wide characters are 4 Byte here, not just 2. So your patch will most likely break the Linux side of things. Ciao, Marcus

1 0

Pre-regression regression error :)
by Paul Millar 12 May '02

12 May '02

Hi, Looks like the bug picked up in WRT [1] is genuine (I didn't want to post anything until I was reasonably sure). Juergen shlwapi tests, patch http://cvs.winehq.com/patch.py?id=1020973688889206600449146 seem to have uncovered a bug in registry expansion, but strangely only when wine is emulating an NT-like versions of windows. If you do: export WINEOPTIONS="-winver win2k" make testclean test you find two errors in tests/shreg.c: the tests at line 125 and at line 145. But, if the tests are done with wine in a Win95-like mode: export WINEOPTIONS="-winver win95" make testclean test the tests pass. The errors are: > tests/shreg.c:125: Test failed: (21,20) > tests/shreg.c:145: Test failed: (21,20) which suggests an out-by-one error (the value "21" should be "20"). As far as I've tracked the problem, it seems to be with RegQueryValueExA returning the wrong size. Unfortunately I'm rather pushed for time right now, so if anyone fancies getting to the bottom of this, feel free. Cheers, ---- Paul Millar [1] - http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php

1 0

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