June 2007 - Wine-devel - list.winehq.org

Re: [2/2] wined3d: For ps_2_0 and higher, call shader_get_registers_used() in IWineD3DPixelShaderImpl_SetFunction
by Stefan Dösinger 08 Jun '07

08 Jun '07

Am Donnerstag, 7. Juni 2007 23:52 schrieb H. Verbeet: > For pre-2.0 pixel shaders the stateblock is used to determine the > sampler types, so we need to wait until CompileShader to do this. For > ps_2_0 and higher there is no such requirement. > > Changelog: > - For ps_2_0 and higher, call shader_get_registers_used() in > IWineD3DPixelShaderImpl_SetFunction Are you going to compile >= 2.0 shaders in SetFunction? How would that work with other things that may need delayed compilation, like fog or (future) srgb write correction?

2 2

Re: gdiplus: added stub implementation of gdiplus.dll
by Mounir IDRASSI 08 Jun '07

08 Jun '07

Hi, You also have to modify other files in order to integrate your stub implementation to the wine build chain: Makefile.in, configure and configure.ac in the wine root directory, Makefile.in in the "dlls" directory. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Evan Stade wrote: > Changelog: > * added stub implementation of gdiplus.dll (3 files) > > dlls/gdiplus/Makefile.in | 16 + > dlls/gdiplus/gdiplus.c | 45 +++ > dlls/gdiplus/gdiplus.spec | 609 > +++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 670 insertions(+), 0 deletions(-)

6 7

FYI: SHELL_ArgifyW and unquoted %1, non-native behavior
by Misha Koshelev 08 Jun '07

08 Jun '07

Sorry if I am just filling your inboxes, but I thought I'd at least throw this out there before I forget about it. When I was making my ShellExecute DDE conformance tests to get Vector NTI associated files to open correctly (using DDE and without the fake "%1" that wine was adding to all shell/?/command strings that don't have one at the time), I noticed another non-native behavior in wine. Specifically, when %1 is in a command or a ddeexec string on Windows (XP), the filename is passed as is. However, under wine quotes are added to this argument in SHELL_ArgifyW. Since this did not affect anything Vector NTI related, I decided to just not worry about this behavior at the time and just to change my conformance test so it wouldn't tickle this. However, I am just wondering what the general policy is about something like this? Should it just be left alone until an app is found that somehow depends on this (I am thinking this is the case)? Or do we want to try to correct this when we discover this, that way perhaps preventing this bug in this application from ever even occuring? Thanks Misha

1 0

Re: ole32: Remove stack-based string buffer inFileMonikerImpl_DecomposePath
by Dmitry Timoshkov 07 Jun '07

07 Jun '07

"Ulrich Czekalla" <ulrich.czekalla(a)utoronto.ca> wrote: > - WCHAR word[MAX_PATH]; > - int i=0,j,tabIndex=0; > + LPOLESTR word; > + int i=0,j,tabIndex=0, ret=0; > LPOLESTR *strgtable ; > > int len=lstrlenW(str); > > TRACE("%s, %p\n", debugstr_w(str), *stringTable); > > - strgtable =CoTaskMemAlloc(len*sizeof(LPOLESTR)); > + strgtable = CoTaskMemAlloc(len*sizeof(LPOLESTR)); > > if (strgtable==NULL) > return E_OUTOFMEMORY; > > + word = CoTaskMemAlloc((len + 1)*sizeof(LPOLESTR)); Shouldn't it be *sizeof(WCHAR) or *sizeof(OLECHAR)? -- Dmitry.

2 1

Could somebody run the wininet/ftp tests on Wine?
by Paul Vriens 07 Jun '07

07 Jun '07

Hi, Some time ago I added some ftp-tests. After I've seen a lot of wininet patches I just tried (current GIT) to run the ftp tests again on Wine. This time I get some failure (or actually successes): [paul(a)LatitudeC600 tests]$ make ftp.ok ../../../tools/runtest -v -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so ftp.c && touch ftp.ok ftp.c:303: Test succeeded inside todo block: Expected ERROR_SUCCESS, got 0 ftp.c:363: Test succeeded inside todo block: Expected ERROR_SUCCESS, got 0 ftp.c:375: Test succeeded inside todo block: Expected ERROR_SUCCESS, got 0 ftp.c:485: Test failed: Expected FtpOpenFileA to succeed ftp.c:858: Test succeeded inside todo block: Expected ERROR_SUCCESS or ERROR_FILE_NOT_FOUND (win98), got 0 ftp: 128 tests executed (14 marked as todo, 5 failures), 0 skipped. make: *** [ftp.ok] Error 5 The strange thing is that the calls fail yet the last error is set to ERROR_SUCCESS. Can somebody confirm? Cheers, Paul.

