May 2004 - Wine-Devel - list.winehq.org

Re: Making a system DLL unavailable (problem with COMMCTRL)

by Eric Pouech

Samuel Audet a écrit : > Hello, > > I have a Windows 3.1 application here that uses the OWL library. I have > problems running it properly, and I have found the following: > http://www.xploiter.com/programming/c/borland/3031.html > > Looking at what wine outputs when I use "WINEDEBUG=dll" or loaddll, I > see that my program tries to load commctrl.dll and always succeeds. The > problem is, I want it not to succeed, since AFAIK, 16 bit COMMCTRL > functionality is not implemented in WINE, and the OWL library has a > backup plan where it emulates some of the controls (like described on > the site above) when it can't find COMMCTRL, which is what it does in > Windows 2000 or XP for example. > > I have confirmed that the COMMCTRL is at the source of the problem by > using one from a Windows 98 installation. Dialogs that are not showing > using WINE's builtin COMMCTRL are now showing (although they are having > sizing problems... anybody might know why?). > > Is there like a "disable" option in the [DllOverrides] section? Or some > other way to disable a system DLL? I can't seem to just be able to > "remove" commctrl.dll since even 32 bits builtin DLL (in this case > comctl32.dll) require the 16 bit counterpart. In this case, when > comdlg32 tries to load, it loads comctl32 and fails because it can't > load commctrl. I don't think it's a good idea to make 32 bits DLL be > dependent of their 16 bit counterpart. one of the things you could try (but that's risky) is to compile wine twice. First time with standard option, second time with disabling compilation of 16 bit part. Then use the commctrl DLL from the second compilation in the first compilation. But you need to do everything by hand. The best solution anyhow is to understand why Wine's commctrl in 16 bit fails and fix it. A+

May 30, 2004

Re: Help with winedbg

by Shachar Shemesh

