- Wine-Devel - list.winehq.org

load_VDMX - is the check for bCharSet == -1 necessary?
by Troy Rollo Jan. 21, 2005

Jan. 21, 2005

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: [OLE #48] Restructure Unmarshaling Code
by Alexandre Julliard Jan. 21, 2005

Jan. 21, 2005

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 Jan. 21, 2005

Jan. 21, 2005

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 Jan. 21, 2005

Jan. 21, 2005

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 Jan. 21, 2005

Jan. 21, 2005

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 Jan. 21, 2005

Jan. 21, 2005

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

Re: wined3d updates
by Ann and Jason Edmeades Jan. 20, 2005

Jan. 20, 2005

Hi Oliver, D3DRESOURCETYPE WINAPI IWineD3DCubeTextureImpl_GetType(IWineD3DCubeTexture *iface) { - return IWineD3DResourceImpl_GetType((IWineD3DResource *)iface); + return IWineD3DResource_GetType((IWineD3DResource *)iface); } This is wrong (and others) - you'll end up in an infinite loop. You must calls the impl type if you are effectively casting the interface into one of the types it inherits from I haven't got chance to review the rest yet - I'm heading away for the weekend. I'll look at the rest on Mon if you want any comments. Jason

1 0

Font selection logic defective?
by Bill Medland Jan. 20, 2005

Jan. 20, 2005

(Huw?) Do I need to dig deeper to understand this or is there a defect in the logic. If there are ttf fonts available does that mean a poor ttf match will be selected even when a better x11drv font is available? Note that my font knowledge is quite minimal Context When I installed our product on a clean Red Hat Enterprise Linux 3 test machine it looked relatively acceptable. However on my own development machine (again RHEL3) for several texts the font was too large and overflowed the area that had been allocated for it. Then when I installed on Mandrake 10.0 I noticed the same large fonts. So I dug. On my machine (and probably on the Mandrake too; I don't know since I've trashed it) OpenOffice.org is installed. It installs /usr/share/fonts/openoffice, containing Vera*.ttf. As an example the Splash screen asks for an Arial font. My development machine runs through the fonts it knows about and selects the Bitstream Vera Sans, which is not a good match. The test machine has no ttf files to work from and so it reverses the Helvetica-Arial substitution (Hm!!! poor registry setup, I reckon) and performs a match for a Helvetica font and finds a much more acceptable font. So it seems to me that merely because OpenOffice.org has installed a couple of ttf fonts my development machine will select from a small list of ttf fonts and ignore a large list of x11 fonts. Am I correct? What should we do? Get the font matching logic to look at both the sets of fonts? Or add some sort of "Ignore these fonts" list in the Wine fonts area? -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

2 6

Re: Wine threads and TRY/CATCH macros and DCE threads and TRY/CATCH macros
by Juan Lang Jan. 20, 2005

Jan. 20, 2005

Hi Luke, I don't know is this is useful, but the TRY/CATCH stuff in particular is declared here: http://source.winehq.org/source/include/wine/exception.h and the Wine exception handling code is implemented here: http://source.winehq.org/source/dlls/ntdll/exception.c As Mike said, the Wine threading stuff is pretty complicated. Native applications unfortunately rely on things being exactly in the right place in the TEB, and DCE threads are unlikely to give us this. Peruse if you like http://source.winehq.org/source/include/thread.h and http://source.winehq.org/source/dlls/ntdll/thread.c --Juan __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

2 1

Re: RpcImpersonateClient (and ImpersonateNamedPipeClient)
by Juan Lang Jan. 20, 2005

Jan. 20, 2005

Hi Luke, you said: > that's where you'd need the cooperation of samba / samba tng: > it's got "SIDs" behind it, and "SIDs" means a SAMR server > and a NETLOGON server and an LSARPC server (and in the > case of windows 2000 interoperability, access to an Active > Directory Server). Another possibility is that we implement our own version of a SAM. Right now we just return a fake Administrator SID every time we're asked for one. But if we absolutely needed to, we could implement a local version and it needn't even be a separate process. The NT SAM registry is pretty well reverse engineered here: http://neworder.box.sk/files/nullak_ntsecurity/index.php > you can always still implement RpcImpersonateClient as a stub. Yah. I think that's more likely than that we go whole-hog on it. From experience, it's often more important to get things like parameters and error codes just the way Windows programs expect than it is to make a function "really work." By implementing a stubbed or local-only version, we can figure out all this stuff, and maybe make a full-blown version later. and later, > it _does_ mean careful design because i doubt very much whether people > will be happy to have samba tng as a dependency on Wine. Agreed. The focus for the Wine folks is generally, does this get my app to work? Unless it's fixing an app, not too many folks are likely to get real excited by anything. Feel free to point out what we've been missing. Patches speak louder than anything here :) --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

2 1