- wine-devel - winehq.org

Re: wine/dlls wininet/wininet.spec uxtheme/uxtheme ...
by Robert Shearman 12 Sep '05

12 Sep '05

Alexandre Julliard wrote: >Log message: > Specify 64-bit integers as double instead of long long in spec files > so that we get the correct number of arguments. > Wouldn't it be better to extend the spec format to allow for a longlong type instead? -- Rob Shearman

3 5

OOo2.0beta2 installer crashes wine-20050830 in MultiByteToWideChar in msi_process_pending_messages
by Dan Kegel 12 Sep '05

12 Sep '05

Here's a log of wine-20050830 crashing while running the setup.exe in the directory created by unpacking http://openoffice.mirrors.pair.com/ftp/stable/2.0beta2/OOo_2.0beta2_Win32In… (This is on FC3, with wine-20050830 compiled from source tarball, with Mike's patch to fix the ACTION_VerifyComponentForAction crash.) ... fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"StartServices" fixme:msi:ACTION_RegisterProduct Flesh out more information fixme:msi:ACTION_RegisterProduct Write real Estimated Size when we have it fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"MsiPublishAssemblies" fixme:msi:ACTION_PublishProduct Need to write more keys to the user registry wine: Unhandled exception (thread 000b), starting debugger... WineDbg starting on pid 0xa Unhandled exception: page fault on read access to 0x62840730 in 32-bit code (0x7bbb0953). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7bbb0953 ESP:7b92f2f8 EBP:7b92f304 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:7bbf75dc ECX:ffffffff EDX:00000000 ESI:ffffffff EDI:62840730 Stack dump: 0x7b92f2f8: 7b5b32a8 7b92f388 62840730 7b92f36c 0x7b92f308: 7b58b3a8 00000000 00000000 62840730 0x7b92f318: ffffffff 00000000 00000000 7bed88d6 0x7b92f328: 00000005 7bef1e18 7b92f6e8 7b92f37c 0x7b92f338: 7b92f408 7bed8a13 00000002 7b92f37c 0x7b92f348: 00000000 002d0043 7b58a73f 7b5b32a8 Backtrace: =>1 0x7bbb0953 MultiByteToWideChar+0x16f(page=0x0, flags=0x0, src=0x62840730, srclen=0xffffffff, dst=0x0, dstlen=0x0) [/home/dank/wine-20050830/dlls/kernel/locale.c:1527] in kernel32 (0x7b92f304) 2 0x7b58b3a8 WINPROC_MapMsg32ATo32W+0x270(hwnd=0x30024, msg=0x1a, pwparam=0x7b92f388, plparam=0x7b92f38c) [/home/dank/wine-20050830/dlls/user/winproc.c:668] in user32 (0x7b92f36c) 3 0x7b58f4e4 CallWindowProcA+0xa0(func=0x7b5e9226, hwnd=0x30024, msg=0x1a, wParam=0x2a, lParam=0x62840730) [/home/dank/wine-20050830/dlls/user/winproc.c:2952] in user32 (0x7b92f39c) 4 0x7b564d5c call_window_proc+0xd0(wparam=0x2a, lparam=0x62840730, unicode=0x0, same_thread=0x0) [/home/dank/wine-20050830/dlls/user/message.c:1520] in user32 (0x7b92f3fc) 5 0x7b56539b peek_message+0x26f(first=0x0, last=0xffffffff, flags=0x1) [/home/dank/wine-20050830/dlls/user/message.c:2053] in user32 (0x7b92f794) 6 0x7b5693de PeekMessageW(msg_out=0x7b92f7fc, hwnd=0x0, first=0x0, last=0x0, flags=0x1) [/home/dank/wine-20050830/dlls/user/message.c:2694] in user32 (0x7b92f7e0) 7 0x7b7f9812 msi_process_pending_messages+0x2a [/home/dank/wine-20050830/dlls/msi/dialog.c:1807] in msi (0x7b92f828) 8 0x7b7f990b msi_dialog_check_messages+0x4b(handle=0x0) [/home/dank/wine-20050830/dlls/msi/dialog.c:1835] in msi (0x7b92f838) 9 0x7b7e79fd ITERATE_Actions(row=0x7a77c6c0, param=0x7b92f898) [/home/dank/wine-20050830/dlls/msi/action.c:683] in msi (0x7b92f850) 10 0x7b806998 MSI_IterateRecords(view=0x7a77c730, count=0x0, func=0x7b7e7998, param=0x7b92f898) [/home/dank/wine-20050830/dlls/msi/msiquery.c:220] in msi (0x7b92f878) 11 0x7b7e7486 ACTION_ProcessExecSequence+0xc6 [/home/dank/wine-20050830/dlls/msi/action.c:744] in msi (0x7b92f8ac) 12 0x7b7ede17 ACTION_ExecuteAction(package=0x7bcc44a8) [/home/dank/wine-20050830/dlls/msi/action.c:3783] in msi (0x7b92f8dc) 13 0x7b7e772d ACTION_HandleStandardAction(rc=0x7b92f920, force=0x1) [/home/dank/wine-20050830/dlls/msi/action.c:817] in msi (0x7b92f90c) 14 0x7b7e78e5 ACTION_PerformUIAction+0x3d(package=0x7bcc44a8, action=0x7bd26018) [/home/dank/wine-20050830/dlls/msi/action.c:887] in msi (0x7b92f930) 15 0x7b7e79f2 ITERATE_Actions(row=0x7bd23690, param=0x7b92f9bc) [/home/dank/wine-20050830/dlls/msi/action.c:677] in msi (0x7b92f94c) 16 0x7b806998 MSI_IterateRecords+0x70(view=0x7bd22d68, count=0x0, func=0x7b7e7998, param=0x7b92f9bc) [/home/dank/wine-20050830/dlls/msi/msiquery.c:220] in msi (0x7b92f974) 17 0x7b7e8035 ACTION_DoTopLevelINSTALL+0x41d(package=0x7bcc44a8, szPackagePath=0x7bcc3c3e, szCommandLine=0x0, msiFilePath=0x7b92fa1c) [/home/dank/wine-20050830/dlls/msi/action.c:773] in msi (0x7b92f9f4) 18 0x7b8043b0 MsiInstallProductW+0x138(szPackagePath=0x7bcc3c3e, szCommandLine=0x0) [/home/dank/wine-20050830/dlls/msi/msi.c:233] in msi (0x7b92fe48) 19 0x7b94cbc4 main(argc=0x3, argv=0x7bc604f8) [/home/dank/wine-20050830/programs/msiexec/msiexec.c:298] in msiexec (0x7b92ff10) 20 0x7b94d785 __wine_spec_exe_entry(peb=0x7beff8c0) [/home/dank/wine-20050830/dlls/winecrt0/exe_entry.c:34] in msiexec (0x7b92ff2c) 21 0x7bbbf827 start_process+0xc3(arg=0x0) [/home/dank/wine-20050830/dlls/kernel/process.c:995] in kernel32 (0x7b92fff4) 22 0xf6fde6a1 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) 0x7bbb0953 MultiByteToWideChar+0x16f [/home/dank/wine-20050830/dlls/kernel/locale.c:1527] in kernel32: repne scasb %es:(%edi) 1527 if (srclen < 0) srclen = strlen(src) + 1; -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 2

GetOutlineTextMetrics on terminal without X
by FirmOS 12 Sep '05

12 Sep '05

Hi, we have a pdf generator running with wine, started on an X Server the results are as we expected. Running on a terminal without X, the fonts are rendered useless and acrobat complains about the file. I found out, that GetOutlineTextMetrics delivers very different results with our test programm: On an X Term: Font Arial, 20, PixperInch 96 Font:Arial OTM SIZE:246 OTM HEIGHT:1117 OTM ASCEND:905 OTM DESCEND:212 OTM INTLEAD:117 OTM EXTLEAD:33 OTM ACWIDTH:441 OTM MAXCW:2693 OTM WEIGHT:400 OTM OHANG:0 OTM DIGASPX:300 OTM DIGASPY:300 OTM ITALIC:0 OTM UL:0 OTM STRUCKO:0 OTM PFAMILY:39 OTM CSET:0 FILLER:0 FS SEL:64 FS TYPE:0 CSLOPERISE:1 CSLOPERUN:0 IT ANGLE:0 EMSQUARE:2048 ASCEND:728 DESENT:-210 LINEGAP:150 CAP EM HEIGHT:0 XHEIGHT:0 FONTBOX L:-665 FONTBOX T:1037 FONTBOX R:2028 FONTBOX B:-325 On a terminal without X: Font:Arial OTM SIZE:212 OTM HEIGHT:1 OTM ASCEND:0 OTM DESCEND:0 OTM INTLEAD:0 OTM EXTLEAD:0 OTM ACWIDTH:1 OTM MAXCW:1 OTM WEIGHT:500 OTM OHANG:0 OTM DIGASPX:1 OTM DIGASPY:1 OTM ITALIC:0 OTM UL:0 OTM STRUCKO:0 OTM PFAMILY:9 OTM CSET:0 FILLER:0 FS SEL:0 FS TYPE:0 CSLOPERISE:0 CSLOPERUN:0 IT ANGLE:0 EMSQUARE:0 ASCEND:0 DESENT:0 LINEGAP:0 CAP EM HEIGHT:0 XHEIGHT:0 FONTBOX L:0 FONTBOX T:0 FONTBOX R:0 FONTBOX B:0 Values are useless running without X. Is there any solution to this problem ? Setting fonts, etc ? You can get the test application from me. Thanks a lot, Franz Schober franz.schober(a)firmos.at

1 0

Re: hhctrl: Load the default Url in the HTML Pane [take 2]
by James Hawkins 12 Sep '05

12 Sep '05

On 9/9/05, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > Cleaned some smudges spotted by Jacek. > > Changelog > * Add the WebBrowser implementation. > * Load the default Url in the HTML Pane. > Is there anything wrong with this patch? -- James Hawkins

1 0

OOo2.0beta2 installer crashes wine-20050830 in ACTION_VerifyComponentForAction
by Dan Kegel 12 Sep '05

12 Sep '05

Here's a log of wine-20050830 crashing while running the setup.exe in the directory created by unpacking OOo_2.0beta2_Win32Intel_install.zip. (This is on FC3, with wine-20050830 compiled from source tarball.) Is this fixed in CVS, perhaps? ... fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"MoveFiles" fixme:msi:ACTION_InstallFiles Write DiskPrompt wine: Unhandled exception (thread 000b), starting debugger... WineDbg starting on pid 0xa Unhandled exception: page fault on read access to 0x00000510 in 32-bit code (0x7b800327). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7b800327 ESP:7b92f700 EBP:7b92f700 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:7b82a720 ECX:00000000 EDX:00000003 ESI:7b05ef18 EDI:7c228a70 Stack dump: 0x7b92f700: 7b92f748 7b7fc52f 7bcc51d8 00000000 0x7b92f710: 00000003 7b82edc8 7b82edc8 7b82edc8 0x7b92f720: 00000018 7b82edc8 7bcc5204 4d430002 0x7b92f730: 7b05efdc 00000000 7c097368 7b82a720 0x7b92f740: 7b05f000 00000012 7b92f778 7b7e772d 0x7b92f750: 7bcc51d8 004900d0 7b82edc8 00000001 Backtrace: =>1 0x7b800327 ACTION_VerifyComponentForAction+0xb(package=0x7bcc51d8, comp=0x0, check=0x3) [/home/dank/wine-20050830/dlls/msi/helpers.c:752] in msi (0x7b92f700) 2 0x7b7fc52f ACTION_InstallFiles(package=0x7bcc51d8) [/home/dank/wine-20050830/dlls/msi/files.c:676] in msi (0x7b92f748) 3 0x7b7e772d ACTION_HandleStandardAction+0x251(rc=0x7b92f78c, force=0x1) [/home/dank/wine-20050830/dlls/msi/action.c:817] in msi (0x7b92f778) 4 0x7b7e77fe ACTION_PerformAction+0x3e(package=0x7bcc51d8, action=0x7b05efe8, force=0x1) [/home/dank/wine-20050830/dlls/msi/action.c:866] in msi (0x7b92f79c) 5 0x7b7e8c35 execute_script [/home/dank/wine-20050830/dlls/msi/action.c:1279] in msi (0x7b92f7cc) 6 0x7b7ed9bc ACTION_InstallFinalize+0x20(package=0x7bcc51d8) [/home/dank/wine-20050830/dlls/msi/action.c:3599] in msi (0x7b92f7dc) 7 0x7b7e772d ACTION_HandleStandardAction(rc=0x7b92f820, force=0x0) [/home/dank/wine-20050830/dlls/msi/action.c:817] in msi (0x7b92f80c) 8 0x7b7e77fe ACTION_PerformAction+0x3e(package=0x7bcc51d8, action=0x7b05f5d0, force=0x0) [/home/dank/wine-20050830/dlls/msi/action.c:866] in msi (0x7b92f830) 9 0x7b7e7a59 ITERATE_Actions(row=0x7bd2d9b8, param=0x7b92f898) [/home/dank/wine-20050830/dlls/msi/action.c:679] in msi (0x7b92f850) 10 0x7b806990 MSI_IterateRecords+0x70(view=0x7bd28478, count=0x0, func=0x7b7e7998, param=0x7b92f898) [/home/dank/wine-20050830/dlls/msi/msiquery.c:220] in msi (0x7b92f878) 11 0x7b7e7486 ACTION_ProcessExecSequence+0xc6 [/home/dank/wine-20050830/dlls/msi/action.c:744] in msi (0x7b92f8ac) 12 0x7b7ede17 ACTION_ExecuteAction(package=0x7bcc51d8) [/home/dank/wine-20050830/dlls/msi/action.c:3783] in msi (0x7b92f8dc) 13 0x7b7e772d ACTION_HandleStandardAction(rc=0x7b92f920, force=0x1) [/home/dank/wine-20050830/dlls/msi/action.c:817] in msi (0x7b92f90c) 14 0x7b7e78e5 ACTION_PerformUIAction+0x3d(package=0x7bcc51d8, action=0x7bd255f8) [/home/dank/wine-20050830/dlls/msi/action.c:887] in msi (0x7b92f930) 15 0x7b7e79f2 ITERATE_Actions(row=0x7bd243c0, param=0x7b92f9bc) [/home/dank/wine-20050830/dlls/msi/action.c:677] in msi (0x7b92f94c) 16 0x7b806990 MSI_IterateRecords+0x70(view=0x7bd23a98, count=0x0, func=0x7b7e7998, param=0x7b92f9bc) [/home/dank/wine-20050830/dlls/msi/msiquery.c:220] in msi (0x7b92f974) 17 0x7b7e8035 ACTION_DoTopLevelINSTALL+0x41d(package=0x7bcc51d8, szPackagePath=0x7bcc496e, szCommandLine=0x0, msiFilePath=0x7b92fa1c) [/home/dank/wine-20050830/dlls/msi/action.c:773] in msi (0x7b92f9f4) 18 0x7b8043a8 MsiInstallProductW+0x138(szPackagePath=0x7bcc496e, szCommandLine=0x0) [/home/dank/wine-20050830/dlls/msi/msi.c:233] in msi (0x7b92fe48) 19 0x7b94cbc4 main(argc=0x3, argv=0x7bc604f8) [/home/dank/wine-20050830/programs/msiexec/msiexec.c:298] in msiexec (0x7b92ff10) 20 0x7b94d785 __wine_spec_exe_entry(peb=0x7beff8c0) [/home/dank/wine-20050830/dlls/winecrt0/exe_entry.c:34] in msiexec (0x7b92ff2c) 21 0x7bbbf827 start_process+0xc3(arg=0x0) [/home/dank/wine-20050830/dlls/kernel/process.c:995] in kernel32 (0x7b92fff4) 22 0xf6fde6a1 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) 0x7b800327 ACTION_VerifyComponentForAction+0xb [/home/dank/wine-20050830/dlls/msi/helpers.c:752] in msi: cmpl %edx,0x510(%ecx) 752 if (comp->Installed == check) -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 2

Re: DDraw: Better flag handling in SetCooperativeLevel
by Stefan Dösinger 11 Sep '05

11 Sep '05

Hello, This patch was still not applied. Is anything wrong with it? Does anyone have improvement suggestions? http://www.winehq.org/pipermail/wine-patches/2005-September/020551.html Thanks, Stefan Dösinger

1 0

Re: patches
by Ivan Leo Puoti 11 Sep '05

11 Sep '05

Eric Pouech wrote: > Ivan Leo Puoti a écrit : > >> Is anything wrong with these? >> http://www.winehq.com/pipermail/wine-patches/2005-September/020521.html >> http://www.winehq.com/pipermail/wine-patches/2005-September/020550.html > > > DDK isn't public information. Do we want Wine tree to be tainted by > non cleanly reversed engineered information ? > A+ > Excuse my language but WTF? The EULA of the DDK is very similar to that of the SDK, it's freely available for the cost of shipping and handling, and we can write our own DDK headers just as we can write the SDK ones. Ivan.

3 7

subauth.h
by Luke Kenneth Casson Leighton 11 Sep '05

11 Sep '05

oh maaan, that's really sad: i know what the stuff in subauth.h is all about, aaaaagh! it is incredibly similar to the MSRPC "NETLOGON" stuff that's implemented in cli_nt_login_interactive, cli_nt_login_network and cli_nt_login_generic in rpc_client/cli_login.c joy. l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

2 2

lib/netapi32/access.c and friends
by Luke Kenneth Casson Leighton 10 Sep '05

10 Sep '05

these are standard smbclient-related and/or rpcclient-related functions. NetUserGetInfo grabs the information from a NET_USER_INFO_3 structure which is "cached" from the MSV1_0.DLL access token for example (it's a really long story). NetShareEnum() is a LANMAN function, whoopeee what fun. in nt, there are _stacks_ of functions that tie pretty much directly into samba source code. l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 0

CreateProcess - wine is not doing it right
by Vitaliy Margolen 10 Sep '05

10 Sep '05

Now I really need you help people. Ok, here is the problem: LdrInitializeThunk is called from within start_process - the first thing to be executed in the new process's context. But this is not right. All what I found so far indicates, that LdrInitializeThunk should be queued as an APC, so it executes first no matter what. To complicate matters more, LdrInitializeThunk calling wineserver to stop the process if it's created with CREATE_SUSPENDED flag set. This is wrong. New process should never make it to it's main thread yet. And even worse, none of this happens where it should be - in ntdll. Functions such as NtCreateProcess and NtCreateThread are stubs. So when I'm looking on-line for any information, they all refer to these ntdll functions. I'm looking at this code and can't figure out what part of it belongs where. In kernel we have: 1. CreateProcessW that figures out what the executable is and calls the one of the other functions. That's talk about PE for now (create_process). 2. create_process: I'm not sure what the first part does (something about child). It looks to me that most of the first part including new_process wineserver call should be a part of NtCreateProcess. Everything else from create_process should go into NtCreateThread. 3. THREAD_InitStack shoul probably stay, except all the memory allocation goes to NtCreateThread. 4. start_process should stay the way it is, except delete call to LdrInitializeThunk. 5. LdrInitializeThunk - have no clue what should stay, and what should go somewhere else. Then we have a wineserver's init_process_done. Some parts of it looks like should go into create_process. But I'm not sure here ether. -- Best regards, Vitaliy

2 2

Re: patch for bug 2830 "MSFT_GetTdesc fails on methods with >= 30 params"
by Robert Shearman 10 Sep '05

10 Sep '05

White Snake wrote: >Hallo, >patch goes in typelib.c and is attached as a diff file against >typelib.c 1.167. > >Patch is divided in 3 parts: >1) in MSFT_DoFuncs: "reclength" of the function information record is stored >in a 16 bit int and not in a 8 bit int as previously supposed, using a 0x1ff >mask. Upper 16 bits contains the ordinal number of the function. Allocation of >the "recbuf" must be modified, to support larger data. > >2) Supporting a larger number of parameters means that the function "_invoke" >must be updated too. Maybe there is a smarter way than the one i've found. > >3) This is a "new" bug I discovered: in ITypeInfo_fnInvoke, after >_invoke, when you copy data back to pVarResult, you must not always do it. >Sometimes pVarResult is passet to the called function, so data is already in the exit >buffer. Check the comment few lines above "If pointer to variant, pass >reference it." > > Hi, As these are 3 different bug fixes, can you submit patches separately for each? -- Rob Shearman

1 0

listbox APIs
by Ivan Leo Puoti 10 Sep '05

10 Sep '05

I installed the R2 upgrade for win2k3 today, and the listbox tests don't pass anymore, as shown here http://test.winehq.com/data/200509101000/#2003 R2 is the one on the right. Ivan.

1 0

Possible solution for bug 3028
by Karsten Elfenbein 10 Sep '05

10 Sep '05

Hi, after a lot of trail & error I found out that in dlls/kernel/file.c line 1483-1484 the filename/mask is removed. After removing those two codelines the mask was handed over to wine_nt_to_unix_file_name (dlls/ntdll/directory.c) In the wine_nt_to_unix_file_name function it exits at the invalid char check in line 1418-1419 because a "*" is in the file name. If I comment out that loop the updated test case is producing the same error codes as windows xp. Does anyone have a better solution to solve this? (why is the mask removed in dlls/kernel/file.c? why is the "*" an illegal char in dlls/ntdll/directory.c check?) Karsten http://bugs.winehq.org/show_bug.cgi?id=3028

1 0

Re: Relax Marlett LOGFONT specification
by Huw Davies 10 Sep '05

10 Sep '05

On Fri, Sep 09, 2005 at 12:46:10PM +0100, Richard Cohen wrote: > Index: dlls/user/uitools.c > =================================================================== > RCS file: /home/wine/wine/dlls/user/uitools.c,v > retrieving revision 1.7 > diff -u -p -r1.7 uitools.c > --- dlls/user/uitools.c 7 Jul 2005 18:24:12 -0000 1.7 > +++ dlls/user/uitools.c 9 Sep 2005 11:41:49 -0000 > @@ -926,9 +926,9 @@ static BOOL UITOOLS95_DrawFrameCaption(H > return FALSE; > } > > - hf = CreateFontW(-SmallDiam, 0, 0, 0, FW_NORMAL, FALSE, FALSE, FALSE, > - SYMBOL_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, > - DEFAULT_QUALITY, FIXED_PITCH|FF_DONTCARE, glyphFontName); > + hf = CreateFontW(-SmallDiam, 0, 0, 0, FW_DONTCARE, FALSE, FALSE, FALSE, > + DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, > + DEFAULT_QUALITY, DEFAULT_PITCH|FF_DONTCARE, glyphFontName); > alignsave = SetTextAlign(dc, TA_TOP|TA_LEFT); > bksave = SetBkMode(dc, TRANSPARENT); > clrsave = GetTextColor(dc); We shouldn't need to do this. Fixing marlett.ttf would be the right thing to do. I'll try to look at this next week (but feel free to beat me to it!). Huw.

2 1

patches
by Ivan Leo Puoti 10 Sep '05

10 Sep '05

Is anything wrong with these? http://www.winehq.com/pipermail/wine-patches/2005-September/020521.html http://www.winehq.com/pipermail/wine-patches/2005-September/020550.html Ivan

1 0

Re: dlls/x11drv/mouse.c
by Alexandre Julliard 09 Sep '05

09 Sep '05

Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> writes: > We had a XFlush call in X11DRV_SetCursorPos before but it was removed for > some reason. This restores the call and fixes a regression in JInitiator > where the mouse position was being reported incorrectly. This sounds like it's just masking the problem. Do you know precisely why the mouse position is incorrect? -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: shell32: correct a failing test
by Saulius Krasuckas 09 Sep '05

09 Sep '05

* On Fri, 2 Sep 2005, Juan Lang wrote: > > This test was failing after the first time on Windows, so (hopefully) > fix it. > > ChangeLog: fix a test failing on Windows. Reported by Katerina Nizhnik. Unfortunately, this code pops up some window: --- wine/dlls/shell32/tests/shellpath.c 2005/08/16 16:00:07 1.11 +++ wine/dlls/shell32/tests/shellpath.c 2005/09/03 09:37:15 1.12 ... + shFileOp.pFrom = modifiedPath; + shFileOp.fFlags = FOF_NOCONFIRMATION | FOF_NOERRORUI | + FOF_SILENT; + SHFileOperationA(&shFileOp); which says: | Favorites is a Windows system folder and is required for Windows to run | properly. It cannot be deleted. And then exception of an access violation is thrown from the SHLWAPI.DLL. This happens on WinME. It seems here the flag FOF_NOERRORUI is ignored. I can't test this on other platforms and am going out of city for a weekend. Anyone feel free to fix it. :-P

1 0

Re: dll/winmm/playsound.c
by Robert Shearman 09 Sep '05

09 Sep '05

