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

Re: dsound: fix remaining ds3d, dsound, dsound8 test failures shown on test.winehq.org

by Paul Vriens

Jeff Zaroyko wrote: > This should clear up the remaining dsound test failures shown for the > Win98 and WinME test results. > > > ------------------------------------------------------------------------ > > Hi Jeff, Would be a nice-to-have if you could add the platforms as comments to the different return values. -- Cheers, Paul.

Dec. 4, 2008

Re: wineconsole: Wait on events in curses backend using select instead of poll

by Martin Storsjö

On Thu, 4 Dec 2008, Damjan Jovanovic wrote: > On Mon, Dec 1, 2008 at 11:57 AM, Martin Storsjö <martin(a)martin.st> wrote: >> >> But there may of course be other reasons for using poll, which I don't know >> about. > > select() not only has a hard limit on the number of file descriptors > (1024 or whatever) that can only be increased at kernel and libc build > time, but also has a corresponding limit on the maximum file > descriptor that can be selected (1023). Ah, thanks for pointing this out. > On the other hand, console handles presumably exist on the low file > descriptors (0, 1, and 2 - though doesn't transferring fds from the > wineserver result in call to dup() which can change that?) and we poll > very few of them, so those could possibly be done using select() - on > MacOS *only*. So, what would be the correct and clean way of conditionally enabling this? The broken poll behaviour could be checked with this kind of snippet: #include <poll.h> int main(int argc, char** argv) { struct pollfd pfd; pfd.fd = 0; pfd.events = POLLIN; poll(&pfd, 1, 0); return (pfd.revents & POLLNVAL) ? 1 : 0; } Should this kind of detection be welded into configure in some way? Or would it be better to simply define e.g. POLL_BROKEN whenever building for Darwin? That way, the binary would work well on all versions even if built on some newer version, if they would happen to fix the bug there. Regards, // Martin

Dec. 4, 2008

Re: wineconsole: Wait on events in curses backend using select instead of poll

by Damjan Jovanovic

On Mon, Dec 1, 2008 at 11:57 AM, Martin Storsjö <martin(a)martin.st> wrote: > On Mon, 1 Dec 2008, Kai Blin wrote: > >> On Sunday 30 November 2008 00:52:57 Martin Storsjö wrote: >>> >>> poll can't handle terminal devices on Darwin, since Tiger. See the >>> following discussion: >>> http://lists.apple.com/archives/Darwin-dev/2006/Apr/msg00066.html >> >> There's reasons we switched from select to poll. You can't just switch >> back to > > As far as I can tell from the history of curses.c, it never used select > (directly) before, it used WaitForMultipleObjects, which was changed into a > poll in 267d38e1bc78541221d20cc72a759acc78908e8e, "wineconsole: Don't use a > Win32 wait on a Unix file descriptor." > > But there may of course be other reasons for using poll, which I don't know > about. select() not only has a hard limit on the number of file descriptors (1024 or whatever) that can only be increased at kernel and libc build time, but also has a corresponding limit on the maximum file descriptor that can be selected (1023). On the other hand, console handles presumably exist on the low file descriptors (0, 1, and 2 - though doesn't transferring fds from the wineserver result in call to dup() which can change that?) and we poll very few of them, so those could possibly be done using select() - on MacOS *only*. > >> select to work around a OSX _bug_. If Apple can't get their act together >> to >> fix this, this needs to go behind a configure check/ifdef. > > Yes, that's true. > > I'm not too familiar with the wine codebase and customs, so instead of > nagging you with questions on what a proper solution would look like, should > I just file a bug with the actual issue; that the curses based console is > unusable on Darwin at the moment? > > // Martin > > > Damjan

Dec. 4, 2008

Re: Wine t-shirts?

by Steven Edwards

Heh sorry for all the spam, it would help if I used gmail for everything, in the original thread Jer already gave blanket permission for Wine to that logo: from Jeremy White <jwhite(a)winehq.org> to Dan Kegel <dank(a)kegel.com> cc Wine Developers List <wine-devel(a)winehq.org> date Wed, Apr 23, 2008 at 7:40 AM subject Re: Wine t-shirts? mailing list wine-devel.winehq.org Filter messages from this mailing list > http://kegel.com/wine/wine-penguin-corkscrew.png Jon Parshall is proud of his ability to draw those penguins, and we'd gladly send that artwork to anyone that wanted to make a T-shirt. Note, though, that we felt we had to (very sadly) drop the penguin; it doesn't really work for Mac users. Again sorry for the spam, I will stop with it now. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Dec. 4, 2008

Re: Wine t-shirts?

by Steven Edwards

Would help if I actually send the email to you Jer On Wed, Dec 3, 2008 at 11:43 PM, Steven Edwards <sedwards(a)bordeauxgroup.com> wrote: > On Wed, Dec 3, 2008 at 6:12 PM, Ismael Barros² <razielmine(a)gmail.com> wrote: >> Hum, that would be cool, I'll ask the boss but it's probably in. >> >> Does anyone have a higher resolution version? > > There is a copy of the images from a prior email Jeremy Newman at > CodeWeavers sent here > > ftp://wine.codeweavers.com/pub/wine/logos/ > > Jeremy White of CodeWeavers has been pretty liberal in the past about > letting others (myself included) use the old logos they developed for > other Wine related projects now that CrossOver has moved to a new > logo. > > jwhite, was it implied by the drunk Penguin EPS being on the ftp site > that the Wine project now has free reign to that logo? > > > Thanks > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo > -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Dec. 4, 2008

Re: Wine t-shirts?

by Steven Edwards

On Wed, Dec 3, 2008 at 6:12 PM, Ismael Barros² <razielmine(a)gmail.com> wrote: > Hum, that would be cool, I'll ask the boss but it's probably in. > > Does anyone have a higher resolution version? There is a copy of the images from a prior email Jeremy Newman at CodeWeavers sent here ftp://wine.codeweavers.com/pub/wine/logos/ Jeremy White of CodeWeavers has been pretty liberal in the past about letting others (myself included) use the old logos they developed for other Wine related projects now that CrossOver has moved to a new logo. jwhite, was it implied by the drunk Penguin EPS being on the ftp site that the Wine project now has free reign to that logo? Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Dec. 4, 2008

Re: Wine t-shirts?

by Steven Edwards

