wine-devel January 2005

wine-devel@winehq.org

149 participants
343 discussions

Re: WINEDBG: add support to interrogate gdi objects
by Pouech Eric DMI AEI CAEN 21 Jan '05

21 Jan '05

> Message du 21/01/05 04:10 > > ChangeLog: > Ulrich Czekalla > * add support to interrogate gdi objects several comments: * the changes in db_disasm.c are not declared in the changelog. Morever, I don't see the need of passing an extra parameter in db_task_printsym as you don't need it (maybe you forgot that part from the patch ?) * for the pure gdi info. - always use (when looking for a symbol) the name of the DLL you're looking the symbol from. this has several good side effects: first, it shortens the scope for searching (as dbghelp treats all global symbol - static or public - in the same name space), this reduces the likely hood of name conflicts. Secondly, the search will be much faster (as dbghelp won't be searched for all loaded DLLs), and won't force loading of symbols in DLLs for which we haven't looked up symbols yet (deferred symbol loading). For example, you should use gdi32!GDI_HeapSel for the symbol out of gdi32. * why are you using the ldt_copy at all ? there's support in winedbg for linearizing 16bit addresses, so making a 16 bit addr out of gdi-sel and handle and linearizing it should work. * you should add the same functionality to the gdbproxy (or at least add a TODO in winedbg.c to remain that it has to be done) * you should document the feature (info.c and documentation/debugger.sgml) A+

2 1

Re: fix the DEVELOPER-HINTS file to reflect how things are really done
by Dimitrie O. Paun 21 Jan '05

21 Jan '05

On Fri, Jan 21, 2005 at 04:54:29PM +0900, Mike McCormack wrote: > - FIXME("(%x,%p,%d): stub\n", hdc, p, count); ... > + FIXME("%p %p %ld\n", hdc, p, count); Well, I must agree with Andy: there's no reason to remove the 'stub' part, most of the code uses it, automated tools look for it, and it saves nothing. -- Dimi.

2 1

NTLMSSP authentication added to FreeDCE (requires Samba TNG, uses winbindd)
by Luke Kenneth Casson Leighton 21 Jan '05

21 Jan '05