Ulrich Czekalla wrote: >fccType may be NULL or contain non-printable characters. Show output as hex >instead of characters. > >ChangeLog: > Ulrich Czekalla <ulrich(a)codeweavers.com> > Display fccType as hex instead of characters in trace output > > >------------------------------------------------------------------------ > >Index: dlls/winmm/playsound.c >=================================================================== >RCS file: /home/wine/wine/dlls/winmm/playsound.c,v >retrieving revision 1.17 >diff -u -p -r1.17 playsound.c >--- dlls/winmm/playsound.c 13 Jul 2005 11:59:15 -0000 1.17 >+++ dlls/winmm/playsound.c 8 Sep 2005 14:42:09 -0000 >@@ -328,7 +328,7 @@ static DWORD WINAPI proc_PlaySound(LPVOI > if (mmioDescend(hmmio, &mmckInfo, &ckMainRIFF, MMIO_FINDCHUNK)) > goto errCleanUp; > >- TRACE("Chunk Found ckid=%.4s fccType=%.4s cksize=%08lX \n", >+ TRACE("Chunk Found ckid=%.4s fccType=%08x cksize=%08lX \n", > (LPSTR)&mmckInfo.ckid, (LPSTR)&mmckInfo.fccType, mmckInfo.cksize); > > lpWaveFormat = HeapAlloc(GetProcessHeap(), 0, mmckInfo.cksize); >@@ -349,7 +349,7 @@ static DWORD WINAPI proc_PlaySound(LPVOI > if (mmioDescend(hmmio, &mmckInfo, &ckMainRIFF, MMIO_FINDCHUNK)) > goto errCleanUp; > >- TRACE("Chunk Found ckid=%.4s fccType=%.4s cksize=%08lX\n", >+ TRACE("Chunk Found ckid=%.4s fccType=%08x cksize=%08lX\n", > (LPSTR)&mmckInfo.ckid, (LPSTR)&mmckInfo.fccType, mmckInfo.cksize); > > I think these formats should be %04x as fccType is 2 bytes, not 4 bytes. -- Rob Shearman

3 2

Problem detecting libxslt
by Vincent Béron 09 Sep '05

09 Sep '05

Hi Mike, Doing ./configure on a RH8 box I get the following: checking libxslt/transform.h presence... yes configure: WARNING: libxslt/transform.h: present but cannot be compiled configure: WARNING: libxslt/transform.h: check for missing prerequisite headers? configure: WARNING: libxslt/transform.h: see the Autoconf documentation configure: WARNING: libxslt/transform.h: section "Present But Cannot Be Compiled" configure: WARNING: libxslt/transform.h: proceeding with the preprocessor's result configure: WARNING: libxslt/transform.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ## The problem looks to come from my transform.h needing xsltInternals.h being included first. I added an #ifdef HAVE_LIBXSLT_PATTERN_H include to the AC_CHECK_HEADERS which defines HAVE_LIBXSLT, as that file does #include "xsltInternals.h". I don't think we should directly include xsltInternals.h. Could you please comment if the attached patch is correct or not? I'll send it to wine-patches if acceptable. Thank you, Vincent

3 2

Re: kernel: Forward Atom APIs to ntdll
by Dmitry Timoshkov 09 Sep '05

09 Sep '05

"James Hawkins" <truiken(a)gmail.com> wrote: > + if (!table) > { > - req->atom = atom; > - req->table = table; > - wine_server_set_reply( req, full_name, sizeof(full_name) ); > - if (!wine_server_call_err( req )) > + ATOM_BASIC_INFORMATION *abi; > + > + size = sizeof(*abi) + MAX_ATOM_LEN * sizeof(WCHAR); > + abi = HeapAlloc(GetProcessHeap(), 0, size); Using HeapAlloc will considerably slowdown the function, you can safely allocate the necessary buffer on the stack. The same for GetAtomNameW. -- Dmitry.

1 0

appdb developers please read
by Ivan Leo Puoti 08 Sep '05

08 Sep '05

Hello, if you look at http://www.winehq.com/pipermail/wine-devel/2005-September/039837.html you'll see there was a project at some point to make a decent patch management system, but apparently due to the complexity of it and Newman being constantly overloaded with work, it never got anywhere, do you guys think it's doable/would you be willing to volunteer to build something of the sort? It would make wine development easier quicker (No more wondering "should I ask Alexandre about that patch? Is it too soon? should I wait a little longer? should I rewrite it? to be or not to be?") and would be great value for the project as it would probably make it easier for new developers to join. Ivan.

5 8

winnt32.exe on AMD64
by Tom Kennedy 08 Sep '05

08 Sep '05

All I have install Wine one an AMD 64 bit system running Redhat 3 update 2. I am trying to run the winnt32.exe prgram and I am getting the following load error. root@cert-amd1 ~]# wine "y:\amd64\winnt32.exe" Trying to load PE image for unsupported architecture (Unknown-8664) wine: could not load L"Y:\\amd64\\winnt32.exe" as Win32 binary [root@cert-amd1 ~]# I assue the 32 in the name of the executabel means it is a 32 bit binary, but wine is telling me it is not. Any clues as to why I am getting this error message. Thanks. Tom

2 1

Re: DSOUND: tolerate inexact conversion between different frequencies
by Robert Reif 08 Sep '05

08 Sep '05

Alex Villacís Lasso wrote: > During the winealsa tests, I am frequently annoyed by the following: > say, in playing a 11050Hz secondary buffer with an 8000Hz primary > buffer, the number of samples are converted form secondary->primary > and back. In the process, the number of consumed samples in the > secondary buffer drifts by a few frames from the actual value, and > this triggers the warning about "problem with underflow detection". > This patch allows a tolerance of up to 4 bytes before issuing the > message. > > Alex Villacís Lasso Or you could keep track of the round off errors (fractions) like winex does.

1 0

Re: Suggestions for improvement of the emulator
by Juan Lang 08 Sep '05

08 Sep '05

> This of course points to another problem with the existing system - > if a patch has been rejected, it should be a necessary consequence > that the submitter is informed with reasons - they shouldn't have to > be chasing up Alexandre to find out if the patch was rejected or > merely missed (which happens often). (snip) > What is needed is a system that records all patches, together with > their current status (NEW, APPLIED, REJECTED (with reasons), and > whatever other status), informs the submitter of any change, and does > not allow for a patch merely to be forgotten. What this misses is the most common status that causes us all to argue: uncomitted, because Alexandre's not sure about it. Perhaps he has a gut feeling that the approach is not right, but hasn't taken the time to identify any particular flaw. Perhaps it merits additional thought. Perhaps it's too big to review quickly. Perhaps he hopes the submitter will realize it's not up to snuff, and resubmit a better patch. There are probably other reasons, but these all come to mind from my own experience. And no system can appropriately capture that, when the answer is not as clearly defined as one of the above states. This is frustrating, and some people do seem to be put off by it. I have no idea how many potential contributors we lose this way. On the other hand, this is Alexandre's style, and we've all had to get used to it. Any alternative that involves Alexandre doing more work will get summarily rejected--he does a great deal as it is, more I think than any one of us would be willing to do (or perhaps could do). The only credible alternative is a multi-maintainer system. This could allow faster development of some larger features, or more invasive ones, or more exploratory ones. The problem I see with this is one of quality: We have a large code churn rate, and, corresponding with that, a high bug churn rate. That makes regression testing and choosing an appropriate wine version both very difficult. Having multiple maintainers multiplies the number of possible configurations. Yes, I know we could have official releases and the like, but who of us would resist trying out some as-yet-unmerged DX9 patch from Oliver, or experimenting with safedisc? Continuing in that vein, we're all lazy about merging in large patch sets. I'm merging in a fairly large set of changes at the moment, and the slower pace has allowed me to catch issues that may not have surfaced otherwise. Having several competing trees with substantial differences would, in my opinion, reduce the overall quality of the project. So I see a tradeoff between development speed and quality. We may be perceived as having issues with speed, but I think we do pretty well with our small stable of developers. We do have issues with quality, IMHO, so I'd be reluctant to endorse any radical changes. What does seem to work is picking up for Alexandre by reviewing patches on wine-devel, and helping newcomers along. We seem to have picked up a few lately that don't mind the public thrashing :) There does seem to be some more collaborative development going on lately, too. Perhaps we should be more vocal about how we do business, what kind of feedback to expect, and how to get help? --Juan ______________________________________________________ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/

7 7

ShellExecuteExW
by Ge van Geldorp 08 Sep '05

08 Sep '05

This patch: http://www.winehq.org/pipermail/wine-cvs/2005-August/017595.html broke execution of Control Panel items. The cpanel code would concatenate the name of the .cpl file and the display name and pass that in the lpFile member of the SHELLEXECUTEINFO struct. This is solved by passing .cpl in lpFile and display name in lpParameters. I ran into another problem: just before calling the execfunc(), any parameters would be appended to wszApplicationName. Unfortunately, sei_tmp.lpFile points to wszApplicationName at that point, so if the execfunc() fails (e.g. for a .cpl file) sei_tmp.lpFile is messed up. Fixing this allowed one of the todo tests to succeeed. Since looking at/tracing through the ShellExecuteEx code makes me scream in agony every time, I would appreciate a review of the patch below. Ge van Geldorp. Index: dlls/shell32/cpanelfolder.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/cpanelfolder.c,v retrieving revision 1.20 diff -u -r1.20 cpanelfolder.c --- dlls/shell32/cpanelfolder.c 27 Jul 2005 11:10:52 -0000 1.20 +++ dlls/shell32/cpanelfolder.c 8 Sep 2005 21:38:08 -0000 @@ -970,6 +970,7 @@ SHELLEXECUTEINFOW sei_tmp; PIDLCPanelStruct* pcpanel; WCHAR path[MAX_PATH]; + WCHAR params[MAX_PATH]; BOOL ret; int l; @@ -990,12 +991,13 @@ /* pass applet name to Control_RunDLL to distinguish between applets in one .cpl file */ path[l++] = '"'; - path[l++] = ' '; + path[l] = '\0'; - MultiByteToWideChar(CP_ACP, 0, pcpanel->szName+pcpanel->offsDispName, -1, path+l, MAX_PATH); + MultiByteToWideChar(CP_ACP, 0, pcpanel->szName+pcpanel->offsDispName, -1, params, MAX_PATH); memcpy(&sei_tmp, psei, sizeof(sei_tmp)); sei_tmp.lpFile = path; + sei_tmp.lpParameters = params; sei_tmp.fMask &= ~SEE_MASK_INVOKEIDLIST; sei_tmp.lpVerb = wCplopen; Index: dlls/shell32/shlexec.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/shlexec.c,v retrieving revision 1.71 diff -u -r1.71 shlexec.c --- dlls/shell32/shlexec.c 8 Sep 2005 18:54:52 -0000 1.71 +++ dlls/shell32/shlexec.c 8 Sep 2005 21:38:09 -0000 @@ -1263,9 +1263,10 @@ lpFile = wfileName; + strcpyW(wcmd, wszApplicationName); if (sei_tmp.lpParameters[0]) { - strcatW(wszApplicationName, wSpace); - strcatW(wszApplicationName, wszParameters); + strcatW(wcmd, wSpace); + strcatW(wcmd, wszParameters); } /* We set the default to open, and that should generally work. @@ -1273,7 +1274,7 @@ if (!sei_tmp.lpVerb) sei_tmp.lpVerb = wszOpen; - retval = execfunc(wszApplicationName, NULL, FALSE, &sei_tmp, sei); + retval = execfunc(wcmd, NULL, FALSE, &sei_tmp, sei); if (retval > 32) return TRUE; Index: dlls/shell32/tests/shlexec.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/tests/shlexec.c,v retrieving revision 1.5 diff -u -r1.5 shlexec.c --- dlls/shell32/tests/shlexec.c 23 Aug 2005 09:37:30 -0000 1.5 +++ dlls/shell32/tests/shlexec.c 8 Sep 2005 21:38:09 -0000 @@ -704,9 +704,7 @@ okChildInt("argcA", 5); okChildString("argvA3", "Open"); sprintf(filename, "%s\\test file.shlexec", tmpdir); - todo_wine { okChildPath("argvA4", filename); - } sprintf(filename, "%s\\test_shortcut_exe.lnk", tmpdir); rc=shell_execute_ex(SEE_MASK_NOZONECHECKS, NULL, filename, NULL, NULL);

1 0

Spam in wine-announce?
by Anssi Hannula 08 Sep '05

08 Sep '05

This just came in from wine-announce list. -- Anssi Hannula julliard(a)winehq.com wrote: > Warning: This message has had one or more attachments removed > Warning: (document.txt .scr, document.zip). > Warning: Please read the "yoursite-Attachment-Warning.txt" attachment(s) for more information. > > Here are your banks documents. > > > > ------------------------------------------------------------------------ > > This is a message from the MailScanner E-Mail Virus Protection Service > ---------------------------------------------------------------------- > The original e-mail attachment "document.zip" > was believed to be infected by a virus and has been replaced by this warning > message. > > If you wish to receive a copy of the *infected* attachment, please > e-mail helpdesk and include the whole of this message > in your request. Alternatively, you can call them, with > the contents of this message to hand when you call. > > At Thu Sep 8 11:27:12 2005 the virus scanner said: > ClamAV: document.txt .scr contains Worm.Mytob.H-1 > MailScanner: Windows Screensavers are often used to hide viruses (document.txt .scr) > > Note to Help Desk: Look on the yoursite MailScanner in /var/spool/MailScanner/quarantine/20050908 (message j88GR1Ks012044).

3 2

Need ideas about ntoskrnl
by Vitaliy Margolen 08 Sep '05

08 Sep '05

We need ntoskrnl to run some subset of drivers on wine. Notably cd protection drivers. They are not a hardware drivers, but a means to access something that is not accessible from user space. So in a sense ntoskrnl is just a process to run those drivers in, and send/receive requests to/from those drivers. You need to keep in mind that this is a kernel level, so some things will not work, and some things have to work that normally do not in the user space. Also ntoskrnl for windows _is_ what wineserver for wine. User space programs talk to these drivers in the following way: 1. At the start up, driver creates symbolic link in "\DosDevices\something". 2. Program calls CreateFile("\\.\something",..) to get a handle to the device. 3. Uses ReadFile/WriteFile/DeviceIoControl on that handle. (For now we need only DeviceIoControl. Read/Write could be added later.) Here is a list of the most pressing problem and the way to solve them. Any ideas and comments will be greatly appreciated, Vitaliy. Problems: 1. Open handle to a device - NtCreateFile. 2. Call DeviceIoControl on a device. (This also includes (1) since we need to know that this is not a cdrom, vxd or something else.) 3. Resolve user space handle to the DEVICE_OBJECT. (Assuming that we don't call ntoskrnl through wineserver). Solutions for (1): 1.1. Use a hack to determine that passed name is a device name. (Device names don't have colon in them). 1.2. Check against all possible names other then device names. (A:..Z:, etc.) 1.3. Try it last if all else fails. (since name spaces don't intersect this should work.) 1.4. Use object manager to lookup the name to find out what is it. (Unless we open all handles using this method it will add one extra wineserver call.) Solutions for (2): ntdll->ntoskrnl 2.1. Use named pipe to communicate with ntoskrnl process. Pass commands over the pipe in internal format. 2.2. Use UNIX IPC to talk to ntoskrnl. (pipe, socket, etc.) ntdll->wineserver->ntoskrnl 2.3. Call wineserver which will call ntoskrnl using 2.1. or 2.2. 2.4. Call wineserver which will call ntoskrnl using proper IoXXX functions from ntoskrnl to create an IRP. ntoskrnl will process them and notify wineserver when call is complete. (This is the most complicated and closer represents what windows does. There are still a problem communicating to ntoskrnl. It is probably the way to go in the future. But that will require number of things implemented which are not trivial.) Solutions for (2): MSDN quote: "Note that handles are not used for accessing device objects or driver objects." 3.1. Use wineserver to resolve handle to some internal identifier and pass it to ntoskrnl. 3.2. Pass handle and calling process id (pid, global handle, etc.) to ntoskrnl. ntoskrnl will call wineserver to resolve handle to internal id. (This handle will have to be either cached, or it will have to be created for every call.) 3.3. (requires 2.3. or 2.4.) Wineserver will resolve handle and pass internal id to ntoskrnl. (Unless we want wineserver do much more than that.)

14 31

wineserver keeps running after wine exits
by ivan vadovič 08 Sep '05

08 Sep '05

Hi, This is what's going on using wine-20050725 and 20050830 under gentoo: $ ls -l user.reg; wine winecfg; ls -l user.reg # winecfg did some changes ... 7517 Sep 2 16:00 user.reg ... 7517 Sep 2 16:00 user.reg $ sleep 5 $ ls -l user.reg ... 7629 Sep 2 16:13 user.reg So, wine exits, but wineserver keeps running and finishes a second or two later. As a result it rewrites the config files AFTER the command completion. That confuses scripts reading and manipulating the registers. Well, it confuses wine too, if I try to run wine immediately after exiting wine. Is that on purpose? Is there any workaround? Am I doing something wrong here? Ivan

2 1

Re: hhctrl: Load the default Url in the HTML Pane
by Jacek Caban 08 Sep '05

08 Sep '05

Hello. James Hawkins wrote: >Hi, > >Changelog >* Add the WebBrowser implementation. >* Load the default Url in the HTML Pane. > > ... >+static HRESULT STDMETHODCALLTYPE UI_ShowContextMenu(IDocHostUIHandler *iface, DWORD dwID, POINT __RPC_FAR *ppt, IUnknown __RPC_FAR *pcmdtReserved, IDispatch __RPC_FAR *pdispReserved) > > You don't need to add __RPC_FAR here. Same in few other places. >+BOOL WB_EmbedBrowser(WBInfo *pWBInfo, HWND hwndParent) >+{ >+ IOleClientSiteImpl *iOleClientSiteImpl; >+ IOleObject *browserObject; >+ IWebBrowser2 *webBrowser2; >+ HRESULT hr; >+ RECT rc; >+ >+ static const WCHAR hostNameW[] = {'H','o','s','t',' ','N','a','m','e',0}; >+ >+ iOleClientSiteImpl = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, >+ sizeof(IOleClientSiteImpl)); >+ if (!iOleClientSiteImpl) >+ return FALSE; >+ >+ iOleClientSiteImpl->ref = 0; >+ iOleClientSiteImpl->lpVtbl = &MyIOleClientSiteTable; >+ iOleClientSiteImpl->lpvtblOleInPlaceSite = &MyIOleInPlaceSiteTable; >+ iOleClientSiteImpl->lpvtblOleInPlaceFrame = &MyIOleInPlaceFrameTable; >+ iOleClientSiteImpl->hwndWindow = hwndParent; >+ iOleClientSiteImpl->lpvtblDocHostUIHandler = &MyIDocHostUIHandlerTable; >+ >+ hr = OleCreate(&CLSID_WebBrowser, &IID_IOleObject, OLERENDER_DRAW, 0, >+ (IOleClientSite *)iOleClientSiteImpl, &MyIStorage, >+ (void **)&browserObject); >+ if (FAILED(hr)) goto error; >+ >+ /* make the browser object accessible to the IOleClientSite implementation */ >+ iOleClientSiteImpl->pBrowserObject = browserObject; >+ IOleObject_SetHostNames(browserObject, hostNameW, 0); >+ >+ GetClientRect(hwndParent, &rc); >+ >+ hr = OleSetContainedObject((struct IUnknown *)browserObject, TRUE); >+ if (FAILED(hr)) goto error; >+ >+ hr = OleSetContainedObject((struct IUnknown *)browserObject, TRUE); >+ if (FAILED(hr)) goto error; > > Why do you call OleSetContainedObject twice? >+ >+ hr = IOleObject_DoVerb(browserObject, OLEIVERB_SHOW, NULL, >+ (IOleClientSite *)iOleClientSiteImpl, >+ -1, hwndParent, &rc); >+ if (FAILED(hr)) goto error; >+ >+ >+ hr = IOleObject_QueryInterface(browserObject, &IID_IWebBrowser2, >+ (void **)&webBrowser2); >+ if (SUCCEEDED(hr)) >+ { >+ IWebBrowser2_put_Left(webBrowser2, 0); >+ IWebBrowser2_put_Top(webBrowser2, 0); >+ IWebBrowser2_put_Width(webBrowser2, rc.right); >+ IWebBrowser2_put_Height(webBrowser2, rc.bottom); >+ >+ pWBInfo->pOleClientSite = (IOleClientSite *)iOleClientSiteImpl; >+ pWBInfo->pBrowserObject = browserObject; >+ pWBInfo->pWebBrowser2 = webBrowser2; >+ pWBInfo->hwndParent = hwndParent; >+ >+ return TRUE; >+ } >+ >+error: >+ WB_UnEmbedBrowser(pWBInfo); >+ >+ if (webBrowser2) >+ IWebBrowser2_Release(webBrowser2); >+ >+ HeapFree(GetProcessHeap(), 0, iOleClientSiteImpl); >+ >+ return FALSE; >+} >+ > ... >+ >+BOOL WB_Navigate(WBInfo *pWBInfo, LPCWSTR szUrl) >+{ >+ IWebBrowser2 *pWebBrowser2 = pWBInfo->pWebBrowser2; >+ VARIANT myURL; >+ >+ if (!pWebBrowser2) >+ return FALSE; >+ >+ VariantInit(&myURL); >+ myURL.n1.n2.vt = VT_BSTR; >+ >+ myURL.n1.n2.n3.bstrVal = SysAllocString(szUrl); > > It's better to use macros to use VARIANT type: V_VT(&myURL) = VT_BSTR; V_BSTR(&myURL) =SysAllocString(szUrl); >+ >+ if (!myURL.n1.n2.n3.bstrVal) >+ return FALSE; >+ >+ IWebBrowser2_Navigate2(pWebBrowser2, &myURL, 0, 0, 0, 0); >+ VariantClear(&myURL); >+ >+ return TRUE; >+} >+ > > Jacek

1 0

Re: dlls/shell32/iconcache.c
by Dmitry Timoshkov 08 Sep '05

08 Sep '05

"Ge van Geldorp" <gvg(a)reactos.com> wrote: > --- dlls/shell32/iconcache.c 26 Aug 2005 10:05:34 -0000 1.92 > +++ dlls/shell32/iconcache.c 7 Sep 2005 21:02:00 -0000 > @@ -351,7 +351,17 @@ > > if ( INVALID_INDEX == index ) > { > - ret = SIC_LoadIcon (sSourceFile, dwSourceIndex, dwFlags); > + if (0 == strcmpW (sSourceFile, swShell32Name) && Better do a case insensitive comparison of file names. -- Dmitry.

1 0

Re: Help with a patch needed
by Oliver Stieber 08 Sep '05

08 Sep '05

--- Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hi, > I've sent the following patch to wine-patches approximatly 2 weeks ago, and it > wasn't applied nor any suggestions for improvement where given. As suggested > by some people in another thread, I send it to wine-devel to ask for help. > > This patch adds handling for the DDSCL_SETFOCUSWINDOW flag in > DirectDraw7::SetCooperativeLevel. It also adds some tests which test the > reactions of Windows to these flag. > > I've stumbled across the DDSCL_SETFOCUSWINDOW flag while debugging Empire > Earth. This game cancels with msvcrt_abort if SetCooperativeLevel returns an > error. > > Any comments / Suggestions from the DirectX people? > Seems ok to me, the logging could do with a but of tarting up. It's usually really handy if the instance is logged with each FIXME / TRACE e.g. instead of FIXME("Poorly handled flag DDSCL_SETFOCUSWINDOW\n"); use FIXME("(%p) : Poorly handled flag DDSCL_SETFOCUSWINDOW\n", This); It's also usefull to log whenever a function returns an error. e.g. if (!(cooplevel & (DDSCL_EXCLUSIVE|DDSCL_NORMAL|DDSCL_SETFOCUSWINDOW))) { TRACE("(%p) : Call to SetCooperativeLevel failed: cooplevel != DDSCL_EXCLUSIVE|DDSCL_NORMAL|DDSCL_SETFOCUSWINDOW, returning DDERR_INVALIDPARAMS); return DDERR_INVALIDPARAMS; } that way if returning an error is causing something else to fail it's fairly easy to pick up. Oliver. > Thanks, > Stefan Dösinger > > ? dlls/ddraw/tests/cooplevels.c > Index: dlls/ddraw/ddraw_main.c > =================================================================== > RCS file: /home/wine/wine/dlls/ddraw/ddraw_main.c,v > retrieving revision 1.8 > diff -u -p -r1.8 ddraw_main.c > --- dlls/ddraw/ddraw_main.c 26 Jul 2005 20:10:51 -0000 1.8 > +++ dlls/ddraw/ddraw_main.c 25 Aug 2005 13:53:20 -0000 > @@ -1116,13 +1116,54 @@ Main_DirectDraw_SetCooperativeLevel(LPDI > * created." Otherwise the window can be changed??? > * > * This appears to be wrong - comment it out for now. > + * This seems to be true at least for DDSCL_SETFOCUSWINDOW > + * It looks like Windows doesn't store the HWND in all cases, > + * probably if DDSCL_NORMAL is specified, but that's not sure > if (This->window) > return DDERR_HWNDALREADYSET; > */ > > - if (!(cooplevel & (DDSCL_EXCLUSIVE|DDSCL_NORMAL))) > - return DDERR_INVALIDPARAMS; > + /* DDSCL_EXCLUSIVE or DDSCL_NORMAL or DDSCL_SETFOCUSWINDOW must be given */ > + if (!(cooplevel & (DDSCL_EXCLUSIVE|DDSCL_NORMAL|DDSCL_SETFOCUSWINDOW))) > + return DDERR_INVALIDPARAMS; > > + /* Device window and focus Window. They only really matter in a > + * Multi-Monitor application, but some games specify them and we > + * have to react correctly. */ > + if(cooplevel & DDSCL_SETFOCUSWINDOW) > + { > + /* This flag is a biest: It is only valid when DDSCL_NORMAL has been set > + * or no hwnd is set and no other flags are allowed, except DDSCL_NOWINDOWCHANGES > + */ > + if(This->window) > + if(!(This->cooperative_level & DDSCL_NORMAL)) return DDERR_HWNDALREADYSET; > + if((cooplevel != DDSCL_SETFOCUSWINDOW)) > + if(cooplevel != (DDSCL_SETFOCUSWINDOW | DDSCL_NOWINDOWCHANGES) ) return > DDERR_INVALIDPARAMS; > + > + /* Don't know what exactly to do, but it's perfectly valid > + * to pass DDSCL_SETFOCUSWINDOW only */ > + FIXME("Poorly handled flag DDSCL_SETFOCUSWINDOW\n"); > + > + /* Store the flag in the cooperative level. I don't think that all other > + * flags should be overwritten, so just add it > + * (In the most cases this will be DDSCL_SETFOCUSWINDOW | DDSCL_NORMAL) */ > + cooplevel |= DDSCL_SETFOCUSWINDOW; > + > + return DD_OK; > + } > + > + /* DDSCL_EXCLUSE mode requires DDSCL_FULLSCREEN and vice versa */ > + if((cooplevel & DDSCL_EXCLUSIVE) && !(cooplevel & DDSCL_FULLSCREEN)) > + return DDERR_INVALIDPARAMS; > + /* The other case is checked above */ > + > + /* Unhandled flags. Give a warning */ > + if(cooplevel & DDSCL_SETDEVICEWINDOW) > + FIXME("Unhandled flag DDSCL_SETDEVICEWINDOW.\n"); > + if(cooplevel & DDSCL_CREATEDEVICEWINDOW) > + FIXME("Unhandled flag DDSCL_CREATEDEVICEWINDOW.\n"); > + > + /* Perhaps the hwnd is only set in DDSCL_EXLUSIVE and DDSCL_FULLSCREEN mode. Not sure */ > This->window = hwnd; > This->cooperative_level = cooplevel; > > Index: dlls/ddraw/tests/Makefile.in > =================================================================== > RCS file: /home/wine/wine/dlls/ddraw/tests/Makefile.in,v > retrieving revision 1.5 > diff -u -p -r1.5 Makefile.in > --- dlls/ddraw/tests/Makefile.in 7 Jun 2005 21:34:59 -0000 1.5 > +++ dlls/ddraw/tests/Makefile.in 25 Aug 2005 13:53:20 -0000 > @@ -9,7 +9,8 @@ EXTRALIBS = -ldxguid > CTESTS = \ > d3d.c \ > ddrawmodes.c \ > - dsurface.c > + dsurface.c \ > + cooplevels.c > > @MAKE_TEST_RULES@ > > --- /dev/null 2005-08-25 09:49:19.469757400 +0000 > +++ dlls/ddraw/tests/cooplevels.c 2005-08-25 15:26:27.000000000 +0000 > @@ -0,0 +1,187 @@ > +/* > + * Unit tests for ddraw cooperative levels > + * > + * Copyright (C) 2005 Stefan Dösinger > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > + */ > + > +#include <assert.h> > +#include "wine/test.h" > +#include "ddraw.h" > + > +static LPDIRECTDRAW lpDD = NULL; > +static WNDCLASS wc; > +static HWND hwnd; > + > +static void createwindow(void) > +{ > + wc.style = CS_HREDRAW | CS_VREDRAW; > + wc.lpfnWndProc = DefWindowProcA; > + wc.cbClsExtra = 0; > + wc.cbWndExtra = 0; > + wc.hInstance = GetModuleHandleA(0); > + wc.hIcon = LoadIconA(wc.hInstance, IDI_APPLICATION); > + wc.hCursor = LoadCursorA(NULL, IDC_ARROW); > + wc.hbrBackground = (HBRUSH) GetStockObject(BLACK_BRUSH); > + wc.lpszMenuName = NULL; > + wc.lpszClassName = "TestWindowClass"; > + if(!RegisterClassA(&wc)) > + assert(0); > + > + hwnd = CreateWindowExA(0, "TestWindowClass", "TestWindowClass", > + WS_POPUP, 0, 0, > + GetSystemMetrics(SM_CXSCREEN), > + GetSystemMetrics(SM_CYSCREEN), > + NULL, NULL, GetModuleHandleA(0), NULL); > + assert(hwnd != NULL); > + > + ShowWindow(hwnd, SW_HIDE); > + UpdateWindow(hwnd); > + SetFocus(hwnd); > + > +} > + > +static void createdirectdraw(void) > +{ > + HRESULT rc; > + > + rc = DirectDrawCreate(NULL, &lpDD, NULL); > + ok(rc==DD_OK,"DirectDrawCreate returned: %lx\n",rc); > +} > + > + > +static void releasedirectdraw(void) > +{ > + if( lpDD != NULL ) > + { > + IDirectDraw_Release(lpDD); > + lpDD = NULL; > + } > +} > + > +static void testcooperativelevels_normal(void) > +{ > + HRESULT rc; > + > + /* Do some tests with DDSCL_NORMAL mode */ > + > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_NORMAL); > + ok(rc==DD_OK,"SetCooperativeLevel(DDSCL_NORMAL) returned: %lx\n",rc); > + > + /* Set the focus window */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_SETFOCUSWINDOW); > + ok(rc==DD_OK,"SetCooperativeLevel(DDSCL_SETFOCUSWINDOW) returned: %lx\n",rc); > + > + /* Set the focus window a secound time*/ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_SETFOCUSWINDOW); > + ok(rc==DD_OK,"SetCooperativeLevel(DDSCL_SETFOCUSWINDOW) the secound time returned: > %lx\n",rc); > + > + /* Test DDSCL_SETFOCUSWINDOW with the other flags. They should all fail, except of > DDSCL_NOWINDOWCHANGES */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_NORMAL | DDSCL_SETFOCUSWINDOW); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_NORMAL | DDSCL_SETFOCUSWINDOW) > returned: %lx\n",rc); > + > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN | DDSCL_SETFOCUSWINDOW); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN | > DDSCL_SETFOCUSWINDOW) returned: %lx\n",rc); > + > + /* This one succeeds */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_NOWINDOWCHANGES | DDSCL_SETFOCUSWINDOW); > + ok(rc==DD_OK,"SetCooperativeLevel(DDSCL_NOWINDOWCHANGES | DDSCL_SETFOCUSWINDOW) returned: > %lx\n",rc); > + > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_MULTITHREADED | DDSCL_SETFOCUSWINDOW); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_MULTITHREADED | DDSCL_SETFOCUSWINDOW) > returned: %lx\n",rc); > + > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_FPUSETUP | DDSCL_SETFOCUSWINDOW); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_FPUSETUP | DDSCL_SETFOCUSWINDOW) > returned: %lx\n",rc); > + > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_FPUPRESERVE | DDSCL_SETFOCUSWINDOW); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_FPUPRESERVE | DDSCL_SETFOCUSWINDOW) > returned: %lx\n",rc); > + > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_ALLOWREBOOT | DDSCL_SETFOCUSWINDOW); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_ALLOWREBOOT | DDSCL_SETFOCUSWINDOW) > returned: %lx\n",rc); > + > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_ALLOWMODEX | DDSCL_SETFOCUSWINDOW); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_ALLOWMODEX | DDSCL_SETFOCUSWINDOW) > returned: %lx\n",rc); > + > + /* Set the device window without any other flags. Should give an error */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_SETDEVICEWINDOW); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_SETDEVICEWINDOW) returned: > %lx\n",rc); > + > + /* Set device window with DDSCL_NORMAL */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_NORMAL | DDSCL_SETDEVICEWINDOW); > + ok(rc==DD_OK,"SetCooperativeLevel(DDSCL_NORMAL | DDSCL_SETDEVICEWINDOW) returned: > %lx\n",rc); > + > + /* Also set the focus window. Should give an error */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_ALLOWMODEX | DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN | DDSCL_SETDEVICEWINDOW | > DDSCL_SETFOCUSWINDOW); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_NORMAL | DDSCL_SETDEVICEWINDOW | > DDSCL_SETFOCUSWINDOW) returned: %lx\n",rc); > + > + /* All done */ > +} > + > +static void testcooperativelevels_exclusive(void) > +{ > + HRESULT rc; > + > + /* Do some tests with DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN mode */ > + > + /* Try to set exclusive mode only */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_EXCLUSIVE); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_EXCLUSIVE) returned: %lx\n",rc); > + > + /* Full screen mode only */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_FULLSCREEN); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_FULLSCREEN) returned: %lx\n",rc); > + > + /* Full screen mode + exclusive mode */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_FULLSCREEN | DDSCL_EXCLUSIVE); > + ok(rc==DD_OK,"SetCooperativeLevel(DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN) returned: %lx\n",rc); > + > + /* Set the focus window. Should fail */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_SETFOCUSWINDOW); > + ok(rc==DDERR_HWNDALREADYSET,"SetCooperativeLevel(DDSCL_SETFOCUSWINDOW) returned: > %lx\n",rc); > + > + > + /* All done */ > +} > +START_TEST(cooplevels) > +{ > + createwindow(); > + > + createdirectdraw(); > + testcooperativelevels_normal(); > + releasedirectdraw(); > + > + createdirectdraw(); > + testcooperativelevels_exclusive(); > + releasedirectdraw(); > +} > > > ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

2 1

Mails get doubled (at wine.codeweavers.com ?)
by Detlef Riekenberg 08 Sep '05

08 Sep '05

Hi. While reading the List, I found a Transfer-Problem: Mails are send once (same ID), get doubled on the Path and arrived twice. And Mysterious: Only one Version is in the Archiv! ------- cut ----- Example 1: http://www.winehq.org/pipermail/wine-devel/2005-September/039849.html One Version: Received: from lnx131.hrz.tu-darmstadt.de ([130.83.174.25] ident=root) by wine.codeweavers.com with esmtp (Exim 4.50) id 1ECuZm-0006Ev-KU for wine-devel(a)winehq.org; Wed, 07 Sep 2005 02:42:41 -0500 Received: from mailserver3.hrz.tu-darmstadt.de (lnx115.hrz.tu-darmstadt.de [130.83.174.27]) by lnx131.hrz.tu-darmstadt.de (8.12.10/8.12.10) with ESMTP id j877XlRN027997; Wed, 7 Sep 2005 09:33:47 +0200 Other Version: Received: from lnx131.hrz.tu-darmstadt.de ([130.83.174.25] ident=root) by wine.codeweavers.com with esmtp (Exim 4.50) id 1ECuUQ-0005j4-6t for wine-devel(a)winehq.org; Wed, 07 Sep 2005 02:37:08 -0500 Received: from mailserver3.hrz.tu-darmstadt.de (lnx115.hrz.tu-darmstadt.de [130.83.174.27]) by lnx131.hrz.tu-darmstadt.de (8.12.10/8.12.10) with ESMTP id j877XlRN027997; Wed, 7 Sep 2005 09:33:47 +0200 ------- cut ----- Example 2: http://www.winehq.org/pipermail/wine-devel/2005-September/039862.html One Version: Received: from sgi2.kievinfo.com ([65.100.132.146]) by wine.codeweavers.com with esmtp (Exim 4.50) id 1ED10P-0008Qr-TC for wine-devel(a)winehq.org; Wed, 07 Sep 2005 09:34:36 -0500 Received: (qmail 18371 invoked by uid 89); 7 Sep 2005 14:34:16 -0000 Other Version: Received: from sgi2.kievinfo.com ([65.100.132.146]) by wine.codeweavers.com with esmtp (Exim 4.50) id 1ED10P-0008Qq-Rc for wine-devel(a)winehq.com; Wed, 07 Sep 2005 09:34:32 -0500 Received: (qmail 18371 invoked by uid 89); 7 Sep 2005 14:34:16 -0000 ------- cut ----- What's wrong ? -- By By ... ... Detlef

3 4

Re: Perform automatic bitmap font configuration. Take 3
by Detlef Riekenberg 07 Sep '05

07 Sep '05

Dmitry Timoshkov wrote: > create an appropriate locale setup: > ACP/OEMCP/MACCP and fonts. Great Idea ! > +;; File generated automatically from dlls/kernel/nls/*.nls; do not edit! Would you like to add the script to CVS also? > +;; This should be run through setupapi: > +;; rundll32 setupapi.dll,InstallHinfSection LCID 0 wine_intl.inf > +;; where LCID is locale id, for instance 00000409 for US English. Why did you not use the first Part of $LANG / $LANGUAGE (maybe with a Prefix) as Index? (LOCALE_SISO639LANGNAME and LOCALE_SISO3166CTRYNAME) It's easy to calculate the Index in wineprefixcreate with "cut" and it works for everybody. What about "Default" and "InstallLanguage" in "System\CurrentControlSet\Control\Nls\Language"? (LOCALE_IDEFAULTLANGUAGE) -- By By ... ... Detlef

1 0

Printing Problems
by josie＠mbstemps.com 07 Sep '05

07 Sep '05

I have been trying to print reports in Landscape and every time a line hits about 122 characters it cuts out 5 characters and then picks up with the rest of the line, example 'Wine Printing Problems' would be 'Wine ing Problems.' Is anybody familiar with this kind of problem and what I can do to remedy this? I'm not sure if it has to do with the line buffer or the printer driver. Thanks All, Josie

2 1

Re: URLMON: Added ReleaseBindInfo implementation
by Robert Shearman 07 Sep '05

07 Sep '05

Jacek Caban wrote: >Index: dlls/urlmon/urlmon_main.c >=================================================================== >RCS file: /home/wine/wine/dlls/urlmon/urlmon_main.c,v >retrieving revision 1.32 >diff -u -p -r1.32 urlmon_main.c >--- dlls/urlmon/urlmon_main.c 6 Sep 2005 09:27:04 -0000 1.32 >+++ dlls/urlmon/urlmon_main.c 7 Sep 2005 16:44:48 -0000 >@@ -362,3 +362,27 @@ HRESULT WINAPI CoGetClassObjectFromURL( > debugstr_guid(riid), ppv); > return E_NOINTERFACE; > } >+ >+/*********************************************************************** >+ * ReleaseBindInfo (URLMON.@) >+ * >+ * Release the resources used by the specified BINDINFO structure. >+ * >+ * PARAMS >+ * pbindinfo [I] BINDINFO to release. >+ * >+ * RETURNS >+ * Nothing. >+ */ >+void WINAPI ReleaseBindInfo(BINDINFO* pbindinfo) >+{ >+ TRACE("(%p)\n", pbindinfo); >+ >+ if(!pbindinfo) >+ return; >+ >+ if(pbindinfo->szExtraInfo) >+ CoTaskMemFree(pbindinfo->szExtraInfo); > > There is no need for the NULL check above. >+ if(pbindinfo->pUnk) >+ IUnknown_Release(pbindinfo->pUnk); >+} > > -- Rob Shearman

1 0

Re: Resend (2): Status bar fixes
by Alexandre Julliard 07 Sep '05

07 Sep '05

Michael Kaufmann <hallo(a)michael-kaufmann.ch> writes: > Changelog: > - Redraw immediately upon WM_SETTEXT, WM_SETFONT, SB_SETTEXT, SB_SETICON > - SB_GETRECT: Return FALSE for simple status bars, check the part number > - SB_SETICON: Didn't work for simple status bars (-1 has been casted to 255) > - SB_SETTEXT: Don't redraw normal status bars if the simple text has > been set and vice versa Please submit separate changes as separate patches. -- Alexandre Julliard julliard(a)winehq.org

1 0

Multiple defenitions of CLSID_FileProtocol
by Paul Millar 07 Sep '05

07 Sep '05

Hi, Cross-compilation is broken again. This time its CLSID_FileProtocol. The GUID is part of the standard MinGW 3.3 release. I can patch MinGW to remove its definition of this GUID, but I'm not sure this is the correct solution. What do people think? Cheers, Paul. --- i686-mingw32msvc-gcc generated.o misc.o protocol.o url.o testlist.o -o urlmon_test.exe -lurlmon -luser32 -lkernel32 -lole32 -luuid /usr/local/mingw/lib/gcc-lib/i686-mingw32msvc/3.3.3/../../../../i686-mingw32msvc/lib/libuuid.a(uuid.o):/usr/local/src/mingw/build-w32api/lib/../../w32api-3.3/lib/uuid.c (.rdata+0x1a0): multiple definition of `CLSID_FileProtocol' protocol.o:/home/paul/Production/wine-cross-source/dlls/urlmon/tests/protocol.c:63: first defined here

2 1

Re: Kernel: Move handling of NT devices to NtCreateFile
by Vitaliy Margolen 07 Sep '05

07 Sep '05

Anything wrong with this patch? All it does is moving small piece of code prom one place to another. ATM it will fail in the same way as it does now ;-) Vitaliy http://www.winehq.com/pipermail/wine-patches/2005-August/020229.html > Move some stuff around for upcoming ntoskrnl.exe > changelog: > dlls/kernel/file.c > dlls/kernel/vxd.c > Move handling of NT devices to NtCreateFile > (c)Ivan Leo Puoti

1 0

Web Server Back Online
by Jeremy Newman 07 Sep '05

07 Sep '05

The webserver is back online. There are still plenty of quirks to fix. Feel free to bug me here on wine-devel about any issues that crop up. Whats Up: www.winehq.org website bugs.winehq.org website appdb.winehq.org website FTP site Anonymous CVS access What is still down: We use cvsupd to sync our CVS trees. I'm still working on getting this running on Debian Sarge. It is no longer included in Sarge so I installed the woody packages. Though I have been unable to get it working. What this means is any commits that Alexander makes will not get into the anonymous tree until I figure it out. ChangeLog: - moved OS to Debian Sarge * now using - Apache 2.0.54 / PHP 4.3.10 * switched from sendmail to Exim4 * upgraded mailing lists from mailman 2.0 to 2.1 * mailing lists now using pipermail for archiving note: old links will work as the hypermail archives still exist I'm still tweaking configs and all so expect the site to be a bit erratic over the next few days.

11 28

Re: fake directx 9c instead of 9b (needed for rFactor Config)
by Oliver Stieber 07 Sep '05

07 Sep '05