On Wed, Dec 3, 2008 at 11:15 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: >> +1 on the teeshirts if you can use the drunk Penguin on some of them >> now that CodeWeavers is not using it for products. >> >> http://www.ixsoft.de/software/products/CWTSHIRTDP-L.html >> >> > It would be nice to ask the folks at CodeWeavers before running off and > producing a bunch of t-shirts. They may not own the copyrights to it, > but can point you in the right direction. That was supposed to be implied by the 'if you can use'. I guess I should have clarified that yes of course be sure to check with CodeWeavers first. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Dec. 4, 2008

Re: wineconsole: Wait on events in curses backend using select insteadof poll

by Dmitry Timoshkov

"James McKenzie" <jjmckenzie51(a)earthlink.net> wrote: > Martin Storsjö wrote: >> >> poll can't handle terminal devices on Darwin, since Tiger. See the >> following discussion: >> http://lists.apple.com/archives/Darwin-dev/2006/Apr/msg00066.html >> > This will have to be setup so that it only works for Macs. Maybe this > can be a static patch in the Darwine code but it does not belong in the > Wine code stack. Why do you prefer to have a broken hack in Darwine instead of fixing this properly? Btw, what are the difference between Darwine and WineHQ that you insist to have a different name (Darwine) instead of just Wine? Are you aware that due to that all bugs reported to Wine bugzilla mentioning Darwine are closed as invalid? Do you have your own bug tracking system? -- Dmitry.

Dec. 4, 2008

Re: Wine t-shirts?

by James McKenzie

