- wine-devel - winehq.org

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

Re: Second try for GetCalendarInfo
by Andreas Mohr 12 May '02

12 May '02

On Sat, May 11, 2002 at 11:35:47PM -0400, Vincent Béron wrote: > There's still a couple of things unimplemented, as I don't have access > to a compiler able to produce working code on Windows for me to get the > missing data. (VC98 bails out on _GetCalendarInfoA, and it's the only > one I have easy access to). Err, "man GetProcAddress" ? :-) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.arcor.de/andi.mohr/

3 2

Re: patch for the ldconfig fix in latest snapshot
by Tony Lambregts 12 May '02

12 May '02

Dustin Navea wrote: [snip] >--- tools/wineinstall Sat May 4 13:31:24 2002 >+++ tools/wineinstall.new Sat May 11 01:19:04 2002 >@@ -319,7 +319,9 @@ > # to our sucommand string > if [ -f /etc/ld.so.conf ] > then >- if [ ! grep -qs "$libdir" /etc/ld.so.conf ] >+ # why were there brackets around this? it wasn't evaluating >+ # correctly because of them! -Dustin Navea > Doh!... The previous two lines should not be in the patch . If it was applied it would make for very strange reading. Please re-submit without them. >+ if ! grep -qs "$libdir" /etc/ld.so.conf > then { > echo > echo "$libdir doesn't exist in your /etc/ld.so.conf, it will be added" > > lookingoveryourshoulder Tony Lambregts

3 2

Making wine complain if profile dir isn't valid
by Paul Millar 12 May '02

12 May '02

Hi, Got caught out by a "gotcha", where %USERPROFILE% was not mapped into the correct directory because the directory didn't exist. A valid %USERPROFILE% is a requirement of one of Juergen regression tests (%USERPROFILE%\\subdir1 > 25). The attached patch will make wine emit a warning if the directory isn't valid. This is "the right thing", isn't it? ChangeLog: Wine now warns if Profile directory doesn't exist. ---- Paul Millar

1 0

Running unit tests on Windows
by Jakob Eriksson 12 May '02

12 May '02

The http://www.codeweavers.com/about/news/talks/wineconf2002/regression/Slide17… talks about compiling on Windows with proprietary compilers. Since I've seen on this list ideas about compiling with mingw on Windows instead. Shouldn't it be possible to cross-compile with mingw on Linux instead? That way the samba share would also keep the .EXE files, and life would be much simpler... just a thought. what do you all think? -- regards, Jakob Eriksson The wages of sin is debugging. -- Ron Jeffries

5 19

(no subject)
by Paul Millar 12 May '02

12 May '02

Hi, I've tried to get wine to compile under a 2.2.17 kernel machine (w/ RedHat 7.0), not particularly because of Stefan's problems under RH-5.2, but trying to track down some other bugs (although hopefully the patches will help a little :) The first stumbling block was in dlls/ntdll/cdrom.c. Two routines in the file try to set members of the cdrom_generic_command structure (defined in linux/cdrom.h) that don't exist in 2.2.x kernels, but do exist in 2.4.x kernels. The attached patch adds configure checks for these structure members and puts "#ifdef"s around the assignments in dlls/ntdll/cdrom.c . I don't know the knock-on effects for not setting these values, but presumably getting something to work is better than wine not compiling :) On a point of style, should there be one test for these two structure members, or two independent tests? The members appear in the kernel at the same time (2.2.x -> 2.4.0) ChangeLog: Towards fixing compilation under 2.2.x kernels NB both configure and include/config.h.in need to be regenerated. ... but, the problems didn't stop there. The compilation continues until it starts to use wmc, which core-dumps on the /second/ usage. ------------------------[ Compilation log ]--------------------------- [...] make[2]: Leaving directory `/scratch/remus1/paulm/wine/dlls/ntdll' rm -f ntdll.dll.so && ln -s ntdll/ntdll.dll.so ntdll.dll.so rm -f libntdll.dll.so && ln -s ntdll/ntdll.dll.so libntdll.dll.so make[2]: Entering directory `/scratch/remus1/paulm/wine/dlls/kernel' LD_LIBRARY_PATH="../../library:../../unicode:$LD_LIBRARY_PATH" ../../tools/wmc/wmc -i -H /dev/null -o messages/winerr_enu.mc.rc messages/winerr_enu.mc DEBUG: setting up handler DEBUG: getting time DEBUG: cmdlen=72 LD_LIBRARY_PATH="../../library:../../unicode:$LD_LIBRARY_PATH" ../../tools/wrc/wrc -I. -I. -I../../include -I../../include -o kernel.res -r kernel.rc make[2]: *** [kernel.res] Segmentation fault (core dumped) make[2]: Leaving directory `/scratch/remus1/paulm/wine/dlls/kernel' make[1]: *** [kernel/kernel32.dll.so] Error 2 make[1]: Leaving directory `/scratch/remus1/paulm/wine/dlls' make: *** [dlls] Error 2 [paulm@mowgli wine]$ ------------------------------[ End of log ]------------------------- The DEBUG output above was from the following patch: --- wmc.c 10 Mar 2002 00:24:24 -0000 1.3 +++ wmc.c 11 May 2002 19:49:33 -0000 @@ -125,8 +125,10 @@ int i; int cmdlen; + printf( "DEBUG: setting up handler\n"); signal(SIGSEGV, segvhandler); + printf( "DEBUG: getting time\n"); now = time(NULL); /* First rebuild the commandline to put in destination */ @@ -134,6 +136,7 @@ cmdlen = 4; /* for "wmc " */ for(i = 1; i < argc; i++) cmdlen += strlen(argv[i]) + 1; + printf( "DEBUG: cmdlen=%u\n", cmdlen); cmdline = (char *)xmalloc(cmdlen); strcpy(cmdline, "wmc "); for(i = 1; i < argc; i++) so, wmc is crashing before it is running main(), suggesting some linking problem? The machine is running glibc 2.2.4 (via RedHat RPM glibc-2.2.4-18.7.0.3) and I was compiling with the alleged "v2.96" release of gcc (RPM gcc-2.96-85). Any ideas? Cheers, ---- Paul Millar

