August 2005 - Wine-Devel - list.winehq.org

Re: Delphi 5 debugger is working!

by Kuba Ober

On Tuesday 23 August 2005 20:05, Vitaliy Margolen wrote: > As of todays CVS Delphi 5 debugger is fixed. > > Well, ok, there are still some bugs. One is a minor bug (Module view > reports all modules as a project executable name), but all exports are > there. You can even try to disassemble them. But here is where the major > problems start. Debugger segfaults on that. This is because > NtQueryVirtualMemory and > NtProtectVirtualMemory currently don't work on other processes. What are the problems with implementing those using SIGSTOP/SIGCONT and ptrace(2)? I imagine that for example changing memory protection for another process could be achieved as follows: 1. SIGSTOP to the process 2. inject code that invokes mprotect() and stops execution 3. change EIP, ESP, etc. then SIGCONT 4. wait(pid,&status,WUNTRACED) on the child 5. remove the injected code, restore registers, SIGCONT I have never implemented such a beast so I might be way off, nevertheless it'd be interesting to hear what the problems are. phrack might also be a useful read in that respect. Cheers, Kuba

Aug. 24, 2005

wine error with 'wine client error:d: write: Bad file descriptor'

by Oliver Mössinger

Hi wine-devel, i have a windows program whitch generates the attached 'wine.txt' wine output. Followed is a part of the output: >>> Threads: process tid prio (all id:s are in hex) 00000042 (D) C:\MGC\LeoSpec\LS2005a_82\bin\win32\leonardo.exe 00000017 0 0000000d 0 <== 0000000e 00000016 0 00000013 0 00000012 0 00000011 0 00000010 0 0000000f 0 WineDbg terminated on pid 0x42 wine client error:d: write: Bad file descriptor <<< The program works with windows! Can someone help me to run the program? thanks Oliver Mössinger

Aug. 24, 2005

Re: accessing WRT binaries on the web

by Paul Millar

Hi Saulius, No, this isn't intentional. The cross-building part needs patching so it knows about an additional part of the Win32 API. Nothing new there. But rather than just patching the (somewhat ancient) version of the w32api, I've decided to upgrade to the latest version. This means going through the large number of patches to Win32api figuring out which are now redundant and which are still needed, and fixing the patches so they work again. Once this is done, things should be up and running again. Cheers, Paul. On Tuesday 23 Aug 2005 17:13, Saulius Krasuckas wrote: > Now it seems test are being build daily [1], but none of them shows up on > the web [2] since 2005.08.16. > > Is this intentional state of the system or just some bug had went in it? > > > [1] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php > [2] http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/

Aug. 24, 2005

Re: [Bug 3148] Mouse: multi-file "selection" & drag behavior broken

by Saulius Krasuckas

* On Tue, 23 Aug 2005, Hiji wrote: > --- Vitaly Lipatov <lav(a)etersoft.ru> wrote: > > > Hi, Can you pay attention to this patch? It really fixes the problem > > but not discussed in the list and not applied: > > http://www.winehq.com/hypermail/wine-patches/2005/08/0018.html > > WOOHOO! This fixes "half" the problem with Bug3148. > Once I applied the patch, I no longer had the problem > with the effect of the mouse button being continously > pressed once I clicked on something. ... > So, can someone listen (pay attention) to Vitaly and > apply the patch so at least this bug can get half-way > fixed??? The patch has 2 points to change (I am afraid): a, header of its first section refers to "sysparams.c" and "dlls/user/sysparams.c", which makes patcher to not find needed file (dlls/user/tests/sysparams.c). Command "cvs diff -pu dlls/user/" would do the job. :-P b, first hunk of the second section (dlls/user/sysparams.c) is already in the tree, so it fails too.

Aug. 24, 2005

Re: secur32: Getting real functionality into the NTLM provider

by Alexandre Julliard

Kai Blin <blin(a)gmx.net> writes: > * Alexandre Julliard <julliard(a)winehq.org> [23/08/05, 20:39:52]: > >> You should avoid using stdio. > > How would I do this avoiding stdio? ntlm_auth uses stdin and stdout to > read input and write output. This seems to be the Unix way of doing > things. I mean the stdio functions like fdopen, fgets, etc. They are not guaranteed to be thread-safe because of the way we handle libc threads. It's better to use normal read()/write() instead. -- Alexandre Julliard julliard(a)winehq.org

Aug. 24, 2005

wglMakeCurrent doesn't pick up HDC region

by Russ

