May 2009 - Wine-Devel - list.winehq.org

Re: DIB Engine : passing all tests

by James McKenzie

Steven Edwards wrote: > On Sun, May 24, 2009 at 9:23 PM, James McKenzie > <jjmckenzie51(a)earthlink.net> wrote: > >> Let me know how this goes. I'm interested in improvements that will >> help all *nixes, including MacOSX. >> > > I think I am using the latest patch, its dibeng_max.zip thats got the > 1-10 patches. > > There are some major graphical glitches, though it could be related to > me having Quartz Extreme and Quartz2d enabled on unsupported hardware. > It does seem much faster though. Sorry I don't have time right now to > do a complete report. I'll try to upload information to bugzilla in > the morning after I make my environment a little more sane. > > That's ugly. Did you attempt to type in something in the Document area? I don't have the time tonight to attempt to build and run the DIB stuff to see what it does to the games and other programs that I work with. Maybe, tomorrow afternoon after my bicycle ride. James McKenzie

May 25, 2009

Re: DIB Engine : passing all tests

by Steven Edwards

On Sun, May 24, 2009 at 9:23 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > Let me know how this goes. I'm interested in improvements that will > help all *nixes, including MacOSX. I think I am using the latest patch, its dibeng_max.zip thats got the 1-10 patches. There are some major graphical glitches, though it could be related to me having Quartz Extreme and Quartz2d enabled on unsupported hardware. It does seem much faster though. Sorry I don't have time right now to do a complete report. I'll try to upload information to bugzilla in the morning after I make my environment a little more sane. 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

May 25, 2009

Re: DIB Engine : passing all tests

by James McKenzie

Steven Edwards wrote: > On Sun, May 24, 2009 at 11:06 AM, Massimo Del Fedele <max(a)veneto.com> wrote: > >> André Hentschel ha scritto: >> No idea on what will happen with Mac or other unixes.... >> > > I am attempting a Mac build now. As with the rest of the discussion, > It would be nice if we could produce a PE version using something like > cygwin with X11 headers and the -mno-cygwin switch but I don't know if > this would really work. If did then it should work on everything. > Let me know how this goes. I'm interested in improvements that will help all *nixes, including MacOSX. James McKenzie

May 25, 2009

Re: DIB Engine : passing all tests

by Steven Edwards

On Sun, May 24, 2009 at 11:06 AM, Massimo Del Fedele <max(a)veneto.com> wrote: > André Hentschel ha scritto: > No idea on what will happen with Mac or other unixes.... I am attempting a Mac build now. As with the rest of the discussion, It would be nice if we could produce a PE version using something like cygwin with X11 headers and the -mno-cygwin switch but I don't know if this would really work. If did then it should work on everything. 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

May 25, 2009

PowerPC MacOSX work...

by Michael G Hughes

I have managed to get Wine compiling on a PowerMac G4, MacOSX 10.3.9, a while back... What I know so far... It does not work... Who'd a thunk it? Just trying to run winecfg gives me: fixme:seh:RTLCaptureContext not implimented on PowerPC fixme:seh:call_stack_handlers not implemented on PowerPC wine: Unhandled alignment at address 0x44010788 (thread 000d), starting debugger... err:process:__wine_kernel_init boot event wait timed out So... Some of my questions to from the people involved with chugging away at the PowerPC parts of the code... What are the known issues faced in getting the project to work on PowerPC? What critical pieces are known to be missing? What is the problem(s) with X11 on 10.3.9? How do I start testing parts of Wine on PowerPC? RTLCaptureContext... I started to impliment RTLCaptureContext... Looks like this involves adding code to winebuild in addition to RTLCaptureContext itself... Correct? Can RTLCaptureContext be implimented without mucking with the winebuild tool? Michael -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

May 24, 2009

Re: [comctl32] Test request

by Nikolay Sivov

Ge van Geldorp wrote: > Hi Nikolay, > > >> From: Nikolay Sivov [mailto:bunglehead(a)gmail.com] >> >> Ge van Geldorp wrote: >> >>>> From: Nikolay Sivov <bunglehead(a)gmail.com> >>>> >>>> I've just prepared some simple MRU tests and I need test them on various >>>> native platfoms - >>>> >>>> tested only on xp sp2 so this one could be skipped. >>>> >>>> Could somebody do it? >>>> >>> Your tests pass on my W2K, XP, W2K3, Vista and W2K8 machines, but I get >>> crashes which were not there before on NT4 Workstation and NT4 Server >>> > (both > >>> SP6). I haven't investigated further, I could probably determine the test >>> case that crashes if needed. >>> >> Thanks for testing, Ge. >> >> Yes, it will be nice if you tell me which tests crash. I'll comment them >> out then with some notes. >> > > Both the pEnumMRUList(NULL, 0, NULL, 0) and pEnumMRUListW(NULL, 0, NULL, 0) > calls in test_EnumMRUList() cause a crash. If I comment out these 2 tests > then the rest of the tests pass. > > Ge. > Ok. Thank you.

May 24, 2009

RE: [comctl32] Test request

by Ge van Geldorp

Hi Nikolay, >From: Nikolay Sivov [mailto:bunglehead(a)gmail.com] > >Ge van Geldorp wrote: >>> From: Nikolay Sivov <bunglehead(a)gmail.com> >>> >>> I've just prepared some simple MRU tests and I need test them on various >>> native platfoms - >>> >>> tested only on xp sp2 so this one could be skipped. >>> >>> Could somebody do it? >> >> Your tests pass on my W2K, XP, W2K3, Vista and W2K8 machines, but I get >> crashes which were not there before on NT4 Workstation and NT4 Server (both >> SP6). I haven't investigated further, I could probably determine the test >> case that crashes if needed. > >Thanks for testing, Ge. > >Yes, it will be nice if you tell me which tests crash. I'll comment them >out then with some notes. Both the pEnumMRUList(NULL, 0, NULL, 0) and pEnumMRUListW(NULL, 0, NULL, 0) calls in test_EnumMRUList() cause a crash. If I comment out these 2 tests then the rest of the tests pass. Ge.

May 24, 2009

Re: [comctl32] Test request

by Nikolay Sivov

Ge van Geldorp wrote: >> From: Nikolay Sivov <bunglehead(a)gmail.com> >> >> I've just prepared some simple MRU tests and I need test them on various >> > native platfoms - > >> tested only on xp sp2 so this one could be skipped. >> >> Could somebody do it? >> > > Your tests pass on my W2K, XP, W2K3, Vista and W2K8 machines, but I get > crashes which were not there before on NT4 Workstation and NT4 Server (both > SP6). I haven't investigated further, I could probably determine the test > case that crashes if needed. > > Ge. Thanks for testing, Ge. Yes, it will be nice if you tell me which tests crash. I'll comment them out then with some notes. Nikolay S.

May 24, 2009

RE: [comctl32] Test request

by Ge van Geldorp

> From: Nikolay Sivov <bunglehead(a)gmail.com> > > I've just prepared some simple MRU tests and I need test them on various native platfoms - > tested only on xp sp2 so this one could be skipped. > > Could somebody do it? Your tests pass on my W2K, XP, W2K3, Vista and W2K8 machines, but I get crashes which were not there before on NT4 Workstation and NT4 Server (both SP6). I haven't investigated further, I could probably determine the test case that crashes if needed. Ge.

May 24, 2009

Re: DXTn textures in D3DX9

by Mike Kaplinskiy

I believe mesa looks for libtxc_dxtn @ http://homepage.hispeed.ch/~rscheidegger/dri_experimental/s3tc_index.html and then enables full s3tc support. The library itself is tiny and in (ugly) C, so that is already good news. But as stated on the website, you cannot use the code due to legality. Maybe there would be a way to do on-demand loading as with mesa and output a warn/fixme if the library is not found? It seems like the approach would be similar to the way the font bytecode interpreter was handled (turn on if available). On a sidenote, I may not know what I'm talking about so feel free to completely disagree. Mike. On Sat, May 23, 2009 at 4:48 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > 2009/5/22 Tony Wasserka <tony.wasserka(a)freenet.de>: >> Hi everyone, >> I'm working on implementing D3DXLoadSurfaceFromFileInMemory right now, >> but I've got a problem. The function >> most convert a loaded surface's data to a user specified surface format >> (I did not yet find a way to do it elsehow, >> UpdateTexture and StretchRect are to limited for that task, suggestions >> welcome if I missed anything). >> Now, if the user specifies that D3DX9 needs to convert e.g. an R8G8B8 >> surface to DXT1 (or to save a surface to a >> DXTn compressed DDS file), I'm not sure wether I can implement that >> behavior; on #winehackers I was told that >> the (de)compression part is coverered by S3's patents, but the Gimp DDS >> plugin and this >> (http://mollyrocket.com/forums/viewtopic.php?t=392) seem to provide OSS >> solutions for it anways. >> So... Can anybody tell me for sure wether I may implement this code or not? >> > > What it comes down to is that I don't think we want to take that risk, > so essentially "No". > > >

May 24, 2009

Re: DIB Engine : passing all tests

by Ben Klein

2009/5/25 Massimo Del Fedele <max(a)veneto.com>: > André Hentschel ha scritto: >> >> I dont know anything about that, but may it be possible to compile your >> code to a standalone driver for seperate download? >> It would be great to just install a DIB-Driver for wine. >> Sorry if that was a stupid idea. >> > The idea is not stupid at all :-) > I was thinking to do it, but I don't know for how many > machines a separate compile would be needed. > I'm working on ubuntu64, and I tested just migrating the > 2 DLLs on an ubuntu32 and it do work, so I guess it should > work on most linuxes. > No idea on what will happen with Mac or other unixes.... To make this work and be as portable as possible, you'd need to produce pure win32 DLLs (not ELF/PE hybrid .dll.so files). You would then only need to distribute win32 and win64 variants, and not need to worry about all the different kernels/libc's Wine is capable of running on. :)

May 24, 2009

Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3

by Roderick Colenbrander

On Sun, May 24, 2009 at 2:49 AM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > Roderick Colenbrander wrote: >> >> Thanks, I used this to compile wine 1.1.21 for testing purposes this >> week. I had to update the scripts a bit (e.g. use newere versions of >> some libraries and tools because the old ones are offline). I can post >> a patch against the old script. Further don't ship the opengl hack >> anymore for new wine packages as you are aware it isn't needed for >> xquartz 2.3.3 anymore. Everyone should move to the latest xquartz. >> This might prevent some opengl bug reports which I have to close on >> bugzilla as well ;) >> >> > Can you provide the updates to the scripts? Since I am using Leopard, > the opengl fix is not needed anymore, but it may have to stay until > XQuartz 2.3.3 is backported for Tiger. > > James McKenzie > > Hi James, This is the script I used. It mainly consists of some new servers and updated version numbers because the original versions weren't available anymore (sure they are useally in some 'old' directory). Further I'm not building with the opengl patch. Roderick

May 24, 2009

Re: annoying pkg-config problem on 64 bit Ubuntu 8.10

by Austin English

On Sun, May 24, 2009 at 12:25 AM, Ben Klein <shacklein(a)gmail.com> wrote: > 2009/5/23 Austin English <austinenglish(a)gmail.com>: >> On Thu, May 21, 2009 at 5:24 PM, Joel Holdsworth >> <joel(a)airwebreathe.org.uk> wrote: >>> On Thu, 2009-05-21 at 22:18 +0200, Tijnema wrote: >>>> Haven't checked Jaunty yet to see if it's still busted. >>>> We may need to postprocess pkg-config's output to add the >>>> missing 32 >>>> in some cases. Not sure if it's worth it. >>>> >>> >>> On Jaunty I get >>> >>> $ pkg-config --libs dbus-1 >>> -L//lib -ldbus-1 >> >> I do as well, but './configure' and './configure --enable-win64' both work fine. > > Does it tell you you're missing dbus or HAL stuff when you're not? > No, configure shows all dependencies as satisfied, for 32 and 64 bit. -- -Austin

May 24, 2009

Re: [PATCH 01/10] msi/tests: Add tests for binary OBJECTS.

by Austin English

On Sun, May 24, 2009 at 11:51 AM, Hib Eris <hib(a)hiberis.nl> wrote: > Hi, > > I will send 10 patches for msi.dll that will add support for OBJECT > types in the Msi Database and that will allow you to merge in new > tables. > > This will make the WiX (Windows Installer XML) toolkit work a lot better. > > Please review and provide feedback on what can be improved as this is > my first substantial patch series to wine. > > Kind regards, > > Hib Eris > > > --- > dlls/msi/tests/db.c | 84 +++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 84 insertions(+), 0 deletions(-) > > > > Great work. Thanks for helping Wine! -- -Austin

May 24, 2009

Re: DIB Engine : passing all tests

by Massimo Del Fedele

André Hentschel ha scritto: > Massimo Del Fedele schrieb: >> André Hentschel ha scritto: >>> I dont know anything about that, but may it be possible to compile >>> your code to a standalone driver for seperate download? >>> It would be great to just install a DIB-Driver for wine. >>> Sorry if that was a stupid idea. >>> >> The idea is not stupid at all :-) >> I was thinking to do it, but I don't know for how many >> machines a separate compile would be needed. >> I'm working on ubuntu64, and I tested just migrating the >> 2 DLLs on an ubuntu32 and it do work, so I guess it should >> work on most linuxes. >> No idea on what will happen with Mac or other unixes.... >> >> Max >> >> >> > > would you provide your builds for us? > > > Can do on next days. But I need some place on where to put the precompiled dlls... I guess nor bug421 page nor here are good places for it. Ciao Max

