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

Re: [Gdiplus 8/9] Implement GdipGetFontHeight
by Nikolay Sivov Aug. 18, 2008

Aug. 18, 2008

Adam Petaccia wrote: > --- > dlls/gdiplus/font.c | 18 ++++++++++++++++++ > dlls/gdiplus/gdiplus.spec | 2 +- > include/gdiplusflat.h | 2 ++ > 3 files changed, 21 insertions(+), 1 deletions(-) > > diff --git a/dlls/gdiplus/font.c b/dlls/gdiplus/font.c > index 0c78bd5..5e1a14e 100644 > --- a/dlls/gdiplus/font.c > +++ b/dlls/gdiplus/font.c > @@ -387,6 +387,24 @@ GpStatus WINGDIPAPI GdipCloneFont(GpFont *font, GpFont **cloneFont) > } > > /******************************************************************************* > + * GdipGetFontHeight [GDIPLUS.@] > + */ > +GpStatus WINGDIPAPI GdipGetFontHeight(GDIPCONST GpFont *font, > + GDIPCONST GpGraphics *graphics, REAL *height) > +{ > + REAL dpi; > + GpStatus stat; > + > + TRACE("%p %p %p\n", font, graphics, height); > + > + stat = GdipGetDpiX(graphics, &dpi); > Is it normal that you use GdipGetDpiX and not GdipGetDpiY? I'm not much familiar with fonts so treat it like a question. It seems to me that height is measured using another axis. > + if (stat != Ok) > + return stat; > + > + return GdipGetFontHeightGivenDPI(font, dpi, height); > +} > + > +/******************************************************************************* > * GdipGetFontHeightGivenDPI [GDIPLUS.@] > * PARAMS > * font [I] Font to retrieve DPI from > diff --git a/dlls/gdiplus/gdiplus.spec b/dlls/gdiplus/gdiplus.spec > index f1ad0d4..e37eeec 100644 > --- a/dlls/gdiplus/gdiplus.spec > +++ b/dlls/gdiplus/gdiplus.spec > @@ -267,7 +267,7 @@ > @ stdcall GdipGetFamilyName(ptr ptr long) > @ stdcall GdipGetFontCollectionFamilyCount(ptr ptr) > @ stdcall GdipGetFontCollectionFamilyList(ptr long ptr ptr) > -@ stub GdipGetFontHeight > +@ stdcall GdipGetFontHeight(ptr ptr ptr) > @ stdcall GdipGetFontHeightGivenDPI(ptr long ptr) > @ stdcall GdipGetFontSize(ptr ptr) > @ stdcall GdipGetFontStyle(ptr ptr) > diff --git a/include/gdiplusflat.h b/include/gdiplusflat.h > index 17fae9c..f650e24 100644 > --- a/include/gdiplusflat.h > +++ b/include/gdiplusflat.h > @@ -425,6 +425,8 @@ GpStatus WINGDIPAPI GdipGetFamily(GpFont*, GpFontFamily**); > GpStatus WINGDIPAPI GdipGetFontUnit(GpFont*, Unit*); > GpStatus WINGDIPAPI GdipGetFontSize(GpFont*, REAL*); > GpStatus WINGDIPAPI GdipGetFontStyle(GpFont*, INT*); > +GpStatus WINGDIPAPI GdipGetFontHeight(GDIPCONST GpFont*, GDIPCONST GpGraphics*, > + REAL*); > GpStatus WINGDIPAPI GdipGetFontHeightGivenDPI(GDIPCONST GpFont*, REAL, REAL*); > > GpStatus WINGDIPAPI GdipCreateFontFamilyFromName(GDIPCONST WCHAR*, >

1 0

Re: [Gdiplus] Implement GdipCloneImage
by Huw Davies Aug. 18, 2008

Aug. 18, 2008

On Sat, Aug 16, 2008 at 11:26:42PM -0400, Adam Petaccia wrote: > This seems like the right thing to do, but OleLoadImage fails. > Comments welcome. > --- > dlls/gdiplus/image.c | 42 ++++++++++++++++++++++++++++++++++++++++-- > dlls/gdiplus/tests/image.c | 2 +- > 2 files changed, 41 insertions(+), 3 deletions(-) > > diff --git a/dlls/gdiplus/image.c b/dlls/gdiplus/image.c > index 197665d..a74003f 100644 > --- a/dlls/gdiplus/image.c > +++ b/dlls/gdiplus/image.c > @@ -242,11 +242,49 @@ GpStatus WINGDIPAPI GdipBitmapUnlockBits(GpBitmap* bitmap, > > GpStatus WINGDIPAPI GdipCloneImage(GpImage *image, GpImage **cloneImage) > { > + hr = OleLoadPicture(stream, size, FALSE, &IID_IPicture, > + (LPVOID*)(*cloneImage)->picture); This can't be right. You need to pass the address of the interface ptr. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: [Gdiplus 1/5] Tests for PrivateFontCollection
by Nikolay Sivov Aug. 18, 2008

Aug. 18, 2008

Adam Petaccia wrote: > --- > dlls/gdiplus/tests/font.c | 81 +++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 81 insertions(+), 0 deletions(-) > > diff --git a/dlls/gdiplus/tests/font.c b/dlls/gdiplus/tests/font.c > index 3d30a86..b19f0aa 100644 > --- a/dlls/gdiplus/tests/font.c > +++ b/dlls/gdiplus/tests/font.c > @@ -28,6 +28,7 @@ static const WCHAR arial[] = {'A','r','i','a','l','\0'}; > static const WCHAR nonexistent[] = {'T','h','i','s','F','o','n','t','s','h','o','u','l','d','N','o','t','E','x','i','s','t','\0'}; > static const WCHAR MSSansSerif[] = {'M','S',' ','S','a','n','s',' ','S','e','r','i','f','\0'}; > static const WCHAR MicrosoftSansSerif[] = {'M','i','c','r','o','s','o','f','t',' ','S','a','n','s',' ','S','e','r','i','f','\0'}; > +static const WCHAR Tahoma[] = {'T','a','h','o','m','a','\0'}; > static const WCHAR TimesNewRoman[] = {'T','i','m','e','s',' ','N','e','w',' ','R','o','m','a','n','\0'}; > static const WCHAR CourierNew[] = {'C','o','u','r','i','e','r',' ','N','e','w','\0'}; > > @@ -333,6 +334,85 @@ monospace: > expect (Ok, stat); > } > > +static void test_fontcollections(void) > +{ > + const static WCHAR tahomafilename[] = {'C',':','\\','W','I','N','D','O','W','S','\\','F','o','n','t','s','\\','T','a','h','o','m','a','.','t','t','f','\0'}; > + const static WCHAR timesNRfilename[] = {'C',':','\\','W','I','N','D','O','W','S','\\','F','o','n','t','s','\\','T','i','m','e','s','.','t','t','f','\0'}; > + const static WCHAR badFileName[] = {'C',':','\\','W','I','N','D','O','W','S','\\','F','o','n','t','s','\\','S','h','o','u','l','d','n','o','t','e','x','i','s','t','.','t','t','f','\0'}; > + > + static WCHAR familyName[LF_FACESIZE]; > + GpStatus stat; > + GpFontCollection* PrivateFontCollection; > + GpFontFamily** fontFamily; > + INT expected = 0, count = 0, i; > + BOOL hastahoma, hastimesnr; > + > + stat = GdipNewPrivateFontCollection(&PrivateFontCollection); > +todo_wine > + expect(Ok, stat); > + stat = GdipPrivateAddFontFile(PrivateFontCollection, NULL); > + expect(InvalidParameter, stat); > +todo_wine{ > + stat = GdipPrivateAddFontFile(PrivateFontCollection, badFileName); > + expect(FileNotFound, stat); > + > + stat = GdipPrivateAddFontFile(PrivateFontCollection, tahomafilename); > + if (stat == Ok) > + { > + expected++; > + hastahoma = TRUE; > + } > + > + stat = GdipPrivateAddFontFile(PrivateFontCollection, timesNRfilename); > + if (stat == Ok) > + { > + expected++; > + hastimesnr = TRUE; > + } > + > + stat = GdipGetFontCollectionFamilyCount(PrivateFontCollection, &count); > + expect(Ok, stat); > + expect(expected, count); > + > + expected = count; > + > + /* Test retrieving of installed fonts */ > + fontFamily = GdipAlloc(sizeof(GpFontFamily*) * count); > + stat = GdipGetFontCollectionFamilyList(PrivateFontCollection, count, > + fontFamily, &count); > + expect(Ok, stat); > + expect(expected, count); > + if (stat == Ok) > + { > + i = 0; > + if (hastahoma) > + { > + GdipGetFamilyName(fontFamily[i], familyName, LANG_NEUTRAL); > + ok(lstrcmpiW(familyName, Tahoma) == 0, "Expected Tahoma, got %s\n", > + debugstr_w(familyName)); > + i++; > + } > + > + if (hastimesnr) > + { > + GdipGetFamilyName(fontFamily[i], familyName, LANG_NEUTRAL); > + ok(lstrcmpiW(familyName, TimesNewRoman) == 0, "Expected Times New " > + "Roman, got %s\n", debugstr_w(familyName)); > + i++; > This i++ is redundant, isn't it? > + } > + } > + > + for (i = 0; i < count; i++) > + { > + stat = GdipDeleteFontFamily(fontFamily[i]); > + expect(Ok, stat); > + } > +} > + > + stat = GdipDeletePrivateFontCollection(&PrivateFontCollection); > + expect(Ok, stat); > +} > + > START_TEST(font) > { > struct GdiplusStartupInput gdiplusStartupInput; > @@ -350,6 +430,7 @@ START_TEST(font) > test_fontfamily(); > test_fontfamily_properties(); > test_getgenerics(); > + test_fontcollections(); > > GdiplusShutdown(gdiplusToken); > } >

1 0

Re: rpcrt4: Remove unreachable code in EmbeddedComplexSize.
by James McKenzie Aug. 18, 2008

Aug. 18, 2008

Rob Shearman wrote: > RPC_FC_ERROR_STATUS_T has a value of 0x10 and therefore isn't a > possible value of "flags_type & 0xf" in the switch statement. > Rob: This may be a really stupid question, but is it possible to generate this condition? James McKenzie

3 3

How to use wine to load windows dll files ?
by Gregory Hosler Aug. 18, 2008

Aug. 18, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, I'm a developer of an open source project that needs to load some windows dlls for conversion routines. Specifically, I'm the lead developer of GyachI https://sourceforge.net/projects/gyachi/ a Yahoo Messenger client. In GyachI, in order to support speech in chat rooms, we make use of the window dll codec files (supplied by the end user) to do the necessary codec compression/decompression. At the present moment, we copied mplayer's method of loading the dll files. That is to say that we have some very old wine code in our source tree. It works, but as and when a user runs GyachI on a box with wine installed, then GyachI will run against the installed wine libraries instead of the inbuilt wine code (not sure how, but this seems to be the case, from several reports). Since the code that we're using is all wine code, and in fact it is in the wine libraries, I would like to purge the wine code out of our project tree, and just compile/link against the necessary wine header files / wine libraries. To that extent, I have been able to remove the wine code from a build tree, and using the wine header files, I can get my code to compile. However, when I go to link, I get a number of undefined symbols. Some of the undefined symbols (at link time) are: undefined reference to `CloseDriver' undefined reference to `CodecAlloc' undefined reference to `CodecRelease' undefined reference to `export_names' undefined reference to `GetProcAddress' undefined reference to `HeapAlloc' undefined reference to `HeapFree' undefined reference to `OpenDriverA' undefined reference to `SendDriverMessage' undefined reference to `__vprintf' Upon investigation, I've discovered that many of the routines that I'm linking against are not in libwine.so, but instead, they are in other libraries. e.g. /usr/lib/wine/user32.dll.so, /usr/lib/wine/winmm.dll.so, and a few others. I would like to know how to link to and make use of these routines in the respective wine libraries. I'm willing to write any stub code that might need to be written, but I cannot find any documentation of what needs to be done. Any suggestions, pointers, links, urls, etc., would be most appreciated. Code samples (e.g. from other projects doing what I'm trying to do) would also be much appreciated. :) Many thanks, and best rgds, - -Greg - -- +---------------------------------------------------------------------+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler ghosler(a)redhat.com | +---------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFIqQJ6404fl/0CV/QRAivBAJ0c66W7ePiItK8ZvNnZ/1nLErSWKwCfRRD7 PbePRptt6e8mEEefwRx2YsE= =euK4 -----END PGP SIGNATURE-----

2 1

(no subject)
by Hongbo Ni Aug. 18, 2008

Aug. 18, 2008

Sorry my previous email got wrong format. "Dan Kegel" wrote: > This guide seems rather well written: > http://ldn.linuxfoundation.org/how-participate-linux-community > Wine could probably use something similar. YES, the Wine development speed can be greatly improved if similar development process is adepted, specially the 'Chain of Commands'. I am sure that Alexandre has done a great job as the Wine maintainer, but he may be stressed out when he comes back from his holiday as there are pile of patches awaiting him to review and commit. Hongbo Ni _________________________________________________________________ Win a Nokia E51 with mobile Hotmail SMS alerts http://www.livelife.ninemsn.com.au/compIntro.aspx?compId=4589

1 0

.NET program crashes involving stubbed functions
by Adam Petaccia Aug. 17, 2008

Aug. 17, 2008

Its customary to make a function return NotImplemented in Gdiplus, if its just a dummy function that does nothing and returns. But .NET seems to check for this and throw an exception, crashing the program anyway. See bug http://bugs.winehq.org/show_bug.cgi?id=12951 for details, but originally a program crashed because GdipNewPrivateFontCollection was just a stub. After the function was created, it still crashes because it returns "NotImplemented", rather than "Ok". IIRC, we return "NotImplemented" for some debugging reason, but if the goal of Wine is to run Windows applications, should we just go ahead and return "Ok" so that .NET apps don't freak out? Of course in a perfect world, we wouldn't have to fake a return code, but until that time comes do people have opinions one way or another?

3 3

Patchwatcher status
by Dan Kegel Aug. 17, 2008

Aug. 17, 2008

Patchwatcher is online and giving reasonably good feedback on the patch stream. The bug that caused every patch to be marked 'failed tests' is fixed, and the blacklist is expanded enough that false regressions seem to be rare. There are still bugs: 1. the dashboard shows no status column for http://kegel.com/wine/patchwatcher/results/32.txt even though http://kegel.com/wine/patchwatcher/results/32.log exists and shows that there was some strange problem in applying the patch. 2. The most recent patch shows up as 'queued' but the link to the patch doesn't work. Results are at http://kegel.com/wine/patchwatcher/results/ and source code is at http://winezeug.googlecode.com Next steps: - add timeout to handle hanging tests (every day or two I have to kill some test or other). There's no portable way to do this from wine/test.h that works in Win9x, so I'll probably set WINETEST_WRAPPER to run the tests via a wrapper that implements the timeout. - distribute across multiple machines by splitting into master (which watches the patch stream) and slaves (which execute tests). I will probably use http and ftp for this so the slaves can be remote. - support multiple architectures (anybody want to run the slaves on MacOSX for me?) - improve the web page to have error counts and perhaps separate links to the build and test logs - merge the chroot support (though this will need porting to run on MacOSX) - add valgrind as the next step after running tests - improve the web page generator to show current status (e.g. show the results from "make test" before starting valgrind)

4 5

Re: kernel32: Tiny improvement to the GetVolumePathNameW stub (try 3)
by Michael Karcher Aug. 17, 2008

Aug. 17, 2008

Am Samstag, den 16.08.2008, 23:56 +0000 schrieb Louis. Lenders: > Hi Michael, thanks again for the comment, i moved the check for the > stringlength to the front, and removed the wrong check for the > bufferlength (oops). Looks quite good now, but somehow the "return TRUE;" line got lost. Regards, Michael Karcher

1 0

re: kernel32: Tiny improvement to the GetVolumePathNameW stub (try 2)
by Dan Kegel Aug. 16, 2008

Aug. 16, 2008

"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> wrote: > i'm sure that if this function ever gets implemented all these checks and tests are needed, but as i said, a bit of google for fixme:GetVolumePath shows the common way (the very few) apps call this function is with filename="c:\blabla\bla", so for now , in my opinion, i don't think it's worth the effort. A simple test would be very easy and would help convince Alexandre to apply your patch. IMHO you should go drink a little bit of the koolaid at http://en.wikipedia.org/wiki/Test-driven_development Check it out; It even *sounds* like Wine development philosophy: ... > By focusing on writing only the code necessary to pass tests, designs can be cleaner and clearer than is often achieved by other methods[3]. In Test-Driven Development by Example Kent Beck also suggests the principle "Fake it, till you make it". - Dan

1 0

Re: kernel32: Tiny improvement to the GetVolumePathNameW stub (try 2)
by Michael Karcher Aug. 16, 2008

Aug. 16, 2008

Am Samstag, den 16.08.2008, 19:09 +0000 schrieb Louis. Lenders: > Hi Michael, thanks for your comments. I've added some simple sanity > checks from your first suggestions. It looks much better now, but you still access filename[1] before you even know that filename is not an empty string. In that case, filename[1] is past the end of the array, and you must not access it. Your check for strlenW comes too late. The minimal fix would be to put the strlenW call before the character comparisons, but it would be even smarter to either a) check that filename[0] is not 0, and check the next characters in order. So if any of these characters, short circuit evaluation prevents access of later characters, or b) just implement the special case for the empty string and catch this case before you access filename[1] and filename[2]. Please think about what "sizeof(volumepathname)" will return. The condition "sizeof(volumepathname) > 3" is *always* true. You should check buflen at that point. > As for the other suggestions, i'm sure that if this function ever gets > implemented all these checks and tests are needed, but as i said, a > bit of google for fixme:GetVolumePath shows the common way (the very > few) apps call this function is with filename="c:\blabla\bla", so for > now , in my opinion, i don't think it's worth the effort. As long as there are no junctions in wine, your implementation is correct for paths it can handle. So I would suggest to make the FIXME a TRACE and add a FIXME("Can't handle path %s\n",debugstr_w(filename)); below the case you handle. While googling for GetVolumeFileNameW, I stumbled across http://www.winehq.org/pipermail/wine-patches/2006-June/027228.html This patch obviously has not been applied. That is not really surprising, as it contains an extra hunk on an unrelated include file at the end, and also ignores buflen, but it does contain the correct logic for testing whether filename is a fully qualified local part, it contains the GetVolumeFileNameA implementation that forwards to GetVolumeFileNameW and contains at least one basic test. I would suggest to polish that patch a bit and submit the extra goodies from it also (you might use your GetPathNameW implementation after fixing the points raised above; these implementations are mostly equivalent). With polishing, I mean the following changes: - Test buflen in GetVolumeFileNameW (important) - The test "!filename[2]" is redundant (should be removed) (or just use your fixed version instead of the last two) - In the test: There is no need to allocate volumepath on the heap. char volumepath[16] (too bad you can't use constants in C for array dimensions!) would also do. Also, an ok(ret,"Error...") should precede the if(ret) block, the else part killed. If you expect something, always test it with an ok statement; do not sprinkle ok(FALSE) later in the code. Regards, Michael Karcher

1 0

Re: [winmm] Implement stub for midiConnect and midiDisconnect.
by Nikolay Sivov Aug. 16, 2008

Aug. 16, 2008

Christian Costa wrote: > Hi, > > This fixes bug 11142 & 11182. > > Bye, > Christian > > Changelog: > Implement stub for midiConnect and midiDisconnect. > Usually some error code returned for plain stubs like these. Does it block these bugs?

2 1

Re: kernel32: Tiny improvement to the GetVolumePathNameW stub
by Michael Karcher Aug. 16, 2008

Aug. 16, 2008

Am Samstag, den 16.08.2008, 17:12 +0000 schrieb Louis. Lenders: > Hi, this fixes Adobe Lightroom 2.0 start up bug, mentioned in > http://bugs.winehq.org/show_bug.cgi?id=8224#c4 > > as long wine doesn't handle with volume mount points, it's probably > safe to satisfy most apps. The idea of your patch looks right to me. But (1) please don't use memcmp to compare wide characters, especially, don't use memcmp with a count of one, as it only compares one half the the wide character. use filename[1] == ':' && filename[2] == '\\' instead. (2) Please check that filename really has at least 3 characters before accessing it. (3)Please check the size of the output buffer before copying anything into it. Finally, the chance of getting this patch accepted raises if you accompany the implementation with an API test. Another point to increase the chances of getting that patch committed is to implement the corner cases (at least the empty string) explained on MSDN, also backed up by an API test. Please also note the documented behaviour for the case of the output buffer being short by one byte. Regards, Michael Karcher

1 0

re: winmm: remove misleading message
by Dan Kegel Aug. 16, 2008

Aug. 16, 2008

Jeff wrote: > Remove a message suggesting that Wine should be pointed at a windows installation. > > - FIXME("Couldn't load driver for type %s.\n" > - "If you don't have a windows installation accessible from Wine,\n" > - "you perhaps forgot to create a [mci] section in system.ini\n", > + FIXME("Couldn't load driver for type %s.\n", The [mci] section in system.ini advice is still valid and usful, I think. You probably just want to remove the middle line. - Dan

1 0

Re: [1/2] mshtml: Changed get_typeinfo to help support IDispatch
by leslie_alistair＠hotmail.com Aug. 16, 2008

Aug. 16, 2008

-------------------------------------------------- From: "Jacek Caban" <jacek(a)codeweavers.com> Sent: Saturday, August 16, 2008 8:18 PM To: <wine-devel(a)winehq.org> Cc: "Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> Subject: Re: [1/2] mshtml: Changed get_typeinfo to help support IDispatch > Alistair Leslie-Hughes wrote: >> Hi, >> >> Changelog: >> mshtml: Changed get_typeinfo to help support IDispatch > > Subject: [PATCH] Changed get_typeinfo to AddRef the COM pointer > > > get_typeinfo is an internal function so it's fine to not AddRef as long as > we guarantee that we hold the reference (and we do) so there is no point > to add unneeded AddRef here. > I based the msxml get_typeinfo on the mshtml implementation, and it was initial rejected due to the missing AddRef's. So before I started Implementing more of the IDispatch functions, I thought this was the right thing todo. Best Regards Alistair Leslie-Hughes

1 0

Re: [2/2] mshtml: Implement IDispatch for IHTMLElement
by Jacek Caban Aug. 16, 2008

Aug. 16, 2008

Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > mshtml: Implement IDispatch for IHTMLElement You should forward these calls to IDispatchEx implementation. See htmlselect.c for example. Jacek

1 0

Re: [1/2] mshtml: Changed get_typeinfo to help support IDispatch
by Jacek Caban Aug. 16, 2008

Aug. 16, 2008

Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > mshtml: Changed get_typeinfo to help support IDispatch > Subject: [PATCH] Changed get_typeinfo to AddRef the COM pointer get_typeinfo is an internal function so it's fine to not AddRef as long as we guarantee that we hold the reference (and we do) so there is no point to add unneeded AddRef here. Jacek

1 0

re: Unwanted WM_CTLCOLORSTATIC notification
by Dan Kegel Aug. 15, 2008

Aug. 15, 2008

Matt wrote: > I've been trying to debug a problem with Adobe Indesign CS where the > application crashes while creating the file open dialog box. Now I believe > (not 100% sure) I have tracked down the problem to a spurious > WM_CTLCOLORSTATIC notification. Thanks for looking into this. This is a key app needed by many schools and companies, but we haven't had enough time to give it the attention it deserves. Please file a bug report at http://bugs.winehq.org including all the info needed to reproduce the bug (ideally with a trial version; you can find download URLs at http://wiki.winehq.org/AdobeIndesign And attach your test case source there. If you want to go a little further, rewrite your test case in plain C instead of C++ (should be easy). And if you want to go even further, integrate it into our existing message tests, http://source.winehq.org/source/dlls/user32/tests/msg.c which already do have some tests for WM_CTLCOLORSTATIC. One note of caution: the user32/msg.c tests don't all pass on Wine, see http://wiki.winehq.org/MakeTestFailures and http://test.winehq.org/data/520ab5c261706f6118a85a82ba84213932ba76e7/#group… - Dan

2 1

Re: .NET program crashes involving stubbed functions
by James Mckenzie Aug. 15, 2008

Aug. 15, 2008

Reece Dunn <msclrhd(a)googlemail.com> on Aug 13, 2008 11:32 AM wrote about .NET program crashes involving stubbed functions > >2008/8/13 Adam Petaccia <adam(a)tpetaccia.com>: >> Its customary to make a function return NotImplemented in Gdiplus, if >> its just a dummy function that does nothing and returns. But .NET seems >> to check for this and throw an exception, crashing the program anyway. >> >> See bug http://bugs.winehq.org/show_bug.cgi?id=12951 for details, but >> originally a program crashed because GdipNewPrivateFontCollection was >> just a stub. After the function was created, it still crashes because it >> returns "NotImplemented", rather than "Ok". IIRC, we return >> "NotImplemented" for some debugging reason, but if the goal of Wine is >> to run Windows applications, should we just go ahead and return "Ok" so >> that .NET apps don't freak out? >> >> Of course in a perfect world, we wouldn't have to fake a return code, >> but until that time comes do people have opinions one way or another? > >The problem with returning Ok is that it implies that the function >succeeded in what it is intended to do. As a result, the application >will continue and in this case expect to be able to use the private >font collection. To prevent the application crashing, it is likely >that several functions will need to be implemented. > >Also note that the reporter of the bug mentions that they installed >mono. This means that using MS.NET may lead to different behaviour. It >also means that it should be possible to see how the >GdipNewPrivateFontCollection call is being used by mono and the data >that it returns. Is there a method of resolving this using functions provided by Mono or will this require additional tools? > >So to summarise, I suspect this will require more than simply returning Ok. > I agree. There should be more responses than just OK. James McKenzie

1 0

Re: #1 winhttp: Add a handle management implementation.
by H. Verbeet Aug. 15, 2008

Aug. 15, 2008

2008/8/15 Hans Leidekker <hans(a)meelstraat.net>: > > +HINTERNET alloc_handle( object_header_t *hdr ) > +{ > + object_header_t **p; > + ULONG_PTR handle = 0, num; > + > + list_init( &hdr->children ); > + > + EnterCriticalSection( &handle_cs ); > + if (!max_handles) > + { > + num = HANDLE_CHUNK_SIZE; > + if (!(p = heap_alloc_zero( sizeof(ULONG_PTR) * num ))) goto end; > + handles = p; > + max_handles = num; > + } > + if (max_handles == next_handle) > + { > + num = max_handles + HANDLE_CHUNK_SIZE; > + if (!(p = heap_realloc_zero( handles, sizeof(ULONG_PTR) * num ))) goto end; > + handles = p; > + max_handles = num; > + } > + handle = next_handle; > + if (handles[handle]) ERR("handle isn't free but should be\n"); > + > + handles[handle] = addref_object( hdr ); > + while (handles[next_handle] && (next_handle < max_handles)) next_handle++; > + > +end: > + LeaveCriticalSection( &handle_cs ); > + return hdr->handle = (HINTERNET)(handle + 1); > +} Not necessarily wrong, but the common way to implement tables like this is to grow the table by some percentage of the original size, and keep a list of free handles.

2 1

Re: #1 winhttp: Add a handle management implementation.
by Hans Leidekker Aug. 15, 2008

Aug. 15, 2008

On Friday 15 August 2008 14:41:36 Hans Leidekker wrote: Sorry for the From address confusion. The CodeWeavers mail server accused me of relaying but I found out now that it's because I forgot to enable authenticated SMTP. -Hans

1 0

Unwanted WM_CTLCOLORSTATIC notification
by Matt J Aug. 15, 2008

Aug. 15, 2008

Hi, I've been trying to debug a problem with Adobe Indesign CS where the application crashes while creating the file open dialog box. Now I believe (not 100% sure) I have tracked down the problem to a spurious WM_CTLCOLORSTATIC notification. This notification is generated when the application invokes WM_SETTEXT to change the caption of a 'group box' control control in the dialog box. To verify this I coded up a small test case, which I have attached to the email. This basically creates a new dialog box and when it receives it WM_INITDIALOG notification it calls SendDlgItemMessage to send a WM_SETTEXT message to set the text of a 'group box' control on the dialog. As it runs it logs the notifications that it receives. On windows we see the following: Message: 0x00000030 (48) Message: 0x00000110 (272) WM INITDIALOG Message: 0x00000127 (295) Message: 0x00000128 (296) Message: 0x00000018 (24) Message: 0x00000046 (70) ... Under wine we see: Message: 0x00000030 (48) Message: 0x00000110 (272) WM INITDIALOG Message: 0x00000138 (312) Message: 0x00000018 (24) Message: 0x00000046 (70) ... Of primary interest to me here is the WM_CTLCOLORSTATIC notification (0x00000138) that is generated only under wine. Also of interest is that WM_CHANGEUISTATE (0x00000127) and WM_UPDATEUISTATE (0x00000128) notifications are received under windows but not wine. This is my first foray into debugging wine, so I may be totally off track here, but I do believe that the WM_CTLCOLORSTATIC notification is what is causing InDesign to crash. So, I am wondering if someone with more experience here can give some advice about rectifying this problem. If I can provide any more info about the problem, please let me know. Regards, Matt

1 0

Re: wininet: default to keep-alive when the server is HTTP/1.1, not when it isn't
by Huw Davies Aug. 15, 2008

Aug. 15, 2008

Vincent Povirk wrote: > This is a fix to a problem I introduced in > fd5b97bc4d12adc69085b739061c56e9107f8d1f. The expression that checked > the HTTP version was true for HTTP/1.0 servers, and I treated it as if > it were true for HTTP/1.1 servers. That means we defaulted to keep-alive > for HTTP/1.0 servers only, the exact opposite of what we want. This was a problem with the old code too, but what happens when we get HTTP > 1.1 ? Huw.

2 1

Flaky tests are starting to get real annoying...
by Dan Kegel Aug. 14, 2008

Aug. 14, 2008

So, one of the things one learns when writing a patch robot is that flaky tests are very annoying. Each time it gets a new git tree, the robot does five baseline "make -k test" runs, remembers the tests that fail, and doesn't penalize patches for failing any of those tests. See http://code.google.com/p/winezeug/source/browse/trunk/patchwatcher/patchwat… Annoyingly, that's not enough. Some tests stubbornly refuse to fail during the baseline test runs. So I added a second, manual blacklist for those tests; see http://code.google.com/p/winezeug/source/browse/trunk/patchwatcher/patchwat… The list is currently user32:msg.c user32:input.c d3d9:visual.c ddraw:visual.c urlmon:protocol.c kernel32:thread.c and will continue growing as I keep plugging away at getting the patch robot happy. Is anybody else seeing this kind of flakiness? (If you're not, try running patchwatcher for a while :-) FWIW, I'm running the tests on hardy with a fresh metacity (as described in http://wiki.winehq.org/MakeTestFailures ).

4 6

Re: user32: test what FindWindow when window isn't found
by Dmitry Timoshkov Aug. 14, 2008

Aug. 14, 2008

"Austin English" <austinenglish(a)gmail.com> wrote: > - /* test FindWindow behavior */ > + SetLastError(0xdeadbeef); > + HWND hWnd = FindWindow("SomeWindowThatDoesNotExist", NULL); > + if(hWnd) { > + printf("hWnd not NULL"); > + } > + else { > + > + todo_wine > + ok(GetLastError() == ERROR_FILE_NOT_FOUND, "ERROR_FILE_NOT_FOUND, got %d\n", GetLastError()); > + } Why did you remove the comment? Introducing 'hWnd' variable is not needed, there is one already called 'found', besides declaring variables in the code is not allowed in Wine. It would be much simpler to add the last error test to 2 existing FindWindowExA calls instead of introducing something looking as foreign code (in indentation, braces usage and spaces). -- Dmitry.

3 3