Steven Edwards wrote: > On Wed, Dec 3, 2008 at 9:50 AM, Ismael Barros² <razielmine(a)gmail.com> wrote: > >> I already asked julliard about permissions and donations (winehq is >> getting 3€ for each sold T-shirt), and now I should determine the >> T-shirt design itself. We'll probably start off with the classical >> wine logo, but we're not sure about the composition, any ideas? The >> website logo looks fine (without the shades, we're limited to 4 >> colours), but the "hq" is probably unnecessary for a T-shirt. >> > > +1 on the teeshirts if you can use the drunk Penguin on some of them > now that CodeWeavers is not using it for products. > > http://www.ixsoft.de/software/products/CWTSHIRTDP-L.html > > It would be nice to ask the folks at CodeWeavers before running off and producing a bunch of t-shirts. They may not own the copyrights to it, but can point you in the right direction. James McKenzie

Dec. 4, 2008

Re: wineconsole: Wait on events in curses backend using select instead of poll

by James McKenzie

Martin Storsjö wrote: > > poll can't handle terminal devices on Darwin, since Tiger. See the > following discussion: > http://lists.apple.com/archives/Darwin-dev/2006/Apr/msg00066.html > This will have to be setup so that it only works for Macs. Maybe this can be a static patch in the Darwine code but it does not belong in the Wine code stack. I'll look at what the Darwine code can and cannot do. James McKenzie

Dec. 4, 2008

Re: patch for gdi32

by Dan Kegel

On Wed, Dec 3, 2008 at 3:38 PM, Xiangrong Fang <xrfang(a)gmail.com> wrote: > It is indeed bug #4065. I read the info there, although I don't fully > understand every bit information there, but that is marked as FIXED > and CLOSED?? As far as I know, this is NOT fixed yet, and it affect a > HUGE amount of Chinese applications, those applications are otherwise > perfectly supported by wine. I think 4065 was closed because we found what seemed to be an acceptable way to get that particular app (Picasa) working. > A very good progress in this area is > that I found Chinese text are more properly auto-wrapped in recent > Wine releases, which is excellent. We are very interested in providing excellent Asian language support. We can use all the help we can get, though, as few Wine developers speak any Asian languages well. > About this issue, shall I submit discussion in #4065 or open a new > bug? (I need to upload some screenshots to illustrate the problem -- > this is NOT a missing font problem as discussed). Please open a new bug. If possible, include source code for a small noninteractive program that demonstrates the problem. e.g. a C program that displays a single character that is wrong in wine but right in windows. > BTW, for these discussions, shall I use wine-devel or wine-patch? All discussions go to wine-devel. When replying to a message on wine-patches, please change the destination to wine-devel. - Dan

Dec. 3, 2008

Re: patch for gdi32

by Xiangrong Fang

Hi Dan, Thank you for your explanations! It is indeed bug #4065. I read the info there, although I don't fully understand every bit information there, but that is marked as FIXED and CLOSED?? As far as I know, this is NOT fixed yet, and it affect a HUGE amount of Chinese applications, those applications are otherwise perfectly supported by wine. A very good progress in this area is that I found Chinese text are more properly auto-wrapped in recent Wine releases, which is excellent. About this issue, shall I submit discussion in #4065 or open a new bug? (I need to upload some screenshots to illustrate the problem -- this is NOT a missing font problem as discussed). BTW, for these discussions, shall I use wine-devel or wine-patch? Please advise. Thank you! Sincerely, Shannon 2008/12/4 Dan Kegel <dank(a)kegel.com>: > On Wed, Dec 3, 2008 at 1:24 PM, Dan Kegel <dank(a)kegel.com> wrote: >> Hi Xiangrong, >> you forgot to attach the patch, I think. > > Aha. You attached the wrong format. We want a plain text file, > i.e. not .odt, but .txt. The nice description in your .odt/.pdf > belongs in a bug report in http://bugs.winehq.org. > (And, as somebody mentioned, there may be related bugs already, > e.g. http://bugs.winehq.org/show_bug.cgi?id=4065 ) > > If you don't want to use "git diff" to generate the patch, use 'diff -u'. See > http://kegel.com/academy/opensource.html#patches > > Good luck, and welcome to Wine development! > - Dan >

Dec. 3, 2008

Re: Wine t-shirts?

by Ismael Barros²

Hum, that would be cool, I'll ask the boss but it's probably in. Does anyone have a higher resolution version? On Wed, Dec 3, 2008 at 4:29 PM, Steven Edwards <sedwards(a)bordeauxgroup.com> wrote: > On Wed, Dec 3, 2008 at 9:50 AM, Ismael Barros² <razielmine(a)gmail.com> wrote: >> I already asked julliard about permissions and donations (winehq is >> getting 3€ for each sold T-shirt), and now I should determine the >> T-shirt design itself. We'll probably start off with the classical >> wine logo, but we're not sure about the composition, any ideas? The >> website logo looks fine (without the shades, we're limited to 4 >> colours), but the "hq" is probably unnecessary for a T-shirt. > > +1 on the teeshirts if you can use the drunk Penguin on some of them > now that CodeWeavers is not using it for products. > > http://www.ixsoft.de/software/products/CWTSHIRTDP-L.html > > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo >

Dec. 3, 2008

Re: patch for gdi32

by Dan Kegel

On Wed, Dec 3, 2008 at 1:24 PM, Dan Kegel <dank(a)kegel.com> wrote: > Hi Xiangrong, > you forgot to attach the patch, I think. Aha. You attached the wrong format. We want a plain text file, i.e. not .odt, but .txt. The nice description in your .odt/.pdf belongs in a bug report in http://bugs.winehq.org. (And, as somebody mentioned, there may be related bugs already, e.g. http://bugs.winehq.org/show_bug.cgi?id=4065 ) If you don't want to use "git diff" to generate the patch, use 'diff -u'. See http://kegel.com/academy/opensource.html#patches Good luck, and welcome to Wine development! - Dan

Dec. 3, 2008

Re: patch for gdi32

by Henri Verbeet

Isn't this the same issue a bug 4065? (http://bugs.winehq.org/show_bug.cgi?id=4065)

Dec. 3, 2008

Re: Mono integration to Wine

by Scott Ritchie

Kornél Pál wrote: > Hi, > > I would like to receive comments on mixed-mode assembly support of Mono > on Wine and if there are people willing to update the Loader to call > _CorValidateImage, _CorExeMain (real entry point is not called for EXEs) > and _CorImageUnloading for managed images. > What is the current status of running a mixed-mode assembly app with Wine after doing something like winetricks mono2? I'm very interested in this question, especially in finding a good sample application out there. Thanks, Scott Ritchie

Dec. 3, 2008

Re: [2/2] gdiplus: fix a warning in GdipMultiplyTextureTransform

by Henri Verbeet

2008/12/3 Nikolay Sivov <bunglehead(a)gmail.com>: > Our prototypes should match MS', shouldn't they?. In this case I don't see > another way to silent this warning > which means nothing (you've already named the reason why). Up to a point. Personally I'd say the PSDK headers are broken here since they're inconsistent with themselves.

Dec. 3, 2008

Re: [2/2] gdiplus: fix a warning in GdipMultiplyTextureTransform

by Nikolay Sivov

Henri Verbeet wrote: > 2008/12/3 Nikolay Sivov <bunglehead(a)gmail.com>: > >> - return GdipMultiplyMatrix(brush->transform, matrix, order); >> + return GdipMultiplyMatrix(brush->transform, (GpMatrix*)matrix, order); >> > > I don't think casting const away makes it much better. Considering > what the function does, and the fact that the matrix *is* const in the > prototype for Matrix::Multiply(), I'd say it would be better to just > change the prototype for GdipMultiplyMatrix. MS doesn't seem to care a > whole lot about their plain C interfaces these days. > Our prototypes should match MS', shouldn't they?. In this case I don't see another way to silent this warning which means nothing (you've already named the reason why). > Slightly OT, the code in matrix_multiply() isn't quite the most > efficient way to multiply two 2x3 matrices, although if you're lucky > the compiler will unroll the loop for you and fold the constants. > Of course you're right here.

Dec. 3, 2008

IServiceProvider::QueryService tests

by Konstantin Kondratyuk

In dlls/mshtml/tests/htmldoc.c there is a comment: /* * Services used by HTMLDocument: * * IOleUndoManager * IInternetSecurityManager * ITargetFrame * {D5F78C80-5252-11CF-90FA-00AA0042106E} * HTMLFrameBase * IShellObject * {3050F312-98B5-11CF-BB82-00AA00BDCE0B} * {53A2D5B1-D2FC-11D0-84E0-006097C9987D} * {AD7F6C62-F6BD-11D2-959B-006097C553C8} * DefView (?) * {6D12FE80-7911-11CF-9534-0000C05BAE0B} * IElementBehaviorFactory * {3050F429-98B5-11CF-BB82-00AA00BDCE0B} * STopLevelBrowser * IHTMLWindow2 * IInternetProtocol * IWebBrowserApp * UrlHostory * IHTMLEditHost * IHlinkFrame */ It is confirmed by tests? I have not found. It seems to me, also there should be IHTMLEditServices interface support. How it is correct to add the test on IServiceProvider::QueryService? Thanks. -- Best regards, Konstantin Kondratyuk.

Dec. 3, 2008

Re: Alexandre Julliard : ole32: Register interfaces through dlldata. c as far as possible.

by Alexandre Julliard

"Rob Shearman" <robertshearman(a)gmail.com> writes: > 2008/12/3 Alexandre Julliard <julliard(a)winehq.org>: >> /* from dlldata.c */ >> +extern HINSTANCE hProxyDll DECLSPEC_HIDDEN; >> +extern BOOL WINAPI OLE32_DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID fImpLoad) DECLSPEC_HIDDEN; > > Why declare OLE32_DllMain when it isn't used? No reason, I just declared all the functions that could be useful, but DllMain turned out to be not so useful in the end. -- Alexandre Julliard julliard(a)winehq.org

Dec. 3, 2008

Re: [2/2] gdiplus: fix a warning in GdipMultiplyTextureTransform

by Henri Verbeet

2008/12/3 Nikolay Sivov <bunglehead(a)gmail.com>: > - return GdipMultiplyMatrix(brush->transform, matrix, order); > + return GdipMultiplyMatrix(brush->transform, (GpMatrix*)matrix, order); I don't think casting const away makes it much better. Considering what the function does, and the fact that the matrix *is* const in the prototype for Matrix::Multiply(), I'd say it would be better to just change the prototype for GdipMultiplyMatrix. MS doesn't seem to care a whole lot about their plain C interfaces these days. Slightly OT, the code in matrix_multiply() isn't quite the most efficient way to multiply two 2x3 matrices, although if you're lucky the compiler will unroll the loop for you and fold the constants.

Dec. 3, 2008

Re: Wine t-shirts?

by Steven Edwards

On Wed, Dec 3, 2008 at 9:50 AM, Ismael Barros² <razielmine(a)gmail.com> wrote: > I already asked julliard about permissions and donations (winehq is > getting 3€ for each sold T-shirt), and now I should determine the > T-shirt design itself. We'll probably start off with the classical > wine logo, but we're not sure about the composition, any ideas? The > website logo looks fine (without the shades, we're limited to 4 > colours), but the "hq" is probably unnecessary for a T-shirt. +1 on the teeshirts if you can use the drunk Penguin on some of them now that CodeWeavers is not using it for products. http://www.ixsoft.de/software/products/CWTSHIRTDP-L.html -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Dec. 3, 2008

Re: Wine t-shirts?

by Ismael Barros²

On Thu, May 8, 2008 at 10:32 PM, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > 2008/5/8 Maarten Lankhorst <m.b.lankhorst(a)gmail.com>: >> 2008/5/8 Jon Parshall <jparshall(a)codeweavers.com>: >>> I've messed around with Wine Bottles for our installer artwork, and I have this version that I could gussy up for the shirts if you'd like. >> I like the most left bottle, can you make one in the reddish color >> wine uses? And put the label I created on it and get it roughly in the >> same size? It would be perfect for the t-shirt. > Uncorked, since wine will be released. :D > Hi all I'm setting up a T-shirt store specialized in free software, www.freewear.org (work still in progress, but if everything goes well it should be running in one or two weeks), and obviously want Wine T-shirts in :) I already asked julliard about permissions and donations (winehq is getting 3€ for each sold T-shirt), and now I should determine the T-shirt design itself. We'll probably start off with the classical wine logo, but we're not sure about the composition, any ideas? The website logo looks fine (without the shades, we're limited to 4 colours), but the "hq" is probably unnecessary for a T-shirt. Anyway, if you guys want come up with a nicer design/logo, or want to order T-shirts for some Wine/FOSS event, we're open for business. Cheers Ismael Barros

Dec. 3, 2008

Re: Alexandre Julliard : ole32: Register interfaces through dlldata. c as far as possible.

by Rob Shearman

2008/12/3 Alexandre Julliard <julliard(a)winehq.org>: > /* from dlldata.c */ > +extern HINSTANCE hProxyDll DECLSPEC_HIDDEN; > +extern BOOL WINAPI OLE32_DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID fImpLoad) DECLSPEC_HIDDEN; Why declare OLE32_DllMain when it isn't used? > extern HRESULT WINAPI OLE32_DllGetClassObject(REFCLSID rclsid, REFIID iid,LPVOID *ppv) DECLSPEC_HIDDEN; > +extern HRESULT WINAPI OLE32_DllRegisterServer(void) DECLSPEC_HIDDEN; > +extern HRESULT WINAPI OLE32_DllUnregisterServer(void) DECLSPEC_HIDDEN; -- Rob Shearman