May 24, 2009

Using Windows ODBC drivers

by martti

Types successfully tested under wine: DB Type=PostgreSQL, Usefullness=100% Wine use: 1.1.21

May 24, 2009

Re: urlmon: Cache binding notif window.

by Jacek Caban

Hi Dan, Dan Kegel wrote: > Hi Jacek, > why do you have tls_list in > http://www.winehq.org/pipermail/wine-patches/2009-May/072833.html > ? The usual idiom is to just free each thread's data in THREAD_DETACH, > isn't it? > THREAD_DETACH is called only if thread detaches before urlmon.dll is unloaded. When urlmon.dll is unloaded only PROCESS_DETACH is called and we have to free TLS resources of all threads to avoid leaks (I don't consider such leaks as a serious problem, but it's better to avoid them). > I ran into this while chasing a crash regression in Sketchup, see > Anastasius' comments in http://bugs.winehq.org/show_bug.cgi?id=18601 > I've attached a patch to the bug. Thanks, Jacek

May 24, 2009

[comctl32] Test request

by Nikolay Sivov

Hi. I've just prepared some simple MRU tests and I need test them on various native platfoms - tested only on xp sp2 so this one could be skipped. Could somebody do it?

May 24, 2009

re: urlmon: Cache binding notif window.

by Dan Kegel

Hi Jacek, why do you have tls_list in http://www.winehq.org/pipermail/wine-patches/2009-May/072833.html ? The usual idiom is to just free each thread's data in THREAD_DETACH, isn't it? I ran into this while chasing a crash regression in Sketchup, see Anastasius' comments in http://bugs.winehq.org/show_bug.cgi?id=18601 - Dan

May 24, 2009

Re: DIB Engine : passing all tests

by André Hentschel

Massimo Del Fedele schrieb: > André Hentschel ha scritto: >> I dont know anything about that, but may it be possible to compile >> your code to a standalone driver for seperate download? >> It would be great to just install a DIB-Driver for wine. >> Sorry if that was a stupid idea. >> > The idea is not stupid at all :-) > I was thinking to do it, but I don't know for how many > machines a separate compile would be needed. > I'm working on ubuntu64, and I tested just migrating the > 2 DLLs on an ubuntu32 and it do work, so I guess it should > work on most linuxes. > No idea on what will happen with Mac or other unixes.... > > Max > > > would you provide your builds for us?

May 24, 2009

Re: DIB Engine : passing all tests

by Massimo Del Fedele

André Hentschel ha scritto: > I dont know anything about that, but may it be possible to compile your > code to a standalone driver for seperate download? > It would be great to just install a DIB-Driver for wine. > Sorry if that was a stupid idea. > The idea is not stupid at all :-) I was thinking to do it, but I don't know for how many machines a separate compile would be needed. I'm working on ubuntu64, and I tested just migrating the 2 DLLs on an ubuntu32 and it do work, so I guess it should work on most linuxes. No idea on what will happen with Mac or other unixes.... Max

May 24, 2009

Re: DIB Engine : passing all tests

by André Hentschel

I dont know anything about that, but may it be possible to compile your code to a standalone driver for seperate download? It would be great to just install a DIB-Driver for wine. Sorry if that was a stupid idea. >> > Nope, and I think they will not be solved soon. Not by me, anyways. > I made my engine because I was needing it, but Alexandre don't like > its architecture, so it won't be merged even if, IMHO of course, it > could be done as an "alternative experimental driver" in parallel to > current winex11 one, which could spread its usage and testing a lot > more. But Alexandre didn't like that solution, ever. > > Ciao > > Max > > >

May 24, 2009

Re: DIB Engine : passing all tests

by Chris Howe

2009/5/24 Massimo Del Fedele <max(a)veneto.com> > I'm looking forward to this hitting upstream :) Have the architectural >> issues been solved yet? >> >> Nope, and I think they will not be solved soon. Not by me, anyways. > I made my engine because I was needing it, but Alexandre don't like > its architecture, so it won't be merged even if, IMHO of course, it > could be done as an "alternative experimental driver" in parallel to > current winex11 one, which could spread its usage and testing a lot > more. But Alexandre didn't like that solution, ever. > I assume all this took place on IRC because unless I missed it, Alexandre hasn't deigned to comment on here about what the right architectural solution would be. Sorry to sound like a stuck record but the Wine website still lists "write a DIB engine" as a requirement, and every time someone does, the patches dissapear down a hole because they're "not right". Someone document what "would be right", or take "write a DIB engine" off the list. I'd love to have a go at documenting it myself, but I don't have the time to reverse engineer it from a few years' worth of rejected solutions. -- Chris

May 24, 2009

Re: DIB Engine : passing all tests

by Massimo Del Fedele

Kai Blin ha scritto: > On Sunday 24 May 2009 06:54:10 Ben Klein wrote: > >> Does that mean it's time to remove these todos (and make them full >> tests) or are they still wanted for the case where Max's DIB engine is >> not installed? > > They are full tests, they're just marked as not passing in wine. Which they > don't. At least not until wine has a DIB engine. Most but not all of them. A few of them could be fixed anyways. > >> I'm looking forward to this hitting upstream :) Have the architectural >> issues been solved yet? > > It seems like Max and Alexandre agreed to disagree. I wouldn't hold my breath > for this code to be merged to the main tree. Unfortunately, Max seems to like > using Bugzilla to let people track his patches, instead of dumping them into > some git tree, which would make keeping track of updates easier. His call of > course. The problem here is that I've got no time to maintain an updated git tree with my engine.... and I'm still fixing stuffs, so I prefere to manage my patchset directly in order to avoid a 1000+ patches on my tree. Dumping my patchset on a git tree wouldn't make its usage easier and would make me loose time and bandwidth to maintain it. People able to check out a git tree and build it are also able to apply the patchset to a clean one. It makes them spare time, too, as they don't have to maintain and build 2 different trees. With stacked git it's easy to add/remove the patchset. Anyways, if somebody wont take the (again, useless imho) job of maintain an updated tree with it, feel free to do it :-) Ciao Max

May 24, 2009

Re: DIB Engine : passing all tests

by Massimo Del Fedele

Ben Klein ha scritto: > 2009/5/24 Massimo Del Fedele <max(a)veneto.com>: >> Austin English ha scritto: >>> On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele <max(a)veneto.com> >>> wrote: >>>> I posted on bug 421 page (as usual) latest update of my engine. >>>> It suld pass all tests in wine suite.... also all bitmap's todo_wines, >>>> so expect some "false positive" signaled by tests. >>>> >>>> Austin, could you please re-run it on your test machines ? >>> Sorry for the delay. New residence has crappy wireless internet, need >>> to find a better solution. >>> >>> Anywho, I've still got a failure: >>> palette.c:105: Test failed: getColor=00302010 >>> >>> http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_a… >>> >> Yep, I've seen it.... sorry, I checked out just the bitmap suite. >> It's trivial to fix, will do on next release >> >>> Yep, several todo's are passing now: >>> >>> http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_a… >>> >> too bad that the suite marks them as failures :-) > > Does that mean it's time to remove these todos (and make them full > tests) or are they still wanted for the case where Max's DIB engine is > not installed? I guess not, wine is not passing them, and it won't pass most of them without a proper DIB engine. Some of them are independent of dib engine, indeed, and could be fixed anyways. > > I'm looking forward to this hitting upstream :) Have the architectural > issues been solved yet? > Nope, and I think they will not be solved soon. Not by me, anyways. I made my engine because I was needing it, but Alexandre don't like its architecture, so it won't be merged even if, IMHO of course, it could be done as an "alternative experimental driver" in parallel to current winex11 one, which could spread its usage and testing a lot more. But Alexandre didn't like that solution, ever. Ciao Max

May 24, 2009

Re: DIB Engine : passing all tests

by Kai Blin

On Sunday 24 May 2009 06:54:10 Ben Klein wrote: > Does that mean it's time to remove these todos (and make them full > tests) or are they still wanted for the case where Max's DIB engine is > not installed? They are full tests, they're just marked as not passing in wine. Which they don't. At least not until wine has a DIB engine. > I'm looking forward to this hitting upstream :) Have the architectural > issues been solved yet? It seems like Max and Alexandre agreed to disagree. I wouldn't hold my breath for this code to be merged to the main tree. Unfortunately, Max seems to like using Bugzilla to let people track his patches, instead of dumping them into some git tree, which would make keeping track of updates easier. His call of course. 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.

May 24, 2009

Re: annoying pkg-config problem on 64 bit Ubuntu 8.10

by Ben Klein

2009/5/23 Austin English <austinenglish(a)gmail.com>: > On Thu, May 21, 2009 at 5:24 PM, Joel Holdsworth > <joel(a)airwebreathe.org.uk> wrote: >> On Thu, 2009-05-21 at 22:18 +0200, Tijnema wrote: >>> Haven't checked Jaunty yet to see if it's still busted. >>> We may need to postprocess pkg-config's output to add the >>> missing 32 >>> in some cases. Not sure if it's worth it. >>> >> >> On Jaunty I get >> >> $ pkg-config --libs dbus-1 >> -L//lib -ldbus-1 > > I do as well, but './configure' and './configure --enable-win64' both work fine. Does it tell you you're missing dbus or HAL stuff when you're not?

May 24, 2009

Re: DIB Engine : passing all tests

by Ben Klein

2009/5/24 Massimo Del Fedele <max(a)veneto.com>: > Austin English ha scritto: >> >> On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele <max(a)veneto.com> >> wrote: >>> >>> I posted on bug 421 page (as usual) latest update of my engine. >>> It suld pass all tests in wine suite.... also all bitmap's todo_wines, >>> so expect some "false positive" signaled by tests. >>> >>> Austin, could you please re-run it on your test machines ? >> >> Sorry for the delay. New residence has crappy wireless internet, need >> to find a better solution. >> >> Anywho, I've still got a failure: >> palette.c:105: Test failed: getColor=00302010 >> >> http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_a… >> > Yep, I've seen it.... sorry, I checked out just the bitmap suite. > It's trivial to fix, will do on next release > >> Yep, several todo's are passing now: >> >> http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_a… >> > too bad that the suite marks them as failures :-) Does that mean it's time to remove these todos (and make them full tests) or are they still wanted for the case where Max's DIB engine is not installed? I'm looking forward to this hitting upstream :) Have the architectural issues been solved yet?

May 24, 2009

Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3

by James McKenzie

Roderick Colenbrander wrote: > > Thanks, I used this to compile wine 1.1.21 for testing purposes this > week. I had to update the scripts a bit (e.g. use newere versions of > some libraries and tools because the old ones are offline). I can post > a patch against the old script. Further don't ship the opengl hack > anymore for new wine packages as you are aware it isn't needed for > xquartz 2.3.3 anymore. Everyone should move to the latest xquartz. > This might prevent some opengl bug reports which I have to close on > bugzilla as well ;) > > Can you provide the updates to the scripts? Since I am using Leopard, the opengl fix is not needed anymore, but it may have to stay until XQuartz 2.3.3 is backported for Tiger. James McKenzie

May 24, 2009

Re: Updating bugs in Bugzilla

by Ken Sharp

Done without reply. :-p Thanks. Ken Sharp wrote: > Hi all, > > Is there any way I can have access to update bugs that I did not open in > Bugzilla? I update a lot of bugs and some of them are not set correctly > (incorrect component or incorrect URL). Wrong URLs are a real pain > because it can lead to testing the wrong version of an app (see Bug 13371). > At the moment I have to ask someone with access to make these changes > for me, and they're not always done. I don't want to ask them > repeatedly because they have better things to do, I'm sure, and it would > be easier if I could do it myself. > > I have admin access on the AppDB for this reason. Is there any way I > could have a similar access on Bugzilla? > > I had no idea where to send this email to... > > Thanks, > Ken. >

May 24, 2009

Re: Static-ify rsaenh/mpi?

by Andrew Talbot

Francois Gouget wrote: > The bug is with -O3 which is not the default and which I would not > personally care about. I'd be more open about maintenance issues. > My inclination would be to make the functions static. However, how to handle the comments is an issue to consider. Also, I probably made a mistake in moving functions around at the same time in order to avoid unnecessary forward references: perhaps that is best treated as a separate exercise. -- Andy.

May 23, 2009

Re: Static-ify rsaenh/mpi?

by Francois Gouget