Trying to get my commercial 3-D app to run under WINE using the same binary with the odd workaround or two. It uses OpenGL in various subwindows of the main window as needed. Under WINE, the subwindow graphics all get drawn in the lower left corner of the overall X11 window. In Win32, when you call wglMakeCurrent, the opengl context is configured to match the size/position of the HWND for the HDC, so drawing openGL goes just into the desired subwindow. However, the WINE implementation of wglMakeCurrent just calls glXMakeCurrent (and glXCreateContext), which produces the entire size of the X11 window, resulting in the incorrect behavior observed. In my Mac OS X port, I have a similar issue, resolved by calling aglSetInteger(glContext, AGL_BUFFER_RECT,... I'm not sure what a glX equivalent would be to try, I don't see one offhand. As is, emulating the wglMakeCurrent accurately appears impossible, such that apps that use this Windows behavior can not be run. Suggestions welcome. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Aug. 24, 2005

solution for including itss.h in hhctrl.ocx

by James Hawkins

Hey Alexandre, I need to be able to include itss.h from dlls/itss in order to read CHM files. Mike offered the solution that I add -I($SRCDIR)../itss to hhctrl's Makefile.in. The next problem comes when I run make depend. make depend looks for itss.h but can't find it because it hasn't been built yet. Mike then suggested adding ../dlls/itss/itss.idl to IDL_SRCS in include/Makefile.in. That works fine up until make install which gives these two errors: /usr/bin/install: cannot create regular file `/usr/include/wine/windows/../dlls/itss/itss.idl': No such file or directory /usr/bin/install: cannot create regular file `/usr/include/wine/windows/../dlls/itss/itss.h': No such file or directory Do you have any suggestions on how to access itss.h from hhctrl.ocx? -- James Hawkins

Aug. 24, 2005

Re: [Bug 3148] Mouse: multi-file "selection" & drag behavior broken

by Hiji

--- Vitaly Lipatov <lav(a)etersoft.ru> wrote: > Hi, Can you pay attention to this patch? It really fixes > the problem but not > discussed in the list and not applied: > http://www.winehq.com/hypermail/wine-patches/2005/08/0018.html WOOHOO! This fixes "half" the problem with Bug3148. Once I applied the patch, I no longer had the problem with the effect of the mouse button being continously pressed once I clicked on something. However, one problem still remains. If I select 3 items (shift + click from start item to finish item), and I click with the left-mouse, my selection is lost as now only 1 item is selected (the one I clicked on). However, if I right-click, my selection isn't lost. It seems what *should* happen is the following: 1. you make your selection in a listview (2+ items) by using the shiftkey + left-mouse button 2. let go of shiftkey and items are still selected 3. click on one of the highlighted items 4. selection remains intact 5. drag-drop as you wish However, things seem to go amiss at step 3. I can somewhat retain the selection if I keep the shift-key pressed throughout the process -- which is not the norm as I should let go at step 2.. So, can someone listen (pay attention) to Vitaly and apply the patch so at least this bug can get half-way fixed??? Thanks! Hiji --- Hiji <hijinio(a)yahoo.com> wrote: > > > Anybody on this list make any changes to > listview > > or > > > treeview in the last few months? > > I wouldn't even find it hard to believe that they > > already forgot about it... > > > > If you want hard, definitive data, then I I cannot > > find any reason why you > > wouldn't want to look at ChangeLog... > > > How about this: I didn't know about ChangeLog! LOL! > > I'm looking through it now... ;) > > Thanks! > Hiji > > > > ____________________________________________________ > Start your day with Yahoo! - make it your home page > http://www.yahoo.com/r/hs > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Aug. 24, 2005

x11drv: use of uninitialized rect

by James Hawkins

Hey, While compiling x11drv, gcc gives the following error: gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o text.o text.c text.c: In function 'X11DRV_ExtTextOut': text.c:85: warning: 'rect.bottom' is used uninitialized in this function text.c:85: warning: 'rect.top' is used uninitialized in this function text.c:85: warning: 'rect.right' is used uninitialized in this function text.c:85: warning: 'rect.left' is used uninitialized in this function Looking through the CVS log for text.c, I saw that before the latest patch, rect would be initialized if lprect == NULL; otherwise, rect = *lprect. My guess is that we want to use lprect instead of rect, but I'm not familiar enough with that code to make the change. Can you take a look at this Huw? Thanks, James Hawkins

Aug. 24, 2005

Delphi 5 debugger is working!

by Vitaliy Margolen

As of todays CVS Delphi 5 debugger is fixed. Well, ok, there are still some bugs. One is a minor bug (Module view reports all modules as a project executable name), but all exports are there. You can even try to disassemble them. But here is where the major problems start. Debugger segfaults on that. This is because NtQueryVirtualMemory and NtProtectVirtualMemory currently don't work on other processes. I have modified those functions to return STATUS_SUCCESS instead. This allows to access ntdll, kernel32 and possibly any other modules that have the same base address for application and debugger. You might need prelink installed to relocate ntdll and kernel32 to 0x7bxxxxxx addresses. This makes their base addresses the same for all wine apps. Unfortunately fixing NtQueryVirtualMemory, NtProtectVirtualMemory and others is not that simple. Basically there are no way to do it from other processes. Ok, NtQueryVirtualMemory could be implemented some-what easily using NtReadVirtualMemory and possibly one more server call. But for others I see only three ways to implement them: 1. Adding worker thread to each process. This way we can ask it to perform requested operation for us. But, there is a catch - this will complicate lots of things. Besides, messing with processes is not a good thing(tm). It will brake some apps, that don't expect to see more then one thread. Or if we'll try to hide a worker thread, it will make things even worse. 2. Using signal(s). Unfortunately this is not as simple to do ether. From what I been told, this will require non trivial synchronization, that still doesn't guarantee deadlocks. 3. Infamous wine kernel module. Some how I don't think that kernel guys will go for this type of functionality. Even for debugging proposes, it still poses considerable security risk allowing one process manipulate other process' memory. So it will have to be a wine only module, which means we'll have to maintain in against all supported kernel versions and require kernel development environment. Any other solutions that I have forgotten/haven't even thought of? -- Best regards, Vitaliy

Aug. 24, 2005