Dec. 3, 2008

Re: cryptdlg: Implement FormatVerisignExtension (resend)

by Alexandre Julliard

"Juan Lang" <juan.lang(a)gmail.com> writes: > Aside from the size, is there anything wrong with this one? You are still wasting lots of space by storing copies of string resources. There's no need to do that. -- Alexandre Julliard julliard(a)winehq.org

Dec. 3, 2008

Re: [4/5] wined3d: Use a bitmask to store which bool and int constants are set.

by Alexandre Julliard

"Henri Verbeet" <hverbeet(a)gmail.com> writes: > 2008/12/3 Juan Lang <juan.lang(a)gmail.com>: >>> Why is this a good thing - this just artificially caps your constants at >>> 32. If I remember correctly I had to change shaders to do the exact >>> opposite change, because newer versions introduced more than 32 constants. >> >> I agree with you, this is a questionable change. The benefit in >> reduced data results in a gain of code size and runtime cost. >> --Juan >> > Perhaps setting constants becomes slightly more expensive this way, > but I'm not convinced it's very significant. The more performance > critical code that applies the constants becomes significantly cheaper > though. I expect most operations will become faster, because the data is more likely to be kept in cache and in registers. It could probably be made even more efficient by getting rid of most of the remaining loops. I think it's a very reasonable change, using array of BOOLs is really wasteful. -- Alexandre Julliard julliard(a)winehq.org

Dec. 3, 2008

Re: [4/5] wined3d: Use a bitmask to store which bool and int constants are set.

by Henri Verbeet

2008/12/3 Juan Lang <juan.lang(a)gmail.com>: >> Why is this a good thing - this just artificially caps your constants at >> 32. If I remember correctly I had to change shaders to do the exact >> opposite change, because newer versions introduced more than 32 constants. > > I agree with you, this is a questionable change. The benefit in > reduced data results in a gain of code size and runtime cost. > --Juan > Perhaps setting constants becomes slightly more expensive this way, but I'm not convinced it's very significant. The more performance critical code that applies the constants becomes significantly cheaper though.

Dec. 3, 2008

Re: [4/5] wined3d: Use a bitmask to store which bool and int constants are set.

by Henri Verbeet

2008/12/3 Ivan Gyurdiev <ivg231(a)gmail.com>: >> Re: [4/5] wined3d: Use a bitmask to store which bool and int constants >> are set. > > Why is this a good thing - this just artificially caps your constants at 32. > If I remember correctly I had to change shaders to do the exact opposite > change, because newer versions introduced more than 32 constants. > > Ivan > We could always extend the number of possible constants by using an array. However, when we need more constants we'll probably need a scheme more like what's used for float constants anyway. The reduced memory usage is significant, not so much because we can't spare the memory, but because it allows the compiler to just keep the entire thing in a register. Perhaps even more importantly, when an application starts using constants from zero and goes up from there (which is not an unreasonable thing to do), we only have to go through the loop the amount of times as there are constants set. If the application doesn't use int or bool constants at all, we don't have to go through the loop at all either.

Dec. 3, 2008

Re: [4/5] wined3d: Use a bitmask to store which bool and int constants are set.

by Juan Lang

> Why is this a good thing - this just artificially caps your constants at > 32. If I remember correctly I had to change shaders to do the exact > opposite change, because newer versions introduced more than 32 constants. I agree with you, this is a questionable change. The benefit in reduced data results in a gain of code size and runtime cost. --Juan

Dec. 3, 2008

Re: [4/5] wined3d: Use a bitmask to store which bool and int constants are set.

by Ivan Gyurdiev

> Re: [4/5] wined3d: Use a bitmask to store which bool and int constants are set. Why is this a good thing - this just artificially caps your constants at 32. If I remember correctly I had to change shaders to do the exact opposite change, because newer versions introduced more than 32 constants. Ivan

Dec. 3, 2008

RE: Coverity Telco coming up

by ricardo filipe