2 2

Re: cmd:Ru:Update Russian translation.[try2][fixed]
by Kirill K. Smirnov 07 Jun '07

07 Jun '07

> >> + WCMD_YES, "Д" > >> + WCMD_NO, "Н" > > > > Answers to "Yes/No" question should not be translated, should they? "All" > > too. > > I think that should translate this answers because in some languages > such as Norwegian,German and Korean it was translated. > I really doesn`t understand why in Russian language this answers should > not to be translated. In windows they are not translated. Moreover, it is inconvenient to switch to Russian, press 'Д' ('Н'), then switch to English. It may be better if we allow to use translated and untranslated answers simultaneously. AFAIK it is allowed to use translated only. -- Kirill

1 0

Re: cmd:Ru:Update Russian translation.[try2][fixed]
by Kirill K. Smirnov 07 Jun '07

07 Jun '07

Hi, Anatoly! The translation is still very raw. Please, verify it. >+ WCMD_YES, "Д" >+ WCMD_NO, "Н" Answers to "Yes/No" question should not be translated, should they? "All" too. >+ WCMD_NOASSOC, "Файл, ассоциированный с расширением %s,отсутствует\n" This phrase does not sound Russian. "Отсутствует сопоставление для расширения %s" will be better. and so on... -- Kirill

3 2

Re: wininet: Make the passive mode response check case insensitive.
by Francois Gouget 07 Jun '07

07 Jun '07

On Wed, 6 Jun 2007, Hans Leidekker wrote: [...] > Changelog > Make the passive mode response check case insensitive. --- a/dlls/wininet/ftp.c +++ b/dlls/wininet/ftp.c [...] - if (strncmp(p, "Entering Passive Mode", 21)) + if (strncasecmp(p, "Entering Passive Mode", 21)) You should not be using str*casecmp() in Wine (because it's a Unix function, and because it uses the wrong locale). Try CompareString() instead. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: the choice of a GNU generation

3 2

Re: avifil32: remove 'recursive registry key delete' function
by Detlef Riekenberg 07 Jun '07

07 Jun '07

On Do, 2007-06-07 at 00:00 +0200, Stefan Leichter wrote: Replacing recursive_delete_key with RegDeleteTree is not the same. As Example: > - res = recursive_delete_keyA(HKEY_CLASSES_ROOT, > list->progid); > + res = RegDeleteTreeA(HKEY_CLASSES_ROOT, list->progid); > if (res != ERROR_SUCCESS) goto error_close_coclass_key; When the Initial RegOpenKey failed, RegDeleteTree is returning ERROR_FILE_NOT_FOUND and the codepath went to the error-label, but the old recursive_delete_keyA returned ERROR_SUCCESS. See this removed Line from recursive_delete_keyA/W: - if (res == ERROR_FILE_NOT_FOUND) return ERROR_SUCCESS; This additional change should work: if ((res != ERROR_SUCCESS) && (res != ERROR_FILE_NOT_FOUND)) { goto error_close_coclass_key; } Thanks -- By by ... Detlef

1 0

Re: wined3d [1/5]: Add GL_EXT_texture_sRGB constants and corresponding CheckDeviceFormat query
by Phil Costin 07 Jun '07

07 Jun '07

Stefan Dösinger wrote: > Am Donnerstag, 7. Juni 2007 01:03 schrieb Phil Costin: >> Adds necessary GL constants and allows the application to query whether a >> particular texture format is compatible with sample-time texture >> linearization. > Ideally you shouldn't enable the srgb formats in this patch already, but > rather in 4/5, but since the current code returns WINED3D_OK this is an > unimportant detail. Well, originally I did but you advised me to move it to patch 1 so I did :) Regards, Phil

2 1