i _would_ announce this on the samba mailing lists but the samba team have placed some rather fascist censorship in place, and consider any posting that i make to any samba.org addresses to be "net abuse". i've just modified winbindd (written in 2000 by tim and andrew) to be able to use it to do NTLM "challenge response" authentication. i also wrote a small library, containing two functions, which could be used by absolutely any project: they take a user+pass+domain, or a user+domain+challenge+responses. the functions don't care where your PDC is: it could be on the local machine, under which circumstances the back-end (winbindd) will adjust accordingly and save you some network traffic. both functions return a "blob" which is a NET_USER_INFO_3 structure, which contains valuable information - in particular, it contains the session key, but also it contains the equivalent of uid+gid+secondary groups: namely, the primary user rid, primary group rid, and secondary group SIDs etc. that the user is in. [for the benefit of the wine people: this information is essential for doing things like "ImpersonateNamedPipeClient" and "RpcImpersonateClient" in Wine / ReactOS, if the authentication being performed is to have any "meaning", as it's what gets passed to SeAccessCheck(). you can always of course return stub data and you can always have an implementation of SeAccessCheck return "ok"...] samba tng cvs can be obtained via www.samba-tng.org/cvs.html and freedce cvs from http://sf.net/projects/freedce. you can test the new interface by compiling and running bin/winbindauthtest - you must have a user of "test" with a password of "test". i may have one more thing to do - add "NamedPipe" security context "inheritance" to the client-side libraries in FreeDCE, but to be honest i don't think it's all that essential / there going to be a whopping big demand for it. l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 0

load_VDMX - is the check for bCharSet == -1 necessary?
by Troy Rollo 21 Jan '05

21 Jan '05

In dlls/gdi/freetype.c, load_VDMX refuses to process ratio records in which bCharSet is 0. Looking at the meaning of bCharSet and the layout of the VDMX table <http://www.microsoft.com/OpenType/OTSpec/vdmx.htm>, I can see no rational reason for this, and no reason appears in the code. Since 13th December this has been generating a FIXME message for some fonts. Does anybody know of a reason why this check is necessary? Commenting it hasn't hurt anything obvious.

2 1

Re: fix the DEVELOPER-HINTS file to reflect how things are really done
by Andreas Mohr 21 Jan '05

21 Jan '05

Hi, On Fri, Jan 21, 2005 at 04:54:29PM +0900, Mike McCormack wrote: > ChangeLog: > * fix the DEVELOPER-HINTS file to reflect how things are really done Did I miss something? > - FIXME("(%x,%p,%d): stub\n", hdc, p, count); > + BOOL WINAPI PolyBezierTo(HDC hdc, const POINT *p, DWORD count) > + { > + /* tell the user they've got a substandard implementation */ > + FIXME("%p %p %ld\n", hdc, p, count); This is a step backwards IMHO. It doesn't tell squat: the user doesn't know that this is a stub ("FIXME" what??), and he doesn't know that these are supposed to be the function parameters either (it could be any other variable debug printout, too - it's indistinguishable). To developers, such a printout might make sense if it's known to be the standard format (and I'd say it isn't!), but to people that aren't fiddling with Wine on a daily basis it will mean less than the previous form. OTOH, since "stub" is a somewhat nebulous word, too (to non-developers), it probably makes sense to leave it out (a FIXME does indicate a shortcoming after all, so such a non-specific output string makes it very likely that it's the whole function that is broken), but at least keep the braces that indicate function parameters. But OTOH, since "... stub" has been in use for ages, its meaning is probably common knowledge amoung many older Wine users, and it's only an extra 6 or 7 characters anyway, so I'd still leave it in. Greetings, Andreas Mohr

4 3

Re: [OLE #48] Restructure Unmarshaling Code
by Alexandre Julliard 21 Jan '05

21 Jan '05

Robert Shearman <rob(a)codeweavers.com> writes: > Changelog: > - Add a new flag SORFP_NOLIFETIMEMGMT to tell the proxy manager not to > pass an outer unknown to IRpcProxyBuffer_CreateProxy. > - Move the low-level unmarshaling code into a new function, > unmarshal_object, so that it can be easily reused for unmarshaling > IRemUnknown. This causes the test to crash: ../../../tools/runtest -q -P wine -M ole32.dll -T ../../.. -p ole32_test.exe.so marshal.c && touch marshal.ok marshal.c:329: Test failed: Number of locks should be 0, but actually is 2 wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00000002 in 32-bit code (0x00000002). In 32 bit mode. Register dump: CS:0023 SS:002b DS:002b ES:002b FS:1007 GS:0000 EIP:00000002 ESP:4067fdcc EBP:4067fdd8 EFLAGS:00010216( - 00 -RIAP1) EAX:00000002 EBX:40776bf0 ECX:40031000 EDX:40340074 ESI:403c924c EDI:403c92a0 Stack dump: 0x4067fdcc: 407479d2 403c92e4 40776bf0 4067fdf4 0x4067fddc: 40747ff6 403c92a0 40776bf0 403c9230 0x4067fdec: 40378828 403c9258 4067fe0c 407481ba 0x4067fdfc: 403c9228 40776bf0 403787e0 403787c0 0x4067fe0c: 4067fe2c 40738c0c 403787e0 40776bf0 0x4067fe1c: 40776acf 403787c0 40573c81 00000000 0200: sel=1007 base=40031000 limit=00001f97 32-bit rw- Backtrace: =>1 0x00000002 (0x4067fdd8) 2 0x40747ff6 proxy_manager_disconnect+0x9e(This=0x403c9228) [/home/julliard/wine/wine/dlls/ole32/marshal.c:455] in ole32 (0x4067fdf4) 3 0x407481ba MARSHAL_Disconnect_Proxies+0x36(apt=0x403787e0) [/home/julliard/wine/wine/dlls/ole32/marshal.c:536] in ole32 (0x4067fe0c) 4 0x40738c0c COM_ApartmentRelease+0xe0(apt=0x403787e0) [/home/julliard/wine/wine/dlls/ole32/compobj.c:310] in ole32 (0x4067fe2c) 5 0x407392b5 CoUninitialize+0xad [/home/julliard/wine/wine/dlls/ole32/compobj.c:639] in ole32 (0x4067fe44) 6 0x4056ff2e test_marshal_proxy_apartment_shutdown+0x15e [/home/julliard/wine/wine/dlls/ole32/tests/marshal.c:393] in ole32_test (0x4067fe70) 7 0x40571979 func_marshal+0x59 [/home/julliard/wine/wine/dlls/ole32/tests/marshal.c:1063] in ole32_test (0x4067fe80) 8 0x40573ee5 run_test+0x81(name=0x40340a76) [/home/julliard/wine/wine/dlls/ole32/tests/../../../include/wine/test.h:287] in ole32_test (0x4067fe94) 9 0x405740da main+0xf2(argc=0x2, argv=0x40340a58) [/home/julliard/wine/wine/dlls/ole32/tests/../../../include/wine/test.h:327] in ole32_test (0x4067feac) 10 0x4056f190 __wine_exe_main+0x190 in ole32_test (0x4067ff2c) 11 0x405088a2 start_process+0x8a(arg=0x0) [/home/julliard/wine/wine/dlls/kernel/process.c:1046] in kernel32 (0x4067fff4) 12 0x4001ccd5 wine_pthread_abort_thread+0x29(status=0x0) [/home/julliard/wine/wine/libs/wine/port.c:85] in libwine.so.1 (0x00000000) -- Alexandre Julliard julliard(a)winehq.org

1 0

Regression : tools/wineinstall fails with an X Error
by Paul Vriens 21 Jan '05

21 Jan '05

Hi, doing a tools/wineinstall on a clean system yields in an X-Error. Doing: winedbg rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf gives: .. Wine-dbg>bt Backtrace: =>1 0x00abec49 (0x00a6d7f4) 2 0x00656d76 _XcmsSine+0xe6 in x11drv (0x00a6d818) 3 0x00767b5a WIN_DestroyWindow+0xf2(hwnd=0x30026) [/data/install/linux/wine-src/wine/dlls/user/../../windows/win.c:655] in user32 (0x00a6d830) 4 0x007699be DestroyWindow+0x116(hwnd=0x30026) [/data/install/linux/wine-src/wine/dlls/user/../../windows/win.c:1517] in user32 (0x00a6d854) 5 0x00ff6862 COM_ApartmentRelease+0x146(apt=0x77e60090) [/data/install/linux/wine-src/wine/dlls/ole32/compobj.c:338] in ole32 (0x00a6d870) 6 0x00ff6f54 CoUninitialize+0x100 [/data/install/linux/wine-src/wine/dlls/ole32/compobj.c:641] in ole32 (0x00a6d888) 7 0x00934c2f register_filters+0x28f(list=0x946700) [regsvr.c:644] in quartz (0x00a6d8e0) 8 0x009350cb QUARTZ_DllRegisterServer+0x6b [regsvr.c:1078] in quartz (0x00a6d8f0) 9 0x00843686 do_register_dll+0xca(info=0xa6fb80, path=0x77e51400, flags=0x1, timeout=0x3c, args=0x0) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:491] in setupapi (0x00a6d924) 10 0x00843a2a register_dlls_callback+0x1a6(hinf=0x77e15ce0, field=0xa6f9b4, arg=0xa6fb80) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:574] in setupapi (0x00a6f970) 11 0x00843f48 iterate_section_fields+0xe0(hinf=0x77e15ce0, section=0xa6fbe4, key=0x852420, callback=0x843884, arg=0xa6fb80) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:696] in setupapi (0x00a6fb50) 12 0x0084421c SetupInstallFromInfSectionW+0x8c(owner=0x10024, hinf=0x77e15ce0, section=0xa6fbe4, flags=0x3ff, key_root=0x0, src_root=0x0, copy_flags=0x4, callback=0x84a894, context=0x77e8bda8, devinfo=0x0, devinfo_data=0x0) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:851] in setupapi (0x00a6fbac) 13 0x00844625 InstallHinfSectionW+0x101(hwnd=0x10024, handle=0xc30000, cmdline=0x77bd05a8, show=0x1) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:934] in setupapi (0x00a6fe00) 14 0x00c327da main+0x1aa(argc=0x5, argv=0x77de0420) [/data/install/linux/wine-src/wine/programs/rundll32/rundll32.c:291] in rundll32 (0x00a6fe9c) 15 0x00c32163 __wine_exe_main+0x163 in rundll32 (0x00a6ff2c) 16 0x0029d2d7 start_process+0xc3(arg=0x0) [/data/install/linux/wine-src/wine/dlls/kernel/process.c:1046] in kernel32 (0x00a6fff4) 17 0x004ec6a5 __GI_____strtof_l_internal+0x155 in libc.so.6 (0x00000000) I didn't do a regression test yet, to find the cause, but the error seems to be in COM_ApartmentRelease during the DestroyWindow(apt->win) I've applied OLE # 45 already. Will do some more testing tonight. Cheers, Paul.