even if there are admins the information about them and how to apply is well hidden and not easy to join :) so it's a good subject to bring...> Date: Tue, 2 Dec 2008 15:54:39 -0600> From: austinenglish(a)gmail.com> To: kai.blin(a)gmail.com> Subject: Re: Coverity Telco coming up> CC: wine-devel(a)winehq.org> > On Tue, Dec 2, 2008 at 11:58 AM, Kai Blin <kai.blin(a)gmail.com> wrote:> > Hi folks,> >> > Coverity is hosting a telco tomorrow about some new technology they're going> > to roll out to projects. I'm planning to attend, and would like to bring up> > any issues we're currently having in the Q&A session.> >> > Issues I'm currently seeing with our Coverity experience:> > - Adding new developers to the access list is painfully slow> > To add new developers, don't we have project admins that are notified> on request to approve the developers? Couldn't we just add more> admins?> > To list as well.> > --> -Austin> > _________________________________________________________________ Cansado de espaço para só 50 fotos? Conheça o Spaces, o site de relacionamentos com até 6,000 fotos! http://www.amigosdomessenger.com.br

Dec. 2, 2008

Re: Coverity Telco coming up

by Austin English

On Tue, Dec 2, 2008 at 11:58 AM, Kai Blin <kai.blin(a)gmail.com> wrote: > Hi folks, > > Coverity is hosting a telco tomorrow about some new technology they're going > to roll out to projects. I'm planning to attend, and would like to bring up > any issues we're currently having in the Q&A session. > > Issues I'm currently seeing with our Coverity experience: > - Adding new developers to the access list is painfully slow To add new developers, don't we have project admins that are notified on request to approve the developers? Couldn't we just add more admins? To list as well. -- -Austin

Dec. 2, 2008

Re: Coverity Telco coming up

by Paul Vriens

Marcus Meissner wrote: > On Tue, Dec 02, 2008 at 06:58:37PM +0100, Kai Blin wrote: >> Hi folks, >> >> Coverity is hosting a telco tomorrow about some new technology they're going >> to roll out to projects. I'm planning to attend, and would like to bring up >> any issues we're currently having in the Q&A session. >> >> Issues I'm currently seeing with our Coverity experience: >> - Adding new developers to the access list is painfully slow >> - Builds are pretty outdated (They seem to be working on this) >> >> Anything else? > > - rung1.html page is still outdated. > - More regular Builds (not just every 2 months or so) would be helpful > - Notification Mail(s) and/or RSS feed when new builds appear. > > Ciao, Marcus > > > Well actually: == For projects that have never had regular builds, we have a new solution to get rung 1 projects updated builds as often as you want them. We are launching a new program that allows you to submit new builds for analysis as often as you want. Please read http://scan.coverity.com/self-build/ for more information, and send an email to scan-admin(a)coverity.com if you wish to sign up. == Doesn't help in updating the rung1.html page though ;) -- Cheers, Paul.

Dec. 2, 2008

Re: Coverity Telco coming up

by Marcus Meissner

On Tue, Dec 02, 2008 at 06:58:37PM +0100, Kai Blin wrote: > Hi folks, > > Coverity is hosting a telco tomorrow about some new technology they're going > to roll out to projects. I'm planning to attend, and would like to bring up > any issues we're currently having in the Q&A session. > > Issues I'm currently seeing with our Coverity experience: > - Adding new developers to the access list is painfully slow > - Builds are pretty outdated (They seem to be working on this) > > Anything else? - rung1.html page is still outdated. - More regular Builds (not just every 2 months or so) would be helpful - Notification Mail(s) and/or RSS feed when new builds appear. Ciao, Marcus

Dec. 2, 2008

Coverity Telco coming up

by Kai Blin

Hi folks, Coverity is hosting a telco tomorrow about some new technology they're going to roll out to projects. I'm planning to attend, and would like to bring up any issues we're currently having in the Q&A session. Issues I'm currently seeing with our Coverity experience: - Adding new developers to the access list is painfully slow - Builds are pretty outdated (They seem to be working on this) Anything else? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Dec. 2, 2008

Re: today's git does not compile with yesterday's new gcc -- regression test results

by Susan Cragin

>>> I did the regression test. But how legitimate are the results if the problem is the new gcc that I downloaded recently, and not wine? This problem was an Ubuntu linux bug, and has been fixed in headers for kernel 2.6.28-2.2. See Ubuntu bug 303711. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/303711

Dec. 2, 2008

Patchwatcher status

by Dan Kegel

Patchwatcher is down for the moment - I mistakenly tried using proprietary nvidia drivers, forgetting that my nvidia card is too old to be supported, and don't have time this morning to recover. I'll fix it tonight.

Dec. 2, 2008

Re: Status of 64 bit Wine

by Francois Gouget

On Tue, 2 Dec 2008, Michael Ost wrote: [...] > Thanks for the link. It says AMD64 --- I hope this doesn't sound stupid > but will that work on 64 bit Intels too? Yes. It's called AMD64 in many places because the 64bit extension of the x86 ISA was made by AMD and Intel played catch up later. So for instance on my Core 2 Quad I use the amd64 Linux kernel (2.6.26-1-amd64). [...] > "Pacman" is a windows 64 binary, with the windows ABI? And that required > your local gcc patch to work, right? Does --enable-win64 alter gcc so it > builds code that can deal with the windows 64 bit conventions? That's also the way I understand it. > Knowing that you got past that would be good news, because this sounded > like the biggest, scariest part when I looked into it a while back. Yep. However once we're past this stage there is still a lot of work. Not scary because it's hard but because of the size of it, fixing types all over the place: * long -> LONG when related to the Windows API * DWORD -> DWORD_PTR when used to pass around pointers * spec file fixes: long -> ptr Then there will be the harder issue of getting 64bit and 32bit binaries to play nice together: a 64bit executable should be able to start a 32bit one and vice versa, and both should talk to the same Wine server. But yes. With the gcc issue fixed the future looks much brighter. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds

Dec. 2, 2008

Re: Status of 64 bit Wine

by Michael Ost

Maarten Lankhorst wrote: > Hi Michael, > > Michael Ost schreef: >> Hi list, >> >> Every once in a while my boss asks me about 64 bit wine. And today was >> the day. So what's the status? >> >> From my understanding there are two parts to the question. First, is >> anyone using a 64 bit build of Wine? How successfully? Does it pass >> the internal wine tests? >> > Been playing around with it a little bit for fun and profit. If you look > at the Wine64 wiki page you see the current state. Thanks for the link. It says AMD64 --- I hope this doesn't sound stupid but will that work on 64 bit Intels too? Is this an afterhours project for you, or something more serious? >> And second, is there any progress on loading 64 bit windows binaries >> in Wine? My understanding was that changes were needed to gcc to make >> that happen. Is that correct? Is there any progress on that score? >> > The changes are mostly in, there is a bug in gcc with handling it, but I > got the patch for it so locally it works. Basic programs winelib > programs like winecfg work. > The most succesful binary I ran was a pacman for win64, but the only > thing it does is throw up a messagebox 'unable to load resources'. "Pacman" is a windows 64 binary, with the windows ABI? And that required your local gcc patch to work, right? Does --enable-win64 alter gcc so it builds code that can deal with the windows 64 bit conventions? Knowing that you got past that would be good news, because this sounded like the biggest, scariest part when I looked into it a while back. > Getting it in an AJ approved form is a bit harder, but I'm working on it. Right-o! Glad to hear you are at it. Thanks! ... mo

