Re: Really slow named pipes
Duane Clark wrote: That one came through, but unfortunately it did not fix the problem. I will try to see if I can figure out a bit more about how writes to pipes work. Okay, more info about what is happening. It is not a problem of writes being blocked. Instead what I see is: trace:file:CreateFileW Opening a pipe: L".\\pipe\\Win32.Pipes.0014.0001" trace:file:FILE_OpenPipe Returned 0x1c8 trace:file:CreateFileW returning 0x1c8 trace:file:CreatePipe Read 0x1c4 write 0x1c8 ... trace:file:WriteFile 0x1c8 0x40c13768 77 0x40c13b70 (nil) ... trace:file:WriteFile 0x1c8 0x40c13768 75 0x40c13b70 (nil) ... trace:file:WriteFile 0x1c8 0x40c13768 75 0x40c13b70 (nil) ... trace:file:WriteFile 0x1c8 0x40c136ec 83 0x40c13af4 (nil) ... trace:file:WriteFile 0x1c8 0x40c136ec 78 0x40c13af4 (nil) ... trace:file:PeekNamedPipe 0x004d bytes available ... trace:file:PeekNamedPipe 0x004b bytes available ... trace:file:PeekNamedPipe 0x004b bytes available ... trace:file:PeekNamedPipe 0x0053 bytes available ... trace:file:PeekNamedPipe 0x004e bytes available Notice that the number of bytes available in each Peek corresponds exactly with the number that were written in each individual write. What should be happening of course is that the total number of bytes should have been reported in the first peek.
Re: Thank you!
Dustin Navea wrote: bah some of these sobig emails are still getting thru jer I think these have no attachments, though I don't receive the emails directly, so I can't be sure. At least the attachments are not archived; I don't know where they are being stripped. Without the attachment, they won't be caught by the moderation filter if they have a legitimate From email address.
Deleted emails
Ahh..., fun with the Sobig.F virus. I skipped out yesterday to do some scuba diving, and arrived this morning to find about 7000 emails awaiting moderation. Yikes!!! Anyway, Jeremy seems to have fixed things so they are now being blocked. Thanks!!! But rather than trying to go through 7000 postings to find legitimate emails, all pending moderation requests were simply deleted. So if anyone posted something to any of the lists in about the 36 hours or so prior to this morning, and it never showed up, please just resend.
Re: Really slow named pipes
Eric Pouech wrote: oops (took the file from the wrong dir...) That one came through, but unfortunately it did not fix the problem. I will try to see if I can figure out a bit more about how writes to pipes work.
Re: Fwd: Your message to wine-bugs awaits moderator approval
Gregory M. Turner wrote: I don't think I've done anything on wine-bugs lately... what's going on here? -- Forwarded Message -- Subject: Your message to wine-bugs awaits moderator approval Date: Sunday 24 August 2003 05:40 pm From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Your mail to 'wine-bugs' with the subject Thank you! Is being held until the list moderator can review it for approval. Sobig.F is kindly sending emails to the list with your email address forged on them. Sorry about the bounces. I have now disabled the automatic notification; it is already off on the other lists but somehow it was still on on wine-bugs.
Re: Really slow named pipes
Eric Pouech wrote: So the problem appears to be that in the new implementation, the write to the pipe is being blocked on every call, until a read has happened. What should be happening is that the write should only block if the pipe is full. Does that help someone know where to look? does this help ? bash: wine: command not found Nope ;) I think there was a problem when you tried to attach that :-)
Re: Really slow named pipes
Duane Clark wrote: This is a bit old, from May, but anyhow... The patch to implement anonymous pipes on top of named pipes: http://www.winehq.com/hypermail/wine-cvs/2003/05/0305.html along with a corresponding bug fix: http://www.winehq.com/hypermail/wine-cvs/2003/06/0123.html causes Xilinx ISE to run really, really slow. It has a window to which messages are sent via a pipe, and what I see now is that one line comes out every 2/3 of a second or so, as regular as a clock at least by eye. I can revert those two patches, and it goes back to spitting out the messages very fast. Since there are a lot of messages being sent, the current version slows the app down to a crawl. A bit more info about what is happening, as best as I can tell. It looks like the message window is doing a PeekNamedPipe about every 2/3 of a second; hence the timing that I am seeing. So the problem appears to be that in the new implementation, the write to the pipe is being blocked on every call, until a read has happened. What should be happening is that the write should only block if the pipe is full. Does that help someone know where to look?
Really slow named pipes
This is a bit old, from May, but anyhow... The patch to implement anonymous pipes on top of named pipes: http://www.winehq.com/hypermail/wine-cvs/2003/05/0305.html along with a corresponding bug fix: http://www.winehq.com/hypermail/wine-cvs/2003/06/0123.html causes Xilinx ISE to run really, really slow. It has a window to which messages are sent via a pipe, and what I see now is that one line comes out every 2/3 of a second or so, as regular as a clock at least by eye. I can revert those two patches, and it goes back to spitting out the messages very fast. Since there are a lot of messages being sent, the current version slows the app down to a crawl. It does not look like the patch itself is the problem; I am guessing that it is the underlying named pipe implementation that is the problem, which was exposed by the patch. Also, reverting to the full CVS 5/20, just after the pipe patches, has the same problem. So it appears that whatever is wrong with named pipes (if that really is the problem) was already there on 5/20, rather than it being something introduced since then. Any hints on what I could look for would be welcome.
Re: Viruses in the wine-devel archive ??
Stefan Leichter wrote: On Friday 22 August 2003 19:00, Duane Clark wrote: I have temporarily changed the maximum message size on wine-patches to 40KB. So any emails with valid forged "From" headers will be caught for moderation. Since all the other lists were already set at 40KB by default, no viruses were able to make it through. If you like to save some work i have seen filter rule against sobig.f for Postfix (http://sbserv.stahl.bau.tu-bs.de/~hildeb/postfix/postfix_sobigf.shtml), Exim and sendmail. For Exim and sendmail the description is in german only on http://www.heise.de/newsticker/data/dab-20.08.03-004/. I don't control the mail server, so you would need to address this to Jeremy. I just do moderation. Hopefully he will also soon add the Mailman spam filtering he mentioned a couple of weeks ago?
Re: About spam
Sylvain Petreolle wrote: I have an evidence that some robots can grab our email adress, even with our mangling process on winehq. I used my work adress only onto wine-devel and got spammed last week. A lot of spammers do dictionary attacks using various email combinations including first initial last [EMAIL PROTECTED]
Re: Viruses in the wine-devel archive ??
Jeremy Newman wrote: Yup, here is the message. http://winehq.com/hypermail/wine-patches/2003/08/0203.html I'll remove that attachment. Should we contact that author and let him know he is infected, or simply remove him from the list? Please don't remove anyone from the lists. The "From" is always forged, so you should ignore it. The Wine lists are currently getting about 1000 Sobig.F viruses per day, some of them supposedly from Alexandre ;) I have temporarily changed the maximum message size on wine-patches to 40KB. So any emails with valid forged "From" headers will be caught for moderation. Since all the other lists were already set at 40KB by default, no viruses were able to make it through.
Re: Wine history draft
Brian Vincent (C) wrote: I put together the following: http://users.theshell.com/~vinn/wine-history.html ... Comments / suggestions / criticisms? Some interesting postings from the beginnings of Wine were collected and reposted last year. They might be worth including or being referenced in some form. http://www.winehq.com/hypermail/wine-devel/2002/11/0455.html
Re: propset.c: In function `DSPROPERTY_EnumerateW
Peter Birch wrote: The latest cvs code (08/06/2003 20:45:00 pst) will not compile - I get the following error: gcc -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -D__WINESRC__ -Wall -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o propset.o propset.c propset.c: In function `DSPROPERTY_EnumerateW': propset.c:522: parse error before `*' propset.c:526: `wDescription' undeclared (first use in this function) propset.c:526: (Each undeclared identifier is reported only once propset.c:526: for each function it appears in.) propset.c:527: `wModule' undeclared (first use in this function) propset.c:528: `wInterface' undeclared (first use in this function) propset.c:550: parse error before `*' This is on Linux kernel 2.4.20 (i586), GCC 2.95.4 with the configure line: ./configure --prefix=/usr --sysconfdir=/etc --with-opengl --with-x This used to work, and the error amazes me because the exact same code appears in the source file several times before the error. This patch will fix it. http://www.winehq.com/hypermail/wine-patches/2003/08/0050.html
Crash in EnumMRUListA
Running MS Excel viewer, I seem to be able to crash it fairly easily when opening files. The is occurring in the apparently undocumented function EnumMRUListA, so I am not really sure what to expect here. Unhandled exception: page fault on read access to 0x in 32-bit code (0x40a231f0). In 32-bit mode. 0x40a231f0 (EnumMRUListA+0x88 [comctl32undoc.c:1056] in comctl32.dll.so): movl 0x0(%edi),%eax 1056datasize = min( witem->size, nBufferSize ); Wine-dbg>bt Backtrace: =>0 0x40a231f0 (EnumMRUListA+0x88(hList=0x416c00b8, nItemPos=0x3, lpBuffer=0x405816a8, nBufferSize=0x800) [comctl32undoc.c:1056] in comctl32.dll.so) (ebp=40581230) 1 0x4097b3d9 (SHAddToRecentDocs+0x3c9(uFlags=0x2, pv=0x4058242c) [shellord.c:788] in shell32.dll.so) (ebp=40582414) 2 0x300c4151 (XLVIEW.EXE.EntryPoint+0xabc81 in XLVIEW.EXE) (ebp=40582530) 3 0x301851a2 (XLVIEW.EXE.EntryPoint+0x16ccd2 in XLVIEW.EXE) (ebp=40582950) 4 0x30047dae (XLVIEW.EXE.EntryPoint+0x2f8de in XLVIEW.EXE) (ebp=40582b94) 5 0x30046b30 (XLVIEW.EXE.EntryPoint+0x2e660 in XLVIEW.EXE) (ebp=40582c10) 6 0x300476cb (XLVIEW.EXE.EntryPoint+0x2f1fb in XLVIEW.EXE) (ebp=40582c44) 7 0x30047790 (XLVIEW.EXE.EntryPoint+0x2f2c0 in XLVIEW.EXE) (ebp=40582c68) 8 0x407de4f7 (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=40582c8c) 9 0x407de582 (WINPROC_CallWndProc+0x82(proc=0x300476d2, hwnd=0x10021, msg=0x111, wParam=0x2001, lParam=0x0) [winproc.c:219] in user32.dll.so) (ebp=40582cbc) 10 0x407e492f (CallWindowProcW+0xcf(func=0x4086e3f4, hwnd=0x10021, msg=0x111, wParam=0x2001, lParam=0x0) [winproc.c:2928] in user32.dll.so) (ebp=40582cf0) 11 0x407c7bd2 (DispatchMessageW+0x11e(msg=0x40582dc0) [message.c:886] in user32.dll.so) (ebp=40582d34) 12 0x30043eae (XLVIEW.EXE.EntryPoint+0x2b9de in XLVIEW.EXE) (ebp=)
Re: Trackbar select range tweaks
Dustin Navea wrote:
could someone send me the testcase and i will run it on a win2k machine, a
win98 machine and a winxp machine?
Hmm, an executable for determining the SM_CYCAPTION metric is small, so
I'll attach that. It comes from this code.
#include "windows.h"
#include "stdio.h"
main()
{
printf("GetSystemMetrics(SM_CYCAPTION) = %d\n",
GetSystemMetrics(SM_CYCAPTION));
}
For determing thumb size, I use MS ControlSpy, available here:
http://www.microsoft.com/msj/0798/controlspy.aspx
That includes binaries. Just run the Trackbar binary, click on
"TBM_GETTHUMBLENGTH" in the window on the lower left, and then click the
"Send" button. In the window below that button, it should say something
like:
lResult: 21 (0x15)
which means the thumb size is 21.
sysmetric.exe.zip
Description: Zip archive
Re: Trackbar select range tweaks
BiGgUn wrote: Changelog: Oops, initial thumb length doesn't appear to depend on SM_CYCAPTION after all. Thumb length DOES depend on GetSystemMetrics( SM_CYCAPTION) on a native platform. ( thumb_length = GetSystemMetrics( SM_CYCAPTION) + 2 [with no select range]) If wine uses standard values from windows there's no matter. But if a user decides to change these values in its registry, trackbars won't reflect those changes in their sizes. So i think that thumb length still need to depend on this metrics value. Well, as I mentioned elsewhere, on Win2K for me GetSystemMetrics(SM_CYCAPTION) returns 20, while the initial thumb size is 21. So any relationship appears to depend on the Windows version. By all means feel free to figure out exactly how it works, and submit a patch. But I think it needs to be tested on a few different versions of Windows. I find the explanation of SM_CYCAPTION in the SDK to not be too clear: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/win9x/verdiff_8hwz.asp
Re: Trackbar size fixes
Jon Bright wrote: Duane Clark wrote: > From the Wine include file: > > winuser.h:#define SM_CYCAPTION 4 > > So I don't think we want to use that value. That's just the value for passing to GetSystemMetrics. The actual value returned will be either: sysMetrics[SM_CYCAPTION] = 20; or sysMetrics[SM_CYCAPTION] = SYSMETRICS_GetRegistryMetric(hkey, "CaptionHeight", 18) + 1; /* for the separator? */ Hmm... well I wrote a small test case on Windows. For me on WinNT, GetSystemMetrics(SM_CYCAPTION) returns 19 (which is also what Wine returns for me), while the initial trackbar thumb size is 21. On Win2k, GetSystemMetrics(SM_CYCAPTION) returns 20, but the the initial thumb size is still 21. So am I doing something wrong? It does not appear to me that the trackbar thumb size is related to SM_CYCAPTION. By the way, for me, changing to [Version] "Windows" = "win2k" still returns 19 for SM_CYCAPTION for me on Wine. I am assuming that should return 20?
Re: Trackbar size fixes
BiGgUn wrote: As BiGgUn suggests, in TRACKBAR_InitializeThumb, setting: infoPtr->uThumbLen = 21; In this case 21 is a magic number. In fact, infoPtr->uThumbLen equals SM_CYCAPTION. From the Wine include file: winuser.h:#define SM_CYCAPTION 4 So I don't think we want to use that value.
Re: Trackbar size fixes
Duane Clark wrote: Duane Clark wrote: Hmm, attached is what that looks like for me. So I don't know why it looks bad to you. Oops, sorry. I was using a native control there. I do see the same thing as you. (Sorry about replying to myself several times) As BiGgUn suggests, in TRACKBAR_InitializeThumb, setting: infoPtr->uThumbLen = 21; fixes IE. I suspect that is close to correct, other than that it probably should not be a magic number.
Re: Trackbar size fixes
Duane Clark wrote: Hmm, attached is what that looks like for me. So I don't know why it looks bad to you. Oops, sorry. I was using a native control there. I do see the same thing as you.
Re: Trackbar size fixes
BiGgUn wrote: Hi, I'm currently working on a patch about trackbar sizes fixes. The main goal of this patch is to get rid off magic values and provide a more generic approach of trackbar computation. Some test cases have shown for example that thumb length doesn't depend on client rect fields... Ah, I suspected as much.
Re: Trackbar size fixes
Mike Hearn wrote: On Tue, 2003-07-29 at 05:19, Duane Clark wrote: I have done quite a bit of comparison testing with ControlSpy on Wine and Win2K, so these changes should be accurate. Mainly done to fix earthquake (which was completely broken). Changelog: Fix the size/position of the thumb/channel/tics to match Win. There's clearly something strange going on here we don't fully understand - this patch breaks Internet Explorer again. See attached screenshot. Builtin after this patch is on the left, native (98) is in the middle, CVS wine is on the right. Hmm, attached is what that looks like for me. So I don't know why it looks bad to you. Horizontal trackbars are still OK, though with this patch the thumb is bigger than native 98. I didn't bother with a screenshot of that since it still looks OK. One part of the code I did not test is the function TRACKBAR_InitializeThumb(), which sets the initial thumb length. My confidence in that part is not very good, since it doesn't make sense to have different calculations for the horizontal and vertical bars. So if someone were to do some simple testing to verify/correct that function, it would be a good thing. All of the rest of the patch sets the rest of the dimensions of the control based on the length of the thumb and the size of the window, which is how Windows does it. That part I tested extensively, and am very confident is correct. <>
Re: lostwages/ include/wwn.php templates/en/contri ...
Brian Vincent (C) wrote: ... PS. Anyone notice the interviews on WWN? Anyone have any comments or suggestions for improving them? Any particular people I need to interview that I'm forgetting? (I do have some in various stages of preparation, and a list of people I need to include.) I'll save Alexandre for last. I've read all of them, and they have been very good. About all that I would consider to be missing are pictures, though maybe not everyone would want that :-)
Re: Missing Bugzilla Descriptions
Robert North wrote: Dustin Navea speeddymon-at-yahoo.com |Wine Mailing Lists| wrote: Hey guys i was browsing thru BugZilla and I noticed that most if not all of the bugs between 853-1349 are missing their descriptions.. Possibly from the software update? Either way, I'm still around every now and then, although I'm not subscribed to any lists, so if anyone replies, please CC me Just noticed that! 2 *important* bugs for me 1160 & 1165 are missing any comments. 1165 in particular, contained some useful debugging info ... I suppose it's a good thing that it seems to be resolved in the current CVS! Any ideas? Well, most all the bugs and comments after Apr 2002 should be archived on news.gmane.org. That includes new bugs starting about bug 565. It is a lot easier to browse with gmane than the winehq archives (select all articles and sort by subject). However, gmane doesn't archive the attachments.
Re: Typo fixes
Francois Gouget wrote: -As to the implict existance question: I'm not sure. +As to the implict existence question: I'm not sure. +As to the implicit existence question: I'm not sure. ^
Re: Internet Explorer regressions
Gregory M. Turner wrote: I've been trying to force myself to use nt4 mode & nt4 native dll's; Oh, and just to make it even more borked I'm using IE6 ;). Absolutely no dice whatsoever, here. The installation goes OK, but I just can't find a combination of native/wine dlls that doesn't go "bonk" real fast. I think, this is about what I should expect with such a get-up, IOW its not a regression. Ah, I should have said "reasonably fast" rather than "reasonably well". I use IE very little, so shouldn't comment on stability. Oops, I am running IE5, not 6. That said, I am using these settings (mostly from Sylvain): [AppDefaults\\iexplore.exe\\Version] "Windows" = "win98" [AppDefaults\\iexplore.exe\\DllOverrides] "comctl32" = "native" # for favorites "commctrl" = "native" # "crypt32" = "native" # call to uninmplemented # "msvcrt20" = "native" "msvcrt" = "native" # "oleaut32" = "native"# | # "ole32" = "native" # |not necessary in order to run # "olepro32" = "native"# | "rpcrt4" = "native" # | "shdocvw" = "native" # .101 PathRemoveBackslashW calls to undocumented # in shlwapi and force IE to abort. # "shell" = "native" # } # "shell32" = "native" # } "shlwapi" = "native" # }} unimplemented funcs "urlmon" = "native" # } "wininet" = "native" # }
Re: Internet Explorer regressions
Mike Hearn wrote: I've been doing that, but unfortunately am limited in how far I can go back before I lose NPTL support and wine stops running. If it's my setup here then it'll also be borked. I'm sending latest CVS into work, to see if that breaks IE as well, then I'll know if it's code or environment. Well, at least on RH7.3 (no nptl) ie6 seems to run reasonably well.
Re: notepad and commdlg problems ?
Sylvain Petreolle wrote: could you tell exactly what you are doing to get this ? I tried it with gnome and kde in managed mode and got no problem of this kind. It looks to me like its your install is borken. However CVS has its own problems http://www.telusplanet.net/public/lambregt/wine/notepad.png Not that bad but the last icon on the right is cut off. I would guess the difference is that you are using a very narrow font. Mine is much wider. As a really wild guess, it looks like perhaps the width is being determined solely as a some multiple of a font width, and no consideration is given for the space the icons take. With a wider font, it comes out ok. This stuff is all in dlls/commdlg/filedlg*, so happy hacking :-)
Re: Mutual Debugging Efforts
James wrote: Great, thanks for the copy of details. I'll file them away for when I get a moment. It's a little while since I last tried building anything manually, and had compatibility issues back then, so I avoid it when I can, plus I noticed some stuff in the knowledgebase about this so felt i should approach with caution! Ah yes, you are running RH8. I do seem to recall some mention of problems there.
Re: Mutual Debugging Efforts
James wrote: On Wed, 2003-03-12 at 17:28, Mike Hearn wrote: Hi, that version is over half a year old. Compiling from source is a bit harder than using RPMs, but not much. If you can keep up with CVS then upgrading is pretty easy as well. Yes, I was wondering about this. RH are often quite good at new releases, but perhaps only for security issues or bugs they consider more serious in non-development systems and hence they've not even tried to deliver a newer RPM for Wine. Oh well, I might have to try biting the bullet. Very badly pressed for time at present though :( Since I recently provided instructions elsewhere, here is a copy. I would ignore the tarball method mentioned in the wine documentation; I consider it more trouble than it is worth. This takes only a few minutes, other than the time spent waiting for the Wine compile to complete. First uninstall the Wine that you have (you can always reinstall it later if desired). Then.. Create the file ~/.cvspass and put in the line: :pserver:[EMAIL PROTECTED]:/home/wine Ah Create the file ~/.cvsrc and put in: cvs -z 3 update -PAd diff -u Type "cvs checkout wine", and in a few minutes (assuming a reasonable internet connection) you should have a complete Wine tree. CD into it and type "./tools/wineinstall", or do it manually: ./configure make depend make make install (as root) And you should then be ready to go. That really should be all there is to it. Then in the future to update, you just CD into the wine directory and type "cvs update", and then redo the last four steps above.
Re: New conformance test for user32.dll
Duane Clark wrote: Which demonstrates one of the complications with inlined plain text, because generally extra effort is required to prevent undesired word wrap. Perhaps what might reduce this problem is to explicitely document for every common mailer, a method that will produce the desired format.
Re: New conformance test for user32.dll
Tony Lambregts wrote: Ok. then Change Log: Clarify patch requirements. Files changed: documentation/patches.sgml Index: patches.sgml === RCS file: /home/wine/wine/documentation/patches.sgml,v retrieving revision 1.6 diff -u -r1.6 patches.sgml --- patches.sgml18 Feb 2003 23:23:35 -1.6 +++ patches.sgml5 Mar 2003 21:01:34 - @@ -48,8 +48,8 @@ For additions: mention that you have some new files and -include them as either separate attachments or by appending -the diff -u /dev/null /my/new/file output of them Which demonstrates one of the complications with inlined plain text, because generally extra effort is required to prevent undesired word wrap.
Re: SystemParametersInfo patch
Jon Bright wrote: ... (as an aside are patches preferred as MIME attachments or straight in the mail here?) I will just throw in a couple more comments to add to those already made. The main problem with the way you attached this is that it has modified a lot of the "special" characters, which you normally don't see because your mail reader has displays them ok. So you should do a "view source" of what you have attached. For example, it starts out: diff -u -r1.49 sysparams.c --- windows/sysparams.c 19 Feb 2003 22:04:46 - 1.49 +++ windows/sysparams.c 5 Mar 2003 10:39:39 - @@ -1662,17 +1662,26 @@ } =20 case SPI_GETMOUSEHOVERWIDTH: /* 98 _WIN32_WINNT >=3D 0x400 || _W= IN32_WINDOW > 0x400 */ Notice the "=20", "=3D", and "=". Not only has the mailer changed some of the characters, but it has inserted line feeds. For many of us, all this is invisible. I use Mozilla, and it recreates the file correctly as long as I Save As... text. But I don't think we should assume that everyone can do that.
Re: A relay trace indenting tool, take 2
Alexandre Julliard wrote: Duane Clark <[EMAIL PROTECTED]> writes: Changelog: A tool for indenting calls in relay traces. It would be much better to merge that into examine-relay, rather than having two different scripts basically doing the same parsing. The format of the output is quite a bit different, so the tools serve somewhat different purposes. I did leave all the error parsing in, but only because that was easier then bothering to delete it. Since the program is rather small, I did not think it was worth the admittedly small effort. I suppose a command line flag could be used to select output format.
Re: Relay trace indenting?
Mike Hearn wrote: I was under the impression this is what tools/examine-relay did? I never understood exactly how it does the indents though, it does it in a slightly non-intuitive way. That is very close to what I want. I have started making mods to it, and will submit it probably as a separate tool, "indent-relay".
Relay trace indenting?
Just wondering if anyone has written a script or something that does indenting of relay traces. I don't know how other people handle these, but I find that I invariably spend a lot of time indenting the calls in relay trace files to make them easier to follow. It would seem like something that someone would already have an automated method of handling (or maybe I'm the only one that does this).
Re: Rebuilding font retrics each time Wine starts.
J. Grant wrote: Hi, Is there a reason the "font metrics" are rebuilt every day or so? (when I start to run a program with wine) See the thread: http://www.winehq.com/hypermail/wine-users/2003/02/0073.html
Re: A window size/move fix (repost)
Alexandre Julliard wrote: Duane Clark <[EMAIL PROTECTED]> writes: Changelog: Before changing window size/pos, handle pending ConfigureNotify events. That's only hiding the problem, and only in some cases. There is no guarantee that the ConfigureNotify has arrived by the time we do the resize, so we need to cope with a ConfigureNotify arriving at any time. Okay, that will certainly be more ...err... challenging ;) I will see what I can do.
Re: PATCH Window resizing
Just wondering about the status of two patches. Is there any additional info I can provide or changes that need to be made for these? http://www.winehq.com/hypermail/wine-patches/2003/02/0080.html http://www.winehq.com/hypermail/wine-patches/2003/02/0095.html
Re: wine/ win32/device.c server/trace.c server/tim ...
Eric Pouech wrote: does this unapplied yet patch helps ? http://www.winehq.com/hypermail/wine-patches/2003/02/0118.html Well, that fixed the corrupted icons that Uwe mentioned yesterday. However when I exited the program (Xilinx ISE, basically the same as WebPack), it spit out a bunch of cryptic messages: 0x8eb0e30:1: Fd unix_fd=15 mode=00 user=0x8eb0e70 0x8eb0df0:1: Fd unix_fd=15 mode=00 user=0x8eb0e30 0x8eb0db0:1: Fd unix_fd=15 mode=00 user=0x8eb0df0 0x8071ea8:1: Fd unix_fd=15 mode=00 user=0x8eb0d80 0x8eb0d40:1: Fd unix_fd=15 mode=00 user=0x8eb0d80 0x8eb0d00:1: Fd unix_fd=15 mode=00 user=0x8eb0d40 0x8eb0cc0:1: Fd unix_fd=15 mode=00 user=0x8eb0d00 0x8eb0c80:1: Fd unix_fd=15 mode=00 user=0x8eb0cc0 0x8eb0c40:1: Fd unix_fd=15 mode=00 user=0x8eb0c80 0x8eb0c00:1: Fd unix_fd=15 mode=00 user=0x8eb0c40 0x8eb0bc0:1: Fd unix_fd=15 mode=00 user=0x8eb0c00 0x8eb0b80:1: Fd unix_fd=15 mode=00 user=0x8eb0bc0 ... etc, about 40 of them.
Re: wine/ win32/device.c server/trace.c server/tim ...
Duane Clark wrote: You mean this one :-) http://www.winehq.com/hypermail/wine-cvs/2003/02/0055.html Oops, I should have looked closer. You didn't mean that one.
Re: wine/ win32/device.c server/trace.c server/tim ...
Eric Pouech wrote: Rein Klazes wrote: On Fri, 14 Feb 2003 14:27:11 -0600, you wrote: Log message: Changed fd operations to take a struct fd instead of a struct object. Removed get_file_info function from object operations. Added get_device_id request to avoid abusing get_file_info. Patch: http://cvs.winehq.com/patch.py?id=7246 does this unapplied yet patch helps ? http://www.winehq.com/hypermail/wine-patches/2003/02/0118.html You mean this one :-) http://www.winehq.com/hypermail/wine-cvs/2003/02/0055.html
Re: The richedit scrollbars
Shachar Shemesh wrote: Duane Clark wrote: The easy fix is to have WM_NCCALCSIZE return the true size of the enclosing window, which is what we have done here. The more difficult fix is to create a custom Richedit MoveWindow procedure for use in the WM_SIZE message above. Since it is very unlikely that an app would call and use the WM_NCCALCSIZE message, we stick with the easy fix for now. Sorry for being a pest about this, and it's not like the Richedit is in my focus at the moment, but what does Windows do under the same circumstances? Well, Windows does not embed an edit control within another Window to come up with the richedit control. So in that case "the true size of the enclosing window" (and I probably should have said "the true size of the client area of the enclosing window") matches the client area of the richedit control. So there is no issue there. This is purely an artifact of the way richedit has been implemented in Wine. This also is why the problem disappears in Wine's notepad when an edit control is used directly (as by your patch of a few weeks ago). Basically the problem comes about because Wine determines what size to set the edit control to with the results of a WM_NCCALCSIZE sent message to the enclosing window, which in our case is the richedit window. If we do not return "the true size of the client area of the enclosing window", then the edit control is drawn incorrectly. And I really do think that the likelihood of an app using WM_NCCALCSIZE on a richedit control to be rather remote, and the likelihood that the value returned affecting the results even more remote. So I personally consider the effort to write a custom WM_SIZE routine to be largely
Re: Listview delete column zero
Dimitrie O. Paun wrote: On February 13, 2003 11:06 pm, Duane Clark wrote: I probably should have mentioned why the app deletes column zero. It repeatedly deletes column zero, testing the returned Boolean until it gets false, and then it starts inserting new columns. So it ends up completely replacing the listview contents. That sounds ... strage . Why not just use LVM_DELETEALLITEMS? Well, I thought it seemed a bit strange too. The short answer is that the new listview has a different number of columns.
Re: Listview delete column zero
Duane Clark wrote: While the MSDN specifically says that column zero should not be deleted, it does in fact work on WinNT, and at least one app depends on it. On WinNT, deleting column zero deletes the last column of items but the first header. Since no app will ever depend on that bizarre behavior, we just delete the last column including the header. I probably should have mentioned why the app deletes column zero. It repeatedly deletes column zero, testing the returned Boolean until it gets false, and then it starts inserting new columns. So it ends up completely replacing the listview contents.
Re: suspended threads acquiring synchronization objects
Dimitrie O. Paun wrote: On Thu, 13 Feb 2003, Peter Hunnisett wrote: ... I've attached a simple test case, the code for the test case and a ReWind licensed patch for the problem. Are you sure? The version with the attached test case got stuck in moderator limbo because it is 60KB, and I just now got to it.
Re: 2GB visible partition size
Tony Lambregts wrote: Alexandre Julliard wrote: Well, yes, if we really need to change the fstype it should be a generic option that allows all types to be specified, not just NTFS. And it shouldn't overload the existing "type" parameter, it should be a separate entry. OK. I guess my biggest problem with this is that the most obvious name for this entry is "Filesytem" which is already used . Since the parameter of interest is specifically named "fsname" rather than "fstype" or "Filesystem", perhaps that should be the configurable parameter name. I would think that would eliminate any confusion.
err:keyboard:X11DRV_ToUnicode Please report
Originally discovered (as far as I know) by Paul McNett and mentioned in bug 1264, typing a shift-tab in an app under Wine generates the message: err:keyboard:X11DRV_ToUnicode Please report: no char for keysym FE20 (ISO_Left_Tab) : err:keyboard:X11DRV_ToUnicode (virtKey=9,scanCode=F,keycode=17,state=1) So here is a report.
Re: Started playing with Wineserver on mingw/cygwin again
Geoff Thorpe wrote: * Michael Stefaniuc ([EMAIL PROTECTED]) wrote: On Wed, Feb 05, 2003 at 01:47:54PM -0500, Dimitrie O. Paun wrote: On Wed, 5 Feb 2003, Geoff Thorpe wrote: This is an interesting question. I know Ingo Molnar has been (one of) the main developer working on the glibc threading stuff, and I also know he used to follow the Wine project. I am sure he's not indifferent to our To resolve any doubts that Ingo isn't taking care of wine read this: http://lwn.net/Articles/6972/ That does indeed suggest that Ingo is "on this". Thank god too, I've just been following up on my hollow words with some attempts to look at the wine code and start finding my way around. That threading stuff is some deep code, and profoundly uninviting. I hope that Ingo's kernel patch (and Alexandre's mention in the mail and address in the CC line) indicate that higher powers are already on top of this problem? I couldn't help but notice that the date on that was 7 Aug 2002. It would be interesting to know what has gone on since then.
Re: Winspool errors with notepad
Sylvain Petreolle wrote: trace:winspool:AddPrinterA ((null),2,0x407c2c1c): stub trace:winspool:DEVMODEdupAtoW trace:winspool:AddPrinterW (L"",2,0x4026ac58) Following these debug messages, we see that the name of the server on which the server is installed changes fromNULL to "". In an attempt to revive this thread (since it broke printing for me too), it appears that if a NULL pointer is passed to: RtlCreateUnicodeStringFromAsciiz(&pNameW,pName); then it returns an empty string in pNameW.buffer, rather than NULL. Since these conversion functions are apparently APIs in Win2000 and later, which I don't have, hopefully someone could add test cases to dlls/ntdll/test/rtlstr.c to test what that function should return when passed a null pointer?
Re: Initialize listview item size.
Dimitrie O. Paun wrote: On February 3, 2003 11:58 am, Duane Clark wrote: This is a separate bug from the other listview patches. If an app sends a LISTVIEW_Paint to a new listview before adding any items (which an app was :-) the item size was not getting set, causing subsequent LISTVIEW_Paint calls to clip the painting. Changelog: Make sure item size is initialized when the first item is added. This is an optimization I've put in to avoid a lot of complex calculations while the listview is initially populated (typically before it's being painted). You are right, we have to detect the change nItemCount from 0 to 1, to do all those calculations. But since we don't actually need them until we paint, I'd like to defer them as much as possible. Moreover, with your patch, we don't catch the SetItemCount case. What about this patch instead: Last night almost the same solution occured to me, so yes I would agree this is better.
Re: LISTVIEW_SetItemCount take 4
Duane Clark wrote: Sigh.. I guess I really should have compiled that previous version before sending it in. Sorry for the excessive traffic. So here it is fixing compiler warnings, with the missing return added in, and with the changelog. Hopefully this will be the last time. Dimi, Dan and I have been looking into this further. This is not the right fix, so please do not apply.
Re: Scrollbars misplaced in several apps
Shachar Shemesh wrote: Duane Clark wrote: Were you perhaps using Window's notepad rather than Wine's? I see it with Wine's notepad. I also see it in Actel designer, that I remember. And I guess I should have said richedit rather than richtext... oh well. In all cases that I have seen, it is fixed by using a native richedit dll. Window's notepad uses the usual EDIT control. As of a few days ago, however, so does the Wine notepad. This may explain the inconsitancy. http://cvs.winehq.com/patch.py?id=7152 Hmmm... I thought I remembered maybe 6 months ago or so a discussion about this... ahh yes between you and Dmitry :-) http://www.winehq.com/hypermail/wine-devel/2002/11/0463.html So does this mean you are going to create a separate wordpad, as you mentioned then?
Re: Scrollbars misplaced in several apps
Dan Kegel wrote: Several apps I've tried (including my company's app) have scrollbars in the wrong place, inset in the window by one scrollbar width. Duane Clark has seen this, too, and said "... the scrollbars being in the wrong position in the richtext window? I am pretty sure that is a richtext bug. I see it in every application that uses richtext. For example, run notepad and then resize the window. " (I tried running notepad, and couldn't reproduce it myself, so maybe I'm confused.) Were you perhaps using Window's notepad rather than Wine's? I see it with Wine's notepad. I also see it in Actel designer, that I remember. And I guess I should have said richedit rather than richtext... oh well. In all cases that I have seen, it is fixed by using a native richedit dll.
Re: Initialize listview item size.
Duane Clark wrote: It paints the headers. And the problem comes about because in LISTVIEW_Paint, a test is made for the first paint, and if it is the first paint, the item size is updated. I guess I should have said something like "...and only if it is the first paint...". Hopefully that was reasonably obvious anyway.
Re: Initialize listview item size.
Dimitrie O. Paun wrote:
On Mon, 3 Feb 2003, Duane Clark wrote:
This is a separate bug from the other listview patches. If an app sends
a LISTVIEW_Paint to a new listview before adding any items (which an app
was :-) the item size was not getting set, causing subsequent
LISTVIEW_Paint calls to clip the painting.
Sorry Duane, maybe it's just Monday morning, but I don't understand this.
If the listview has no items, what is it supposed to paint?
It paints the headers. And the problem comes about because in
LISTVIEW_Paint, a test is made for the first paint, and if it is the
first paint, the item size is updated.
if (infoPtr->bFirstPaint)
{
UINT uView = infoPtr->dwStyle & LVS_TYPEMASK;
infoPtr->bFirstPaint = FALSE;
LISTVIEW_UpdateItemSize(infoPtr);
...
Also, this just doesn't seem like the right place to place this check.
What if the app doesn't call LVM_SETITEMCOUNT?
It has nothing to do with LVM_SETITEMCOUNT that I know, or am I missing
something? This bug is not related to the other bug.
Re: App works almost perfectly, but one MDI screen won't draw
Mike Hearn wrote: These sound like a problem I'm seeing with the Adobe SVG plugin, which means that unfortunately I have to go back to Windows during the day. Basically the app doesn't blit its backbuffer in response to WM_PAINT messages in my case, however, forcing it to redraw itself, for instance due to animation, or a mouseover script causing it to change makes it happen. I keep meaning to look into it, last time I tried I was pretty inexperienced at reading relay traces (well, still am :). I spent a lot of time learning how the bitblt stuff works for the patch I sent in a few weeks ago (which was to fix a similar problem), and stared at a lot of relay traces related to that. So if you narrow it down to a small part of the relay trace and are stuck, go ahead and send it to me (or post it). The bitblt stuff is rather tricky. I'm assuming "Adobe SVG" is a commercial product?
Re: Missing WM_NCPAINT (was: Re: App works almost perfectly, butone MDI screen won't draw)
Dan Kegel wrote:
That sounds like the problem my app is having, too. Now that I
have Spyxx.exe running, I see that a WM_NCPAINT message is sent
to that window in WinMe but not in Wine.
NC messages affect the border that Windows (and Wine) add to a window.
The border that you use to stretch or move the window, and that contains
the window title. Since your problem is within the window client
(content) area, it is probably unrelated.
Interestingly, a WM_NCPAINT *does* get sent to the parent
window ("AfxFrameOrView42") in wine. Is it supposed to
percolate down from that to its child area?
- Dan
Generally, no they won't percolate. I am most of the way through a fix
for the WM_NCPAINT messages in MDI apps, so that will probably come out
this coming weekend. It turned out that finding where the fix went was
fairly easy, but actually implementing it was slightly trickier than I
expected.
Re: App works almost perfectly, but one MDI screen won't draw
Mike Hearn wrote: So then it becomes a matter of figuring out where they should be generated. Yeah, that's the big that usually gets me :) Are they the sort of messages that should be generated by Wine or the app? By Wine. In general, I have found message bugs relatively straightforward to fix. What happens if the app doesn't call BeginPaint in a WM_PAINT handler. Is that an API violation, or are there reasons for it? MSDN had an explanation that seemed to suggest that in certain unusual circumstances you didn't need to call it, but I don't remember exactly what. Yea, I want to try to figure out the exceptions and add something to silence those messages. In this case, they appear to be a "red herring". Looking at SPY++, the WM_NCPAINT and WM_ERASEBACKGROUND messages should have been sent prior to posting the WM_PAINT message. But more studying to come. It is a bit of a mystery to me why the call is bad; it is a call directly from the app. I wonder if the wrong function is being called for some reason. But that is something I will look into later. How common is it for apps to actually make bad API calls? QuickTime seemed to do that, is it rare or not? I don't really know. From the looks of this one, I cannot believe the app was written this incorrectly, so the bug must be something more subtle. I think I am going to have to resort to disassembling the small portion of the app that makes the call to figure out what is happening. Fortunately, the location shows up just fine in winedbg when it crashes, so that makes things easier.
Re: App works almost perfectly, but one MDI screen won't draw
Mike Hearn wrote: Could you explain this to me please? I tried Kaleidograph and started looking at why the "Demo version only" dialog that pops up at the beginning wasn't blanking the background properly, which I decided was because the app didn't call BeginPaint but I am very much a novice. So, if you could explain how you tracked down these bugs I'd very much appreciate it! I ran the app under WinNT and Wine, and compared the messages generated using SPY++. There are non-client (border) and background fill messages missing. So then it becomes a matter of figuring out where they should be generated. Otherwise in the case of Kaleidagraph, there is an additional problem where GetMenuItemInfoA is called with invalid parameters, causing crashes. I temporarily hacked around that, and KGraph then seems to work quite well for me (though I did not test extensively). It is a bit of a mystery to me why the call is bad; it is a call directly from the app. I wonder if the wrong function is being called for some reason. But that is something I will look into later.
Re: App works almost perfectly, but one MDI screen won't draw
Rick Romero wrote: > > If Dan's app behaves the same as mine, I can create a prog that > displays a window :) > > FWIW, Transgaming's current CVS WILL display the text correctly, but > what appeared to be an MDI window is actually created unmanaged (with > windows decorations). If anything, that's one way to test and see if > you get your text.. Please do send me a test app. I plan on going after several painting bugs for the next few weekends.
Re: App works almost perfectly, but one MDI screen won't draw
Dan Kegel wrote: Installing my company's app is still a bear -- the only way I've found to avoid the dreaded "object reference not set" is to run with --debugmsg +ole and redirect to a file (not to the screen, and not to /dev/null). Once installed, the app runs quite well... except for one screen, which remains nearly blank. The MDI frames draw fine, but the contents (which include a hex memory dump area and a tree control) remain blank. I was going to spend this weekend fixing another MDI app to fix a draw problem that several exhibit (for example, Kaleidegraph). Oddly it is just the opposite; the contents draw ok but not the frames. I already have a good idea of where the problem on them is. Would a demo version of your app be available for download somewhere? I would be interested in testing it.
Re: dlls/ddraw/dsurface/user.c and OWN_WINDOW & Worms World Party
Sylvain Petreolle wrote: hasnt got this list a size limitation ? 40KB supposedly. I don't know whether multiple attachments affects that. It is possible that I clicked this one on through (it's happened before), but it doesn't look familiar.
Re: Installshield 6 crash: ole trouble
Dan Kegel wrote: ... Copying and pasting from the wine debugger window is beyond me; it seems totally broken... In ~/.wine/user.reg, look for the [Software\\Wine\\WineDbg] key and change "UseXTerm"=dword: (yes, zero is true for some reason). Then in ~/.wine/system.reg, look for [Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug] and set "Auto"="1" "Debugger"="winedbg.exe --debugmsg -all %ld %ld" ___ put in the ".exe" I think that was all I did to be able to run the debugger within an xterm. Cutting and pasting is now much easier.
Re: VirtualDub cannot find its codecs
Waldeck Schutzer wrote: ... Index: wine/dlls/msvideo/msvideo_main.c === RCS file: /home/wine/wine/dlls/msvideo/msvideo_main.c,v retrieving revision 1.45 diff -r1.45 msvideo_main.c Please supply as diff -u, or better, create a ~/.cvsrc file that contains: cvs -z 3 update -PAd diff -u
Re: Packaging Update $3
Tom Wickline wrote: ... I sent a patch 9 hours ago and it still has not shown up so im re-sending the patch. Ahh, well. To prevent that, you need to subscribe the email address you are using to the wine-patches list, otherwise it waits for me to get around to moderating it. Since your previous email appears to have been sent at about midnight my time, there was a bit of a wait before I saw it ;) If you already are subscribed under a different email address, it is perfectly ok to subscribe another. Just go into your user preferences after completing the subscription process and turn On "Disable mail delivery" to prevent getting multiple copies of postings sent to you.
Getting a program to crash
Howdy, I am trying to make a program crash ;) Instead, the program apparently captures exceptions, pops up a dialog, and continues on. I am hoping for a way to prevent that from happening, and instead falling into the debugger. It does call EXC_RtlRaiseException when the exception occurs, but it is not clear to me how that function works. Hopefully I can comment out something there to get it to crash properly?
Re: Possible bug (with fix) in MENU_FindItem()
Peter Gerwinski wrote: Hello, while developing an application for WINE (also intended to run under MSPOW = MicroSoft's Parody Of WINE, spoken "m-spow";-) I encountered something which I consider a bug in WINE: When I invoke EnableMenuItem to enable/disable a menu item holding a command with the numeric value 200, the first popup menu is enabled/disabled instead of the menu item. (This behaviour does not show up under MSPOW, version "ME".) IMHO this is due to a wrong order of two "if" conditions in control/menu.c:MENU_FindItem(). I am attaching a patch which fixed the problem for me. Hi. Please submit to wine-patches. It will be unlikely to get into wine if submitted here.
Re: Window menu
Dmitry Timoshkov wrote: "Duane Clark" <[EMAIL PROTECTED]> wrote: Changelog: A window with a WS_EX_APPWINDOW extended style can also get a menu. [skipped] /* Set the window menu */ -if ((wndPtr->dwStyle & (WS_CAPTION | WS_CHILD)) == WS_CAPTION ) +if ((wndPtr->dwStyle & WS_CAPTION || wndPtr->dwExStyle & WS_EX_APPWINDOW) +&& !( wndPtr->dwStyle & WS_CHILD) ) Sorry for the late response, but this doesn't look right to me. First of all check for WS_CAPTION should be if ((dwStyle & WS_CAPTION) == WS_CAPTION) because WS_CAPTION is a two bit style. Next, apparently menu can be assigned only for a window that has a caption and not is a child. If for some reason in your case a window has no WS_CAPTION style set (even after all style corrections) then it's a bug in Wine and it should be found and fixed. I would suggest to write a conformance test for this, which will create windows with various styles, check whether they have a caption (by comparing client and window rectangles), then try to set a menu for a window. Well, just as a bit of info, the window does not appear to have a caption; either in Windows or Wine. The menu pops down when the mouse is slid to the very top of the window, and no other border decoration shows ever. Here is the call that does it, which is a call directly from the app. 08072f68:Call user32.CreateWindowExA(0004,004bc998 "menuWndProc",40582b38 "",8000,,,0280,0013,00010023,00c8,0040,) ret=00414c77 trace:win:WIN_CreateWindowEx "" "menuWndProc" ex=0004 style=8000 0,0 640x19 parent=0x10023 menu=0xc8 inst=0x40 params=(nil)
Re: FAQ: best win32 api spy tool?
Dan Kegel wrote: The SPYXX.EXE in my copy of msvc4.0 appears to only let you log windows messages, not api calls. Then again, since help doesn't work under Wine, I can't tell if I'm missing something... Oops, my mistake. That's right.
Re: FAQ: best win32 api spy tool?
Dan Kegel wrote: Hi, I'm trying to figure out why an app works on Windows but not Wine, and it'd sure be nice to be able to log all the api calls the app makes under each of the two environments; then perhaps I could compare the logs to see where Wine differed from Windows. Does anyone else do stuff like that? If so, what tools do you use? You had previously mentioned having a copy of msvc. Did you check in it for SPY++? I would have to say that it seems to work quite well under Wine.
Re: Problem with ShellExecute and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
Dan Kegel wrote: ... I also noticed that ShellExecute will sometimes try to run the executable "C:\\Program" (the first word of "C:\\Program Files\\whatever..."). I fixed that for the case I touched, I think, but didn't do a general fix. MSDN for CreateProcess claims that if the supplied string is not quoted, then that is the correct behavior.
Re: Problem with ShellExecute and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
Dan Kegel wrote: Thanks for the --debugmsg +process tip (and I guess you also did relay?)! But if you also add +reg, you'll see that the App Paths key is indeed being searched by SearchPath(): That was done inside CreateProcessA (note the relay Call and Ret pair), and at least at first glance, appears to be looking for the App Path key for "ListV", which is the name of my test application. I am note real sure what the NtQueryValueKey calls are doing though. I still think the problem is later on, in SHELL_FindExecutable. I think the registry checks here are "red herrings". Then again, I could be completely wrong about that ;) Probably the best way to determine that is to modify your simple program to call CreateProcess directly, and see what happens then. 08073208:Call kernel32.CreateProcessA(,40582788 "wordpad.exe readme.txt",,,,,,0040e4db "C:\\",40581eb8,40581ea8) ret=40c8d29f trace:process:CreateProcessA app (null) cmdline "wordpad.exe readme.txt" trace:process:find_exe_file looking for "wordpad.exe" trace:reg:NtOpenKey ((nil),L"Machine\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths",f003f,0x4057e998) trace:reg:NtOpenKey <- 0x4c trace:reg:NtOpenKey (0x4c,L"ListV.exe",f003f,0x4057e994) trace:reg:NtOpenKey <- (nil) trace:reg:NtOpenKey ((nil),L"Machine\\Software\\Wine\\Wine\\Config\\AppDefaults",f003f,0x4057fdf0) trace:reg:NtOpenKey <- 0x4c trace:reg:NtOpenKey (0x4c,L"ListV.exe\\DllOverrides",f003f,0x4057fdec) trace:reg:NtOpenKey <- (nil) trace:reg:NtQueryValueKey (0x14,L"wordpad.exe",2,0x4057fee4,80,22) trace:reg:NtQueryValueKey (0x14,L"*wordpad.exe",2,0x4057fee4,80,24) trace:reg:NtQueryValueKey (0x14,L"*",2,0x4057fee4,80,2) trace:process:find_exe_file Trying built-in exe "C:\\WINDOWS\\SYSTEM\\wordpad.exe" trace:process:find_exe_file Trying native exe "C:\\WINDOWS\\SYSTEM\\wordpad.exe" trace:process:find_exe_file looking for "wordpad.exe readme.txt" trace:reg:NtOpenKey ((nil),L"Machine\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths",f003f,0x4057e998) trace:reg:NtOpenKey <- 0x4c trace:reg:NtOpenKey (0x4c,L"ListV.exe",f003f,0x4057e994) trace:reg:NtOpenKey <- (nil) trace:reg:NtOpenKey ((nil),L"Machine\\Software\\Wine\\Wine\\Config\\AppDefaults",f003f,0x4057fdf0) trace:reg:NtOpenKey <- 0x4c trace:reg:NtOpenKey (0x4c,L"ListV.exe\\DllOverrides",f003f,0x4057fdec) trace:reg:NtOpenKey <- (nil) trace:reg:NtQueryValueKey (0x14,L"wordpad.exe readme.txt",2,0x4057fee4,80,44) trace:reg:NtQueryValueKey (0x14,L"*wordpad.exe readme.txt",2,0x4057fee4,80,46) trace:reg:NtQueryValueKey (0x14,L"*",2,0x4057fee4,80,2) trace:process:find_exe_file Trying built-in exe "C:\\WINDOWS\\SYSTEM\\wordpad.exe readme.txt" trace:process:find_exe_file Trying native exe "C:\\WINDOWS\\SYSTEM\\wordpad.exe readme.txt" 08073208:Ret kernel32.CreateProcessA() retval= ret=40c8d29f
Re: Problem with ShellExecute and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
Duane Clark wrote: According to MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp CreateProcess should check several places for an application, none of which include the registry key. So that call should fail, and it does. By the way, since many things are "inadvertently" left out of the MSDN, it might be worth testing whether that is really the way CreateProcess works on Windows. In fact, that would make a good test case to add to Wine, if you really wanted go for it.
Re: Problem with ShellExecute and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
Dan Kegel wrote: I have a windows-free installation of current CVS wine, with wordpad.exe and the needed DLLs pulled in from a Windows ME installation. wordpad works great. However, ShellExecute(... "wordpad.exe", ".\\stl\\readme.wri" ...) is failing to find wordpad.exe for me. (The call in question is issued by the msvc4.0 setup.exe. The current directory when I run this is /mnt/cdrom, and stl/readme.wri is indeed there.) Ignore the part about /usr/local/etc/system.reg. With a few more traces, I see the first attempt to execute, triggered by the execfunc at line 608 of ShellExecuteExA32. This is just a test to see if the command line can be executed as is. trace:exec:ShellExecuteExA32 mask=0x hwnd=(nil) verb="open" file="wordpad.exe" parm="readme.txt" dir="C:\\" show=0x0005 class=not used trace:exec:ShellExecuteExA32 execute:'wordpad.exe','readme.txt' trace:exec:SHELL_ExecuteA Execute wordpad.exe readme.txt from directory C:\ 08073208:Call kernel32.CreateProcessA(,40582788 "wordpad.exe readme.txt",,,,,,0040e4db "C:\\",40581eb8,40581ea8) ret=40c8d29f trace:process:CreateProcessA app (null) cmdline "wordpad.exe readme.txt" trace:process:find_exe_file looking for "wordpad.exe" According to MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp CreateProcess should check several places for an application, none of which include the registry key. So that call should fail, and it does. 08073208:Ret kernel32.CreateProcessA() retval= ret=40c8d29f Next comes the test at line 614 of ShellExecuteExA32, which calls SHELL_FindExecutable. trace:exec:SHELL_FindExecutable wordpad.exe 08073208:Call kernel32.SearchPathA(0040e4db "C:\\",40582548 "wordpad.exe",40ca9be7 ".exe",0100,40581af0,) ret=40c8d43a 08073208:Ret kernel32.SearchPathA() retval= ret=40c8d43a trace:exec:SHELL_FindExecutable xlpFile=,extension=(null) warn:exec:SHELL_FindExecutable Returning 31 - No association That call should have passed. It returns early at line 203, because xlpFile and the extension, returned from SearchPathA are null. That appears to be where things broke. Even if that passed, it does not appear that a check for the "App Patch" key is being done here, and it looks to me like it should be. Is that enough to get you going further?
Re: Regression in msvideo patch
Stephen Mollett wrote: Hi, [Following on from a thread on wine-users] I've had some problems recently with running the VirtualDub video post-processing package on Wine. It used to work, but then stopped working (it no longer displays the frame previews when seeking in a video file) recently. It might also be worth mentioning that VirtualDub is a free download and under 1MB. With some initial tinkering, it at least plays mpegs great, though I really have not yet figured out how else to work it.
Re: RtlUnicodeStringToInteger prototype (resending)
Dan Kegel wrote: I sent this to wine-patches on the 25th, but it never appeared in the archive; is that list moderated? Only for unsubscribed email adresses, or postings over a 200KB size limit. And I did not see your patches among those being held.
Re: Old scrolling bug
Duane Clark wrote: Fundamentally, the problem is that the X events are handled out of order, because X11DRV_EndGraphicsExposures stripped out particular events (due to copying) without accounting for other pending events that might be relevant (plain old exposure). Well, that conclusion appears to not be quite correct. I stuck a XPending check at the end of X11DRV_EndGraphicsExposures to see whether there were any pending events, and there were apparently none. So I am not sure why the GraphicsExpose event is coming out before the regular expose event, since in real time, they occurred in the opposite order.
Old scrolling bug
Howdy, Another in my pattern of posting intermediate debugging results here, in case anyone can contribute some insight... Looking into the bug that Dimitrie reported here: http://www.winehq.com/hypermail/wine-devel/2002/09/0748.html Here is what is happening (testing on the Listview Control Spy) when sliding the obscuring window. I changed a bunch of TRACE messages to ERR, and added a few. The window of interest, that the artifacts are appearing in is 0x10039 (the "Control Notifications" window): err:x11drv:X11DRV_Expose win 0x10021 (2e3) 0,138 11x1 err:x11drv:X11DRV_Expose win 0x10021 (2e3) 304,138 4x1 err:x11drv:X11DRV_Expose win 0x10039 (2e00032) 0,110 2x1 err:x11drv:X11DRV_Expose win 0x10039 (2e00033) 0,108 99x1 err:x11drv:X11DRV_Expose win 0x10040 (2e00041) 0,126 293x1 err:win:BeginPaint hwnd 0x10021 hdc = 0x9e8 box = (0,138 - 409,139) err:win:EndPaint Here err:win:BeginPaint hwnd 0x10039 hdc = 0x9e8 box = (0,108 - 99,109) err:win:EndPaint Here err:win:BeginPaint hwnd 0x10040 hdc = 0x9e8 box = (0,0 - 293,186) err:win:EndPaint Here err:win:BeginPaint hwnd 0x10047 hdc = 0x890 box = (0,109 - 277,110) err:win:EndPaint Here So an initial exposure occurred and was almost immediately painted. The obscuring window is now at y=109. The first expose of the pair is a validate, and the second is the invalidate. Then ScrollWindowEx is called, which eventually gets to X11DRV_ScrollDC, where the bitblt that scrolls the window is called. err:bitblt:BitBlt hdcSrc=0x9e8 0,14 24 bpp->hdcDest=0x9e8 0,0 126x154x24 rop=cc0020 After scrolling, X11DRV_EndGraphicsExposures is called, which checks pending exposure events as a result of the scroll. err:x11drv:X11DRV_EndGraphicsExposures got 0,96 99x14 count 0 Note that the exposed part is the rectangle with y coordinates from 96 to 110. That means that before the bitblt copy had occurred, the obscuring window had already moved down one pixel. The bitblt moved the previously obscured rectangle at (0,109 - 99,110) to (0,95 - 99,96), but that rectangle did not get into the update rectangle. This is because the only pending events checked are those that are a direct result of exposure due to the copy in bitblt, and does not include any additional areas that were exposed by sliding the obscuring region. err:scroll:X11DRV_ScrollWindowEx A hwnd 0x10039 rgn rect = (0,96,126,168) err:win:GetUpdateRgn hrgnUpdate 0 err:scroll:X11DRV_ScrollWindowEx B hwnd 0x10039 rgn rect = (0,96,126,168) It should be pointed out that X did not lose the exposure event due to sliding the obscuring window, because here it shows up in the next exposure event err:x11drv:X11DRV_Expose win 0x10021 (2e3) 0,139 11x1 err:x11drv:X11DRV_Expose win 0x10021 (2e3) 304,139 4x1 err:x11drv:X11DRV_Expose win 0x10039 (2e00032) 0,111 2x1 err:x11drv:X11DRV_Expose win 0x10039 (2e00033) 0,109 99x1 ^^^ Unfortunately, we have already handled the offset due to scrolling, so this event is put into the update region unshifted. The remaining exposures are new, so no shifting is needed. err:x11drv:X11DRV_Expose win 0x10040 (2e00041) 0,127 293x1 err:x11drv:X11DRV_Expose win 0x10021 (2e3) 0,140 11x3 err:x11drv:X11DRV_Expose win 0x10021 (2e3) 304,140 4x3 err:x11drv:X11DRV_Expose win 0x10039 (2e00032) 0,112 2x3 err:x11drv:X11DRV_Expose win 0x10039 (2e00033) 0,110 99x3 err:x11drv:X11DRV_Expose win 0x10040 (2e00041) 0,128 293x3 err:x11drv:X11DRV_Expose win 0x10021 (2e3) 0,143 11x1 err:x11drv:X11DRV_Expose win 0x10021 (2e3) 304,143 4x1 err:x11drv:X11DRV_Expose win 0x10039 (2e00032) 0,115 2x1 err:x11drv:X11DRV_Expose win 0x10039 (2e00033) 0,113 99x1 err:x11drv:X11DRV_Expose win 0x10040 (2e00041) 0,131 293x1 err:x11drv:X11DRV_Expose win 0x10021 (2e3) 0,144 11x2 err:x11drv:X11DRV_Expose win 0x10021 (2e3) 304,144 4x2 err:x11drv:X11DRV_Expose win 0x10039 (2e00032) 0,116 2x2 err:x11drv:X11DRV_Expose win 0x10039 (2e00033) 0,114 99x2 err:x11drv:X11DRV_Expose win 0x10040 (2e00041) 0,132 293x2 err:win:BeginPaint hwnd 0x10021 hdc = 0x890 box = (0,139 - 409,146) err:win:EndPaint Here And finally the update region is painted. This update region includes the region exposed by the scroll, plus all the additional exposure events that occurred due to sliding the obscuring window. err:win:BeginPaint hwnd 0x10039 hdc = 0x890 box = (0,96 - 126,168) err:win:EndPaint Here But there is a one pixel artifact at (0,95 - 99,96), because it is not in the update region. Fundamentally, the problem is that the X events are handled out of order, because X11DRV_EndGraphicsExposures stripped out particular events (due to copying) without accounting for other pending events that might be relevant (plain old exposure).
Re: Changing FS type reported by Wine
Derek Broughton wrote: Is it a serious problem using the file system type of the root? This is a fairly obscure problem anyway, and if you encountered a problem with a specific application you could set up new drive letters for the specific file systems you needed. It's a little kludgey, but I don't see it as being incompatible with the intent of Wine - after all, while Wine _can_ access Unix file systems, and use the features of them, it's providing an interface to Windows which _doesn't_ understand the concept of different file systems under a single drive. According to MSDN, "FAT" and "NTFS" are both legitimate return values for the filesystem name from GetVolumeInformation (though it does not mention what other possibilities might also be valid). Wine hardcodes this to always return FAT (or CDROM). http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/getvolumeinformation.asp Since it is hardcoded, I don't know how you would "set up new drive letters for the specific file systems you needed." An option in ~/.wine/config, on the otherhand, would make this easy.
Re: A crash destroying imagelists
Dimitrie O. Paun wrote:
On December 22, 2002 02:50 pm, Duane Clark wrote:
That area is then freed. When freed, COMCTL32_Free writes prev and next
entries into himl.
Where? COMCTL32_Free() simply calls HeapFree():
BOOL WINAPI COMCTL32_Free (LPVOID lpMem)
{
TRACE("(%p)\n", lpMem);
return HeapFree (COMCTL32_hHeap, 0, lpMem);
}
HeapFree then calls RtlFreeHeap, which calls HEAP_MakeInUseBlockFree,
and that writes the prev and next entries. It appears that Wine keeps a
linked list of free blocks on the heap, with the link entries in the
first and second words of the block.
At the end of ImageList_Destroy, there is a call to ZeroMemory, which
obliterates the prev and next pointers which had been written there.
Then another COMCTL32_Free call detects the error. At least I assume it
is an error.
Does this work any better? It shouldn't make any difference, but ...
Nope.
There is something else funny here. I can't see why zeroing out an
area we're just about to free is problematic.
The first time, when it was a valid block, zeroing out the area before
freeing was fine. When the block was freed, HEAP_MakeInUseBlockFree
marked it as free and then wrote the link list entries into it,
overwriting the zeroes that had just been put there.
It would appear that at a minimum, a test needs to be made in
ImageList_Destroy to determine whether the heap corresponding to the
imagelist is valid.
Even better, there is already a magic field in the _IMAGELIST structure,
which does not appear to be used. Perhaps it should have "used" and
"free" magic values, similar to what is used by the heap.
It really would not matter if the "free" value is subsequently
overwritten, either by the heap functions or something else to which the
block was allocated, since it would not be likely to get the "used"
magic written to it; unless of course it was allocated to another imagelist.
Re: A crash destroying imagelists
Duane Clark wrote: ... At the end of ImageList_Destroy, there is a call to ZeroMemory, which obliterates the prev and next pointers which had been written there. Then another COMCTL32_Free call detects the error. At least I assume it is an error. And indeed simply commenting out the ZeroMemory fixes the application. Though I have no idea what the correct fix would be.
Re: A crash destroying imagelists
Duane Clark wrote: I am trying to track down a crash when exiting an application. Here is what I think are relevant parts of the trace. Does it appear that I am in the right area? Any hints on how to proceed would be appreciated. I think the problem comes down to this. The application explicitly destroys the imagelist that belongs to a listview: 08073208:Call comctl32.ImageList_Destroy(41691ba0) ret=005027f5 > ... That area is then freed. When freed, COMCTL32_Free writes prev and next entries into himl. trace:commctrl:COMCTL32_Free (0x41691ba0) trace:heap:RtlFreeHeap (0x4169,0002,41691ba0): returning TRUE 08073208:Ret comctl32.ImageList_Destroy() retval=0001 ret=005027f5 > ... Then LISTVIEW_NCDestroy is called. > trace:listview:LISTVIEW_NCDestroy () > trace:listview:LISTVIEW_DeleteAllItems () > trace:commctrl:DPA_DeleteAllPtrs (0x41690d98) ... trace:listview:notify_hdr <= 0 trace:listview:LISTVIEW_NCDestroy Start destroying data structures. ... The listview does not know that the imagelist was already destroyed, so it again calls ImageList_Destroy. trace:listview:LISTVIEW_NCDestroy Start destroying image lists. 08073208:Call gdi32.DeleteObject() ret=409fcadd 08073208:Ret gdi32.DeleteObject() retval= ret=409fcadd 08073208:Call gdi32.DeleteObject() ret=409fcaea 08073208:Ret gdi32.DeleteObject() retval= ret=409fcaea 08073208:Call gdi32.DeleteObject() ret=409fcaf7 08073208:Ret gdi32.DeleteObject() retval= ret=409fcaf7 08073208:Call gdi32.DeleteObject() ret=409fcb04 08073208:Ret gdi32.DeleteObject() retval= ret=409fcb04 At the end of ImageList_Destroy, there is a call to ZeroMemory, which obliterates the prev and next pointers which had been written there. Then another COMCTL32_Free call detects the error. At least I assume it is an error. trace:commctrl:COMCTL32_Free (0x41691ba0) err:heap:HEAP_ValidateFreeArena Heap 4169: bad next ptr for arena 41691b98
A crash destroying imagelists
I am trying to track down a crash when exiting an application. Here is what I think are relevant parts of the trace. Does it appear that I am in the right area? Any hints on how to proceed would be appreciated. 08073208:Call comctl32.ImageList_Destroy(41691ba0) ret=005027f5 08073208:Call gdi32.DeleteObject(098c) ret=409fcadd 08073208:Call x11drv.DeleteBitmap(098c) ret=4078081b 08073208:Call gdi32.GDI_GetObjPtr(098c,4f4b) ret=40adcfe4 08073208:Ret gdi32.GDI_GetObjPtr() retval=40279910 ret=40adcfe4 08073208:Call gdi32.GDI_ReleaseObj(098c) ret=40add01e 08073208:Ret gdi32.GDI_ReleaseObj() retval= ret=40add01e 08073208:Ret x11drv.DeleteBitmap() retval=0001 ret=4078081b trace:heap:RtlFreeHeap (0x4023,0002,40279910): returning TRUE 08073208:Ret gdi32.DeleteObject() retval=0001 ret=409fcadd 08073208:Call gdi32.DeleteObject(0990) ret=409fcaea 08073208:Call x11drv.DeleteBitmap(0990) ret=4078081b 08073208:Call gdi32.GDI_GetObjPtr(0990,4f4b) ret=40adcfe4 08073208:Ret gdi32.GDI_GetObjPtr() retval=402799c8 ret=40adcfe4 08073208:Call gdi32.GDI_ReleaseObj(0990) ret=40add01e 08073208:Ret gdi32.GDI_ReleaseObj() retval= ret=40add01e 08073208:Ret x11drv.DeleteBitmap() retval=0001 ret=4078081b trace:heap:RtlFreeHeap (0x4023,0002,402799c8): returning TRUE 08073208:Ret gdi32.DeleteObject() retval=0001 ret=409fcaea 08073208:Call gdi32.DeleteObject(1282) ret=409fcaf7 trace:heap:RtlFreeHeap (0x4023,0002,40279ac0): returning TRUE trace:heap:RtlFreeHeap (0x4023,0002,40279a58): returning TRUE 08073208:Call kernel32.LOCAL_Free(01b7,1282) ret=4078e36f 08073208:Ret kernel32.LOCAL_Free() retval= ret=4078e36f 08073208:Ret gdi32.DeleteObject() retval=0001 ret=409fcaf7 08073208:Call gdi32.DeleteObject(1286) ret=409fcb04 trace:heap:RtlFreeHeap (0x4023,0002,40279b28): returning TRUE trace:heap:RtlFreeHeap (0x4023,0002,40279ae0): returning TRUE 08073208:Call kernel32.LOCAL_Free(01b7,1286) ret=4078e36f 08073208:Ret kernel32.LOCAL_Free() retval= ret=4078e36f 08073208:Ret gdi32.DeleteObject() retval=0001 ret=409fcb04 trace:commctrl:COMCTL32_Free (0x41691ba0) trace:heap:RtlFreeHeap (0x4169,0002,41691ba0): returning TRUE 08073208:Ret comctl32.ImageList_Destroy() retval=0001 ret=005027f5 The next mention of 41691ba0 is 08073208:Call window proc 0x40a0f0c8 (hwnd=0x1002e,msg=LVM_GETIMAGELIST,wp=0001,lp=) 08073208:Call kernel32._ConfirmSysLevel(4070bc18) ret=406b681d 08073208:Ret kernel32._ConfirmSysLevel() retval= ret=406b681d 08073208:Call user32.GetWindowLongW(0001002e,) ret=40a0f0e5 08073208:Ret user32.GetWindowLongW() retval=41690a18 ret=40a0f0e5 trace:listview:LISTVIEW_WindowProc (uMsg=1002 wParam=1 lParam=0) 08073208:Call user32.GetWindowLongW(0001002e,fff0) ret=40a0f164 08073208:Ret user32.GetWindowLongW() retval=40018405 ret=40a0f164 08073208:Call kernel32.GlobalGetAtomNameW(c012,4070ce90,003c) ret=40693ce9 08073208:Ret kernel32.GlobalGetAtomNameW() retval=000d ret=40693ce9 08073208:Call kernel32.lstrcpynW(4070cf08,40274130 L"List1",0010) ret=406b9fe6 08073208:Ret kernel32.lstrcpynW() retval=4070cf08 ret=406b9fe6 08073208:Ret window proc 0x40a0f0c8 (hwnd=0x1002e,msg=LVM_GETIMAGELIST,wp=0001,lp=) retval=41691ba0 08073208:Ret user32.CallWindowProcA() retval=41691ba0 ret=005050d2 08073208:Ret user32.CallWindowProcA() retval=41691ba0 ret=005050d2 08073208:Call kernel32.GlobalGetAtomNameW(c012,4070ce90,003c) ret=40693ce9 08073208:Ret kernel32.GlobalGetAtomNameW() retval=000d ret=40693ce9 08073208:Call kernel32.lstrcpynW(4070cf08,40274130 L"List1",0010) ret=406b9fe6 08073208:Ret kernel32.lstrcpynW() retval=4070cf08 ret=406b9fe6 08073208:Ret window proc 0x5048bf (hwnd=0x1002e,msg=LVM_GETIMAGELIST,wp=0001,lp=) retval=41691ba0 So it appears to still get the imagelist, even though it has been destroyed. Then the next mention is where it gives a bad ptr message. 08073208:Call window proc 0x503959 (hwnd=0x1002d,msg=WM_NOTIFY,wp=041b,lp=40581ea4) 08073208:Call kernel32._ConfirmSysLevel(4070bc18) ret=406b681d 08073208:Ret kernel32._ConfirmSysLevel() retval= ret=406b681d 08073208:Call kernel32.GlobalFindAtomW(406f3982 L"PropertySheetInfo") ret=406d7488 08073208:Ret kernel32.GlobalFindAtomW() retval= ret=406d7488 08073208:Call kernel32.GlobalGetAtomNameW(8002,4070ce90,003c) ret=40693ce9 08073208:Ret kernel32.GlobalGetAtomNameW() retval=0007 ret=40693ce9 08073208:Call kernel32.lstrcpynW(4070cf08,402757e8 L"Conference Information Window",0010) ret=406b9fe6 08073208:Ret kernel32.lstrcpynW() retval=4070cf08 ret=406b9fe6 08073208:Ret window proc 0x503959 (hwnd=0x1002d,msg=WM_NOTIFY,wp=041b,lp=40581ea4) retval= 08073208:Call kernel32.GlobalFindAtomW(406f3982 L"PropertySheetInfo") ret=406d7488 08073208:Ret
Re: Listview report mode tweaks
Dimitrie O. Paun wrote: On December 19, 2002 07:48 pm, Duane Clark wrote: I also altered LISTVIEW_GetSubItemRect so that it reports correct values, as compared against WinNT on ControlSpy. Problem is that LISTVIEW_GetSubItemRect is documented to return same thing for LVIR_LABEL and LVIR_BOUNDS. Of course, incorrect documentation is known to exist, so as long as you checked it... However, when we implement things different from the documented behavior, a clear comment explaining why we deviate is appropriate. Otherwise, someone might get rid of it in the future. :( Well well... I had not read the docs that closely. I did not expect the definition of LVIR_LABEL to depend on what function used it. This might require that I do a bit more testing. I had noticed that LISTVIEW_GetSubItemRect was only specified for use with a "one-based index of the subitem", but it works fine on WinNT with subitem '0', the first item. A little more testing shows that with subitem '0', LISTVIEW_GetSubItemRect succeeds with LVIR_SELECTBOUNDS too, but that item fails for any other subitem. So I suspect the correct behavior is for subitem '0' to pass the request on to LISTVIEW_GetItemRect. For non zero subitems I may need to try to get icons inserted into another column to test with.
Re: Uninitialized lpVtbl for IExtractIconA in PidlToSicIndex
Uwe Bonnes wrote: Rolf answered in PM. The CVS server seemed doen for him. He send me appended fix and promises to send a patch the wine-patches when he can access the cvs server again. The fix works for me. That fixes my crash too.
Re: Uninitialized lpVtbl for IExtractIconA in PidlToSicIndex
Uwe Bonnes wrote: Hallo, xilinx _pn.exe crashes again. It seems related to the shell updates today. In PidlToSicIndex the call to IShellFolder_GetUIObjectOf succeeds, but ei seems uninitialized and call to IExtractIconA_GetIconLocation goes astray: And Xilinx fpga_editor also crashes, when attempting to bring up the "Open" dialog. Sounds like it could be the same thing. I did not narrow it down beyond one of the Dec 12 patches (which I assume Uwe is referring to).
Re: MSI (MS Installer)
Scott Cote wrote: I agree that the installers that are blindly expecting msiexec to be there are flawed. However, since most windows machines have msiexec installed, the end result is that these installers will run on most windows machines but not on wine. Perhaps a "simple" solution would be a "dummy" msiexec which is installed only if a real one does not exist, which simply prints a message or pops up a dialog when it is executed telling the user where to download MSI.
Re: MSI (MS Installer)
Uwe Bonnes wrote: "Zsolt" == Zsolt Rizsanyi <[EMAIL PROTECTED]> writes: Zsolt> On Monday 09 December 2002 17:54, Scott Cote wrote: >> I've found that many of the test applications I've tried installing >> failed due to the lack of MSIEXEC. If it is implemented, could you >> tell me where to find it? If not, I'd like to contribute, could you >> tell me if any work has been done and who to coordinate with? Zsolt> It is not implemented. That's sure. (Tough installing MS Office Zsolt> 2k installs it for you) I have not heard anybody speaking about Zsolt> implementing it on this list (I'm listening here since about a Zsolt> year). We don't need to implement every MS dll. We only need to implement: - core dlls (kernel32, comclt32, ...) which applications expect to be available - dlls used for compiling/porting (msvcrt) I guess this msiexec is not loaded to the system after a clean Windowsinstall. In this case the installer must cope with the situation that msiexec is not there and must provide it itself. And just as a bit more info, MSI can be downloaded freely and directly from Microsoft. Just go to http://search.microsoft.com/default.asp Type "msi" into the search box, and a couple different versions are available. Seems to work fine.
Re: ppdebug
Michael Sauer wrote: ... P.S.: sorry if this mail reaches the list twice, but the first one i send with some private e-mail address and the list moderator will (hopefully) erase it (as he does it every time). Hmmm... since I am the moderator, I am a bit puzzled by that. On rare occasions I will reject a post, but always supply a reason. The only ones I "erase" are spam. In any case, starting Saturday afternoon for about a week, I will be gone. Hopefully some of the other folks with moderator access will fill in, otherwise moderated posts are going to get stuck in moderator limbo for quite awhile.
Re: An opengl regression
Lionel Ulmer wrote:
...
/* If OpenGL is available, change the default visual, etc as
necessary */
-if ((desktop_vi = X11DRV_setup_opengl_visual( display )))
+if (desktop_dbl_buf && (desktop_vi = X11DRV_setup_opengl_visual(
display )))
{
visual = desktop_vi->visual;
screen = ScreenOfDisplay(display, desktop_vi->screen);
Out of curiosity, do you have the 'DesktopDoubleBuffered' option set in your
Wine config file ?
I did notice and try that (after posting), and it also fixes it. So I
guess the issue becomes whether it should also work without double
buffering, as that is the default in the sample config file.
Re: An opengl regression
Duane Clark wrote:
The patch for dynamic loading of opengl,
http://www.winehq.com/hypermail/wine-cvs/2002/11/0151.html
has caused a (apparently minor) regression in the program earthquake
http://www.navagent.com/products/earthquake/
And as a bit more information, this is the chunk that does it.
--- wine/dlls/x11drv/x11drv_main.c:1.64 Mon Nov 25 19:04:54 2002
+++ wine/dlls/x11drv/x11drv_main.c Mon Nov 25 19:04:54 2002
@@ -313,8 +317,11 @@
}
else screen_depth = DefaultDepthOfScreen( screen );
+/* Initialize OpenGL */
+X11DRV_OpenGL_Init(display);
+
/* If OpenGL is available, change the default visual, etc as
necessary */
-if ((desktop_vi = X11DRV_setup_opengl_visual( display )))
+if (desktop_dbl_buf && (desktop_vi = X11DRV_setup_opengl_visual(
display )))
{
visual = desktop_vi->visual;
screen = ScreenOfDisplay(display, desktop_vi->screen);
An opengl regression
The patch for dynamic loading of opengl, http://www.winehq.com/hypermail/wine-cvs/2002/11/0151.html has caused a (apparently minor) regression in the program earthquake http://www.navagent.com/products/earthquake/ That is a small app (250K download) with a spinning globe that shows current earthquakes; actually a pretty cool little app. The regression is that now when the oceans are turned on (via the settings dialog), the land gets flooded.
Re: Doubleclick in systray (was Pegasus Mail 4.02)
Alexandre Julliard wrote: Duane Clark writes: >And just as a bit more info, under both WinNT and Wine, the systray >gets the dual mouse down, mouse up sequence. The SYSTRAY_WndProc() >function directly the posts messages to the app. So it appears to me >that it is the responsibility of SYSTRAY_WndProc() to keep track of >the clicks, and create the doubleclick message. Does that sound >reasonable? Something like this might help: Yep, that fixed it.
Re: Doubleclick in systray (was Pegasus Mail 4.02)
Duane Clark wrote: The problem here appears to be that under WinNT, when double clicking on the systray icon under WinNT, messages are sent for mouse down (message 201), mouse up (message 202), double click (message 203) (the message 200 is extraneous): ... While under Wine, what is sent are two pairs of mouse down, mouse up messages: And just as a bit more info, under both WinNT and Wine, the systray gets the dual mouse down, mouse up sequence. The SYSTRAY_WndProc() function directly the posts messages to the app. So it appears to me that it is the responsibility of SYSTRAY_WndProc() to keep track of the clicks, and create the doubleclick message. Does that sound reasonable?
Doubleclick in systray (was Pegasus Mail 4.02)
Rick wrote: The second issue, I've noticed that double-clicking the system tray icon does not restore Pegasus Mail. I can minimize it so it appears both on the taskbar and the system tray, but I can't restore the application from the system tray icon (though I can from the taskbar). The problem here appears to be that under WinNT, when double clicking on the systray icon under WinNT, messages are sent for mouse down (message 201), mouse up (message 202), double click (message 203) (the message 200 is extraneous): <00171> 0007011E S message:0x19C9 [User-defined:WM_USER+5577] wParam:1F47 lParam:0201 <00172> 0007011E R message:0x19C9 [User-defined:WM_USER+5577] lResult: <00173> 0007011E S message:0x19C9 [User-defined:WM_USER+5577] wParam:1F47 lParam:0202 <00174> 0007011E R message:0x19C9 [User-defined:WM_USER+5577] lResult: <00175> 0007011E S message:0x19C9 [User-defined:WM_USER+5577] wParam:1F47 lParam:0200 <00176> 0007011E R message:0x19C9 [User-defined:WM_USER+5577] lResult: <00177> 0007011E S message:0x19C9 [User-defined:WM_USER+5577] wParam:1F47 lParam:0203 While under Wine, what is sent are two pairs of mouse down, mouse up messages: <00062> 00010024 P message:0x19C9 [User-defined:WM_USER+5577] wParam:1F47 lParam:0201 <00063> 00010024 P message:0x19C9 [User-defined:WM_USER+5577] wParam:1F47 lParam:0202 <00064> 00010024 P message:0x19C9 [User-defined:WM_USER+5577] wParam:1F47 lParam:0201 <00065> 00010024 P message:0x19C9 [User-defined:WM_USER+5577] wParam:1F47 lParam:0202 So while I am poking around trying to figure out where that translation should be occuring, if anyone has some hints on where to look, it would be most appreciated...
Re: Pegasus Mail 4.02 ('Silver' App)
Rick Romero wrote: ... I don't like being the one to introduce a hack, so FWIW, Pegasus Mail only requires the patch I attached. If this works for Duane also, excellent, I assume you'd want to keep the hack to a minimum. Unfortunately, fpga_editor is still broken with this patch, though it does make Pegasus work fine here too.
Re: Pegasus Mail 4.02 ('Silver' App)
Rick Romero wrote: I'm not sure what Alexandre may not have liked other than the extra stuff that was in there, so I yanked out the extra things that didn't do anything, and did a cvs diff -u . How is this one? (Should I have done it from wine/ instead ?) Well, here was his comment at the time: http://www.winehq.com/hypermail/wine-devel/2002/08/0360.html
Re: Pegasus Mail 4.02 ('Silver' App)
Rick Romero wrote: Hey all, I'm currently testing out Pegasus Mail, and I've noticed three issues that I would like to help with debugging. > ... The second issue, I've noticed that double-clicking the system tray icon does notrestore Pegasus Mail. I can minimize it so it appears both on the taskbar and the system tray, but I can't restore the application from the system tray icon (though I can from the taskbar). This can be fixed by this patch: http://www.winehq.com/hypermail/wine-patches/2002/08/0094.html Alexandre did not like the way I did that, so hopefully you can figure out the right fix :-)
Page faults
Having just added more memory to prevent the disk swapping I was encountering, I now seem to be crashing with a page fault. I don't really know enough about how the memory is handled. Is this likely to be a wine bug? I am running native versions of msvcrt and mfc42, but pretty much builtin for everything else. This is running Xilinx fpga_editor. When running on this particular design, it appears to use about 350MB of RAM. Unhandled exception: page fault on write access to 0x9c5a7c4c in 32-bit code (0x7800d77a). 0x7800d77a (MSVCRT.DLL._set_sbh_threshold+0x6de in C:\WINDOWS\SYSTEM\MSVCRT.DLL): movl %ecx,0xfffc(%ecx,%edx,1) Wine-dbg>bt Backtrace: =>0 0x7800d77a (MSVCRT.DLL._set_sbh_threshold+0x6de in C:\WINDOWS\SYSTEM\MSVCRT.DLL) (ebp=4048f768) 1 0x7800ccf7 (MSVCRT.DLL.??_V@YAXPAX@Z+0xe4 in C:\WINDOWS\SYSTEM\MSVCRT.DLL) (ebp=4048f7a0) 2 0x78001026 (MSVCRT.DLL..text+0x26 in C:\WINDOWS\SYSTEM\MSVCRT.DLL) (ebp=405a2dcc) 3 0x5f40b4fe (MFC42.DLL.1576+0x52 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405a2e8c) 4 0x400c53fc (start_process+0x258 [process.c:564] in libntdll.dll.so) (ebp=405a2f38)
