Re: Add GdipSetStringFormatFlags stub
"Alistair Leslie-Hughes" <[EMAIL PROTECTED]> wrote:
> +GpStatus WINGDIPAPI GdipSetStringFormatFlags(GDIPCONST GpStringFormat
> *format, INT flags)
> +{
> +FIXME("format (%d) flags (%d)\n", (int)(format), flags);
Please try to avoid the casts in traces, especially casting a pointer
to an int, use appropriate format specifier instead.
This applies also to your "gdiplus: Add GdipSetPenMode stub" patch.
--
Dmitry.
Re: 2/2 start.exe: Handle the process title argument (try3)
"Alexander Nicolaysen Sørnes" <[EMAIL PROTECTED]> wrote: > try 2 (thanks to Dmitry & Detlef) > > - Use GlobalFree instead of LocalFree > - Fix indentation > - Remove part of a comment > > try 3 > - Use LocalFree, fixing CommandLineToargvW first The following question from my original review still has not been answered: wmain() already has arc/argv pair of parameters, why do you need to parse command line again? -- Dmitry.
Re: start.exe: Handle the process title argument (try2)
On Tuesday 29 January 2008 04:10:34 Dmitry Timoshkov wrote: > "Alexander Nicolaysen Sørnes" <[EMAIL PROTECTED]> wrote: > > - Use GlobalFree instead of LocalFree > > According to MSDN LocalFree is the correct one, as I asked before > you need to fix Wine implementation of CommandLineToArgvW. Sorry, I misread your previous post.THanks for point it out. Alexander
Re: d3dx: A few last questions...
I have submitted a patch for this function and it is easily convertable to the 13 different functions. Anyway, propose another patch for it and let it be implemented. [EMAIL PROTECTED] escribió: The function D3DXCheckVersion must not be forwarded from each d3dx9_xx file to the 36 because D3DX_SDK_VERSION changes for each file. Thanks for your comment, though I don't know if this is needed: Comment from the d3dx9core.h of the DX SDK: /// // D3DX_SDK_VERSION: // - // This identifier is passed to D3DXCheckVersion in order to ensure that an // application was built against the correct header files and lib files. // This number is incremented whenever a header (or other) change would // require applications to be rebuilt. If the version doesn't match, // D3DXCheckVersion will return FALSE. (The number itself has no meaning.) /// So this function is only needed to ensure that no header file changed between the last build of an application. As this won't be the case in our wine implementation we can let all dlls use the same function. Also, the D3DX_SDK_VERSION is declared in d3dx9core.h, which means we can only have one definition of it at a time which even prevents us from caring about this function. By the way, I think this function is just a leftover from the times, when microsoft released updates of their D3DX library without renaming the dlls, were using a more actual dll could really lead to conflicts. Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/index.html
Re: shell32:shlfileop - interactive dialogs on Windows Vista
On 27/01/2008, Reece Dunn <[EMAIL PROTECTED]> wrote: > Hi, > > One of the new features of Windows Vista is to bring up dialogs > whenever you are copying files, moving files, etc. to ask the user > what behaviour they want (e.g. move and replace; don't move; move, but > keep both files). > > This makes it more user friendly, but for the Wine tests, it means that: > - on XP the shlfileop tests run and pass eithout any user interaction; > - on Vista, the shlfileop tests bring up several of those dialog prompts. > > I haven't yet looked at the tests to see what they are doing, or at > the MSDN documentation to see if this would break things (i.e. if the > program selected copy & replace, but the user said don't copy). > > Does anyone have any ideas how to get these working without user > interaction (or if that is at all possible)? Any ideas? Also, the length of the timeout period in the Wine Test Shell should be increased to cater for the timeout in several tests that do eventually pass (see the previous e-mail sent about this). - Reece
Re: user32: understanding the HiliteMenuItem failures (all platforms)... call for help
On 26/01/2008, Reece Dunn <[EMAIL PROTECTED]> wrote: > Hi, > > I am currently looking at the user32: menu (HiliteMenuItem) test failures: > > menu.c:1884: Test failed: HiliteMenuItem: Item 1 is not hilited > menu.c:1891: Test failed: HiliteMenuItem: Item 3 is not hilited > > 1. These are failing consistently on all platforms (see > http://test.winehq.org/data/200801161000 - you may need to search for > HiliteMenuItem to find the failures!). > > 2. It appears (backed up with tests in the attached patch) that the > API fails when the HWND parameter is NULL. > > 3. The tests are not comprehensive enough. > > The patch I have attached here is still a work in progress: see previous e-mail for the patch. > 1. I have not tested it on Wine - it is likely that this will require > todo_wine markers to make it run successfully. > > 2. The tests are still failing on Windows (both XP and Vista). > > Here is where I get stuck. According to the MDSN documentation (which > is likely to be wrong) this appears to be correct. > > Does anyone know how to get HiliteMenuItem to work?! Any ideas? - Reece
Re: ddraw: ddrawmodes test failures (all platforms)
On 26/01/2008, Paul Vriens <[EMAIL PROTECTED]> wrote: > Stefan Dösinger wrote: > > Am Samstag, 26. Januar 2008 13:20:44 schrieb Henning Gerhardt: > >> Am 01/26/2008 12:50 PM schrieb Stefan Dösinger: > >>> Am Samstag, 26. Januar 2008 12:05:09 schrieb Reece Dunn: > Hi, > > Looking at the ddrawmode test failures, they are because the test is > checking that if the DDSD_REFRESHRATE flag is set, then dwRefreshRate > is not 0. However, on many of the test platforms at > http://test.winehq.org/data/200801161000, they are reporting a refresh > rate of 0. > > Are these bogus - due to them running on VM - or is this a valid case? > >>> I have never seen such failures on my real hardware(Windows XP or Vista), > >>> so I think they fail due to VM drivers. I'll re-run the tests to make > >>> sure the tests didn't break somewhen. > >> I don't think so. My system (called xanlosch) is a real XP system with > >> an ATI Mobility 9700 graphic card with one of the latest ATI drivers > >> (7.11er catalyst drivers). Maybe an ATI driver issue? > > > Just ran the test on my real WinXP box (NVIDIA GeForce FX 5200) with the same > results: > > http://test.winehq.org/data/200801161000/xp_XPSP2-HOME-NL/ddraw:ddrawmodes.txt The options for this are: 1. Remove this test case. 2. Set the data member being checked to 0xdeadbeef or similar value, then check if the data member has been set. Ideally, this would need to be done before every call into the callback function where this check is happening, but this may not be possible. I prefer option 2, as this tests if the data member is set (even if it is set to 0) when the specified flag is set. Any takers? - Reece
Re: ddraw: ddrawmodes test failures (all platforms)
Am Dienstag, 29. Januar 2008 19:16:38 schrieb Reece Dunn: > On 26/01/2008, Paul Vriens <[EMAIL PROTECTED]> wrote: > > Stefan Dösinger wrote: > > > Am Samstag, 26. Januar 2008 13:20:44 schrieb Henning Gerhardt: > > >> Am 01/26/2008 12:50 PM schrieb Stefan Dösinger: > > >>> Am Samstag, 26. Januar 2008 12:05:09 schrieb Reece Dunn: > > Hi, > > > > Looking at the ddrawmode test failures, they are because the test is > > checking that if the DDSD_REFRESHRATE flag is set, then > > dwRefreshRate is not 0. However, on many of the test platforms at > > http://test.winehq.org/data/200801161000, they are reporting a > > refresh rate of 0. > > > > Are these bogus - due to them running on VM - or is this a valid > > case? > > >>> > > >>> I have never seen such failures on my real hardware(Windows XP or > > >>> Vista), so I think they fail due to VM drivers. I'll re-run the tests > > >>> to make sure the tests didn't break somewhen. > > >> > > >> I don't think so. My system (called xanlosch) is a real XP system with > > >> an ATI Mobility 9700 graphic card with one of the latest ATI drivers > > >> (7.11er catalyst drivers). Maybe an ATI driver issue? > > > > Just ran the test on my real WinXP box (NVIDIA GeForce FX 5200) with the > > same results: > > > > http://test.winehq.org/data/200801161000/xp_XPSP2-HOME-NL/ddraw:ddrawmode > >s.txt > > The options for this are: > >1. Remove this test case. > >2. Set the data member being checked to 0xdeadbeef or similar > value, then check if the data member has been set. Ideally, this would > need to be done before every call into the callback function where > this check is happening, but this may not be possible. > > I prefer option 2, as this tests if the data member is set (even if it > is set to 0) when the specified flag is set. I'll send a patch once Alexandre is back, as currently it doesn't make much sense flooding wine-patches. I actually intended option 1 first, but now that you mentioned it I think 2 is better.
RE: d3dx: A few last questions...
> The function D3DXCheckVersion must not be forwarded from each d3dx9_xx file > to the 36 because D3DX_SDK_VERSION changes for each file. Thanks for your comment, though I don't know if this is needed: Comment from the d3dx9core.h of the DX SDK: > /// > // D3DX_SDK_VERSION: > // - > // This identifier is passed to D3DXCheckVersion in order to ensure that an > // application was built against the correct header files and lib files. > // This number is incremented whenever a header (or other) change would > // require applications to be rebuilt. If the version doesn't match, > // D3DXCheckVersion will return FALSE. (The number itself has no meaning.) > /// So this function is only needed to ensure that no header file changed between the last build of an application. As this won't be the case in our wine implementation we can let all dlls use the same function. Also, the D3DX_SDK_VERSION is declared in d3dx9core.h, which means we can only have one definition of it at a time which even prevents us from caring about this function. By the way, I think this function is just a leftover from the times, when microsoft released updates of their D3DX library without renaming the dlls, were using a more actual dll could really lead to conflicts. Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/index.html
Re: Wine Wiki spam users
Vitaliy Margolen wrote: > Does anyone have a power to block / remove those users that spam Wine wiki? > It seems just 2-3 users keep creating more and more spam. Can't we just > remove them and permanently block an IP range? I wonder if we should enable moderation of account creations and spread the load of deleting rogue users on many shoulders. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Consulting Communications Engineer Fax.: +49-711-96437-111
Re: Mail flood from the uncoordinated bugzilla cleanup
On Jan 29, 2008 8:36 AM, Detlef Riekenberg <[EMAIL PROTECTED]> wrote: > The flood was to fast to stop Mail-delivery in wine-bugs. > After i stopped Mail-delivery in wine-bugs, the sending queue was still > so full, that my Mailbox got flood again and the bounce rate reached the > limit and mailman disabled Mail-delivery for all wine groups. Sorry. Hopefully there won't be a next time, but if there is, we should give people a few days warning so they can unsubscribe. Or we should disable sending mail when doing bulk changes. - Dan
RE: d3dx: A few last questions...
The function D3DXCheckVersion must not be forwarded from each d3dx9_xx file to the 36 because D3DX_SDK_VERSION changes for each file.
Mail flood from the uncoordinated bugzilla cleanup
Grrr. Please remember, that some Free Mail accounts have a limit in the numbers of Mails. The flood was to fast to stop Mail-delivery in wine-bugs. After i stopped Mail-delivery in wine-bugs, the sending queue was still so full, that my Mailbox got flood again and the bounce rate reached the limit and mailman disabled Mail-delivery for all wine groups. Not nice. -- By by ... Detlef
re: [Patch for Bug 8551] MoveFileWithProgressW unconditional fails for directories with flag MOVEFILE_REPLACE_EXISTING
James McKenzie wrote: > Please submit a git diff not a UNIX diff. Now, hang on there. Jens submitted a perfectly good unified diff patch taken from the right directory. There is no reason to turn up our noses at it. It will apply using patch in exactly the same way as a diff generated by git. Jens, you're fine, I wouldn't bother rediffing. You might however resend your patch next week when Alexandre the maintainer is back from vacation! - Dan
Re: [Patch for Bug 8551] MoveFileWithProgressW unconditional fails for directories with flag MOVEFILE_REPLACE_EXISTING
Jens Nestler wrote: > Am Dienstag, 29. Januar 2008 09:07:16 schrieb Rolf Kalbermatter: > >> Jens Nestler wrote: >> >>> [Patch for Bug 8551] MoveFileWithProgressW >>> unconditional fails fordirectories with flag MOVEFILE_REPLACE_EXISTING >>> >>> http://bugs.winehq.org/show_bug.cgi?id=8551 >>> >>> Hello, >>> >>> please find attached the patch for the bug mentioned above. >>> >> Hi Jens, >> >> Please diff your patches from the top level wine directory itself, as it >> is it's not helpful since the patch utility couldn't even know which of >> the many path.c files in the source tree needs to be patched, and the >> maintainer has a lot more things to do than to search where a patch could >> apply to. >> >> Rolf Kalbermatter >> > > Hi Rolf, > attached you can find the revised path. > Jens > > Please submit a git diff not a UNIX diff. James McKenzie
Re: RegOverridePredefKey stub
"Jens Nestler" <[EMAIL PROTECTED]> wrote: > Sorry, I haven't seen it. > Can you please change it, or should I deliver a changed patch ? Please resend and updated patch with a 'Take 2' in the subject and an explanation in the body what's changed. -- Dmitry.
comctl32 failures on Win95, Win98, NT4 asnd Win2K
These tests are all failing consistently with identical failures on these platforms: combobox - 21 failures; all identical across the platforms. datetime - 2 failures; all identical across the platforms. The rebar tests have 146 failures on some (Win95 and NT4) and 545 failures on others (Win98 and Win2K). This looks like it is due to a different comctl32 version as a result of a different IE version. Several of the others have failures on Win95 and Win98 only. Is anyone going to look at these? - Reece
Re: RegOverridePredefKey stub
Am Dienstag, 29. Januar 2008 07:07:26 schrieb Dmitry Timoshkov: > "Jens Nestler" <[EMAIL PROTECTED]> wrote: > > diff -urN wine-0.9.54_org/include/winreg.h wine-0.9.54/include/winreg.h > > --- wine-0.9.54_org/include/winreg.h 2008-01-25 17:05:38.0 +0100 > > +++ wine-0.9.54/include/winreg.h 2008-01-28 22:07:55.0 +0100 > > @@ -131,6 +131,7 @@ > > WINADVAPI LSTATUS WINAPI RegLoadKeyA(HKEY,LPCSTR,LPCSTR); > > WINADVAPI LSTATUS WINAPI RegLoadKeyW(HKEY,LPCWSTR,LPCWSTR); > > #defineRegLoadKey WINELIB_NAME_AW(RegLoadKey) > > +WINADVAPI LSTATUS WINAPI RegOverridePredefKey(HKEY,HKEY); > > WINADVAPI LSTATUS WINAPI > > RegLoadMUIStringA(HKEY,LPCSTR,LPSTR,DWORD,LPDWORD,DWORD,LPCSTR); > > WINADVAPI LSTATUS WINAPI > > RegLoadMUIStringW(HKEY,LPCWSTR,LPWSTR,DWORD,LPDWORD,DWORD,LPCWSTR); > > #defineRegLoadMUIString > > WINELIB_NAME_AW(RegLoadMUIString) > > Isn't there something that suggests that the entries are alphabetically > sorted? Sorry, I haven't seen it. Can you please change it, or should I deliver a changed patch ? Jens
Re: comctl32 failures on Win95, Win98, NT4 asnd Win2K
Reece Dunn wrote: > These tests are all failing consistently with identical failures on > these platforms: > combobox - 21 failures; all identical across the platforms. > datetime - 2 failures; all identical across the platforms. > > The rebar tests have 146 failures on some (Win95 and NT4) and 545 > failures on others (Win98 and Win2K). This looks like it is due to a > different comctl32 version as a result of a different IE version. > > Several of the others have failures on Win95 and Win98 only. > > Is anyone going to look at these? > > - Reece > > > I already had a brief look and it appears that the failures started happening after: commit 7a5497b5c06600dc3b58788d0d6132e9f7cb7b87 Author: Francois Gouget <[EMAIL PROTECTED]> Date: Mon Dec 10 01:27:50 2007 +0100 comctl32/tests: InitCommonControlsEx() is missing on Windows 95 so call InitCommonControls() instead. I didn't look further yet though. -- Cheers, Paul.
Wine BOF at Scale 6X in Los Angeles, Feb 8th
Anyone going to Scale in Los Angeles? I've scheduled a Wine BOF at 7pm on Friday, Feb 8th; see http://www.socallinuxexpo.org/scale6x/conference-info/social-events/birds-of-a-feather/ For those who don't know, SCALE is the brightest spot in Los Angeles' open source / free software scene. They've been going for eight years now. It's where I first saw a Samba developer running Windows in a VM and immediately going from Ethereal traces to implementing new code :-) See you there, I hope! (The BOF is a combined BOF with Zumastor, but don't worry, that just means I'll be talking with two people instead of one :-) - Dan
Re: [Patch for Bug 8551] MoveFileWithProgressW unconditional fails for directories with flag MOVEFILE_REPLACE_EXISTING
Am Dienstag, 29. Januar 2008 09:07:16 schrieb Rolf Kalbermatter:
> Jens Nestler wrote:
> > [Patch for Bug 8551] MoveFileWithProgressW
> > unconditional fails fordirectories with flag MOVEFILE_REPLACE_EXISTING
> >
> > http://bugs.winehq.org/show_bug.cgi?id=8551
> >
> > Hello,
> >
> > please find attached the patch for the bug mentioned above.
>
> Hi Jens,
>
> Please diff your patches from the top level wine directory itself, as it
> is it's not helpful since the patch utility couldn't even know which of
> the many path.c files in the source tree needs to be patched, and the
> maintainer has a lot more things to do than to search where a patch could
> apply to.
>
> Rolf Kalbermatter
Hi Rolf,
attached you can find the revised path.
Jens
diff -urN wine-0.9.54_org/dlls/kernel32/path.c wine-0.9.54/dlls/kernel32/path.c
--- wine-0.9.54_org/dlls/kernel32/path.c 2008-01-25 17:05:38.0 +0100
+++ wine-0.9.54/dlls/kernel32/path.c 2008-01-28 22:59:19.0 +0100
@@ -1042,15 +1042,6 @@
goto error;
}
-if (info.FileAttributes & FILE_ATTRIBUTE_DIRECTORY)
-{
-if (flag & MOVEFILE_REPLACE_EXISTING) /* cannot replace directory */
-{
-SetLastError( ERROR_INVALID_PARAMETER );
-goto error;
-}
-}
-
/* we must have write access to the destination, and it must */
/* not exist except if MOVEFILE_REPLACE_EXISTING is set */
@@ -1061,7 +1052,7 @@
}
status = NtOpenFile( &dest_handle, GENERIC_READ | GENERIC_WRITE, &attr, &io, 0,
FILE_NON_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT );
-if (status == STATUS_SUCCESS)
+if (status == STATUS_SUCCESS) /* destination exists */
{
NtClose( dest_handle );
if (!(flag & MOVEFILE_REPLACE_EXISTING))
@@ -1070,6 +1061,11 @@
RtlFreeUnicodeString( &nt_name );
goto error;
}
+else if (info.FileAttributes & FILE_ATTRIBUTE_DIRECTORY) /* cannot replace directory */
+{
+SetLastError( ERROR_ACCESS_DENIED );
+goto error;
+}
}
else if (status != STATUS_OBJECT_NAME_NOT_FOUND)
{
Re: No new winetest?
On 26/01/2008, Francois Gouget <[EMAIL PROTECTED]> wrote: > On Fri, 25 Jan 2008, Paul Millar wrote: > [...] > > The front-end machine had stopped responding to network traffic. > [...] > > So, sorry, winetest will be off-line until Monday at the earliest. > > Thanks for the status update. Is there any more news on this? - Reece
RE: [Patch for Bug 8551] MoveFileWithProgressW unconditional fails fordirectories with flag MOVEFILE_REPLACE_EXISTING
Jens Nestler wrote: > [Patch for Bug 8551] MoveFileWithProgressW > unconditional fails fordirectories with flag MOVEFILE_REPLACE_EXISTING > > http://bugs.winehq.org/show_bug.cgi?id=8551 > > Hello, > > please find attached the patch for the bug mentioned above. Hi Jens, Please diff your patches from the top level wine directory itself, as it is it's not helpful since the patch utility couldn't even know which of the many path.c files in the source tree needs to be patched, and the maintainer has a lot more things to do than to search where a patch could apply to. Rolf Kalbermatter
Re: RegOverridePredefKey stub
"Jens Nestler" <[EMAIL PROTECTED]> wrote: > diff -urN wine-0.9.54_org/include/winreg.h wine-0.9.54/include/winreg.h > --- wine-0.9.54_org/include/winreg.h 2008-01-25 17:05:38.0 +0100 > +++ wine-0.9.54/include/winreg.h 2008-01-28 22:07:55.0 +0100 > @@ -131,6 +131,7 @@ > WINADVAPI LSTATUS WINAPI RegLoadKeyA(HKEY,LPCSTR,LPCSTR); > WINADVAPI LSTATUS WINAPI RegLoadKeyW(HKEY,LPCWSTR,LPCWSTR); > #defineRegLoadKey WINELIB_NAME_AW(RegLoadKey) > +WINADVAPI LSTATUS WINAPI RegOverridePredefKey(HKEY,HKEY); > WINADVAPI LSTATUS WINAPI > RegLoadMUIStringA(HKEY,LPCSTR,LPSTR,DWORD,LPDWORD,DWORD,LPCSTR); > WINADVAPI LSTATUS WINAPI > RegLoadMUIStringW(HKEY,LPCWSTR,LPWSTR,DWORD,LPDWORD,DWORD,LPCWSTR); > #defineRegLoadMUIString WINELIB_NAME_AW(RegLoadMUIString) Isn't there something that suggests that the entries are alphabetically sorted? -- Dmitry.
Re: Bugzilla: Remove obsolete components
On Jan 28, 2008 1:12 PM, Austin English <[EMAIL PROTECTED]> wrote: > Howdy, > > I just finished moving over the last of the obsolete components. > _obsolete_binary, _obsolete_directx, and _obsolete_gui can all be > removed now. > Also, can you please make the following changes: rename: wineps-driver -> wineps.drv winmm&mci -> winmm x11-driver -> winex11.drv add: wintab32 msacm32 wintrust rasapi32 msvfw32 Thanks, James Hawkins
Re: [Patch for Bug 8551] MoveFileWithProgressW unconditional fails for directories with flag MOVEFILE_REPLACE_EXISTING
On Jan 28, 2008 4:05 PM, Jens Nestler <[EMAIL PROTECTED]> wrote: > http://bugs.winehq.org/show_bug.cgi?id=8551 > > Hello, > > please find attached the patch for the bug mentioned above. > Please submit a test case for this change as well. -- James Hawkins
Wine Wiki spam users
Does anyone have a power to block / remove those users that spam Wine wiki? It seems just 2-3 users keep creating more and more spam. Can't we just remove them and permanently block an IP range? Vitaliy.
Re: [PATCH 1/1] winecoreaudio: Make sure Port_SendToMessageThread is non-NULL in CoreAudio_WaveRelease.
On Jan 28, 2008, at 8:06 AM, Misha Koshelev wrote: I have started playing with wine on MacOS in VMWare. wineprefixcreate page faults on my MacOS "system" and I tracked it to Port_SendToMessageThread staying NULL because of: err:wave:CoreAudio_WaveInit AudioHardwareGetProperty: CoreAudio_DefaultDevice.outputDeviceID == kAudioDeviceUnknown Clearly wineprefixcreate shouldn't be page faulting under any condition. It seems to me that the driver ought to just fail to load in this case. If you back out your patch and apply the attached patch, does that fix the page fault? -Ken coreaudio_detect_load_failure.patch Description: Binary data
Re: start.exe: Handle the process title argument (try2)
"Alexander Nicolaysen Sørnes" <[EMAIL PROTECTED]> wrote: > - Use GlobalFree instead of LocalFree According to MSDN LocalFree is the correct one, as I asked before you need to fix Wine implementation of CommandLineToArgvW. -- Dmitry.