Dec. 2, 2008

Re: Status of 64 bit Wine

by Maarten Lankhorst

Hi Michael, Michael Ost schreef: > Hi list, > > Every once in a while my boss asks me about 64 bit wine. And today was > the day. So what's the status? > > From my understanding there are two parts to the question. First, is > anyone using a 64 bit build of Wine? How successfully? Does it pass the > internal wine tests? > Been playing around with it a little bit for fun and profit. If you look at the Wine64 wiki page you see the current state. > And second, is there any progress on loading 64 bit windows binaries in > Wine? My understanding was that changes were needed to gcc to make that > happen. Is that correct? Is there any progress on that score? > The changes are mostly in, there is a bug in gcc with handling it, but I got the patch for it so locally it works. Basic programs winelib programs like winecfg work. The most succesful binary I ran was a pacman for win64, but the only thing it does is throw up a messagebox 'unable to load resources'. Getting it in an AJ approved form is a bit harder, but I'm working on it. Cheers, Maarten.

Dec. 2, 2008

Re: wineoss.drv: Eliminate all 64-bits warnings

by Alexandre Julliard

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > sizeof is defined as int on 32-bits, and long on 64-bits. To keep this > working I'm casting all sizeofs to longs Please don't add casts, simply get rid of sizeof in traces like we did in the rest of the code. And please do it as a separate patch. -- Alexandre Julliard julliard(a)winehq.org

Dec. 2, 2008

Re: wineoss.drv: Eliminate all 64-bits warnings

by Kai Blin

On Tuesday 02 December 2008 10:28:04 Austin English wrote: > Minor, but you've got a few extraneous whitespace changes: Those are on otherwise empty lines, I don't see how that'd matter. The reason people don't like formatting-only patches is that it breaks "git blame" history. As git blame supports an "ignore whitespace-only changes" flag, I don't see why these whitespace changes are bad. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Dec. 2, 2008

Re: wineoss.drv: Eliminate all 64-bits warnings

by Austin English