Eric Pouech wrote: >>> (the latest wine misses the debug information for the .spec.c files, >>> and that's were main is... could you print the name of the file and >>> the exact error message) >> >> >> >> See below. Don't have them at the moment. Is there any workaround? >> What do I do if there is no debug symbols for that part at all. What >> do I do if there are no debug symbols at all? > > that shouldn't stop gdb (not winedbg in this case) from debugging. > Normally, setting a bp on WinMain & running should do the trick. > That's why I wanted to get the exact message to know where it really > comes from. > >> All of the above happened at a client's site. I don't have the info >> on me. I'll be able to retest on Sunday. >> >> In any case, this is the latest wine RPMs running on RedHat 7.3 we >> are talking about. > > ok. Again the simpliest test is to run without ddd, in a one step mode > (without the --no-start flag). > > A+ > Apparently, there is a problem even without gdb at all. Attached is the output for running "winedbg program", with no arguments at all. The system is a RedHat 9 with kernel 2.4.20-31.9, and the latest glibc available from redhat for it. Wine is CVS tip for today. Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/ bash-2.05b$ winedbg StackView/watchdog.exe fixme:console:SetConsoleCtrlHandler (0x40672f48,1) - no error checking or testing yet WineDbg starting on pid a Breakpoint 1 at 0x005e7e90 Can't find file for ELF 'wine-kthread' ((nil)) Loaded debug information from ELF 'wine-pthread' ((nil)) Breakpoint 2 at 0x4000cfc0 Loaded debug information from ELF '/usr/local/lib/libwine.so.1' (0x40017000) No debug information in ELF '/lib/tls/libpthread.so.0' (0x4004c000) No debug information in ELF '/lib/tls/libc.so.6' ((nil)) No debug information in ELF '/lib/libdl.so.2' (0x4005a000) No debug information in ELF '/lib/ld-linux.so.2' (0x40000000) Loaded debug information from ELF '/usr/local/lib/wine/ntdll.dll.so' (0x4005f000) Loaded debug information from ELF '/usr/local/lib/libwine_unicode.so.1' (0x400cd000) No debug information in ELF '/lib/tls/libm.so.6' (0x401c0000) No debug information in ELF '/lib/libnss_files.so.2' (0x40031000) No debug information in ELF '/lib/libnss_nis.so.2' (0x4003d000) No debug information in ELF '/lib/libnsl.so.1' (0x401ff000) Loaded debug information from ELF '/usr/local/lib/wine/kernel32.dll.so' (0x40330000) Loaded debug information from 32bit DLL 'C:\Program Files\company\Bin\StackView\watchdog.exe' (0x400000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x40080000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x40360000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' (0x408f0000) Loaded debug information from ELF '/usr/local/lib/wine/user32.dll.so' (0x40750000) Loaded debug information from ELF '/usr/local/lib/wine/gdi32.dll.so' (0x4085d000) Loaded debug information from ELF '/usr/local/lib/wine/advapi32.dll.so' (0x408d8000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' (0x40870000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x40770000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\IPHLPAPI.DLL' (0x40950000) Loaded debug information from ELF '/usr/local/lib/wine/wsock32.dll.so' (0x40908000) Loaded debug information from ELF '/usr/local/lib/wine/ws2_32.dll.so' (0x40925000) Loaded debug information from ELF '/usr/local/lib/wine/iphlpapi.dll.so' (0x4094a000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WS2_32.DLL' (0x40930000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WSOCK32.DLL' (0x40910000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MPR.DLL' (0x40970000) Loaded debug information from ELF '/usr/local/lib/wine/mpr.dll.so' (0x40968000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\DBGHELP.DLL' (0x409b0000) Loaded debug information from ELF '/usr/local/lib/wine/imagehlp.dll.so' (0x40984000) Loaded debug information from ELF '/usr/local/lib/wine/dbghelp.dll.so' (0x4099d000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\IMAGEHLP.DLL' (0x40990000) err:winedbg:DEBUG_ProcessDBGFile -Unable to peruse .DBG file dll\psapi.dbg No debug information in 32bit DLL 'C:\PROGRAM FILES\company\BIN\STACKVIEW\PSAPI.DLL' (0x731b0000) err:wineconsole:WINECON_Fatal Couldn't find a decent font, aborting Invalid address for breakpoint 1, disabling it Invalid address for breakpoint 2, disabling it Process of pid=0000000a has terminated

May 30, 2004

segfault fault at startup

by terra＠gnome.org

A newly built wine segfaults for me. No args: welinder(a)anemone:~/wine> ./wine Segmentation fault No core. gdb just reports: welinder(a)anemone:~/wine> LD_LIBRARY_PATH=/home/welinder/wine/libs/wine gdb loader/wine ... (gdb) r Starting program: /home/welinder/wine/loader/wine [New Thread 16384 (LWP 28622)] [New Thread 32769 (LWP 28624)] [New Thread 16386 (LWP 28625)] Cannot find user-level thread for LWP 28622: generic error This is with a suse 9.0 system. Ideas? Morten

May 30, 2004

Re: Tainted code in User32?

by Dmitry Timoshkov

"Steven Edwards" <steven_ed4153(a)yahoo.com> wrote: > "However, disassembling NT implementation (WIN32K.SYS) reveals > that........." > in > http://source.winehq.org/source/windows/win.c#L845 > > was introduced in to winehq by the following patch: > http://cvs.winehq.com/cvsweb/wine/windows/win.c.diff?r1=1.61&r2=1.62 > > Does this not violate a clean rooming the implementation? The ReactOS > code is a derived work of the Wine code in the case and if soon then we > have to remove it. You didn't provide full comment and some minds on ros-kernel list already started to distort the meaning of the comment. That patch was a part of the effort running calc.exe from Windows98 under Wine, not just pulling an arbitrary code from MS implementation. And since it was back in old Wine days (commit date: Sat Jun 5 15:23:20 1999) Wine didn't have any testing framework at that time. Here is full changelog for the change: * windows/win.c: Slava Monich <Slava.Monich(a)netmanage.com> o check for both CW_USEDEFAULT and CW_USEDEFAULT16. o if x is CW_USEDEFAULT (or CW_USEDEFAULT16) and y is *not* CW_USEDEFAULT (or CW_USEDEFAULT16) then use y as a second parameter to ShowWindow(). Some apps (CALC.EXE for Win98 is one of them) use this undocumented feature to create hidden window with WS_VISIBLE style set. -- Dmitry.

May 30, 2004

Re: Tainted code in User32?

by Shachar Shemesh

Steven Edwards wrote: >Hello this line: > >"However, disassembling NT implementation (WIN32K.SYS) reveals >that........." >in >http://source.winehq.org/source/windows/win.c#L845 > >was introduced in to winehq by the following patch: >http://cvs.winehq.com/cvsweb/wine/windows/win.c.diff?r1=1.61&r2=1.62 > >Does this not violate a clean rooming the implementation? > I'll remind you that the term "clean room" applies specifically to reverse engineering. "Clean room" means that you reverse engineer the specs out of an existing product, and then use those specs to write a new implementation, without copyright interfering (i.e. - without code being copied as derived work). I'll also remind you that the case that coined the term "clean room", the Olivetty BIOS clone, was 100% disassembly, and was deemed legal. > The ReactOS >code is a derived work of the Wine code in the case and if soon then we >have to remove it. > > If these are the standards you set (i.e. - higher than your own courts), you may have to remove the whole of the wine code altogether. Then again, there is no other way for you to reimplement Win32 code. The only standard Win32 adhers to is set to be "whatever Windows does". Whenever MSDN and Windows disagree, Windows is, per definition, the correct party. How can you find that out? Now, in this case it's a single parameter interpretation that was disassembled out of the code. I don't think that's cause for concern. If large scale disassembly takes place, we try to have the disassembler write the specs in human interpreted language, and then have someone else do the actual implementation. This is, AFAIK, what happened with cards.dll, for example. This follows the clean room doctrine to the letter. Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/

May 30, 2004

broken mingw build

by Kevin Koltzau

This patch http://cvs.winehq.org/patch.py?id=12495 seems to have broken the mingw build, currently getting i386-mingw32msvc-gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -Wall -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o interlocked.o interlocked.c {standard input}: Assembler messages: {standard input}:124: Error: unknown pseudo-op: `.previous' {standard input}:135: Error: unknown pseudo-op: `.previous' {standard input}:145: Error: unknown pseudo-op: `.previous' {standard input}:155: Error: unknown pseudo-op: `.previous' {standard input}:165: Error: unknown pseudo-op: `.previous' make[2]: *** [interlocked.o] Error 1

May 30, 2004

Re: Tainted code in User32?

by Abby Ricart

> "However, disassembling NT implementation (WIN32K.SYS) reveals > that........." ... > Does this not violate a clean rooming the implementation? The ReactOS > code is a derived work of the Wine code in the case and if soon then we > have to remove it. Whoa! Slow down there John Wayne! Disassembly is another healthy part of reverse engineering. And without reverse engineering, you wouldn't have the beautiful thing known as WINE here before you. There were no algorithms lifted from the Windows "code", just the discovery of some undocumented functionality.

May 29, 2004

Making a system DLL unavailable (problem with COMMCTRL)

by Samuel Audet

Hello, I have a Windows 3.1 application here that uses the OWL library. I have problems running it properly, and I have found the following: http://www.xploiter.com/programming/c/borland/3031.html Looking at what wine outputs when I use "WINEDEBUG=dll" or loaddll, I see that my program tries to load commctrl.dll and always succeeds. The problem is, I want it not to succeed, since AFAIK, 16 bit COMMCTRL functionality is not implemented in WINE, and the OWL library has a backup plan where it emulates some of the controls (like described on the site above) when it can't find COMMCTRL, which is what it does in Windows 2000 or XP for example. I have confirmed that the COMMCTRL is at the source of the problem by using one from a Windows 98 installation. Dialogs that are not showing using WINE's builtin COMMCTRL are now showing (although they are having sizing problems... anybody might know why?). Is there like a "disable" option in the [DllOverrides] section? Or some other way to disable a system DLL? I can't seem to just be able to "remove" commctrl.dll since even 32 bits builtin DLL (in this case comctl32.dll) require the 16 bit counterpart. In this case, when comdlg32 tries to load, it loads comctl32 and fails because it can't load commctrl. I don't think it's a good idea to make 32 bits DLL be dependent of their 16 bit counterpart. Thank for any input! -- Samuel Audet <guardia(a)step.polymtl.ca> http://www.step.polymtl.ca/~guardia/

May 29, 2004

Tainted code in User32?

by Steven Edwards

Hello this line: "However, disassembling NT implementation (WIN32K.SYS) reveals that........." in http://source.winehq.org/source/windows/win.c#L845 was introduced in to winehq by the following patch: http://cvs.winehq.com/cvsweb/wine/windows/win.c.diff?r1=1.61&r2=1.62 Does this not violate a clean rooming the implementation? The ReactOS code is a derived work of the Wine code in the case and if soon then we have to remove it. Thanks Steven __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

May 29, 2004

Re: EnumDateFormats patch

by William Lahti

Alexandre Julliard wrote: > Wililam <computerman413(a)ezrs.com> writes: > >> Here is the ChangeLog entry: >> >> * dlls/kernel/lcformat.c >> William Lahti <computerman413(a)ezrs.com> >> >> - Implemented the EnumDateFormatsW function and vastly improved upon the >> EnumDateFormatsA function. > > This stuff clearly needs to be stored as data in the nls resource > files, not in the code. > The original EnumDateFormatsA function had the information in the code. There was simply much less. If I knew how to store *ALL* posible combination in the NLS files rather than the default, I would gladly implement them.

May 29, 2004