3 3

Uninstaller problem on mingw port
by Steven Edwards 12 May '02

12 May '02

Hello Jeremy, Andi suggested I email you about my issues with uninstaller under mingw. The main unstaller window will render but be blank and then the program will crash when it gets to this line /*---------------------------------------------------------------------- -- ** Handle requests just to list the programs **---------------------------------------------------------------------- */ if (cmdline && strlen(cmdline) >= 6 && memcmp(cmdline, "--list", 6) == 0) I have inserted debugging code at every line around this point but it never makes it to the next messagebox. Do you see anything that might explain it? Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

2 2

Re: PATCH: Preliminary DMA and SOUNDBLASTER emulation
by Dustin Navea 12 May '02

12 May '02

which sound cards is this meant for? i have a live platinum 5.1, is it to be used by people who _do_ or who _dont_ have sb cards? i must be missing the point, but what is the need for sb emulation? -Dustin __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

3 3

Stubbed implementations and Windows objects
by Ian D. Stewart 12 May '02

12 May '02

I am currently in the process of implementing a stubbed version of ctl3d.dll. For functions that return BOOL, I'm printing a fixme and then returning TRUE. What is the convention for stubbed implementations that return a Windows object (HBRUSH, HWND, etc)? Thanx, Ian

2 2

Re: Little correction to kernel32.spec
by Francois Gouget 12 May '02

12 May '02

On Sat, 11 May 2002, Vincent Béron wrote: > There's a bunch of APIs defined with ptr instead of str/wstr: should I > clean them up also? > > Changelog: > - The definition of GetSystemWideDirectory{A,W} in kernel32.spec had > some ptr args, while they are supposed to be {str, wstr} respectively. This is wrong. These parameters are output parameters. If you declare them as str, then the relay code will print them when the function is called, i.e. before the buffer is initialized. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?

2 1

Re: Little correction to kernel32.spec
by Andreas Mohr 11 May '02

11 May '02

On Sat, May 11, 2002 at 06:04:08PM -0400, Vincent Béron wrote: > There's a bunch of APIs defined with ptr instead of str/wstr: should I > clean them up also? > > Changelog: > - The definition of GetSystemWideDirectory{A,W} in kernel32.spec had > some ptr args, while they are supposed to be {str, wstr} respectively. Wrong. The string buffer is a *return* variable. Thus using str/wstr will simply display useless garbage in relay trace. :-\ -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.arcor.de/andi.mohr/

1 0

Re: Better implementation of GetCalendarInfoA
by Francois Gouget 11 May '02

11 May '02

On Sat, 11 May 2002, Vincent Béron wrote: [...] > Also, I'm not sure how to translate that code to the W version of the > function. Should the W call the A? Or reimplement the same algorithm, > with different string constants and function calls (A vs W)? xxxA should call xxxW. Typically this is done as follows (the NT way): xxxA() { convert input parameters from Ansi to Unicode ret=call xxxW convert return values from Unicode to Ansi return ret; } -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

1 0

Re: Little correction to kernel32.spec
by Eric Pouech 11 May '02

11 May '02