--- Christoph Frick <frick(a)sc-networks.de> wrote: > hi gents. > > The attached patch sets the version for directx to 9C (instead of 9B). > The rF\ Config.exe from the game rFactor (www.rfactor.net) needs this to > work. After that change i was able to successfully run the config and > configure the game (yet the game itself fails to execute by a > stack-overflow in the exception handling). > The only real difference between 9C and 9B is shaders, a lot of cards don't support 9C shaders under windows, even though the drivers are 9C so even on windows you could consider the version to be 'faked'. I'll take a look at getting rfactor working a bit better too, or at least identifying the problems. ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

2 1

Re: include/sqltypes.h: Added SQLWCHAR typedef
by Francois Gouget 07 Sep '05

07 Sep '05

On Tue, 6 Sep 2005, Phil Krylov wrote: > ChangeLog: > > Added typedef SQLWCHAR to include/sqltypes.h. Could you also add SQLTCHAR while you're at it? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

1 0

Re: wine/dlls/shell32 shresdef.h shres.rc shfldr_u ...
by Michael Jung 07 Sep '05

07 Sep '05

Hi Ge, On Wednesday 07 September 2005 01:05, you wrote: > I'm working on importing the changes between Wine-20050725 and > Wine-20050830 into ReactOS. This also includes your patch below. > I'm not sure if you realized it, but shell32 now wastes a lot of memory. > The problem is the initialization of the icon cache. Previously, icons with > indexes 1-39 would be loaded. Since IDI_SHELL_MY_DOCUMENTS has such a high > number, now icons with indexes 1-235 are loaded. Most of those ofcourse > don't exist and will be replaced with index 1, but they still take up a lot > of space in the ImageList bitmaps. I've found that, for ReactOS running on > a 32bpp display, memory usage of shell32 increased by 17Mb. This may in > part be a problem in ReactOS (it's much higher than I expected), but even > for Wine the increase in mem usage should be considerable. The ImageLists > get expanded to 494 entries, taking up 494 (entries) * 2 (color + mask) * > 32 (sizex) * 32 (sizey) * 4 (32bpp) = 4Mb per ImageList. We're keeping 2 > ImageLists, plus 2 16*16 ImageLists, all in all we're talking about 10Mb > minimum. And this for every process that loads shell32. I'm aware of this problem (though I didn't know about the exact numbers). There was a short discussion on wine-devel about it: http://www.winehq.org/pipermail/wine-devel/2005-August/039452.html The problem is, that we currently can't read icons via PrivateExtractIcons from wine's ELF dlls. I would guess that for ReactOS, you don't need the hack'ish icon cache pre-initialization at all, since you do have real PE dlls? > For the moment I'm limiting the ReactOS icon cache to the lower 39 entries, > but I think we need to figure out a way to include the My Documents icon > without wasting so much space. As was pointed out by Alexandre, the correct fix for wine would probably be to try to load the given dll via LoadModule, if all other methods fail in PrivateExtractIcon. Unfortunetaly, I don't have time to work on this at the moment, and probably won't have for the next months. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

2 1

Re: urlmon resource
by Alexandre Julliard 07 Sep '05

07 Sep '05

Stefan Leichter <Stefan.Leichter(a)camLine.com> writes: > diff -urw ../wine/dlls/urlmon/Makefile.in dlls/urlmon/Makefile.in > --- ../wine/dlls/urlmon/Makefile.in 2005-09-06 19:18:47.000000000 +0200 > +++ dlls/urlmon/Makefile.in 2005-09-03 21:05:48.000000000 +0200 > @@ -16,7 +15,8 @@ > umstream.c \ > urlmon_main.c > > -RC_SRCS = rsrc.rc > +RC_SRCS = rsrc.rc \ > + version.rc You shouldn't add multiple resource files, mingw unfortunately doesn't support that. Simply #include version.rc from the main file. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: add proper support for native NT drivers and programs to the build system
by Alexandre Julliard 07 Sep '05

07 Sep '05

Ivan Leo Puoti <ivanleo(a)gmail.com> writes: > @@ -469,8 +469,10 @@ > /* get the default entry point for a given spec file */ > static const char *get_default_entry_point( const DLLSPEC *spec ) > { > + if (spec->subsystem == IMAGE_SUBSYSTEM_NATIVE && spec->characteristics & IMAGE_FILE_DLL) > + return "__wine_spec_drv_entry"; > + if (spec->subsystem == IMAGE_SUBSYSTEM_NATIVE) return "__wine_spec_exe_nentry"; Native drivers are not supposed to be dlls. > @@ -322,9 +322,15 @@ > ORDDEF *odp = &spec->entry_points[i]; > if (odp->type != TYPE_STUB) continue; > fprintf( outfile, "#ifdef __GNUC__\n" ); > - fprintf( outfile, "extern void __wine_spec_unimplemented_stub( const char *module, const char *func ) __attribute__((noreturn));\n" ); > + if(spec->subsystem == IMAGE_SUBSYSTEM_NATIVE) > + fprintf( outfile, "extern void __wine_spec_nunimplemented_stub( const char *module, const char *func ) __attribute__((noreturn));\n" ); > + else > + fprintf( outfile, "extern void __wine_spec_unimplemented_stub( const char *module, const char *func ) __attribute__((noreturn));\n" ); > fprintf( outfile, "#else\n" ); > - fprintf( outfile, "extern void __wine_spec_unimplemented_stub( const char *module, const char *func );\n" ); > + if(spec->subsystem == IMAGE_SUBSYSTEM_NATIVE) > + fprintf( outfile, "extern void __wine_spec_nunimplemented_stub( const char *module, const char *func ) __attribute__((noreturn));\n" ); > + else > + fprintf( outfile, "extern void __wine_spec_unimplemented_stub( const char *module, const char *func );\n" ); You should provide your own handling of stubs inside ntoskrnl, like ntdll does. -- Alexandre Julliard julliard(a)winehq.org

2 2

Object manager case sensitivity issue
by Vitaliy Margolen 07 Sep '05

07 Sep '05

I want to make sure that this problem is well understood. Also to make it clear that Wine differs from windows in this really important aspect. For more details, you can refer to the following thread: http://www.winehq.org/hypermail/wine-devel/2005/04/0426.html It needs to be fixed at least on the server level (I have sent a patch for one of the possible solutions). Then we can get ntdll to follow the suite. For a test see attached program. You should be able to run it on windows with administrative privileges. As you can see, this is something very dangerous yet perfectly legal, at least on win2k sp4. -- Best regards, Vitaliy

1 0

Strange problem with writing files from wine
by Pavel Troller 07 Sep '05

07 Sep '05

Hi! I have problems with writing files from wine (today's CVS). Typical example is word95, which always writes something like: Cannot access folder "F:\filename.doc ": unaccessible or protected by password (in my local language, so it may be inaccurate). There is a small problem with this strange indentation (that the second double quote is on a next line, but it is not fatal. More fatal is that this dialog even occurs and the file cannot be written. I've created a tracefile with +file and I think I've found the problem. At the moment of attempt to write (in this example, F:\brumbal.doc), there appears: trace:file:CreateFileW L"\\\\.\\F:" GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L"\\\\.\\F:",0x7fc8975c,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"\\\\.\\F:" 520 0x7fc89508 (nil)) trace:file:get_dos_device L"F:" -> "/dev/hdb1" warn:file:CreateFileW Unable to create file L"\\\\.\\F:" (status c0000022) trace:file:CreateFileW returning 0xffffffff trace:file:RtlDosPathNameToNtPathName_U (L"F:\\",0x7fc89744,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"F:\\" 520 0x7fc89508 (nil)) trace:file:wine_nt_to_unix_file_name L"\\??\\F:\\" -> "/home/patrol/.wine/dosdevices/f:/" trace:file:GetFileAttributesW L"F:\\brumbal.doc\r\n" trace:file:RtlDosPathNameToNtPathName_U (L"F:\\brumbal.doc\r\n",0x7fc8aae4,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"F:\\brumbal.doc\r\n" 520 0x7fc8a8b0 (nil)) trace:file:CreateFileW L"\\\\.\\F:" GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L"\\\\.\\F:",0x7fc8975c,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"\\\\.\\F:" 520 0x7fc89508 (nil)) trace:file:get_dos_device L"F:" -> "/dev/hdb1" warn:file:CreateFileW Unable to create file L"\\\\.\\F:" (status c0000022) trace:file:CreateFileW returning 0xffffffff trace:file:RtlDosPathNameToNtPathName_U (L"F:\\",0x7fc89744,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"F:\\" 520 0x7fc89508 (nil)) trace:file:wine_nt_to_unix_file_name L"\\??\\F:\\" -> "/home/patrol/.wine/dosdevices/f:/" patrol@arcus:/opt/samba-dir/Program Files/Microsoft Office/Office$ Why the hell wine is trying to access /dev/hdb1 ? Yes, my home directory is on it, but I think that such a form of access is not good :-). In my .wine/dosdevices, there is clearly a line lrwxrwxrwx 1 patrol users 12 Sep 7 06:50 f: -> /home/patrol Or am I misinterpreting the log and the failure is caused by something else ? Otherwise wine is working near to perfect now. With regards, Pavel Troller

1 0

Path for Testfiles (MSI: Test creating a package)
by Detlef Riekenberg 07 Sep '05

07 Sep '05

Hi After reading reading this commit, .... > ChangeSet ID: 20009 > Added files: > dlls/msi/tests : package.c > Test creating a package. > Patch: http://cvs.winehq.org/patch.py?id=20009 ... i Suggest that: - all directories and files for tests should be created in "%TEMP%\winetest" - we modify "wine/tests.h" to get this path and check for path and name overflows (MAX_PATH and nesting level). "c:" could be readonly or absent/hidden Any comments please. -- By By ... ... Detlef

2 1

DirectX status update....
by Oliver Stieber 06 Sep '05

06 Sep '05

I though it was about time I gave a status update on DirectX9/wined3d, so here goes. Short of a couple of bug fixes (one to shaders, and another that causes some games to crash) and a couple of patches that need resending (support for non-power2 textures in warhammer 40k) wined3d and d3d9 is functionally as complete as the version on http://directxwine.sourceforge.net/, that means that as soon as pixel shaders are coppied across from d3d8 it's more or less the end of adding features to wined3d and the start of fixing the remaining bugs and getting the performance up to spec. Anyhow, as soon as I've sent in those patches I'll provide another status update with a bit more information about moving d3d8 over to wined3d and the improvements that have been made. Oliver. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

3 2

Re: URLMON: Added file protocol implementation
by Stefan Leichter 06 Sep '05

06 Sep '05

Am Samstag, 3. September 2005 21:22 schrieb Jacek Caban: > Changelog: > Added file protocol implementation Hello, this patch breaks the cross compiling of the tests with mingw. Which is the correct location of the class id? Bye Stefan make[3]: Entering directory `/usr/src/wine/wine-mingw/dlls/urlmon/tests' i386-mingw32-gcc generated.cross.o misc.cross.o protocol.cross.o url.cross.o testlist.cross.o -o urlmon_crosstest.exe -lurlmon -luser32 -lkernel32 -lole32 -luuid /usr/local/lib/gcc/i386-mingw32/3.4.2/../../../../i386-mingw32/lib/ libuuid.a(uuid.o):/usr/src/packages/BUILD/mingw-3.7/w32api-3.2/lib/uuid.c: (.rdata+0x1340): multiple definition of `_CLSID_FileProtocol' protocol.cross.o:/usr/src/wine/wine-mingw/dlls/urlmon/tests/../../../../wine/ dlls/urlmon/tests/protocol.c:63: first defined here collect2: ld returned 1 exit status make[3]: *** [urlmon_crosstest.exe] Fehler 1 make[3]: Leaving directory `/usr/src/wine/wine-mingw/dlls/urlmon/tests'

1 0

Re: Wined3d: added A2R10G10B10 and D3DFMT_D24FS8
by Oliver Stieber 06 Sep '05

06 Sep '05

--- Karsten Elfenbein <kelfe(a)gmx.de> wrote: Can you put together a patch to add A2R10G10B10 and D3DFMT_D24FS8 to utils.c as well please. D3DFmt2GLIntFmt needs to return GL_RGBA, D3DFmt2GLFmt needs to return GL_RGBA, D3DFmt2GLType needs to return GL_UNSIGNED_INT_2_10_10_10_REV, D3DFmtGetBpp needs to return 4, D3DFmtMakeGlCfg needs to PUSH2(GLX_ALPHA_SIZE, 2); PUSH2(GLX_RED_SIZE, 10); PUSH2(GLX_GREEN_SIZE, 10); PUSH2(GLX_BLUE_SIZE, 10); Also in surface.c IWineD3DSurfaceImpl_UnlockRect needs to use glDrawPixels(This->lockedRect.right - This->lockedRect.left, (This->lockedRect.bottom - This->lockedRect.top) - 1, GL_BGRA, GL_UNSIGNED_INT_2_10_10_10_REV, This->resource.allocatedMemory); when unlocking the back buffer Thanks, Oliver. > Changelog: > * added A2R10G10B10 and D3DFMT_D24FS8 modes > > > ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

2 2

Re: fonts: don't call LineTo with the gdi lock
by Alexandre Julliard 06 Sep '05

06 Sep '05

Huw D M Davies <h.davies1(a)physics.ox.ac.uk> writes: > On Sun, Aug 28, 2005 at 12:04:41PM +0100, Huw D M Davies wrote: >> Huw Davies <huw(a)codeweavers.com> >> Don't call LineTo while holding the gdi lock > > Is this one better? I think it would be better to release the DC earlier on and then just do normal GDI calls. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: MSI: test creating a package
by Andreas Mohr 06 Sep '05

06 Sep '05

Hi, On Tue, Sep 06, 2005 at 03:21:55PM +0900, Mike McCormack wrote: > ChangeLog: > <aric(a)codeweavers.com> > <mike(a)codeweavers.com> > * test creating a package + res = MsiCloseHandle( suminfo); + ok( res == ERROR_SUCCESS , "Failed to close suminfo" ); + + + res = MsiCloseHandle( hPackage); + ok( res == ERROR_SUCCESS , "Failed to close package" ); +} Hmm, something seems to be missing here... Andreas

2 2

Messages from 2030 (Laxdragon please read)
by Ivan Leo Puoti 06 Sep '05

06 Sep '05

http://www.winehq.com/pipermail/wine-devel/2030-March/000355.html Well, now we all know wineserver will still be around in 2030... Seriously, this should be fixed (not wineserver, the list archive) Ivan.

1 0

ntoskrnl patch, reviews/comments/suggestions wanted
by Ivan Leo Puoti 06 Sep '05

06 Sep '05

As Dmitry rightly pointed out, wine-devel is a good place to post stuff for help/comments/review, so here is an (almost) full diff of my tree against cvs. Without going as far as making wineserver a user mode ntoskrnl like mike_m suggested, this code allows kernel mode drivers to work decently in wine, naturally not many have been tested but it's a start. Alexadre's main complaint is that it's ugly to pass handles to ntoskrnl because it's a client process, currently we pass a pointer to a DEVICE_OBJECT, that obviously won't do but we're not sure what would do, suggestions are welcome. secdrv.sys from safedisc 1 works. Some code used to work around the anti debugger checks has been removed, so you can't run safedisc in winedbg with this patch. Running tools/make_requests and a full ./config.status && make depend && make is needed to build this patch. Ivan.

1 0

Some troubles with InstallShield
by Vitaly Lipatov 06 Sep '05

06 Sep '05

Can anyone test PHP Expert Editor for install? It uses InstallShield and install loop at message "File access denied." http://www.ankord.com/download/phpxedit_33.zip -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

2 1

fake higher directx version
by Christoph Frick 06 Sep '05

06 Sep '05

hiho, i am currently trying rFactor with WINE. the config programm wants dx9C - the current version with the last release version of wine is dx9B. where would i find this so i can fake a higher version? a naïve grep found nothing in my source. -- cu

3 2

Re: kernel32: get ExitProcess to call NtTerminateProcess
by Eric Pouech 05 Sep '05

05 Sep '05

Ivan Leo Puoti a écrit : > As NtTerminateProcess alredy exists in ntdll, there's no reason to call > wineserver directly. > > Ivan. I don't see why you need to return something. If NtTerminateProcess() fails, then just call exit(status). A+ -- Eric Pouech

2 1

Some troubles with InstallShield:solved
by Robbert Xerox 05 Sep '05

05 Sep '05

Hahaha, Wine is just great, patch that just came in : http://www.winehq.org/pipermail/wine-patches/2005-September/020456.html seems to fix the problem.... ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

1 0

Some troubles with InstallShield
by Robbert Xerox 05 Sep '05

05 Sep '05

Using native comctl32 makes the installer proceed; is this also caused by theming patches that got in? See for example http://bugs.winehq.org/show_bug.cgi?id=3241 ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

1 0

Re: dinput force feedback header detection
by Daniel Remenak 05 Sep '05

05 Sep '05

The patch to fix that error is at http://www.winehq.org/pipermail/wine-patches/attachments/20050903/636b08f6/… The headers are correctly detected but the use of the constants was not protected. --Daniel Remenak On 9/5/05, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > Hi I got this compile error from current cvs: > > make[2]: Entering directory `/home/jesse/.local/build/wine/dlls/dinput' > gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ > -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 > -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o > joystick_linuxinput.o joystick_linuxinput.c > joystick_linuxinput.c: In function `alloc_device': > joystick_linuxinput.c:305: error: `FF_STATUS_STOPPED' undeclared > (first use in this function) > joystick_linuxinput.c:305: error: (Each undeclared identifier is > reported only once > joystick_linuxinput.c:305: error: for each function it appears in.) > joystick_linuxinput.c: In function `joy_polldev': > joystick_linuxinput.c:726: error: `EV_FF_STATUS' undeclared (first use > in this function) > joystick_linuxinput.c: In function `JoystickAImpl_EnumEffects': > joystick_linuxinput.c:1182: warning: unused variable `dei' > joystick_linuxinput.c: In function `JoystickWImpl_EnumEffects': > joystick_linuxinput.c:1266: warning: unused variable `dei' > make[2]: *** [joystick_linuxinput.o] Error 1 > make[2]: Leaving directory `/home/jesse/.local/build/wine/dlls/dinput' > make[1]: *** [dinput] Error 2 > make[1]: Leaving directory `/home/jesse/.local/build/wine/dlls' > make: *** [dlls] Error 2 > > > Apparently the linux/input.h version 2.4.31 does not have support for > force feedback. I've installed headers for 2.6.12.5 and now have it > compiled. So something might need to be done to improve detection, > else others still running 2.4 will get this error. > > Jesse > > >

1 0

dinput force feedback header detection
by Jesse Allen 05 Sep '05

05 Sep '05

Hi I got this compile error from current cvs: make[2]: Entering directory `/home/jesse/.local/build/wine/dlls/dinput' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o joystick_linuxinput.o joystick_linuxinput.c joystick_linuxinput.c: In function `alloc_device': joystick_linuxinput.c:305: error: `FF_STATUS_STOPPED' undeclared (first use in this function) joystick_linuxinput.c:305: error: (Each undeclared identifier is reported only once joystick_linuxinput.c:305: error: for each function it appears in.) joystick_linuxinput.c: In function `joy_polldev': joystick_linuxinput.c:726: error: `EV_FF_STATUS' undeclared (first use in this function) joystick_linuxinput.c: In function `JoystickAImpl_EnumEffects': joystick_linuxinput.c:1182: warning: unused variable `dei' joystick_linuxinput.c: In function `JoystickWImpl_EnumEffects': joystick_linuxinput.c:1266: warning: unused variable `dei' make[2]: *** [joystick_linuxinput.o] Error 1 make[2]: Leaving directory `/home/jesse/.local/build/wine/dlls/dinput' make[1]: *** [dinput] Error 2 make[1]: Leaving directory `/home/jesse/.local/build/wine/dlls' make: *** [dlls] Error 2 Apparently the linux/input.h version 2.4.31 does not have support for force feedback. I've installed headers for 2.6.12.5 and now have it compiled. So something might need to be done to improve detection, else others still running 2.4 will get this error. Jesse

1 0

Delphi edit control created in Unicode instead of ANSI mode
by Michael Kaufmann 05 Sep '05

05 Sep '05

Hi Frank, One of your theming patches ( http://www.winehq.org/hypermail/wine-cvs/2005/08/0313.html ) has caused a problem in many Delphi applications. The edit controls of Delphi applications are now created in Unicode mode. I hope you have an idea why this happens... Of course Delphi applications are ANSI and expect ANSI controls in their windows. If you believe that this is a real problem, you won't need to read the rest of this email :-) Because the Delphi edit controls are now in Unicode mode, the messages sent to them have to be translated from ANSI to Unicode and back. When a program reads the "Text" property of a TEdit control, Delphi sends a WM_GETTEXTLENGTH message. Wine doubles the return value when translating back from Unicode to ANSI because of double-byte character sets. (dlls/user/winproc.c) Now Delphi gets the doubled text size (should be no problem because WM_GETTEXTLENGTH only returns an upper limit of the text size, but Delphi doesn't regard this fact). Because Delphi does NOT use zero-terminated strings, Delphi will return a string that has twice the size of the text in the edit control and contains a '\0' character. If the application then concatenates this string with another string and passes the result to a Windows API function, the API function will only see the first string because of the '\0' character. I've discovered the problem because installers created by InnoSetup ( http://www.innosetup.com/ ) are now failing. You may use my simple Delphi demo program to test the bug: http://www.michael-kaufmann.ch/WINE/DelphiEdit.zip Regards Michael

2 6

Re: http://cvs.winehq.org/patch.py?id=19897 (shlfolder.c test)
by Paul Vriens 05 Sep '05

05 Sep '05

Hi, this change to shell32/tests/shlfolder.c fails on Win98/WinNT and W2KProf because ILFindLastID is not exported on those platforms. I tried to change shlfolder.c to test for the export, but that shows that it's not exported on Wine either ? The .spec file says different. Apart from that, 2 todo_wine's can be removed: shlfolder.c:452: Test succeeded inside todo block: SFGAO_FILESYSTEM attribute is not set for MyDocuments! shlfolder.c:461: Test succeeded inside todo block: RegOpenKeyEx failed! result: 00000000 But I'd like to leave that to the person how fixes the first problem :-). Cheers, Paul.

4 6

Re: http://cvs.winehq.org/patch.py?id=19897 (shlfolder.c test)
by Paul Vriens 05 Sep '05

05 Sep '05

On Sun, 2005-09-04 at 16:17 +0300, Saulius Krasuckas wrote: > * On Sat, 3 Sep 2005, Saulius Krasuckas wrote: > > * On Sat, 3 Sep 2005, Paul Vriens wrote: > > > > > > this change to shell32/tests/shlfolder.c fails on Win98/WinNT and > > > W2KProf because ILFindLastID is not exported on those platforms. > > > > > > I tried to change shlfolder.c to test for the export, but that shows > > > that it's not exported on Wine either ? The .spec file says different. > > > > I have made pretty trivial change and it worksforme. See below. > > I believe the test works a lot better now. Still I tried upgrading my RH8 > glibc to one of FC4 and now I sit even w/o XF. :-/ > > > Log message: > Saulius Krasuckas <saulius.krasuckas(a)ieee.org> > SHELL32.dll.ILFindLastID is exported by an ordinal on an older platforms. ... > /* This test shows that Windows doesn't allocate a new pidlLast, but returns a pointer into > * pidlTestFile (In accordance with MSDN). */ > - todo_wine{ok (ILFindLastID(pidlTestFile) == pidlLast, > + todo_wine{ok (pILFindLastID(pidlTestFile) == pidlLast, > "SHBindToParent doesn't return the last id of the pidl param!\n");} Shouldn't we (for consistency sake) surround the call to pILFindLastID with a: if (pILFindLastID) Cheers, Paul.

2 1

Possible regression in CVS wine
by Pavel Troller 05 Sep '05

05 Sep '05

Hi! I've just upgraded wine on my son's computer by today's CVS. He tried some games and one of them stopped working. It's hind95 and the game bails out on an illegal instruction - outb, jumping into winedbg. Backtrace shows just 3 levels of game code itself, no dlls involved. I understand that user code cannot perform direct hardware I/O, but the game worked just before the upgrade (on wine about 1 month old). I don't know whether wine is normally intercepting and emulating these instructions, and the CVS version doesn't, or whether a new wine caused that another code path has been activated in the game code, leading to such a problem. There is also native w2k version of the game (hind.exe) but it still doesn't work in wine: it very sllllooooowwwwwllllyyyy renders the splash screen and then sits there and does nothing more. The game can be freely downloaded from www.abandonia.com; just search "hind" in the title page. There is probably a dynamic download URL used so I'm not posting it there. With regards, Pavel Troller

2 2

Problems with winecfg and theming
by Ron Jensen 05 Sep '05

05 Sep '05

On Wed Aug 31 14:19:53 CDT 2005, Kevin DeKorte wrote: >On Wednesday 31 August 2005 01:03 pm, Paul Vriens wrote: >> Hi, >> >> I'm not able to use winecfg and theming. If I select to add a theme I >> get an exception after selecting the file and clicking OK. >> >> the .msstyles files seems to have been copied to the right place. When I >> however start winecfg again and go to the Appearance tab I get a new >> exception. Remove everything under Resources/Themes 'fixes' this so >> there must be something wrong with the enumeration. >> >> Anybody else experiencing this? >> >> Paul. > > Yes, I can duplicate this crash as well. > > Kevin I was playing with theming after pulling from CVS on the 27th. I tried to use theming today after pulling from CVS on Sep 1. The Appearance tab worked before, it doesn't work now. Removing all the msstyles files from windows\resources\themes\*\ stops the crashing. I reversed patches 19901 and 19915 but that didn't seem to help. Ron

2 1

Re: DINPUT: protect FF_STATUS usage
by Marcelo Duarte 04 Sep '05

04 Sep '05

Now it compiles... Thank you! Daniel Remenak escreveu: >Changelog: >Protect FF_STATUS usage to avoid compile errors on machines with old >linux/input.h > >This patch should fix Marcelo Duarte's reported compile error on FC2. > >This patch was made against a copy of joystick_linuxinput.c that >already had "linuxinput axis enumeration fixes" and "allow the >creation of an effect while unacquired" applied to it, but it should >apply to an earlier revision. > >--Daniel Remenak > > >------------------------------------------------------------------------ > >--- ../wine2/dlls/dinput/joystick_linuxinput.c 2005-09-03 14:29:30.000000000 -0700 >+++ dlls/dinput/joystick_linuxinput.c 2005-09-03 23:00:35.000000000 -0700 >@@ -302,7 +302,9 @@ > newDevice->ref = 1; > newDevice->joyfd = -1; > newDevice->dinput = dinput; >+#ifdef HAVE_STRUCT_FF_EFFECT_DIRECTION > newDevice->ff_state = FF_STATUS_STOPPED; >+#endif > memcpy(&(newDevice->guid),rguid,sizeof(*rguid)); > for (i=0;i<ABS_MAX;i++) { > newDevice->wantmin[i] = -32768; >@@ -723,9 +725,11 @@ > break; > } > break; >+#ifdef HAVE_STRUCT_FF_EFFECT_DIRECTION > case EV_FF_STATUS: > This->ff_state = ie.value; > break; >+#endif > default: > FIXME("joystick cannot handle type %d event (code %d)\n",ie.type,ie.code); > break; > > >------------------------------------------------------------------------ > > > >

1 0

MMIO error
by Matthew D'Asaro 04 Sep '05

04 Sep '05

Hi, I have been trying to get a professional Audio restoration program, DCart32, to work in wine. Everything goes well until you try to run one of the "filters." These process wav files to remove clicks, hiss etc. The filter runs OK, but when it comes time to write the wav file modified in memory back to disk, it fails saying "The file contains a format not supported by DCart." At this point wine gives the error err:mmio:MMIO_ParseExtA No . in szFileName: "", which I have taken to mean that their is a problem in wine's implementation of the MMIO api. I have tried a native winmom.dll, but naturally that does not work at all; wine crashes on load. I have heard through another mailing list that this is an ancient regression, that this used to work. It is true that the filters work in Cedega, but run their DCart has so many graphical, and other problems, it is not usable. Any other suggestions or hints as to where I could start diffing code would be much appreciated. Thanks, Matthew D'Asaro

1 0

mail address
by Eric Pouech 04 Sep '05

04 Sep '05

Hi folks, please note my new email address: eric.pouech(a)wanadoo.fr A+ -- Eric Pouech

3 3

Re: http://cvs.winehq.org/patch.py?id=19964
by Juan Lang 04 Sep '05

04 Sep '05

> this latest change to the shellpath test produces the attached error on > Windows XP. Haven't looked into this further. Damn. Alexandre, would you mind backing out this patch? It needs more work. http://cvs.winehq.org/patch.py?id=19964 Thanks, --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

winedebug/gdb crashes
by Simon Kissane 04 Sep '05

04 Sep '05

Hi Using latest wine CVS (checked out today), trying to debug the PackageForTheWeb self-extracting EXE that MS uses to distribute MSDE 2000.... The EXE works fine (albeit with some visual bugs) when running under plain wine instead of winedebug.... Anyone have any idea what might be wrong? (I am very new to wine, although I've been following the wine-devel archives for a while...) Cheers Simon Kissane ===== winedebug window ====== > winedbg --gdb --no-start z:/home/skissane/downloads/MSDE2000A.exe 0000001b:0000001c: create process 'Z:\home\skissane\downloads\MSDE2000A.exe'/0x7fff003c @0040ce00 (0<0>) 0000001b:0000001c: create thread I @0040ce00 target remote localhost:32815 0000001b:0000001c: loads DLL c:\windows\system\ntdll.dll @00840000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\kernel32.dll @00e50000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\advapi32.dll @00770000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\gdi32.dll @00370000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\user32.dll @00270000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\comctl32.dll @00430000 (0<0>) fixme:dbghelp:elf_new_wine_thunks Duplicate in comctl32<elf>: refDataPropName<004b4d60-00000020> subclasses<4b4d60-00000000> 0000001b:0000001c: loads DLL c:\windows\system\iphlpapi.dll @00b00000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\rpcrt4.dll @004e0000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\ole32.dll @006b0000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\shlwapi.dll @00d90000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\shell32.dll @00550000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\lz32.dll @003e0000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\winex11.drv @00ca0000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\imm32.dll @00710000 (0<0>) 0000001b:0000001c: exception code=0x80000003 wine-pthread: gdbproxy.c:1984: extract_packets: Assertion `i == gdbctx->out_len' failed. wine: Unhandled exception (thread 001d), starting debugger... WineDbg starting on pid 0x1e Unhandled exception: assertion failed in 32-bit code (0x595a97e2). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:595a97e2 ESP:7fcbf38c EBP:7fcbf3a0 EFLAGS:00000202( - 00 - - I1) EAX:00000000 EBX:00004e8c ECX:00004e8c EDX:00000006 ESI:00000000 EDI:2014fff4 Stack dump: 0x7fcbf38c: 200521f8 00004e8c 2014fff4 00000000 0x7fcbf39c: b7efe9e0 7fcbf4cc 20053948 00000006 0x7fcbf3ac: 7fcbf440 00000000 00000060 7d00bf80 0x7fcbf3bc: 00000068 00000000 2008bae7 7fcbf404 0x7fcbf3cc: 7d00bf88 7d00bfec 7fcbf4dc 2014fff4 0x7fcbf3dc: 00000059 0000005a 7fcbf4b0 20086515 0200: sel=1007 base=b7f04000 limit=00001f97 32-bit rw- Backtrace: =>1 0x595a97e2 (0x7fcbf3a0) 2 0x20053948 (0x7fcbf4cc) 3 0x2004b38e (0x7fcbf510) 4 0x75ff7e2f gdb_remote+0xaab(flags=0x1) [/home/skissane/osdevel/wine/programs/winedbg/gdbproxy.c:1981] in winedbg (0x7fcbfddc) 5 0x76002b9b main+0x473(argc=0x2, argv=0x7fee04a8) [/home/skissane/osdevel/wine/programs/winedbg/winedbg.c:1285] in winedbg (0x7fcbfeac) 6 0x75fef26f __wine_exe_main+0x176 in winedbg (0x7fcbff2c) 7 0x4bdbe9e2 start_process+0xb6(arg=0x0) [/home/skissane/osdevel/wine/dlls/kernel/process.c:996] in kernel32 (0x7fcbfff4) 8 0x20004935 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) 0x595a97e2: ret Modules: Module Address Debug info Name (21 modules) ELF 0x0051b000-00537000 Deferred ld-linux.so.2 ELF 0x00539000-00663000 Deferred libc.so.6 ELF 0x00665000-00669000 Deferred libdl.so.2 ELF 0x0066b000-0068f000 Deferred libm.so.6 ELF 0x00a05000-00a17000 Deferred libpthread.so.0 ELF 0x20000000-20018000 DIA libwine.so.1 ELF 0x20154000-201c6000 Deferred ntdll<elf> \-PE 0x20170000-201c6000 \ ntdll ELF 0x201ea000-201f5000 Deferred libnss_files.so.2 ELF 0x201f5000-2020b000 Deferred psapi<elf> \-PE 0x20200000-2020b000 \ psapi ELF 0x39fc3000-39fff000 Deferred advapi32<elf> \-PE 0x39fd0000-39fff000 \ advapi32 ELF 0x45dc6000-45e01000 Deferred dbghelp<elf> \-PE 0x45dd0000-45e01000 \ dbghelp ELF 0x4bd54000-4be4f000 Stabs kernel32<elf> \-PE 0x4bd80000-4be4f000 \ kernel32 ELF 0x6be33000-6bf28000 Deferred libwine_unicode.so.1 ELF 0x75fd7000-76019000 Stabs winedbg<elf> \-PE 0x75fe0000-76019000 \ winedbg ELF 0x7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 0000001b 0000001c 0 0000001e (D) c:\windows\system\winedbg.exe 0000001d 0 <== 0000000e 0000000f 0 0000000a 0000000b 0 WineDbg terminated on pid 0x1e ===== gdb window ====== > gdb GNU gdb Red Hat Linux (6.3.0.0-1.21rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu". (gdb) target remote localhost:32815 Remote debugging using localhost:32815 Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Couldn't establish connection to remote target Malformed response to offset query, timeout (gdb)

2 1

More debugger quesions
by Robert Lunnon 04 Sep '05

04 Sep '05

Well we are getting somewhere When my test application segfaults the debugger attaches and runs through a number of debug events eventually ariving at a segfault strace:winedbg:dbg_handle_debug_event 00000008:00000009: loads DLL c: \windows\system\imm32.dll @7f440000 (0<0>) trace:winedbg:dbg_handle_debug_event 00000008:00000009: exception code=80000003 Now I added some instrumentation and find the following happens IE trace:winedbg:dbg_handle_debug_event Continue on first exception is true trace:winedbg:dbg_handle_debug_event Breaking switch trace:winedbg:dbg_handle_debug_event Call ContinueDebugEvent trace:winedbg:dbg_handle_debug_event Continuing executio trace:winedbg:dbg_main_loop Wait for next debug event... In this code at the top of dbg_main_loop if (dbg_curr_process) dbg_printf("WineDbg starting on pid 0x%lx\n", dbg_curr_pid); /* wait for first exception */ while (WaitForDebugEvent(&de, INFINITE)) { WINE_TRACE("Calling handle_debug_event 2\n"); if (dbg_handle_debug_event(&de)) {WINE_TRACE("Event handled\n");break;} WINE_TRACE("Wait for next debug event...\n"); } Problem is that the client program is stopped, probably on a segfault trace because I enable tracing (stops) on all machine faults and signals when I attached it (this allows my replacement for wait4 to find out if a fault or signal happened in the debuggee). Everything deadlocks then since the debugger never continues the program after the exception (Or perhaps the wineserver never gets a message to restart it) Perhaps I don't understand the semantics of PTRACE wait4 interactions. Should I just let the app trap machine faults ? All help appreciated Bob

3 4

Re: wine/dlls/dinput joystick_linuxinput.c
by Marcelo Duarte 04 Sep '05

04 Sep '05

Alexandre Julliard escreveu: >ChangeSet ID: 19966 >CVSROOT: /opt/cvs-commit >Module name: wine >Changes by: julliard(a)winehq.org 2005/09/03 10:02:38 > >Modified files: > dlls/dinput : joystick_linuxinput.c > >Log message: > Daniel Remenak <dtremenak(a)gmail.com> > Implement EnumEffects, CreateEffect, EnumCreatedEffects, > SendForceFeedbackCommand, and GetForceFeedbackStatus for linux input > joysticks. > >Patch: http://cvs.winehq.org/patch.py?id=19966 > >Old revision New revision Changes Path > 1.25 1.26 +377 -12 wine/dlls/dinput/joystick_linuxinput.c > > I think that this patch is the cause of a compiler error in my box (Fedora core 2): make[2]: Entering directory `/home/mduarte/wine/dlls/dinput' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o joystick_linuxinput.o joystick_linuxinput.c joystick_linuxinput.c: In function `alloc_device': joystick_linuxinput.c:305: error: `FF_STATUS_STOPPED' undeclared (first use in this function) joystick_linuxinput.c:305: error: (Each undeclared identifier is reported only once joystick_linuxinput.c:305: error: for each function it appears in.) joystick_linuxinput.c: In function `joy_polldev': joystick_linuxinput.c:726: error: `EV_FF_STATUS' undeclared (first use in this function) joystick_linuxinput.c: In function `JoystickAImpl_EnumEffects': joystick_linuxinput.c:1182: warning: unused variable `dei' joystick_linuxinput.c: In function `JoystickWImpl_EnumEffects': joystick_linuxinput.c:1266: warning: unused variable `dei' make[2]: ** [joystick_linuxinput.o] Erro 1 make[2]: Leaving directory `/home/mduarte/wine/dlls/dinput' make[1]: ** [dinput/__install-lib__] Erro 2 make[1]: Leaving directory `/home/mduarte/wine/dlls' make: ** [dlls/__install-lib__] Erro 2

1 0

wined3d - d3d9 regression testing
by Oliver Stieber 03 Sep '05

03 Sep '05

Hi, Wined3d in CVS is now in a reasonable state to start regression testing new changes against. I usually regression test against a few game demos and DirectX 9 tutorials, I'm going to list the DirectX 9 tutorials as they start to work (there are 68 tutorials that work with the big patch). The current list of working DirectX 9 demos is: from http://www.codesampler.com/dx9src.htm dx9_1pass_emboss_bump_mapping dx9_2pass_emboss_bump_mapping dx9_alpha_blending_texture dx9_multiple_vertex_buffers dx9_texture_dot3_blending dx9_texture_filtering dx9_texture_mipmapping dx9_texture_subloading dx9_tokamak_chain dx9_transforms dx9_vertex_data dx9_view_matrix dx9_view_ports dx9_spot_light dx9_texture dx9_texture_addressing (has a mipmapping error with ATI's drivers) dx9_primitive_types dx9_point_light dx9_dot3_bump_mapping dx9_effect_simple dx9_fonts dx9_indexed_geometry dx9_initialization dx9_lighting (has a slight artifact) dx9_material dx9_multitexture dx9_offscreen_rendering (faked) dx9_2d_demo_game (text for non-power2 textures, ship doesn't animate yet) from http://triplebuffer.devmaster.net/tutorials.php BumpMapping tb_dx9_03 tb_dx9_04 tb_dx9_05 (sort of) tb_dx9_06 tb_dx9_07 tb_dx9_08 tb_dx9_09 tb_dx9_10 from http://www.clootie.ru/delphi/download_dx90.html#Direct3D Tut01_CreateDevice Tut02_Vertices Tut03_Matrices Tut04_Lights Tut05_Textures Tut06_Meshes cull ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

5 12

wine20050830 - is quite fast
by Vijay Kiran Kamuju 03 Sep '05

03 Sep '05

hi, previous it took 3-4 minutes to show the application in wine20050725, but the latest has reduced to less than a min. even in managed mode its faster. bye, Vijay

3 3

wine/ tools/winebuild/import.c dlls/winecrt0/M ...
by Stefan Leichter 03 Sep '05

03 Sep '05

Hello, this patch http://cvs.winehq.org/patch.py?id=19957 broke the inital startup (creating of .wine directory) of wine for me. Wine crashes now with: wine: creating configuration directory '/home/sle/.wine'... wine-pthread: ne_module.c:203: __wine_dll_register_16: Assertion `i < 50' failed. wine: Unhandled exception (thread 0009), starting debugger... err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0 addr 0x41603340 wine: wineprefixcreate failed while creating '/home/sle/.wine'. sle@sle3:/usr/src/wine/wine-20050902-0944> wineserver: could not save registry branch to /home/sle/.wine-iqLHbI/system.reg : No such file or directory wineserver: could not save registry branch to /home/sle/.wine-iqLHbI/ user.reg : No such file or directory on my system (SuSE 9.0) Bye Stefan

1 0

http://cvs.winehq.org/patch.py?id=19964
by Paul Vriens 03 Sep '05

03 Sep '05

Hi, this latest change to the shellpath test produces the attached error on Windows XP. Haven't looked into this further. Cheers, Paul.

1 0

Opposite for wine_get_unix_filename()
by Phil Krylov 03 Sep '05

03 Sep '05

Hi, What can I use as a function opposite to wine_get_unix_filename() (e.g. to pass a filename to GetSaveFileNameW() dialog)? -- Ph.

2 2

winebuld/winecrt changes and breakages
by Ivan Leo Puoti 03 Sep '05

03 Sep '05

Your recent changes have broken the ntoskrnl build, because we're forced to link to kernel32 (that we don't need nor want) Could you please fix this? ntoskrnl is meant to be a native program anyway, so it shouldn't have an entry point routine like win32 progs. Being able to use NtProcessStartup instead of main would be an extra bonus. Of course this means we'll have to call NtProcessTerminate at shutdown but that's something all native progs on windows have to do too. Also I believe this patch of your to be wrong: http://cvs.winehq.org/patch.py?id=19957 The entry point of native drivers is DriverEntry, native drivers don't link to kernel32, thus can't call ExitProcess, also consider DriverEntry is like DllMain, it's an initialisation routine, the real work is then done by the DispatchDeviceControl function, so if you call ExitProcess nobody will have a chance to call the driver anyway. And all this is taken care by the io subsystem, so that entry point routine really shouldn't be there (Apart from the fact that windows doesn't have it). Ivan.

1 0

proper nt-style authentication (reactos, wine, samba tng)
by Luke Kenneth Casson Leighton 03 Sep '05

03 Sep '05

[please note: due to its cross-discipline and cross-project nature, this message is going out to SEVERAL related project mailing lists. when replying, please take EXTRA caution not least because some of these lists are subscriber-only. also, please note: i _would_ post this also to the samba mailing lists but due to the fascist censorship in place since the 15th dec 2004, i am unable to do so. this is their decision and it is their loss. i am not asking you to respect that decision i am simply making you aware of it.] hi, out the woodwork i pop - not necessarily ready to chew anything because i know just how much work's involved, but what i did want to do was say "hi, i'm still here" and do a brain-dump of how authentication ideally needs to be implemented in reactos. at 2,600 words and 16k, this message is quite long and so i have placed a copy at http://lkcl.net/software/reports/reactos-auth.txt, just in case it doesn't make it past various mailing-list limits (i'll find out in a couple of minutes... :) it breaks down into a number of sections: 1) i describe the timescales and ways to cut them, along with some warnings and stuff. 2) amonst other stuff i outline some background as to why i am posting this to so many lists. 3) i outline a project plan and the dependencies and "optional" steps, 4) i describe a recommended implementation roadmap starting with the "minimum" requirements, and expand on some technical info and references i found, which would help with some of the "nice-to-have" steps. so. first. please do not be scared by how much work is involved, and how much code there is. it all hinges one ONE function and that one function... you are _not_ going to believe how much code that one function drags in, kicking and screaming, behind it. please also please i beg you DO NOT consider going "bleedin 'ellfire, that's so much frakkin work we can't POSSIBLY do it the way you describe, we MUST do it our own way, starting with what we know, love and have already started tackling, and can't possibly back out of what we've already done". should you choose to exercise the "NIH" option, i frakkin guarantee you that you will waste about five to eight years of your (collective) lives reinventing the wheel. "The Plan" outlined here will shave that down to about 12 to 18 months, utilising some SIX HUNDRED THOUSAND lines of pre-existing code, and later in this message i also outline a prioritisation of the necessary work to "cut down" the time to maybe about ... mmm... three or so months, by leaving out some of the "nice-to-have" stuff. actually... _all_ of the nice-to-have stuff :) that will at least "GetItWorking(tm)" and the rest of the bits can be considered at leisure once people go "god that's awful, we can't possibly leave it like that" and hopefully hopefully things will actually progress from there. remember - please: this stuff is sufficiently complicated such that you really can't afford the niceties such as "It Must Be Perfect (tm)" before it can be accepted. i've seen that shit before, and it's a baad mxxxxxxxer path to go down, especially with such complex and heavily interdependant reverse-engineering projects as reactos, wine, samba and freedce. anyway. fyi - before i begin, i should mention a couple of things: 1) this message also goes out the the apache devel mailing list (specifically the APR one) because the NT style authentication thing is the sort of thing that really _should_ be in a (special?) APR util library, along with "NT Named Pipes" - see http://en.wikipedia.org/wiki/NamedPipes one of the reasons why NT-style NamedPipes is _not_ in an APR util is because it is believed that NT-style NamedPipes do not fit the "least common denominator". by having the infrastructure outlined below, it is possible to move things "up one level" to the point where unix _has_ that denominononmination. also, if APR still has support for that god-awful program-running program called Win95, it would, with not much extra effort, be possible to port some reactos components to Win95 (!) such that ThePlan outlined here would make Win95 have proper NT-style authentication (!) now there's a horrible thought that will give MS and free software people nightmares both: upgrading Win95 by installing free software components at it. muhahahahah ahem. 2) i have filled in a number of pages on wikipedia.org. see http://en.wikipedia.org/wiki/User:lkcl. please take the time to review these pages, PLEASE help me with my totally biased "POV" (point-of-view) comments, by either editing the pages direct or by adding comments on the "talk" pages as appropriate. or alternatively dumping me in the nearest pond if ever you meet me. wikipedia is supposed to be encyclopedia-ic and some of my comments are anything but that. help!!! 3) please due to the quite broad distribution of this message across multiple mailing lists, please do NOT ask stupid questions like "what the hell do we need to use samba tng for, why can't we use samba in reactos"? and "why is this guy bothering us with this insane stuff?" and "how do i use killfiles?" or terry pratchett's - more specifically the librarian's favourite - "where has all the pie and custard gone?" please do your research: see if nothing else http://en.wikipedia.org/wiki/Samba_TNG_software and then start googling. anyway. onward. roughly in order of dependence, with "nice-to-have" status added as well: 1) port FreeDCE to Win32 - more specifically add in autoconf support for an alternative threading model - the one in reactos. no, this is not a joke: MSRPC is a critical part of NT infrastructure it's just that very few people are actually aware of this (including the US DoJ and the EU commission...) see http://www.google.co.uk/search?q=lkcl+wine+freedce for discussion links as to why - it's a long story and it took me several dozen messages spanning over many days to outline it in sufficient detail for it to be understood (mostly me getting things straight in my head...) status: "nice to have" but you will soon wish that you _did_ have it!!! there is also an opportunity to support Wine, here: essentially it's the same job, for DCOM, for proper "authentication" purposes in Wine just like in ReactOS... it's a long story. 2) remove dependence on "unix" security model from Samba TNG's services starting with samrd (perhaps by finishing off samrtdbd?) status: "essential". sub-projects: a) in Samba TNG, rework winbindd such that it is a REQUIRED service, and it has "modes" that, instead of "inventing" links between unix uids and nt sids, it reads smbpasswd and correlates unix uids with nt sids _just_ like is done now - but hard-coded through the awful code that has had to dieee since... about two weeks after i wrote it, back in 1999. this one's a long story but it's not actually required for reactos but _might_ be required for wine... status: "pretty much essential" but not for reactos but for making life easy to share tng development between reactos and unix. b) in Samba TNG, make the authentication code (smb-side and rpc server back-end-wise) contact winbindd BUT ONLY for resolving unix uids and unix gids - which is actually a VERY small task involving a few hundred lines of code. this goes back to the "SURS" stuff i wrote up in 1999 - but instead of a library it hands off the responsibility for sid<->uid+gid lookups to winbindd. it _may_ also be essential for Wine to operate correctly with authentication (which is a "stub" at the moment just like it is in reactos), to interoperate with other programs, to cache login credentials in order to do smb client-side operations, that sort of thing, under which circumstances, it will be necessary for Wine to have the same sort of thing. it's no big deal :) status: same as for 2a). c) in Samba TNG, abandon all use of hard-coded MSRPC stuff and utilise FreeDCE instead, and do a rewrite of all services, one by one (and because samba tng is modular, this _can_ be done one-by-one, checking MSRPC interoperability along the way between the "old" services, the "new" services, and also with NT itself). in and of itself, this critically depends on making DCEThreads reliable, though, or adding support (finally!) for POSIX threads. status: "non-essential" but you would soon end up wishing that you had :) 3) complete LsaLogonUser, add LsaLogonUserEx, in NTOSKRNL.DLL, and friends. my favourites. the LSASS stuff. these functions are quite simple: they are "redirectors" - a vector table of functions is required to be passed in, which includes things like "authenticate with my lovely service" and "free some memory". there are many LSASS sub-services: one of them is Netware, one of them is MSV1_0.DLL, one of them is Kerberos. there are others. LSASS is based on _exactly_ the same technique that dlopen does e.g in libdvdcss, and in freedce's ntlmsspauth.so, and in... mmm... the freedce transport module infrastructure and _many_ other projects ... except of course it's NT-based table of higher-order-functions not unix "dlopen()" ones. i'll stop trying to teach people to suck eggs, now *embarrassed* :) status: "essential". sub-projects: a) write an MSV1_0.DLL which registers with the LSASS service. this will utilise MSRPC functions that call into the Samba TNG "NETLOGON" service. there already exists "basic" functions inside Samba TNG that... well... it's a bit messy, but they work. the key function to be calling is cli_nt_login_interactive, and you will notice _very_ quickly from the arguments hey, some of those look... kinda... familiar!! see http://viewcvs.samba-tng.org/cgi-bin/viewcvs.cgi/tng/source/rpc_client/cli_… status: "essential." the "porting" bit of this code to FreeDCE i would classify as "non-essential" but again, you will soon wish that you _were_ using FreeDCE. that's basically it: there are other sub-projects such as turning the "Registry" code in ReactOS (or Wine) into an MSRPC service (yes, i did say pretty much everything that's anything critical in NT is an MSRPC service, didn't i? :) but they aren't "essential". i say basically it, but that ONE stupid function, cli_nt_login_interactive, drags in quite literally HALF A MILLION lines of code - 250,000 lines of it in FreeDCE, alone (which, like i said, could possibly be avoided but the hard-coded MSRPC stuff in samba tng is sufficiently awkward to make a rewrite utilising FreeDCE very attractive). what i would suggest is the following: 1) write an MSV1_0.DLL "test stub" in combination with completing the LSASS functions, which supports a username "test", domain of "test" and password of "test". code up a hard-coded "blob" - a NET_USER_INFO_3 structure - that contains the response / essential information of groups, gids, sids, user session key etc. see http://viewcvs.samba-tng.org/cgi-bin/viewcvs.cgi/tng/source/include/rpc_net… (note: i _did_ say it would be nice to utilise FreeDCE didn't i? well, the NET_USER_INFO_3 structure in that header file is a "messy" version that i recreated from off-the-wire back in about ... mmmm... 1997. there _do_ exist IDL-generated versions of this data structure, thanks to matthew chapman - NETLOGON.idl for example). once that works... 2) write a lovely insecure method of "outsourcing" the username, domain and password to an external server - Samba TNG - which performs the authentication on your behalf and gets back "real" data. this could be done simply with a TCP connection, throw the data in-the-clear over to a simple temporary shim service blah blah, bob's your uncle. 3) port samba tng's netlogond, samrd and lsarpcd to ReactOS. this is quite straightforward: about the only really essential "missing" bit is to tie the services in to "NT Named Pipes" rather than unix domain sockets. _but_ - they only need to be plugged in to a back-end transport which all services - any of samba tng's MSRPC services - would use. so there's a key bit of work needed - probably under 400 lines of code - and the rest should fall into place. this is where it would be SO much easier to be utilising FreeDCE. all that's needed would be to write a FreeDCE "transport" plugin for ReactOS - ncacn_np - and then you'd be DONE. it's a long story... hey, has someone implemented TransactNamedPipe() and CreateNamedPipe() in ReactOS? if not, it's quite straightforward to do, and it involves dropping opaque data blobs onto smbd (again, smbd ported to reactos...) i _did_ say it's a long story, didn't i? :) 4) finally: track down how "LsaLogonUserEx" works. LsaLogonUser utilises cleartext passwords. LsaLogonUserEx i BELIEVE utilises NT and LM password hashes, or some brain-dead encrypted variant thereof. once 1) is completed, then TA-DAAAAA!!! lib/secur/lsa.c's "LsaLogonUser" function actually gets REAL DATA! okay. notes: 1) regarding FreeDCE. see http://en.wikipedia.org/wiki/FreeDCE freedce is an interoperable version of MSRPC that is derived from EXACTLY the same source code (DCE 1.0 reference implementation) that is present in Windows NT. DCE/RPC was co-opted / adopted / borg-ified by microsoft to form the basis of NT domains because paul leach, a co-founder of apollo computers and originator of NCS which became DCE/RPC, ended up working for microsoft back at the time when dave cutler was doing the original NT 3.1. using FreeDCE is non-essential for small projects of less than about 8,000 lines of code. Samba TNG's MSRPC code comprises OVER ONE HUNDRED THOUSAND lines of code. that i carried on hand-crafting MSRPC packets for three years simply demonstrates quite how bloody stupid i am. that you - the wine team - continue to reinvent an non-interoperable version of MSRPC, for binary-level "DCOM" interoperabiltiy ONLY, demonstrates quite how just as bloody stupid you are being. that _can_ be taken as a compliment, as i genuinely i mean it with the greatest of respect. 2) regarding a strategy to "minimise" the amount of time needed to "Get Things Working". a) utilise samba tng as-it-is, porting it as-is to ReactOS (mingw32) b) utilise cli_nt_login_interactive() as-it-is. c) complete MSV1_0.DLL. this will be SUFFICIENT and would only take a few months. enhancements come later, roughly in this order: a) complete a port of FreeDCE to ReactOS, by beating DCEthreads to death and replacing it with Win32 (NT) threads - #ifdef style, autoconf style. b) locate NETLOGON.idl, samr.idl and lsarpc.idl from matthew chapman's stuff, or from "todd sabin's" http://razor.bindview.com, or from the samba web site. actually... see: http://www.bindview.com/services/razor/utilities/ compile up CLIENT-SIDE ONLY, using dceidl, and create a library for use inside MSV1_0.DLL. i know todd developed interoperable versions of these idl files, because he was using them, compiled with MIDL.EXE, to do security tests against NT 4.0. remember: these IDL files are what microsoft DOESN'T want anyone to have, and there are very good _legitimate_ reasons for it: they are "behind-the-scenes" APIs which, if some idiot inside microsoft went and wrote a tool which became publicly used and relied on, they would be stuffed: they have ENOUGH apis which date back 15 years and they don't need any more. that having been said, i hate the fact that they are forcing people to pay $50k up-front and then $100 per-client for frakkin _information_. bastards. c) replace cli_nt_login_interactive() with a function that utilises the above library that utilises netlogon, samr and lsarpc client-side stuff from b) above. basically, what it boils down to is that the functions inside cli_nt_login_interactive i wrote BY HAND after examining MSRPC traffic. those functions neeeed too dieeee and they can easily be replaced one-by-one with the "proper" versions from doing "dceidl -client lsarpc.idl". it takes a couple of seconds and you get a header file lsarpc.h and a lsarpc.o and you're DONE. question. why did i spend so long doing hand-marshalling of the nt domains code. perhaps because i would not be able to give microsoft absolute hell for three frakkin years? d) consider porting, one-by-one, the Samba TNG services lsarpcd, netlogond and samrd (or better samrtdbd) to FreeDCE runtime infrastructure. this is NOT essential but it is very worthwhile. every project needs to do at least two throw-aways and with the samba tng code, there has been approximately one and a half throwaways so far... time for a major one, ESPECIALLY in light of the reactos project. FINALLY: e) consider writing that winregd service but actually picking up REAL registry hive files. someone did write a "reader" of registry files, i do not recall who it was. [note: YESSSS!!! yeeeeeehawww, todd i could KISS you!!] http://www.bindview.com/Services/RAZOR/Utilities/Unix_Linux/ntreg_readme.cfm todd wrote a registry-hive-reader as a linux filesystem driver!!!!! todd, you are bloody mad. *smooch*. f) consider writing a samr service with the FreeDCE runtime that utilises "registry" functions RegXXXX - _properly_. anyway, if you got this far: congratulations and welcome to a brief nightmare history of the development behind NT Domains Authentication. all of the infrastructure above _already_ exists - in Samba TNG. it's just... it works. it's a bit creaky at the edges, but it works. how about it? l. p.s. it almost goes without saying, but i will hint at it once again: you will not find the samba team's goals and strategic direction to be compatible with reactos. as a team, they lack the insight, vision and project management skills to be able to cope with such inter-dependant insane gibberish. this i say with much sadness because they are highly respected individuals in the free software community, and yet they are taking the samba project in very different - and ultimately time-consuming - directions from what is really really needed. due to pride they cannot admit this in public but they have been known to admit it in private. much much disappointment and sadness and there's absolutely nothing i can do about it. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

4 6

Re: Wine test results problem
by Juan Lang 02 Sep '05

02 Sep '05

Hi Katerina, > I execute Wine tests on clean Windows XP SP2 and Windows 2003 SP1 EE. > > Why the number of tests executed and number of failures are so > different for the identical test groups? There are bugs in the tests, unfortunately. For example, these failures: > -tests/shellpath.c: 10 tests executed, 0 marked as todo, 0 failures. > +tests/shellpath.c: 10 tests executed, 0 marked as todo, 4 failures. There's a bug in that test, it succeeds the first time run on Windows, but fails subsequently because it attempts to delete a non-empty directory. (That's my fault, I wrote that test.) > How should I fix this to obtain stable results? Report the failing tests here. It would help if you could report the actual failures, not just the number of failures. Then keep bugging us till someone fixes them (or, submit patches that fix the tests ;) ) Cheers, --Juan ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs

1 0

Strange problem with OpenGL in recent versions of wine
by Daniel 02 Sep '05

02 Sep '05

Hi there, recent versions of wine have shown a very peculiar behaviour for me. The first I noticed it with was 20050628, whereas I know 20050310 to work in this respect. What happens is that any program that uses D3D or OpenGL will at startup complain that it is missing hardware acceleration, that I should change the color depth or some such thing. The program will then quit or switch to software rendering. Wine will at the same time show an OpenGL-related error. The exact error will differ from program to program, but it will always say the same: No Pixelformat matching what the program wanted could be found. Programs with which I have experienced this: Half-Life Unreal Quake 3 Demo Cube Hitman I seem to be the only one having this problem, as I couldn't find anything on the web. Is there something obvious I am missing? (Yes, Linux Q3 works fine) I would really appreciate any help with this, as I'm out of things to try. Feel free to ask for additional info, logfiles etc. regards, Daniel Skorka

1 0

Re: include/guiddef.h: C++ compatibility patch (with MSVC++ support)
by Dmitry Timoshkov 02 Sep '05

02 Sep '05

"Troy Rollo" <wine(a)troy.rollo.name> wrote: > --- include/guiddef.h (revision 26053) > +++ include/guiddef.h (local) > @@ -35,12 +35,18 @@ > #undef DEFINE_GUID > > #ifdef INITGUID > +#ifdef __cplusplus > #define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > + EXTERN_C const GUID name = \ > + { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } } > +#else > +#define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > const GUID name = \ > { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } } > +#endif > #else > #define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > - extern const GUID name > + EXTERN_C const GUID name > #endif > > #define DEFINE_OLEGUID(name, l, w1, w2) \ There are 2 problems with this patch: you forgot to provide a definition for EXTERN_C, and it needlessly duplicates code for the __cplusplus case. -- Dmitry.

2 1

Re: URLMON: Added CreateAsyncBindCtxEx implementation
by Robert Shearman 02 Sep '05

02 Sep '05

Jacek Caban wrote: >+static void test_CreateAsyncBindCtxEx(void) >+{ >+ IBindCtx *bctx = NULL, *bctx_arg = NULL; >+ IBindStatusCallback *bsc = statusclb_create(); >+ BIND_OPTS bindopts; >+ HRESULT hres; >+ >+ hres = CreateAsyncBindCtxEx(NULL, 0, NULL, NULL, NULL, 0); >+ ok(hres == E_INVALIDARG, "CreateAsyncBindCtx failed: %08lx, expected E_INVALIDARG\n", hres); >+ >+ hres = CreateAsyncBindCtxEx(NULL, 0, NULL, NULL, &bctx, 0); >+ ok(hres == S_OK, "CreateAsyncBindCtxEx failed: %08lx\n", hres); >+ >+ if(SUCCEEDED(hres)) { >+ bindopts.cbStruct = sizeof(bindopts); >+ hres = IBindCtx_GetBindOptions(bctx, &bindopts); >+ ok(SUCCEEDED(hres), "IBindCtx_GetBindOptions failed: %08lx\n", hres); >+ ok(bindopts.grfFlags == BIND_MAYBOTHERUSER, >+ "bindopts.grfFlags = %08lx, expected: BIND_MAYBOTHERUSER\n", bindopts.grfFlags); >+ ok(bindopts.grfMode = STGM_READWRITE | STGM_SHARE_EXCLUSIVE, > > Are you sure you mean to assign the value instead of just testing it? >+ "bindopts.grfMode = %08lx, expected: STGM_READWRITE | STGM_SHARE_EXCLUSIVE\n", >+ bindopts.grfMode); >+ ok(bindopts.dwTickCountDeadline == 0, >+ "bindopts.dwTickCountDeadline = %08lx, expected: 0\n", bindopts.dwTickCountDeadline); >+ >+ IBindCtx_Release(bctx); >+ } >+ >+ CreateBindCtx(0, &bctx_arg); >+ hres = CreateAsyncBindCtxEx(NULL, 0, NULL, NULL, &bctx, 0); >+ ok(hres == S_OK, "CreateAsyncBindCtxEx failed: %08lx\n", hres); >+ >+ if(SUCCEEDED(hres)) { >+ bindopts.cbStruct = sizeof(bindopts); >+ hres = IBindCtx_GetBindOptions(bctx, &bindopts); >+ ok(SUCCEEDED(hres), "IBindCtx_GetBindOptions failed: %08lx\n", hres); >+ ok(bindopts.grfFlags == BIND_MAYBOTHERUSER, >+ "bindopts.grfFlags = %08lx, expected: BIND_MAYBOTHERUSER\n", bindopts.grfFlags); >+ ok(bindopts.grfMode = STGM_READWRITE | STGM_SHARE_EXCLUSIVE, >+ "bindopts.grfMode = %08lx, expected: STGM_READWRITE | STGM_SHARE_EXCLUSIVE\n", >+ bindopts.grfMode); > > Same here. -- Rob Shearman

1 0

Wine test results problem
by Katerina Nizhnik 02 Sep '05

02 Sep '05

Hi, I execute Wine tests on clean Windows XP SP2 and Windows 2003 SP1 EE. I tried to use both pre-compiled binary from http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/winetest-latest.exe and Wine sources built by myself with Visual Studio .NET 2003 (20050830 version). What I do is just launching the test several times on the same machine and comparing log files received. Please, see the sample diff of 2 such log files. Why the number of tests executed and number of failures are so different for the identical test groups? It seems to be some synchronization problem. How should I fix this to obtain stable results? Thank you in advance. ------------------------------------------------------------ @@ -50,7 +50,7 @@ module: 34 tests executed, 0 marked as todo, 0 failures. mailslot: 75 tests executed, 0 marked as todo, 0 failures. path: 1741 tests executed, 0 marked as todo, 0 failures. -pipe: 419 tests executed, 0 marked as todo, 0 failures. +pipe: 418 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. @@ -78,7 +78,7 @@ util: 139 tests executed, 0 marked as todo, 136 failures. mlang: 11211 tests executed, 0 marked as todo, 20 failures. msacm: 385 tests executed, 0 marked as todo, 0 failures. -profile: 127 tests executed, 0 marked as todo, 1 failure. +profile: 127 tests executed, 0 marked as todo, 0 failures. htmldoc: 688 tests executed, 0 marked as todo, 0 failures. protocol: 255 tests executed, 0 marked as todo, 0 failures. db: 73 tests executed, 0 marked as todo, 0 failures. @@ -104,7 +104,7 @@ env: 611 tests executed, 0 marked as todo, 0 failures. error: 813 tests executed, 0 marked as todo, 0 failures. generated: 1981 tests executed, 0 marked as todo, 0 failures. -info: 765 tests executed, 0 marked as todo, 0 failures. +info: 725 tests executed, 0 marked as todo, 0 failures. large_int: 700 tests executed, 0 marked as todo, 0 failures. path: 230 tests executed, 0 marked as todo, 5 failures. reg: 9 tests executed, 0 marked as todo, 0 failures. @@ -133,7 +133,7 @@ main: 15 tests executed, 0 marked as todo, 1 failure. generated: 1141 tests executed, 0 marked as todo, 0 failures. shelllink: 116 tests executed, 0 marked as todo, 3 failures. -tests/shellpath.c: 10 tests executed, 0 marked as todo, 0 failures. +tests/shellpath.c: 10 tests executed, 0 marked as todo, 4 failures. tests/shellpath.c: 4 tests executed, 0 marked as todo, 0 failures. shellpath: 447 tests executed, 0 marked as todo, 3 failures. shlexec: 20 tests executed, 0 marked as todo, 0 failures. @@ -174,4 +174,4 @@ timer: 44 tests executed, 0 marked as todo, 0 failures. wave: 289 tests executed, 0 marked as todo, 15 failures. protocol: 26 tests executed, 0 marked as todo, 0 failures. -sock: 8971 tests executed, 0 marked as todo, 5 failures. +sock: 8951 tests executed, 0 marked as todo, 5 failures. ------------------------------------------------------------ -- Sincerely yours, katy

1 0

Re: WINEALSA: comment on unexpected shrinking of mmap-buffer (resend)
by Alex Villacís Lasso 01 Sep '05

01 Sep '05

Robert Reif wrote: > Alex Villacís Lasso wrote: > >> Robert Reif wrote: >> >>> Fix the wine ALSA driver rather than the test unless you can prove >>> that the test fails on Windows. >>> > Hers is a real quick hack that fixes the problem. This should give > you someplace to start. > >------------------------------------------------------------------------ > >? audio.c.test >? audio.diff >Index: audio.c >=================================================================== >RCS file: /home/wine/wine/dlls/winmm/winealsa/audio.c,v >retrieving revision 1.96 >diff -p -u -r1.96 audio.c >--- audio.c 12 Aug 2005 11:17:54 -0000 1.96 >+++ audio.c 31 Aug 2005 00:59:33 -0000 >@@ -2527,14 +2527,16 @@ static DWORD wodOpen(WORD wDevID, LPWAVE > getFormat(wwo->format.Format.wFormatTag)); > > dir=0; >- EXIT_ON_ERROR( snd_pcm_hw_params_set_buffer_time_near(pcm, hw_params, &buffer_time, &dir), MMSYSERR_INVALPARAM, "unable to set buffer time"); >+// EXIT_ON_ERROR( snd_pcm_hw_params_set_buffer_time_near(pcm, hw_params, &buffer_time, &dir), MMSYSERR_INVALPARAM, "unable to set buffer time"); >+ buffer_size = 0x10000; >+ EXIT_ON_ERROR( snd_pcm_hw_params_set_buffer_size_near(pcm, hw_params, &buffer_size), MMSYSERR_INVALPARAM, "unable to set buffer size"); > dir=0; > EXIT_ON_ERROR( snd_pcm_hw_params_set_period_time_near(pcm, hw_params, &period_time, &dir), MMSYSERR_INVALPARAM, "unable to set period time"); > > EXIT_ON_ERROR( snd_pcm_hw_params(pcm, hw_params), MMSYSERR_INVALPARAM, "unable to set hw params for playback"); > > err = snd_pcm_hw_params_get_period_size(hw_params, &period_size, &dir); >- err = snd_pcm_hw_params_get_buffer_size(hw_params, &buffer_size); >+// err = snd_pcm_hw_params_get_buffer_size(hw_params, &buffer_size); > > snd_pcm_sw_params_current(pcm, sw_params); > EXIT_ON_ERROR( snd_pcm_sw_params_set_start_threshold(pcm, sw_params, dwFlags & WAVE_DIRECTSOUND ? INT_MAX : 1 ), MMSYSERR_ERROR, "unable to set start threshold"); > > From what I could see from the patch, it tries to set a buffer size instead of a buffer time. However, the patch did not solve the problems as it is. First, the patch supplies a constant value for snd_pcm_hw_params_set_buffer_size_near(). However, the ALSA documentation states that the parameter for buffer_size for this function is given in *frames*, not bytes. Since a frame (nChannels * bitsPerSample / 8) can be from 1 to 4 bytes depending on the requested format, this patch only fixes the frame length, not the byte length. So the attached patch divides the required buffer size (in bytes) by the frame size to arrive to the buffer size in frames. Second, even after the division, the ALSA API is unable to honor the exact value required (at least in my hardware). For most formats the upper limit on the byte size is 30104 bytes, but for the reference tone it changes to 15052 bytes. So it triggers the buffer resize all over again. The attached patch hardcodes the value of 15052 bytes (0x3acc) as the required buffer size, and then the ALSA API doesn't resize the buffer. But obviously, this is a machine-dependent value that might be different in everybody else's machine. Any other value greater than 15052 triggers the buffer resize, and other values below it cause awful buzzings and silences on the games I have tested. Even the chosen value of 15052 bytes, though it works in the tested games, causes buzzings instead of the proper tone on some 8000Hz and 11050Hz tests (the tests where the playtime is around 100-300 ms instead of 1000 ms in the attached trace). Third (but this is no longer a winealsa issue), I still get the critical section timeouts on invalid threads in aprox. 1 in 5 runs of the interactive dsound test, even on an idle CPU. This proves that the timeout bug is not because of CPU load, and should be investigated further. All of this leads me to think that the winealsa driver should give up on trying to provide access to the direct mmap buffer, and revert to providing a fixed-size buffer that is then used to feed the actual ALSA buffer. This would a) hide the buffer resizes from the tests and the games, and b) remove the need of the undocumented hardware pointer function. In fact, I do not remember what was the rationale behind switching from the old model to the current one. In addition, I have tested a few games Any comments on this are welcome. Alex Villacís Lasso

2 1

curses problems in wineconsole
by Robert Lunnon 01 Sep '05

01 Sep '05

curses.c in wineconsole seems to be under (re) development at the moment. Under Solaris I get the following. I presume this is because the changes are being developed with ncurses in mind. gmake gcc -c -I. -I. -I../../include -I../../include -DUNICODE -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I /opt/sfw/cups/include -I /opt/sfw/cups/include -o curses.o curses.c In file included from winecon_private.h:24, from curses.c:50: ../../include/wincon.h:133:1: warning: "MOUSE_MOVED" redefined In file included from curses.c:41: /usr/include/curses.h:1487:1: warning: this is the location of the previous definition curses.c:70: error: parse error before "mmask_t" curses.c:70: warning: no semicolon at end of struct or union curses.c:75: error: parse error before '}' token curses.c:95: error: `mouseinterval' undeclared here (not in a function) curses.c:95: warning: type defaults to `int' in declaration of `p_mouseinterval' curses.c:96: error: `mousemask' undeclared here (not in a function) curses.c:96: warning: type defaults to `int' in declaration of `p_mousemask' curses.c: In function `WCCURSES_ResizeScreenBuffer': curses.c:221: error: dereferencing pointer to incomplete type curses.c:221: error: dereferencing pointer to incomplete type curses.c:222: error: dereferencing pointer to incomplete type curses.c:223: error: dereferencing pointer to incomplete type curses.c:225: error: dereferencing pointer to incomplete type curses.c:226: error: dereferencing pointer to incomplete type curses.c:226: error: dereferencing pointer to incomplete type curses.c:229: error: dereferencing pointer to incomplete type curses.c: In function `WCCURSES_PosCursor': curses.c:250: error: dereferencing pointer to incomplete type curses.c:257: error: dereferencing pointer to incomplete type curses.c: In function `WCCURSES_ComputePositions': curses.c:299: error: dereferencing pointer to incomplete type curses.c: In function `WCCURSES_Refresh': curses.c:354: error: dereferencing pointer to incomplete type curses.c:356: error: dereferencing pointer to incomplete type curses.c:356: error: dereferencing pointer to incomplete type curses.c:356: error: dereferencing pointer to incomplete type curses.c: In function `WCCURSES_FillMouse': curses.c:557: error: `MEVENT' undeclared (first use in this function) curses.c:557: error: (Each undeclared identifier is reported only once curses.c:557: error: for each function it appears in.) curses.c:557: error: parse error before "mevt" curses.c:559: error: `mevt' undeclared (first use in this function) curses.c:559: error: too many arguments to function curses.c:586: error: `BUTTON_SHIFT' undeclared (first use in this function) curses.c:588: error: `BUTTON_CTRL' undeclared (first use in this function) curses.c:590: error: `BUTTON_ALT' undeclared (first use in this function) curses.c: In function `WCCURSES_FillCode': curses.c:657: error: dereferencing pointer to incomplete type curses.c:746: error: `KEY_RESIZE' undeclared (first use in this function) curses.c: In function `WCCURSES_GetEvents': curses.c:830: error: `KEY_CODE_YES' undeclared (first use in this function) curses.c: In function `WCCURSES_DeleteBackend': curses.c:849: error: `mmask_t' undeclared (first use in this function) curses.c:849: error: parse error before "mm" curses.c:853: error: dereferencing pointer to incomplete type curses.c:855: error: dereferencing pointer to incomplete type curses.c:856: error: dereferencing pointer to incomplete type curses.c:856: error: `mm' undeclared (first use in this function) curses.c:856: error: called object is not a function curses.c:859: error: dereferencing pointer to incomplete type curses.c: In function `WCCURSES_MainLoop': curses.c:873: error: dereferencing pointer to incomplete type curses.c: In function `WCCURSES_InitBackend': curses.c:906: error: invalid application of `sizeof' to incomplete type `inner_data_curse' curses.c:921: error: dereferencing pointer to incomplete type curses.c:956: error: `BUTTON_SHIFT' undeclared (first use in this function) curses.c:956: error: `BUTTON_CTRL' undeclared (first use in this function) curses.c:956: error: `BUTTON_ALT' undeclared (first use in this function) curses.c:957: error: dereferencing pointer to incomplete type curses.c:957: error: called object is not a function curses.c:962: error: called object is not a function curses.c:966: error: dereferencing pointer to incomplete type curses.c:966: error: called object is not a function gmake: *** [curses.o] Error 1

2 2

Re: Web Server Back Online
by Jeremy Newman 01 Sep '05

01 Sep '05

Try that, let me know if it's better. Note: web browses cache mime type as well, so try a different .bin if needed. I'll try it for now. I played with mod_mime_magic as well, but was unable to get any joy out of it. It is supposed to do what the command 'file' does and get the mime type based on the contents of the file. Didn't seem to work though. On Thu, 2005-09-01 at 10:49 -0500, Robert Shearman wrote: > Could you configure .bin files to have a MIME type of text/x-diff or > something in Apache? Maybe just for the mailman directory if there are > other .bin files on the web site. >

1 0

uxtheme requiring shlwapi
by Aric Stewart 01 Sep '05

01 Sep '05

Thanks for the great work on this! It is really cool, however I am having a dependency problem that would be great to resolve. uxtheme currently links in shlwapi.dll, shlwapi.dll in turn links in ole32.dll. Since WM_NCCREATE seems to load uxtheme it would be that ole32 is being loaded almost all the time now. This is an issue because when we here at CodeWeavers try to install dcom95.exe we need to set ole32=native (ie, disabled) so that dcom95 does not detect the builtin version. However because uxtheme is now being loaded with MessageBoxA, the install fails because it is unable to load ole32, thus shlwapi and thus uxtheme. Looking at uxtheme it seems like there are only 3 functions being used out of shlwapi. StrChrW: this is also located in comctl32.dll, while i hate to add comctl32.dll as a dependency to swap out shlwapi, it does solve the current problem, also a quick reimplementation of StrChrW as a helper function would remove this problem totally. SHRegGetPathW and PathAddBackslashW: These are really convenient functions but should not be hard to make little helper functions to replace the dependency. Any chance these changes could be made? Thanks alot, -aric

2 2

Re: KERNEL: check for NULL in LoadModule16
by Andreas Mohr 01 Sep '05

01 Sep '05

Hi, On Mon, Aug 29, 2005 at 12:37:31PM -0500, Alex Villacís Lasso wrote: > An old copy of Print Shop Deluxe Companion manages to supply a NULL as a > name to be loaded by LoadLibrary16 --> LoadModule16 --> SIGSEGV. This > patch adds a check to return ERROR_READ_FAULT instead of crashing. > > Alex Villacís Lasso > > Changelog: > * Add a NULL check in LoadModule16 Are you sure that Windows does that thing? Somehow I really cannot imagine that during all these years this one has gone unnoticed... (and is ERROR_READ_FAULT the correct error to return here?) Thanks, Andreas Mohr

3 5

Re: Wine device drivers proposal
by Evgeny F 01 Sep '05

01 Sep '05

In message Mon, 28 Mar 2005 02:30:28 -0800, Damjan Jovanovic wrote: > I propose adding a driver loading system to Wine that > works as follows: > -CreateFile() gets a device filename, like (in my > case) \\.\MiiScan0 > -Currently, Wine's behaviour for such a filename is to > try load a VXD. > -In the case of VXD loading failure, a search is > performed in (Wine's) C:\Windows\System32\Drivers (or > somewhere else?) for a matching driver. > > The driver is then loaded and used for (at least): > ReadFile() > WriteFile() > DeviceIoControl() > CloseHandle() I am doing now a dll which should load scanner microdriver and implement all the surrounding API's. Can anybody tell, what naming convention Windows uses for USB devices ("\\.\????")? > 2. The driver is a file giving a process to start and > some IPC method to use. Wine starts the process and > uses the IPC method to communicate with the driver. > This is good as far as Wine's current ReadFile() and > WriteFile() go, since they don't have to know they're > not writing to an actual file. The problem here is, > which IPC method supports both read() and write() on > the same file descriptor, preserves message > boundaries, and carries out-of-band data for > DeviceIoControl()? I was thinking TCP sockets, but > they don't preserve message boundaries. Local UNIX sockets would do fine, do we really have to preserve message bounderies? Evgeny

4 8

Re: include/guiddef.h: C++ compatibility patch
by Dmitry Timoshkov 01 Sep '05

01 Sep '05

"Troy Rollo" <wine(a)troy.rollo.name> wrote: > #ifdef INITGUID > +#ifdef __cplusplus > #define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > + extern const GUID name = \ > + { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } } > +#else > +#define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > const GUID name = \ > { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } } > +#endif > #else > #define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > extern const GUID name PSDK has 'extern' for both C and CPP cases, just the CPP one has 'extern "C"'. We have to use the same approach. -- Dmitry.

4 4

Problems with winecfg and theming
by Paul Vriens 31 Aug '05

31 Aug '05

Hi, I'm not able to use winecfg and theming. If I select to add a theme I get an exception after selecting the file and clicking OK. the .msstyles files seems to have been copied to the right place. When I however start winecfg again and go to the Appearance tab I get a new exception. Remove everything under Resources/Themes 'fixes' this so there must be something wrong with the enumeration. Anybody else experiencing this? Paul.

2 1

Wine 20050830, Notes 6.51 and uxtheme.dll.so
by Kevin DeKorte 31 Aug '05

31 Aug '05

I installed Wine 20050830 this morning and got it working with Notes after fixing a problem with usp10.dll. I was then using Notes and I selected an attachment and right clicked and selected Save. The notes crash handler then took over and Notes shut down. The crash handler reported and error in uxtheme.dll, but did not give me a trace back to send in. I'm guessing it is a missing function in uxtheme for the standard "save" dialog box. Reverting back to Wine 20050725 solves this issue. Kevin -- Get my public GnuPG key from http://keyserver.veridis.com:11371/export?id=7574690260641978351

1 0

Oxford Genie ERROR..
by MoUCLAs 31 Aug '05

31 Aug '05

Hi, i get the following error when i try to run the "Illview02.exe" of the Oxford Genie Dictionary. I tried also with the latest version 20050830 and nothing. I run Suse 9.3 64bit. -- email me: mouclas(a)gmail.com ___________________________________________________ Greek Tech Portal: www.micronews.tk

1 0

How to diplay Unicode in Html Help Index & Table of Content
by LONG LU THANH 31 Aug '05

31 Aug '05

Dear Sir/Madam, I read one message on website " http://www.winehq.org/hypermail/wine-patches/2005/04/0004.html" about how to display unicode characters in Html Help Index & Table of Content. Could you please guide me more or please tell which Help Authoring tool that can be do it for me. Thanks so much! -- LONG LU THANH General Director MISA Jsc 218 Doi Can - Ba Dinh - Ha Noi - Vietnam MB: 090 341 1822 Tel: 844-762-7891 Email: ltlong(a)misa.com.vn Website: http://www.misa.com.vn

1 0

Wine 20050830 and Notes 6.51
by Kevin DeKorte 31 Aug '05

31 Aug '05

Wine 20050830 will not startup Notes 6.51, rolling back to the previous version works fine. Kevin Crash Dump: wine nlnotes fixme:uniscribe:ScriptGetProperties 0x61be3aa8,0x61be3a7c fixme:uniscribe:ScriptRecordDigitSubstitution 1024,0x61be3a70 wine: Call from 0x41558608 to unimplemented function usp10.dll.ScriptCacheGetHei ght, aborting fixme:netapi32:NetUserEnum ((null),20, 0x2,0x4191f2e4,2,0x4191f4ec,0x4191f4f0,0x 4191f2dc) stub! fixme:advapi:LookupAccountSidA ((null),sid=0x4191f01c,0x4191e9d4,0x4191edd8 (512) ,0x4191ebd4,0x4191efe0(512),0x4191efe4): semi-stub fixme:advapi:LookupAccountSidA ((null),sid=0x4191ed2c,0x4191e6e4,0x4191eae8 (512) ,0x4191e8e4,0x4191ecf0(512),0x4191ecf4): semi-stub fixme:advapi:LookupAccountSidA ((null),sid=0x4191ed2c,0x4191e6e4,0x4191eae8 (512) ,0x4191e8e4,0x4191ecf0(512),0x4191ecf4): semi-stub fixme:advapi:LookupAccountSidA ((null),sid=0x4191ed2c,0x4191e6e4,0x4191eae8 (512) ,0x4191e8e4,0x4191ecf0(512),0x4191ecf4): semi-stub fixme:advapi:LookupAccountSidA ((null),sid=0x4191ed2c,0x4191e6e4,0x4191eae8 (512) ,0x4191e8e4,0x4191ecf0(512),0x4191ecf4): semi-stub wine: Unhandled exception (thread 000b), starting debugger... WineDbg starting on pid 0xa Unhandled exception: page fault on read access to 0x00003c1c in 32-bit code (0x6 0001293). In 32 bit mode. fixme:dbghelp:sffip_cb NIY on 'g:\build\bin\w32\bin\nnotes.pdb' Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:60001293 ESP:4191f0e0 EBP:4191f0e8 EFLAGS:00010216( - 00 -RIAP1) EAX:0000000b EBX:00008122 ECX:00000000 EDX:000000a3 ESI:00003bda EDI:0000000a Stack dump: 0x4191f0e0: 00000000 00003bda 4191f10c 60003ef4 0x4191f0f0: 00003bda 00000000 00008128 00008000 0x4191f100: 00008122 412d2e18 00000000 4191f148 0x4191f110: 60003bab 00000000 00000000 000000a3 0x4191f120: 00008128 0000000a 00000000 4191f144 0x4191f130: 00000000 00000000 4b910d88 00000000 Backtrace: =>1 0x60001293 OSGetNativeThreadID+0x283 in nnotes (0x4191f0e8) 2 0x60003ef4 ODSReadItem+0x414 in nnotes (0x4191f10c) 3 0x60003bab ODSReadItem+0xcb in nnotes (0x4191f148) 4 0x6018dbd8 DesignTranslateSpecialViewName+0xdc8 in nnotes (0x4191f46c) fixme:dbghelp:sffip_cb NIY on 'g:\build\bin\w32\bin\nfileret.pdb' 5 0x00401aae in nfileret (+0x1aae) (0x4191feec) 6 0x00401cbd EntryPoint+0xc5 in nfileret (0x4191ff2c) 7 0x4157d7d3 start_process+0xc3(arg=0x0) [/home/kdekorte/Downloads/wine-200508 30/dlls/kernel/process.c:995] in kernel32 (0x4191fff4) 8 0x400246a1 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) 0x60001293 OSGetNativeThreadID+0x283 in nnotes: cmpl %eax,0x42(%esi) Wine-dbg>quit -- Get my public GnuPG key from http://keyserver.veridis.com:11371/export?id=7574690260641978351

3 3

Today's release fails to build for me
by Gerald Pfeifer 31 Aug '05

31 Aug '05

...with the following error (FreeBSD 5.4): /usr/bin/gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o add.o add.c In file included from add.c:39: winldap_private.h:289: error: syntax error before "BerElement" winldap_private.h:290: error: syntax error before "BerElement" winldap_private.h:322: error: syntax error before "BerElement" winldap_private.h:323: error: syntax error before "BerElement" gmake: *** [add.o] Error 1 nibal[50]:/sw/test/wine/dlls/wldap32% Due to CVS being down I cannot update my Linux build hosts nor investigate the history in detail, but this seems pretty recent (as in the last 24 to 48 hours). Any ideas? Gerald

2 1

compile pb on wine 20050830
by rmkml 31 Aug '05

31 Aug '05

Hi, look my compile pb : ... make[2]: Entering directory `/mnt3/wine-20050830/dlls/wldap32' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o add.o add.c In file included from add.c:39: winldap_private.h:289: parse error before "BerElement" winldap_private.h:290: parse error before "BerElement" winldap_private.h:322: parse error before "BerElement" winldap_private.h:323: parse error before "BerElement" make[2]: *** [add.o] Error 1 no compile pb on previous version on linux kernel2613/glibc232. Regards Rmkml

1 0

Re: WLDAP32: fix the build without openldap headers
by Andreas Mohr 31 Aug '05

31 Aug '05

Hi, On Wed, Aug 31, 2005 at 02:47:31PM +0200, Hans Leidekker wrote: > > CVS is still unavailable, so here's a patch generated without CVS. I > hope it applies cleanly. It is not. The main server might still be, but there's a rather adequate mirror available, as has even been mentioned right before the server transition. Andreas Mohr

1 0

Re: MSHTML: Beggining implementation of onload rutine
by Dmitry Timoshkov 31 Aug '05

31 Aug '05

"Jacek Caban" <jack(a)itma.pwr.wroc.pl> wrote: > +static nsIURIContentListenerVtbl nsURIContentListenerVtbl = { > + nsURIContentListener_QueryInterface, > + nsURIContentListener_AddRef, > + nsURIContentListener_Release, > + nsURIContentListener_OnStartURIOpen, > + nsURIContentListener_DoContent, > + nsURIContentListener_IsPreferred, > + nsURIContentListener_CanHandleContent, > + nsURIContentListener_GetLoadCookie, > + nsURIContentListener_SetLoadCookie, > + nsURIContentListener_GetParentContentListener, > + nsURIContentListener_SetParentContentListener > +}; Jacek, is there a reason you don't mark your vtables 'const'? -- Dmitry.

1 0

Wine-20050830 Compile error
by John Shillinglaw 31 Aug '05

31 Aug '05

Hello, I just answered my own question, after emerging openldap, the error went away. Someone might have mentioned before, there needs to be a configure test for this... John P.S. The bug system under winehq.org still seems to be down. After getting the lastest tar, I get the following error: gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o add.o add.c In file included from add.c:39: winldap_private.h:289: error: syntax error before "BerElement" winldap_private.h:290: error: syntax error before "BerElement" winldap_private.h:322: error: syntax error before "BerElement" winldap_private.h:323: error: syntax error before "BerElement" make[2]: *** [add.o] Error 1 make[2]: Leaving directory `/usr/src/wine/dlls/wldap32' make[1]: *** [wldap32] Error 2 make[1]: Leaving directory `/usr/src/wine/dlls' make: *** [dlls] Error 2 This occurs both with Wine-20050830.tar.gz and the latest cvs. I'm compiling under Gentoo ( up to date ) with gcc 3.3.5 John

2 1

Wine-20050830 Compile error
by John Shillinglaw 31 Aug '05

31 Aug '05

Hello, After getting the lastest tar, I get the following error: gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o add.o add.c In file included from add.c:39: winldap_private.h:289: error: syntax error before "BerElement" winldap_private.h:290: error: syntax error before "BerElement" winldap_private.h:322: error: syntax error before "BerElement" winldap_private.h:323: error: syntax error before "BerElement" make[2]: *** [add.o] Error 1 make[2]: Leaving directory `/usr/src/wine/dlls/wldap32' make[1]: *** [wldap32] Error 2 make[1]: Leaving directory `/usr/src/wine/dlls' make: *** [dlls] Error 2 This occurs both with Wine-20050830.tar.gz and the latest cvs. I'm compiling under Gentoo ( up to date ) with gcc 3.3.5 John

2 1

Re: wined3d - d3d9 regression testing 7_12_2005
by Ann & Jason Edmeades 31 Aug '05

31 Aug '05

Out of interest, does reversing this patch fix the wc3 fonts - If I recall correctly if was the glTranslate calls which originally made the wc3 fonts look correct, and I noticed in one of the patches Oliver changed them. He's probably right, but just in case its worth a test Try changing glTranslatef(0.9 / This->stateBlock->viewport.Width, -0.9 / This->stateBlock->viewport.Height, 0); to glTranslatef(1.0/This->stateBlock->viewport.Width, -1.0/This->stateBlock->viewport.Height, 0); in drawprim.c Jason

3 2

Re: [resend] atl.DllRegisterServer
by Alexandre Julliard 30 Aug '05

30 Aug '05

Stefan Leichter <Stefan.Leichter(a)camLine.com> writes: > Hi Alexandre, > > anything wrong with this patch ? Well, the resource id is 1, so loading it with 0x65 is certainly not going to work. Were you planning to change the resource too? -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: WLDAP32: implement more functions
by Vitaly Lipatov 30 Aug '05

30 Aug '05

В сообщении от 29 Август 2005 23:26 Hans Leidekker написал(a): > -Hans > > Changelog > Implement ldap_count_entries, ldap_count_references, > ldap_first_attribute*, ldap_first_entry, ldap_first_reference, > ldap_next_attribute*, ldap_next_entry and ldap_next_reference. I guess, this patch cause an compile error: gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o add.o add.c In file included from add.c:39: winldap_private.h:289: error: syntax error before "BerElement" winldap_private.h:290: error: syntax error before "BerElement" winldap_private.h:322: error: syntax error before "BerElement" winldap_private.h:323: error: syntax error before "BerElement" -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

2 1

BUG[1481] : unimplemented function msvcrt.dll._mbsbtype
by Vijay Kiran Kamuju 30 Aug '05

30 Aug '05

Hi, can we use the reactos implementation of the _mbsbtype? http://reactos.geldorp.nl/dc/d8d/mbbtype_8c-source.html Any ReactOS guys, please respond regarding the licensing of the above code? Thanks, Vijay

4 6

Re: wine/ include/prsht.h include/commctrl.h dlls/ ...
by Frank Richter 30 Aug '05

30 Aug '05

On 30.08.2005 12:07, Alexandre Julliard wrote: > Log message: > Frank Richter <frank.richter(a)gmail.com> > Fix warnings in 64bit. No I didn't; something must have been mixed up while making the commit message. -f.r.

1 0

Possible critical section bug - lock by invalid thread
by Alex Villacís Lasso 30 Aug '05

30 Aug '05

In several RPG I have been testing, I have found deadlocks on the sound thread - the sound loops on and on, and the program freezes. At the same time, I see messages like the following: fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fe32708)->(00010022,00000008) err:dsound:DSOUND_MixOne underrun on sound buffer 0x7fe82310 err:dsound:DSOUND_MixOne underrun on sound buffer 0x7fe82880 err:wave:DSDB_MMAPCopy mmap partially failed. err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 000a, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 0009, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 000a, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 0009, blocked by 0000, retrying (60 sec) I thought that DirectSound was not performing locking properly, until I noticed the following: all the times I see this deadlock, the thread ID "responsible" for the deadlock is 0000. From a little digging in the code, I see that 0 is the value used in the critical section when it is not held by any thread. So these are potentially cases where a previous thread frees the critical section, but somehow the critical section remains locked. I think I saw a select() call in the wineserver, used as an implementation for this wait, and this select() call times out, resulting in the behavior shown above. All these instances happen under heavy CPU load, so I suspect some sort of race condition. If I really try and bog down the CPU, I can even trigger this deadlock on the DirectSound tests (under ALSA). Could anybody who knows about Wine critical sections comment on this? I do not really understand the implementation of critical sections at the wineserver side (other than the fact that a select() is used somewhere), so I could take a long time to unravel this bug. This problem does not seem specific to DirectSound as far as I could tell, so this might be affecting a couple other apps under Wine. Also, comments on how I could supply more information on this are welcome. Alex Villacís Lasso

3 2

Possible theming bug?
by James Liggett 30 Aug '05

30 Aug '05

Hi, Yesterday I updated CVS and tried the new theme system. While I find it very impressive, I think I may have discovered a glaring problem with it. I copied the WinXP "Luna" theme from my XP partition into the Resources folder as directed by this week's WWN issue. It showed up in the Appearances tab as "Windows XP style." It works quite well, shown here: http://members.cox.net/jrliggett/screenshots/theme.png. After deciding that I preferred the old style, I set the theme back to "(No theme)" But, there was a problem: all the colors that the theme I had before were still there (but no other visual effects)--and not the usual dark gray/blue combination. Here's a shot of what I mean: http://members.cox.net/jrliggett/screenshots/theme-bug.png Is this type of behavior a bug or am I doing something wrong? Thanks, James

1 0

WINEALSA: comment on unexpected shrinking of mmap-buffer (resend)
by Alex Villacís Lasso 30 Aug '05

30 Aug '05

Alex Villacís Lasso wrote: > >> The good news: the patch sort of works (in my setup, at least, with >> Fedora Core 4). All the games I have (Japanese RPGs) now have smooth >> sound, unless the CPU load is too high. >> The bad news: the patch does nothing to make the dsound tests pass in >> Wine (but they were already failing before the patch :-) > > > In a previous post, I commented about DirectSound tests failing when > ALSA is used with full hardware acceleration. Now I know the reason why. > > As far as I can glean from the code, DirectSound is supposed to report > the application several properties of the sound system, including the > size of the hardware buffer. This hardware buffer is queried by the > snd_hw_params_get_buffer_size(), and is then converted from frame > units to bytes. Then the application, or in this case, the test, > expects the buffer size to remain constant for each and every hardware > buffer created, regardless of requested format. Only this assertion > fails in ALSA. For example, the capability query causes the following > output to be shown: > > trace:wave:DSDB_CreateMMAP format=U8 frames=11025 channels=2 > bits_per_sample=8 bits_per_frame=16 > trace:wave:DSDB_CreateMMAP created mmap buffer of 11025 frames (22050 > bytes) at 0x7c0fd100 > > This reported size (22050 bytes) remains constant as long as the > request is for U8 format with 2 channels (although the mmap address > jumps between three different values in my setup; this may or may not > be relevant). However, as soon as the requested format changes, the > trace shows the following: > > trace:wave:DSDB_CreateMMAP format=S16_LE frames=3763 channels=2 > bits_per_sample=16 bits_per_frame=32 > trace:wave:DSDB_CreateMMAP created mmap buffer of 3763 frames (15052 > bytes) at 0x7c0fd6b8 > > There goes a fourth mmap address, but the truly interesting thing is > that the buffer size also changes, and no longer matches the > previously reported size of 22050 bytes. The test then goes and plays > a 5-second sound with the (now incorrect) buffer size of 22050 bytes, > not noting that the reported position is wrapping around at 15052 bytes: > > ds3d.c:431: Playing 5 second 440Hz tone at 11025x16x2 > > ... > > trace:dsound:DSOUND_PrimaryGetPosition (0x7fe03ab8,0x7fa6fa80,(nil)) > trace:wave:IDsDriverBufferImpl_GetPosition hw_ptr=0x00000000, > playpos=0, writepos=-1, mmap_buflen_bytes=15052 > trace:dsound:DSOUND_PrimaryGetPosition playpos = 0, writepos = 0 > (0x7fe03ab8, time=1913) > trace:dsound:PrimaryBufferImpl_GetCurrentPosition playpos = 0, > writepos = 0 (0x7fe03ab8, time=1913) > ds3d.c:230:buf size=22050 last_play_pos=0 play_pos=0 played=0 / > 220500, fraction_played=0 > ds3d.c:248:offset=15052 free=6998 written=15052 / 220500 > > ... > ds3d.c:230:buf size=22050 last_play_pos=10296 play_pos=11700 > played=11700 / 220500, fraction_played=1404 > ds3d.c:248:offset=10296 free=1404 written=32346 / 220500 > ds3d.c:230:buf size=22050 last_play_pos=11700 play_pos=13104 > played=13104 / 220500, fraction_played=1404 > ds3d.c:248:offset=11700 free=1404 written=33750 / 220500 > ds3d.c:230:buf size=22050 last_play_pos=13104 play_pos=14508 > played=14508 / 220500, fraction_played=1404 > ds3d.c:248:offset=13104 free=1404 written=35154 / 220500 > ds3d.c:230:buf size=22050 last_play_pos=14508 play_pos=860 > played=22910 / 220500, fraction_played=8402 > ds3d.c:248:offset=14508 free=8402 written=36558 / 220500 > > Please note that the play_pos wrapped from 14508 to 860 because it > exceeded 15052 bytes, but the test assumes it wrapped around at 22050 > bytes, so it miscalculates the fraction_played, advancing it at an > abnormally fast rate. That is how the following result ensues: > > trace:dsound:DSOUND_PrimaryGetPosition playpos = 176, writepos = 0 > (0x7fe03ab8, time=5366) > trace:dsound:PrimaryBufferImpl_GetCurrentPosition playpos = 176, > writepos = 0 (0x7fe03ab8, time=5366) > ds3d.c:230:buf size=22050 last_play_pos=13824 play_pos=176 > played=220676 / 220500, fraction_played=8402 > ds3d.c:237:all the samples have been played, stopping... > ds3d.c:279:stopping playback > trace:dsound:PrimaryBufferImpl_Stop (0x7fe143b8) > ds3d.c:628: Test failed: The sound played for 3453 ms instead of 5000 ms > > Many other tests with formats other than U8, 11025Hz fail for the same > reason. Any other DirectSound application that reuses the buffer size > as the test does will fail in the same way (music mixing up and > prematurely stopping). However, I am to understand that this test > passes on Windows, in all versions. > > Now that I have found the issue, I ask for help in suggesting a proper > fix. I think that the ALSA implementation used to have a separate > buffer from which samples were copied into the hardware buffer, but > this implementation was scrapped for some reason (and I think, without > re-running the ALSA tests). So I tried using > snd_hw_params_set_buffer_size() - it fails to set the buffer size to > the previously reported size. So I am still thinking about this. Any > comments or suggestions for fixing this will be greatly appreciated. > > BTW, does the DirectSound API allow the application to access the > hardware mmap directly (that is, not just by specifying the buffer to > be played)? If not, one possible solution would be to remember the > first reported buffer size, and wrap the *reported* position around at > that buffer size, even when the ALSA playback uses the real buffer > size. However, when I tried to do this (by hardcoding 22050 as a > wraparound value, just as a test), Wine promptly crashed, so I need > more insight into this. > > Alex Villacís Lasso > Resending because previous attempt probably was rejected due to gigantic attachment (my bad).

2 5

theming error on initial startup
by Stefan Leichter 29 Aug '05

29 Aug '05

Hello, starting wine (current cvs) without the .wine directory leads to the error below. Do i miss something? Bye Stefan wine: creating configuration directory '/home/sle/.wine'... err:theming:THEMING_Initialize Could not re-register class L"#32770": 582 err:theming:THEMING_Initialize Could not re-register class L"ComboBox": 582 err:theming:THEMING_Initialize Could not re-register class L"ComboLbox": 582 err:theming:THEMING_Initialize Could not re-register class L"Edit": 582 err:theming:THEMING_Initialize Could not re-register class L"ListBox": 582 wine: '/home/sle/.wine' created successfully. Wine 20050725 Usage: wine PROGRAM [ARGUMENTS...] Run the specified program wine --help Display this help and exit wine --version Output version information and exit

1 0

Re: DDraw: Better flag handling in SetCooperativeLevel
by Stefan Dösinger 29 Aug '05

29 Aug '05

Am Donnerstag, 25. August 2005 18:45 schrieb Stefan Dösinger: > Hello, > This patch adds better handling for the flags in > Main_DirectDraw_SetCooperativeLevel. The function reacts to > DDSCL_SETFOCUSWINDOW, DDSCL_CREATEDEVICEWINDOW and DDSCL_SETDEVICEWINDOW. > It doesn't really handle them, but it returns the correct return values. > The patch also contains a lenghty test which I used to verify the behaviour > with Windows 2000. Is anything wrong with this patch? Any reason why it wasn't applied? Stefan (link to archive: http://www.winehq.org/hypermail/wine-patches/2005/08/0648.html )

1 0

standard load address for a Win32 program (0x00400000) not available
by James Hawkins 29 Aug '05

29 Aug '05

Hi, I'm trying to run googletalk.exe with wine-pthread in order to debug the application. Running it fails with this error: $ /usr/bin/wine-pthread googletalk.exe err:virtual:map_image Image was mapped at 0xfb0000: standard load address for a Win32 program (0x00400000) not available err:virtual:map_image Do you have exec-shield or prelink active? wine: could not load L"Z:\\home\\truiken\\googletalk.exe" as Win32 binary exec-shield and prelink are definitely disabled, and running other native .exe's with wine-pthread work fine. Anyone have any ideas what the problem is, or how I can get this to work? -- James Hawkins

1 0

Theme regression
by Paul Vriens 29 Aug '05

29 Aug '05

Hi, with the latest CVS I'm seeing major graphical glitches when using a theme. After 'disabling' theming the glitches are gone, so it points to theming. No regression testing done yet. Anybody else seeing this problem ? Paul.

1 1

Web Server Downtime
by Jeremy Newman 29 Aug '05

29 Aug '05

The Web Server will be offline tomorrow from 9am CDT through 4pm CDT. (04:00 - 11:00 GMT) The website will be up temporarily on our other webserver during the move. Things like CVS and the Mailing lists will be offline during that time. Note: I plan on upgrading Mailman (the software that controls the mailing lists) to the latest version in Debian Sarge. (2.1.5). WineHQ currently runs 2.0.13. The subscription list should port over with no issues. The list archives I will convert from hypermail to Mailmans own internal pipermail format. This will change the URL of the archives as well. I will post the final details once the upgrade is complete. Features on Mailman 2.1 http://www.gnu.org/software/mailman/features.html

1 1

Re: [Wine]Softlinking to a dvd-drive with inconsistent mount points? => HAL-Support
by Detlef Riekenberg 29 Aug '05

29 Aug '05

Am Samstag, den 27.08.2005, 14:38 -0700 schrieb Hiji: > It might be the ugly way, but it is the official way. That's because many Applications are unable to handle it yet. > This is definately *not* a Wine issue because it > affects any application which relies on have a static > name for the drive - let's make sure we're clear on > that. ;) No! This is not only a Wine issue, it's an issue of all applications which relies on static names. The big mistake: The Volume-Label is optional. It's possible on windows (since w2k) to work without a Driveletter for your CDROM, ("%SYSTEMROOT%\mountpoint") but they made the same mistake: Using a mountpoint (junction) is optional. When they used the mountpoint-method as default and the driveletter-method as optional fallback for old applications, then all important software would work today without an extra driveletter for removeable media. It's time to be more flexible. freedesktop.org did a step in the direction, now the applications must follow! > I suspect this "mounting by volume label" > won't last past Suse 9.3 since .. and go backwards? No way! > I haven't read anyone > praise this "feature" anywhere. That's the same when /dev/cdrom or /cdrom comes up as a link to the real device. It doesn't matter, on which controller, port and id your drive is connected; it just works. The link comes up and step by step more applications using this. And think about logical-volumes. Go backwards, because the admin will define on his own, which physical drive is used and mounted to a specific location? Logical volumes are present for ages in Novell Netware and other systems, arrived Windows since w2k and are working in linux for some years now. -- By By ... ... Detlef

5 4

accessing WRT binaries on the web
by Saulius Krasuckas 29 Aug '05

29 Aug '05

Now it seems test are being build daily [1], but none of them shows up on the web [2] since 2005.08.16. Is this intentional state of the system or just some bug had went in it? [1] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php [2] http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/

5 6

Re: commctrl: push button theming
by Frank Richter 29 Aug '05

29 Aug '05

On 26.08.2005 16:58, Frank Richter wrote: > Frank Richter <frank.richter(a)gmail.com> > Add initial push button theming. > What are the issues with this one? -f.r.

1 0

Re: ntdll: Implement FSCTL_PIPE_LISTEN
by Alexandre Julliard 29 Aug '05

29 Aug '05

Ivan Leo Puoti <ivanleo(a)gmail.com> writes: > This patch adds FSCTL_PIPE_LISTEN support to NtFsControlFile > It also corrects the function prototype based on information from ntifs.h > While I was at it I wrote a little test and found windows puts the > returning ntstatus in IoStatusBlock, so I've added that too. > > ChangeLog: Add FSCTL_PIPE_LISTEN support to NtFsControlFile, minor fixes. OVERLAPPED is a kernel structure, I doubt that this is the correct behavior for that ioctl. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: secur32: Use a standard wine list for packages and providers
by Alexandre Julliard 29 Aug '05

29 Aug '05

James Hawkins <truiken(a)gmail.com> writes: > Changelog > * Use a standard wine list for packages and providers. It fails make test: main.c:226: Test failed: EnumerateSecurityPackages() should return 0, not -2146893056 main.c:230: Test failed: Number of sec packages should be > 0 ,but is 0 main.c:233: Test failed: pkg_info should not be NULL after EnumerateSecurityPackages -- Alexandre Julliard julliard(a)winehq.org

1 0

[BUG1001]: please update comments
by Vijay Kiran Kamuju 29 Aug '05

29 Aug '05

Hi, for BUG 1001, please update the comments with the following link, http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q113996 I am unable to update via bugzilla, my id is infyquest, its giving me error that the short_id_desc is missing. Thanks, Vijay

2 3

Re: IDA Pro Regression
by Robbert Xerox 29 Aug '05

29 Aug '05

Hi, same patch is causing a regression in quite a few installers; one of them is: http://www.winehq.org/hypermail/wine-bugs/2005/08/0206.html Hopefully it can be fixed soon :) ------------------------------------------------------ Hi, A week or so ago I reported some regressions running IDA pro on wine. I've done some regression testing and I have found the patches that were causing the problems. The first problem I noticed were the large edit boxes in the General Registers window in IDA's debugger. It was caused by this edit control theming patch: http://cvs.winehq.org/patch.py?id=19554. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

2 1

Compile time error wldap32.h
by Robert Lunnon 28 Aug '05

28 Aug '05

wldap32.h seems to be missing a definition for LDAPSortKey and won't compile. I can't seem to find a definition anywhere. Is this a linuxism, does it borrow this definition from somewhere else under linux ?

2 1

Theming Support
by Jonathan Ernst 28 Aug '05

28 Aug '05

Hello, Now that theming using .msstyle is working quite well, wouldnt'it be possible to use the current used theme in the currently used window manager. I think it would be of great value to have windows applications integrate semlessly with the linux desktop without having to look for a msstyle theme that looks like the same as the currently used theme. Searching a little bit, it seems that something like this is on the way: http://wiki.winehq.org/ThemingSupport "Write a GTK+ theming bridge so Win32 apps get GTK+ themes automatically." Are we (=you) far away from this step ? Keep up the good work, -- Jonathan Ernst <Jonathan(a)ErnstFamily.ch>

5 10

curses, curses is broken
by Robert Lunnon 28 Aug '05

28 Aug '05

Seems a problem here for solaris too. Lots of breakage recently... Bob

1 0

Re: old version freetype installed warning
by Dmitry Timoshkov 28 Aug '05

28 Aug '05

"Yuri Kozlov" <kozlov.y(a)gmail.com> wrote: > changelog: > gdi: old version freetype installed warning added > --- wine/dlls/gdi/freetype.c 2005-08-20 08:33:00.000000000 +0400 > +++ bwine/dlls/gdi/freetype.c 2005-08-27 16:05:47.000000000 +0400 > @@ -438,6 +438,7 @@ > /* There are too many bugs in FreeType < 2.1.9 for bitmap font support */ > if(!FT_IS_SCALABLE(ft_face) && FT_SimpleVersion < ((2 << 16) | (1 << 8) | (9 << 0))) { > pFT_Done_Face(ft_face); > + WARN("Please, update FreeType library (>=2.1.9) -- font %s will not be load\n", debugstr_a(file)); If it's supposed to be a user visible message then it should use MESSAGE instead of a WARN. -- Dmitry.

2 1

Re: [COMCTL32] Set default size in ToolBar.SetBitmapSize
by Dmitry Timoshkov 28 Aug '05

28 Aug '05

"Yuri Kozlov" <kozlov.y(a)gmail.com> wrote: > changelog: > [COMCTL32] set default size for toolbar bitmap if not specified > --- wine/dlls/comctl32/toolbar.c 2005-08-16 19:25:16.000000000 +0400 > +++ bwine/dlls/comctl32/toolbar.c 2005-08-27 13:12:46.000000000 +0400 > @@ -4719,7 +4719,7 @@ > FIXME("wParam is %d. Perhaps image list index?\n", wParam); > > if ((LOWORD(lParam) <= 0) || (HIWORD(lParam)<=0)) > - return FALSE; > + lParam = MAKELONG(16, 15); Better use MAKELPARAM here since it's a 64-bit entity in Win64. -- Dmitry.

2 1

Re: IDA Pro Regression
by James Liggett 28 Aug '05

28 Aug '05

Hi, A week or so ago I reported some regressions running IDA pro on wine. I've done some regression testing and I have found the patches that were causing the problems. The first problem I noticed were the large edit boxes in the General Registers window in IDA's debugger. It was caused by this edit control theming patch: http://cvs.winehq.org/patch.py?id=19554. I also noted a crash after setting the debugger's process options. I found that this problem was also caused by a theming patch, this time for comboboxes: http://cvs.winehq.org/patch.py?id=19604 Since I'm really not too familiar with these areas of wine, perhaps someone with a little more experience with these patches can take a look at them so that they can be fixed. Thanks, James

1 0

Re: [Wine]Softlinking to a dvd-drive with inconsistent mount points? => HAL-Support
by Detlef Riekenberg 27 Aug '05

27 Aug '05

Am Freitag, den 26.08.2005, 12:50 +0200 schrieb Holly Bostick: >>Problem solved: > >>http://portal.suse.com/sdb/en/2005/05/dkukawka_hal_mountpoints.html > > Thanks Hiji, that was useful for me too. Thats an ugly workaround that should be forbidden. See Below. > > It might be nice to be able to symlink "d::" to /dev/hdc > > and have wine figure out where that's mounted, > > instead of having to specify both the device and the mount point. IMHO thats the only possible Way and wine must go that Way ASAP! (and use the old method for systems, where the new way dis not work) > Of course ~/.wine/drive_c (or wherever it's placed since Wine now > allows you to place the wine directory on first run), is going to > automatically be C:\. This is the default Location used by "wineprefixcreate" > The user's $HOME directory, > > is automatically symlinked to D:\ "D:\" is not created by "wineprefixcreate". > /tmp, ..., is automatically symlinked to E:\, which Wine seems to "e:\" is not created by "wineprefixcreate". "c:\windows\temp" is used as the default Temporary Directory. > C:\Windows\temp, where it always is under Windows) This is the default Location in win9x, if "TEMP" is not set in "config.sys" or "autoexec.bat" when starting this DOS-Taskswitcher. %USERPROFILE%\Local Settings\Temp" is the default for W2k and above. (Replace the second Part with the Translation in your Language). (WinNT 4.0 is The actual Location is always found in "TEMP" > / , being the third of the necessary directories that everyone is known > to have, is automatically symlinked to Z:\ This is also created by "wineprefixcreate" > I honestly don't know what SuSE was thinking with that one-- what > earthly reason could the majority of users have to need their CD/DVD > mounted to the label of the media itself? Yeah, I want /media/Far Cry > one minute, and /media/Office 2003 the next. Like I even know the LABEL > of most of the media I mount (and that's just retail disks, nothing said > about backup disks or other self-burned media). So how am I supposed to > know where it is, if I don't know the label? That's the best thing they did, but many Years to late! I used this semantic since 1985 when the computers had one or two floppy-disks, the hd was optional with a size about 40MB and was very surprised, when i changed my system. When a different medium (Disk) was needed and not present, the first system asks: 'Please insert Volume "Application, Disk 2" in any Drive'. The system detected the Media-Change and closed the Requester automatic, no matter in which Drive you inserted the Disk (DF0:, DF1: DF2 or DF3: for Floppy-Disks). Even the Requester was created automatic, when the required medium was not found and the Application did not forbid this behaviour explicit. About 20 Years later in 1994, a different System told me to insert the "Installation CD #2" in drive "E:" and was unable to detect, that the required medium was already present in drive "F:". Thats the way: The software-vendors are inflexible and the users do not complain. The First system was my Amiga and the second was the Software "WISO Sparbuch 2004" on Windows 2000. So with the HAL-System, linux is on the right way. Please do not be fixed on the old style, be flexible. Software need to use "/media/LABEL_OF_THE_MEDIA" to be more flexible, but that do not work, if the user create that ugly workaround above. > I could maybe see it for USB sticks, or Flash cards, > but those are different rules than the ones for CD/DVD drives. Which rules? Why use different behaviour? They are all media! Even Linux can use the semantic with the Volume-Label. No matter, on which Harddisk or which Partition the Files are. Mount find the Label. > And I don't even like this /media thing anyway; half > the time I start typing ls -la /mnt/wherever and get nothing (of > course). Phooey. Thats the Problem. The change was very late and many user must learn the flexible way. IMHO, it's required for wine to handle the HAL-Message-System ASAP. -- By By ... ... Detlef

4 5

Norwegian Bokmål README file
by "Alexander N. Sørnes" 27 Aug '05

27 Aug '05

I have translated the README file in CVS into Norwegian Bokmål, and I hope this is the right place to send it to. Regards, Alexander N. Sørnes

1 0

Re: [d3d8] use wined3dformat when calling wined3d #2 resent
by Jesse Allen 27 Aug '05

27 Aug '05

On 8/26/05, Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote: > > This patch is a resend of an earlier patch '[d3d8] use wined3dformat when > calling wined3d' > > > This patch adds a stray close parenthesis to wine/dlls/d3d8/directx.c line 644. Thanks, Jesse

1 0

Googletalk and Wine
by Andrew Neil Ramage 27 Aug '05

27 Aug '05

Googletalk is a free chat program from Google with integrated VoIP. I installed the program and received a message saying Googletalk required Windows 2000, XP or 2003. The program started after installation and almost immewdiately crashed. Here is the output. andrew@apollo:~/Download/Windows> wine googletalk.exe wine: cannot find 'googletalk.exe' andrew@apollo:~/Download/Windows> wine googletalk-setup.exe fixme:win:SetWindowTextA setting text "Google Talk Setup" of other process window (nil) should not use SendMessage fixme:win:SetWindowTextA setting text "Google Talk Setup" of other process window (nil) should not use SendMessage fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub fixme:richedit:RichEditANSIWndProc EM_AUTOURLDETECT: stub fixme:richedit:RichEditANSIWndProc EM_EXLIMITTEXT: stub err:menubuilder:InvokeShellLinker failed to fork and exec wineshelllink err:menubuilder:InvokeShellLinker failed to fork and exec wineshelllink fixme:advapi:LookupAccountSidW ((null),sid=0x403cf860,0x406dfcf8,0x406dfcf4(64),0x406dfd78,0x406dfcf0(64),0x406dfcd4): semi-stub fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),0,3,(nil),0,(nil)) - stub! err:ole:CoGetClassObject class {304ce942-6e39-40d8-943a-b913c40c9cd4} not registered fixme:ole:CoCreateInstance no classfactory created for CLSID {304ce942-6e39-40d8-943a-b913c40c9cd4}, hres is 0x80040154 andrew@apollo:~/Download/Windows> fixme:advapi:LookupAccountSidW ((null),sid=0x403cf868,0x406dfcf8,0x406dfcf4(64),0x406dfd78,0x406dfcf0(64),0x406dfcd4): semi-stub fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),0,3,(nil),0,(nil)) - stub! fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub fixme:richedit:RichEditANSIWndProc EM_SHOWSCROLLBAR: stub fixme:richedit:RichEditANSIWndProc EM_SHOWSCROLLBAR: stub fixme:richedit:RichEditANSIWndProc EM_SETTEXTMODE: stub fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub fixme:richedit:RichEditANSIWndProc EM_SHOWSCROLLBAR: stub fixme:richedit:RichEditANSIWndProc EM_SHOWSCROLLBAR: stub fixme:richedit:RichEditANSIWndProc EM_HIDESELECTION: stub err:x11drv:X11DRV_CreateWindow invalid window height -2 fixme:keyboard:RegisterHotKey (0x3002e,0,0x00000008,27): stub fixme:richedit:RichEditANSIWndProc EM_HIDESELECTION: stub fixme:richedit:RichEditANSIWndProc EM_HIDESELECTION: stub fixme:sensapi:IsNetworkAlive 0x406de880 fixme:richedit:RichEditANSIWndProc EM_HIDESELECTION: stub wine: Unhandled exception (thread 0018), starting debugger... WineDbg starting on pid 0x15 Unhandled exception: page fault on write access to 0x0074006f in 32-bit code (0x401b140e). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:401b140e ESP:42cb686c EBP:42cb6894 EFLAGS:00210206( - 00 - RIP1) EAX:00740065 EBX:401ebbd4 ECX:006e006c EDX:00740063 ESI:403d0ed8 EDI:403d0f00 Stack dump: 0x42cb686c: 403d0380 00000020 401f2a20 401f2ace 0x42cb687c: 00000000 00000028 40360000 401ebbd4 0x42cb688c: 403d0ed8 00000028 42cb68d4 401b1be7 0x42cb689c: 401b13a0 401b13a0 42cb68c8 00004000 0x42cb68ac: 401f2ace 401f2ace 401b08de 00043bd8 0x42cb68bc: 00000001 40360000 40360000 401ebbd4 Backtrace: =>1 0x401b140e in ntdll (+0x2140e) (0x42cb6894) 2 0x401b1be7 in ntdll (+0x21be7) (0x42cb68d4) 3 0x401b1e2a RtlFreeHeap in ntdll (0x42cb6908) 4 0x40703dde in wininet (+0x13dde) (0x42cb692c) 5 0x40709693 WININET_Release in wininet (0x42cb6958) 6 0x4070edb9 InternetCloseHandle in wininet (0x42cb697c) fixme:dbghelp:sffip_cb NIY on 'googletalk.pdb' 7 0x004142c9 in googletalk (+0x142c9) (0x4221b164) 8 0x00000000 (0x005778c8) 9 0x00413230 in googletalk (+0x13230) (0x004131c0) 0x401b140e: movl %eax,0xc(%edx) Modules: Module Address Debug info Name (84 modules) PE 0x00400000-00720000 Export googletalk ELF 0x40000000-40018000 Deferred ld-linux.so.2 ELF 0x40031000-4004a000 Deferred libwine.so.1 ELF 0x4004a000-4005c000 Deferred libpthread.so.0 ELF 0x4005c000-40175000 Deferred libc.so.6 ELF 0x40175000-40179000 Deferred libdl.so.2 ELF 0x4017a000-401f5000 Export ntdll<elf> \-PE 0x40190000-401f5000 \ ntdll ELF 0x4020d000-40302000 Deferred libwine_unicode.so.1 ELF 0x40302000-40325000 Deferred libm.so.6 ELF 0x40470000-40581000 Deferred kernel32<elf> \-PE 0x404a0000-40581000 \ kernel32 ELF 0x406e0000-40726000 Export wininet<elf> \-PE 0x406f0000-40726000 \ wininet ELF 0x40726000-40746000 Deferred mpr<elf> \-PE 0x40730000-40746000 \ mpr ELF 0x40746000-40878000 Deferred user32<elf> \-PE 0x40770000-40878000 \ user32 ELF 0x40878000-4126c000 Deferred gdi32<elf> \-PE 0x40890000-4126c000 \ gdi32 ELF 0x41342000-4134a000 Deferred libgcc_s.so.1 ELF 0x4134a000-4138c000 Deferred advapi32<elf> \-PE 0x41360000-4138c000 \ advapi32 ELF 0x4138c000-413eb000 Deferred shlwapi<elf> \-PE 0x413a0000-413eb000 \ shlwapi ELF 0x413eb000-41479000 Deferred ole32<elf> \-PE 0x41400000-41479000 \ ole32 ELF 0x41479000-414c4000 Deferred rpcrt4<elf> \-PE 0x41490000-414c4000 \ rpcrt4 ELF 0x414c4000-414e4000 Deferred iphlpapi<elf> \-PE 0x414d0000-414e4000 \ iphlpapi ELF 0x414e4000-415ad000 Deferred shell32<elf> \-PE 0x41500000-415ad000 \ shell32 ELF 0x415ad000-4166b000 Deferred comctl32<elf> \-PE 0x415c0000-4166b000 \ comctl32 ELF 0x4166b000-41696000 Deferred ws2_32<elf> \-PE 0x41670000-41696000 \ ws2_32 ELF 0x41696000-41717000 Deferred winmm<elf> \-PE 0x416a0000-41717000 \ winmm ELF 0x41717000-4173e000 Deferred crypt32<elf> \-PE 0x41720000-4173e000 \ crypt32 ELF 0x4173e000-41752000 Deferred sensapi<elf> \-PE 0x41740000-41752000 \ sensapi ELF 0x41752000-4176d000 Deferred version<elf> \-PE 0x41760000-4176d000 \ version ELF 0x4176d000-41783000 Deferred lz32<elf> \-PE 0x41770000-41783000 \ lz32 ELF 0x41783000-4181c000 Deferred oleaut32<elf> \-PE 0x417a0000-4181c000 \ oleaut32 ELF 0x4181c000-41830000 Deferred msimg32<elf> \-PE 0x41820000-41830000 \ msimg32 ELF 0x41830000-4188d000 Deferred setupapi<elf> \-PE 0x41840000-4188d000 \ setupapi ELF 0x4188d000-418b1000 Deferred msacm32<elf> \-PE 0x418a0000-418b1000 \ msacm32 ELF 0x418b1000-418ce000 Deferred secur32<elf> \-PE 0x418c0000-418ce000 \ secur32 ELF 0x418e6000-41955000 Deferred libfreetype.so.6 ELF 0x4196d000-4199b000 Deferred libfontconfig.so.1 ELF 0x4199b000-419ba000 Deferred libexpat.so.0 ELF 0x419ba000-41a40000 Deferred winex11.drv<elf> \-PE 0x419d0000-41a40000 \ winex11.drv ELF 0x41a40000-41a42000 Deferred xlcutf8load.so.2 ELF 0x41a58000-41a60000 Deferred libsm.so.6 ELF 0x41a60000-41a78000 Deferred libice.so.6 ELF 0x41a78000-41a7e000 Deferred libxxf86dga.so.1 ELF 0x41a7e000-41a83000 Deferred libxxf86vm.so.1 ELF 0x41a83000-41a91000 Deferred libxext.so.6 ELF 0x41a91000-41b8d000 Deferred libx11.so.6 ELF 0x41b8d000-41bfa000 Deferred libgl.so.1 ELF 0x41bfa000-41c19000 Deferred ximcp.so.2 ELF 0x41c19000-41c37000 Deferred imm32<elf> \-PE 0x41c20000-41c37000 \ imm32 ELF 0x41c4f000-41c58000 Deferred libxcursor.so.1 ELF 0x41c58000-41c60000 Deferred libxrender.so.1 ELF 0x41ec0000-41f03000 Deferred wineoss.drv<elf> \-PE 0x41ed0000-41f03000 \ wineoss.drv ELF 0x41f03000-41f1c000 Deferred msacm.drv<elf> \-PE 0x41f10000-41f1c000 \ msacm.drv ELF 0x42130000-42145000 Deferred midimap.drv<elf> \-PE 0x42140000-42145000 \ midimap.drv ELF 0x42902000-42943000 Deferred riched20<elf> \-PE 0x42910000-42943000 \ riched20 ELF 0x7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 00000015 (D) C:\Program Files\Google\Google Talk\googletalk.exe 00000018 0 <== 00000017 0 00000016 0 WineDbg terminated on pid 0x15 Anyone know what went wrong ? -- Andrew You can be the captain I will draw the chart Sailing into destiny Closer to the heart Closer to the Heart by Rush (A Farewell to Kings, 1977) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 2

