Re: user32 - set_active_window uses SendMessage instead of PostMessage for WM_ACTIVATEAPP messages.
Peter Dons Tychsen wrote: Hello Wine. On original Windows, the messages WM_ACTIVATEAPP are sent using PostMessage() and not SendMessage() like in the current Wine implementation. I have thoroughly verified that this is the case on Windows-XP (that it uses PostMessage()). This error can lead to fatal focusing problems, as some programs call more focus related functions when they receive this message. This leads to recursive calls into set_active_calls. It does not crash, but leads to unexpected results such as lost focus for mouse and keyboard. This fixes the focus for the game "Wild Metal" if you switch focus from the game to the desktop, and then back again. http://www.rockstargames.com/classics/ Cheers, /Pedro This patch makes 45 msg.c tests in user32 fail for me. Could you double check your findings? Also when you say "thoroughly verified" have you used Wine tests or your own program? Vitaliy
[PATCH 2/5] urlmon: Use BSCF_ values passed to report_data to keep track of download state.
> Hi Misha, > > Misha Koshelev wrote: > > This simplifies the code a bit by getting rid of an enum and a > > corresponding variable in the IBinding > > implementation, as we can successfully use the bscf values that are passed > > to report_data to get all > > the information. > > > > Additionally, the original implementation was somewhat incorrect at least > > for the case of the Http protocol > > as far as sending OnStopBinding > > This patch is already accepted, but unfortunately it's wrong. Tests > changed in the attached patch succeed on native urlmon.dll and fail on > current Wine. Probably only BSCF_LASTDATANOTIFICATION flag should be > used. Other OnProgress callbacks should be called depending on the real > binding state, not the one reported by protocol handler. > > Jacek > -- next part -- > diff --git a/dlls/urlmon/tests/url.c b/dlls/urlmon/tests/url.c > index 187fb03..dcae846 100644 > --- a/dlls/urlmon/tests/url.c > +++ b/dlls/urlmon/tests/url.c > @@ -255,6 +255,7 @@ static HRESULT WINAPI Protocol_Start(IInternetProtocol > *iface, LPCWSTR szUrl, > SET_EXPECT(OnDataAvailable); > SET_EXPECT(OnStopBinding); > > +bscf = BSCF_LASTDATANOTIFICATION; > hres = IInternetProtocolSink_ReportData(pOIProtSink, bscf, 13, 13); > ok(hres == S_OK, "ReportData failed: %08x\n", hres); > Yes, I am sorry about this patch. I actually figured out that it was wrong this morning and was going to send an email out to wine-devel but since it was already committed just decided to send out a revert patch + more conservative fixes that are necessary tonight. I will prob be sending them soon. Again, sorry about the patch. Thanks for the email. Misha
Re: Patch: VarWeekdayName
On 8/2/07, Jiří Paleček <[EMAIL PROTECTED]> wrote:
> On Fri, 03 Aug 2007 01:43:05 +0200, James Hawkins <[EMAIL PROTECTED]>
> wrote:
>
> > On 8/2/07, Jiří Paleček <[EMAIL PROTECTED]> wrote:
> >> On Thu, 02 Aug 2007 16:06:44 +0200, Juan Lang <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >> >> Thank you. Hope it will be better this time. Also, I'll send a test
> >> >> if this is OK.
> >> >
> >> > This one looks pretty good to me, but I have one error and a few nits
> >> > to correct:
> >> >
> >> > The error:
> >> > + {
> >> > +ERR("GetLocaleInfo of 0x%x failed in 2nd stage?!\n",
> >> localeValue);
> >> > +SysFreeString(*pbstrOut);
> >> >
> >> > You should set *pbstrOut to NULL in this case.
> >>
> >> OK. However, note that this was copy&pasted, so there are more instances
> >> of this error in wine. It could be somehow automated (like having a
> >> macro
> >> for these disposing functions which will also set the pointer to NULL).
> >>
> >> > The nits:
> >> > You have a couple small errors in the comments:
> >> > - You misspell iWeekday
> >> > - The comment for iWeekday in the params section implies 0 is allowed,
> >> > but the first check in the function disallows it.
> >>
> >> This is the problem the misspelled comment is about, MSDN also suggest
> >> 0 for weekday is OK, however, disassemble showed it isn't on Win XP.
> >>
> >
> > Are you disassembling native windows binaries?
>
> Yes, is it a problem?
>
Yes it's not allowed in this project. Assuming you only disassembled
oleaut32.dll, you will unfortunately not be able to contribute to that
dll anymore for the Wine project.
--
James Hawkins
Re: Patch: VarWeekdayName
On Fri, 03 Aug 2007 01:43:05 +0200, James Hawkins <[EMAIL PROTECTED]>
wrote:
On 8/2/07, Jiří Paleček <[EMAIL PROTECTED]> wrote:
On Thu, 02 Aug 2007 16:06:44 +0200, Juan Lang <[EMAIL PROTECTED]>
wrote:
>> Thank you. Hope it will be better this time. Also, I'll send a test
>> if this is OK.
>
> This one looks pretty good to me, but I have one error and a few nits
> to correct:
>
> The error:
> + {
> +ERR("GetLocaleInfo of 0x%x failed in 2nd stage?!\n",
localeValue);
> +SysFreeString(*pbstrOut);
>
> You should set *pbstrOut to NULL in this case.
OK. However, note that this was copy&pasted, so there are more instances
of this error in wine. It could be somehow automated (like having a
macro
for these disposing functions which will also set the pointer to NULL).
> The nits:
> You have a couple small errors in the comments:
> - You misspell iWeekday
> - The comment for iWeekday in the params section implies 0 is allowed,
> but the first check in the function disallows it.
This is the problem the misspelled comment is about, MSDN also suggest
0 for weekday is OK, however, disassemble showed it isn't on Win XP.
Are you disassembling native windows binaries?
Yes, is it a problem?
Jiri Palecek
Re: Patch: VarWeekdayName
On 8/2/07, Jiří Paleček <[EMAIL PROTECTED]> wrote:
> On Thu, 02 Aug 2007 16:06:44 +0200, Juan Lang <[EMAIL PROTECTED]> wrote:
>
> >> Thank you. Hope it will be better this time. Also, I'll send a test
> >> if this is OK.
> >
> > This one looks pretty good to me, but I have one error and a few nits
> > to correct:
> >
> > The error:
> > + {
> > +ERR("GetLocaleInfo of 0x%x failed in 2nd stage?!\n", localeValue);
> > +SysFreeString(*pbstrOut);
> >
> > You should set *pbstrOut to NULL in this case.
>
> OK. However, note that this was copy&pasted, so there are more instances
> of this error in wine. It could be somehow automated (like having a macro
> for these disposing functions which will also set the pointer to NULL).
>
> > The nits:
> > You have a couple small errors in the comments:
> > - You misspell iWeekday
> > - The comment for iWeekday in the params section implies 0 is allowed,
> > but the first check in the function disallows it.
>
> This is the problem the misspelled comment is about, MSDN also suggest
> 0 for weekday is OK, however, disassemble showed it isn't on Win XP.
>
Are you disassembling native windows binaries?
--
James Hawkins
Re: Patch: VarWeekdayName
On Thu, 02 Aug 2007 16:06:44 +0200, Juan Lang <[EMAIL PROTECTED]> wrote:
Thank you. Hope it will be better this time. Also, I'll send a test
if this is OK.
This one looks pretty good to me, but I have one error and a few nits
to correct:
The error:
+ {
+ERR("GetLocaleInfo of 0x%x failed in 2nd stage?!\n", localeValue);
+SysFreeString(*pbstrOut);
You should set *pbstrOut to NULL in this case.
OK. However, note that this was copy&pasted, so there are more instances
of this error in wine. It could be somehow automated (like having a macro
for these disposing functions which will also set the pointer to NULL).
The nits:
You have a couple small errors in the comments:
- You misspell iWeekday
- The comment for iWeekday in the params section implies 0 is allowed,
but the first check in the function disallows it.
This is the problem the misspelled comment is about, MSDN also suggest
0 for weekday is OK, however, disassemble showed it isn't on Win XP.
Attaching a test with the patch would certainly help.
I'm sending it to wine-patches.
Regards
Jiri Palecek
Re: wine3d3: Check the destination recangle when for FastBlt().
On Mon, 2007-07-30 at 22:18 +0200, Peter Dons Tychsen wrote: > On Sun, 2007-07-29 at 23:08 +0200, Stefan Dösinger wrote: > > Am Sonntag, 29. Juli 2007 21:28 schrieb Peter Dons Tychsen: > > > Hello Wine! > > > > > > I have fixed a small bug in FastBlt(), which caused Wine to crash if the > > > application tried to do FastBlt() to a surface using a bad destination > > > setup. The problem is already fixed in normal Blt(), but was broken for > > > FastBlt(). > > > > > > This fixes a crash for the little game "Treasure Mole Winter Vacations": > > This check should be in ddraw, not wined3d. ddraw, d3d8 and d3d9 have > > different ideas about such checks, that's why the check was moved from > > WineD3D to the client libs. Originally it was in LockRect, and when it was > > moved the check was lost in Blt and BltFast. There should be a check in > > ddraw > > already, maybe it is not sufficient. > > > > Also please write a test case to verify that the fix is correct(look at > > dlls/ddraw/tests/dsurface.c). This will also prevent the problem from > > coming > > back. Treasure Mole broke after the ddraw rewrite because exactly this > > check > > was missing. I implemented it in LockRect, like in old ddraw, but I forgot > > to > > write a test for BltFast. Then a d3d9 game was broken because d3d9 LockRect > > behaved differently, a test was written for Lock(Rect) in ddraw, d3d8 and > > d3d9, and the range check moved to ddraw, d3d8 and d3d9 to be able to > > implement different checking in each version. Since I forgot to write a > > test > > when I originally fixed Treasure Mole the bug could creep back in again :-( > > > > Thanks for your comments Stefan, I have taken another look at it. I still think this specific problem should be fixed in wined3d. The problem occurs because BltFast (ddraw, d3d and d3d-gdi) all take two DWORDs as the offset write position, and then later casts them into a RECT structure which has signed values. This must for any caller be considered an error. No caller could get anything useful out of this. Code: IWineGDISurfaceImpl_BltFast(IWineD3DSurface *iface, DWORD dstx, DWORD dsty, IWineD3DSurface *Source, RECT *rsrc, DWORD trans) ... lock_dst.left = dstx; <--- bad cast! lock_dst.top = dsty; <--- bad cast! lock_dst.right = dstx + w; <--- bad cast! lock_dst.bottom = dsty + h; <--- bad cast! Why does this not trigger a warning? Not sure. I can still move the fix to ddraw, but as said, i am not sure it's the right move. Please comment, /pedro Please note: this is a re-send. I think my mail-server trashed the first one. Not sure what happened. Sorry if you get this more than once.
Re: dinput - Allow the use of the standard Joystick GUID when calling CreateDevice
On Fri, 2007-08-03 at 01:02 +0200, Peter Dons Tychsen wrote:
> On Thu, 2007-08-02 at 06:54 -0600, Vitaliy Margolen wrote:
> > Peter Dons Tychsen wrote:
> > > On Tue, 2007-07-31 at 20:05 -0600, Vitaliy Margolen wrote:
> > >> Peter Dons Tychsen wrote:
> > >>> On Tue, 2007-07-31 at 06:34 -0600, Vitaliy Margolen wrote:
> > Peter Dons Tychsen wrote:
> > > On Mon, 2007-07-30 at 21:20 +0200, Peter Dons Tychsen wrote:
> > >> On Sun, 2007-07-29 at 17:43 -0600, Vitaliy Margolen wrote:
> > >>> Peter Dons Tychsen wrote:
> > OK. Please review this diff:
> >
> > I will re-submit it if you like it.
> >
> > /Pedro
> > >>> Alright looks good now (you might want to remove the extra white
> > >>> space your
> > >>> patch adds - git complains about those). Just left to make the same
> > >>> change
> > >>> to the other joystick interface :)
> > >>>
> > >>> BTW don't forget to cc: the wine-devel list when you replying.
> > >>>
> > >>> Vitaliy.
> > >> OK. I still feel that trying to sync joystick_linuxinput.c and
> > >> joystick_linux.c is out of scope for this patch. But as my steadiness
> > >> has limits i have done some of it anyway... :). I have kept the
> > >> changes
> > >> modest.
> > >>
> > >> Please take a look at the new patch.
> > >>
> > >> On another note i will agree with you that it would be practical if
> > >> the
> > >> two files had similar (or maybe even shared) code. Redundant code is
> > >> never very practical as it always ends up as this very example. The
> > >> two
> > >> implementations which were supposed to identical always drift apart.
> > >> If
> > >> things are supposed to do the same, keep them together to begin with.
> > >>
> > >> Thanks,
> > >>
> > > Maybe i would be more successful if i actually attached the
> > > patch :-)
> > >
> > > Here it is
> > Just few small things left:
> >
> > > -#undef MAX_JOYSTICKS
> > As I mentioned earlier you should move this instead of removing it
> > completely.
> >
> >
> > > static HRESULT joydev_create_deviceW(IDirectInputImpl *dinput,
> > > REFGUID rguid, REFIID riid, LPDIRECTINPUTDEVICEW* pdev)
> > > {
> > > - int i;
> > > -
> > > - find_joydevs();
> > You removed a really important function call here.
> >
> >
> > > +static HRESULT joydev_create_deviceA(IDirectInputImpl *dinput,
> > > REFGUID rguid, REFIID riid, LPDIRECTINPUTDEVICEA* pdev)
> > > +{
> > > + unsigned short index;
> > > +
> > > + if ((index = get_joystick_index(rguid)) < MAX_JOYDEV) {
> > > +if ((riid == NULL) ||
> > If you reformat the whole function, please make it 4-space indented.
> >
> > >>> OK. Here is the new patch:
> > >>>
> > >> Looks good to me. The problem is, it doesn't work for me (USB joystick).
> > >> I
> > >> think you forgot to look at how joystick_linuxinput.c handles that data3
> > >> field. It's not just 0 based index...
> > >>
> > > I told you i should bot have merged the changes over to
> > > joystick_linuxinput as they were too different... :-)
> > >
> > > OK, so how do i force my system to use the other implementation (so i
> > > can test it) ?
> > >
> > > I have a Logitech WingMan Extreme (old version).
> > >
> > Just (re)move /dev/input/js*. Or in dinput change device name to point to
> > non-existent directory/device (in joystick_linux.c).
> >
> > Vitaliy.
>
> OK, fair enough. Even though i did'nt like messing around with
> joystick_linuxinput.c i should have been smarter than trying to submit
> something i could not test... :-(
>
> But... tada!... now i have re-fixed it and re-tested both
> implementations. Its seems stable now. :-)
>
> Please give it another go on your machine Vitaliy.
>
> Cheers,
>
> /Pedro
As usual, i forgot the patch getting late inside my head :-)
Here it is...
/p
0001-Allow-the-use-of-the-standard-Joystick-GUID-when-cal.patch
Description: application/mbox
Re: dinput - Allow the use of the standard Joystick GUID when calling CreateDevice
On Thu, 2007-08-02 at 06:54 -0600, Vitaliy Margolen wrote:
> Peter Dons Tychsen wrote:
> > On Tue, 2007-07-31 at 20:05 -0600, Vitaliy Margolen wrote:
> >> Peter Dons Tychsen wrote:
> >>> On Tue, 2007-07-31 at 06:34 -0600, Vitaliy Margolen wrote:
> Peter Dons Tychsen wrote:
> > On Mon, 2007-07-30 at 21:20 +0200, Peter Dons Tychsen wrote:
> >> On Sun, 2007-07-29 at 17:43 -0600, Vitaliy Margolen wrote:
> >>> Peter Dons Tychsen wrote:
> OK. Please review this diff:
>
> I will re-submit it if you like it.
>
> /Pedro
> >>> Alright looks good now (you might want to remove the extra white
> >>> space your
> >>> patch adds - git complains about those). Just left to make the same
> >>> change
> >>> to the other joystick interface :)
> >>>
> >>> BTW don't forget to cc: the wine-devel list when you replying.
> >>>
> >>> Vitaliy.
> >> OK. I still feel that trying to sync joystick_linuxinput.c and
> >> joystick_linux.c is out of scope for this patch. But as my steadiness
> >> has limits i have done some of it anyway... :). I have kept the changes
> >> modest.
> >>
> >> Please take a look at the new patch.
> >>
> >> On another note i will agree with you that it would be practical if the
> >> two files had similar (or maybe even shared) code. Redundant code is
> >> never very practical as it always ends up as this very example. The two
> >> implementations which were supposed to identical always drift apart. If
> >> things are supposed to do the same, keep them together to begin with.
> >>
> >> Thanks,
> >>
> > Maybe i would be more successful if i actually attached the
> > patch :-)
> >
> > Here it is
> Just few small things left:
>
> > -#undef MAX_JOYSTICKS
> As I mentioned earlier you should move this instead of removing it
> completely.
>
>
> > static HRESULT joydev_create_deviceW(IDirectInputImpl *dinput, REFGUID
> > rguid, REFIID riid, LPDIRECTINPUTDEVICEW* pdev)
> > {
> > - int i;
> > -
> > - find_joydevs();
> You removed a really important function call here.
>
>
> > +static HRESULT joydev_create_deviceA(IDirectInputImpl *dinput, REFGUID
> > rguid, REFIID riid, LPDIRECTINPUTDEVICEA* pdev)
> > +{
> > + unsigned short index;
> > +
> > + if ((index = get_joystick_index(rguid)) < MAX_JOYDEV) {
> > +if ((riid == NULL) ||
> If you reformat the whole function, please make it 4-space indented.
>
> >>> OK. Here is the new patch:
> >>>
> >> Looks good to me. The problem is, it doesn't work for me (USB joystick). I
> >> think you forgot to look at how joystick_linuxinput.c handles that data3
> >> field. It's not just 0 based index...
> >>
> > I told you i should bot have merged the changes over to
> > joystick_linuxinput as they were too different... :-)
> >
> > OK, so how do i force my system to use the other implementation (so i
> > can test it) ?
> >
> > I have a Logitech WingMan Extreme (old version).
> >
> Just (re)move /dev/input/js*. Or in dinput change device name to point to
> non-existent directory/device (in joystick_linux.c).
>
> Vitaliy.
OK, fair enough. Even though i did'nt like messing around with
joystick_linuxinput.c i should have been smarter than trying to submit
something i could not test... :-(
But... tada!... now i have re-fixed it and re-tested both
implementations. Its seems stable now. :-)
Please give it another go on your machine Vitaliy.
Cheers,
/Pedro
Bug introduced in 0.9.42 in printer dialog
A bug was introduced in version 0.9.42, that makes printer dialogs to not work. When you press Accept button in the printer dialog the I receive the followin error: fixme:commdlg:PRINTDLG_UpdatePrintDlgA No lpdm ptr? fixme:commdlg:PRINTDLG_WMCommandA Update printdlg was not successful! Should I post to bugzilla? Regards Christian [EMAIL PROTECTED]
Re: [PATCH 2/5] urlmon: Use BSCF_ values passed to report_data to keep track of download state.
Hi Misha, Misha Koshelev wrote: This simplifies the code a bit by getting rid of an enum and a corresponding variable in the IBinding implementation, as we can successfully use the bscf values that are passed to report_data to get all the information. Additionally, the original implementation was somewhat incorrect at least for the case of the Http protocol as far as sending OnStopBinding This patch is already accepted, but unfortunately it's wrong. Tests changed in the attached patch succeed on native urlmon.dll and fail on current Wine. Probably only BSCF_LASTDATANOTIFICATION flag should be used. Other OnProgress callbacks should be called depending on the real binding state, not the one reported by protocol handler. Jacek diff --git a/dlls/urlmon/tests/url.c b/dlls/urlmon/tests/url.c index 187fb03..dcae846 100644 --- a/dlls/urlmon/tests/url.c +++ b/dlls/urlmon/tests/url.c @@ -255,6 +255,7 @@ static HRESULT WINAPI Protocol_Start(IInternetProtocol *iface, LPCWSTR szUrl, SET_EXPECT(OnDataAvailable); SET_EXPECT(OnStopBinding); +bscf = BSCF_LASTDATANOTIFICATION; hres = IInternetProtocolSink_ReportData(pOIProtSink, bscf, 13, 13); ok(hres == S_OK, "ReportData failed: %08x\n", hres);
Re: #1 winhttp: Forward WinHttpTime{From, To}SystemTime to their counterparts in wininet.
Hans Leidekker wrote: We should be able to implement more than 95% of this dll by wrapping/forwarding to wininet. That's better than many other dlls in Wine and we're already seeing regressions in apps trying to use our stub winhttp. And when we'll find an app (I'm sure we will) that uses the remaining 5% of winhttp, we'll have to reimplement it properly, what will be a real pain. I agree that such a big code duplication is ugly, but that's the way to go. We may separate the common code to different files in wininet and keep them in sync with winhttp. This way it shouldn't be too hard to implement most of the functionality you have implemented. Jacek
Re: WGL: GetPixelFormat fix for offscreen formats
On Thursday 02 August 2007, Tomas Carnecky wrote:
> from the patch:
>
> return physDev->current_pf;
> + TRACE("(%p): returns %d\n", physDev, physDev->current_pf);
> }
>
> What's the purpose of that TRACE() ?
Copy/paste bug?
Cheers, Kuba
Re: WGL: GetPixelFormat fix for offscreen formats
from the patch:
return physDev->current_pf;
+ TRACE("(%p): returns %d\n", physDev, physDev->current_pf);
}
What's the purpose of that TRACE() ?
tom
Re: #1 winhttp: Forward WinHttpTime{From, To}SystemTime to their counterparts in wininet.
On Thursday 02 August 2007 20:19:52 Robert Shearman wrote: > We shouldn't be implementing winhttp on top of wininet as there are > functions such as WinHttpSetCredentials > (http://msdn2.microsoft.com/en-us/library/Aa384112.aspx) that can't be > implemented on top of wininet functions. Why not? Could it not add the required headers to the request? > There are also issues with different error codes being returned as well > as different callbacks > (http://msdn2.microsoft.com/en-us/library/aa383917.aspx). Well, error codes can be translated in wrappers and WINHTTP_STATUS_CALLBACK has the same prototype as INTERNET_STATUS_CALLBACK, although it's not called for the same set of events. We should be able to implement more than 95% of this dll by wrapping/forwarding to wininet. That's better than many other dlls in Wine and we're already seeing regressions in apps trying to use our stub winhttp. -Hans
Re: #1 winhttp: Forward WinHttpTime{From, To}SystemTime to their counterparts in wininet.
Hans Leidekker wrote:
Forward WinHttpTime{From, To}SystemTime to their counterparts in wininet.
We shouldn't be implementing winhttp on top of wininet as there are
functions such as WinHttpSetCredentials
(http://msdn2.microsoft.com/en-us/library/Aa384112.aspx) that can't be
implemented on top of wininet functions.
There are also issues with different error codes being returned as well
as different callbacks
(http://msdn2.microsoft.com/en-us/library/aa383917.aspx).
--
Rob Shearman
Re: Is there a process for reviewing a bugzilla staffer?
> Is there a formal process for reviewing an arguably incompetent > bugzilla staffer? Obviously it wouldn't be to submit their name as a > bug. But is there any defined administrative layer that concerns > itself with people on that level who are dragging on the project? > > I looked around a bit for information on this. Sorry if it's posted > somewhere and I missed it. > > Thanks, > Whit > >>> > >>> To spare everyone time and to skip directly to an entertainment see bug > >>> 9147: http://bugs.winehq.org/show_bug.cgi?id=9147 > >> > >> I agree with Whit. Most of your writing in that bug report would be in > >> line with lack of sleep or prolonged fatigue, or some other factor that > >> causes you to be compartmentalized in your own verions of things and > >> completely ignore the real issue at hand. > >> > >> Similar behavioral pattern that happened on China Airlines Flight 006. > >> The resemblance is striking: the pilots completely unaware of what the > >> real problem is, and were dealing with non-issues (rather than fluing > >> the plane). Similar thing here: the user tells you one thing (the real > >> issue), your situational awareness is as if something entirely different > >> has been taking place (dupes, etc). Interesting. > >> > >> http://en.wikipedia.org/wiki/China_Airlines_Flight_006 > >> > >> http://www.rvs.uni-bielefeld.de/publications/Incidents/DOCS/ComAndRep/Ch > >>inaAir/AAR8603.html > >> > >> http://catless.ncl.ac.uk/Risks/3.79.html > >> > >> [...] the captain had become so preoccupied with the dwindling > >> airspeed that he failed to note that the autopilot, which relied on > >> ailerons only, not the rudder, to maintain heading, was using the > >> maximum left control- wheel deflection available to it to overcome the > >> thrust asymmetry due to the hung outboard engine. When the right wing > >> nevertheless began to drop, ... the captain didn't notice the bank on > >> the attitude indicator ... . When he did notice it, he refused to > >> believe what he saw. At this point, ... the upset had begun and the > >> captain and first officer were both spatially disorientated. > >> > >> You can almost substitute terms from the bugreport for the flying terms > >> above... > >> > >> > >> Common thing to happen when you're tired, distracted, etc. So this is > >> nothing personal, just noticing a pretty common problem. BTDT, one has > >> to learn to recognize the first signs and take a break (helps me). At > >> least here it won't kill anyone. Now, if you *are* sleeping well (and > >> long enough), and are not tired, then IANAD and wouldn't know what to do > >> either... > > I've spent a fair amount of time helping users on irc in #winehq and > > this bug report sounds like one of the most common issues, user error > > precipitated by a distribution that requires a high level of user > > knowledge. The back and forth on the bug is mostly a waste of time > > trying to figure out user compile time options, which version of wine > > is actually running when multiple versions are installed etc. I can > > understand Vitaliy's frustration with this stuff as its easily > > avoidable on almost all binary package based distributions. > > > > Maybe we should point gentoo users at the gentoo wiki page we have and > > enhance that page with things we've learned from gentoo debugging. > As a Gentoo user, I would have to agree. If a fairly good document is > put together a lot of headaches can be avoided. When they are done > following the guide then bugzilla staff and others can help them. The > advantages of this are twofold. One is that there are fewer headaches > from chasing down weird compile time options, etc. The second is that > Gentoo is a more advance/complicated distro and some of the users really > know their stuff and can be quite useful. By providing good > documentation we might encourage those users to participate more. Weed > out the bad, keep the good. Umm, how exactly does Gentoo affect the "legacy" compilation of an autotools-based tarball, where you simply untar, configure and make install which normally will go to /usr/local/...? I'd expect this to work the same on my FC6 system, just like it used to work on a FreeBSD system last time I checked (a few months ago). If wine is not overzealous by design in finding its bits and pieces (I doubt, since I don't recall seeing such a bug) and gets correctly invoked, AFAIK it will ignore any existing installations and do its thing. I'd routinely have version A of wine installed from an rpm, and one or more local versions installed in $HOME for testing before deployment. Somehow it had just worked. Heck, every once in a while when I need two or more versions of wine deployed at the same time from an rpm, that'll work just fine too (a development tool or two used to require an older wine version to work). As a more useful measure, I'd suggest bug reporters who run into possible
Re: Is there a process for reviewing a bugzilla staffer?
On Thursday 02 August 2007, Chris Morgan wrote: > > Rewriting: > > > > We can conclude that VM was distracted first by the mention of the > > ies4lin and second by attempts to attribute the problem to ies4lin, and > > that, because of these distractions, he was unable to assess properly the > > issue at hand. One also concludes that VM over-relied on the features of > > the development process automation (bugzilla) and this this was also > > causel to tine incident since data available from bugzilla effectively > > masked the real problem. > > I also wanted to mention that ies4lin SHOULD be a distraction. If > users want to use unsupported tools to modify their configuration do > we really want to be debugging those modifications as well as wine > issues? IMHO, you succumb just the same to completely ignoring the real problem at hand. Mind you, flt 006 flight crew was not one person only, yet they were all equally confused (or so it seemed, at least PF and FE were). Nowhere did the bug reporter indicate that he used ies4lin on the failing configuration. "Coincidentally, ies4lin, which runs fine on prior versions of Wine, doesn't accept URL line input in 0.9.42." The user just mentioned this as a coincidence. He then explicitly states: "InfoSelect is broken on a fresh installation before ies4lin is installed to it" Then, VM rambles once more and finally says that he's sorry for missing an attachment. I admit there's a chance that previous installs were not done correctly by WB, just like the #4 engine *did* get hung in flt 006. The deal is that in both cases, the engineer who should have worked the problem did something to exacerbate the issue. VM didn't, IMHO, follow the best approach to get WB to check if he reports the results from a correct install (this is not really documented AFAICS). In 006, the FE didn't follow the correct procedure to un-hang the engine (close bleed air valve). So, now the bug is on the right track. If what Mikolaj Zalewski suggests to check turns out to be the culprit, this will be, in the end, an easy one. Just like flt 006 was an easy one once the pilots went below the clouds and saw what the airplane was really doing. Either way, most of VMs doing was consistent with being generally confused and not letting the bug-reported reality sink in. Again, this is not an indication of incompetence -- well trained people (IIRC human factors) will tend to do it more than untrained ones, given right combination of external factors (fatigue, etc). Heck, being in a grumpy mood can make you act like this -- as long as it's transient, it's something that one can expect to see and can live with :) Cheers, Kuba
Re: Is there a process for reviewing a bugzilla staffer?
Chris Morgan wrote: On 8/2/07, Kuba Ober <[EMAIL PROTECTED]> wrote: On Wednesday 01 August 2007, Vitaliy Margolen wrote: Whit Blauvelt wrote: Hi, Is there a formal process for reviewing an arguably incompetent bugzilla staffer? Obviously it wouldn't be to submit their name as a bug. But is there any defined administrative layer that concerns itself with people on that level who are dragging on the project? I looked around a bit for information on this. Sorry if it's posted somewhere and I missed it. Thanks, Whit To spare everyone time and to skip directly to an entertainment see bug 9147: http://bugs.winehq.org/show_bug.cgi?id=9147 I agree with Whit. Most of your writing in that bug report would be in line with lack of sleep or prolonged fatigue, or some other factor that causes you to be compartmentalized in your own verions of things and completely ignore the real issue at hand. Similar behavioral pattern that happened on China Airlines Flight 006. The resemblance is striking: the pilots completely unaware of what the real problem is, and were dealing with non-issues (rather than fluing the plane). Similar thing here: the user tells you one thing (the real issue), your situational awareness is as if something entirely different has been taking place (dupes, etc). Interesting. http://en.wikipedia.org/wiki/China_Airlines_Flight_006 http://www.rvs.uni-bielefeld.de/publications/Incidents/DOCS/ComAndRep/ChinaAir/AAR8603.html http://catless.ncl.ac.uk/Risks/3.79.html [...] the captain had become so preoccupied with the dwindling airspeed that he failed to note that the autopilot, which relied on ailerons only, not the rudder, to maintain heading, was using the maximum left control- wheel deflection available to it to overcome the thrust asymmetry due to the hung outboard engine. When the right wing nevertheless began to drop, ... the captain didn't notice the bank on the attitude indicator ... . When he did notice it, he refused to believe what he saw. At this point, ... the upset had begun and the captain and first officer were both spatially disorientated. You can almost substitute terms from the bugreport for the flying terms above... Common thing to happen when you're tired, distracted, etc. So this is nothing personal, just noticing a pretty common problem. BTDT, one has to learn to recognize the first signs and take a break (helps me). At least here it won't kill anyone. Now, if you *are* sleeping well (and long enough), and are not tired, then IANAD and wouldn't know what to do either... Cheers, Kuba I've spent a fair amount of time helping users on irc in #winehq and this bug report sounds like one of the most common issues, user error precipitated by a distribution that requires a high level of user knowledge. The back and forth on the bug is mostly a waste of time trying to figure out user compile time options, which version of wine is actually running when multiple versions are installed etc. I can understand Vitaliy's frustration with this stuff as its easily avoidable on almost all binary package based distributions. Maybe we should point gentoo users at the gentoo wiki page we have and enhance that page with things we've learned from gentoo debugging. As a Gentoo user, I would have to agree. If a fairly good document is put together a lot of headaches can be avoided. When they are done following the guide then bugzilla staff and others can help them. The advantages of this are twofold. One is that there are fewer headaches from chasing down weird compile time options, etc. The second is that Gentoo is a more advance/complicated distro and some of the users really know their stuff and can be quite useful. By providing good documentation we might encourage those users to participate more. Weed out the bad, keep the good. Chris ---Alex
Re: [1/5] DDraw: Some drivers return DDERR_INVALIDPARAMS if DXTn surfaces aren't supported
Am Donnerstag, 2. August 2007 13:57 schrieb H. Verbeet: > On 02/08/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > > > If the return value is irrelevant though, what's the point of the test? > > > > I want to catch all the possible return values from windows drivers, even > > if it's just for documentation purposes. > > That doesn't seem very useful if there are no actual applications > depending on those values. The idea is to catch a few things in our test beyond needs of apps known to us. Some of my tests test things even though I had no application that really needed it. So I prefer to document things I come accross, even if I can't see an immediate use, and will most likely never have a use. You never know what the future brings. I do not claim that I have a scheme when writing tests for unused functions or not doing so, it mainly depends on wether I'm in the moot of writing a test :-)
Re: Is there a process for reviewing a bugzilla staffer?
> Rewriting: > > We can conclude that VM was distracted first by the mention of the ies4lin and > second by attempts to attribute the problem to ies4lin, and that, because of > these distractions, he was unable to assess properly the issue at hand. One > also concludes that VM over-relied on the features of the development process > automation (bugzilla) and this this was also causel to tine incident since > data available from bugzilla effectively masked the real problem. > I also wanted to mention that ies4lin SHOULD be a distraction. If users want to use unsupported tools to modify their configuration do we really want to be debugging those modifications as well as wine issues? Chris
Re: Is there a process for reviewing a bugzilla staffer?
On 8/2/07, Kuba Ober <[EMAIL PROTECTED]> wrote: > On Wednesday 01 August 2007, Vitaliy Margolen wrote: > > Whit Blauvelt wrote: > > > Hi, > > > > > > Is there a formal process for reviewing an arguably incompetent bugzilla > > > staffer? Obviously it wouldn't be to submit their name as a bug. But is > > > there any defined administrative layer that concerns itself with people > > > on that level who are dragging on the project? > > > > > > I looked around a bit for information on this. Sorry if it's posted > > > somewhere and I missed it. > > > > > > Thanks, > > > Whit > > > > To spare everyone time and to skip directly to an entertainment see bug > > 9147: http://bugs.winehq.org/show_bug.cgi?id=9147 > > I agree with Whit. Most of your writing in that bug report would be in line > with lack of sleep or prolonged fatigue, or some other factor that causes you > to be compartmentalized in your own verions of things and completely ignore > the real issue at hand. > > Similar behavioral pattern that happened on China Airlines Flight 006. The > resemblance is striking: the pilots completely unaware of what the real > problem is, and were dealing with non-issues (rather than fluing the plane). > Similar thing here: the user tells you one thing (the real issue), your > situational awareness is as if something entirely different has been taking > place (dupes, etc). Interesting. > > http://en.wikipedia.org/wiki/China_Airlines_Flight_006 > > http://www.rvs.uni-bielefeld.de/publications/Incidents/DOCS/ComAndRep/ChinaAir/AAR8603.html > > http://catless.ncl.ac.uk/Risks/3.79.html > > [...] the captain had become so preoccupied with the dwindling > airspeed that he failed to note that the autopilot, which relied on ailerons > only, not the rudder, to maintain heading, was using the maximum left control- > wheel deflection available to it to overcome the thrust asymmetry due to the > hung outboard engine. When the right wing nevertheless began to drop, ... > the captain didn't notice the bank on the attitude indicator ... . When he > did notice it, he refused to believe what he saw. At this point, ... the > upset had begun and the captain and first officer were both spatially > disorientated. > > You can almost substitute terms from the bugreport for the flying terms > above... > > > Common thing to happen when you're tired, distracted, etc. So this is nothing > personal, just noticing a pretty common problem. BTDT, one has to learn to > recognize the first signs and take a break (helps me). At least here it won't > kill anyone. Now, if you *are* sleeping well (and long enough), and are not > tired, then IANAD and wouldn't know what to do either... > > Cheers, Kuba I've spent a fair amount of time helping users on irc in #winehq and this bug report sounds like one of the most common issues, user error precipitated by a distribution that requires a high level of user knowledge. The back and forth on the bug is mostly a waste of time trying to figure out user compile time options, which version of wine is actually running when multiple versions are installed etc. I can understand Vitaliy's frustration with this stuff as its easily avoidable on almost all binary package based distributions. Maybe we should point gentoo users at the gentoo wiki page we have and enhance that page with things we've learned from gentoo debugging. Chris
Re: Is there a process for reviewing a bugzilla staffer?
> We can conclude that VM was distracted first by the mention of the ies4lin > and second by attempts to attribute the problem to ies4lin, and that, > because of these distractions, he was unable to assess properly the issue > at hand. One also concludes that VM over-relied on the features of the > development process automation (bugzilla) and this this was also causel to > tine incident I meant 'causal to the incident'. Can't spell today, and someone turned kmail's spellchecker off (sure thing it could have been me). Cheers, Kuba
Re: Is there a process for reviewing a bugzilla staffer?
> > > Is there a formal process for reviewing an arguably incompetent > > > bugzilla staffer? > > To spare everyone time and to skip directly to an entertainment see bug > > 9147: http://bugs.winehq.org/show_bug.cgi?id=9147 > I agree with Whit. Most of your writing in that bug report would be in line > with lack of sleep or prolonged fatigue, or some other factor that causes > you to be compartmentalized in your own verions of things and completely > ignore the real issue at hand. > [...] > [...] the captain had become so preoccupied with the dwindling > airspeed that he failed to note that the autopilot, which relied on > ailerons only, not the rudder, to maintain heading, was using the maximum > left control- wheel deflection available to it to overcome the thrust > asymmetry due to the hung outboard engine. When the right wing nevertheless > began to drop, ... the captain didn't notice the bank on the attitude > indicator ... . When he did notice it, he refused to believe what he saw. > At this point, ... the upset had begun and the captain and first officer > were both spatially disorientated. > > You can almost substitute terms from the bugreport for the flying terms > above... http://www.rvs.uni-bielefeld.de/publications/Incidents/DOCS/ComAndRep/ChinaAir/AAR8603.html "The captain was not only unable to assess the situation properly, he was confused by it; therefore, he was unable to take the necessary action to correct the situation." "*The Safety Board can only conclude that the captain was distracted first by the evaluation of the engine malfunction and second by his attempts to arrest the decreasing airspeed, and that, because of these distractions, he was unable to assess properly and promptly the approaching loss of airplane control. The Safety Board also concludes that the captain over-relied on the autopilot and that this was also causal to the accident since the autopilot effectively masked the approaching onset of the loss of control of the airplane.*" (emphasis mine) Rewriting: We can conclude that VM was distracted first by the mention of the ies4lin and second by attempts to attribute the problem to ies4lin, and that, because of these distractions, he was unable to assess properly the issue at hand. One also concludes that VM over-relied on the features of the development process automation (bugzilla) and this this was also causel to tine incident since data available from bugzilla effectively masked the real problem. This is a classical pattern, so I'd be hard pressed to call Vitaliy "incompetent". Overdependence on bugzilla and some fatigue, that's what it is if you ask me. Cheers, Kuba
Re: Is there a process for reviewing a bugzilla staffer?
On Wednesday 01 August 2007, Vitaliy Margolen wrote: > Whit Blauvelt wrote: > > Hi, > > > > Is there a formal process for reviewing an arguably incompetent bugzilla > > staffer? Obviously it wouldn't be to submit their name as a bug. But is > > there any defined administrative layer that concerns itself with people > > on that level who are dragging on the project? > > > > I looked around a bit for information on this. Sorry if it's posted > > somewhere and I missed it. > > > > Thanks, > > Whit > > To spare everyone time and to skip directly to an entertainment see bug > 9147: http://bugs.winehq.org/show_bug.cgi?id=9147 I agree with Whit. Most of your writing in that bug report would be in line with lack of sleep or prolonged fatigue, or some other factor that causes you to be compartmentalized in your own verions of things and completely ignore the real issue at hand. Similar behavioral pattern that happened on China Airlines Flight 006. The resemblance is striking: the pilots completely unaware of what the real problem is, and were dealing with non-issues (rather than fluing the plane). Similar thing here: the user tells you one thing (the real issue), your situational awareness is as if something entirely different has been taking place (dupes, etc). Interesting. http://en.wikipedia.org/wiki/China_Airlines_Flight_006 http://www.rvs.uni-bielefeld.de/publications/Incidents/DOCS/ComAndRep/ChinaAir/AAR8603.html http://catless.ncl.ac.uk/Risks/3.79.html [...] the captain had become so preoccupied with the dwindling airspeed that he failed to note that the autopilot, which relied on ailerons only, not the rudder, to maintain heading, was using the maximum left control- wheel deflection available to it to overcome the thrust asymmetry due to the hung outboard engine. When the right wing nevertheless began to drop, ... the captain didn't notice the bank on the attitude indicator ... . When he did notice it, he refused to believe what he saw. At this point, ... the upset had begun and the captain and first officer were both spatially disorientated. You can almost substitute terms from the bugreport for the flying terms above... Common thing to happen when you're tired, distracted, etc. So this is nothing personal, just noticing a pretty common problem. BTDT, one has to learn to recognize the first signs and take a break (helps me). At least here it won't kill anyone. Now, if you *are* sleeping well (and long enough), and are not tired, then IANAD and wouldn't know what to do either... Cheers, Kuba
Re: Patch: VarWeekdayName
> Thank you. Hope it will be better this time. Also, I'll send a test
> if this is OK.
This one looks pretty good to me, but I have one error and a few nits
to correct:
The error:
+ {
+ERR("GetLocaleInfo of 0x%x failed in 2nd stage?!\n", localeValue);
+SysFreeString(*pbstrOut);
You should set *pbstrOut to NULL in this case.
The nits:
You have a couple small errors in the comments:
- You misspell iWeekday
- The comment for iWeekday in the params section implies 0 is allowed,
but the first check in the function disallows it.
You also inconsistently put spaces after commas - please do in all cases.
Attaching a test with the patch would certainly help.
--Juan
RE: Is there a process for reviewing a bugzilla staffer?
I don't think we need to be rude and poke fun at new wine users by pointing out their mistakes to everyone. He may someday prove to be a valuable asset to the project, or may be driven off from contributing altogether because a dev/admin had to point out his errors for "entertainment" purposes. I don't see being rude to new users "entertainment", it comes across as being kind of a bully and deters people from contributing. We're all linux/wine newbs at some point, and telling them their posts are useless information instead of trying to help them in a friendly fashion is going to end up driving them away from the project.> Date: Wed, 1 Aug 2007 21:09:13 -0600> From: [EMAIL PROTECTED]> To: wine-devel@winehq.org> Subject: Re: Is there a process for reviewing a bugzilla staffer?> > Whit Blauvelt wrote:> > Hi,> > > > Is there a formal process for reviewing an arguably incompetent bugzilla> > staffer? Obviously it wouldn't be to submit their name as a bug. But is> > there any defined administrative layer that concerns itself with people on> > that level who are dragging on the project?> > > > I looked around a bit for information on this. Sorry if it's posted> > somewhere and I missed it.> > > > Thanks,> > Whit> > > > To spare everyone time and to skip directly to an entertainment see bug > 9147: http://bugs.winehq.org/show_bug.cgi?id=9147> > Vitaliy.> > > _ See what you’re getting into…before you go there. http://newlivehotmail.com
Re: dinput - Allow the use of the standard Joystick GUID when calling CreateDevice
On Thu, Aug 02, 2007 at 06:54:12AM -0600, Vitaliy Margolen wrote: > >OK, so how do i force my system to use the other implementation (so i > >can test it) ? > >I have a Logitech WingMan Extreme (old version). > Just (re)move /dev/input/js*. Or in dinput change device name to point to > non-existent directory/device (in joystick_linux.c). or on systems with udev and friends just dont load joydev. just evdev. then this devices will not be created (even on non-udev boxes /dev/input/js* would not work). -- cu pgpeGFt7uAtjv.pgp Description: PGP signature
Re: dinput - Allow the use of the standard Joystick GUID when calling CreateDevice
Peter Dons Tychsen wrote:
On Tue, 2007-07-31 at 20:05 -0600, Vitaliy Margolen wrote:
Peter Dons Tychsen wrote:
On Tue, 2007-07-31 at 06:34 -0600, Vitaliy Margolen wrote:
Peter Dons Tychsen wrote:
On Mon, 2007-07-30 at 21:20 +0200, Peter Dons Tychsen wrote:
On Sun, 2007-07-29 at 17:43 -0600, Vitaliy Margolen wrote:
Peter Dons Tychsen wrote:
OK. Please review this diff:
I will re-submit it if you like it.
/Pedro
Alright looks good now (you might want to remove the extra white space your
patch adds - git complains about those). Just left to make the same change
to the other joystick interface :)
BTW don't forget to cc: the wine-devel list when you replying.
Vitaliy.
OK. I still feel that trying to sync joystick_linuxinput.c and
joystick_linux.c is out of scope for this patch. But as my steadiness
has limits i have done some of it anyway... :). I have kept the changes
modest.
Please take a look at the new patch.
On another note i will agree with you that it would be practical if the
two files had similar (or maybe even shared) code. Redundant code is
never very practical as it always ends up as this very example. The two
implementations which were supposed to identical always drift apart. If
things are supposed to do the same, keep them together to begin with.
Thanks,
Maybe i would be more successful if i actually attached the
patch :-)
Here it is
Just few small things left:
-#undef MAX_JOYSTICKS
As I mentioned earlier you should move this instead of removing it completely.
static HRESULT joydev_create_deviceW(IDirectInputImpl *dinput, REFGUID rguid,
REFIID riid, LPDIRECTINPUTDEVICEW* pdev)
{
- int i;
-
- find_joydevs();
You removed a really important function call here.
+static HRESULT joydev_create_deviceA(IDirectInputImpl *dinput, REFGUID rguid,
REFIID riid, LPDIRECTINPUTDEVICEA* pdev)
+{
+ unsigned short index;
+
+ if ((index = get_joystick_index(rguid)) < MAX_JOYDEV) {
+if ((riid == NULL) ||
If you reformat the whole function, please make it 4-space indented.
OK. Here is the new patch:
Looks good to me. The problem is, it doesn't work for me (USB joystick). I
think you forgot to look at how joystick_linuxinput.c handles that data3
field. It's not just 0 based index...
I told you i should bot have merged the changes over to
joystick_linuxinput as they were too different... :-)
OK, so how do i force my system to use the other implementation (so i
can test it) ?
I have a Logitech WingMan Extreme (old version).
Just (re)move /dev/input/js*. Or in dinput change device name to point to
non-existent directory/device (in joystick_linux.c).
Vitaliy.
Re: Direct3D Game test framework
> To make this useful, we need to solve 'DirectX detection failed' bug, so we > can run real tests nightly. Could you send me ~/.wine directory you are > using with latest WineHq? Do you have HKCU/Software/Wine/Direct3D/DirectDrawRenderer set to "gdi" perhaps? This disables D3D support altogether. You could try with a fresh .wine, it should run 3dmark2000 and 2001 out of the box. I'm not sure wether I should really attempt to send you my ~/.wine, it is full with games and has a size of 51GB :-) . I could send you the .reg files though.
Re: Direct3D Game test framework
Hello Stefan! > It is without CxTest and without VNC. I do have HW acceleration and OpenGL > (GLX) enabled. Attached is output of xdpyinfo. > > I am going to try whether 3DMark2001 works. 3DMark2001 behaves the same way. Note this is long lasting bug, I remember on WineConf 2006 I was able to run 3DMark2000 under CrossOver, but only after the fresh installation. Subsequent runs failed with the same error we have today (DirectX detection failed). It is probably configuration dependent (~/.wine). However, I was able to run it on another machine (Mac OS X) using latest CrossOver nightly build. There were some minor issues, but after a while I was able to get benchmark.txt file. I submitted that file to CxTest server several times, to test new Direct3D evaluation functionality. It is here: http://www.cxtest.org/product-d3d-eval?id_product=3&m_from=7&d_from=26&y_from=2007&m_to=8&d_to=2&y_to=2007&submit=Go Please have a look whether this is (roughly) what you need. To make this useful, we need to solve 'DirectX detection failed' bug, so we can run real tests nightly. Could you send me ~/.wine directory you are using with latest WineHq? Thanks, Martin
Re: [1/5] DDraw: Some drivers return DDERR_INVALIDPARAMS if DXTn surfaces aren't supported
On 02/08/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: >+ok(hr == DD_OK || hr == DDERR_NOTEXTUREHW || DDERR_INVALIDPARAMS, That doesn't do what you want it to do. If the return value is irrelevant though, what's the point of the test?
Re: [5/5] D3D9: Check for volume texture support before running the volume test
Am Donnerstag, 2. August 2007 13:53 schrieb H. Verbeet:
> On 02/08/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > +if(!(caps.TextureCaps & D3DPTEXTURECAPS_CUBEMAP)) {
>
> That doesn't check for volume textures.
oops again... :-|
Re: [1/5] DDraw: Some drivers return DDERR_INVALIDPARAMS if DXTn surfaces aren't supported
On 02/08/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > > If the return value is irrelevant though, what's the point of the test? > I want to catch all the possible return values from windows drivers, even if > it's just for documentation purposes. That doesn't seem very useful if there are no actual applications depending on those values.
Re: [1/5] DDraw: Some drivers return DDERR_INVALIDPARAMS if DXTn surfaces aren't supported
Am Donnerstag, 2. August 2007 13:41 schrieb H. Verbeet: > On 02/08/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > >+ok(hr == DD_OK || hr == DDERR_NOTEXTUREHW || DDERR_INVALIDPARAMS, > > That doesn't do what you want it to do. oops... > If the return value is irrelevant though, what's the point of the test? I want to catch all the possible return values from windows drivers, even if it's just for documentation purposes.
Re: [5/5] D3D9: Check for volume texture support before running the volume test
On 02/08/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> +if(!(caps.TextureCaps & D3DPTEXTURECAPS_CUBEMAP)) {
That doesn't check for volume textures.
dwarf2_parse_udt_type Unhandled Tag type 0x16
I get tons of these sometimes when a program crashes: fixme:dbghelp_dwarf:dwarf2_parse_udt_type Unhandled Tag type 0x16 at ctx(0x34ec70,L"kernel32"), for debug_info(abbrev:0x17ab04,symt:0xe24ee4) which makes debugging difficult.
re: OT: Everyone at minnesota ok?
I checked with Jeremy six hours ago and he said he hadn't heard of any of his folks being involved, whew. I've driven over that bridge a lot myself, and my father in law drove over it an hour before the collapse. There's a video of the collapse at http://edition.cnn.com/2007/US/08/02/bridge.collapse/
Re: mshtml #2: Make get_typeinfo thread safe.
Jacek Caban <[EMAIL PROTECTED]> writes: > } > + > +tl = InterlockedExchangePointer((void**)&typelib, tl); > + > +if(tl) > +ITypeLib_Release(tl); That's not thread-safe. You need to use InterlockedCompareExchangePointer. -- Alexandre Julliard [EMAIL PROTECTED]
OT: Everyone at minnesota ok?
For those who have not head, there was a lethal bridge collapse and there are several casualties. Codeweavers is located near there. Just wanted to make sure everyone is ok. Shachar
msvcrt40.dll
Dear all, In relation to the file msvcrt40.dll File Version 5.1.2600.2180 Product Version 5.1.2600.2180 This file has been transformed and forwards all of its calls to either msvcrt.dll or msvcirt.dll The forwards to msvcrt.dll are set in the current wine msvcr40.spec but the rest of the functions, which should be forwarded to msvcirt, are stub. Nevertheless, msvcirt.dll is not currently one of the files to be ported, i.e., dlls/msvcirt does not exist. My questions are: 1. Can we add the forward to all the rest of the functions in the msvcrt40.dll spec file to msvcirt.dll? 2. Should we first add a wine port of msvcirt.dll? Luis