> Changelog: > - The definition of GetSystemWideDirectory{A,W} in kernel32.spec had > some ptr args, while they are supposed to be {str, wstr} respectively. I think we should keep the ptr here... in fact, the difference between str and ptr (in relay trace for 32 bit functions) is that, on entry, str will tell the relay code to trace the string itself, whereas ptr will only trace its address in this case, the API expects a buffer to be filled by the function ([out] in MSDN doc), which means that the string in the argument while entering the function has no meaning only the value contained in the buffer at exit time is of interest so, leaving them as ptr is the thing to do (OTOH the Set???? form of this API needs to have a str) A+

1 0

Re: wineinstall fails after cvs update
by Dustin Navea 11 May '02

11 May '02

--- degs <degs(a)giantblob.com> wrote: > Have to wait until someone removes something from > Wine cvs which would > otherwise cause configure to screw up if 'cvs update > -RdP' didn't remove it I > guess - its one of those > no-non-black-crows-disproving-the-all-crows-are-black > kind of deals :-) > > -- degs what about downloading the latest snapshot? 20020509 is out. dl it and then cvs update -RdP wine...i didnt have any problems doing it that way... the only time you ever need to use cvs checkout is when you are downloading it for the first time... the rest of the time use cvs update -RdP wine... __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 0

Re: wineinstall fails after cvs update
by Dustin Navea 11 May '02

11 May '02

--- degs <degs(a)giantblob.com> wrote: > On Saturday 11 May 2002 21:30, you wrote: > > try doing cvs update -RdP wine > > > > and see if configure fails after that... > > thanks > -- degs > > > > __________________________________________________ > > Do You Yahoo!? > > LAUNCH - Your Yahoo! Music Experience > > http://launch.yahoo.com > did it work? :) -Dustin __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 0

wineinstall fails after cvs update
by degs 11 May '02

11 May '02