CVS Problem
by Andrew Neil Ramage 27 Aug '05

27 Aug '05

After downloading the new CVS, I hit the following problem after running './configure': config.status: error: cannot find input file: dlls/mciavi32/Makefile.in andrew@apollo:~/Download/Software/wine> make make[1]: Entering directory `/home/andrew/Download/Software/wine/libs' Makefile is older than ../configure, please rerun ../configure make[1]: *** [Makefile] Error 1 make[1]: Leaving directory `/home/andrew/Download/Software/wine/libs' make: *** [libs] Error 2 andrew@apollo:~/Download/Software/wine> Anyone know what is wrong ? -- Andrew You can be the captain I will draw the chart Sailing into destiny Closer to the heart Closer to the Heart by Rush (A Farewell to Kings, 1977) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

4 4

FAQ patch
by Tom Wickline 27 Aug '05

27 Aug '05

I sent a small FAQ patch a couple days ago, please don't apply that patch I have a newer patch with allot more changes in it. I need to give it another look over before sending it for review. Cheers, Tom

1 0

Re: Frequent and annoying Wine bug:Assertion failed !bogus context in Local_Unwind()
by Robbert Xerox 27 Aug '05

27 Aug '05

--- Robbert Xerox <xerox_xerox2000(a)yahoo.co.uk> wrote: Hi, i think i finally found a solution for this bug: i'm running fc3 (the "normal" x32 version) on an athlon64. When i compile wine with option CFLAGS="-m32" the error is gone. My question is: is this an error in Fedora , in wine or maybe gcc? > --- Robbert Xerox <xerox_xerox2000(a)yahoo.co.uk> > wrote: > > > Hi , i know this is not a wine-bug channel, but > this > > bug is affecting quite some apps, and seems to > > affect > > more and more ... > > At least five apps from wine-bug mailinglist throw > > up > > an exception which either reads: "Assertion Failed > > !bogus context in Local_Unwind()" or "in > > Exception_Handler". As a reference a filed 2 bugs, > > and > > commented another one where you can read the > > +relay,+seh logs: > > Bug 3097 > > Bug 3127 > > Bug 3139 > > > > Some googling around makes me believe that this is > a > > Borland specific error. I tried to install Demo > > Borland compiler in wine to see if i could > reproduce > > this error, but unfortunately it fails with > exactly > > the same error. > > > > all programs show the same pattern before an > > exception > > is thrown: they call LoadstringA() ,with something > > like > > L"Failed to get data for '%s'" or L"Access > > violation at address %p in module '%s'. %s of > > address > > %p" See the bugs for more info. > > > > I think this bug is really affecting quite some > more > > apps then the ones mentioned in wine-bugs so would > > be > > great if anyone could shine a light on this, as of > > how > > to solve the bug. Regards > > > > > > > > > > > ___________________________________________________________ > > > > How much free photo storage do you get? Store your > > holiday > > snaps for FREE with Yahoo! Photos > > http://uk.photos.yahoo.com > > > > > > > ___________________________________________________________ > > How much free photo storage do you get? Store your > holiday > snaps for FREE with Yahoo! Photos > http://uk.photos.yahoo.com > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

