Wine 1.0.2
Please add 1.0.2 target milestone to Bugzilla. -- -Austin
Re: Unable to add cc to bug 13583
On Wed, Oct 29, 2008 at 10:50 PM, Matt Perry <[EMAIL PROTECTED]> wrote: > I ran a regression test for bug 13583 and attempted to add the patch > author to the CC field in Bugzilla as indicated in the regression test > documentation. Unfortunately, I get the following error: > > CC: [EMAIL PROTECTED] did not match anything > > How do I get the author of the patch onto the CC list? > > Matt > > > He uses a different e-mail address for bugzilla. He's cc'ed to wine-devel, so he'll notice, no need to CC him :-). -- -Austin
Unable to add cc to bug 13583
I ran a regression test for bug 13583 and attempted to add the patch author to the CC field in Bugzilla as indicated in the regression test documentation. Unfortunately, I get the following error: CC: [EMAIL PROTECTED] did not match anything How do I get the author of the patch onto the CC list? Matt
Re: Changed more malloc to HeapAlloc calls
On Wed, Oct 29, 2008 at 8:02 PM, Pete Myers <[EMAIL PROTECTED]> wrote: > It does match the style of the way that HeapAlloc is used elsewhere in the > file, though not malloc admittedly. I wasn't sure which convention had > precedent. > Please bottom-post when replying to a post on the wine lists. There is one test function that uses a space after opening parentheses, but it's the exception, not the rule. > I'm afraid that I don't understand how my changelog doesn't match the > patch. I'm new here, can you help me out? There's obviously something I'm > missing! > You had several 'changelog' entries in the email, but the last one was Changelog: * malloc calls in dlls/kernel32/process.c have been change to HeapAlloc which does not match the patch. -- James Hawkins
Vertex pipeline replacement
Hi, I have my vertex pipeline replacement almost ready to send. Because the fragment pipeline replacement caused a bunch of regressions, I want to give this patch a bit of testing before committing it. I expect slightly more regressions there because the vertex processing stuff is still badly tested, especially lighting. Can you give the patches a try and see if your game still works? For now the most important part is that the game works without any performance loss or rendering bugs. This patchset is supposed to address the following issues: 1) Improve performance in applications that are hit hard by drawStridedSlow. I don't know if there are many left, because the vertex buffer fixups really helped here 2) Allow adding features that do not exist in the GL fixed function pipeline(or are not supported by drivers): Vertex blending, tweening, more efficient material tracking, per-vertex point size 3) Make the way towards OpenGL 3 forward compatibility mode So far (1) should already go some way with these patches. There are no new features added yet, and opengl 3 needs the same stuff implemented with GLSL and further work, but this is a necessary start. Once these patches are in, I'll turn to fine-tuning things. The rhw handling can be done better(maybe), and vertex buffer loading can be made much cheaper if the pipeline replacement is in use and opengl supports native 16 bit vertex attributes. This should get old card compatibility costs off our backs when we're running on a modern GPU without sacrificing backward compatibility.
Re: Changed more malloc to HeapAlloc calls
On Wed, Oct 29, 2008 at 7:39 PM, Pete Myers <[EMAIL PROTECTED]> wrote: > In line with http://wiki.winehq.org/ReplaceMalloc this is a small patch that > changes all malloc calls to HeapAlloc in the following files: > ./dlls/iphlpapi/tests/iphlpapi.c > ./dlls/wnaspi32/winaspi16.c > > Changelog: > * malloc calls in dlls/kernel32/process.c have been change to HeapAlloc > Your changelog (right above) doesn't match the patch, and - PMIB_IPADDRTABLE buf = (PMIB_IPADDRTABLE)malloc(dwSize); + PMIB_IPADDRTABLE buf = (PMIB_IPADDRTABLE)HeapAlloc( GetProcessHeap(), 0, dwSize); You've introduced a space after opening parentheses which does not match the style of the rest of the file. -- James Hawkins
Re: does anyone else's windows 98 machine not survive the user32 msg test?
On So, 2008-10-26 at 22:31 -0500, Vincent Povirk wrote: > After I run "user32_crosstest msg" on my windows 98 virtual machine in > qemu, it no longer responds to any mouse input (the cursor moves and > changes, but clicking has no effect) > > Does this happen to anyone else, especially on a windows 98 machine > not running in qemu? winetest on win98se on real hardware. Alt-Tab is needed to close the msg-box from the crashing tests, and most times, a deadlook follows, with checkdsk after the reboot -- By by ... Detlef
Re: BUG 15833: TreeView control don't save item's state
On Wed, Oct 29, 2008 at 6:50 AM, warmouse <[EMAIL PROTECTED]> wrote: > Hi. > > BUG: > TreeView sends TVS_GETDISPINFO notifycation. Main application catch it and > change "mask","state" and "stateMask" in a TVITEM structure. After returning > > from message handler, item's state don't changed. TreeView don't save new > item > state in function TREEVIEW_UpdateDispInfo after calling > TREEVIEW_SendRealNotify. > Hey, Any patch needs the authors real name with it. Also probably a test case showing the behavior implemented by your patch would be nice as well. Cheers, --John Klehm
Re: [try 2] [2/2] mlang: Add implementation offnIMLangFontLink_GetCharCodePages
"Vitaly Perov" <[EMAIL PROTECTED]> wrote: > "Vitaly Perov" <[EMAIL PROTECTED]> wrote: > >>> It doesn't really matter what code pages Windows supports, it does >>> matter though what code pages are valid. You need to use Win32 APIs >>> EnumSystemCodePages/GetCPInfo/MultiByteToWideChar instead of accessing >>> Wine internals directly. > >>I used EnumSystemCodePages before, but in this case GetCharCodePages set some >>extra bits in result. So the result differ from Windows I can't read your mind or guess what those "some extra bits" are. Why can't you mark the failing tests with todo_wine and think later how to make the tests pass? >>> ... or rather use mlang internal mlang_data structures. > >>I's good idea! Thank you! > > So, I use mlang_data[i].family_codepage as you adviced. > May be I misunderstood something? Have you tried to do what I suggested? Also you either need to send the test after the implementation, or add todo_wine in appropriate places and remove them in the patch which makes the tests pass. -- Dmitry.
Re: [try 2] [2/2] mlang: Add implementation offnIMLangFontLink_GetCharCodePages
"Vitaly Perov" <[EMAIL PROTECTED]> wrote: >> It doesn't really matter what code pages Windows supports, it does >> matter though what code pages are valid. You need to use Win32 APIs >> EnumSystemCodePages/GetCPInfo/MultiByteToWideChar instead of accessing >> Wine internals directly. >I used EnumSystemCodePages before, but in this case GetCharCodePages set some >extra bits in result. So the result differ from Windows >> ... or rather use mlang internal mlang_data structures. >I's good idea! Thank you! So, I use mlang_data[i].family_codepage as you adviced. May be I misunderstood something? -- Best wishes, Vitaly Perov Russia, Saint-Petersburg. www.etersoft.ru
Re: [try 2] [2/2] mlang: Add implementation offnIMLangFontLink_GetCharCodePages
"Vitaly Perov" <[EMAIL PROTECTED]> wrote: > Changed since last send: use mlang internal mlang_data structures instead of > static array. You still haven't done the other part: use Win32 APIs EnumSystemCodePages/ GetCPInfo/WideCharToMultiByte instead of accessing Wine internals directly. -- Dmitry.
Re: [PATCH] [1/19] paint: basic paint program
> "Hirofumi Katayama" <[EMAIL PROTECTED]> writes: > > > From ee02c7995d6dcaf490f8f90b8d37ebc6b08f733e Mon Sep 17 00:00:00 2001 > > From: Katayama Hirofumi MZ <[EMAIL PROTECTED]> > > Date: Sat, 25 Oct 2008 10:55:17 +0900 > > Subject: [PATCH] [1/19] paint: basic paint program > > The program should probably be called mspaint.exe if it's supposed to be > a replacement for the Windows one. Also you can't copy the toolbar icons > from the original, you need to draw your own. > > -- > Alexandre Julliard > [EMAIL PROTECTED] > It might be a solution to use the icons from Paint.NET an open source Paint program licensed under the MIT license. It aims to improve Paint (it was originally sponsored by Microsoft). Depending on where they got their icons from it might be legal to use those instead of drawing your own. Roderick -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail
xrandr unsupported video modes [was: Re: winecfg - great job!]
On 28.10.2008 22:33, Eric Anopolsky wrote: > Thanks, but it's not a wine bug. The problem is that xrandr doesn't > think 640x480 and 800x600 are valid modes on my laptop so when I launch > Diablo II I get a dialog box that says: I guess technically it would be possible to emulate the modes. I recall that DirectDraw/Wine actually uses OpenGL as a backend, so just stretching up to a higher resolution would be trivial (though not it may not necessarily look good to everyone). Anyhow, all that should probably go into a bug report if it's perceived as an issue Wine should deal with ... -f.r. signature.asc Description: OpenPGP digital signature
Re: [PATCH] [1/19] paint: basic paint program
"Hirofumi Katayama" <[EMAIL PROTECTED]> writes: > From ee02c7995d6dcaf490f8f90b8d37ebc6b08f733e Mon Sep 17 00:00:00 2001 > From: Katayama Hirofumi MZ <[EMAIL PROTECTED]> > Date: Sat, 25 Oct 2008 10:55:17 +0900 > Subject: [PATCH] [1/19] paint: basic paint program The program should probably be called mspaint.exe if it's supposed to be a replacement for the Windows one. Also you can't copy the toolbar icons from the original, you need to draw your own. -- Alexandre Julliard [EMAIL PROTECTED]
Re: D3DXMatrixstack: where to go....
Actually, I just cleaned up your patches, and will probably submit the first few later today.
patchwatcher status: ready for volunteers to get working on bsd/solaris/mac
Blacklisted wininet:http.c because it relies on winehq.org being up and serving php properly :-) Fixed enough problems with the new patchwatcher that it seems to be running tests properly. You can see the new patchwatcher's results at http://kegel.com/wine/patchwatcher/results2/ The results should agree with the original patchwatcher, http://kegel.com/wine/patchwatcher/results/ Now I just have to get the email and web reporting smoothed out, then I can consider turning the old one off and turning on the new one's email notifications. Then it should be pretty easy to add new slave build machines to speed up the build or add new slave types (e.g. windows, valgrind, macosx, bsd, solaris). Now is a good time for bsd / macosx / solaris enthusiasts to jump in and get patchwatcher running on their favorite OS or compiler. Patches gladly accepted. If alternate platforms or compilers are working well and are worth integrating into the main patchwatcher instance, I'll do it. The code's all in svn at http://code.google.com/p/winezeug/source/browse/#svn/trunk/patchwatcher as usual. The new patchwatcher is described in readme.txt. Have fun! - Dan
D3DXMatrixstack: where to go....
I did several patches about D3DXMAtrixStack. All were uncorrect. The idea of Henri to implement it is this one: it is very time -comsumming to allocate or to free memory. So one needs to do that as less as possible. So, we start with a stack with predefined size. When the stack is full, one multiplies by 2 its size. When one releases items enough of the stack, one divides its size by 2. Here are patches that implemented that idea. When looking at your patch, I saw that in my patch, in the D3dxMatrixstackImpl_release function, I do not free the memory of the array of matrix. It should be done. In the tests patch, I did not check if d3dxmatrixstackcreate fails. If it fails, tests should be skipped. At the end of the test, I did not call the _Release function. It should be done too. Maybe, you should use these patches and try to improve them. All the tests passed on my Windows XP box. David 0001-Implement-the-basic-functions-for-MatrixStack(2).patch Description: Binary data 0005-Implement-a-few-tests-for-MatrixStack.patch Description: Binary data