Hi, I find tools/wineinstall frequently fails in ./configure when trying to rebuild Wine after a "cvs update". I only seem to be able to fix this by blowing away the whole tree and re-fetching it with "cvs checkout". Is wineinstall the Right Way to build Wine when one is trying to hack on it? thanks -- degs PS: I know hardly anything about autoconf (shudder) and absolutely *zero* about CVS :-(

6 8

FindFirstFile
by Insyde 11 May '02

11 May '02

Hi, I looked for the APIs wine had already implemented, but I didn't find, so I'll post this. I getting error with this API FindFirstFile. Wine does not show all of the attributes, not like Windows do. I made a program that reads from the command line the file you're looking for and displays all the attributes from the API. I've compared both runnings. Wine results are different from the Windows. Wasn't that API fully implemented? If so, why is the results differents? thanks, Ricardo.

11 17

strange errors to me
by Lonnie Cumberland 11 May '02

11 May '02

Hello All, I was trying to install TCL 8.4. The install went all the way through and said "installation completed" via their installer, but then the last window to popup from the installer froze up wine. I was then able to get these error messages from a program called "OpenVision" and I do not know what they mean is wrong. I was able to get these messages. -------------------------------------------------------------- err:font:AddFontFileToList Unable to load font file "/c/windows/Fonts/desktop.ini" err = 55 err:font:AddFontFileToList Already loaded font L"Garamond" L"Bold" err:font:AddFontFileToList Already loaded font L"Garamond" L"Italic" err:font:AddFontFileToList Already loaded font L"Garamond" L"Regular" err:font:AddFontFileToList Unable to load font file "/c/windows/Fonts/modern.fon" err = 2 err:font:AddFontFileToList Unable to load font file "/c/windows/Fonts/Mtsorts.ttf" err = 2 err:font:AddFontFileToList Unable to load font file "/c/windows/Fonts/roman.fon" err = 2 err:font:AddFontFileToList Unable to load font file "/c/windows/Fonts/script.fon" err = 2 err:font:AddFontFileToList Unable to load font file "/c/windows/Fonts/SFMAOFRG.PFM" err = 2 err:font:AddFontFileToList Unable to load font file "/c/windows/Fonts/SFMATEXT.PFM" err = 2 fixme:commctrl:InitializeFlatSB stub fixme:commctrl:FlatSB_SetScrollProp stub fixme:commctrl:FlatSB_SetScrollProp stub fixme:commctrl:FlatSB_SetScrollProp stub fixme:commctrl:FlatSB_SetScrollProp stub fixme:richedit:RICHED32_WindowProc Unknown message 0x0081 fixme:richedit:RICHED32_WindowProc Unknown message 0x0210 fixme:richedit:RICHED32_WindowProc Unknown message 0xbe10 fixme:richedit:RICHED32_WindowProc Unknown message 0xb012 fixme:richedit:RICHED32_WindowProc Unknown message 0xbe10 fixme:richedit:RICHED32_WindowProc Unknown message 0x0082 fixme:commctrl:FlatSB_SetScrollProp stub fixme:commctrl:FlatSB_SetScrollProp stub fixme:commctrl:FlatSB_SetScrollProp stub fixme:commctrl:FlatSB_SetScrollProp stub fixme:commctrl:FlatSB_SetScrollProp stub fixme:commctrl:FlatSB_SetScrollProp stub fixme:commctrl:FlatSB_SetScrollProp stub fixme:commctrl:FlatSB_SetScrollProp stub wine: Unhandled exception, starting debugger... Warning: /usr/local/bin/winedbg.exe not accessible from a configured DOS drive Warning: /usr/local/bin/winedbg not accessible from a configured DOS drive Warning: /usr/local/bin/winedbg 134657448.exe not accessible from a configured DOS drive Warning: /usr/local/bin/winedbg 134657448 not accessible from a configured DOS drive Warning: /usr/local/bin/winedbg 134657448 60.exe not accessible from a configured DOS drive Warning: /usr/local/bin/winedbg 134657448 60 not accessible from a configured DOS drive err:seh:start_debugger Couldn't start debugger ("/usr/local/bin/winedbg 134657448 60") (2) Read the Wine Developers Guide on how to set up winedbg or another debugger fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet. ------------------------------------------------------------- Does anyone have any ideas on how to fix these? Any help would be greatly appreciated. Lonnie

3 3

Re: DPMI RawModeSwitch, return to protected mode fix
by Joerg Mayer 11 May '02

11 May '02

On Sat, May 11, 2002 at 05:23:39PM +0300, Jukka Heinonen wrote: > + /* > + * FIXME: This routine will not work if it is called > + * from 32 bit DPMI program and the program returns > + * to protected mode while ESP or EIP is over 0xffff. > + * FIXME: This routine will not work if it is not called > + * using 16-bit-to-Wine callback glue function. > + */ Shouldn't these be FIXME("...") or an ERR()? That way people would know immediatly why their program failed. Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

1 0

TCL 8.3 installs?
by Lonnie Cumberland 11 May '02

11 May '02

Hello All, I was just wondering if anyone has had any troubles getting TCL 8.3 to install under Wine? I tried, but it froze up. I will try again tomorrow and hopefully be able to get some error messages to report to the group, ok. Cheers, Lonnie

1 0

Internationalisation (bug #452)
by Sylvain Petreolle 11 May '02

11 May '02

Hi, I'm currentlly converting winhelp for NLS use. I have to problems to use Va.rc,since I don't know whis country this file is associed to. (probably due to the fact I was asleep in history & geography :) ). I looked in dlls/kernel/nls but didn't see it. Can someone help ? ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

7 10

Re: PATCH: imaadp32.acm
by Eric Pouech 10 May '02

10 May '02

Marcus Meissner a écrit : > > On Fri, May 10, 2002 at 07:57:16PM +0200, Marcus Meissner wrote: > > Hi, > > > > This implements an empty stub for DriverProc, until we have something here. > > (So we don't crash loading this driver.) > > Or better, just drop the whole thing. I have an IMA ADPCM ready for inclusion (with decoding and encoding ready). I may have time to send it tonight (with a ton of other stuff I have in my tree), so don't bother with this patch A+

1 0

Regression in CreateDIBSection
by Mehmet YASAR 10 May '02

10 May '02

Hi, the following patch incorporated in CVS may 3rd has broken BabyGammon (you can get it at http://www.directfichiers.com/babygammon/BAFR100DOGT90.EXE ) With it I have black background instead of the normal backgammon game. If somebody could look at this ... Mehmet YASAR Extract from logs : .... 08073078:Call user32.LoadImageA(00400000,0000006a,00000000,00000000,00000000,00002000) ret=00407f17 08073078:Call x11drv.CreateDIBSection(403844f4,403bb334,00000000,00000000,00000000,00000000,00000000) ret=407b4ac2 trace:bitmap:X11DRV_DIB_CreateDIBSection format (114,19), planes 1, bpp 8, size 2204, colors 256 (RGB) 08073078:Call x11drv.GetDeviceCaps(403844f4,0000000c) ret=407b173b 08073078:Ret x11drv.GetDeviceCaps() retval=00000010 ret=407b173b 08073078:Call x11drv.GetDeviceCaps(403844f4,0000000e) ret=407b173b 08073078:Ret x11drv.GetDeviceCaps() retval=00000001 ret=407b173b trace:bitmap:CreateBitmap 114x19, 65536 colors returning 00000870 trace:bitmap:X11DRV_DIB_DoProtectDIBSection Changed protection from 4 to 4 08073078:Ret x11drv.CreateDIBSection() retval=00000870 ret=407b4ac2 .... Index: wine/graphics/x11drv/dib.c diff -u wine/graphics/x11drv/dib.c:1.91 wine/graphics/x11drv/dib.c:1.92 --- wine/graphics/x11drv/dib.c:1.91 Wed Apr 24 16:32:11 2002 +++ wine/graphics/x11drv/dib.c Sat May 4 13:32:48 2002 @@ -5793,16 +5793,8 @@ InitializeCriticalSection(&(dib->lock)); if (VIRTUAL_SetFaultHandler(bm.bmBits, X11DRV_DIB_FaultHandler, (LPVOID)res)) { - if (section || offset) - { - X11DRV_DIB_DoProtectDIBSection( bmp, PAGE_READWRITE ); - if (dib) dib->status = DIB_Status_AppMod; - } - else - { - X11DRV_DIB_DoProtectDIBSection( bmp, PAGE_READONLY ); - if (dib) dib->status = DIB_Status_InSync; - } + X11DRV_DIB_DoProtectDIBSection( bmp, PAGE_READWRITE ); + if (dib) dib->status = DIB_Status_AppMod; } }

2 2

Re: wine/ ./configure ./configure.ac include/confi ...
by Joerg Mayer 10 May '02

10 May '02

On Thu, May 09, 2002 at 08:33:41PM -0500, Alexandre Julliard wrote: > Log message: > Steven Edwards <Steven_Ed4153(a)yahoo.com> > Detect snprintf && _snprintf, use _snprintf on stupid platforms > (windows). I'm afraid that this is the wrong solution to this problem: People using sNprintf do this sometimes for security reasons. Just ignoring the length is very likely to cause some problems with applications that would have been otherwise secure (I'm thinking of chatclients etc). snprintf should either be implemented or the application simply should not work, but making a secure app insecure is not the way to go. ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

2 2

Request For Comments: emulation of Windows file attributes on POSIX
by Jakob Eriksson 10 May '02

10 May '02

I filed a bug that comments Wine can't create a HIDDEN file, so that Wine does not later find it with FindFirstFile(). http://bugs.winehq.com/show_bug.cgi?id=660 there was a little discussion there and I suggested a) a mode where Wine reads the special info from VFAT and NTFS filesystems. (linux kernel enhancement probably necessary) b) for POSIX filesystems, an emulation layer where Wine emulates the attributes by storing them in a special file in each directory. Andriy Palamarchuk commented with this: There are plans on integration with Samba and this functionality can be implemented there for communication with Windows machines. However, I can't decide whether it is worth to implement these features for Posix file system. I suggest you to discuss the matter on wine-devel. Is it worth it at all? Is it worth it if I implement it as a Wine learning exercise and all you Wine demigods have to do is either say "ok" or "bad, to slow, let's ditch it" or whatever. I don't understand that about Samba integration. Can they read the special attributes on VFAT and NTFS? Are they planning to emulate it? -- regards, Jakob Eriksson The wages of sin is debugging. -- Ron Jeffries

2 1

A little configure change help needed for the mingw/msys port.
by Steven Edwards 09 May '02

09 May '02

Preface: If you have the time to help thanks, if not I will keep fighting with it and should be able To get it sooner or latter and thanks anyway. After the recent patch for cygwin I found the 2 changes I need to make to configure/configure.ac for a mingw host/target but I'm having trouble with the syntax of configure to get it to do what I need it to do. My current porting work has been based on some dirty hacks to configure that didn't Really fix the problem without breaking the checks for other platforms. Now I just need some help making These 2 changes. Change #1. at line 5552 its checking for dlopen which I think is in dlfcn.h. Mingw doesn't have this and I don't think the mingw port needs this but configure returns. else LIBEXT="a" fi This of course causes configure to bomb because we need to build a dll/so. I cant get my syntax right To let it know not to set LIBEXT=a here if it's a mingw host. Change #2 On line 9465 there is the $LIBEXT = so/$target_os *cygwin* check. If I make Change #1 via my dirty breaking of configure and I change the case $target_os to *mingw* then it generates My makefiles right. My problem is really stupid because if I copy the cygwin check and make a mingw check It bitches about unexepected EOF in the configure script where I'm just missing a if/fi or something. Like I said, its really minor. Once this is done then you should at least be able to ./configure on msys just like cygwin if they fix the dlltool/wrap on msys. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

2 2

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