November 2007 - Wine-Devel - list.winehq.org

Re: Add tests for RSA_AES provider in rsaenh

by Reece Dunn

On 16/11/2007, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > ChangeLog > -------------- > Add tests for RSA_AES provider in rsaenh > > Note: > ------- > Some tests might fail as there is no RSA_AES provider in wine. > These will be fixed once the implementation is in place, which will be > sent next. The recommended way to do this is mark the parts of the tests that fail in Wine with todo_wine. - Reece

Nov. 16, 2007

Re: USER32: win16 applications should not see long filenames returned from dialog control (try 4)

by Alex Villacís Lasso

Alex Villacís Lasso escribió: > I hope this version addresses the fact DlgDirSelect does not modify the > last error code, and therefore cannot be used to distinguish between a > valid and an invalid file. > > Changelog: > * Applications should not see long filenames returned from dialog control > > ------------------------------------------------------------------------ > > This patch has not been applied, and has not been commented on either. Is there something wrong with it? -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

Nov. 16, 2007

pglXMakeCurrent causes wine to crash on Mac os x

by Tobias Platen

Hello if i run wine on Mac os x 10.4.10 with Apples X11 (opengl linked staticly) i get the following runtime errors; X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 129 (Apple-DRI) Minor opcode of failed request: 2 () Value in failed request: 0x57 Serial number of failed request: 16 Current serial number in output stream: 16 I have found out that commenting out the bad code will not cause that X Error wine crashes in a access violation (SIGSEGV) if (ctx) { // pglXMakeCurrent(gdi_display, win, ctx); } else { ERR(" couldn't initialize OpenGL, expect problems\n"); wine_tsx11_unlock(); return FALSE; } Does anybody know how to get opengl working on the mac.

Nov. 16, 2007

Re: ntdll: send_debug_event: don't send uninitialized bytes

by Robert Shearman

Dan Kegel wrote: > On Nov 16, 2007 3:06 AM, Robert Shearman <rob(a)codeweavers.com> wrote: > >>> + return sizeof(*rec) >>> + - (EXCEPTION_MAXIMUM_PARAMETERS-rec->NumberParameters) * sizeof(ULONG_PTR); >>> >> FIELD_OFFSET exists for this exact purpose. >> > > OK, I'll bite: is > + return FIELD_OFFSET(EXCEPTION_RECORD, ExceptionInformation) > + + rec->NumberParameters * sizeof(ULONG_PTR); > really clearer? No, but this is: return FIELD_OFFSET(EXCEPTION_RECORD, ExceptionInformation[rec->NumberParameters]); -- Rob Shearman

Nov. 16, 2007

Re: ntdll: send_debug_event: don't send uninitialized bytes

by Dan Kegel

On Nov 16, 2007 3:06 AM, Robert Shearman <rob(a)codeweavers.com> wrote: > > + return sizeof(*rec) > > + - (EXCEPTION_MAXIMUM_PARAMETERS-rec->NumberParameters) * sizeof(ULONG_PTR); > > FIELD_OFFSET exists for this exact purpose. OK, I'll bite: is + return FIELD_OFFSET(EXCEPTION_RECORD, ExceptionInformation) + + rec->NumberParameters * sizeof(ULONG_PTR); really clearer? - Dan

Nov. 16, 2007

Re: winetest_interactive : how does it work?

by Francois Gouget

On Fri, 16 Nov 2007, Paul Vriens wrote: > Hi, > > I just ran winetest (by double clicking on the executable) on my WinXP box. I > was missing some advpack popups that were there before. Francois sent in a patch > to only do some particular tests when winetest_interactive is true. I would > assume that clicking on a executable is interactive, not? No, it's not. The application (winetest.exe) cannot tell whether someone double-clicked on the exe in a file manager, whether it was started by some sort of a cron job, or whether it was started by autorun when you 'inserted a CD in the drive' (which is what I usually do). Plus the way you start winetest really tells nothing about whether you want to run the extra tests (which are going to resize your screen to a gazillion different resolutions, play tons of tunes, and ask for your attention again and again). Maybe you just started the test before goign to bed and expect them to run to completion and turn the computer off without your intervention. One possibility would be to add a checkbox to the winetest GUI that you would check if you wanted to run the extra tests. Actually it would be nice if it also let you specify the debug level to run the tests with. But right now the solution is to just do: set WINETEST_INTERACTIVE=1 winetest.exe -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

Nov. 16, 2007

Re: Start: Convert start to Unicode. [try5]

by Alexandre Julliard

Anatoly Lyutin <vostok(a)etersoft.ru> writes: > @@ -202,9 +246,9 @@ int main(int argc, char *argv[]) > DWORD waitcode; > waitcode = WaitForSingleObject(sei.hProcess, INFINITE); > if (waitcode) > - fatal_error("WaitForSingleObject", GetLastError()); > + fatal_error(WaitForSingleObjectW, GetLastError()); > if (!GetExitCodeProcess(sei.hProcess, &exitcode)) > - fatal_error("GetExitCodeProcess", GetLastError()); > + fatal_error(GetExitCodeProcessW, GetLastError()); This is way overkill, there's no reason to convert errors like these to Unicode. WINE_ERR would work just as well. -- Alexandre Julliard julliard(a)winehq.org

Nov. 16, 2007

Re: [PATCH] svchost: Added base implementation of svchost (1/12)

by Alexandre Julliard

Roy Shea <roy(a)cs.hmc.edu> writes: > +/* Allocate and initializes an ANSI version of the Unicode string */ > +static LPSTR UnicodeToAnsi(const WCHAR *unicode) > +{ > + int size; > + LPSTR ansi; > + > + size = WideCharToMultiByte(CP_UTF8, 0, unicode, -1, NULL, 0, NULL, NULL); > + ansi = HeapAlloc(GetProcessHeap(), 0, size); > + WideCharToMultiByte(CP_UTF8, 0, unicode, -1, ansi, size, NULL, NULL); > + return ansi; > +} UTF-8 is not the same thing as ANSI, this function is misleading. For procedure names what you probably want is a special-purpose function that rejects anything that isn't 7-bit ASCII. > + ret = RegOpenKeyExW(HKEY_LOCAL_MACHINE, service_param_key, 0, > + KEY_READ, &service_hkey); > + if (ret != ERROR_SUCCESS) > + { > + WINE_ERR("cannot open key %s, err=%d\n", > + wine_dbgstr_w(service_param_key), ret); > + HeapFree(GetProcessHeap(), 0, service_param_key); > + return FALSE; > + } > + > + /* Find DLL associate with service from key */ > + dll_name_short = GetRegValue(service_hkey, service_dll); > + if (!dll_name_short) > + { > + WINE_ERR("cannot find registry value %s for service %s\n", > + wine_dbgstr_w(service_dll), wine_dbgstr_w(service_name)); > + HeapFree(GetProcessHeap(), 0, service_param_key); > + return FALSE; > + } You are leaking registry handles pretty much everywhere. -- Alexandre Julliard julliard(a)winehq.org

Nov. 16, 2007

Re: server: Add a call for retrieving the image file name of a process.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > get_dll_info doesn't appear to be suitable for this purpose. We don't > know what the base address of the EXE is and the call doesn't return > the required size for the filename. Well, you have to extend it a bit to support that, but it's better than adding a new request. -- Alexandre Julliard julliard(a)winehq.org

Nov. 16, 2007

Re: server: Add a call for retrieving the image file name of a process.

by Robert Shearman

Alexandre Julliard wrote: > Robert Shearman <rob(a)codeweavers.com> writes: > > >> --- >> dlls/ntdll/process.c | 20 +++++++++++++++++++- >> dlls/ntdll/tests/info.c | 36 ++++++++++++++++++++++++++++++++++++ >> server/process.c | 31 +++++++++++++++++++++++++++++++ >> server/protocol.def | 9 +++++++++ >> 4 files changed, 95 insertions(+), 1 deletions(-) >> > > You should use the existing get_dll_info request for that. get_dll_info doesn't appear to be suitable for this purpose. We don't know what the base address of the EXE is and the call doesn't return the required size for the filename. -- Rob Shearman

Nov. 16, 2007