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
Wine 1.0.2
Please add 1.0.2 target milestone to Bugzilla. -- -Austin
Re: Wine 1.0.2
Why is that needed? I believe Alexandre mentioned that 1.0.1 would be the last release. Roderick Please add 1.0.2 target milestone to Bugzilla. -- -Austin -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
Re: DIrectSound on top of openAL ?
On Tue, Oct 28, 2008 at 02:16:12PM -0700, Chris Robinson wrote: It's not very easy to get DirectSound working on top of OpenAL. I actually made a DSound-OpenAL wrapper (as a native C++ Win32 DLL, so it can't go into Wine as-is even if I wanted it to), but it's none too stable. Some apps work, others don't. Some work better than others. The biggest problem is updating the sound buffer in real-time (DSound lets you lock a sound buffer and modify it while it's playing; OpenAL only lets you rebuffer the whole buffer, while it's not attached to any source). I get around this by spawning a real-time thread which queues small chunks just in time to keep the buffer playing, but this is a hack at best.. there's no way to know how much you need to buffer ahead so OpenAL doesn't run out during an update, some apps are more sensitive to a large write-ahead, and real-time threads aren't really available in Wine (meaning even larger sections would need to be queued to be able to update in time). The problem is compounded when you consider multiple DSound buffers can share the same data buffer. Another problem is the lack of panning. OpenAL has no controls for panning a 2D sound. At most you can move the sound left and right to simulate panning (for mono sources; stereo is out of luck), but the actual algorithms are implementation dependant and thus would not produce consistant results. Additionally, OpenAL hides a lot of the hardware vs. software caps. OpenAL doesn't tell you if you're using hardware or software, while DSound would tell you. Of course you can always lie and say you have hardware (which I found was needed to get some games to even attempt to use DSound3D), but it's not entirely proper. Just out of curiousity, have any of these limitations been raised with the OpenAL developers? Any of them in its future wish list? If OpenAL was updated with the next release 1.2+ to support the type of access that wine needs to support the windows sound API's on linux, would it make it easier that supporting multiple sound drivers? 1.0 was released 2000, 1.1 in 2005, so it's probably due a new release in the next year/two, so it might be possible to add some feature requests that would make implementing DirectSound on top of OpenAL visible in the future. -- Darragh Nothing is foolproof to a sufficiently talented fool.
Re: DIrectSound on top of openAL ?
On Tue, Oct 28, 2008 at 02:16:12PM -0700, Chris Robinson wrote: It's not very easy to get DirectSound working on top of OpenAL. I actually made a DSound-OpenAL wrapper (as a native C++ Win32 DLL, so it can't go into Wine as-is even if I wanted it to), but it's none too stable. Some apps work, others don't. Some work better than others. The biggest problem is updating the sound buffer in real-time (DSound lets you lock a sound buffer and modify it while it's playing; OpenAL only lets you rebuffer the whole buffer, while it's not attached to any source). I get around this by spawning a real-time thread which queues small chunks just in time to keep the buffer playing, but this is a hack at best.. there's no way to know how much you need to buffer ahead so OpenAL doesn't run out during an update, some apps are more sensitive to a large write-ahead, and real-time threads aren't really available in Wine (meaning even larger sections would need to be queued to be able to update in time). The problem is compounded when you consider multiple DSound buffers can share the same data buffer. Another problem is the lack of panning. OpenAL has no controls for panning a 2D sound. At most you can move the sound left and right to simulate panning (for mono sources; stereo is out of luck), but the actual algorithms are implementation dependant and thus would not produce consistant results. Additionally, OpenAL hides a lot of the hardware vs. software caps. OpenAL doesn't tell you if you're using hardware or software, while DSound would tell you. Of course you can always lie and say you have hardware (which I found was needed to get some games to even attempt to use DSound3D), but it's not entirely proper. Just out of curiousity, have any of these limitations been raised with the OpenAL developers? Any of them in its future wish list? If OpenAL was updated with the next release 1.2+ to support the type of access that wine needs to support the windows sound API's on linux, would it make it easier that supporting multiple sound drivers? 1.0 was released 2000, 1.1 in 2005, so it's probably due a new release in the next year/two, so it might be possible to add some feature requests that would make implementing DirectSound on top of OpenAL visible in the future. -- Darragh Nothing is foolproof to a sufficiently talented fool. The design philosophy behind OpenAL and OpenGL is to hide hardware details from the designer. For instance the libraries hide things like buffer sizes or the amount of video memory. DirectX APIs like Directsound and DirectDraw/Direct3D provide you will all sorts of hardware info which the designers of OpenAL and OpenGL should be hidden. The reasoning is that if you expose such hardware details that you end up with hardware specific codepaths and not with generic solutions which are also more future proof. Roderick -- GMX Download-Spiele: Preizsturz! Alle Puzzle-Spiele Deluxe über 60% billiger. http://games.entertainment.gmx.net/de/entertainment/games/download/puzzle/index.html
Re: DIrectSound on top of openAL ?
Actually just spotted that some of the features are approved on the wish list, so it seems that OpenAL will include them in it's next specification. On Thu, Oct 30, 2008 at 10:46:51AM +, Darragh Bailey wrote: On Tue, Oct 28, 2008 at 02:16:12PM -0700, Chris Robinson wrote: The biggest problem is updating the sound buffer in real-time (DSound lets you lock a sound buffer and modify it while it's playing; OpenAL only lets you rebuffer the whole buffer, while it's not attached to any source). I get around this by spawning a real-time thread which queues small chunks just in time to keep the buffer playing, but this is a hack at best.. there's no way to know how much you need to buffer ahead so OpenAL doesn't run out during an update, some apps are more sensitive to a large write-ahead, and real-time threads aren't really available in Wine (meaning even larger sections would need to be queued to be able to update in time). The problem is compounded when you consider multiple DSound buffers can share the same data buffer. Couldn't tell if this is on the wish list, there appears to be some suggested enhancements for better buffer control, but I don't know enough to determine whether they actually match up. Another problem is the lack of panning. OpenAL has no controls for panning a 2D sound. At most you can move the sound left and right to simulate panning (for mono sources; stereo is out of luck), but the actual algorithms are implementation dependant and thus would not produce consistant results. Requested: Item:2D panning/speaker level support Contributor: Creative Description: Approval Status: Approved Additionally, OpenAL hides a lot of the hardware vs. software caps. OpenAL doesn't tell you if you're using hardware or software, while DSound would tell you. Of course you can always lie and say you have hardware (which I found was needed to get some games to even attempt to use DSound3D), but it's not entirely proper. Looks like this has been requested too: Item: Generic Effects Contributor: Creative Description: OpenAL could have a generic mechanism for enumerating and making use of the effects capabilities of the active audio device. Approval Status: Approved 1.0 was released 2000, 1.1 in 2005, so it's probably due a new release in the next year/two, so it might be possible to add some feature requests that would make implementing DirectSound on top of OpenAL visible in the future. If all of the wish list gets added, it would appear the next specification of OpenAL would appear to me to go a long way to allowing wine to implement the Windows sound API's via that, rather than having to support various drivers. -- Darragh Nothing is foolproof to a sufficiently talented fool.
Re: [PATCH] ntdll: Don't append directory entries if the filename length is less than 1.
Lei Zhang [EMAIL PROTECTED] writes: I saw the following in a +file trace a user sent me: trace:file:FindNextFileW returning L (L) I tried fixing FindNextFileW(), but that patch didn't get accepted. I'm guessing we should fix the problem in NtQueryDirectoryFile() so nobody who call it will get back an empty file name. This should never happen. You should figure out where the empty name comes from and fix the caller. -- Alexandre Julliard [EMAIL PROTECTED]
RE: Vertex pipeline replacement
Hmm... It looks like my 2nd mail with the patch wasn't CC'ed to wine-devel -Original Message- From: [EMAIL PROTECTED] [mailto:wine-devel- [EMAIL PROTECTED] On Behalf Of Stefan Dösinger Sent: Thursday, October 30, 2008 2:02 AM To: wine-devel@winehq.org Subject: 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. arbvp.tar.bz2 Description: Binary data
Re: Changed more malloc to HeapAlloc calls
Hello Pete,
James Hawkins wrote:
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.
In addition to what James said please split the patch up; one patch per
module. A dll or program is a module.
Also while you are at it please remove the superfluous casts in the
lines you are changing. HeapAlloc (malloc too) returns a void pointer
which doesn't needs to be casted to an other pointer type. E.g.
--- a/dlls/iphlpapi/tests/iphlpapi.c
+++ b/dlls/iphlpapi/tests/iphlpapi.c
@@ -225,7 +225,7 @@ static void testGetIpAddrTable(void)
GetIpAddrTable(NULL, dwSize, FALSE) returned %d, expected
ERROR_INSUFFICIENT_BUFFER\n,
apiReturn);
if (apiReturn == ERROR_INSUFFICIENT_BUFFER) {
- PMIB_IPADDRTABLE buf = (PMIB_IPADDRTABLE)malloc(dwSize);
+ PMIB_IPADDRTABLE buf = (PMIB_IPADDRTABLE)HeapAlloc(
GetProcessHeap(), 0, dwSize);
apiReturn = gGetIpAddrTable(buf, dwSize, FALSE);
ok(apiReturn == NO_ERROR,
should really be just:
PMIB_IPADDRTABLE buf = HeapAlloc(GetProcessHeap(), 0, dwSize);
thanks
bye
michael
Re: [PATCH 1/3] fusion: Implement the IAssemblyEnum interface. [try3]
Hi James, James Hawkins wrote: --- dlls/fusion/Makefile.in |1 + dlls/fusion/asmcache.c | 83 -- dlls/fusion/asmenum.c| 385 ++ dlls/fusion/asmname.c| 15 +-- dlls/fusion/fusion.c | 12 -- dlls/fusion/fusionpriv.h | 15 ++ 6 files changed, 402 insertions(+), 109 deletions(-) create mode 100644 dlls/fusion/asmenum.c + +done: +FindClose(hfind); +return S_OK; +} + You always set hr in error paths so I guess you want to return it here. Also, it's a matter of style, but these gotos look strange. You could replace them all by break statements. Jacek
Re: mshtml: Implement IHTMLElement get_document
Hi Alistair,
Alistair Leslie-Hughes wrote:
Hi,
Changelog:
mshtml: Implement IHTMLElement get_document
+*p = NULL;
+
+if(!This-node.doc-nsdoc) {
+WARN(NULL nsdoc\n);
+return E_UNEXPECTED;
+}
You don't use nsdoc so there is no reason to test it.
+hr = IHTMLDocument2_QueryInterface(HTMLDOC(This-node.doc),
IID_IHTMLDocument, (void**)p);
+
+return hr;
You could just cast This-node.doc to IHTMLDocument and call AddRef on result.
Jacek
Re: Changed more malloc to HeapAlloc calls
Pete Myers wrote: In addition to what James said please split the patch up; one patch per module. A dll or program is a module. Sorry, I'm inundated with noobie errors here I think. No problem. Janitorial tasks are really good to accustom new people to the patch submission process. Also while you are at it please remove the superfluous casts in the lines you are changing. HeapAlloc (malloc too) returns a void pointer which doesn't needs to be casted to an other pointer type. E.g. Will do. Didn't want to change coding style. Well that's not coding style. Superfluous casts are evil. I have even created a new janitorial tasks for that: http://wiki.winehq.org/SuperfluousCasts Also if one has to touch a line it is expected from him to fix all errors in that line. That includes dangling whitespace at the end of the line and mixed tab and space indentation. Actually my big struggle at the moment is trying to figure out where malloc() memory gets free(). What's the policy here? Should Just search for free in that file. HeapAlloc() always be set free... Is the fact that some malloc() memory not free()'d an error, or a policy? Or should I work harder to You need to replace the free calls with HeapFree calls. find out where free() gets called? grep -w free dlls/iphlpapi/tests/iphlpapi.c dlls/wnaspi32/winaspi16.c That will do. bye michael
Re: DIrectSound on top of openAL ?
If all of the wish list gets added, it would appear the next specification of OpenAL would appear to me to go a long way to allowing wine to implement the Windows sound API's via that, rather than having to support various drivers. -- Darragh Personally I think that even if OpenAL added the functionality we need that the user experience for most users still won't be good. Most users want to play lets say mp3's while they are gaming. This means that in order to work properly OpenAL under the hood again needs to use alsa+dmix or even worse pulseaudio. For that reason I'm not sure if going directly to OpenAL instead of going through wineoss/winealsa is any better. Roderick -- Feel free - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail
comctl32 tree problem?
Here's an app that says they had to work around a problem in our tree control: http://www.webyog.com/blog/2008/10/30/sqlyog-712-has-been-released/
Re: Vertex pipeline replacement
Hi Stefan, I have tested this with Age of Myhology (Titans 1.03) on wine-1.1.7-106-g38815e1, patches 1-11 don't seem to cause any problems (haven't checked extensively though), but upon applying the 12th (0012-WineD3D-ARBvp-ffp-replacement.patch) the water lost it's transparency [1]. I'm not sure what other information you need, so just let me know. I'm happy to test any changes you make. Chris. [1] http://i37.tinypic.com/dcyjac.png
Present Wine at CeBit?
Anyone want to give a presentation on Wine at CeBit? http://www.linux-magazine.com/online/news/cebit_open_source_linux_magazine_and_linux_foundation_announce_call_for_projects/(kategorie)/0 If you're interested, email me privately, and I'll connect you with Britta. Cheers, Jeremy
Re: comctl32 tree problem?
On Thu, Oct 30, 2008 at 8:43 AM, Juan Lang [EMAIL PROTECTED] wrote: Here's an app that says they had to work around a problem in our tree control: http://www.webyog.com/blog/2008/10/30/sqlyog-712-has-been-released/ Maybe you could contact the developer and ask him to log a bug? Done.
Re: comctl32 tree problem?
Here's an app that says they had to work around a problem in our tree control: http://www.webyog.com/blog/2008/10/30/sqlyog-712-has-been-released/ Maybe you could contact the developer and ask him to log a bug? --Juan
RE: Vertex pipeline replacement
I have tested this with Age of Myhology (Titans 1.03) on wine-1.1.7-106-g38815e1, patches 1-11 don't seem to cause any problems (haven't checked extensively though), but upon applying the 12th (0012-WineD3D-ARBvp-ffp-replacement.patch) the water lost it's transparency [1]. Sounds as if there's a problem with texture coordinates. Can you file a bugreport and assign it to me? Please add a link to a downloadable demo if one exists
Re: rundll32: build with -mwindows
Vincent Povirk [EMAIL PROTECTED] wrote: -APPMODE = -mconsole +APPMODE = -mwindows Have you tested that it still works? I'd expect that you also need to replace main() by WinMain() and adapt command line processing. -- Dmitry.
RE: rundll32: build with -mwindows
I have tested, and it still works. I would have fully expected it to fail if I had remembered the difference between main() and WinMain(). -Original Message- From: Dmitry Timoshkov [mailto:[EMAIL PROTECTED] Sent: Thursday, October 30, 2008 11:37 AM To: Vincent Povirk Cc: WineHQ Development Mailing List Subject: Re: rundll32: build with -mwindows Vincent Povirk [EMAIL PROTECTED] wrote: -APPMODE = -mconsole +APPMODE = -mwindows Have you tested that it still works? I'd expect that you also need to replace main() by WinMain() and adapt command line processing. -- Dmitry.
Re: Fix kernel_main.c to generate console Window
2008/10/29 Dan Kegel [EMAIL PROTECTED]: Hi Slawek, Please just attach the bare patch, not a .tgz of the patch. This sounds related to http://bugs.winehq.org/show_bug.cgi?id=5541 but not a duplicate. Please open a bug report and repost your patch without compression or archiving. Furthermore, it looks like the issues would be solved by using wineconsole when launching the app. We could try to be clever and detect when an application uses a function that isn't supported on a bare Unix console, but I don't think it would be useful in practice. -- Rob Shearman
Re: DIrectSound on top of openAL ?
On Thursday 30 October 2008 06:05:20 am Roderick Colenbrander wrote: Personally I think that even if OpenAL added the functionality we need that the user experience for most users still won't be good. Most users want to play lets say mp3's while they are gaming. This means that in order to work properly OpenAL under the hood again needs to use alsa+dmix or even worse pulseaudio. For that reason I'm not sure if going directly to OpenAL instead of going through wineoss/winealsa is any better. winealsa/wineoss would have to do the same, really. With a proper DLL thunk, Win32 OpenAL apps can call directy to host OpenAL, which does have some improvements (namely talking to ALSA/OSS directly, up to 7.1 surround sound output (Creative's only does stereo for software mixing), using host configuration, etc). DSound on top of OpenAL is a nice idea, IMO, it's just OpenAL's current short-comings prevent it from happening well enough.
Re: DIrectSound on top of openAL ?
On Thursday 30 October 2008 04:01:31 am Darragh Bailey wrote: On Thu, Oct 30, 2008 at 10:46:51AM +, Darragh Bailey wrote: On Tue, Oct 28, 2008 at 02:16:12PM -0700, Chris Robinson wrote: The biggest problem is updating the sound buffer in real-time (DSound lets you lock a sound buffer and modify it while it's playing; OpenAL only lets you rebuffer the whole buffer, while it's not attached to any source). I get around this by spawning a real-time thread which queues small chunks just in time to keep the buffer playing, but this is a hack at best.. there's no way to know how much you need to buffer ahead so OpenAL doesn't run out during an update, some apps are more sensitive to a large write-ahead, and real-time threads aren't really available in Wine (meaning even larger sections would need to be queued to be able to update in time). The problem is compounded when you consider multiple DSound buffers can share the same data buffer. Couldn't tell if this is on the wish list, there appears to be some suggested enhancements for better buffer control, but I don't know enough to determine whether they actually match up. I've been thinking about this, and have some ideas. There's actually a few extensions I'm trying to get through Creative.. two I'm waiting on a response from, and two more I want to propose that would help DSound compatibility greatly. Another problem is the lack of panning. OpenAL has no controls for panning a 2D sound. At most you can move the sound left and right to simulate panning (for mono sources; stereo is out of luck), but the actual algorithms are implementation dependant and thus would not produce consistant results. Requested: Item:2D panning/speaker level support Contributor: Creative Description: Approval Status: Approved AFAIK, this is in EAX4. Though I can hope it means getting into the core API, I don't know. Additionally, OpenAL hides a lot of the hardware vs. software caps. OpenAL doesn't tell you if you're using hardware or software, while DSound would tell you. Of course you can always lie and say you have hardware (which I found was needed to get some games to even attempt to use DSound3D), but it's not entirely proper. Looks like this has been requested too: Item: Generic Effects Contributor: Creative Description: OpenAL could have a generic mechanism for enumerating and making use of the effects capabilities of the active audio device. Approval Status: Approved I think this is talking about sound effects, like low/hi-pass filters, reverb, etc. This can be done through the EAX and EFX extensions. Nothing about saying what's in hardware and what's in software. 1.0 was released 2000, 1.1 in 2005, so it's probably due a new release in the next year/two, so it might be possible to add some feature requests that would make implementing DirectSound on top of OpenAL visible in the future. If all of the wish list gets added, it would appear the next specification of OpenAL would appear to me to go a long way to allowing wine to implement the Windows sound API's via that, rather than having to support various drivers. I'm not sure what bearing the wish list has on the actual OpenAL API. I don't remember reading anywhere that anything approved will be put into the next core API revision. AFAIK, it could just mean they'll look into ways into adding it.. maybe via extensions.
Re: DIrectSound on top of openAL ?
On Thursday 30 October 2008 03:46:51 am Darragh Bailey wrote: Just out of curiousity, have any of these limitations been raised with the OpenAL developers? Any of them in its future wish list? I'm the developer of OpenAL Soft http://kcat.strangesoft.net/openal.html, which is becoming the implementation to use on Linux and other Unices (as the old Sample Implementation is deprecated/not maintained anymore). Though I'm not really hands-in with Creative or anything.. just a hobbyist developer making a Linux lib on his own time, who gives out his ideas. If OpenAL was updated with the next release 1.2+ to support the type of access that wine needs to support the windows sound API's on linux, would it make it easier that supporting multiple sound drivers? I would like to see DirectSound(3D) running properly on OpenAL, even if as a seperate project (eg. my DSound-OpenAL DLL project). It's not up to me whether such a thing would get into Wine or not, though.
Re: [PATCH] ntdll: Don't append directory entries if the filename length is less than 1.
On Thu, Oct 30, 2008 at 4:08 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: Lei Zhang [EMAIL PROTECTED] writes: I saw the following in a +file trace a user sent me: trace:file:FindNextFileW returning L (L) I tried fixing FindNextFileW(), but that patch didn't get accepted. I'm guessing we should fix the problem in NtQueryDirectoryFile() so nobody who call it will get back an empty file name. This should never happen. You should figure out where the empty name comes from and fix the caller. It's probably because we didn't check d_ino, patch sent. Though wouldn't it be good to have some sanity checking in append_entry(), since all the read_directory helper functions use it?
Re: Changed more malloc to HeapAlloc calls
2008/10/30 James Hawkins [EMAIL PROTECTED] 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. Sure, I'll be more careful about both of those in future. 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. That was a dumb mistake, caused by copying and pasting from a different patch. Thanks for your help James, I'll try and fix the patch then resubmit. Pete Myers
Re: Changed more malloc to HeapAlloc calls
In addition to what James said please split the patch up; one patch per module. A dll or program is a module. Sorry, I'm inundated with noobie errors here I think. Also while you are at it please remove the superfluous casts in the lines you are changing. HeapAlloc (malloc too) returns a void pointer which doesn't needs to be casted to an other pointer type. E.g. Will do. Didn't want to change coding style. Actually my big struggle at the moment is trying to figure out where malloc() memory gets free(). What's the policy here? Should HeapAlloc() always be set free... Is the fact that some malloc() memory not free()'d an error, or a policy? Or should I work harder to find out where free() gets called? Pete
Re: PATCH: warn if missing stdole32.tlb
On Thu, Oct 30, 2008 at 6:13 AM, mayura [EMAIL PROTECTED] wrote: Kind regards. Mayura Swarna kumara ABC Insurance Company Limited, Trans Court, No 21, Nawam Mawatha Colombo 0200 Sri Lanka ( +94 11 230 3560 7 +94 11 230 3566 * [EMAIL PROTECTED] ü www.abcinsurance.lk P Save a tree. Don't print this e-mail unless it's really necessary You forgot to attach the patch. -- -Austin
Re: [PATCH] gdi32: Small patch to fix the return vars of WineEngRemoveFontResourceEx
On Wed, Oct 29, 2008 at 4:18 PM, Daniel Jakob [EMAIL PROTECTED] wrote: Hi My first post on the list is just a small patch. WineEngRemoveFontResourceEx is currently a stub and should return a zero on fail instead of true. Have you thought about the possibility that we return TRUE for a reason? Maybe an app fails if an error percolates up from WineEngRemoveFontResourceEx? -- James Hawkins
Re: Wine 1.0.2
On Thu, Oct 30, 2008 at 3:35 AM, Roderick Colenbrander [EMAIL PROTECTED] wrote: Why is that needed? I believe Alexandre mentioned that 1.0.1 would be the last release. Roderick Please add 1.0.2 target milestone to Bugzilla. -- -Austin -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger Asked Alexandre in IRC, who said he wasn't planning on it unless there were enough patches to justify it. I asked because I wasn't sure how to mark any bugs that warrant nomination for 1.0.2. I'll mark them as 1.0.1 for now, if any come up. -- -Austin
Re: [PATCH] ntdll: Don't append directory entries if the filename length is less than 1.
Lei Zhang [EMAIL PROTECTED] writes: On Thu, Oct 30, 2008 at 4:08 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: Lei Zhang [EMAIL PROTECTED] writes: I saw the following in a +file trace a user sent me: trace:file:FindNextFileW returning L (L) I tried fixing FindNextFileW(), but that patch didn't get accepted. I'm guessing we should fix the problem in NtQueryDirectoryFile() so nobody who call it will get back an empty file name. This should never happen. You should figure out where the empty name comes from and fix the caller. It's probably because we didn't check d_ino, patch sent. Though wouldn't it be good to have some sanity checking in append_entry(), since all the read_directory helper functions use it? I'm not a big fan of the belt-and-suspenders approach. If the callers are behaving correctly there's no need for an extra check, and if they aren't then we shouldn't attempt to cope with their bugs. Besides, there's no guarantee that invalid entries would be empty, they may also contain garbage, and we can't fix that in append_entry. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [2/2] [PATCH] msxml3: fixed if nesting / ptr checking problems inxmlnode_transformNodemarcus
Hi Marcus,
Marcus Meissner [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Hi, htmlDocContentDumpOutput(pOutput, result-doc,
NULL); -if(pOutput) -{
Should this be changed to if(pOutput-buffer), I don't remember if
pOutput-buffer can be NULL.
Best Regards
Alistair Leslie-Hughes
_
Re: Changed more malloc to HeapAlloc calls
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. 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! Pete 2008/10/30 James Hawkins [EMAIL PROTECTED] 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] Vertex pipeline replacement
Short feedback: - Max Payne 2: works as expected, I don't see any visual changes - Morrowind: 3D rendering breaks completly, minor (blending?) issues in the menu as well - however ingame scenes are fully black now How should I report this? Open a bug? Should I do any regression testing (since your patchset consists of more than one patch)? Greets, Tobias
patchwatcher status
Both old and new patchwatcher: - fixed the displayed time of patches on the results web page. New patchwatcher: - for some reason it wasn't looking for all the errors the old one did. Fixed. - for some reason I had forgotten to have it actually watch for new commits in git. Fixed. - Better at logging errors during 'make depend' etc.
Re: [PATCH] gdi32: Small patch to fix the return vars of WineEngRemoveFontResourceEx
James Hawkins wrote: On Wed, Oct 29, 2008 at 4:18 PM, Daniel Jakob [EMAIL PROTECTED] wrote: Hi My first post on the list is just a small patch. WineEngRemoveFontResourceEx is currently a stub and should return a zero on fail instead of true. Have you thought about the possibility that we return TRUE for a reason? Maybe an app fails if an error percolates up from WineEngRemoveFontResourceEx? James: The function should return an INT, not a BOOL. Maybe returning a one is better than returning TRUE, if TRUE = 1. However, I don't like changing a TRUE to a FALSE, as is done in both executions of teh called function. A little explanation on why the change is needed is in order here. The question that needs to be answered is: Should the call return a FALSE (0) or a TRUE (1) and then a patch formulated around the answer to this question. James McKenzie
Re: [Re] Vertex pipeline replacement
Tobias Jakobi wrote: Short feedback: - Max Payne 2: works as expected, I don't see any visual changes - Morrowind: 3D rendering breaks completly, minor (blending?) issues in the menu as well - however ingame scenes are fully black now How should I report this? Open a bug? Should I do any regression testing (since your patchset consists of more than one patch)? Do a regression test to locate which patch breaks Morrowmind. If you know which patch might have broken this, start there. If you do not, a normal regression test is a good idea. James McKenzie
Re: [Re] Vertex pipeline replacement
On Thu, Oct 30, 2008 at 10:07 PM, James McKenzie [EMAIL PROTECTED] wrote: Tobias Jakobi wrote: Short feedback: - Max Payne 2: works as expected, I don't see any visual changes - Morrowind: 3D rendering breaks completly, minor (blending?) issues in the menu as well - however ingame scenes are fully black now How should I report this? Open a bug? Should I do any regression testing (since your patchset consists of more than one patch)? Do a regression test to locate which patch breaks Morrowmind. If you know which patch might have broken this, start there. If you do not, a normal regression test is a good idea. Tobias is referring to Stefan's RFC concerning his vertex pipeline replacement patch. Stefan asked for users to test the patch to see if any games break. -- James Hawkins
