Re: Still need help fixing deadlock (GDI/metafile)
Hi Cihan, What happens if you comment out #define STRETCH_VIA_DIB in dlls/gdi/mfdrv/bitblt.c? This will make it use GetBitmapBits instead of GetDIBits. - Walter On Wed, 11 Jan 2006, Cihan Altinay wrote: > Since nobody seems to be able to help me with this problem at the moment > I opened a bug report[1] for it. I would appreciate if somebody with > more knowledge could take a quick look at it. Thanks! > > Cihan > > [1] http://bugs.winehq.org/show_bug.cgi?id=4284 > > > Cihan Altinay wrote: > > Hi, > > > > I am still trying to finding the reason for PowerPoint 2000 causing a > > deadlock if a file is opened that contains a preview which itself > > contains a bitmap >90x90 pixels (ie. on the first slide). > > After inserting some traces I feel I am pretty close but I'm > > stuck since before the holidays. The problem is connected to GDI's > > and/or metafile's StretchBlt (bitblt.c). > > It calls MFDRV_StretchBlt and then the trouble begins as can be seen > > from the output: > > > > > > trace:bitblt:StretchBlt --Start-- > > trace:gdi:GDI_GetObjPtr (0x3b0c): enter 1 > > trace:dc:DC_GetDCPtr > > trace:gdi:GDI_ReleaseObj (0x3b0c): leave 1 > > trace:gdi:GDI_GetObjPtr (0x3aec): enter 1 > > trace:dc:DC_GetDCPtr > > trace:gdi:GDI_GetObjPtr (0x3b0c): enter 2 > > trace:dc:DC_GetDCPtr > > trace:bitblt:StretchBlt 0x3aec 0,0 160x120 -> 0x3b0c 0,0 960x720 rop=cc0020 > > trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 > > trace:dc:DC_GetDCPtr > > trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 > > trace:gdi:GetObjectW 0x3af8 24 0x7fc2f760 > > trace:gdi:GDI_GetObjPtr (0x3af8): enter 3 > > trace:gdi:GDI_ReleaseObj (0x3af8): leave 3 > > trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 > > trace:dc:DC_GetDCPtr > > trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 > > trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 > > trace:dc:DC_GetDCPtr > > trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 > > trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 > > trace:dc:DC_GetDCPtr > > trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 > > trace:metafile:MFDRV_StretchBlt MF_StretchBltViaDIB->len = 20292 rop=cc0020 > > PixYPM=3780 Caps=96 > > trace:bitmap:GetDIBits > > trace:dc:CreateCompatibleDC --Checking lock-- hdc=0x3aec > > err:syslevel:_CheckNotSysLevel Holding lock 0x7fad49e0 level 3 > > > > > > Yes well... hdcDst and hdcSrc aren't freed yet from within StretchBlt. > > There is a comment "FIXME: there is a race condition here". Could that > > be the cause for the deadlock? > > Btw. this might be the same problem as bug #3125 as both refer to the > > preview and both cause a deadlock. > > > > Can somebody give me a hint on how to tackle this? It is really important > > for us... If you need more output please let me know. > > > > Thanks a lot, > > Cihan > > > > > > > > >
Re: RFC/PATCH: avoid metafilevirus problems
On Mon, 2 Jan 2006, Marcus Meissner wrote: > Hi, > > requesting comments... > > This patch reduces the attack vector on metafiles. > > I originally wanted to filter only SETABORTPROC, > but there are a lot of things that might be used > to inject code. > > Comments? Would it not be better to block it in the gdi Escape function? Or is SETABORTPROC legitimitely needed in some cases outside of metafiles?
Re: Small visual issues with P-CAD2000 and wine 0.9
Yes, Marcos sent another message with pictures of what the buttons look like under Windows and Wine, but he didn't send it to the list. I forwarded it to the list and you can see it here: http://www.winehq.org/pipermail/wine-devel/2005-November/041863.html - Walter On Thu, 3 Nov 2005, Kuba Ober wrote: > On Monday 31 October 2005 17:39, Walt Ogburn wrote: > > Hi Marcos, > > > > What are the buttons supposed to look like? The ones in your screenshot > > look OK to me. > > You do see that the bottom edge of each tool button is cut off, right? I don't > think that's OK :) > > Kuba > >
Re: Small visual issues with P-CAD2000 and wine 0.9 (fwd)
Please remember to send to the whole list. - Walter -- -- Forwarded message -- Date: Tue, 1 Nov 2005 07:22:33 -0200 From: Marcos Vicente Cruz <[EMAIL PROTECTED]> To: Walt Ogburn <[EMAIL PROTECTED]> Subject: Re: Small visual issues with P-CAD2000 and wine 0.9 Hi, OK, I'm putting together a image taken from a Windows98 machine. Note that every button drawn on Wine is cut by the bottom side. Marcos Em Monday 31 October 2005 20:39, você escreveu: > Hi Marcos, > > What are the buttons supposed to look like? The ones in your screenshot > look OK to me. > > On Mon, 31 Oct 2005, Marcos Vicente Cruz wrote: > > HI, > > > > I having small visual issues in P-CAD 2000's toolbar on Linux since I've > > upgraded to wine 0.9. The buttons aren't displayed properly. See the > > screenshot attached. > > > > Thank you, > > > > Marcos pcad-windows.png Description: PNG image pcad-wine.png Description: PNG image
Re: Small visual issues with P-CAD2000 and wine 0.9
Hi Marcos, What are the buttons supposed to look like? The ones in your screenshot look OK to me. On Mon, 31 Oct 2005, Marcos Vicente Cruz wrote: > HI, > > I having small visual issues in P-CAD 2000's toolbar on Linux since I've > upgraded to wine 0.9. The buttons aren't displayed properly. See the > screenshot attached. > > Thank you, > > Marcos >
Re: killing wine dregs
Does wineserver -k not work for you? On Mon, 31 Oct 2005 [EMAIL PROTECTED] wrote: > > I took the system right down to the login console and still cant clean up. > > Do I really have to reboot as the only way to clean up this mess? > > This is taking windows emulation too far!! ;) > >
Re: headless question, and IPC question
On Mon, 3 Oct 2005, Boaz Harrosh wrote: > Ken Larson wrote: > > > Thanks for the info. > > > > Ultimately, my app is a Java app. > > If I recall correctly someone has reported Installation of Sun's Java > for windows under wine. Or was it A failure to install? I can't recall. > How would you call a DLL on Windows? > Sun's JVM installs and runs. - Walter
Re: Off-topic, Was: Re: headless question, and IPC question
On Fri, 30 Sep 2005, Jakob Eriksson wrote: > Alex Villacís Lasso wrote: > > > > > > > You can try installing and configuring this X server. It will not > > output anything or use a console, but will behave otherwise like a > > valid X server. Then you should point the DISPLAY environment variable > > to this X server, and this will keep your app happy. However, I > > *strongly* recommend to try and create a true console-mode app before > > trying the virtual-framebuffer X server, because it will consume > > precious memory. > > > > You can also run a VNC server on the virtual X server. Then you can > leave and connect to your session > from any client computer, without shutting down your running X programs. > If it's not really trying to do anything graphical, maybe you could use ttydrv instead of xdrv.
Re: OleFont: Fix IDispatch Implementation (was Re: olefont: GetIDsOfNames)
On Wed, 14 Sep 2005, Robert Shearman wrote: > > You're not being lazy enough. All of this stuff can be easily > implemented in one go using CreateStdDispatch, as long as you know how > to use it. Try the attached patch. > > Changelog: > Return the standard font IDispatch interface created using > CreateStdDispatch on top of a typelib instead of manually implementing > the necessary methods. > Hi Robert, I'm not sure how to proceed here. My small patch makes the GetIDsOfNames in olefont work, so that programs that want to use GetIDsOfNames to get a DISPID code and then use Invoke to set font size, bold, etc. will work. With your bigger patch, IFontDisp uses the GetIDsOfNames from typelib.c, which also works, but it also uses the Invoke from typelib.c, which doesn't know how to set the font size, etc. Therefore, programs that try to get the DISPID code with GetIDsOfNames and then set some property with Invoke are broken at a different point after your patch. The thing is, I don't see how the Invoke in typelib.c can be made to get and set the font size, font weight, etc. correctly. It shouldn't know about the internal structure of OLEFontImpl, right? So how can it know that DISPID_FONT_WEIGHT and DISPID_FONT_BOLD mean doing doing different things to the same field in the OLEFontImpl, or where to find it? If you know how to make Invoke work again after your patch, that would be great. Otherwise, I could just re-submit my patch with the error handling corrected as Alexandre said. - Walter
Re: OleFont: Fix IDispatch Implementation (was Re: olefont: GetIDsOfNames)
Wait a minute, hold that - after this patch, you can't use Invoke any more to get and set the members of IFontDisp! With the current code, it works. Alexandre, please don't commit that yet. Thanks, Walter On Wed, 14 Sep 2005, Robert Shearman wrote: > Walt Ogburn wrote: > > >Changelog: > > Implement IFontDisp::GetIDsOfNames > > > > > > > > You're not being lazy enough. All of this stuff can be easily > implemented in one go using CreateStdDispatch, as long as you know how > to use it. Try the attached patch. > > Changelog: > Return the standard font IDispatch interface created using > CreateStdDispatch on top of a typelib instead of manually implementing > the necessary methods. > > -- > Rob Shearman > >
Re: OleFont: Fix IDispatch Implementation (was Re: olefont: GetIDsOfNames)
On Wed, 14 Sep 2005, Robert Shearman wrote: > > You're not being lazy enough. All of this stuff can be easily > implemented in one go using CreateStdDispatch, as long as you know how > to use it. Try the attached patch. > > Changelog: > Return the standard font IDispatch interface created using > CreateStdDispatch on top of a typelib instead of manually implementing > the necessary methods. > That doesn't look very lazy to me, but it simplifies olefont very nicely (300 fewer lines!). Please use this patch for GetIDsOfNames instead of mine. My patch for DispGetIDsOfNames and the test for IFontDisp_GetIDsOfNames are still OK. With Robert Shearman's big patch to olefont.c and my small one to typelib.c, the tests in my patch to tests/olefont.c all pass. Thanks, Walter
Re: GetIDsOfNames
On Mon, 12 Sep 2005, Robert Shearman wrote: > Walt Ogburn wrote: > > >... > >2. Call GetTypeInfo to get an ITypeInfo, and call DispGetIDsOfNames on > >that. I think this means that the information should be extracted from > >stdole32.tlb. Currently this doesn't find any match for these property > >names. Do they need to be added to stdole32.tlb somehow? > > > > Yes, the typelib approach is the correct one. You need to use > stdole2.tlb instead of stdole32.tlb though. > Right, thanks. I think that means that OLEFontImpl_GetTypeInfo needs to get IFontDisp from stdole2.tlb instead of IDispatch from stdole32.tlb. That way, you can use GetTypeInfo and DispGetIDsOfNames together to implement GetIDsOfNames. I'll submit some tests and proposed patches soon. - Walter
GetIDsOfNames
Hi guys, Eric Tanguy asked on wine-users a while back about getting some geography games (http://olivier.leflon.free.fr/jeux/jeux.htm) to run. These seem to be Visual Basic, so oleaut32 issues come up. We succeeded with the first one (departments of France - font size problem fixed). Next, there is the issue that some of them call GetIDsOfNames on ole font objects (countries of Europe, http://olivier.leflon.free.fr/jeux/europe.htm). OLEFontImpl_GetIDsOfNames is currently a stub. What's needed is basically just to convert the strings "Name", "Size", "Bold", etc. into DISPID_FONT_NAME, etc. In particular, this game only needs "Size." It's not hard to code that, and make the game work. I'm not sure, though, what the proper approach would be for an acceptable patch: 1. Just code in the string comparisons, ignoring the locale. (Google provides no evidence that the property names vary by locale). 2. Call GetTypeInfo to get an ITypeInfo, and call DispGetIDsOfNames on that. I think this means that the information should be extracted from stdole32.tlb. Currently this doesn't find any match for these property names. Do they need to be added to stdole32.tlb somehow? 3. Something else. Any ideas? Thanks, Walter
Re: [Wine]Softlinking to a dvd-drive with inconsistent mount points? => HAL-Support
Hi guys,
Sorry if I started a contentious discussion. I have looked into it a
little more and found some useful information. There was a discussion on
wine-devel about this topic back in March, which I had forgotten. You can
find a summary in the Wine newsletter from that month:
http://www.winehq.org/?issue=265#Drive%20Management
What I had in mind was not to break the current system, but to allow an
optional alternative method of mapping the drives, e.g. if you have
d: -> /mnt/cdrom
d:: -> /dev/hdc
everything will work like now, and if you only have
d:: -> /dev/hdc
wine will figure out where hdc is mounted and map DOS to Unix filenames
accordingly.
Looking at the code, though, that doesn't fit in very naturally with the
way wine actually does things. What I hadn't understood is that the
mapping of DOS to Unix filenames is purely an operation on strings, with
no disk access needed: Q:\foo\bar is translated to
~/.wine/dosdevices/q:/foo/bar regardless of whether ~/.wine/dosdevices/q:
points to anything meaningful or exists at all. This current system is
very neat and simple, and doing anything different would mean introducing
a significant amount of extra complication.
The other possibility is to have something in wineserver update the
dosdevices symlinks when volumes are mounted. That would also be a
significant amount of new stuff in wineserver.
Without doing anything to wine itself, there's one other option: set up a
HAL front-end like ivman (http://ivman.sourceforge.net/) to update the
dosdevices symlinks when volumes are mounted. This might be the right
aswer. A distro like SuSE that wants to use HAL and have things mounted
in different places can include ivman scripts in its wine package to
automatically do the right thing with the dosdevices links, and then
there's no problem. Or wine could check for ivman at the same time it
creates .wine, and set up appropriate ivman scripts if it finds it.
- Walter
On Sun, 28 Aug 2005, Detlef Riekenberg wrote:
> Am Samstag, den 27.08.2005, 14:38 -0700 schrieb Hiji:
>
> > It might be the ugly way, but it is the official way.
>
> That's because many Applications are unable to handle it yet.
>
> > This is definately *not* a Wine issue because it
> > affects any application which relies on have a static
> > name for the drive - let's make sure we're clear on
> > that. ;)
> No!
> This is not only a Wine issue, it's an issue of all applications which
> relies on static names.
> The big mistake: The Volume-Label is optional.
>
> It's possible on windows (since w2k) to work without a Driveletter for
> your CDROM, ("%SYSTEMROOT%\mountpoint") but they made the same mistake:
> Using a mountpoint (junction) is optional.
> When they used the mountpoint-method as default and the
> driveletter-method as optional fallback for old applications, then all
> important software would work today without an extra driveletter for
> removeable media.
>
> It's time to be more flexible. freedesktop.org did a step in the
> direction, now the applications must follow!
>
> > I suspect this "mounting by volume label"
> > won't last past Suse 9.3 since
>
> .. and go backwards? No way!
>
> > I haven't read anyone
> > praise this "feature" anywhere.
>
> That's the same when /dev/cdrom or /cdrom comes up as a link to the real
> device. It doesn't matter, on which controller, port and id your drive
> is connected; it just works.
> The link comes up and step by step more applications using this.
>
> And think about logical-volumes.
> Go backwards, because the admin will define on his own, which physical
> drive is used and mounted to a specific location?
> Logical volumes are present for ages in Novell Netware and other
> systems, arrived Windows since w2k and are working in linux for some
> years now.
>
>
> --
> By By ...
> ... Detlef
>
>
Re: Memory problem in winelib apps?
Thanks Mike. I think the fixed problem Chris mentioned was a different
one, so I'll see if I can make jack_fst work properly using your
suggestion.
- Walter
On Wed, 22 Jun 2005, Mike McCormack wrote:
>
> Walt Ogburn wrote:
>
> > #define BUFSIZE 1044096
> > /* #define BUFSIZE 200 */
> >
> > int PASCAL WinMain (HINSTANCE inst, HINSTANCE prev, LPSTR cmdline, int show)
> > {
> >char buf[BUFSIZE];
> >int i;
>
> Wine allocates a 1Mb stack by default, and more if a larger stack size
> is specified in a PE executeable's header. You can specify the size of
> the a .exe.so's stack by making a def file for it, and adding the line
>
> STACKSIZE 300
>
> that should fix the problem, however allocating a 2M buffer on the stack
> seems like a waste of stack space, so it would be better to fix the
> program to allocate memory on the heap, or directly using mmap.
>
> Mike
>
Re: Memory problem in winelib apps?
Thanks Chris. Mark, do you see the problem go away with a later Jack
version? I was just trying to see if I could understand better what was
going on when we were trying to get this working last year.
- Walter
On Tue, 21 Jun 2005, Chris Morgan wrote:
> This should have been fixed in jack around 20040325 with a jack to the jack
> variable, JACK_THREAD_STACK_TOUCH. The value was changed from 1048576
> (#define BIG_ENOUGH_STACK in client.c:jack_activate():1033 or so) and moved
> into configure.in.
>
> The change was made in this rev of configure.in:
>
> revision 1.253
> date: 2004/03/26 04:41:57; author: joq; state: Exp; lines: +17 -4
> [0.96.1] config fixes for shm; stack touch
>
>
> The reason jack does this is to ensure that all pages of the shared memory for
> all jack clients is mapped so there are no delays during excution. The value
> was reduced because wine was taking up a bunch of the stack and jack/wine
> were crashing.
>
> Which version of jack are you using? Which version of wine?
>
> The last time I tried jack under wine it didn't work but I wasn't able to
> figure out why this time and haven't gone back to it in a few months.
>
> Chris
>
>
>
>
> On Tuesday 21 June 2005 10:02 pm, Alex Villac??s Lasso wrote:
> > Walt Ogburn wrote:
> > >Hi developers,
> > >
> > >I'm trying to understand why the following simple program crashes. I
> > >think this is the same problem that prevents jack_fst from running with
> > >the current version of wine. (Jack_fst allows a lot of programs called
> > >VSTs to be run, for audio work).
> > >
> > >I compiled this with:
> > >>winemaker .
> > >>make
> > >
> > >and ran it with:
> > >>wine membug.exe.so
> > >
> > >If BUFSIZE is 1044097, there's an error like this:
> > >err:seh:setup_exception stack overflow 12 bytes in thread 0009 eip
> > > 4057426f esp 40580ff4 stack 0x4058-0x4068
> > >
> > >If BUFSIZE is 1044096 or lower, there's no error. If BUFSIZE is much
> > >higher (like 200), there's a segfault.
> > >
> > >All the program does is define a character array of size BUFSIZE and
> > >scribble in it to make sure it really gets allocated. Maybe this simple
> > >example will show how to make jack_fst work.
> > >
> > >Thanks,
> > >Walter
> > >
> > >
> > >
> > >#include "windows.h"
> > >
> > >#define BUFSIZE 1044096
> > >/* #define BUFSIZE 200 */
> > >
> > >int PASCAL WinMain (HINSTANCE inst, HINSTANCE prev, LPSTR cmdline, int
> > > show) {
> > > char buf[BUFSIZE];
> > > int i;
> > >
> > > for (i=0; i > > {
> > > buf[i] = (char) (i % 256);
> > > }
> > >
> > > return 0;
> > >}
> >
> > Your sample program is trying to use almost 1 megabyte (!) of stack
> > space. No wonder it crashes. Are you sure that your program jack_fst is
> > trying to allocate such an enormous amount of stack space? Most (sane)
> > programs would just declare a pointer and allocate the required space
> > via malloc() or HeapAlloc().
> >
> > Where can somebody else get a copy of jack_fst? Is there a public
> > download somewhere?
> > Maybe jack_fst corrupts the stack in some strange way that was
> > misdiagnosed as as request for a 1Mb stack?
>
>
Memory problem in winelib apps?
Hi developers,
I'm trying to understand why the following simple program crashes. I
think this is the same problem that prevents jack_fst from running with
the current version of wine. (Jack_fst allows a lot of programs called
VSTs to be run, for audio work).
I compiled this with:
> winemaker .
> make
and ran it with:
> wine membug.exe.so
If BUFSIZE is 1044097, there's an error like this:
err:seh:setup_exception stack overflow 12 bytes in thread 0009 eip 4057426f esp
40580ff4 stack 0x4058-0x4068
If BUFSIZE is 1044096 or lower, there's no error. If BUFSIZE is much
higher (like 200), there's a segfault.
All the program does is define a character array of size BUFSIZE and
scribble in it to make sure it really gets allocated. Maybe this simple
example will show how to make jack_fst work.
Thanks,
Walter#include "windows.h"
#define BUFSIZE 1044096
/* #define BUFSIZE 200 */
int PASCAL WinMain (HINSTANCE inst, HINSTANCE prev, LPSTR cmdline, int show)
{
char buf[BUFSIZE];
int i;
for (i=0; i
Re: flexible-mmap breaks application
On Thu, 10 Mar 2005, Uwe Bonnes wrote: > > Setting /proc/sys/vm/legacy_va_layout, like proposed by Ingo, lets the app > finally run. > To Mark Knecht: If you have a copy of jack_fst without the special memory allocation hack, you might try it and see if this suggestion makes any difference. Maybe this is the same memory allocation issue. - Walter
Re: Warnings left when compiling on GNU/Linux
Hi Gerald, The metafile.c warning is because of a test that is commented out in dlls/gdi/test/metafile.c. It's commented out instead of protected with todo because it doesn't just fail, it crashes. Perhaps the rtlstr test warnings are there for similar reasons. There's a patch to make the metafile test pass, which also un-comments the test, at http://www.winehq.org/hypermail/wine-patches/2004/12/0191.html The patch hasn't been committed, but if anybody wants to make it nicer and try again, feel free to do so. Thanks, - Walter On Wed, 5 Jan 2005, Gerald Pfeifer wrote: > When compiling on SUSE LINUX 9.2 using GCC 3.3.5 the following are the > only warnings I'm getting for current Wine CVS: > > metafile.c:395: warning: `test_mf_PatternBrush' defined but not used > rtlstr.c:552: warning: `test_RtlUpcaseUnicodeChar' defined but not used > rtlstr.c:578: warning: `test_RtlUpcaseUnicodeString' defined but not used > rtlstr.c:629: warning: `test_RtlDowncaseUnicodeString' defined but not used > hlp2sgml.c:219: warning: `%x' yields only last 2 digits of year in some > locales > > On FreeBSD 4.10 using GCC 3.3.4 I am also seeing the following one: > > fd.c:572: warning: right shift count >= width of type > fd.c:574: warning: right shift count >= width of type > > Any chance we could get rid of these? :-) > > Gerald >
Re: "Debugging" a password dialog
Sorry, I was thinking of the debug channels, but I don't know which ones to use, short of turning on "trace+all." - Walter On Sat, 11 Dec 2004, David [iso-8859-1] Gümbel wrote: > On Samstag 11 Dezember 2004 01:42, Walt Ogburn wrote: > > Dump a trace into a file, then grep for the username and password you > > entered? > > Are you refering to using something like strace, or would you use a debug > channel? If a debug channel, which ?-) > > > > Bye, and thanks for your input! > > > David > >
Re: "Debugging" a password dialog
Dump a trace into a file, then grep for the username and password you entered? On Fri, 10 Dec 2004, David [iso-8859-15] Gümbel wrote: > Hi everybody, > > > > > I am trying to get an application to run under Wine that requires a login > with a username and a password. The program runs all fine, however I can't > login with data that should work (and AFAIK works under Windows). > > Having entered the password, in the corresponding part of the dialog I only > see "*" (which is correct). However, when I change focus to some other > part of that dialog afterwards, the password field shows > "*" (way more asterisks than before). The previous (i.e. > correct) length of s is restored when setting the focus back onto the > password field. > > I have reason to believe that the password I entered is not correctly passed > on to the login procedure of the program. However, I am sort of badly > lacking a nice idea how to efficiently debug this thingy and verify > (falsify ;) that I'm right. So, does anybody have an idea? > > > > Bye, > > > > David >
Re: dlls/gdi/tests/metafile.c warning about test_mf_PatternBrush
Hi Gerald, It's commented out because the test currently crashes under Wine. I submitted one patch earlier, but the metafile records weren't the same as the correct Windows values and it didn't get committed. Now that there's a test I'll work on another patch. - Walter On Thu, 9 Dec 2004, Gerald Pfeifer wrote: > The following patch to dlls/gdi/tests/metafile.c > > revision 1.3 > date: 2004/12/09 11:37:59; author: julliard; state: Exp; lines: +236 -0 > Walt Ogburn <[EMAIL PROTECTED]> > Added some tests for win-format metafiles. > > introduces the following warning: > > metafile.c:381: warning: `test_mf_PatternBrush' defined but not used > > Should we put #ifdefs around the definition, or enable the following > code in the main test function? > > /* Crashes under wine: */ > /* test_mf_PatternBrush(); */ > > Another option would be not to make this function static. > > Gerald >
gdi/metafile tests
To Dmitry Timoshkov -
I have started working on some tests (attached here) for metafile
functions in gdi. If these seem reasonable, should I add them to your
metafile.c test code, or move yours to enhmetafile.c and start a new
metafile.h?
Thanks,
Walter/*
* Unit tests for metafile functions
*
* Copyright (c) 2004 R. Walter Ogburn IV
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include "wine/test.h"
#include "winbase.h"
#include "wingdi.h"
#include "winuser.h"
#include "winerror.h"
#include
/* Maximum size of sample metafiles in bytes. */
#define MF_BUFSIZE 256
/* 8x8 bitmap data for a pattern brush */
static const unsigned char SAMPLE_PATTERN_BRUSH[] = {
0x00, 0x00, 0x00, 0x00,
0x55, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
0xaa, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
0x55, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
0xaa, 0x00, 0x00, 0x00
};
/* Sample metafiles to be compared to the outputs of the
* test functions.
*/
static const unsigned char MF_BLANK_BITS[] = {
0x01, 0x00, 0x09, 0x00, 0x00, 0x03, 0x0c, 0x00,
0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00,
0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00,
};
static const unsigned char MF_GRAPHICS_BITS[] = {
0x01, 0x00, 0x09, 0x00, 0x00, 0x03, 0x22, 0x00,
0x00, 0x00, 0x00, 0x00, 0x07, 0x00, 0x00, 0x00,
0x00, 0x00, 0x05, 0x00, 0x00, 0x00, 0x14, 0x02,
0x01, 0x00, 0x01, 0x00, 0x05, 0x00, 0x00, 0x00,
0x13, 0x02, 0x02, 0x00, 0x02, 0x00, 0x05, 0x00,
0x00, 0x00, 0x14, 0x02, 0x01, 0x00, 0x01, 0x00,
0x07, 0x00, 0x00, 0x00, 0x18, 0x04, 0x02, 0x00,
0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00,
0x00, 0x00, 0x00, 0x00
};
static const unsigned char MF_PATTERN_BRUSH_BITS[] = {
0x01, 0x00, 0x09, 0x00, 0x00, 0x03, 0x3d, 0x00,
0x00, 0x00, 0x01, 0x00, 0x2d, 0x00, 0x00, 0x00,
0x00, 0x00, 0x2d, 0x00, 0x00, 0x00, 0x42, 0x01,
0x03, 0x00, 0x00, 0x00, 0x28, 0x00, 0x00, 0x00,
0x08, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
0x01, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00,
0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00,
0xaa, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x55, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00,
0x2d, 0x01, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00,
0x00, 0x00
};
/* For debugging or dumping the raw metafiles produced by
* new test functions.
*/
static void dump_mf_bits (const HMETAFILE mf, const char *desc)
{
char buf[MF_BUFSIZE];
UINT mfsize;
int i;
mfsize = GetMetaFileBitsEx (mf, MF_BUFSIZE, buf);
ok (mfsize > 0, "%s: GetMetaFileBitsEx failed.\n", desc);
printf ("MetaFile %s has bits:\n{\n", desc);
for (i=0; i 0, "%s: GetMetaFileBitsEx failed.\n", desc);
if (mfsize < MF_BUFSIZE)
ok (mfsize == bsize, "%s: mfsize=%d, bsize=%d.\n",
desc, mfsize, bsize);
else
ok (bsize >= MF_BUFSIZE, "%s: mfsize > bufsize (%d bytes), bsize=%d.\n",
desc, mfsize, bsize);
if (mfsize != bsize)
return -1;
diff = 0;
for (i=0; ilbStyle = BS_PATTERN;
orig_lb->lbColor = RGB(0, 0, 0);
orig_lb->lbHatch = (INT) CreateBitmap (8, 8, 1, 1, SAMPLE_PATTERN_BRUSH);
ok((HBITMAP *)orig_lb->lbHatch != NULL, "CreateBitmap error %ld.\n", GetLastError());
hBrush = CreateBrushIndirect (orig_lb);
ok(hBrush != 0, "CreateBrushIndirect error %ld\n", GetLastError());
hdcMetafile = CreateMetaFileA(NULL);
ok(hdcMetafile != 0, "CreateMetaFileA error %ld\n", GetLastError());
trace("hdcMetafile %p\n", hdcMetafile);
hBrush = SelectObject(hdcMetafile, hBrush);
ok(hBrush != 0, "SelectObject error %ld.\n", GetLastError());
/* ok(ExtFloodFill(hdcMetafile, 1, 1, RGB(0, 0, 0), FLOODFILLSURFACE),
"FloodFill failed."); */
hMetafile = CloseMetaFile(hdcMetafile);
ok(hMetafile != 0, "CloseMetaFile error %ld\n", GetLastError());
ok(!GetObjectType(hdcMetafile), "CloseMetaFile has to destroy metafile hdc\n");
if (compare_mf_bits (hMetafile, MF_PATTERN_BRUSH_BITS, sizeof(MF_PATTERN
Re: gdi/mfdrv BS_PATTERN brushes
Hi Huw, You're right, it's a META_DIBCREATEPATERNBRUSH under XP at least. I think I understand this better now. I'll hold off on the patch and try to write some tests. I don't think there's any easy way to fix the problems in the current code without changing it to META_CREATEPATTERNBRUSH. Thanks. Walter On Tue, 30 Nov 2004, Huw D M Davies wrote: > On Mon, Nov 29, 2004 at 09:16:49PM -0800, Walt Ogburn wrote: > > > > This fixes the problem that Emanuele Gisi reported last month in the Aloha > > problem. With this patch BS_PATTERN brushes get created correctly and > > don't cause a locking problem. > > > > Changelog: > > Fix creation of BS_PATTERN brushes in mfdrv > > > > > > Index: dlls/gdi/mfdrv/objects.c > > === > > RCS file: /home/wine/wine/dlls/gdi/mfdrv/objects.c,v > > retrieving revision 1.14 > > diff -u -r1.14 objects.c > > --- dlls/gdi/mfdrv/objects.c22 Nov 2004 18:19:59 - 1.14 > > +++ dlls/gdi/mfdrv/objects.c30 Nov 2004 06:10:03 - > > > > - mr->rdFunction = META_DIBCREATEPATTERNBRUSH; > > + mr->rdFunction = META_CREATEPATTERNBRUSH; > > Does a BS_PATTERN brush really create a META_CREATEPATTERNBRUSH record > under Windows? > > Huw. > -- > Huw Davies > [EMAIL PROTECTED] >
Re: keyboard: ISO_Left_Tab
Hi Andreas,
On (a), you are certainly correct. I'll swap the order and resubmit.
As for (b), the "if (ret == 0)" just below is followed by an "else" which
does the actual unicode conversion. I wanted to put in the tab character
and change ret to 1 in time to get into the "else". It the ISO_Left_Tab
check went under the existing "if (ret == 0)", it would have to have its
own MultiByteToWideChar call, or use a goto. This way seemed a lot more
readable.
Thanks,
Walter
On Sat, 6 Nov 2004, Andreas Mohr wrote:
> Hi,
>
> On Sat, Nov 06, 2004 at 07:30:20AM -0800, Walt Ogburn wrote:
> > +/* Special case: X turns shift-tab into ISO_Left_Tab. */
> > +/* Here we change it back. */
> > +if ((ret == 0) && (keysym == XK_ISO_Left_Tab))
> > +{
> > +ret = 1;
> > + lpChar[0] = 0x09;
> > +}
> > +
> > if (ret == 0)
> > {
> > BYTE dead_char;
>
> Two comments:
> a) A return value of 0 probably is much more common than the XK_ISO_Left_Tab
> keysym, so the XK_ISO_Left_Tab check should be first to not have to check both
> conditions in the event that ret is 0.
> (the compiler might do reordering according to check probability, though,
> but OTOH I doubt that it knows which one is more likely)
> b) there's another if (ret == 0) *right below*, so why not add the
> XK_ISO_Left_Tab check there? Again useless waste of resources...
>
> Thanks for this patch!
>
> Andreas Mohr
>
Re: err:keyboard:X11DRV_ToUnicodeEx Please report:
Hi Jon,
It looks to me like shift-tab works fine when it's used to navigate around
dialogs. It's only in things like text input that it tries to get
converted to Unicode and doesn't match anything.
Do you know what shift-tab does under such circumstances in Windows? If
it's the same as regular tab, you could just map ISO_Left_Tab onto tab,
like below.
- Walter
diff -urN wine-cvs/dlls/x11drv/keyboard.c wine/dlls/x11drv/keyboard.c
--- wine-cvs/dlls/x11drv/keyboard.c 2004-10-27 20:11:23.0 -0700
+++ wine/dlls/x11drv/keyboard.c 2004-11-05 08:23:28.557190200 -0800
@@ -2143,6 +2143,12 @@
ret = XLookupString(&e, lpChar, sizeof(lpChar), &keysym, NULL);
wine_tsx11_unlock();
+if (keysym == XK_ISO_Left_Tab)
+{
+ret = 1;
+lpChar[0] = 0x09;
+}
+
if (ret == 0)
{
BYTE dead_char;
On Fri, 5 Nov 2004, Jon Griffiths wrote:
> Hi,
>
> Duly reporting:
>
> err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym
> FE20 (ISO_Left_Tab) :
> err:keyboard:X11DRV_ToUnicodeEx
> (virtKey=9,scanCode=F,keycode=17,state=1)
>
> This happens when I shift-tab in any Wine app. System is mdk
> 10.0/wine cvs and this message has been there for several months at
> least (when I first noticed).
>
> I'm happy to provide more info on request if someone knows how to fix
> this.
>
> Cheers,
> Jon
>
>
> =
> "Don't wait for the seas to part, or messiahs to come;
> Don't you sit around and waste this chance..." - Live
>
> [EMAIL PROTECTED]
>
>
>
> __
> Do you Yahoo!?
> Check out the new Yahoo! Front Page.
> www.yahoo.com
>
>
>
Re: gdi/dib.c GetDIBits
Thanks Huw. Actually, when GetDIBits gets invoked by the SelectBrush
code, it winds up in an unimplemented part anyway, so the current brush
code needs a different fix than just preventing the locking problem.
I'll try to see if the GetDIBits call can be replaced with something else
that works right, and otherwise just put in a FIXME so that the result
will be a slightly wrong brush instead of a crash.
Here's the part of the GetDIBits code that it winds up in, in case you're
interested. It's the commented FIXME.
Thanks,
Walter
/* Otherwise, get bits from the XImage */
else
{
if (!bmp->funcs && !BITMAP_SetOwnerDC( hbitmap, dc )) lines = 0;
else
{
if (bmp->funcs && bmp->funcs->pGetDIBits)
lines = bmp->funcs->pGetDIBits( dc->physDev, hbitmap, startscan,
lines, bits, info, coloruse );
else
lines = 0; /* FIXME: should copy from bmp->bitmap.bmBits */
}
}
On Thu, 4 Nov 2004, Huw D M Davies wrote:
> On Wed, Nov 03, 2004 at 09:24:08PM -0800, Walt Ogburn wrote:
> >
> > Changelog:
> > Take color info from existing hdc instead of creating a new memory HDC.
> >
> >
> > Index: dlls/gdi/dib.c
> > ===
> > RCS file: /home/wine/wine/dlls/gdi/dib.c,v
> > retrieving revision 1.7
> > diff -u -r1.7 dib.c
> > --- dlls/gdi/dib.c 2 Nov 2004 05:23:49 - 1.7
> > +++ dlls/gdi/dib.c 4 Nov 2004 05:08:24 -
> > @@ -563,7 +559,7 @@
> >same color depth then get the color map from it */
> > if (bmp->dib && bmp->dib->dsBm.bmBitsPixel == bpp) {
> > if(coloruse == DIB_RGB_COLORS) {
> > -HBITMAP oldbm = SelectObject(memdc, hbitmap);
> > +HBITMAP oldbm = SelectObject(hdc, hbitmap);
> > unsigned int colors = 1 << bpp;
> >
> > if (core_header)
>
> This won't always work since hdc does not necessarily have to be a
> memory dc.
>
> I think what you want to do is to store the dib colour table in the
> gdi bmp->dib structure rather than in the driver's (x11drv) one. Then
> retrieving the colour table can be done by simply accessing the data
> directly, rather than through a call to GetDIBColorTable.
>
> Huw.
> --
> Huw Davies
> [EMAIL PROTECTED]
>
Re: [Wine]How to help improving Wine?
Hi Emanuele, After poking around a bit, there seems to be a logical problem in Wine's GDI code. From the backtrace, SelectObject on this object calls BRUSH_SelectObject, which uses a bitmap and eventually GetDIBits, which tries to CreateCompatibleDC (or sometimes DeleteDC instead). However, SelectObject always calls GDI_GetObjPtr, which calls _EnterSysLevel and not _LeaveSysLevel. But the CreateCompatibleDC complains and dies if you have had an _EnterSysLevel and not a _LeaveSysLevel. It might be that BRUSH_SelectObject really should use a different set of "internal" functions that won't complain about locking. Or maybe DeleteDC and CreateCompatibleDC should just increment the recursion level instead of erroring out. I don't know, so I'm forwarding to wine-devel for greater insight. - Walter Here's a summary of the relevant part of my backtrace again: 1 _CheckNotSysLevel (complains!) 2 GDI_CheckNotLock 3 DeleteDC 4 GetDIBits 5 MFDRV_CreateBrushIndirect 6 MFDRV_SelectBrush 7 BRUSH_SelectObject 8 SelectObject - calls GDI_GetObjPtr, which does _EnterSysLevel. On Thu, 28 Oct 2004, Emanuele Gissi wrote: > Hi, > I really did my best to understand how I can help improving Wine, but I did > not succed. > > Well, everything started when I installed a win application on my Debian 3.1, > Wine 2004.07.16 deb (clean install, no dlls). > > The application is ALOHA (http://www.epa.gov/ceppo/cameo/aloha.htm) > It's a free application from US-Environment Protection Agency used for > chemical emergency planning (I am an officer firefighter). > > On Wine it has a problem that prevents its wide use. > After having entered all the needed data (or loading the included prova.alo > example in "planning mode"), Wine crashes when tring to show the chemical > footprint result. > > The application works perfectly on Codeweavers Crossover Office 3.0.1 (trial). > And I am ready to buy it (as they support the free Wine, I think.) > > But I would like to understand why it does not work on Wine! > > The included log finishes with this: > [...] > warn:heap:HEAP_ValidateInUseArena Heap 4036: invalid in-use arena magic > for 403bd120 > warn:heap:HEAP_ValidateInUseArena Heap 4036: invalid in-use arena magic > for 403b46f0 > warn:heap:HEAP_ValidateInUseArena Heap 4036: invalid in-use arena magic > for 403b6948 > warn:heap:HEAP_ValidateInUseArena Heap 4036: invalid in-use arena magic > for 403b1570 > warn:heap:HEAP_ValidateInUseArena Heap 4036: invalid in-use arena magic > for 403b11c0 > warn:gdi:GDI_GetObjPtr Invalid handle (nil) > warn:gdi:GDI_GetObjPtr Invalid handle (nil) > warn:gdi:GDI_GetObjPtr Invalid handle (nil) > err:syslevel:_CheckNotSysLevel Holding lock 0x408f15e0 level 3 > wine: Unhandled exception (thread 0009), starting debugger... > > 1) What should I do next time I encounter a similar problem with an app? That > is: how to use winedbg? > 2) Why does ALOHA work on Crossover and not on Wine? > 3) Which are the main differences between Crossover and Wine? > 4) Does Codewaver really contribute back to Wine? > > I thank you in advance. > > (Please, CC: me as I am not on the list for now) > -- > Ing. Emanuele Gissi - Ispettore Antincendio > Comando Provinciale dei Vigili del Fuoco di Ravenna > viale Randi, 25 - 48100 Ravenna - Italia > tel: 0544 281.501 - fax: 0544 281.531 >
Writing tests
Hi folks,
I have a question about dependencies when writing tests. Some tests use
LoadLibraryA and GetProcessAddress to get access to Windows / Wine APIs,
and other tests just include the appropriate header files and link to the
DLLs. One example of the first type is dlls/oleaut32/olefont.c:
==
static HMODULE hOleaut32;
static HRESULT (WINAPI
*pOleCreateFontIndirect)(LPFONTDESC,REFIID,LPVOID*);
START_TEST(olefont)
{
LPVOID pvObj = NULL;
HRESULT hres;
IFont* font = NULL;
hOleaut32 = LoadLibraryA("oleaut32.dll");
pOleCreateFontIndirect = (void*)GetProcAddress(hOleaut32,
"OleCreateFontIndirect");
if (!pOleCreateFontIndirect)
return;
=
What is the reason for this difference? Which example should new tests
follow? My guess is that LoadLibraryA and GetProcAddress are used if the
headers, DLLs, and APIs might not be present on some Windows machines, so
that the tests don't fail. If that's correct, is there a list somewhere
of which ones are safe and which ones should be handled like in the
olefont test?
Thanks,
Walter
Re: WineHQ: Assorted spelling fixes
s/concensus/consensus On Tue, 26 Oct 2004, Filip Navara wrote: > Francois Gouget wrote: > > >Index: wwn/wn20041015_244.xml > >=== > >RCS file: /var/cvs/lostwages/wwn/wn20041015_244.xml,v > >retrieving revision 1.1 > >diff -u -r1.1 wn20041015_244.xml > >--- wwn/wn20041015_244.xml 15 Oct 2004 03:59:52 - 1.1 > >+++ wwn/wn20041015_244.xml 25 Oct 2004 23:10:22 - > >@@ -185,7 +185,7 @@ > > We discussed Jason Edmeades plans to work on > > Direct3D 9 a few weeks ago (see WWN issue > > http://www.winehq.com/?issue=240#DirectX%209%20Roadmap";>#240). > >-The concensus seemed to be created a shared library between > >+The concensus seemed to be ro create a shared library between > > > s/to be ro/to be to/ > >
Re: Problems downloading the RedHat packages
I can't download the RH 20041019 packages either: "The mirror you've selected, telia.dl.sourceforge.net does not currently have the file you requested." - Walter On Mon, 25 Oct 2004, Bill Medland wrote: > I am unable to download the RedHat 20041019 packages; any idea why? (Did they > get built?) > > I can download a SuSE one (well, it at least asks me if I want to save it) but > for all the Red Hat ones I've tried the mirror page keeps repeatedly coming > up and it never actually tries to download. > > -- > Bill Medland > mailto:[EMAIL PROTECTED] > http://webhome.idirect.com/~kbmed > >
Re: Winedbg: watchpoints broken?
Hi Eric, I suspected that might be the case. It just takes a little bit of guessing to find the previous expression, since its size is not fixed. Thanks, Walter > > no, we should point to the correct insn, I'll look into it. > in fact, it'll be hard to change it. ia-32 reports insn after the one > that triggers the watch. The rationale beeing that you must execute the > insn in order to now of the write change (unlike a seg fault where you > cannot know execute the insn). > GDB behaves the same (it shows the line after the one that triggered the > watch). >
Re: Winedbg: watchpoints broken?
Hi Eric,
Thanks. That fixes the watchpoints, but introduces a couple of small
problems:
1) in dbg.y, break_add_watch_from_lvalue should take only one argument
(drop second argument)
2) in dbg.y, I have no minidump_write. Should this be replaced with
dbg_printf("%s\n", $2); ?
After fixing these two things, breakpoints work, although the instruction
pointer displayed is the one just after the watched address gets written
to. Perhaps this is the expected behavior, but it would be nice to have
the instruction that makes the write instead.
- Walter
On Wed, 20 Oct 2004, Eric Pouech wrote:
> Walt Ogburn a écrit :
> > Hi,
> >
> > Winedbg's watchpoints don't seem to work for me: when I try to watch a
> > memory location, winedbg responds that a watchpoint has been set at a
> > different, always constant location (I suspect this is actually in
> > winedbg's memory space). Nothing happens when the location I was trying
> > to watch changes.
> does the attached patch help ?
> A+
>
>
Re: oleaut32: SafeArrayDestroyData
Hi hans, Thanks, I hadn't thought of doing it that way. That was very useful. The result is that SafeArrayDestroyData shouldn't do anything if FADF_STATIC is set for that array. I'll submit a test and a fix for that. - Walter On Mon, 18 Oct 2004, Hans Leidekker wrote: > On Monday 18 October 2004 19:19, Walt Ogburn wrote: > > > Also, is there a way to make the tests in oleaut32/tests/ run on the > > native dlls? If so, I could more clearly show that the Windows version > > doesn't null pvData. > > Wine's build system has support for cross compiling tests into PE > executables with MinGW. You can then run these on Windows of course, > or on Wine with: > > WINEDDLOVERRIDES="oleaut32=n" wine oleaut32_crosstest.exe > > after you've put a native oleaut32.dll in ~/.wine/drive_c/windows/system > Cross compiling tests is documented here: > > http://winehq.org/site/docs/wine-devel/cross-compiling-tests > > Alternatively you could carry over the source for the tests to a > Visual C installation and it should build there as well. This > is also documented on the site. > > -Hans >
oleaut32: SafeArrayDestroyData
Hi,
I am working on getting a scientific / engineering application called
SRIM (www.srim.org), specifically the batch-mode component SRModule of
SRIM 2003. This is a Visual Basic program, so there's lots of reliance on
oleaut32.dll.
In addition to freeing the data memory of the SafeArray, Wine's
implementation of SafeArrayDestroyData sets the pointer pvData to
NULL. The native Windows version apparently does not do this, and SRIM
depends on pvData still pointing to the same place afterwards. Wine's
code also uses this nulling to keep track of the memory, so that it won't
get freed again. I can't say why a program would still want pvData after
a call to SafeArrayDestroyData, but there it is.
Could the flag FADF_DATADELETED be used to keep track of this instead?
That seems to be the case only for vector SafeArrays now. The following
patch seems to make SRIM work:
===
Index: dlls/oleaut32/safearray.c
===
RCS file: /home/wine/wine/dlls/oleaut32/safearray.c,v
retrieving revision 1.40
diff -u -r1.40 safearray.c
--- dlls/oleaut32/safearray.c 20 Sep 2004 19:11:48 - 1.40
+++ dlls/oleaut32/safearray.c 18 Oct 2004 17:03:51 -
@@ -1254,7 +1254,7 @@
if (psa->cLocks)
return DISP_E_ARRAYISLOCKED; /* Can't delete a locked array */
- if (psa->pvData)
+ if (psa->pvData && !(psa->fFeatures & FADF_DATADELETED))
{
/* Delete the actual item data */
if (FAILED(SAFEARRAY_DestroyData(psa, 0)))
@@ -1265,7 +1265,8 @@
{
if (!SAFEARRAY_Free(psa->pvData))
return E_UNEXPECTED;
- psa->pvData = NULL;
+ /* psa->pvData = NULL; */
+ psa->fFeatures |= FADF_DATADELETED;
}
else
psa->fFeatures |= FADF_DATADELETED; /* Mark the data deleted */
===
Also, is there a way to make the tests in oleaut32/tests/ run on the
native dlls? If so, I could more clearly show that the Windows version
doesn't null pvData.
Thanks,
Walter
Winedbg: watchpoints broken?
Hi,
Winedbg's watchpoints don't seem to work for me: when I try to watch a
memory location, winedbg responds that a watchpoint has been set at a
different, always constant location (I suspect this is actually in
winedbg's memory space). Nothing happens when the location I was trying
to watch changes.
Here is a cut-and-paste from my winedbg session. I try to watch memory
location 0x0041a5ec, but I can set other breakpoints and see that the
value has changed without the watchpoint taking effect.
---
Wine-dbg>run
In 32 bit mode.
0x4049a81f start_process+0xcf
[/home/reuben/project/wine/wine/dlls/kernel/../../include/winternl.h:1249]
in kernel32: jmp 0x4049a815 start_process+0xc5
[/home/reuben/project/wine/wine/dlls/kernel/process.c:1022] in kernel32
1249static inline void WINAPI DbgBreakPoint(void) { __asm__
__volatile__("int3"); }
1249static inline void WINAPI DbgBreakPoint(void) { __asm__
__volatile__("int3"); }
Wine-dbg>watch *0x0041a5ec
Watchpoint 1 at 0x405ae8c4
Wine-dbg>x 0x0041a5ec
Wine-dbg>break *0x004130ec
Breakpoint 2 at 0x004130ec
Wine-dbg>cont
fixme:ole:CoRegisterMessageFilter stub
Stopped on breakpoint 2 at 0x004130ec
Wine-dbg>x 0x0041a5ec
403e9d40
Wine-dbg>cond 2 $ecx==0x10
Wine-dbg>cont
Stopped on breakpoint 2 at 0x004130ec
Wine-dbg>x 0x0041a5ec
Wine-dbg>info break
Breakpoints:
2: y 0x004130ec (1)
stop when ($ecx == 16)
Watchpoints:
1: y 0x405ae8c4 on 4 bytes (W)
--
The fact that winedbg thinks the watchpoint is 0x405ae8c4 is especially
puzzling, but it's entirely possible that the confusion lies with me
rather than winedbg.
Thanks,
Walter
