- Wine-Devel - list.winehq.org

Re: hhctrl: Load the default Url in the HTML Pane [take 2]
by James Hawkins Sept. 12, 2005

Sept. 12, 2005

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 Sept. 12, 2005

Sept. 12, 2005

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 Sept. 11, 2005

Sept. 11, 2005

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 Sept. 11, 2005

Sept. 11, 2005

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 Sept. 11, 2005

Sept. 11, 2005

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 Sept. 10, 2005

Sept. 10, 2005

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 Sept. 10, 2005

Sept. 10, 2005

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 Sept. 10, 2005

Sept. 10, 2005

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 Sept. 10, 2005

Sept. 10, 2005

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 Sept. 10, 2005

Sept. 10, 2005

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