1 0

Re: secur32: Use a standard wine list for packages and providers
by James Hawkins 27 Aug '05

27 Aug '05

On 8/27/05, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > Changelog > * Use a standard wine list for packages and providers. > Ignore this for now. I have to fix some things first. -- James Hawkins

1 0

MSHTML: German resource [2nd try]
by Henning Gerhardt 27 Aug '05

27 Aug '05

with some spelling improvements by Frank Richter Changelog: Add German resources diff -Nur wine/dlls/mshtml/De.rc wine-working/dlls/mshtml/De.rc --- wine/dlls/mshtml/De.rc 1970-01-01 01:00:00.000000000 +0100 +++ wine-working/dlls/mshtml/De.rc 2005-08-27 08:56:47.000000000 +0200 @@ -0,0 +1,240 @@ +/* + * German resources for mshtml + * + * Copyright 2005 Henning Gerhardt + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + + +LANGUAGE LANG_GERMAN, SUBLANG_DEFAULT + +/* FIXME: This should be in shdoclc.dll */ + +IDR_BROWSE_CONTEXT_MENU MENU +{ + POPUP "Standard" + { + MENUITEM "&Zurück", IDM_BACK + MENUITEM "V&orwärts", IDM_FORWARD + MENUITEM SEPARATOR + MENUITEM "&Speichere Hintergrund als...", IDM_SAVEBACKGROUNDAS + MENUITEM "Als Hintergrund", IDM_SETASBACKGROUND + MENUITEM "Hintergrund &kopieren", IDM_COPYBACKGROUND + MENUITEM "Als Desktopelement einrichten...", IDM_SETASDESKTOPITEM + MENUITEM SEPARATOR + MENUITEM "Alles &auswählen", IDM_SELECTALL + MENUITEM "Ein&fügen", IDM_PASTE + MENUITEM SEPARATOR + MENUITEM "Erzeuge &Verknüpfung", IDM_CREATESHORTCUT + MENUITEM "Zu &Favoriten hinzufügen", IDM_ADDTOFAVOURITES + MENUITEM "&Quelltextansicht", IDM_VIEWSOURCE + MENUITEM SEPARATOR + MENUITEM "&Textkodierung", IDM_ENCODING + MENUITEM SEPARATOR + MENUITEM "&Drucken", IDM_PRINT + MENUITEM "A&ktualisieren", IDM_REFRESH + MENUITEM SEPARATOR + MENUITEM SEPARATOR + MENUITEM "&Eigenschaften", IDM_PROPERTIES + } + + POPUP "Bild" + { + MENUITEM "&Öffne Verweis", IDM_OPENLINK + MENUITEM "Öffne Verweis in neuem Fenster", IDM_OPENINNEWWINDOW + MENUITEM "Speichere &Ziel als...", IDM_SAVETARGETAS + MENUITEM "&Drucke Ziel", IDM_PRINTTARGET + MENUITEM SEPARATOR + MENUITEM "Zeige B&ild", IDM_SHOWPICTURE + MENUITEM "Speichere &Bild als...", IDM_SAVEPICTUREAS + MENUITEM "&Versende Bild...", IDM_EMAILPICTURE + MENUITEM "D&rucke Bild...", IDM_PRINTPICTURE + MENUITEM "&Gehe zu Eigene Bilder", IDM_GOTOMYPICTURES + MENUITEM "Als Hintergrund", IDM_SETASBACKGROUND + MENUITEM "Als Desktopelement einrichten...", IDM_SETASDESKTOPITEM + MENUITEM SEPARATOR + MENUITEM "Aus&schneiden", IDM_CUT + MENUITEM "&Kopieren", IDM_COPY + MENUITEM "Verk&nüpfung kopieren", IDM_COPYSHORTCUT + MENUITEM "Ein&fügen", IDM_PASTE + MENUITEM SEPARATOR + MENUITEM "Zu &Favoriten hinzufügen...", IDM_ADDTOFAVOURITES + MENUITEM SEPARATOR + MENUITEM SEPARATOR + MENUITEM "&Eigenschaften", IDM_PROPERTIES + } + + POPUP "Steuerung" + { + MENUITEM "&Rückgängig", IDM_UNDO + MENUITEM SEPARATOR + MENUITEM "Aus&schneiden", IDM_CUT + MENUITEM "&Kopieren", IDM_COPY + MENUITEM "Ein&fügen", IDM_PASTE + MENUITEM "&Löschen", IDM_DELETE + MENUITEM SEPARATOR + MENUITEM SEPARATOR + MENUITEM "Alles &auswählen", IDM_SELECTALL + } + + POPUP "Tabelle" + { + POPUP "&Auswählen" + { + MENUITEM "&Zelle", IDM_CELL + MENUITEM "Zei&le", IDM_ROW + MENUITEM "&Spalte", IDM_COLUMN + MENUITEM "&Tabelle", IDM_TABLE + } + MENUITEM SEPARATOR + MENUITEM SEPARATOR + MENUITEM "&Zellen Eigenschaften", IDM_CELLPROPERTIES + MENUITEM "&Tabellen Eigenschaften", IDM_TABLEPROPERTIES + } + + POPUP "1DSeiten Auswahl" + { + MENUITEM "Aus&schneiden", IDM_CUT + MENUITEM "&Kopieren", IDM_COPY + MENUITEM "Ein&fügen", IDM_PASTE + MENUITEM "Alles &auswählen", IDM_SELECTALL + MENUITEM "&Drucken", IDM_PRINT + MENUITEM SEPARATOR + } + + POPUP "Anker" + { + MENUITEM "&Öffnen", IDM_OPENLINK + MENUITEM "Im &neuen Fenster öffnen", IDM_OPENINNEWWINDOW + MENUITEM "Speichere &Ziel als...", IDM_SAVETARGETAS + MENUITEM "&Drucke Ziel", IDM_PRINTTARGET + MENUITEM SEPARATOR + MENUITEM "Aus&schneiden", IDM_CUT + MENUITEM "&Kopieren", IDM_COPY + MENUITEM "&Verknüpfung kopieren", IDM_COPYSHORTCUT + MENUITEM "Ein&fügen", IDM_PASTE + MENUITEM SEPARATOR + MENUITEM "Zu &Favoriten hinzufügen...", IDM_ADDTOFAVOURITES + MENUITEM SEPARATOR + MENUITEM SEPARATOR + MENUITEM "&Eigenschaften", IDM_PROPERTIES + } + + POPUP "Context Unknown" + { + MENUITEM SEPARATOR + } + + POPUP "DYNSRC Bild" + { + MENUITEM "&Öffne Verweis", IDM_OPENLINK + MENUITEM "Öffne Verweis in &neuem Fenster", IDM_OPENINNEWWINDOW + MENUITEM "Speichere &Ziel als...", IDM_SAVETARGETAS + MENUITEM "&Drucke Ziel", IDM_PRINTTARGET + MENUITEM SEPARATOR + MENUITEM "Zeige B&ild", IDM_SHOWPICTURE + MENUITEM "Speichere &Video als...", IDM_SAVEPICTUREAS + MENUITEM "Als Hintergrund", IDM_SETASBACKGROUND + MENUITEM "Als Desktopelement einrichten...", IDM_SETASDESKTOPITEM + MENUITEM SEPARATOR + MENUITEM "Aus&schneiden", IDM_CUT + MENUITEM "&Kopieren", IDM_COPY + MENUITEM "&Verknüpfung kopieren", IDM_COPYSHORTCUT + MENUITEM "Ein&fügen", IDM_PASTE + MENUITEM SEPARATOR + MENUITEM "Zu &Favoriten hinzufügen...", IDM_ADDTOFAVOURITES + MENUITEM SEPARATOR + MENUITEM SEPARATOR + MENUITEM "Abspielen", IDM_PLAY + MENUITEM "Halt", IDM_STOP + MENUITEM "&Eigenschaften", IDM_PROPERTIES + } + + POPUP "ART Bild" + { + MENUITEM "&Öffne Verweis", IDM_OPENLINK + MENUITEM "Öffne Verweis in &neuem Fenster", IDM_OPENINNEWWINDOW + MENUITEM "Speichere &Ziel als...", IDM_SAVETARGETAS + MENUITEM "&Drucke Ziel", IDM_PRINTTARGET + MENUITEM SEPARATOR + MENUITEM "Zeige B&ild", IDM_SHOWPICTURE + MENUITEM "&Speichere Bild als...", IDM_SAVEPICTUREAS + MENUITEM "Als Hintergrund", IDM_SETASBACKGROUND + MENUITEM "Als Desktopelement einrichten...", IDM_SETASDESKTOPITEM + MENUITEM SEPARATOR + MENUITEM "Aus&schneiden", IDM_CUT + MENUITEM "&Kopieren", IDM_COPY + MENUITEM "&Verknüpfung kopieren", IDM_COPYSHORTCUT + MENUITEM "&Einfügen", IDM_PASTE + MENUITEM SEPARATOR + MENUITEM "Zu &Favoriten hinzufügen...", IDM_ADDTOFAVOURITES + MENUITEM SEPARATOR + MENUITEM "Abspielen", IDM_PLAY + MENUITEM "Anhalten", IDM_STOP + MENUITEM "Rückspulen", IDM_REWIND + MENUITEM SEPARATOR + MENUITEM SEPARATOR + MENUITEM "&Eigenschaften", IDM_PROPERTIES + } + + POPUP "Debug" + { + MENUITEM "Trace Tags", IDM_TRACETAGS + MENUITEM "Resource Failures", IDM_RESOURCEFAILURES + MENUITEM "Dump Tracking Info", IDM_DUMPTRACKINGINFO + MENUITEM "Debug Break", IDM_DEBUGBREAK + MENUITEM "Debug View", IDM_DEBUGVIEW + MENUITEM "Dump Tree", IDM_DUMPTREE + MENUITEM "Dump Lines", IDM_DUMPLINES + MENUITEM "Dump Displaytree", IDM_DUMPDISPLAYTREE + MENUITEM "Dump FormatCaches", IDM_DUMPFORMATCACHES + MENUITEM "Dump LayoutRects", IDM_DUMPLAYOUTRECTS + MENUITEM "Memory Monitor", IDM_MEMORYMONITOR + MENUITEM "Performance Meters", IDM_PERFORMANCEMETERS + MENUITEM "Save HTML", IDM_SAVEHTML + MENUITEM SEPARATOR + MENUITEM "&Browse View", IDM_BROWSEVIEW + MENUITEM "&Edit View", IDM_EDITVIEW + } + + POPUP "Vertikale Scrollbar" + { + MENUITEM "Scrolle hier", IDM_SCROLLHERE + MENUITEM SEPARATOR + MENUITEM "Oben", IDM_TOP + MENUITEM "Unten", IDM_BOTTOM + MENUITEM SEPARATOR + MENUITEM "Seite hoch", IDM_PAGEUP + MENUITEM "Seite runter", IDM_PAGEDOWN + MENUITEM SEPARATOR + MENUITEM "Scrolle hoch", IDM_SCROLLUP + MENUITEM "Scrolle runter", IDM_SCROLLDOWN + } + + POPUP "Horizontale Scrollbar" + { + MENUITEM "Scrolle hier", IDM_SCROLLHERE + MENUITEM SEPARATOR + MENUITEM "Linke Ecke", IDM_LEFTEDGE + MENUITEM "Rechte Ecke", IDM_RIGHTEDGE + MENUITEM SEPARATOR + MENUITEM "Seite links", IDM_PAGELEFT + MENUITEM "Seite rechts", IDM_PAGERIGHT + MENUITEM SEPARATOR + MENUITEM "Scrolle links", IDM_SCROLLLEFT + MENUITEM "Scrolle rechts", IDM_SCROLLRIGHT + } +} diff -Nur wine/dlls/mshtml/rsrc.rc wine-working/dlls/mshtml/rsrc.rc --- wine/dlls/mshtml/rsrc.rc 2005-08-27 01:19:07.000000000 +0200 +++ wine-working/dlls/mshtml/rsrc.rc 2005-08-27 01:28:36.000000000 +0200 @@ -21,6 +21,7 @@ #include "resource.h" +#include "De.rc" #include "En.rc" REGINST REGINST mshtml.inf