6 17

Re: dlls/comctl32/status.c
by Alexandre Julliard 21 Jan '05

21 Jan '05

Ge van Geldorp <gvg(a)reactos.com> writes: > Changelog: > Gunnar Dalsnes <hardon(a)online.no> > STATUSBAR_SetTextT: > - ntext wasn't freed on return if text was unicode > - part->text was allways freed, but if the previous style was SBT_OWNERDRAW, > part->text would contain 32bit data (not a buffer ptr.) Conversely, if the previous style was not SBT_OWNERDRAW but the new one is you should free the text pointer. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: dlls/comctl32/status.c
by Mike McCormack 21 Jan '05

21 Jan '05

Ge van Geldorp wrote: > diff -u -r1.69 status.c > --- dlls/comctl32/status.c 9 Jan 2005 16:42:54 -0000 1.69 > +++ dlls/comctl32/status.c 13 Jan 2005 09:05:24 -0000 > @@ -650,6 +650,7 @@ > { > STATUSWINDOWPART *part=NULL; > BOOL changed = FALSE; > + WORD oldStyle; That should be a DWORD, shouldn't it? Mike

1 0

Re: RtlQueryRegistryValues and RtlCheckRegistryKey
by Robert Shearman 21 Jan '05

21 Jan '05

Ivan Leo Puoti wrote: > Implement RtlQueryRegistryValues, RtlCheckRegistryKey is implemented in > this patch as a free bonus. Thanks to the guys on IRC for their help. > > BTW when RtlCheckRegistryKey is called with the RTL_REGISTRY_HANDLE flag, > it always returns STATUS_SUCCESS, even if called with NULL, an invalid > HKEY, > a string containing rude words, a random number, and anything else I > could think of, > so that's why STATUS_SUCCESS is always returned when > RTL_REGISTRY_HANDLE is set. >+NTSTATUS WINAPI RtlCheckRegistryKey(IN ULONG RelativeTo, IN PWSTR Path) >+{ >+ HKEY handle; >+ NTSTATUS status = STATUS_SUCCESS; >+ if((!RelativeTo) && Path == NULL) >+ return STATUS_OBJECT_PATH_SYNTAX_BAD; >+ if(RelativeTo & RTL_REGISTRY_HANDLE) >+ return status; >+ if ((RelativeTo & 0xff) <= 5) >+ { >+ if(RelativeTo & RTL_REGISTRY_HANDLE) >+ handle = (HANDLE)Path; > > This test is redundant due to the test outside of this block. >+ else >+ status = RTL_GetKeyHandle(RelativeTo, Path, &handle); >+ if(status==STATUS_INVALID_HANDLE) >+ return STATUS_OBJECT_NAME_NOT_FOUND; >+ if(status==STATUS_ACCESS_DENIED) >+ return STATUS_ACCESS_DENIED; >+ if(status!=STATUS_SUCCESS) >+ return status; >+ } >+ else >+ return STATUS_INVALID_PARAMETER; >+ return status; >+} > > Rob

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
35
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel January 2005