On Tue, Dec 2, 2008 at 3:19 AM, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > sizeof is defined as int on 32-bits, and long on 64-bits. To keep this > working I'm casting all sizeofs to longs > --- > Minor, but you've got a few extraneous whitespace changes: diff --git a/dlls/wineoss.drv/audio.c b/dlls/wineoss.drv/audio.c index 460c1f5..1828320 100644 --- a/dlls/wineoss.drv/audio.c +++ b/dlls/wineoss.drv/audio.c @@ -1923,7 +1923,6 @@ static DWORD CALLBACK wodPlayer(LPVOID pmt) dwNextFeedTime = dwNextNotifyTime = INFINITE; } } - return 0; } diff --git a/dlls/wineoss.drv/mmaux.c b/dlls/wineoss.drv/mmaux.c index b48ea6b..44e22b7 100644 --- a/dlls/wineoss.drv/mmaux.c +++ b/dlls/wineoss.drv/mmaux.c @@ -219,10 +219,10 @@ static DWORD AUX_SetVolume(WORD wDevID, DWORD dwParam) /************************************************************************** * auxMessage (WINEOSS.2) */ -DWORD WINAPI OSS_auxMessage(UINT wDevID, UINT wMsg, DWORD dwUser, - DWORD dwParam1, DWORD dwParam2) +DWORD WINAPI OSS_auxMessage(UINT wDevID, UINT wMsg, DWORD_PTR dwUser, + DWORD_PTR dwParam1, DWORD_PTR dwParam2) { - TRACE("(%04X, %04X, %08X, %08X, %08X);\n", + TRACE("(%04X, %04X, %08lX, %08lX, %08lX);\n", wDevID, wMsg, dwUser, dwParam1, dwParam2); #ifdef HAVE_OSS @@ -250,3 +250,4 @@ DWORD WINAPI OSS_auxMessage(UINT wDevID, UINT wMsg, DWORD dwUser, return MMSYSERR_NOTENABLED; #endif } + -- -Austin

Dec. 2, 2008

Status of 64 bit Wine

by Michael Ost

Hi list, Every once in a while my boss asks me about 64 bit wine. And today was the day. So what's the status? From my understanding there are two parts to the question. First, is anyone using a 64 bit build of Wine? How successfully? Does it pass the internal wine tests? And second, is there any progress on loading 64 bit windows binaries in Wine? My understanding was that changes were needed to gcc to make that happen. Is that correct? Is there any progress on that score? And please correct any misunderstandings I may have. Thanks... mo

Dec. 2, 2008

Re: winetest.exe now available on test.winehq.org

by Paul Millar

On Saturday 29 November 2008 15:40:33 Paul Vriens wrote: > This also means that Paul Millars winetest is no longer available. Yup, this is true. After providing winetest.exe for (I think) a little over 4 years, quisquiliae is falling silent and WineHQ is picking up the baton for winetest.exe. > I'd like to thank Paul for all the hard work he did with keeping up that > site and providing us for years with a cross compiled version of winetest. I > also like to thank the people that provided the necessary MinGW patches in > the past to get that winetest compiled again. I'd like to add my vote of thanks to the people who have helped out behind the scenes, providing useful suggestions or sending in patches for MinGW so we can keep winetest.exe rolling out the door (in alphabetical order) Alexandre Julliard, John Klehm, Kevin Koltzau, Saulius Krasuckas, Stefan Leichter, Hans Leidekker, Mike McCormack, Juan Melgarejo, Detlef Riekenberg, Sebastian Schauenburg, Brian Vincent, and Paul Vriens. (and anyone else I've inadvertently forgotten) My thanks to you all! Cheers, Paul.

Dec. 1, 2008

Re: [08/12] msxml3: Add an internal IUnknown object for xmlnode

by Michael Karcher

Am Samstag, den 29.11.2008, 10:52 +0100 schrieb Michael Karcher: > This makes the xmlnode structures kind-of aggregatable COM objects. > The explanation of the new reference management is in the rather verbose > comment at the top of the new node_unk.c file. For reference, the comment explaining the proposed reference counting scheme is at the end of this mail. This patch got the comment on IRC: "julliard: mkarcher: the comment explaining that COM rules are not followed rings an alarm bell". So, let me first explain the problem I'm trying to solve. In libxml2, the application is responsible for lifetime management, whereas in msxml3, lifetime management is done by reference counting. The XML documents are highly cyclic data structures: There is one real root, called the "document node". In XML documents, it has a single child, the so called "document element". The document element is the root of the so called DOM tree. Every node in the DOM tree has a get_parent and a get_ownerDocument method. Also, each non-leaf node has a get_children method. This is opposed to the standard container-containee model, where the container owns a reference on the containees, but the containees do not know about being in a container. Reference counting in that case is straightforward. Currently, msxml3 implements reference counting in the following way: As soon as an interface object for any DOM node is requested, the reference count of the document is increased by one, and as soon as the interface looses its final reference, the document's reference count is decremented. If the document's reference count reaches zero, no pointer to any object in the DOM tree is out anymore, so the document can be deleted. This seems to work nicely, but has two major catches, that made me do this rewrite of the reference management: a) msxml3 has methods to splice subtrees. b) msxml3 can create nodes nodes owned by a document, that are not in the DOM tree Point a) means that the document a node belongs to is not constant over the lifetime of the node. As in the current model, the node needs to take a reference on its current document, reference counts have to be adjusted. The xmldoc_release and xmldoc_add_ref function calls in removeChild, insertBefore (and alike) seem to take care of this. But as the bullet already said, it is not just splicing the node passed into the splicing function, but a whole subtree! That means that all interface objects to child nodes have to move their reference to the new document. Alas, there is *no* *way* in current wine to find all interface objects for a given node, so there is no way to tell these interface objects to move their references. As there is also no way just to know *how* *many* interface objects are out for a given node, let alone for a whole subtree, reference-correct moving is impossible. Point b) means that just freeing the nodes in the DOM tree on document destruction does not get all the nodes belonging to the document. This is taken care of in the orphan list. The (benign) problem with the orphan list approach is that the so called orphan subtrees, i.e. subtrees that are not part of the document get not freed as soon as no references to the subtree are out anymore, but not until there are no references to any node that is associated with the document. Think put_documentElement, that replaces the whole DOM tree, making the old tree orphan. This might be quite a lot of wasted memory. Now, lets look at what can be done. To solve the important issue in part a, there are two possible approaches: a1) Move to a concept that doesn't need the missing information a2) Make the missing information available. My patch went the route of a1), but I think a2) is also possible: We might count reference to a node in the _private element of the node, so the number of references to a node is at hand. If a subtree is spliced, we would have to traverse the whole subtree to collect the number of references in the subtree to move from the old document to the new document. Another a2) approach is to count the number of references to the whole subtree inside the _private element. This makes obtaining the number of references to the subtree an O(1) operation, but updating the interface object count of one node means the interface count of all parents has to be updated, too. While this is not as expensive as a subtree traversal, updating interface object counts is a very common operation that ought to be O(1) too, and not O(depth). To solve the issue of b), the same things are imaginable. If a node gets orphan, check whether the whole subtree is orphan, and nuke it if it is. If it is not, add it to the orphan list. If later the last reference into that subtree is freed, one has to detect that the subtree is orphan. One could do that by checking on every interface release whether the subtree is now orphan. As this is a "is there any reference to the subtree" question, the first a2 approach is out immediately. The second one can do. The up-traversal will stop either at the document element or at the root of the orphan subtree, and the information whether there is any reference left is immediately at hand. Now, there is the a1 thing left. Throw the old concept of "everyone refs the document" away (which is only band-aided by the orphan list and the expensive sub-tree counts or up-traversals, IMHO) and try to find a clean way to get what we need. This is what this patch is about. The first choice about reference counting in cyclic structures is the choice of reference direction. The choice that the parent node owns its child nodes is tempting, as it seems to resemble the simple container-owns-containee concept. But it breaks down as soon as there are references to the child nodes out, and the parent node looses its last reference, as the parent node would get freed in that case. It would be possible for a parent node to wait for all children to be released before it gets freed itself. But this again needs non-local information. A node has to stay alive as long as *any* descendant of that node, however deep in the hierarchy it might be, is alive. On the other hand, if the explicit references are from child to parent, the crucial operation is no longer to find out whether any child node is still in use (we do have that info in the node's reference count now), the difficult operation is now to find out whether the parent is still in use. This operation is unneeded however, as freeing is delegated to the root node of the subtrees, so a node doesn't care whether there might be new reference obtained to it by use of its parent node, as it can be sure, the parent won't destroy it until it is sure that references can no longer be obtained through it. This finally leads to the solution I implemented. (I won't explain it here again in detail, see below the PS for the explanation of that system) Now, my question is how to proceed. The patches I posted seem to be working fine and seem to clean up the reference management, for example, they do away with the orphan list I introduced but still looks like a hack to me. On the other hand, there are concerns that the new reference management does not follow COM rules (although I couldn't find definitive COM rules for cyclic structures, just the usual info that reference cycles have to be avoided in some way). As I really want problem a) to get fixed, I ask for advice. Thanks for reading this quite long mail. I would be grateful for suggestions. Regards, Michael Karcher PS: This mail does not cover the second, independent topic that we need an IUnknown pointer with node lifetime stability. A basis for that is also introduced in the new reference counting system. While lifetime IUnknown and reference counting are two different things, it looked like a good idea to have both things solved at once. To make use of the provided lifetime IUnknown, the upper layer classes like XMLDOMNode, XMLDOMDocument and the like have to be adjusted too, but I postponed that part of work. The node_unk object serves two purposes: a) it provides a lifetime stable IUnknown for an XML node b) it manages references each xmlNode can carry a node_unk reference in its _private member. If there is an interface pointer to the node floating around, the node does have an associated node_unk object which is created and destroyed lazily. Lazy allocation means: node_unk objects are created when first needed, not at XML document creation time. The main advantage of it is that one does not need to manually create the node_unk objects at each place a xmlNode could be created. Lazy destruction means that the node_unk object is *not* freed as soon as its reference count drops down to zero, because purpose a) wouldn't be fulfilled that way. A node_unk with no references are said to be in "standby mode". Reference counting is done this way: 1) Parents do *not* hold references on their children 2a) If the child is not in standby mode, a reference is held in the parent. 2b) If there is no parent, a reference on the document is held instead. 2c) The document node is exempt from rule 2b), it doesn't hold a reference. Rule 1 is obvious to prevent cyclic references. As children do not destroy themselves on their own, there is no danger of stale child pointers. Each node needs to indirectly reference its document, as strings like node names can be stored in per-document dictionaries in libxml2. For nodes being part of the document tree, this is accomplished by each node referencing its parent via 2a, up to the root element, whose parent is the document itself. There is a complication: A document is fact is not a tree, but a forest! The forest has one main tree, its root being the "document element", but can have many further trees consisting of nodes created by createElement, createText and alike functions, or by removing some subtrees from the document tree, for example by removeChild or replaceChild. These trees are called orphan trees, as they don't have a parent, opposed to the "document element" whose parent is the document itself. The root node of the orphan tree (having no parent) is holding a reference on the document by rule 2b. As there is no way to get a reference to a node in an orphan tree except for having a reference to another node in the same orphan tree, orphan trees can be destroyed as soon as its root node enters standby mode. This has the consequence that the document doesn't need to know about the orphan trees itself, it just needs to know whether there are any of them to prevent early destruction. This is implemented by the reference from rule 2b. On the other hand, one can not free the main document tree as long as any orphan tree is alive, as each orphan tree provides a reference to the document which in turn provides a reference to its main tree. Finally, all nodes you can access from the document node are members of the main document tree, which is kept alive as subtree of the document node, so the document node does not have to hold the reference on anything. So, the implementation works like this: As soon, as the windows program asks for an interface pointer into some XML document (we don't care about the source here), the node is equipped with its node_unk structure, and so get all its parents. While it would be possible to delay the allocation to the AddRef call, the AddRef call has no way to indicate failure in the out-of-memory case. If the application asks for further interface pointers into the same document, chains of node_unk objects are created until a branch is met that already has them; at that point, the reference count is just increased by one on that level without further up-propagation. The document itself (the parent of the document element) keeps out of standby mode until all interface pointers to the document vanished. At that point, the document frees itself and all children. Root node of orphan trees work the same way. The most interesting points are not covered yet: Subtrees can be spliced from one document into another one, like with IXMLDOMNode::appendChild or IXMLDOMNode::replaceChild. In that case, the simple old approach where each IXMLDOMFoo interface held a reference on its document breaks down, as it is unknown how many IXMLDOMFoo pointers are out there that get moved to a different document behind their back. With this model, it is quite simple. A tree that gets spliced out has either zero or one reference on its direct parent, depending on whether it is in standby mode or not. A tree that gets spliced in takes exactly one reference if it is not in standby mode. As an added bonus, we get orphan tracking and early freeing of orphans (a feature we didn't have in the old model) for free.

Dec. 1, 2008

Re: Bugzilla's down again

by Lei Zhang

On Wed, Nov 26, 2008 at 2:15 PM, Austin English <austinenglish(a)gmail.com> wrote: > On Wed, Nov 26, 2008 at 4:12 PM, Jeremy Newman <jnewman(a)codeweavers.com> wrote: >> mysqld didn't crash at least. This seems to be a temporary issue that >> cleared up when the server load came back down. >> >> I don't think the server has been down hardly at all? Where are you getting >> your "down so much" from? >> >> -Newman >> >> Austin English wrote: >>> >>> Different error than usual though: >>> >>> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> >>> <html><head> >>> <title>500 Internal Server Error</title> >>> </head><body> >>> <h1>Internal Server Error</h1> >>> <p>The server encountered an internal error or >>> misconfiguration and was unable to complete >>> your request.</p> >>> <p>Please contact the server administrator, >>> bugs-admin(a)winehq.org and inform them of the time the error occurred, >>> and anything you might have done that may have >>> caused the error.</p> >>> <p>More information about this error may be available >>> in the server error log.</p> >>> </body></html> >>> >>> Is there anything we can do to prevent it from going down so much? >>> >> > > Sorry if that came off as rash. It's been much better in the past few > months. But I was referring to the semi-frequent mysql crashes. I'm on > bugzilla a lot, so even if it's only down for a few minutes, I usually > catch it. > > -- > -Austin > > > I notice it from time to time as well. 95% of the time it works fine, but every so often, for about 30 minutes or so, I get an error 500 or a mysql error.

Dec. 1, 2008

Patchwatcher locked up?

by Michael Stefaniuc

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Dan, did the patchwatcher look up? The last patch it shows is from 30-Nov-2008 14:01. bye michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFJNCYg08alQ5mXm14RAnsPAJ44C2vVFmSnD5OknaoMGPkSuB+VFQCfbb6J PhbFmQ4U1nOrHIw5JycPWbc= =005q -----END PGP SIGNATURE-----

Dec. 1, 2008

Re: Did anyone have any trouble compiling wine today? Or was it just me ....

by Susan Cragin

>On Mon, Dec 1, 2008 at 9:06 AM, Susan Cragin <susancragin(a)earthlink.net> wrote: >>>>I don't know off hand then. I'd say run a regression test. As a guess, >>>>you might try removing: >>>>#ifdef HAVE_LINUX_SERIAL_H >>>>#include <linux/serial.h> >>>>#endif >>>> >>>>but that would just be a kludgy workaround. >>>> >>>>-- >>>>-Austin >>> >>>Will try both tomorrow. >>>Thanks. >> >> Austin: >> Did not see above section, but did see this, so removed it. >> #ifdef HAVE_LINUX_INPUT_H >> #include <linux/input.h> >> #endif >> Did not work. Got same error. :( > >Regression test? As Detleft said, it may be kernel related. > >-- >-Austin Found something similar to what Detlef found, so filed a Ubuntu bug against the kernel. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/303711 Also tried new kernel, 2.6.28-1-ub, but got same result. Susan

Dec. 1, 2008

Re: netapi32: Why my patch is ignored?

by Vitaly Perov

On Monday 01 December 2008 18:45:22 Alexandre Julliard wrote: > Vitaly Perov <vitperov(a)etersoft.ru> writes: > > + GetCurrentDirectoryA(MAX_PATH, tmpPath); > > + result = SetCurrentDirectoryW(path); > > + SetCurrentDirectoryA(tmpPath); > > + if (!result) return ERROR_FILE_NOT_FOUND; > > This is not the right way to test if a directory exists. Thank you for your answer. I will fix it. -- Best wishes, Vitaly Perov Russia, Saint-Petersburg. www.etersoft.ru

Dec. 1, 2008