On Sat, 23 May 2009, Andrew Talbot wrote: [...] > I made a few of the functions in mpi.c static a while back, but stopped when > there was a bug report (http://bugs.winehq.org/show_bug.cgi?id=17406) > that seemed consequential but turned out to be apparently due to a bug gcc. The bug is with -O3 which is not the default and which I would not personally care about. I'd be more open about maintenance issues. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

May 23, 2009

re: Updating bugs in Bugzilla

by Dan Kegel

Ken Sharp asked: > [Can I have bugzilla privs?] OK, you have them now. Please them wisely.

May 23, 2009

Re: DXTn textures in D3DX9

by Henri Verbeet

2009/5/22 Tony Wasserka <tony.wasserka(a)freenet.de>: > Hi everyone, > I'm working on implementing D3DXLoadSurfaceFromFileInMemory right now, > but I've got a problem. The function > most convert a loaded surface's data to a user specified surface format > (I did not yet find a way to do it elsehow, > UpdateTexture and StretchRect are to limited for that task, suggestions > welcome if I missed anything). > Now, if the user specifies that D3DX9 needs to convert e.g. an R8G8B8 > surface to DXT1 (or to save a surface to a > DXTn compressed DDS file), I'm not sure wether I can implement that > behavior; on #winehackers I was told that > the (de)compression part is coverered by S3's patents, but the Gimp DDS > plugin and this > (http://mollyrocket.com/forums/viewtopic.php?t=392) seem to provide OSS > solutions for it anways. > So... Can anybody tell me for sure wether I may implement this code or not? > What it comes down to is that I don't think we want to take that risk, so essentially "No".

May 23, 2009

Re: [patch] segv on use-after-free in dsound/buffer.c

by Austin English

2009/5/23 Yuriy Kaminskiy <yumkam(a)mail.ru>: > Hello! > One of games rarely crashed with segv in line 86 of dsound/buffer.c: > 85: IDirectSoundBuffer_Release((LPDIRECTSOUNDBUFFER)This->dsb); > 86: This->dsb->notify = NULL; > (sorry, I failed to save actual backtrace at the time). This looks like > typical assign-after-free bug. I've applied attached patch (wine-1.1.7, now > on 1.1.19), no crashes so far (btw, similar *Secodary*Release method down in > code uses proper order - assign-NULL-then-release). Please send patches to wine-patches(a)winehq.org Thanks for helping Wine! -- -Austin

May 23, 2009

Re: DIB Engine : passing all tests

by Massimo Del Fedele

Austin English ha scritto: > On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele <max(a)veneto.com> wrote: >> I posted on bug 421 page (as usual) latest update of my engine. >> It suld pass all tests in wine suite.... also all bitmap's todo_wines, >> so expect some "false positive" signaled by tests. >> >> Austin, could you please re-run it on your test machines ? > > Sorry for the delay. New residence has crappy wireless internet, need > to find a better solution. > > Anywho, I've still got a failure: > palette.c:105: Test failed: getColor=00302010 > http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_a… > Yep, I've seen it.... sorry, I checked out just the bitmap suite. It's trivial to fix, will do on next release > Yep, several todo's are passing now: > http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_a… > too bad that the suite marks them as failures :-) > Full report: > http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_a… > (The user32 failure can be ignored, I get that spuriously without DIB engine). > Thank you for report. I still have to do a couple of optimizations, some font cleanups and then it'll be finished. I guess I'll setup a build machine for debian/ubuntu packages shortly. Ciao Max

May 23, 2009

Re: DIB Engine : passing all tests

by Austin English

On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele <max(a)veneto.com> wrote: > I posted on bug 421 page (as usual) latest update of my engine. > It suld pass all tests in wine suite.... also all bitmap's todo_wines, > so expect some "false positive" signaled by tests. > > Austin, could you please re-run it on your test machines ? Sorry for the delay. New residence has crappy wireless internet, need to find a better solution. Anywho, I've still got a failure: palette.c:105: Test failed: getColor=00302010 http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_a… Yep, several todo's are passing now: http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_a… Full report: http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_a… (The user32 failure can be ignored, I get that spuriously without DIB engine). -- -Austin

May 23, 2009

Updating bugs in Bugzilla

by Ken Sharp

Hi all, Is there any way I can have access to update bugs that I did not open in Bugzilla? I update a lot of bugs and some of them are not set correctly (incorrect component or incorrect URL). Wrong URLs are a real pain because it can lead to testing the wrong version of an app (see Bug 13371). At the moment I have to ask someone with access to make these changes for me, and they're not always done. I don't want to ask them repeatedly because they have better things to do, I'm sure, and it would be easier if I could do it myself. I have admin access on the AppDB for this reason. Is there any way I could have a similar access on Bugzilla? I had no idea where to send this email to... Thanks, Ken.

May 23, 2009

Re: Static-ify rsaenh/mpi?

by Andrew Talbot

Francois Gouget wrote: > > So dlls/rsaenh/mpi.c defines 13 functions that are only used there. So > they could be made static by tweaking mpi.c and tomcrypt.h. > > However my understanding is that this files has been imported in Wine > from another project so maybe it's not a good idea to diverge much from > them. > > What do you think? > Should we just leave them as is? > Hi Francois, I made a few of the functions in mpi.c static a while back, but stopped when there was a bug report (http://bugs.winehq.org/show_bug.cgi?id=17406) that seemed consequential but turned out to be apparently due to a bug gcc. Also one of my patches to this file was rejected, which I didn't follow up, but it may have been due to the fact that there are comments to each function in both tomcrypt.h and mpi.c, and I tried to form combined versions in the latter. -- Andy.

May 23, 2009

Static-ify rsaenh/mpi?

by Francois Gouget

So dlls/rsaenh/mpi.c defines 13 functions that are only used there. So they could be made static by tweaking mpi.c and tomcrypt.h. However my understanding is that this files has been imported in Wine from another project so maybe it's not a good idea to diverge much from them. What do you think? Should we just leave them as is? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A particle is an irreducible representation of the Poincaré Group - Eugene Wigner

May 23, 2009

[patch] segv on use-after-free in dsound/buffer.c

by Yuriy Kaminskiy

Hello! One of games rarely crashed with segv in line 86 of dsound/buffer.c: 85: IDirectSoundBuffer_Release((LPDIRECTSOUNDBUFFER)This->dsb); 86: This->dsb->notify = NULL; (sorry, I failed to save actual backtrace at the time). This looks like typical assign-after-free bug. I've applied attached patch (wine-1.1.7, now on 1.1.19), no crashes so far (btw, similar *Secodary*Release method down in code uses proper order - assign-NULL-then-release).

May 23, 2009

Re: DXTn textures in D3DX9

by Tony Wasserka

Ben Klein schrieb: > 2009/5/23 Stefan Dösinger <stefandoesinger(a)gmx.at>: > >> Am Freitag, 22. Mai 2009 19:15:22 schrieb Roderick Colenbrander: >> >>> So what they are saying is that Nvidia has a license on the s3tc >>> patent for use in those tools but if we would rip their code out we >>> wouldn't be covered unless (but that is gray area) we put all their >>> image code in wine (which would be impossible since it is C++). >>> Perhaps if we want to be safe we could ask s3 for a license for use in >>> Wine? >>> >> Hmm. My idea would have been to link against this lib, but if it is C++ it >> makes troubles. >> >> > > Interestingly enough, nvidia-texture-tools is MIT license and provides > no provision for patent protection. In theory, a fork of this project > to C would be linkable with Wine without legal issues. > > > Their FAQ states that "[we] don't have to obtain a license of the S3TC patent to use any of NVIDIA's products" but it also adds that "certain uses of NVIDIA Texture Tools source code cannot be considered NVIDIA products anymore." Thus, forking the project and integrating it into Wine would probably have the same legal status as writing an own S3TC (de)compressor within Wine. Seems like asking for a license or directly using the binaries of this lib are the only options we have then. Forking NVIDIA TT and disable it by default would probably not be accepted by AJ I guess...

May 23, 2009

Re: DXTn textures in D3DX9

by Ben Klein

2009/5/23 Stefan Dösinger <stefandoesinger(a)gmx.at>: > Am Freitag, 22. Mai 2009 19:15:22 schrieb Roderick Colenbrander: >> So what they are saying is that Nvidia has a license on the s3tc >> patent for use in those tools but if we would rip their code out we >> wouldn't be covered unless (but that is gray area) we put all their >> image code in wine (which would be impossible since it is C++). >> Perhaps if we want to be safe we could ask s3 for a license for use in >> Wine? > Hmm. My idea would have been to link against this lib, but if it is C++ it > makes troubles. > Interestingly enough, nvidia-texture-tools is MIT license and provides no provision for patent protection. In theory, a fork of this project to C would be linkable with Wine without legal issues.

May 23, 2009

DIB Engine : passing all tests

by Massimo Del Fedele

I posted on bug 421 page (as usual) latest update of my engine. It suld pass all tests in wine suite.... also all bitmap's todo_wines, so expect some "false positive" signaled by tests. Austin, could you please re-run it on your test machines ? Ciao Max

May 22, 2009

Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3

by James Mckenzie

Roderick Colenbrander wrote about Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3 > >On Wed, May 20, 2009 at 4:04 PM, Austin English <austinenglish(a)gmail.com> wrote: >> On Wed, May 20, 2009 at 4:46 AM, Roderick Colenbrander >> <thunderbird2k(a)gmail.com> wrote: >>> On Tue, May 19, 2009 at 6:41 PM, Mike Kronenberg >>> <mike.kronenberg(a)kronenberg.org> wrote: >>>> On 18.05.2009, at 06:56, Dmitry Timoshkov wrote: >>>> >>>>> "James McKenzie" <jjmckenzie51(a)earthlink.net> wrote: >>>>> >>>>>> Austin: >>>>>> Contact Mike Kronenberg or Zach Drayer and see what they currently >>>>>> have. >>>>> >>>>> IMHO since they haven't even bothered so far to change the license from >>>>> GPL to LGPL to match Wine, and clarify what exactly is so much different >>>>> in their builds so that they insist on different naming (Darwine vs. >>>>> Wine), >>>>> they shouldn't be even considered as partners to the Wine project. >>>>> >>>>> If we could have our own Wine builds for Intel Macs, that would finally >>>>> help to avoid this confusion Darwine adds, and remove it from our Wiki >>>>> altogether (since it's apparently where the users coming to them from). >>>>> >>>>> -- >>>>> Dmitry. >>>>> >>>>> >>>> >>>> >>>> >>>> Hi, >>>> >>>> (I hope I did not double-post, but somehow my mail from yesterday was eaten >>>> by filter-gnomes) >>>> >>>> It's not about being willing to, but plain lack of time. >>>> I follow this list closely and work on solutions as time permits. >>>> After half a year, it's been four weeks now that I am able again to build >>>> and test on a regular base again. >>>> >>>> There are other components on OS X that need some love, like the >>>> winehelper.app into which I'm looking atm. >>>> >>>> License and renaming is definitely on the list. >>>> I thought to revamp the package, once the winehelper is replaced, to not >>>> double do the work. >>>> >>>> As already mentioned, I build the dependencies and store them inside the >>>> apple .app package, which allows for drag'n'drop installation and removal. >>>> >>>> Having the dependencies as frameworks would be even better, as there is a >>>> lot of trouble with PATHS, especially if multiple environments are on the >>>> system, like fink and macports. >>>> >>>> But if the name-change is the most pressing issue, I will gladly do that >>>> with this weekends release. >>>> >>>> Mike Kronenberg >>>> >>>> >>>> >>> >>> Could you also upload some docs / scripts on how to build 'DarWine' >>> from scratch? I have an app which I need to run on osx which I like to >>> package as well. I have time to help fixing osx issues (duplicating >>> the effort is not worth it). >>> >>> Roderick >>> >>> >>> >> >> It's available under 'build env': >> http://www.kronenberg.org/darwine/buildenv-1.1.5.zip >> >> -- >> -Austin >> > >Thanks, I used this to compile wine 1.1.21 for testing purposes this >week. I had to update the scripts a bit (e.g. use newere versions of >some libraries and tools because the old ones are offline). I can post >a patch against the old script. Further don't ship the opengl hack >anymore for new wine packages as you are aware it isn't needed for >xquartz 2.3.3 anymore. Everyone should move to the latest xquartz. >This might prevent some opengl bug reports which I have to close on >bugzilla as well ;) > Does XQuartz 2.3.3 apply on Tiger systems? The 'hack' is for both Tiger and Leopard so that some missing functions will work. Please list the updated libraries so that I can upgrade the script as well. James McKenzie

May 22, 2009

Re: Entry point not found for GetDiskInfoA (wininet_crosstest.exe)

by Detlef Riekenberg

On Do, 2009-05-21 at 12:05 +0200, Alexandre Julliard wrote: > > Using that executable on Windows or Wine is not possible > > (Entry point not found for GetDiskInfoA) > > > > The wininet_test.exe on winehq has an ordinal Import of 102 in that > > place. > > How can we fix that? > > You have to use the Wine import libs, not the Mingw ones. >From IRC: <julliard> you haven't run make crosstest from the top level <winspool> "make -C dlls/wininet/tests crosstest" is different???? <julliard> yes it's different <julliard> you need to build the import libs if you want them to be used <winspool> Where is the rule to create all import libs? <julliard> just do a make crosstest at the top level, it takes care of everything Example for building an import-lib for mingw on demand: make -C dlls/wininet/ libwininet.a -- By by ... Detlef

May 22, 2009

Re: Mac OS X Joystick problem

by Nathan Gray

On Thu, May 21, 2009 at 10:45 AM, Aric Stewart <aric(a)codeweavers.com> wrote: > > If you are good there then try building the winetests for dinput and run > them with your joystick plugged in. You should get some status traces about > your joystick (finding the name and status of the various axes and buttons) Ok, I built everything with Mike's build environment (after a bit of updating URLs and such). From within the build directory I can run dinput_test.exe and I get output like this (moving the stick and pushing some buttons): [n8gray(a)golux]% wine programs/winetest/dinput_test.exe joystick joystick.c:616: -- Testing Direct Input Version 0x0700 -- fixme:dinput:get_osx_device_elements Unhandled type 513 fixme:dinput:get_osx_device_elements Unhandled type 513 joystick.c:206: ---- Microsoft SideWinder Precision Pro (USB) ---- joystick.c:572: joystick.c:591: X 1976 Y-1061 Z 0 Rx 0 Ry 0 Rz -323 S0-1056 S1 0 POV0 9000 POV1 -1 POV2 -1 POV3 -1 B 0 0 0 1 1 0 0 1 0 0 0 0 joystick.c:596: joystick.c:616: -- Testing Direct Input Version 0x0500 -- fixme:dinput:get_osx_device_elements Unhandled type 513 fixme:dinput:get_osx_device_elements Unhandled type 513 joystick.c:206: ---- Microsoft SideWinder Precision Pro (USB) ---- joystick.c:572: joystick.c:591: X 2000 Y-1101 Z 0 Rx 0 Ry 0 Rz -323 S0-1088 S1 0 POV0 9000 POV1 -1 POV2 -1 POV3 -1 B 0 0 0 1 1 0 0 1 0 0 0 0 joystick.c:596: joystick.c:616: -- Testing Direct Input Version 0x0300 -- joystick: 251 tests executed (0 marked as todo, 0 failures), 0 skipped. > If that is working then it may be how the games interact with dinput so it > become not a mac specific issue. However, I still don't get any axes detected in the IL2 demo. During launch it produces this output: DirectX Joystick NOT created: DirectX joystick driver: device not attached (Yes, the joystick is attached when I launch it.) I also don't get any joysticks listed in the Descent Freespace demo's setup app. Is there some other demo you can recommend that works for you? Thanks, -n8 -- http://n8gray.org

May 22, 2009

Re: DXTn textures in D3DX9

by Stefan Dösinger

Am Freitag, 22. Mai 2009 19:15:22 schrieb Roderick Colenbrander: > So what they are saying is that Nvidia has a license on the s3tc > patent for use in those tools but if we would rip their code out we > wouldn't be covered unless (but that is gray area) we put all their > image code in wine (which would be impossible since it is C++). > Perhaps if we want to be safe we could ask s3 for a license for use in > Wine? Hmm. My idea would have been to link against this lib, but if it is C++ it makes troubles.

May 22, 2009

Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3

by Roderick Colenbrander

On Wed, May 20, 2009 at 4:04 PM, Austin English <austinenglish(a)gmail.com> wrote: > On Wed, May 20, 2009 at 4:46 AM, Roderick Colenbrander > <thunderbird2k(a)gmail.com> wrote: >> On Tue, May 19, 2009 at 6:41 PM, Mike Kronenberg >> <mike.kronenberg(a)kronenberg.org> wrote: >>> On 18.05.2009, at 06:56, Dmitry Timoshkov wrote: >>> >>>> "James McKenzie" <jjmckenzie51(a)earthlink.net> wrote: >>>> >>>>> Austin: >>>>> Contact Mike Kronenberg or Zach Drayer and see what they currently >>>>> have. >>>> >>>> IMHO since they haven't even bothered so far to change the license from >>>> GPL to LGPL to match Wine, and clarify what exactly is so much different >>>> in their builds so that they insist on different naming (Darwine vs. >>>> Wine), >>>> they shouldn't be even considered as partners to the Wine project. >>>> >>>> If we could have our own Wine builds for Intel Macs, that would finally >>>> help to avoid this confusion Darwine adds, and remove it from our Wiki >>>> altogether (since it's apparently where the users coming to them from). >>>> >>>> -- >>>> Dmitry. >>>> >>>> >>> >>> >>> >>> Hi, >>> >>> (I hope I did not double-post, but somehow my mail from yesterday was eaten >>> by filter-gnomes) >>> >>> It's not about being willing to, but plain lack of time. >>> I follow this list closely and work on solutions as time permits. >>> After half a year, it's been four weeks now that I am able again to build >>> and test on a regular base again. >>> >>> There are other components on OS X that need some love, like the >>> winehelper.app into which I'm looking atm. >>> >>> License and renaming is definitely on the list. >>> I thought to revamp the package, once the winehelper is replaced, to not >>> double do the work. >>> >>> As already mentioned, I build the dependencies and store them inside the >>> apple .app package, which allows for drag'n'drop installation and removal. >>> >>> Having the dependencies as frameworks would be even better, as there is a >>> lot of trouble with PATHS, especially if multiple environments are on the >>> system, like fink and macports. >>> >>> But if the name-change is the most pressing issue, I will gladly do that >>> with this weekends release. >>> >>> Mike Kronenberg >>> >>> >>> >> >> Could you also upload some docs / scripts on how to build 'DarWine' >> from scratch? I have an app which I need to run on osx which I like to >> package as well. I have time to help fixing osx issues (duplicating >> the effort is not worth it). >> >> Roderick >> >> >> > > It's available under 'build env': > http://www.kronenberg.org/darwine/buildenv-1.1.5.zip > > -- > -Austin > Thanks, I used this to compile wine 1.1.21 for testing purposes this week. I had to update the scripts a bit (e.g. use newere versions of some libraries and tools because the old ones are offline). I can post a patch against the old script. Further don't ship the opengl hack anymore for new wine packages as you are aware it isn't needed for xquartz 2.3.3 anymore. Everyone should move to the latest xquartz. This might prevent some opengl bug reports which I have to close on bugzilla as well ;) Roderick

May 22, 2009

Re: DXTn textures in D3DX9

by Roderick Colenbrander

On Fri, May 22, 2009 at 6:11 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > You may find this helpful: > http://code.google.com/p/nvidia-texture-tools/ > > Wrt the legalese check the last question here: > http://code.google.com/p/nvidia-texture-tools/wiki/FAQ > > Using a proven library for s3tc handling is a good idea even without the legal > troubles. s3tc decompression isn't rocket science, but s3tc compression is > harder than it seems. Nvidia, ATI and Microsoft have fought a long battle for > the best s3tc compression algorithm. For a long time s3tc was considered bad > because there was no really good compressor - so I recommend not to reinvent > the wheel here. > So what they are saying is that Nvidia has a license on the s3tc patent for use in those tools but if we would rip their code out we wouldn't be covered unless (but that is gray area) we put all their image code in wine (which would be impossible since it is C++). Perhaps if we want to be safe we could ask s3 for a license for use in Wine? Roderick

May 22, 2009

Re: wine on MacOS 10.5.7: 3/4 success

by Steven Edwards

On Fri, May 22, 2009 at 5:39 AM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Set one of those to /usr/X11/lib, because that's where libfreetype* > resides in MacOS. There's no need to turn to MacPorts. > LD_LIBRARY_PATH=/usr/X11/lib ./wine notepad > lets wine finds hundreds of fonts. > > BTW, Macports' wrapper uses DYLD_FALLBACK_LIBRARY_PATH > The ./wine wrapper itself sets DYLD_LIBRARY_PATH to its internal .so dir. > > Maybe it would not be a good idea to add this directory to the > official ./wine wrapper, as it could cause conflicts with Fink or > Macports sets of libraries? There is a reason you may want to roll your own freetype. I don't believe the freetype that ships with even the latest Xorg dpkg contains support for the patented bytecode stuff or subpixel rendering enabled. I could be wrong about needing to do it (perhaps I have an old version floating around), but I rolled my own freetype with it enabled and enabled the proper keys in Wine and can hardly see a difference in Safari or Wine iexplore rendering winehq.org You should be legally covered on by virtue of being a Mac user as Apple owns a nice patent chest and also owns one part of the patent pie. -- 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

May 22, 2009

Re: Mac OS X Joystick problem

by Nathan Gray

On Fri, May 22, 2009 at 4:54 AM, Mike Kronenberg <mike.kronenberg(a)kronenberg.org> wrote: > On 22.05.2009, at 05:05, Nathan Gray wrote: > >> On Thu, May 21, 2009 at 10:45 AM, Aric Stewart <aric(a)codeweavers.com> >> wrote: >>> >>> Well the Mac OS X Joystick code will only work on Leopard. >>> So you will have to build and run it on Leopard box using xcode3. >> >> I'm certainly running on Leopard, but I can't say how Mike built it. >> >>> If you are good there then try building the winetests for dinput and run >>> them with your joystick plugged in. You should get some status traces >>> about >>> your joystick (finding the name and status of the various axes and >>> buttons) >> >> I guess I'll see if I can find time to set up a build environment. >> The last time I tried I could never build a fully-functional wine >> despite hours of effort. >> >> Thanks, >> -n8 >> >> -- >> http://n8gray.org >> >> > > > Hi Natahn, > > I have a focus on simple enduser products :) > Thats why my downloadable builds are all made on Tiger (XCode 2.x) to have a > single app running on both systems. > But the script from my building environment is made to build on Leopard > (XCode 3.x) , too. I guess that explains it -- thanks for clarifying. You may want to add a note somewhere that joysticks won't work with your builds to save some frustration. Thanks, -n8 -- http://n8gray.org

May 22, 2009

Re: DXTn textures in D3DX9

by Stefan Dösinger

You may find this helpful: http://code.google.com/p/nvidia-texture-tools/ Wrt the legalese check the last question here: http://code.google.com/p/nvidia-texture-tools/wiki/FAQ Using a proven library for s3tc handling is a good idea even without the legal troubles. s3tc decompression isn't rocket science, but s3tc compression is harder than it seems. Nvidia, ATI and Microsoft have fought a long battle for the best s3tc compression algorithm. For a long time s3tc was considered bad because there was no really good compressor - so I recommend not to reinvent the wheel here.

May 22, 2009

Handle Types: Big flaw in wine

by Daniel Santos

As I've been working with user32, adding tests & such, I've noticed that gdi32 also suffers from the same drawbacks: it appears to have no mechanism to track object types with handles. Thus, the functions (that I've examined thus far) simply assume that the caller responsibly passed a handle to the correct object type and proceeds with that assumption. This is the cause of at least one bug that I know of (18371). Right now, I'm trying to determine the best way to implement a solution and I'm still green to wine's architecture. My initial thought was a handle type table in user32 that would just contain a handle's type as a byte (or possibly two types packed in one byte since there are less than 16) using a huge ugly 64k table that directly mapped handle to entry (ugly but correct) and something more efficient later. But I'm wondering if it wouldn't be more appropriate to put something like that in kernel32's global arena table. Input appreciated. Daniel

May 22, 2009

Re: annoying pkg-config problem on 64 bit Ubuntu 8.10

by Austin English

On Thu, May 21, 2009 at 5:24 PM, Joel Holdsworth <joel(a)airwebreathe.org.uk> wrote: > On Thu, 2009-05-21 at 22:18 +0200, Tijnema wrote: >> Haven't checked Jaunty yet to see if it's still busted. >> We may need to postprocess pkg-config's output to add the >> missing 32 >> in some cases. Not sure if it's worth it. >> > > On Jaunty I get > > $ pkg-config --libs dbus-1 > -L//lib -ldbus-1 I do as well, but './configure' and './configure --enable-win64' both work fine. -- -Austin

May 22, 2009

Using TlsGetValue internally

by Daniel Santos

I'm playing with user32/cursoricon.c and winex11.drv/mouse.c and have noticed that one of the TODOs is that SetCursor (and probably lots others) clear the last error when they do not do so in windows. I tracked down the cause and winex11.drv's primary function for retrieving its per-thread data, x11drv_thread_data() calls the public kernel32 function TlsGetValue, which must set the last error to zero by specification. So, should we be using some internal function to get the TLS data that does not alter SetLastError or should we just save the last error in winex11.drv, call TlsGetValue and then restore the last error state? The later seems hack-ish, but the former sounds like a pain. Thanks, Daniel

May 22, 2009

Re: DXTn textures in D3DX9

by Roderick Colenbrander

On Fri, May 22, 2009 at 2:08 PM, Ben Klein <shacklein(a)gmail.com> wrote: > 2009/5/22 Tony Wasserka <tony.wasserka(a)freenet.de>: >> Hi everyone, >> I'm working on implementing D3DXLoadSurfaceFromFileInMemory right now, >> but I've got a problem. The function >> most convert a loaded surface's data to a user specified surface format >> (I did not yet find a way to do it elsehow, >> UpdateTexture and StretchRect are to limited for that task, suggestions >> welcome if I missed anything). >> Now, if the user specifies that D3DX9 needs to convert e.g. an R8G8B8 >> surface to DXT1 (or to save a surface to a >> DXTn compressed DDS file), I'm not sure wether I can implement that >> behavior; on #winehackers I was told that >> the (de)compression part is coverered by S3's patents, but the Gimp DDS >> plugin and this >> (http://mollyrocket.com/forums/viewtopic.php?t=392) seem to provide OSS >> solutions for it anways. >> So... Can anybody tell me for sure wether I may implement this code or not? >> >> >> Best regards, Tony > > If it counts for anything, I'd like to see a converter going the other > way (bug 14939). > > > Note that there is some basic s3tc support in mesa these days which you can activate using driconf. I forgot what its limitations are. I believe it is enough for rendering. Roderick

May 22, 2009

Re: DXTn textures in D3DX9

by Ben Klein

2009/5/22 Tony Wasserka <tony.wasserka(a)freenet.de>: > Hi everyone, > I'm working on implementing D3DXLoadSurfaceFromFileInMemory right now, > but I've got a problem. The function > most convert a loaded surface's data to a user specified surface format > (I did not yet find a way to do it elsehow, > UpdateTexture and StretchRect are to limited for that task, suggestions > welcome if I missed anything). > Now, if the user specifies that D3DX9 needs to convert e.g. an R8G8B8 > surface to DXT1 (or to save a surface to a > DXTn compressed DDS file), I'm not sure wether I can implement that > behavior; on #winehackers I was told that > the (de)compression part is coverered by S3's patents, but the Gimp DDS > plugin and this > (http://mollyrocket.com/forums/viewtopic.php?t=392) seem to provide OSS > solutions for it anways. > So... Can anybody tell me for sure wether I may implement this code or not? > > > Best regards, Tony If it counts for anything, I'd like to see a converter going the other way (bug 14939).

May 22, 2009

DXTn textures in D3DX9

by Tony Wasserka

Hi everyone, I'm working on implementing D3DXLoadSurfaceFromFileInMemory right now, but I've got a problem. The function most convert a loaded surface's data to a user specified surface format (I did not yet find a way to do it elsehow, UpdateTexture and StretchRect are to limited for that task, suggestions welcome if I missed anything). Now, if the user specifies that D3DX9 needs to convert e.g. an R8G8B8 surface to DXT1 (or to save a surface to a DXTn compressed DDS file), I'm not sure wether I can implement that behavior; on #winehackers I was told that the (de)compression part is coverered by S3's patents, but the Gimp DDS plugin and this (http://mollyrocket.com/forums/viewtopic.php?t=392) seem to provide OSS solutions for it anways. So... Can anybody tell me for sure wether I may implement this code or not? Best regards, Tony

May 22, 2009

Re: Mac OS X Joystick problem

by Mike Kronenberg

On 22.05.2009, at 05:05, Nathan Gray wrote: > On Thu, May 21, 2009 at 10:45 AM, Aric Stewart > <aric(a)codeweavers.com> wrote: >> Well the Mac OS X Joystick code will only work on Leopard. >> So you will have to build and run it on Leopard box using xcode3. > > I'm certainly running on Leopard, but I can't say how Mike built it. > >> If you are good there then try building the winetests for dinput >> and run >> them with your joystick plugged in. You should get some status >> traces about >> your joystick (finding the name and status of the various axes and >> buttons) > > I guess I'll see if I can find time to set up a build environment. > The last time I tried I could never build a fully-functional wine > despite hours of effort. > > Thanks, > -n8 > > -- > http://n8gray.org > > Hi Natahn, I have a focus on simple enduser products :) Thats why my downloadable builds are all made on Tiger (XCode 2.x) to have a single app running on both systems. But the script from my building environment is made to build on Leopard (XCode 3.x) , too. Mike

May 22, 2009

wine on MacOS 10.5.7: 3/4 success

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, here are my findings about compiling and using wine on an "early 2009" Mac Mini with NVidia graphics, without Fink or Macports. I hope it'll help other people. The good news first: + compilation essentially works. + Pharaoh (1.2 update, nocd) works in desktop mode. - old (16bit?) apps cause winevdm to crash, e.g. PharaohDemo's setup.exe Details follow. Bugs will be submitted separately. The setup is: + "early 2009" NVidia 9400 Mac Mini with OS 10.5.6 + XCode from DVD install disk. I did not install the whole thing, just a few packages, e.g. + gcc4.2 + DeveloperToolsCLI, + DevSDK, X11SDK, OpenGLSDK + CoreAudioSDK etc., without e.g. - gcc4.0 - MacOSX10.5 - DeveloperTools (actually, this one contains the Xcode.app but now complains that it cannot install into a non-empty directory - any ideas?) + Mac OS 10.5.7 update (includes X11 manpages) + XQuartz' X11.2.33.2 Not installing gcc-4.0, I changed the stale symlink /usr/bin/gcc->gcc-4.0 to gcc-4.2. I used neither Fink nor MacPorts. I found /usr/bin/ in MacOS full of OSS already. Like a Debian (hence Ubuntu) system, every tool has its manpage! Fink was not used because I was told it's obsolete. Macports was nuked after it started to configure and compile software as root, which violates my software acceptance policy. Another time I'll try pre-compiled binaries from Mike Kronenberg to see if that makes a difference, but as I plan to do as much regression testing as on Linux, I'll stick with git and compiling myself. ---------------- Compiling checking png.h usability... no checking png.h presence... no checking for png.h... no png is in /usr/X11/include plus /usr/X11/lib/libpng*, not /usr/include Alas, configure tests for png long before testing for X. Will submit bug. ---- checking mach-o/dyld_images.h usability... no checking mach-o/dyld_images.h presence... yes configure: WARNING: mach-o/dyld_images.h: present but cannot be compiled configure: WARNING: mach-o/dyld_images.h: check for missing prerequisite headers? configure: WARNING: mach-o/dyld_images.h: see the Autoconf documentation configure: WARNING: mach-o/dyld_images.h: section "Present But Cannot Be Compiled" configure: WARNING: mach-o/dyld_images.h: proceeding with the preprocessor's result configure: WARNING: mach-o/dyld_images.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ## Ruben Hillewaere already mentioned this in http://www.winehq.org/pipermail/wine-devel/2009-May/075287.html In file included from conftest.c:67: /usr/include/mach-o/dyld_images.h:65: error: expected specifier-qualifier-list before 'bool' Perhaps a mising bool typedef? ---- configure --verbose summary configure: libhal 32-bit development files not found, no dynamic device support. configure: libgnutls 32-bit development files not found, no schannel support. configure: libsane 32-bit development files not found, scanners won't be supported. configure: libgphoto2 32-bit development files not found, digital cameras won't be supported. configure: liblcms 32-bit development files not found, Color Management won't be supported. configure: libcapi20 32-bit development files not found, ISDN won't be supported. configure: WARNING: libjpeg 32-bit development files not found, JPEG won't be supported. configure: WARNING: libpng 32-bit development files not found, PNG won't be supported. configure: Finished. Do 'make depend && make' to compile Wine. Pretty much what I know from Ubuntu (except for jpeg+hal), where I never bothered to install the lcms or sane or SSL developer packages. ---- compilation warnings In file included from opengl_ext.h:28, from opengl_ext.c:5: /usr/X11/include/GL/gl.h:1387:1: warning: "GL_GLEXT_PROTOTYPES" redefined In file included from opengl_ext.c:5: opengl_ext.h:27:1: warning: this is the location of the previous definition Looks like a bug I'll submit to the XQuartz project. audiounit.c: In function `SynthUnit_CreateDefaultSynthUnit': audiounit.c:351: warning: `AUGraphNewNode' is deprecated (declared at /System/Library/Frameworks/AudioToolbox.framework/Headers/AUGraph.h:674) This is bug #11242 Wine build complete. ---------------- Running ./wine winecfg wine: created the configuration directory '/Users/xyz/.wine' ---- FreeType library issue resolved Wine cannot find the FreeType font library. To enable Wine to use TrueType fonts please install a version of FreeType greater than or equal to 2.0.5. http://www.freetype.org Building font metrics. This may take some time... Font metrics: 0.0% done fixme:font:LFD_InitFontInfo DBCS fonts like '-daewoo-gothic-medium-r-normal--16-120-100-100-c-160-ksc5601.1987-0' are not working correctly now. [... hundreds of messages like this ...] err:font:XFONT_BuildMetrics failed to load -misc-stheiti-medium-r-normal--100-*-100-100-p-0-ibm-cp866 Font metrics: 100.0% done [... repeated anew for every process started ...] "dlopen() searches the following the following until it finds a compatible Mach-O file: $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, current working directory, $DYLD_FALLBACK_LIBRARY_PATH Note: There are no configuration files to control dlopen searching." Set one of those to /usr/X11/lib, because that's where libfreetype* resides in MacOS. There's no need to turn to MacPorts. LD_LIBRARY_PATH=/usr/X11/lib ./wine notepad lets wine finds hundreds of fonts. BTW, Macports' wrapper uses DYLD_FALLBACK_LIBRARY_PATH The ./wine wrapper itself sets DYLD_LIBRARY_PATH to its internal .so dir. Maybe it would not be a good idea to add this directory to the official ./wine wrapper, as it could cause conflicts with Fink or Macports sets of libraries? ---- err:process:__wine_kernel_init boot event wait timed out I get this one *sometimes* on a Linux box as well... ---- no 16 bit apps? winevdm crashes with identical messages on: - Pumuckl Klabauterjagd - Minigolf 1997 (not in AppDB) - Meine Traumburg (dito) - PharaoDemo's setup.exe PharaoDemo:setup.exe "The program winevdm.exe has encountered a serious error ..." Unhandled exception: page fault on read access to 0xffffffff in 32-bit code (1017:00000c1d). Probably a lot of installers will be affected. Is this caused by the mach-o/dyld_images.h warning from configure? Is there no 16bit support on Intel MacOS yet? ---- Pharaoh console log Copying my Linux Pharaoh (1.2 update, nocd) directory over to the Mac, I was pleased to see the title screen and the application running. err:d3d_caps:IWineD3DImpl_FillGLCaps Invalid nVidia version string: "2.0 NVIDIA-1.5.44" The string probably originates from XQuartz' X11.2.33.2. The wine source code expects a space after NVIDIA. Is it actually meningful to return the Apple 1.5 major+minor to a windows program? (On Linux, the numbers are much higher, e.g. "2.1.2 NVIDIA 173.14.09" or "2.1.0 NVIDIA 97.55" -- 2 samples from Google). fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 16 vertex samplers and 16 total samplers fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers fixme:win:EnumDisplayDevicesW ((null),0,0x32f664,0x00000000), stub! fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16 well known from Linux. fixme:wave:wodDsCreate DirectSound not implemented fixme:wave:wodDsCreate The (slower) DirectSound HEL mode will be used instead. probably ok. Pharaoh plays the music. ---- full screen mode Full-screen does not work with Pharaoh. The application exits after: err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 1024x768x16 @0! (NoRes) err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 800x600x16 @0! (NoRes) err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 640x480x16 @0! (NoRes) The LCD's native resolution is higher than those. Hope this helps, Jörg Höhle

May 22, 2009

Re: Mac OS X Joystick problem

by Nathan Gray

On Thu, May 21, 2009 at 10:45 AM, Aric Stewart <aric(a)codeweavers.com> wrote: > Well the Mac OS X Joystick code will only work on Leopard. > So you will have to build and run it on Leopard box using xcode3. I'm certainly running on Leopard, but I can't say how Mike built it. > If you are good there then try building the winetests for dinput and run > them with your joystick plugged in. You should get some status traces about > your joystick (finding the name and status of the various axes and buttons) I guess I'll see if I can find time to set up a build environment. The last time I tried I could never build a fully-functional wine despite hours of effort. Thanks, -n8 -- http://n8gray.org

May 22, 2009

Re: annoying pkg-config problem on 64 bit Ubuntu 8.10

by Joel Holdsworth

On Thu, 2009-05-21 at 22:18 +0200, Tijnema wrote: > Haven't checked Jaunty yet to see if it's still busted. > We may need to postprocess pkg-config's output to add the > missing 32 > in some cases. Not sure if it's worth it. > On Jaunty I get $ pkg-config --libs dbus-1 -L//lib -ldbus-1

May 21, 2009

Re: annoying pkg-config problem on 64 bit Ubuntu 8.10

by Tijnema

(now to the list) On Kubuntu 9.04 (amd64): $ pkg-config --libs dbus-1 -L//lib -ldbus-1 So, still the same. Matijn On Thu, May 21, 2009 at 4:37 PM, Dan Kegel <dank(a)kegel.com> wrote: > On Ubuntu 8.10: > > $ pkg-config --libs dbus-1 > -L//lib -ldbus-1 > > This leads to > > configure:13190: checking for dbus_connection_close in -ldbus-1 > configure:13225: gcc -m32 -o conftest -g -O2 > -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include conftest.c > -ldbus-1 -L//lib -lhal -ldbus-1 >&5 > /usr/bin/ld: //lib/libdbus-1.so: incompatible target > configure:13253: result: no > > Also affects sane. > > Haven't checked Jaunty yet to see if it's still busted. > We may need to postprocess pkg-config's output to add the missing 32 > in some cases. Not sure if it's worth it. > > >

May 21, 2009

Re: Change BITS_IBackgroundCopyJob_SetPriority to a stub so the EvE-Online patcher works.

by Tim Wright

Sorry to everyone for spamming the patch. I was checking " http://www.winehq.org/pipermail/wine-patches/2009-May/date.html" and wasn't seeing it show up so I assumed I had some kind of mail-sending problem at my end. It won't happen again! Regards, Tim On Wed, May 20, 2009 at 11:03 AM, Ricardo Filipe <ricardojdfilipe(a)gmail.com>wrote: > > > 2009/5/20 Tim Wright <timw(a)splhi.com> > >> The EvE-online updater blows up because it's trying to set the download >> priority in BITS (qmgr) and that isn't implemented. Simply stubbing it to >> return S_OK is sufficient to allow it to work. >> >> Third attempt at sending. For some reason, it isn't being posted from >> git-send-email even though the Cc: arrives just fine at another account. >> Patch against git repository. This is bug 18528/12312. >> >> >> >> --- >> dlls/qmgr/job.c | 4 ++-- >> 1 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/dlls/qmgr/job.c b/dlls/qmgr/job.c >> index 3baa893..09693a3 100644 >> --- a/dlls/qmgr/job.c >> +++ b/dlls/qmgr/job.c >> @@ -334,8 +334,8 @@ static HRESULT WINAPI >> BITS_IBackgroundCopyJob_SetPriority( >> IBackgroundCopyJob2 *iface, >> BG_JOB_PRIORITY Val) >> { >> - FIXME("Not implemented\n"); >> - return E_NOTIMPL; >> + FIXME("(%p,0x%08x) stub\n", iface, Val); >> + return S_OK; >> } >> >> static HRESULT WINAPI BITS_IBackgroundCopyJob_GetPriority( >> -- >> 1.6.0.4 >> >> >> >> >> your previous patch was already commited. check git page the next day when > you send patches. > > http://source.winehq.org/git/wine.git/?a=commit;h=cb26244adb4e15ab60e4d02b5… > > ;) >

May 21, 2009

Re: Bugzilla upgrade - opening attachments in browser

by Max Kanat-Alexander

Hey Jeremy. Which parameter, attachment_base or allow_attachment_display? And do you mean that you unset the cookiedomain parameter, or...? (Usually cookiedomain shouldn't be set at all.) -Max Jeremy Newman wrote: > The parameter has been set, as well as the cookie domain param. > > -Newman > > Max Kanat-Alexander wrote: >> Hey Jeremy. The allow_attachment_display parameter has a detailed >> description that notes that you are opening a security hole if you set >> it without setting another parameter (which you haven't set). Did you >> read the description of the parameter? >> >> -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too.

May 21, 2009

Re: Mac OS X Joystick problem

by Aric Stewart

Well the Mac OS X Joystick code will only work on Leopard. So you will have to build and run it on Leopard box using xcode3. If you are good there then try building the winetests for dinput and run them with your joystick plugged in. You should get some status traces about your joystick (finding the name and status of the various axes and buttons) If that is working then it may be how the games interact with dinput so it become not a mac specific issue. -aric Nathan Gray wrote: > Hi all, > > I was happy to see that you recently added support for joysticks in OS > X. (As you may or may not recall, I started to work on that problem a > while back but never found time to finish it.) In any case, I was > disappointed to find that my MS Sidewinder Precision Pro (USB) still > doesn't work in the two games I tried -- The IL-2 Sturmovik demo and > the Descent Freespace demo. The joystick seems not to be detected at > all, from what I can tell. I filed a bug a while back in bugzilla[1] > but it doesn't seem to have gotten any attention. Does the joystick > code work for other people? Does it require any special > configuration? I'm using Mike Kronenberg's 1.1.20 build. > > Thanks, > -n8 > > [1] http://bugs.winehq.org/show_bug.cgi?id=18424 >

May 21, 2009

Re: Bugzilla upgrade - opening attachments in browser

by Jeremy Newman

The parameter has been set, as well as the cookie domain param. -Newman Max Kanat-Alexander wrote: > Hey Jeremy. The allow_attachment_display parameter has a detailed > description that notes that you are opening a security hole if you set > it without setting another parameter (which you haven't set). Did you > read the description of the parameter? > > -Max

May 21, 2009

annoying pkg-config problem on 64 bit Ubuntu 8.10

by Dan Kegel

On Ubuntu 8.10: $ pkg-config --libs dbus-1 -L//lib -ldbus-1 This leads to configure:13190: checking for dbus_connection_close in -ldbus-1 configure:13225: gcc -m32 -o conftest -g -O2 -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include conftest.c -ldbus-1 -L//lib -lhal -ldbus-1 >&5 /usr/bin/ld: //lib/libdbus-1.so: incompatible target configure:13253: result: no Also affects sane. Haven't checked Jaunty yet to see if it's still busted. We may need to postprocess pkg-config's output to add the missing 32 in some cases. Not sure if it's worth it.

May 21, 2009

Re: shell32: for FO_COPY, if the destination is an empty string, SHFileOperation should use the current directory.

by Alexandre Julliard

Lionel Debroux <lionel_debroux(a)yahoo.fr> writes: > I've updated the patch to add more comments and to check whether the > destination file name is empty, instead of checking flTo->feFiles > against NULL, though that should be equivalent due to > ZeroMemory(&flTo, sizeof(FILE_LIST)); > in SHFileOperationW. > > Is this try2 closer to the correct way of doing things ? No, you are still not passing a valid list, and doing lots of extra unneeded work. The first step would be to test what an empty string means for the other cases, so that you can know where to put the code. Then probably build a simple file list containing "." or something like that at the appropriate place. -- Alexandre Julliard julliard(a)winehq.org

May 21, 2009

Re: DIB Engine - Mostly fixed against test suite

by Massimo Del Fedele

Giuseppe Bilotta ha scritto: > > I've started testing your patches (btw, the 9th patch in your series > is missing the 0009- prefix although the 'series' file claims it > should have; ops.... that was the hurry. stgit don't put the prefix, I added it manually just for who don't want to use it also, it's a real pity that git am doesn't accept stgit > patches 8-/ but anyway, that's off topic). well, never used git-am, but I feel quite comfortable with stgit... also because it make easy to correct or integrate a commit > > An application that you might want to test your DIB engine against is > Opera. Although there IS an Opera for Linux, the 64-bit Flash plugin > has some subtle network bugs, and there is no Shockwave plugin at all, > so it is still necessary for me to use Opera for Windows under Wine in > a few cases. that's interesting.... I'll do it in short :-) > > Opera is a good test for your DIB engine because > (1) it has problems with the current GDI32 stuff > (2) it crashes with your DIB engine ;-) uhmmmmm.... see later, I'm afraid you didn't use the last posted engine... > > There is currently a bug that makes the 'native' skin for Opera hard > to use because many widgets fail to display properly (invisible or > totally black: http://bugs.winehq.org/show_bug.cgi?id=18553 ). Also > the rendering of some Flash stuff is considerably buggy. > quite interesting and a good testfield. As I'm restructurating a bit the code to solve the last 2 non conformity on testsuite, I guess I'll check it shortly :-) > I was hoping to test Opera with your DIB engine to see if it works, > and I came across this crash as soon as I tried rendering a webpage: > > =>0 0x7ee242c0 _CheckNotSysLevel+0x40(lock=0x7eaf8780) [/sources/wine/dlls/kernel32/../../include/winternl.h:1976] in kernel32 (0x0032e820) > 1 0x7eac7020 GDI_CheckNotLock+0x20() [/sources/wine/dlls/gdi32/gdiobj.c:743] in gdi32 (0x0032e830) > 2 0x7ea9c7f9 CreateCompatibleDC+0x19(hdc=(nil)) [/sources/wine/dlls/gdi32/dc.c:749] in gdi32 (0x0032e870) > 3 0x7e8c4b2c _DIBDRVBITMAP_InitFromHBITMAP+0x24c(bmp=0x32e9b4, hbmp=<register EDI not in topmost frame>, copyPixels=0) [/sources/wine/dlls/winedib.drv/dibdrvbitmap.c:421] in winedib (0x0032e910) > 4 0x7e8c257d DIBDRV_SetDIBits+0x1ed(physDev=0x19f478, hbitmap=<register EDI not in topmost frame>, startscan=<register ESI not in topmost frame>, lines=7, bits=0x67f97100, info=0x180528, coloruse=0) [/sources/wine/dlls/winedib.drv/dib.c:385] in winedib (0x0032ea60) > 5 0x7ea9ec54 SetDIBits+0xf4(hdc=0x6138, hbitmap=0x6148, startscan=0, lines=7, bits=0x67f97100, info=0x180528, coloruse=0) [/sources/wine/dlls/gdi32/dib.c:361] in gdi32 (0x0032eaa0) > 6 0x7eaa05a3 StretchDIBits+0x233(hdc=0x6124, xDst=0, yDst=0, widthDst=7, heightDst=7, xSrc=0, ySrc=0, widthSrc=7, heightSrc=7, bits=0x67f97100, info=<register EDI not in topmost frame>, wUsage=0, dwRop=13369376) [/sources/wine/dlls/gdi32/dib.c:295] in gdi32 (0x0032eb20) > 7 0x7eb5255b LoadImageW+0x88b(hinst=0x67830000, name=0x67f637f0, type=0, desiredx=7, desiredy=7, loadflags=8193) [/sources/wine/dlls/user32/cursoricon.c:2471] in user32 (0x0032ec40) > 8 0x67b60b57 in opera (+0x330b57) (0x0032ecc4) That's the problem I'm solving with restructuration. In short, using GetDIBits and SetDIBits with a DIB bitmap instead a DDB (as I believed was the only usage for it....) I ran into problem of getting DIB color table. GetDIBColorTable() is useless because it needs the bimpap to be selected on a DC, which is the opposite requirement for Get/SetDIBits; I can't create a temporary DC from inside them because of the SysLevel error you ran into. I obviously can't also use GedDIBits to get the color table (!).... So I removed for the moment DIB handling from both function, and I'm coding the true solution, which is somehow complicated but almost done. In short, if you're interested, the solution is to keep a linked list of HBITMAP <--> Physical bitmap for all DIBs, which allow accessing color table and other useful stuffs without resorting to GDI, which should be faster and less problem-prone. I'll post the code in few days. For then, I guess ALL non-conformities to test suite will be solved. Ciao Max

May 21, 2009

Re: DIB Engine - Mostly fixed against test suite

by Giuseppe Bilotta

On Wednesday 20 May 2009 00:13, Massimo Del Fedele wrote: > Well, it seems that the engine fixes some unrelated bugs too :-) > Bugs 15146 and 10408, as reported by a tester. > > BTW In a couple of weeks all (few) remaining failing tests should be fixed. > Then I'll try to optimize somehow the mixed blitting, which is the only > stuff that remains slower than original. > > Then, last but not least, I guess I'll setup a machine for weekly packaging > for ubuntu.... many people are asking me for autocad usage. I've started testing your patches (btw, the 9th patch in your series is missing the 0009- prefix although the 'series' file claims it should have; also, it's a real pity that git am doesn't accept stgit patches 8-/ but anyway, that's off topic). An application that you might want to test your DIB engine against is Opera. Although there IS an Opera for Linux, the 64-bit Flash plugin has some subtle network bugs, and there is no Shockwave plugin at all, so it is still necessary for me to use Opera for Windows under Wine in a few cases. Opera is a good test for your DIB engine because (1) it has problems with the current GDI32 stuff (2) it crashes with your DIB engine ;-) There is currently a bug that makes the 'native' skin for Opera hard to use because many widgets fail to display properly (invisible or totally black: http://bugs.winehq.org/show_bug.cgi?id=18553 ). Also the rendering of some Flash stuff is considerably buggy. I was hoping to test Opera with your DIB engine to see if it works, and I came across this crash as soon as I tried rendering a webpage: =>0 0x7ee242c0 _CheckNotSysLevel+0x40(lock=0x7eaf8780) [/sources/wine/dlls/kernel32/../../include/winternl.h:1976] in kernel32 (0x0032e820) 1 0x7eac7020 GDI_CheckNotLock+0x20() [/sources/wine/dlls/gdi32/gdiobj.c:743] in gdi32 (0x0032e830) 2 0x7ea9c7f9 CreateCompatibleDC+0x19(hdc=(nil)) [/sources/wine/dlls/gdi32/dc.c:749] in gdi32 (0x0032e870) 3 0x7e8c4b2c _DIBDRVBITMAP_InitFromHBITMAP+0x24c(bmp=0x32e9b4, hbmp=<register EDI not in topmost frame>, copyPixels=0) [/sources/wine/dlls/winedib.drv/dibdrvbitmap.c:421] in winedib (0x0032e910) 4 0x7e8c257d DIBDRV_SetDIBits+0x1ed(physDev=0x19f478, hbitmap=<register EDI not in topmost frame>, startscan=<register ESI not in topmost frame>, lines=7, bits=0x67f97100, info=0x180528, coloruse=0) [/sources/wine/dlls/winedib.drv/dib.c:385] in winedib (0x0032ea60) 5 0x7ea9ec54 SetDIBits+0xf4(hdc=0x6138, hbitmap=0x6148, startscan=0, lines=7, bits=0x67f97100, info=0x180528, coloruse=0) [/sources/wine/dlls/gdi32/dib.c:361] in gdi32 (0x0032eaa0) 6 0x7eaa05a3 StretchDIBits+0x233(hdc=0x6124, xDst=0, yDst=0, widthDst=7, heightDst=7, xSrc=0, ySrc=0, widthSrc=7, heightSrc=7, bits=0x67f97100, info=<register EDI not in topmost frame>, wUsage=0, dwRop=13369376) [/sources/wine/dlls/gdi32/dib.c:295] in gdi32 (0x0032eb20) 7 0x7eb5255b LoadImageW+0x88b(hinst=0x67830000, name=0x67f637f0, type=0, desiredx=7, desiredy=7, loadflags=8193) [/sources/wine/dlls/user32/cursoricon.c:2471] in user32 (0x0032ec40) 8 0x67b60b57 in opera (+0x330b57) (0x0032ecc4) I will try looking further into this, and provide any additional info I can find. -- Giuseppe "Oblomov" Bilotta

May 21, 2009

Re: shell32: for FO_COPY, if the destination is an empty string, SHFileOperation should use the current directory.

by Lionel Debroux

Alexandre Julliard wrote: > lionel_debroux(a)yahoo.fr writes: > >> @@ -1179,6 +1181,15 @@ static HRESULT copy_files(FILE_OPERATION *op, const FILE_LIST *flFrom, FILE_LIST >> const FILE_ENTRY *entryToCopy; >> const FILE_ENTRY *fileDest = &flTo->feFiles[0]; >> >> + /* If the destination is empty, SHFileOperation should use the current directory */ >> + if (!fileDest) >> + { >> + WCHAR currd[MAX_PATH]; >> + GetCurrentDirectoryW(MAX_PATH, currd); >> + parse_file_list(flTo, currd); >> + fileDest = &flTo->feFiles[0]; >> + } > > This can't possibly work. parse_file_list requires a null-terminated > list, and you will be overwriting the previous data. Well, AFAICS, there is no previous data in flTo, because of the early abort upon empty path in parse_file_list(): if (!szFiles[0]) return ERROR_ACCESS_DENIED; right before flList->feFiles = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, flList->num_alloc*sizeof(FILE_ENTRY)); I checked it by adding a trace to the early exit of destroy_file_list(): if (!flList || !flList->feFiles) and calling destroy_file_list() before the call to parse_file_list() in copy_files() added by the patch. I've updated the patch to add more comments and to check whether the destination file name is empty, instead of checking flTo->feFiles against NULL, though that should be equivalent due to ZeroMemory(&flTo, sizeof(FILE_LIST)); in SHFileOperationW. Is this try2 closer to the correct way of doing things ? Lionel.

May 21, 2009

Re: shell32: for FO_COPY, if the destination is an empty string, SHFileOperation should use the current directory.

by Alexandre Julliard

lionel_debroux(a)yahoo.fr writes: > @@ -1179,6 +1181,15 @@ static HRESULT copy_files(FILE_OPERATION *op, const FILE_LIST *flFrom, FILE_LIST > const FILE_ENTRY *entryToCopy; > const FILE_ENTRY *fileDest = &flTo->feFiles[0]; > > + /* If the destination is empty, SHFileOperation should use the current directory */ > + if (!fileDest) > + { > + WCHAR currd[MAX_PATH]; > + GetCurrentDirectoryW(MAX_PATH, currd); > + parse_file_list(flTo, currd); > + fileDest = &flTo->feFiles[0]; > + } This can't possibly work. parse_file_list requires a null-terminated list, and you will be overwriting the previous data. This needs more thought. -- Alexandre Julliard julliard(a)winehq.org

May 21, 2009

Re: Entry point not found for GetDiskInfoA (wininet_crosstest.exe)

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > Using that executable on Windows or Wine is not possible > (Entry point not found for GetDiskInfoA) > > The wininet_test.exe on winehq has an ordinal Import of 102 in that > place. > > How can we fix that? You have to use the Wine import libs, not the Mingw ones. -- Alexandre Julliard julliard(a)winehq.org

May 21, 2009

Mac OS X Joystick problem

by Nathan Gray

Hi all, I was happy to see that you recently added support for joysticks in OS X. (As you may or may not recall, I started to work on that problem a while back but never found time to finish it.) In any case, I was disappointed to find that my MS Sidewinder Precision Pro (USB) still doesn't work in the two games I tried -- The IL-2 Sturmovik demo and the Descent Freespace demo. The joystick seems not to be detected at all, from what I can tell. I filed a bug a while back in bugzilla[1] but it doesn't seem to have gotten any attention. Does the joystick code work for other people? Does it require any special configuration? I'm using Mike Kronenberg's 1.1.20 build. Thanks, -n8 [1] http://bugs.winehq.org/show_bug.cgi?id=18424 -- http://n8gray.org

May 21, 2009

Re: Bugzilla upgrade - opening attachments in browser

by Max Kanat-Alexander

Hey Jeremy. The allow_attachment_display parameter has a detailed description that notes that you are opening a security hole if you set it without setting another parameter (which you haven't set). Did you read the description of the parameter? -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too.

May 20, 2009

Re: Need help writing test

by Igor Tarasov

Hi! I still need help on this case, any advice is appreciated. 2009/4/25 Igor Tarasov <tarasov.igor(a)gmail.com>: > Hi! > > I've found few visual glitches in comctl32/toolbar, and now try to > write this all down as conformance tests, but I have some problems. I > see that there is bug, when I test it with control spy. But when I > repeat it in testcase, it won't work. Here is how you can reproduce > it: > > TB_SETBITMAPSIZE 20,20 > TB_SETBUTTONSIZE 30,30 > TB_SETBITMAPSIZE 10,10 > > Now, if you do TB_SETBUTTONSIZE, you'll see the difference. builtin > comctl will return 17,16. Native - 30,16. But when I write something > like this: > > rebuild_toolbar_with_buttons(&hToolbar); > himl = ImageList_LoadImage(GetModuleHandle(NULL), > MAKEINTRESOURCE(IDB_BITMAP_80x15), 20, 2, CLR_NONE, IMAGE_BITMAP, > LR_DEFAULTCOLOR); > ok(SendMessageA(hToolbar, TB_SETIMAGELIST, 0, (LRESULT)himl) == 0, > "TB_SETIMAGELIST failed\n"); > SendMessageA(hToolbar, TB_SETBITMAPSIZE, 0, MAKELONG(20, 20)); > SendMessageA(hToolbar, TB_SETBUTTONSIZE, 0, MAKELONG(30, 30)); > ok(SendMessageA(hToolbar, TB_GETBUTTONSIZE, 0, 0) == MAKELONG(30, > 30), "Unexpected button size\n"); > SendMessageA(hToolbar, TB_SETBITMAPSIZE, 0, MAKELONG(10, 10)); > compare((int)SendMessageA(hToolbar, TB_GETBUTTONSIZE, 0, 0), > MAKELONG(30, 16), "%x"); > > This test fails, when I test it with native comctl32 (the size is > 17,16). Why could this happen or what am I doing wrong? -- Igor

May 20, 2009

Re: gdiplus: implement partially transparent solid fill brushes

by Vincent Povirk

Don't commit this one. I forgot to pre-multiply the alpha. Vincent Povirk On Wed, May 20, 2009 at 11:33 AM, Vincent Povirk <vincent(a)codeweavers.com> wrote: > > > >

May 20, 2009

Re: Change BITS_IBackgroundCopyJob_SetPriority to a stub so the EvE-Online patcher works.

by Ricardo Filipe

2009/5/20 Tim Wright <timw(a)splhi.com> > The EvE-online updater blows up because it's trying to set the download > priority in BITS (qmgr) and that isn't implemented. Simply stubbing it to > return S_OK is sufficient to allow it to work. > > Third attempt at sending. For some reason, it isn't being posted from > git-send-email even though the Cc: arrives just fine at another account. > Patch against git repository. This is bug 18528/12312. > > > > --- > dlls/qmgr/job.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/qmgr/job.c b/dlls/qmgr/job.c > index 3baa893..09693a3 100644 > --- a/dlls/qmgr/job.c > +++ b/dlls/qmgr/job.c > @@ -334,8 +334,8 @@ static HRESULT WINAPI > BITS_IBackgroundCopyJob_SetPriority( > IBackgroundCopyJob2 *iface, > BG_JOB_PRIORITY Val) > { > - FIXME("Not implemented\n"); > - return E_NOTIMPL; > + FIXME("(%p,0x%08x) stub\n", iface, Val); > + return S_OK; > } > > static HRESULT WINAPI BITS_IBackgroundCopyJob_GetPriority( > -- > 1.6.0.4 > > > > > your previous patch was already commited. check git page the next day when you send patches. http://source.winehq.org/git/wine.git/?a=commit;h=cb26244adb4e15ab60e4d02b5… ;)

May 20, 2009

Entry point not found for GetDiskInfoA (wininet_crosstest.exe)

by Detlef Riekenberg

In "dlls/wininet/tests/urlcache.c", GetDiskInfoA is called, but wininet.dll (native and wine) export this function only by ordinal. When I build the crosstest, my mingw [i586-mingw32msvc-gcc (GCC) 4.2.1-sjlj (mingw32-2)] creates a named Import for GetDiskInfoA with an ordinal hint of 65. Using that executable on Windows or Wine is not possible (Entry point not found for GetDiskInfoA) The wininet_test.exe on winehq has an ordinal Import of 102 in that place. How can we fix that? (My patch to use an ordinal import in the test was dropped: http://www.winehq.org/pipermail/wine-patches/2009-May/073130.html ) -- By by ... Detlef

May 20, 2009

Re: Bugzilla upgrade - opening attachments in browser

by Jeremy Newman

OK, it is now enabled. -Newman Austin English wrote: > On Wed, May 20, 2009 at 6:05 AM, Igor Tarasov <tarasov.igor(a)gmail.com> wrote: >> attachment.cgi shows that it relies on allow_attachment_display >> parameter in bugzilla configuration. It has to be set to true. >> >> -- >> Igor >> > > Can a bugzilla admin please enable this? >

May 20, 2009

Re: Bugzilla upgrade - opening attachments in browser

by Austin English

On Wed, May 20, 2009 at 6:05 AM, Igor Tarasov <tarasov.igor(a)gmail.com> wrote: > attachment.cgi shows that it relies on allow_attachment_display > parameter in bugzilla configuration. It has to be set to true. > > -- > Igor > Can a bugzilla admin please enable this? -- -Austin

May 20, 2009

Re: [PATCH] Add missing classes for DOMDocument in msxml, and add test-cases back it up.

by Austin English

On Tue, May 19, 2009 at 3:07 PM, Judy Devyak <judycarol(a)ameritech.net> wrote: > > > > You forgot the patch. -- -Austin

May 20, 2009

Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3

by Austin English

On Wed, May 20, 2009 at 4:46 AM, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > On Tue, May 19, 2009 at 6:41 PM, Mike Kronenberg > <mike.kronenberg(a)kronenberg.org> wrote: >> On 18.05.2009, at 06:56, Dmitry Timoshkov wrote: >> >>> "James McKenzie" <jjmckenzie51(a)earthlink.net> wrote: >>> >>>> Austin: >>>> Contact Mike Kronenberg or Zach Drayer and see what they currently >>>> have. >>> >>> IMHO since they haven't even bothered so far to change the license from >>> GPL to LGPL to match Wine, and clarify what exactly is so much different >>> in their builds so that they insist on different naming (Darwine vs. >>> Wine), >>> they shouldn't be even considered as partners to the Wine project. >>> >>> If we could have our own Wine builds for Intel Macs, that would finally >>> help to avoid this confusion Darwine adds, and remove it from our Wiki >>> altogether (since it's apparently where the users coming to them from). >>> >>> -- >>> Dmitry. >>> >>> >> >> >> >> Hi, >> >> (I hope I did not double-post, but somehow my mail from yesterday was eaten >> by filter-gnomes) >> >> It's not about being willing to, but plain lack of time. >> I follow this list closely and work on solutions as time permits. >> After half a year, it's been four weeks now that I am able again to build >> and test on a regular base again. >> >> There are other components on OS X that need some love, like the >> winehelper.app into which I'm looking atm. >> >> License and renaming is definitely on the list. >> I thought to revamp the package, once the winehelper is replaced, to not >> double do the work. >> >> As already mentioned, I build the dependencies and store them inside the >> apple .app package, which allows for drag'n'drop installation and removal. >> >> Having the dependencies as frameworks would be even better, as there is a >> lot of trouble with PATHS, especially if multiple environments are on the >> system, like fink and macports. >> >> But if the name-change is the most pressing issue, I will gladly do that >> with this weekends release. >> >> Mike Kronenberg >> >> >> > > Could you also upload some docs / scripts on how to build 'DarWine' > from scratch? I have an app which I need to run on osx which I like to > package as well. I have time to help fixing osx issues (duplicating > the effort is not worth it). > > Roderick > > > It's available under 'build env': http://www.kronenberg.org/darwine/buildenv-1.1.5.zip -- -Austin

May 20, 2009

Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3

by Roderick Colenbrander

On Tue, May 19, 2009 at 6:41 PM, Mike Kronenberg <mike.kronenberg(a)kronenberg.org> wrote: > On 18.05.2009, at 06:56, Dmitry Timoshkov wrote: > >> "James McKenzie" <jjmckenzie51(a)earthlink.net> wrote: >> >>> Austin: >>> Contact Mike Kronenberg or Zach Drayer and see what they currently >>> have. >> >> IMHO since they haven't even bothered so far to change the license from >> GPL to LGPL to match Wine, and clarify what exactly is so much different >> in their builds so that they insist on different naming (Darwine vs. >> Wine), >> they shouldn't be even considered as partners to the Wine project. >> >> If we could have our own Wine builds for Intel Macs, that would finally >> help to avoid this confusion Darwine adds, and remove it from our Wiki >> altogether (since it's apparently where the users coming to them from). >> >> -- >> Dmitry. >> >> > > > > Hi, > > (I hope I did not double-post, but somehow my mail from yesterday was eaten > by filter-gnomes) > > It's not about being willing to, but plain lack of time. > I follow this list closely and work on solutions as time permits. > After half a year, it's been four weeks now that I am able again to build > and test on a regular base again. > > There are other components on OS X that need some love, like the > winehelper.app into which I'm looking atm. > > License and renaming is definitely on the list. > I thought to revamp the package, once the winehelper is replaced, to not > double do the work. > > As already mentioned, I build the dependencies and store them inside the > apple .app package, which allows for drag'n'drop installation and removal. > > Having the dependencies as frameworks would be even better, as there is a > lot of trouble with PATHS, especially if multiple environments are on the > system, like fink and macports. > > But if the name-change is the most pressing issue, I will gladly do that > with this weekends release. > > Mike Kronenberg > > > Could you also upload some docs / scripts on how to build 'DarWine' from scratch? I have an app which I need to run on osx which I like to package as well. I have time to help fixing osx issues (duplicating the effort is not worth it). Roderick

May 20, 2009

Re: [PATCH 7/8] urlmon: Added MIME filter handling in BindProtocol tests.

by Jacek Caban

Hi Paul, Paul Vriens wrote: > Jacek Caban wrote: >> --- >> dlls/urlmon/tests/protocol.c | 723 >> +++++++++++++++++++++++++++++++++++------- >> 1 files changed, 608 insertions(+), 115 deletions(-) >> >> >> >> ------------------------------------------------------------------------ >> >> > Hi Jacek, > > This introduces extra failures on what seems to be mostly on IE7 and > higher; see test.winehq.org. > > Could you have a look? Thanks for notification, I will send patches to fix them later today. Jacek

May 20, 2009

malloc() use in rpcrt4/tests/server.c

by Francois Gouget

Is there a specific reason for using malloc() in these tests? Testing that rpcrt4 does not assume HeapAlloc pointers? (but why would it even care?) Here are the relevant lines: in midl_user_allocate(): dlls/rpcrt4/tests/server.c:56: use HeapXxx(): return malloc(n); in array_tests(): dlls/rpcrt4/tests/server.c:1212: use HeapXxx(): dc = malloc(FIELD_OFFSET(doub_carr_t, a[2])); dlls/rpcrt4/tests/server.c:1214: use HeapXxx(): dc->a[0] = malloc(FIELD_OFFSET(doub_carr_1_t, a[3])); dlls/rpcrt4/tests/server.c:1219: use HeapXxx(): dc->a[1] = malloc(FIELD_OFFSET(doub_carr_1_t, a[2])); -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

May 20, 2009

Re: [PATCH] winhttp: avoid NULL ptr dereference (Coverity 927)

by Marcus Meissner

On Tue, May 19, 2009 at 01:46:31PM +0200, Paul Vriens wrote: > Marcus Meissner wrote: >> +lend2: >> TRACE("%d <--\n", bSuccess); >> return bSuccess; >> } > Hi Marcus, > > After AJ's remark you marked this Coverity one as "lpwhr can not be NULL". > Should we thus delete the "NULL == lpwhr" altogether? Yes, I just sent a patch doing this. Ciao, Marcus

May 20, 2009

RE: Bugzilla upgrade - opening attachments in browser

by Nicklas Börjesson

> It seems the bugzilla upgrade stopped allowing opening attachments in > browser. I can comfirm this on several platforms and browsers. //Nicklas

May 20, 2009

Bugzilla upgrade - opening attachments in browser

by Austin English

It seems the bugzilla upgrade stopped allowing opening attachments in browser. Not sure if that's by choice or just an unchanged setting, but having to open .txt/.jpeg/.png files in outside applications is a bit annoying...Any possibility of fixing that? -- -Austin

May 20, 2009

user32: improvements

by Daniel Santos

In the process of working on this bug (http://bugs.winehq.org/show_bug.cgi?id=18371) I have discovered that user32's SetCursor function does not ensure that the the handle passed is valid or that it is even a handle to a cursor object (and it seems that the lingo for user32 objects is "resources"). The root cause of this problem is that the app attempts to use a cursor after it already destroyed it. At first, this just causes the cursor to be blank. Then, it would appear that the handle is re-used for a different type of resource, which leads to the gibberish image & subsequent hang. When this app runs on windows, I presume that the SetCursor calls just fail and the app resumes harmlessly ignoring the failure (or correcting it, either way). In general, this flaw will affect applications which use the user32 api irresponsibly, and I'm certain that a great number of windows apps out there, to some extent, do. My 1st step is to write some tests that illustrate/prove this problem (and that it works on windows) and I'm building the tests now so I can start on that. However, I've been reading up and considering how to implement a solution. I presume that this problem affects every user32 handle & function related to them, but I have only thoroughly examined mousecursor.c, so please forgive any incorrect assumptions I still have at this point (and let me know if I'm way off!). There was a quaint MSDN article on how the windows GDI32 dll manages GDI objects that even gave the internal structure, etc. (http://msdn.microsoft.com/en-us/magazine/cc188782.aspx) Although this only covers gdi32, I'm getting the idea that what needs to happen in user32 isn't too much different. Essentially, it would seem that user32 needs to associate a handle with a type and it would *appear* at this point that would be sufficient. However, I need to gain a better understanding of the nuisances of user32 objects.. From reading this ms kb article (http://support.microsoft.com/kb/184802) it seems that the windows user32 maintains 3 different types of heaps, a global one, one for each desktop and a different (differently sized?) one for non-interactive desktops. Windows' "global heap" is where user32 stores it's handle table, presumably which, simply associates a kernel32 handle with appropriate information for user32 objects, similar to the way GDI does (as illustrated in the above referenced MSDN article). Thus, if you create a thread, it can never have the same handle value as a cursor, icon, etc. So I'm going to write my tests on my windows machine, starting with only the mousecursor.c stuff because there appears to be quite a lot of ground to cover. If anybody has any feedback, corrections to anything I've said, etc. please do reply. Daniel

May 20, 2009

Re: DIB Engine - Mostly fixed against test suite

by Massimo Del Fedele

Well, it seems that the engine fixes some unrelated bugs too :-) Bugs 15146 and 10408, as reported by a tester. BTW In a couple of weeks all (few) remaining failing tests should be fixed. Then I'll try to optimize somehow the mixed blitting, which is the only stuff that remains slower than original. Then, last but not least, I guess I'll setup a machine for weekly packaging for ubuntu.... many people are asking me for autocad usage. Ciao Max

May 19, 2009

Re: Detecting an invalid handle in setupapi

by Daniel Santos

oops, I meant to reply-all on this. --- On Mon, 5/18/09, Daniel Santos <javatroubadour(a)yahoo.com> wrote: From: Daniel Santos <javatroubadour(a)yahoo.com> Subject: Re: Detecting an invalid handle in setupapi To: "Paul Vriens" <paul.vriens.wine(a)gmail.com> Date: Monday, May 18, 2009, 5:43 PM I'm so very glad you brought this up Paul. I'm new to wine development and I've been working on Lord of the Rings Online issues and I have discovered and validated that the root cause of two of my problems are related (http://bugs.winehq.org/show_bug.cgi?id=18371) There are numerous places in Wine where the validity of handles are not checked. If the handle turns out to be invalid, then a NULL pointer is simply passed instead (which sometimes has an alternate meaning). Worse yet, in the code I was working with (dlls/kernel32/global16.c) the type of object the handle refers to is not stored! I see this as a critical flaw in Wine and I hope I can come up with a viable solution. I'm planning on setting up some test programs to examine the bit-data of some windows objects (starting with user32 -- where my issue lies) as any solution will have to be bit-compatibile with windows since apps like paint shop pro de-reference handles and examine the data of the underlying objects. In truth, if the LOTRO app didn't destroy objects it was still using and then try to use them, the problem wouldn't exist -- this part of wine will work perfectly if the app behaved responsibly. But development timelines and pressures frequently lead to code that works, but is incorrect and is a part of reality. Daniel --- On Sat, 5/16/09, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: From: Paul Vriens <paul.vriens.wine(a)gmail.com> Subject: Detecting an invalid handle in setupapi To: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> Date: Saturday, May 16, 2009, 12:18 PM Hi, I'm trying to install Microsoft's MMC (W2K3) and it crashes every now and then with different symptoms. I've tracked it down to what I think is a fault in the application that triggers a bug in Wine. All inf files that are read are closed with SetupCloseInfFile but the app is still trying to use the handle in a call to SetupFindFirstLineA. On Windows (tested on W2K3) this will lead to a failure of SetupFindFirstLineA with a last error of ERROR_INVALID_HANDLE. On Wine we don't check the handle and thus the outcome cannot be predicted (mostly crash). What ways do we have to detect invalid handles or better yet how can this be solved? -- Cheers, Paul.

May 19, 2009

Re: [PATCH 7/8] urlmon: Added MIME filter handling in BindProtocol tests.

by Paul Vriens

Jacek Caban wrote: > --- > dlls/urlmon/tests/protocol.c | 723 > +++++++++++++++++++++++++++++++++++------- > 1 files changed, 608 insertions(+), 115 deletions(-) > > > > ------------------------------------------------------------------------ > > Hi Jacek, This introduces extra failures on what seems to be mostly on IE7 and higher; see test.winehq.org. Could you have a look? -- Cheers, Paul.

May 19, 2009

Re: winemaker: add include-directory parsing

by Paul Vriens

André Hentschel wrote: > --- > tools/winemaker | 7 +++++-- > 1 files changed, 5 insertions(+), 2 deletions(-) > > > > ------------------------------------------------------------------------ > > Hi André, Not a comment on the patch itself but this is the third time you tried with the same patch. We usually add a 'resend' to the subject of a patch that is, uuh resend. If it's another revision we add 'try x'. In your case you should probably ask (on wine-devel) for comments or contact AJ directly on irc. -- Cheers, Paul.

May 19, 2009

Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3

by Mike Kronenberg

On 18.05.2009, at 06:56, Dmitry Timoshkov wrote: > "James McKenzie" <jjmckenzie51(a)earthlink.net> wrote: > >> Austin: >> Contact Mike Kronenberg or Zach Drayer and see what they currently >> have. > > IMHO since they haven't even bothered so far to change the license > from > GPL to LGPL to match Wine, and clarify what exactly is so much > different > in their builds so that they insist on different naming (Darwine vs. > Wine), > they shouldn't be even considered as partners to the Wine project. > > If we could have our own Wine builds for Intel Macs, that would > finally > help to avoid this confusion Darwine adds, and remove it from our Wiki > altogether (since it's apparently where the users coming to them > from). > > -- > Dmitry. > > Hi, (I hope I did not double-post, but somehow my mail from yesterday was eaten by filter-gnomes) It's not about being willing to, but plain lack of time. I follow this list closely and work on solutions as time permits. After half a year, it's been four weeks now that I am able again to build and test on a regular base again. There are other components on OS X that need some love, like the winehelper.app into which I'm looking atm. License and renaming is definitely on the list. I thought to revamp the package, once the winehelper is replaced, to not double do the work. As already mentioned, I build the dependencies and store them inside the apple .app package, which allows for drag'n'drop installation and removal. Having the dependencies as frameworks would be even better, as there is a lot of trouble with PATHS, especially if multiple environments are on the system, like fink and macports. But if the name-change is the most pressing issue, I will gladly do that with this weekends release. Mike Kronenberg

May 19, 2009

Re: [Article] WINE and the importance of application compatibility

by Austin English

On Tue, May 19, 2009 at 2:47 AM, Kai Blin <kai.blin(a)gmail.com> wrote: > That depends on being able to test a lot of applications, though. I'm working on it :-) -- -Austin

May 19, 2009

Re: Gecko installation broken?

by Austin English

On Tue, May 19, 2009 at 4:52 AM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Montag, 18. Mai 2009 22:46:59 schrieb Lei Zhang: >> It didn't think so either, so I even double checked. Upon further >> investigation, it seems the problem is simply the gecko cab download >> is failing. Either one of the Sourceforge servers is down/flaky, or >> source.winehq.org is taking too long to do the redirect and wininet >> doesn't handle that well. > That might explain why the HL2 test ran successfully yesterday, but not the > TF2 test(which does the same Gecko setup). Today both failed again. On the > other hand, it seems that the download succeeds - the progress bar runs to > the end, and the dialog box says "installing" for about a second. > > > You could always do a local install, and avoid the problem altogether http://wiki.winehq.org/Gecko. -- -Austin

May 19, 2009

Re: ntdll/tests: Mark return value of RtlUnicodeStringToInteger("", 16) as broken for nt4.

by Huw Davies

On Tue, May 19, 2009 at 03:39:07PM +0200, Alexandre Julliard wrote: > Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > > > I don't think this is correct. This test has always succeeded until > > March 9th. There haven't been any changes to the test in that period, > > but I remember an upgrade of winehq in that weekend. > > > > In other words, there is more to it. Testing a simple cross compiled > > version of this test doesn't yield an error on NT4. > > My feeling is that it's returning uninitialized data, so the results > depend on the stack layout that the compiler is using. There's probably > no sense in checking for a specific value, just consider this case > broken no matter what it returns. Ok, I'll resend without the test on the returned value. Huw.

May 19, 2009