1 0

Re: FW: [bug 3064] Listbox fails to populate
by Alexandre Julliard 26 Aug '05

26 Aug '05

"Ann & Jason Edmeades" <us(a)edmeades.me.uk> writes: > Was there any problem with this one or did it just get missed? LISTBOX_RemoveItem already does pretty much the same check, you should reuse that instead of duplicating it, you just need to remove the -1 special case in there. -- Alexandre Julliard julliard(a)winehq.org

2 1

Missing "#define AVISTREAMREAD_CONVENIENT"
by Peter Lemenkov 26 Aug '05

26 Aug '05

Hello, All! Subj. VirtualDub library, called vdremote, wants it, so I propose to include next line anywhere in file "vfv.h": #define AVISTREAMREAD_CONVENIENT (-1L) -- With best regards, Peter Lemenkov.

1 0

Re: [d3d8] use wined3dformat when calling wined3d
by Juan Lang 26 Aug '05

26 Aug '05

Hi again Oliver, > Common subdirectories: clean/wine/CVS and small-patches/wine/CVS Wrong patch I think. --Juan ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs

1 0

Re: [wined3d] dxt2 and dxt4 texture support
by Juan Lang 26 Aug '05

26 Aug '05

Hi Oliver, diff -Nru -x ignore clean/wine/dlls/Makeimplib.rules small-patches/wine/dlls/Makeimplib.rules --- clean/wine/dlls/Makeimplib.rules 1970-01-01 01:00:00.000000000 +0100 +++ small-patches/wine/dlls/Makeimplib.rules 2005-08-26 15:53:11.888455392 +0100 @ This shows up in a couple of your patches and is noise. @@ -334,7 +335,9 @@ TRACE("(%p) glGetTexImage level(%d), fmt(%d), typ(%d), mem(%p) \n" , This, This->glDescription.level, This->glDescription.glFormat, This->glDescription.glType, This->resource.allocatedMemory); /* TODO: DXT2 and DXT4 formats */ if (This->resource.format == WINED3DFMT_DXT1 || + This->resource.format == WINED3DFMT_DXT2 || This->resource.format == WINED3DFMT_DXT3 || + This->resource.format == WINED3DFMT_DXT4 || This->resource.format == WINED3DFMT_DXT5) { TRACE("Locking a compressed texture\n"); if (GL_SUPPORT(EXT_TEXTURE_COMPRESSION_S3TC)) { /* we can assume this as the texture would not have been created otherwise */ Shouldn't that TODO be removed? --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

The recent include/wine/wined3d_types.h changes
by Gerald Pfeifer 26 Aug '05

26 Aug '05

The following patch to include/wine/wined3d_types.h revision 1.8 date: 2005/08/23 09:34:57; author: julliard; state: Exp; lines: +2 -2 Oliver Stieber <oliver_stieber(a)yahoo.co.uk> Tidy up d3d9 and finalize passing d3d9 calls to wined3d for now. @@ -401,7 +401,7 @@ typedef struct _WINED3DADAPTER_IDENTIFIE typedef struct _WINED3DPRESENT_PARAMETERS { UINT *BackBufferWidth; UINT *BackBufferHeight; - D3DFORMAT *BackBufferFormat; + WINED3DFORMAT *BackBufferFormat; UINT *BackBufferCount; D3DMULTISAMPLE_TYPE *MultiSampleType; DWORD *MultiSampleQuality; @@ -409,7 +409,7 @@ typedef struct _WINED3DPRESENT_PARAMETER HWND *hDeviceWindow; BOOL *Windowed; BOOL *EnableAutoDepthStencil; - D3DFORMAT *AutoDepthStencilFormat; + WINED3DFORMAT *AutoDepthStencilFormat; DWORD *Flags; UINT *FullScreen_RefreshRateInHz; UINT *PresentationInterval; triggers the following warning in IDirect3D8Impl_CreateDevice(): directx.c:670: warning: assignment from incompatible pointer type directx.c:678: warning: assignment from incompatible pointer type These two lines are localParameters.BackBufferFormat = &pPresentationParameters->BackBufferFormat; localParameters.AutoDepthStencilFormat = &pPresentationParameters->AutoDepthStencilFormat; and the two variables have the following types D3DPRESENT_PARAMETERS* pPresentationParameters (from include/wine/wined3d_types.h WINED3DPRESENT_PARAMETERS localParameters; (from include/d3d8types.h) Interestingly, I did not see this on SUSE Linux 9.3, but FreeBSD 4.11 (XFree86) and 5.4 (X.org). Both D3DFORMAT and WINED3DFORMAT are enums, so indeed assigning one to the other seems a bit strange, if not dangerous. Is the change as such really correct? Gerald

2 1

OpenGL windowing and wglMakeCurrent
by Russ 26 Aug '05

26 Aug '05

Trying to get my 3-D app to run under WINE using the same binary with the odd workaround or two. It uses OpenGL in various subwindows of the main window as needed. Under WINE, the subwindow graphics all get drawn in the lower left corner of the overall X11 window, and the entire X11 window's redraw is mangled---OpenGL is affecting the entire X11 Window. In Win32, when you call wglMakeCurrent, the opengl context is configured to match the size/position of the HWND for the HDC, even if it is only a small child window, so drawing openGL goes just into the desired subwindow. However, the WINE implementation of wglMakeCurrent just calls glXMakeCurrent (and glXCreateContext), which produces the entire size of the X11 window, resulting in the incorrect behavior observed. In my Mac OS X port, I have a similar issue, resolved by calling aglSetInteger(glContext, AGL_BUFFER_RECT,... I'm not sure what a glX equivalent would be to try. It is possible that glScissor might be used. A more accurate wglMakeCurrent emulation is necessary for a usable port. Suggestions welcome. Thanks, Russ __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

4 3

Re: Loading resources from wine dlls
by Michael Jung 26 Aug '05

26 Aug '05

Hi Rob, On Thursday 25 August 2005 06:50, you wrote: > Anything that uses SearchPath is similarly broken when needing to find a > builtin dll or exe. We should add a hack^H^H^H^Hextension to that > function to make it be able to find installed .so files with a similar > name. I think that's just part of the problem. If I create a symbolic link from .wine/drive_c/windows/system32/shell32.dll to /usr/local/lib/wine/shell32.dll.so SearchPath succeeds. But then USER32_GetResourceTable (dlls/user/exticon.c, line 128) fails (I guess it can't handle ELF wrapped PEs?). Would it be ok to look for an ELF header and then for an enclosed PE header in USER32_GetResourceTable (and then return IMAGE_NT_SIGNATURE and the correct pointer)? Where can I find informations about the format of ELF wrapped PEs? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

2 2

Re: wine/dlls/commdlg printdlg.c
by Vitaly Lipatov 26 Aug '05

26 Aug '05

В сообщении от 25 Август 2005 23:23 Alexandre Julliard написал(a): > Log message: > Vitaly Lipatov <lav(a)etersoft.ru> > Restore paper orientation when pagesetupdlg is initializing. > > Patch: http://cvs.winehq.org/patch.py?id=19818 Dear Alexandre! You are removed dm checking for NULL... But it can be NULL in some cases... <<<<<<< printdlg.c /* Set orientation radiobutton properly */ dm = GlobalLock(pda->dlga->hDevMode); if (dm && dm->u1.s1.dmOrientation == DMORIENT_LANDSCAPE) ======= /* Set orientation radiobutton properly */ dm = GlobalLock(pda->dlga->hDevMode); if (dm->u1.s1.dmOrientation == DMORIENT_LANDSCAPE) >>>>>>> 1.93 -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

2 1

DLL loading
by Bojan �ffff8aernek 26 Aug '05

26 Aug '05

hello, I'd like to load a DLL from a memory buffer. The regular Win32 API function to load DLLs, however, takes a path name. So, I'm looking for resources about this kind of thing, but it has to work both under win32 and unix+wine. There used to be a web page about just this thing, but I lost the link. Any ideas? Thanks. ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs

2 1

undocumented shell32 stuff
by Saulius Krasuckas 26 Aug '05

26 Aug '05

I have stumbled upon a unimplemented function shell32.dll.SHLocalAlloc . OpenRCE page says it is related to kernel32.dll.LocalAlloc [1], and authors of the NSElib (The NameSpace Extension Library) defines it taking two int-params [2]. They define the function in ShlExt.h file which says: // This file can be considered to be in the public domain. // The latest version can normally be found here: // http://www.whirlingdervishes.com/nselib/public // The file is based on various sources, and includes definitions // that were taken over from various places, including // Microsoft documentation and header files. It also contains // many definitions that were introduced by Whirling Dervishes // Software. OTOH, there is one page on the web [3], which declares itself as a homepage of the ShlExt.h and which describes history of the file. It seems as prototype which was extended by Whirling Dervishes Software and based on which their NSElib was built. Earlier ShlExt.h was beeing included in the PSDK, but now it isn't AFAICS. And this is another quote from [2]: // februari 2003: Henk Devos: Made compatible with the // october 2003 Platform SDK // januari 2003: Henk Devos: added some more undefined flags, // including the ones for CDefFolderMenu_Create2. // september 2002: Henk Devos: Made compatible with new Platform SDK // januari 2002: Henk Devos: Added comments with ordinals of // all exports in Windows 2000 version of shell32.dll // 24/06/99 Some changes made by Henk Devos It stays above the changelog of the old file [4]. What developers think about this story? Can we start importing it into our tree? If not, should I declare SHLocalAlloc() somewhere? And where should I put it's code, maybe dlls/shell32/utility.c ? [1] http://www.openrce.org/reference_library/win32_call_chains/2000SP4/SHLWAPI/… [2] http://www.whirlingdervishes.com/nselib/mfc/samples/source.php [3] http://www.mvps.org/user32/shlext.html#shlext [4] http://www.mvps.org/user32/shlext.zip

2 2

Help with debugging needed
by Stefan Dösinger 26 Aug '05

26 Aug '05

Hello, I am trying(once again) to get Empire Earth [1] running with wine. After solving a few problems[2], I've run into a strange access violation crash. It looks like a buffer overrun, followed by a return to an invalid adress. A +relay,+snoop trace gives this: ... 0009:CALL Low-Level Engine.?Deactivate@GERasterizer@@UAEJXZ() ret=7e2b9a14 0009:CALL Low-Level Engine.?Dereference@UReferenceCounter@@QAEXXZ() ret=7e2bd6c5 0009:RET Low-Level Engine.?Dereference@UReferenceCounter@@QAEXXZ() retval=7f24fa70 ret=7e2bd6c5 0009:Call ntdll.RtlEnterCriticalSection(7f074a40) ret=7f0294c5 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=7f0294c5 0009:Call ntdll.RtlLeaveCriticalSection(7f074a40) ret=7f029506 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=7f029506 0009:CALL MSVCRT._except_handler3(<unknown, check return>) ret=7beb649b 0009:CALL MSVCRT._XcptFilter(<unknown, check return>) ret=00665947 0009:Call kernel32.GetLastError() ret=7800385f 0009:Ret kernel32.GetLastError() retval=000005b4 ret=7800385f 0009:Call kernel32.TlsGetValue(00000000) ret=7800386d 0009:Ret kernel32.TlsGetValue() retval=7f180f80 ret=7800386d 0009:Call kernel32.SetLastError(000005b4) ret=7800387e 0009:Ret kernel32.SetLastError() retval=000005b4 ret=7800387e 0009:Call kernel32.UnhandledExceptionFilter(7fc2f81c) ret=7800ed71 0009:Call ntdll.NtQueryVirtualMemory(ffffffff,9803a11c,00000000,7fc2f6e8,0000001c,7fc2f6a8) ret=7fd1aae1 0009:Ret ntdll.NtQueryVirtualMemory() retval=00000000 ret=7fd1aae1 0009:Call kernel32.IsBadCodePtr(7800add3) ret=22d2b743 0009:Ret kernel32.IsBadCodePtr() retval=00000000 ret=22d2b743 0009:Call ntdll.NtCreateEvent(7fc2f6e8,001f0003,7fc2f6ec,00000001,00000000) ret=7fccb9b9 0009:Ret ntdll.NtCreateEvent() retval=00000000 ret=7fccb9b9 wine: Unhandled exception (thread 0009), starting debugger... ... The crash messages look a little bit different every time, with illegal instructions / access violations or even a Segmentation Fault without starting winedbg at various addreses(Attached file crashes). On very rare occasions, this crash doesn't occur, and the game continues to load and crashes later in some ddraw function. Instead of crashing it complains about a corrupted heap: err:heap:HEAP_ValidateInUseArena Heap 0x7fd80000: prev arena 0x7fe01640 is not prev for in-use 0x7fe01cb0 I've looked at a +heap trace, but I couldn't find anything usefull. (See ee-nocrash for a log). I've also attached a normal log without any special debug flags set(ee-normal.log.gz). I've added a few ERR statements for testing in some functions. So my questions are: *Am I right with my suspection that the problems are caused by a incorrect return? *How can I get a disassembly of Low-Level Engine.?Deactivate@GERasterizer@@UAEJXZ or simmilar functions. I didn't find this symbol. Thanks for your help, Stefan Dösinger [1] A demo is available at http://www.vugames.de/scripts/download.aspx?content=4&id=53721&nf=21&url=ft…, but I haven't checked wheter it produces the same results. [2] Other users reported a msvc runtime error, apparently caused by an error returned by Main_DirectDraw_SetCooperativeLevel. EE calls this function with cooplevel == DDSCL_SETFOCUSWINDOW. I made the function simply return DD_OK in this case. Furthermore it checks for sound support and the OS version(setting it to Win98 or WinME is recommended) and it needs native msvcrt(It even seems to ship it's own version)

5 20

Re: PATCH: sensap IsNetworkAlive
by Vijay Kiran Kamuju 26 Aug '05

26 Aug '05

Hi, According to MSDN, >+#define NETWORK_ALIVE_RAS 2 must be #define NETWORK_ALIVE_WAN 2 I think so, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/syncmgr/sy… Thanks, Vijay

1 0

More compatible memory arrangement ?: dlls/winsock.c: WS_dup_pe()
by Krzysztof C. 26 Aug '05

26 Aug '05

Hi, I was having a problem with a game, it couldn't connect to the server, so I started debugging things, and it ofcourse brought me to dlls/winsock.c but the problem seems to be on the game side ( unfortunately its closed-source, so I can only guess what's happening ). The debugging showed that when the game was getting server's ip from DNS (WS_gethostbyname()), it was getting wrong values. Then I started looking for the cause, and I found out that the game was incorrectly reading the hostent/WS_hostent structure. It was assuming that the ip address was at particular offset from the beginning of the structure, it didn't follow the pointers and thus it was getting wrong data. Then I rewrote few lines of the code and now it looks like: "pointer | pointer | pointer | ... data | data | data | .... " and everything works fine. So I assume that Microsoft's winsock arrange this structure this way, but I am not sure if it is 100% compatible way solving "one application problem", although few other programs dependent on this function worked fine with this change. Anyway I left the topic with question mark because I would like to know someone else's opinion on that. ( btw. I am new to mailing lists and it is my first post, so please don't be too rough on me in your responses : ) Index: dlls/winsock/socket.c =================================================================== RCS file: /home/wine/wine/dlls/winsock/socket.c,v retrieving revision 1.188 diff -u -p -r1.188 socket.c --- dlls/winsock/socket.c 25 Aug 2005 10:22:12 -0000 1.188 +++ dlls/winsock/socket.c 25 Aug 2005 22:20:58 -0000 @@ -3343,16 +3343,16 @@ static struct WS_hostent *WS_dup_he(cons p_to->h_addrtype = p_he->h_addrtype; p_to->h_length = p_he->h_length; - p = (char *)(p_to + 1); + p = (char *)p_to + sizeof(struct hostent); + p_to->h_addr_list = (char **)p; + p += list_dup(p_he->h_addr_list, p_to->h_addr_list, p_he->h_length); + p_to->h_name = p; - strcpy(p, p_he->h_name); - p += strlen(p) + 1; + strcpy(p_to->h_name, p_he->h_name); + p += strlen(p_he->h_name) + 1; p_to->h_aliases = (char **)p; - p += list_dup(p_he->h_aliases, p_to->h_aliases, 0); - - p_to->h_addr_list = (char **)p; - list_dup(p_he->h_addr_list, p_to->h_addr_list, p_he->h_length); + list_dup(p_he->h_aliases, p_to->h_aliases, 0); return p_to; }

1 0

Re: Need some help with a patch for version.dll
by Stefan Dösinger 25 Aug '05

25 Aug '05

Hi, > I can't use a LPCSTR, cause: > > BOOL WINAPI VerQueryValueA( LPVOID pBlock, LPCSTR lpSubBlock, > LPVOID *lplpBuffer, UINT *puLen ) > > lplpBuffer points to a place in pBlock where the value is. This value is > in most cases a UNICODE string. This string has to be converted to ANSI > and placed on a different place in pBlock (+ info->wLength + 4). > > Hope this makes sense. Oh, sure, you can't change it here. I guess you need a typecast here to supress the warning. But there are some helper functions for converting a unicode string to an ansi string. If you can use them, this might save you some troubles. Stefan

1 0

Need some help with a patch for version.dll
by Paul Vriens 25 Aug '05

25 Aug '05

Hi, I've finally nailed the last (?) bugs in version.dll. The attached patch shows how. There is however a warning during compile and I have no clue (still learning C :-) ) how to fix that: info.c: In function `VerQueryValueA': info.c:754: warning: pointer of type `void *' used in arithmetic info.c:754: warning: pointer of type `void *' used in arithmetic info.c: In function `VerQueryValueW': info.c:817: warning: pointer of type `void *' used in subtraction info.c:817: warning: pointer of type `void *' used in arithmetic Any idea's ? Cheers, Paul.

2 1

Compiling winelib dependant code with g++
by Gaudet Michael-MGAU01 25 Aug '05

25 Aug '05

wineg++ is using g++, and is passing its options to g++. How can I link some winelib-dependant code with g++ ? compilation is okay, but at linking time, all wine functions are unresolved. // ### here's the output :### [root@udp015809uds Wine2]# g++ -lwine registry.o registry_wrap.o -o registry.out registry.o(.text+0x2e): In function `CreateKey(char const*)': : undefined reference to `RegCreateKeyA' registry.o(.text+0x58): In function `CreateKey(char const*)': : undefined reference to `RegQueryValueExA' registry.o(.text+0x8f): In function `CreateKey(char const*)': : undefined reference to `RegQueryValueExA' registry.o(.text+0xa5): In function `CreateKey(char const*)': : undefined reference to `MessageBoxA' collect2: ld returned 1 exit status // ### And the same code compiled with wineg++ ### [root@udp015809uds Wine2]# wineg++ -lwine registry.o registry_wrap.o -o registry.out // program runs okay. For information, I need to use g++ in order to assimilate wine lib framework to SWIG, to generate Win32 wrappers in C# for mono. Thanks.

2 1

compile a shared object using winelib with g++
by Gaudet Michael-MGAU01 25 Aug '05

25 Aug '05

Hello all. Do you know if there is a way to compile a shared object using winelib with g++ or wineg++ ? I am using wine20050725 under Linux2.6.8.1-12mdk I need references to advapi32.dll and user32.dll. Thanks.

1 0

Bugzilla - old rubbish bugs...
by Ann & Jason Edmeades 25 Aug '05

25 Aug '05

I asked this a while ago and noone was too upset, but I am going to try to spend some time slowly closing off some of the bugs which do not have enough info in them to be reproduced, and have not had a response to a request to see if the problem persists for a long time (e.g. 6 months). I wont close anything which is reproducible (I'll try if I can) and I believe if something is wrongfully closed it can always be reopened? If anyone else has a spare moment, feel free to help! At the moment there is >1300 available bugs, but looking at lots of them in detail I doubt there's 500 which are worth keeping! (I was bored and looking for some things to fix and it's like a needle in the haystack looking in bugzilla at the moment). Jason

2 1

Loading resources from wine dlls
by Michael Jung 25 Aug '05

25 Aug '05

Hello, I would like to add a 'My Documents' icon to shell32. This icon has a resource ID of 235 in WinXP's shell32. Apparently one can't load resources from wine's own dlls, though. If you call PrivateExtractIcons with 'c:\windows\system32\shell32.dll' as the file name parameter, you'll get a 'WARN: File %s not found or path too long'. I guess that's because there is no such file in wine's fake windows environment. There is a hack (which is even declared as a hack in the comment) in the initialization code of the 'Shell Icon Cache' (starting from line 372 in 'dlls/shell32/iconcache.c'). It loads the first 38 icons from shell32 at initialization time, and later returns them from the cache without having to access the file (which would'nt work). This seems to be a principal problem (Loading resources from wine dlls, if they are accessed by the filename they have on a windows system). Are there any plans on how to fix this? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

3 2

Throwing in an idea (probably it was discussed before though)
by John Smith 25 Aug '05

25 Aug '05

As a Win developer, I want to make a suggestion (sorry if it was already discussed - or if similar mechanism already exists): What if some simple way will be provided for Win developers to say which options they prefer for WINE to use for their application? While it may seem to somewhat contradict to the 'big bright future' of the WINE (with all the apps running flawlessly under WINE), it would hopefully allow for immediate increase of out-of-the-box supported applications. For example, it could be a resource string of special format (for example, "__WINE_CONFIG_HINT: "Managed" = "N""), and multiple hints should be allowed. This hint should override system-wide settings but in turn should be overridden by per-app settings in wine config file/registry. _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/

8 13

Re: secur32: Getting some real functionality into the NTLM provider, try 2
by Juan Lang 25 Aug '05

25 Aug '05

Hi Kai, In ntlm.c, + /* convert the program name to Unicode */ (snip) + /* and back to the CP_UNIXCP */ This round-tripping is unnecessary when the text is already ASCII. ASCII values are just as valid in UTF8 as they are in CP1252 or whatever. Basically, don't bother converting anything you can type. + if(pAuthData == NULL) In this if statement, you duplicate the business of converting the user name and domain name to CP_UNIXCP in both branches. You should instead store a pointer to the user name and domain name, and convert them in one common branch after the if statement. + SEC_CHAR *client_argv[] = + { + program, + client_protocol, + client_user_arg, + client_domain_arg, + NULL + }; You must declare variables at the beginning of the block, not in the middle. Not all C compilers allow this. + if(pszPackage != NULL) + { + int package_sizeW = MultiByteToWideChar(CP_ACP, 0, pszPackage, -1, + NULL, 0); Since you don't use pszPackage in ntlm_AcquireCredentialsHandleW, why bother converting it? Just pass NULL. + if(identity->Flags == SEC_WINNT_AUTH_IDENTITY_ANSI) (snip) + else + { + memcpy(pAuthDataW, identity, sizeof(SEC_WINNT_AUTH_IDENTITY_W)); + } This looks funny. Why not just set pAuthDataW to identity in this case? That way you avoid the memcpy. Something like this: PSEC_WINNT_AUTH_IDENTITY_W pAuthDataW; if (identity->Flags == SEC_WINNT_AUTH_IDENTITY_ANSI) { /* convert it like you do */ } else pAuthDataW = (PSEC_WINNT_AUTH_IDENTITY_W)identity; /* call ntlm_AcquireCredentialsHandleW */ if (pAuthDataW != identity) HeapFree(GetProcessHeap(), 0, pAuthDataW); + if((ret = encodeBase64(helper->password, + helper->pwlen-2, buffer+3, + max_len-3, &buffer_len)) != SEC_E_OK) + { + HeapFree(GetProcessHeap(), 0, buffer); + HeapFree(GetProcessHeap(), 0, bin); + return ret; + } You ought to zero the memory of the password and free it, regardless of whether encodeBase64 succeeds or fails. (Really you ought to call SecureZeroMemory, but wine hasn't implemented that.. oh well.) In tests/ntlm.c: + //lstrcpyA(identity->Password, pass ? pass :""); No C++ style comments, please. More generally, on the tests, I like them because they should nearly always succeed in Windows. But they're not very likely to succeed in Wine, are they? You handle not having an ntlm_auth fairly gracefully, I think, and also handle not being able to create an inbound context, which you say may not work without some magic setup. But this won't generally work out of the box if ntlm_auth works and an inbound context can be created, can it? The tests will try to authenticate with whatever domain name is in the registry, or default to WORKGROUP if that's empty, and your UNIX username, and no password. That's not very likely to succeed. So, it would be nice to have these tests somewhere for people to check that this code indeed works.. but I'm not sure they can go into the regression test suite. Unless I'm mistaken. Thanks, --Juan ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs

1 0

Delphi 5 debugger is working!
by Vitaliy Margolen 24 Aug '05

24 Aug '05

As of todays CVS Delphi 5 debugger is fixed. Well, ok, there are still some bugs. One is a minor bug (Module view reports all modules as a project executable name), but all exports are there. You can even try to disassemble them. But here is where the major problems start. Debugger segfaults on that. This is because NtQueryVirtualMemory and NtProtectVirtualMemory currently don't work on other processes. I have modified those functions to return STATUS_SUCCESS instead. This allows to access ntdll, kernel32 and possibly any other modules that have the same base address for application and debugger. You might need prelink installed to relocate ntdll and kernel32 to 0x7bxxxxxx addresses. This makes their base addresses the same for all wine apps. Unfortunately fixing NtQueryVirtualMemory, NtProtectVirtualMemory and others is not that simple. Basically there are no way to do it from other processes. Ok, NtQueryVirtualMemory could be implemented some-what easily using NtReadVirtualMemory and possibly one more server call. But for others I see only three ways to implement them: 1. Adding worker thread to each process. This way we can ask it to perform requested operation for us. But, there is a catch - this will complicate lots of things. Besides, messing with processes is not a good thing(tm). It will brake some apps, that don't expect to see more then one thread. Or if we'll try to hide a worker thread, it will make things even worse. 2. Using signal(s). Unfortunately this is not as simple to do ether. From what I been told, this will require non trivial synchronization, that still doesn't guarantee deadlocks. 3. Infamous wine kernel module. Some how I don't think that kernel guys will go for this type of functionality. Even for debugging proposes, it still poses considerable security risk allowing one process manipulate other process' memory. So it will have to be a wine only module, which means we'll have to maintain in against all supported kernel versions and require kernel development environment. Any other solutions that I have forgotten/haven't even thought of? -- Best regards, Vitaliy

5 6

Re: Software patents
by gslink 24 Aug '05

24 Aug '05

The whole business of software patents is very likely to explode at any time. There are several software patents on cds and dvds which are so vague that it is impossible to tell exactly what is going on. The licenses to use these patents allow the company issuing the patent to control cd content and to examine it. The first time one of these companies tries to use the license to access DOD classified information there will be a resolution. The easiest way to resolve this business with Borland is to contact Borland. They may also have an interest in Wine. If they have no objection to what Wine wants to do then there is no one else to complain. They might even help Wine. Borland probably doesn't even realize that Wine exists although some of the people in Borland are probably very familiar with it. I think you will find this to be true of all big software companies such as IBM and Microsoft.

8 10

solution for including itss.h in hhctrl.ocx
by James Hawkins 24 Aug '05

24 Aug '05

Hey Alexandre, I need to be able to include itss.h from dlls/itss in order to read CHM files. Mike offered the solution that I add -I($SRCDIR)../itss to hhctrl's Makefile.in. The next problem comes when I run make depend. make depend looks for itss.h but can't find it because it hasn't been built yet. Mike then suggested adding ../dlls/itss/itss.idl to IDL_SRCS in include/Makefile.in. That works fine up until make install which gives these two errors: /usr/bin/install: cannot create regular file `/usr/include/wine/windows/../dlls/itss/itss.idl': No such file or directory /usr/bin/install: cannot create regular file `/usr/include/wine/windows/../dlls/itss/itss.h': No such file or directory Do you have any suggestions on how to access itss.h from hhctrl.ocx? -- James Hawkins

2 1

Re: commctrl: dialog theming
by Evil 24 Aug '05

24 Aug '05

I'm no longer able to run programs that require the native comctl32 and commctrl DLLs, since updating to today's CVS. Could it be related to these theme patches? It seems that now, if you override comctl32 for any app (or globally), even WineCfg itself will error out with the error. err:thunk:_loadthunk (commctrl.dll, Cctl1632_ThunkData16, comctl32.dll): Unable to load 'commctrl.dll', error 2 err:module:LdrInitializeThunk "comctl32.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"c:\\windows\\system32\\winecfg.exe" failed, status c0000142 The native commctrl.dll and comctl32.dll both exist in my windows/system directory - the same versions that always worked before. Overriding commctrl doesn't have any effect on this error. -J Frank Richter wrote: >This patch assumes the listbox patch was applied before. > >Frank Richter <frank.richter(a)gmail.com> >Add theming support for dialogs (to support tab page background). > >

5 9

wine error with 'wine client error:d: write: Bad file descriptor'
by Oliver Mössinger 24 Aug '05

24 Aug '05

Hi wine-devel, i have a windows program whitch generates the attached 'wine.txt' wine output. Followed is a part of the output: >>> Threads: process tid prio (all id:s are in hex) 00000042 (D) C:\MGC\LeoSpec\LS2005a_82\bin\win32\leonardo.exe 00000017 0 0000000d 0 <== 0000000e 00000016 0 00000013 0 00000012 0 00000011 0 00000010 0 0000000f 0 WineDbg terminated on pid 0x42 wine client error:d: write: Bad file descriptor <<< The program works with windows! Can someone help me to run the program? thanks Oliver Mössinger

1 0

Re: secur32: Getting real functionality into the NTLM provider
by Alexandre Julliard 24 Aug '05

24 Aug '05

Kai Blin <blin(a)gmx.net> writes: > + unsigned char buffer[SECUR32_MAX_BUF_LEN+6000]; > + BYTE bin[SECUR32_MAX_BUF_LEN]; You shouldn't allocate fixed size buffers on the stack, especially not huge ones like that. You should compute the necessary size and allocate a properly sized buffer from the heap. > + SEC_CHAR client_user_arg[512]; > + SEC_CHAR client_domain_arg[512]; > + SEC_CHAR passwd[512] = {0}; Same here, there's nothing that guarantees the buffers are the right size; using snprintf may avoid overflows but it doesn't make the code behave correctly. > +SECURITY_STATUS fork_helperA(PNegoHelperA *new_helper, const char *prog, > + char * const argv[], char* passwd) > +{ You should have a single fork helper that takes Unicode, you can't pass ASCII chars to the Unix app anyway, you have to use CP_UNIXCP. And more generally, you should do everything in Unicode. > + if( ( pipe(pipe_in) < 0 ) || ( pipe(pipe_out) < 0 ) ) > + { > + return SEC_E_INTERNAL_ERROR; > + } > + > + helper->helper_pid = fork(); > + > + helper->password = passwd; > + > + if(helper->helper_pid == -1) > + { > + return SEC_E_INTERNAL_ERROR; > + } You are leaking file descriptors in the error cases. > + if(helper->helper_pid == 0) > + { > + /* We're in the child now */ > + close(0); > + close(1); > + > + dup2(pipe_out[0], 0); > + close(pipe_out[0]); > + close(pipe_out[1]); > + > + dup2(pipe_in[1], 1); > + close(pipe_in[0]); > + close(pipe_in[1]); > + > + execvp(prog, argv); > + > + /* Whoops, we shouldn't get here. Big badaboom.*/ > + return SEC_E_INTERNAL_ERROR; You shouldn't return from the child, you should pass the error back to the parent and then exit(). > + { > + helper->pipe_in = fdopen(pipe_in[0], "r"); > + close(pipe_in[1]); > + helper->pipe_out = fdopen(pipe_out[1], "w"); > + close(pipe_out[0]); > + } You should avoid using stdio. -- Alexandre Julliard julliard(a)winehq.org

2 2

wglMakeCurrent doesn't pick up HDC region
by Russ 24 Aug '05

24 Aug '05

Trying to get my commercial 3-D app to run under WINE using the same binary with the odd workaround or two. It uses OpenGL in various subwindows of the main window as needed. Under WINE, the subwindow graphics all get drawn in the lower left corner of the overall X11 window. In Win32, when you call wglMakeCurrent, the opengl context is configured to match the size/position of the HWND for the HDC, so drawing openGL goes just into the desired subwindow. However, the WINE implementation of wglMakeCurrent just calls glXMakeCurrent (and glXCreateContext), which produces the entire size of the X11 window, resulting in the incorrect behavior observed. In my Mac OS X port, I have a similar issue, resolved by calling aglSetInteger(glContext, AGL_BUFFER_RECT,... I'm not sure what a glX equivalent would be to try, I don't see one offhand. As is, emulating the wglMakeCurrent accurately appears impossible, such that apps that use this Windows behavior can not be run. Suggestions welcome. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

x11drv: use of uninitialized rect
by James Hawkins 24 Aug '05

24 Aug '05

Hey, While compiling x11drv, gcc gives the following error: gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o text.o text.c text.c: In function 'X11DRV_ExtTextOut': text.c:85: warning: 'rect.bottom' is used uninitialized in this function text.c:85: warning: 'rect.top' is used uninitialized in this function text.c:85: warning: 'rect.right' is used uninitialized in this function text.c:85: warning: 'rect.left' is used uninitialized in this function Looking through the CVS log for text.c, I saw that before the latest patch, rect would be initialized if lprect == NULL; otherwise, rect = *lprect. My guess is that we want to use lprect instead of rect, but I'm not familiar enough with that code to make the change. Can you take a look at this Huw? Thanks, James Hawkins

1 0

WineHQ will be offline tomorrow
by Jeremy Newman 23 Aug '05

23 Aug '05

I will be taking the website offline tomorrow starting at 09:00 CDT (04:00 GMT). I will be moving it to a new ISP. Expect downtime to last for up to 8 hours as I will also be doing a complete reinstall of the OS. This will also affect the mailing lists and the CVS. -- Jeremy Newman <jnewman(a)codeweavers.com> CodeWeavers, Inc.

3 6

Re: winecfg: theming
by Kevin Koltzau 23 Aug '05

23 Aug '05

On Tuesday 23 August 2005 2:39 pm, Frank Richter wrote: > + static const WCHAR themesSubdir[] = > + { > '\\','R','e','s','o','u','r','c','e','s','\\','T','h','e','m','e','s',0 }; > + WCHAR themesPath[MAX_PATH]; > + > + free_theme_files(); > + themeFiles = DSA_Create (sizeof (ThemeFile), 1); > + > + GetWindowsDirectoryW (themesPath, MAX_PATH); This should be based on SHGetFolderPath(CSIDL_RESOURCES)

1 0

Re: shell32: Some tests for FolderShortcut class (3rd try)
by Michael Jung 23 Aug '05

23 Aug '05

Hi Alexandre, On Monday 22 August 2005 17:04, Michael Jung wrote: > Changelog: > Added some tests for CLSID_FolderShortcut objects Are there any further problems with this patch? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

1 0

Automatic ANSI<>Unicode message translation
by Phil Krylov 23 Aug '05

23 Aug '05

Hi, I am having a problem with an app of mine. It posts WM_CHAR messages to a ANSI window with Unicode value in LOWORD(wParam). Wine automatically translates the character code to ANSI (producing a "?" when there is no such code in CP_ACP). Windows does not do it (contrary to documentation). Here is attached (source and binary) a quick and dirty sample application which shows the problem. I could remove map_wparam_AtoW() and map_wparam_WtoA() from dlls/user/message.c, but probably somebody needs that translation. Does anybody have an idea of a better fix for that bug? -- Ph.

5 29

Re: Remove unnecessary #pragma code_page(xxxx) statements from winefile .rc files
by Martin Fuchs 23 Aug '05

23 Aug '05

> This is because 'LANGUAGE LANG_xxxx' statements don't actually change > code page specified by a previous '#pragma code_page(xxxx)', therefore > russian resources get translated to unicode using wrong code page. > I don't know whether it's an rc bug or a feature. We either need > to remove '#pragma code_page' statements altogether, or add them > to all included .rc files. I took the 1st approach. > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Remove unnecessary #pragma code_page(xxxx) statements from > winefile .rc files, they confuse the resource compiler. Please be carefull to remove the code page pragmas. IMHO this is not the correct way. When there is no other code page given, the resource compiler uses the current code page of the operating system. And I don't think, all of those language specific resource scripts will compile correct on all possible OS code pages. The reliable way would be to include the correct code page at the begin of all resource scripts. Please take in mind: Wine is compiled on many different environments: LANG_C, de_DE.ISO-8859-1, en_EN.UTF-8, swedish, or whatever... Removing the code page pragmas would require to test the correctness of the compilation results of all different languages on all possible platforms. Regards, Martin

2 1

Safedisc1 CD checks work, it tries to start the game but fails to do so
by Ivan Leo Puoti 23 Aug '05

23 Aug '05

Hello list, here's a little update Safedisc1 now successfully passes all anti debugger check, and recognises the CD correctly. It then attempts to start the game, but this doesn't work yet because of the nested exception on signal stack bug. Hopefully we aren't too far from getting it to run. Ivan.

4 3

Re: [winedbg] Don't ever pass a NONCONTINUABLE exception
by Alexandre Julliard 22 Aug '05

22 Aug '05

Glenn Wurster <gwurster(a)scs.carleton.ca> writes: > Changelog: > Don't pass on non-continuable exceptions. Why do you want to do that? -- Alexandre Julliard julliard(a)winehq.org

3 6

Re: Throwing in an idea (probably it was discussed before though)
by Jacek Caban 22 Aug '05

22 Aug '05

John Smith wrote: >> You can also set it yourselves in in your app. As configuration >> is in registry, every app can modify it. > > > I like this idea, thanks. There are still 2 issues with such a soultion: > a) most likely, it won't work until 2nd start of the application (we > will modify it on the first run, and it most likely won't be applied > until the second run); If you have an installer, you may configure Wine during installation. If not - just detect Wine at the beginning of the app and, if you have to configure Wine, do so and restart the app. It's a bit (very) hackish but it should work and it's not visible for user. > b) current WINE guides are discouraging us from detecting WINE - and > messing up with Windows Registry, especially HKEY_LOCAL_MACHINE, on > all the millions of non-WINE machines is not a thing I would really > like to do (the last thing we want is to be caught by some antivirus, > which monitors activity it considers suspicious and changing > HKEY_LOCAL_MACHINE can easily qualify). > You don't have to touch HKEY_LOCAL_MACHINE, Wine's configuration is in HKEY_CURRENT_USER. And you may use modified WGA (and millions of other) way to detect Wine:-) Note: I still think fixing Wine is better way to go. Jacek

1 0

UpdateWindow doesn't call XFlush
by Michael Kaufmann 22 Aug '05

22 Aug '05

Hi all, I've noticed that after an application calls UpdateWindow, the window contents doesn't get updated until the application requests the next event (GetMessage/PeekMessage). That's because UpdateWindow doesn't flush the X output queue (XFlush). I think the best approach would be that UpdateWindow calls GdiFlush, but this function is currently not implemented. The problem is that GdiFlush doesn't get a DC handle, it must figure out itself which DCs it has to flush. Can anyone implement GdiFlush or propose another mechanism on how to call XFlush in UpdateWindow? Regards Michael

1 0

X11: Problems with ConfigureNotify events that are received/processed too late
by Michael Kaufmann 22 Aug '05

22 Aug '05

Hi all, I'm trying to get the dialog boxes of Word 95 working. They often appear with the minimal window size (about 70x50 pixels), so they're unusable. With KDE's window manager (KWin) this happens very often. With Enlightenment and GNOME's window manager (Metacity), it only happens from time to time. I've looked for the reason, and I think it's very closely related to WINE bug 1265 which Duane Clark has tried to fix here: http://www.winehq.com/hypermail/wine-patches/2003/02/0095.html That's what's going on (CVS version of WINE, managed window mode): 1. Word creates a dialog with an initial position of (0,0) and size 0x0 (using CreateWindowEx) 2. Word calls SetWindowPos to set the correct dialog position and size 3. Word calls SetWindowPos to show the dialog (SWP_SHOWWINDOW) 4. The dialog gets the focus, the main window is being deactivated 5. In the WM_NCACTIVATE procedure of the main window, Word calls GetQueueStatus. WINE will process X events. 6. WINE receives a ConfigureEvent for the initial dialog position and size (0x0) and saves this to data->whole_rect in X11DRV_sync_window_position (7. If you're lucky, WINE also receives a ConfigureEvent for the correct dialog position) 8. Wine shows the dialog and maps it. It calls X11DRV_set_wm_hints, which calls set_size_hints. This procedure uses data->whole_rect as the dialog's rectangle. But this stored rectangle is completely wrong because WINE has not yet received all ConfigureEvents. 9. The window manager has to resize the dialog to the wrong size. The best solution would be to process all X events before setting the window position in SetWindowPos, but I don't know if that's possible. I've tried another approach: WINE should not set the window size hints when mapping a window (step 8.). I've attached a patch, but it's not 100% correct, because the style of a window (e.g. the WS_THICKFRAME style) may be changed by an application using SetWindowLong and SetWindowPos (with the SWP_FRAMECHANGED flag). WINE doesn't look for the SWP_FRAMECHANGED flag and updates the X11 window every time if it's visible or gets visible. So if an application calls SetWindowPos with the SWP_SHOWWINDOW flag, WINE needs to set the size hints because the window has been hidden and its style may have been changed. What would be the correct fix for this problem? Any ideas? Thanks, Michael Index: window.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/window.c,v retrieving revision 1.115 diff -u -r1.115 window.c --- window.c 27 Jul 2005 15:22:58 -0000 1.115 +++ window.c 15 Aug 2005 21:32:54 -0000 @@ -353,9 +353,9 @@ /*********************************************************************** * X11DRV_set_wm_hints * - * Set the window manager hints for a newly-created window + * Set the window manager hints for a window */ -void X11DRV_set_wm_hints( Display *display, struct x11drv_win_data *data ) +void X11DRV_set_wm_hints( Display *display, struct x11drv_win_data *data, BOOL update_size_hints ) { Window group_leader; XClassHint *class_hints; @@ -400,7 +400,7 @@ } /* size hints */ - set_size_hints( display, data, style ); + if (update_size_hints) set_size_hints( display, data, style ); /* systray properties (KDE only for now) */ if (ex_style & WS_EX_TRAYWINDOW) @@ -692,7 +692,7 @@ xim = x11drv_thread_data()->xim; if (xim) data->xic = X11DRV_CreateIC( xim, display, data->whole_window ); - X11DRV_set_wm_hints( display, data ); + X11DRV_set_wm_hints( display, data, TRUE ); SetPropA( data->hwnd, whole_window_prop, (HANDLE)data->whole_window ); return data->whole_window; Index: winpos.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/winpos.c,v retrieving revision 1.136 diff -u -r1.136 winpos.c --- winpos.c 15 Aug 2005 09:33:39 -0000 1.136 +++ winpos.c 15 Aug 2005 21:32:56 -0000 @@ -489,7 +489,7 @@ { TRACE( "mapping win %p\n", hwnd ); X11DRV_sync_window_style( display, data ); - X11DRV_set_wm_hints( display, data ); + X11DRV_set_wm_hints( display, data, FALSE ); wine_tsx11_lock(); XMapWindow( display, data->whole_window ); wine_tsx11_unlock(); @@ -650,7 +650,7 @@ { TRACE( "mapping win %p\n", hwnd ); X11DRV_sync_window_style( display, data ); - X11DRV_set_wm_hints( display, data ); + X11DRV_set_wm_hints( display, data, FALSE ); wine_tsx11_lock(); XMapWindow( display, data->whole_window ); wine_tsx11_unlock(); Index: x11drv.h =================================================================== RCS file: /home/wine/wine/dlls/x11drv/x11drv.h,v retrieving revision 1.76 diff -u -r1.76 x11drv.h --- x11drv.h 29 Jun 2005 19:28:06 -0000 1.76 +++ x11drv.h 15 Aug 2005 21:32:58 -0000 @@ -686,7 +686,7 @@ const RECT *new_whole_rect ); extern BOOL X11DRV_set_window_pos( HWND hwnd, HWND insert_after, const RECT *rectWindow, const RECT *rectClient, UINT swp_flags, const RECT *validRects ); -extern void X11DRV_set_wm_hints( Display *display, struct x11drv_win_data *data ); +extern void X11DRV_set_wm_hints( Display *display, struct x11drv_win_data *data, BOOL update_size_hints ); extern void X11DRV_handle_desktop_resize(unsigned int width, unsigned int height); extern void X11DRV_Settings_AddDepthModes(void);

1 1

(no subject)
by John Smith 22 Aug '05

22 Aug '05

>You can also set it yourselves in in your app. As configuration >is in registry, every app can modify it. I like this idea, thanks. There are still 2 issues with such a soultion: a) most likely, it won't work until 2nd start of the application (we will modify it on the first run, and it most likely won't be applied until the second run); b) current WINE guides are discouraging us from detecting WINE - and messing up with Windows Registry, especially HKEY_LOCAL_MACHINE, on all the millions of non-WINE machines is not a thing I would really like to do (the last thing we want is to be caught by some antivirus, which monitors activity it considers suspicious and changing HKEY_LOCAL_MACHINE can easily qualify). _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/

1 0

Re: X11DRV: more gcc 4.0 warning fixes
by Alexandre Julliard 22 Aug '05

22 Aug '05

Mike McCormack <mike(a)codeweavers.com> writes: > Index: dlls/x11drv/event.c > =================================================================== > RCS file: /home/mike/src/wine-cvs/wine/dlls/x11drv/event.c,v > retrieving revision 1.58 > diff -u -p -r1.58 event.c > --- dlls/x11drv/event.c 16 Aug 2005 16:02:45 -0000 1.58 > +++ dlls/x11drv/event.c 17 Aug 2005 01:09:41 -0000 > @@ -698,7 +698,7 @@ static void EVENT_DropFromOffiX( HWND hW > > if( !aux_long && p_data) /* don't bother if > 64K */ > { > - signed char *p = (signed char*) p_data; > + char *p = (char*) p_data; > char *p_drop; > > aux_long = 0; The code is storing -1 in there so it has to be a signed char (though that algorithm is really a nasty hack that should be fixed properly). > --- dlls/x11drv/text.c 23 Dec 2004 20:31:56 -0000 1.15 > +++ dlls/x11drv/text.c 16 Aug 2005 01:53:53 -0000 > @@ -390,7 +390,7 @@ X11DRV_ExtTextOut( X11DRV_PDEVICE *physD > wine_tsx11_lock(); > if (lfUnderline) > { > - long linePos, lineWidth; > + unsigned long linePos, lineWidth; > > if (!XGetFontProperty( font, XA_UNDERLINE_POSITION, &linePos )) > linePos = descent - 1; > @@ -405,7 +405,7 @@ X11DRV_ExtTextOut( X11DRV_PDEVICE *physD > } > if (lfStrikeOut) > { > - long lineAscent, lineDescent; > + unsigned long lineAscent, lineDescent; > if (!XGetFontProperty( font, XA_STRIKEOUT_ASCENT, &lineAscent )) > lineAscent = ascent / 2; > if (!XGetFontProperty( font, XA_STRIKEOUT_DESCENT, &lineDescent )) I think these should remain signed too, especially since lineDescent is set to -lineAscent. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: MSXML: add some node tests
by Alexandre Julliard 22 Aug '05

22 Aug '05

Mike McCormack <mike(a)codeweavers.com> writes: > diff -u -p -r1.1 domdoc.c > --- dlls/msxml3/tests/domdoc.c 12 Aug 2005 11:25:05 -0000 1.1 > +++ dlls/msxml3/tests/domdoc.c 20 Aug 2005 07:38:47 -0000 > @@ -27,59 +27,65 @@ > #include "xmldom.h" > #include <stdio.h> > > +#ifndef STANDALONE > #include "wine/test.h" > +#else > +#define ok(cond,str) do{ if(!(cond)) fprintf(stderr,"line %d: %s",__LINE__,str); }while (0) > +#endif Please don't add that sort of thing again, simply copy wine/test.h over to Windows and build with -DSTANDALONE. -- Alexandre Julliard julliard(a)winehq.org

1 0

DDRAW: don't leak visuals
by Saulius Krasuckas 21 Aug '05

21 Aug '05

I was walking through a Lionel code (written in 2003) and stumbled at the call to XGetVisualInfo(). The list of visuals it returns is never released. Hence, three lines were added. This is my first X-perience. Does this look OK, folks? Index: dlls/ddraw/device_opengl.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/device_opengl.c,v retrieving revision 1.7 diff -p -u -r1.7 device_opengl.c --- dlls/ddraw/device_opengl.c 11 Aug 2005 10:57:47 -0000 1.7 +++ dlls/ddraw/device_opengl.c 21 Aug 2005 19:58:09 -0000 @@ -4344,12 +4344,14 @@ d3ddevice_init_at_startup(void *gl_handl gl_context = glXCreateContext(display, vis, NULL, GL_TRUE); if (gl_context == NULL) { + XFree(vis); LEAVE_GL(); WARN("Error creating default context for capabilities initialization - D3D support disabled !\n"); return FALSE; } if (glXMakeCurrent(display, drawable, gl_context) == False) { glXDestroyContext(display, gl_context); + XFree(vis); LEAVE_GL(); WARN("Error setting default context as current for capabilities initialization - D3D support disabled !\n"); return FALSE; @@ -4435,6 +4437,7 @@ d3ddevice_init_at_startup(void *gl_handl /* And frees this now-useless context */ glXMakeCurrent(display, None, NULL); glXDestroyContext(display, gl_context); + XFree(vis); LEAVE_GL(); return TRUE;

1 1

Re: secur32: Fix wrapper.c to honour functions that are run twice.
by Kai Blin 21 Aug '05

21 Aug '05

* Kai Blin <blin(a)gmx.net> [21/08/05, 20:15:55]: > - ret = SECUR32_makeSecHandle(phContext, package, &myCtxt); > + ret = SECUR32_makeSecHandle(phNewContext, package, &myCtxt); > if (ret != SEC_E_OK) > package->provider->fnTableW.DeleteSecurityContext( > &myCtxt); Of course this needs to be changed, or SECUR32_makeSecHandle will overwrite the return value of InitializeSecurityContext resp. AcceptSecurityContext. Fixed in my new patch. Sorry, Kai -- Kai Blin, (blin at gmx dot net) How sharper than a hound's tooth it is to have a thankless serpent.

1 0

Re: atl: fix warnings in 64bit
by Jacek Caban 21 Aug '05

21 Aug '05

Hello. Kevin Koltzau wrote: >Changelog > Remove 'cast to pointer from integer of different size' warnings in 64bit > > >------------------------------------------------------------------------ > >Index: dlls/atl/registrar.c >=================================================================== >RCS file: /home/wine/wine/dlls/atl/registrar.c,v >retrieving revision 1.11 >diff -u -d -r1.11 registrar.c >--- dlls/atl/registrar.c 10 Aug 2005 09:53:47 -0000 1.11 >+++ dlls/atl/registrar.c 21 Aug 2005 02:42:53 -0000 >@@ -634,7 +634,7 @@ > { > Registrar *This = (Registrar*)iface; > TRACE("(%p)->(%s %d %s)\n", iface, debugstr_w(resFileName), nID, debugstr_w(szType)); >- return resource_register(This, resFileName, (LPOLESTR)nID, szType, TRUE); >+ return resource_register(This, resFileName, (LPOLESTR)(UINT_PTR)nID, szType, TRUE); > } > > static HRESULT WINAPI Registrar_ResourceUnregister(IRegistrar* iface, LPCOLESTR resFileName, >@@ -642,7 +642,7 @@ > { > Registrar *This = (Registrar*)iface; > TRACE("(%p)->(%s %d %s)\n", This, debugstr_w(resFileName), nID, debugstr_w(szType)); >- return resource_register(This, resFileName, (LPOLESTR)nID, szType, FALSE); >+ return resource_register(This, resFileName, (LPOLESTR)(UINT_PTR)nID, szType, FALSE); > } > > static const IRegistrarVtbl RegistrarVtbl = { > > It doesn't make a big difference, but it would be better to use MAKEINTRESOURCEW macro here. Jacek

1 0

Re: [WINEOSS] multiple sound card mixer patch
by Robert Reif 21 Aug '05

21 Aug '05

Robert Reif wrote: > Fix mixer detection for multiple sound cards. > > > This fixes a bug with the previous patch and adds some more debugging info. Index: dlls/winmm/wineoss/mixer.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/wineoss/mixer.c,v retrieving revision 1.35 diff -p -u -r1.35 mixer.c --- dlls/winmm/wineoss/mixer.c 3 Aug 2005 21:25:10 -0000 1.35 +++ dlls/winmm/wineoss/mixer.c 21 Aug 2005 11:29:12 -0000 @@ -366,8 +366,8 @@ static DWORD MIX_Open(WORD wDevID, LPMIX * the equivalent of mixer identification * (with a reference to a wave, midi.. handle */ - if (!(mix = MIX_Get(wDevID))) { - WARN("bad device ID\n"); + if ((mix = MIX_Get(wDevID)) == NULL) { + WARN("bad device ID: %04X\n", wDevID); return MMSYSERR_BADDEVICEID; } @@ -610,8 +610,8 @@ static DWORD MIX_GetDevCaps(WORD wDevID, return MMSYSERR_INVALPARAM; } - if (!(mix = MIX_Get(wDevID))) { - WARN("bad device ID\n"); + if ((mix = MIX_Get(wDevID)) == NULL) { + WARN("bad device ID: %04X\n", wDevID); return MMSYSERR_BADDEVICEID; } @@ -787,7 +787,7 @@ static DWORD MIX_GetLineInfo(WORD wDevID } if ((mix = MIX_Get(wDevID)) == NULL) { - WARN("bad device ID\n"); + WARN("bad device ID: %04X\n", wDevID); return MMSYSERR_BADDEVICEID; } @@ -969,7 +969,7 @@ static DWORD MIX_GetLineControls(WORD wD } if ((mix = MIX_Get(wDevID)) == NULL) { - WARN("bad device id\n"); + WARN("bad device ID: %04X\n", wDevID); return MMSYSERR_BADDEVICEID; } @@ -1068,7 +1068,7 @@ static DWORD MIX_GetControlDetails(WORD } if ((mix = MIX_Get(wDevID)) == NULL) { - WARN("bad device ID\n"); + WARN("bad device ID: %04X\n", wDevID); return MMSYSERR_BADDEVICEID; } @@ -1266,7 +1266,7 @@ static DWORD MIX_SetControlDetails(WORD } if ((mix = MIX_Get(wDevID)) == NULL) { - WARN("bad device ID\n"); + WARN("bad device ID: %04X\n", wDevID); return MMSYSERR_BADDEVICEID; } @@ -1457,8 +1457,8 @@ static DWORD MIX_Init(void) #ifdef SOUND_MIXER_INFO mixer_info info; if (ioctl(mixer, SOUND_MIXER_INFO, &info) >= 0) { - MIX_Mixers[i].name = HeapAlloc(GetProcessHeap(),0,strlen(info.name) + 1); - strcpy(MIX_Mixers[i].name, info.name); + MIX_Mixers[MIX_NumMixers].name = HeapAlloc(GetProcessHeap(),0,strlen(info.name) + 1); + strcpy(MIX_Mixers[MIX_NumMixers].name, info.name); } else { /* FreeBSD up to at least 5.2 provides this ioctl, but does not * implement it properly, and there are probably similar issues @@ -1469,10 +1469,10 @@ static DWORD MIX_Init(void) #endif close(mixer); + MIX_Mixers[MIX_NumMixers].dev_name = HeapAlloc(GetProcessHeap(),0,strlen(name) + 1); + strcpy(MIX_Mixers[MIX_NumMixers].dev_name, name); MIX_NumMixers++; - MIX_Mixers[i].dev_name = HeapAlloc(GetProcessHeap(),0,strlen(name) + 1); - strcpy(MIX_Mixers[i].dev_name, name); - MIX_Open(i, NULL, 0); /* FIXME */ + MIX_Open(MIX_NumMixers - 1, NULL, 0); /* FIXME */ } else { WARN("couldn't open %s\n", name); }

1 0

Should all builtin DLLs have version information?
by Paul Vriens 21 Aug '05

21 Aug '05

Hi, the subject says it all. If yes, I will start adding some for the ones visible in Process Explorer when running some of 'my' test-apps. Paul.

2 2

excluding kernel32.9[78] from a relay log
by Saulius Krasuckas 20 Aug '05

20 Aug '05

Using CVS version I get following calls in the output very frequently: 000b:Call kernel32.97(408b8880) ret=40891d49 000b:Ret kernel32.97() retval=40428f60 ret=40891d49 000b:Call kernel32.98(408b8880) ret=40891e27 000b:Ret kernel32.98() retval=00000000 ret=40891e27 I want to exclude this stuff. Adding "97;98" to "HKEY_CURRENT_USER/Software/Wine/debug/RelayExclude" string value doesn't help me. $ grep -Ir [^0-9]9[78][^0-9] dlls/kernel/*.spec | dlls/kernel/kernel32.spec: 97 stdcall -noname _EnterSysLevel(ptr) | dlls/kernel/kernel32.spec: 98 stdcall -noname _LeaveSysLevel(ptr) Adding "_EnterSysLevel;_LeaveSysLevel;97;98" does not help either. Suggestions?

2 2

IDA Pro regression
by James Liggett 20 Aug '05

20 Aug '05

Hi, Yesterday, after not upgrading my wine CVS copy for about a month, I upgraded to do some testing. I started IDA pro (version 4.8 demo) and got ready to debug a DLL that's been giving me trouble. Getting ready to start the debugger, I opened the General Registers window, and I noticed that the boxes that show the contents of the registers were about five times taller than they normally are. I set up the process options for the debugger and tried to get back to the General Registers window to start the debugger but IDA crashed with an "Abnormal Termination" error. It doesn't give any unusual errors in the console. Can someone recommend to me some tips for finding the problem? I have considered downgrading CVS until I find the problem, but that seems like a *lot* of compiling and recompiling. Is there a more efficient way to go about finding the cause of the problem? Thanks very much, James Liggett

3 2

Bugs in ole32 test (Or in windows)
by Ivan Leo Puoti 20 Aug '05

20 Aug '05

The tmp files generated by the testProps() and testCodepage() in dlls/ole32/tests/stg_prop.c don't get deleted in windows nt 4.0, even if apparently a DeleteFileW is done on them. Ivan.

1 0

Re: winefile: TRY2 Fix for encoding Ru.rc
by Dmitry Timoshkov 20 Aug '05

20 Aug '05

"Yuri Kozlov" <kozlov.y(a)gmail.com> wrote: > Changelog: > fix for encoding Ru.rc > --- wine/programs/winefile/Ru.rc 2005-06-20 15:45:39.000000000 +0400 > +++ bwine/programs/winefile/Ru.rc 2005-08-18 19:56:37.000000000 +0400 > @@ -20,6 +20,8 @@ > > LANGUAGE LANG_RUSSIAN, SUBLANG_DEFAULT > > +#pragma code_page(1251) Why do you need it? Specifying a language should be enough, at least it works for all other resource files, including russian ones. -- Dmitry.

2 1

Re: RICHED20: Avoid flicker
by Phil Krylov 19 Aug '05

19 Aug '05

On Sun, 14 Aug 2005 17:53:33 +0400 Phil Krylov <phil(a)newstar.rinet.ru> wrote: > this patch needs to be applied after the "Re: RICHED20: Implement > EM_SETRECT, EM_SETRECTNP and WM_SETREDRAW messages (fixed)" patch. > > ChangeLog: > > Avoid flicker in RichEdit using proper update region invalidation and an > offscreen bitmap. Anything wrong with this patch? -- Ph.

2 1

Re: shell32: Some tests for FolderShortcut class
by Alexandre Julliard 19 Aug '05

19 Aug '05

Michael Jung <mjung(a)iss.tu-darmstadt.de> writes: > Changelog: > Added some tests for CLSID_FolderShortcut objects Could you please merge that in one of the existing test files, like shlfolder.c? We don't want to create too many test files. -- Alexandre Julliard julliard(a)winehq.org

1 0

Mouse-buttons swapped after winetest
by Paul Vriens 19 Aug '05

19 Aug '05

Hi, with the latest winetest http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/winetest-200506211000… my mouse-buttons (left and right) are swapped after the test. Any idea?? Cheers, Paul.

4 6

Re: USER32: fix gcc 4.0 warnings
by Alexandre Julliard 19 Aug '05

19 Aug '05

Mike McCormack <mike(a)codeweavers.com> writes: > When switching on a WORD value, case values should also be WORD values > to avoid value out of range warnings. We shouldn't be switching on a WORD, that magic item handling is broken. -- Alexandre Julliard julliard(a)winehq.org

1 0

Weird issue with advapi32 tests on nt 4.0
by Ivan Leo Puoti 19 Aug '05

19 Aug '05

The advapi32 tests save a key, load it and delete the file, and all is fine. But on nt 4.0 sp6 I'm getting a *really* weird, thing, a saved_key.LOG comes out of the blue, it appears to get written to disc after the RegLoadKey call at line 543 of dlls/advapi32/tests/registry.c, however this really shouldn't happen, why should RegLoadKey write this empty file? Has anyone else seen this? I was tempted to send a patch to just delete the file but I'm curious about where this file is coming from and why it gets created, anyone have a clue?. Ivan.

1 0

[Bug 3165] Patch available
by Dripple 19 Aug '05

19 Aug '05

Hi, I tested the patch submitted in http://bugs.winehq.org/show_bug.cgi?id=3165 Bugzilla page with Notes. Seems to fix the issue. Regards. Dripple.

4 3

winspool.drv: Conformance-Tests
by Detlef Riekenberg 18 Aug '05

18 Aug '05

Hi. I wrote a Commandline-Program for testing the Printing-API and found many misterious behaviour. While rewriting the conformance-tests for winspool.drv, how should we handle this bugs / features ? Example for GetPrinterDriverDirectory (W/A): Win98se and WinME do not check the requested level I marked that as todo("windows"). Is this ok? Another Example for GetPrinterDriverDirectory and Enum*: from MSDN: pcbNeeded [out] - Pointer to a value that specifies the number of bytes copied if the function succeeds, - or the number of bytes required if cbBuf is too small. On w2k, the the returned "number of bytes required" in the ANSI-Version is the same as in the Unicode-Version. For GetPrinterDriverDirectory, the rest from the unicode-version of the result is visible in the second part of the buffer. (I Think, w2k fill the buffer with the unicode-version and convert in-place to ANSI. Should we do the same ?) I marked both Versions as valid. (buffersize == (datasize+datasize) and buffersize == datasize) Is this ok? -- By By ... ... Detlef

2 2

Re: Cursor disappears and reappears
by gslink 18 Aug '05

18 Aug '05

I suspect this may not be in Wine at all. There is currently a problem that shows up both in and out of Wine with the cursor vanishing permanently until reboot on some games that block or change the cursor. This appears to be a problem in FC but I have not had time to track it down.

1 0

Re: IStorage* vs. LPSTORAGE vs. winapi_check
by Marcus Meissner 17 Aug '05

17 Aug '05

On Tue, Aug 16, 2005 at 04:33:36PM +0200, Francois Gouget wrote: > > I checked the prototypes of OleDoAutoConvert() and GetConvertStg() and > they use LPSTORAGE rather than IStorage* so I think the 16bit versions > should match. This would avoid introducing ISTorage* in win16.api. > > However one could probably also argue that these functions (which are > currently just stubs) should take a SEGPTR anyway... > > This brings me to OleLoad16() and ReadClassStg16() which were causing > winapi_check to complain because they have comments in their prototypes > that look like documentation to it. I think the right way to handle > those is use the regular documentation to document the real type of > these pointers, i.e. do it as follows: The LPSTORAGE layout is definitely not the same. So LPSTORAGE16 would be more fitting I think. Also when not using "SEGPTR" I get conversion warnings and it clarifies a bit what exactly the type of the argument is. I am fine by the patch, but will have to fix it up regarding LPSTORAGE once we get to the point of implementing those funcs. Ciao, Marcus

2 4

Re: fontforge 20050729 insists on adding .ttf extension
by Huw D M Davies 17 Aug '05

17 Aug '05

On Wed, Aug 17, 2005 at 02:25:29PM -0400, Pavel Roskin wrote: > Hello! > > ChangeLog: > fontforge 20050729 insists on adding .ttf extension even if > the requested output file name ends with a dot. So let's use > names ending with ttf. These are ttf files, and we are not even > installing them. This looks good to me. What seems to have happened was that George Williams gave Rob a workaround to a fontforge regression, that regression has since been fixed and the workaround no longer works. So applying this patch (in affect reversing Rob's) seems like the right thing to do, at the expense of breaking font creation for some versions of fontforger. Ideally we'd detect a broken fontforge, but I don't think it's really worth the effort. Huw.

1 0

Cursor Disappears and reappears
by Kevin DeKorte 17 Aug '05

17 Aug '05

Using Wine 20050725 and Lotus Notes 6.51 when I move my mouse to the database tabs or over the replication window the mouse disappears while I move over the tab or replicated databases and then reappears when I leave the list. The databases are highlighted, but having the mouse completely disappear is a little annoying. I don't remember it doing this with 20041202. Kevin -- Get my public GnuPG key from http://keyserver.veridis.com:11371/export?id=7574690260641978351

2 2

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