wine-devel

wine-devel@winehq.org

84463 discussions

Re: wine/memory virtual.c
by Alexandre Julliard 25 Oct '01

25 Oct '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Well, though I haven't tested it yet (working on other stuff right now), > if it works for you, it'll work for me. I haven't really tested it either, but I'll commit it and we'll see... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wine/memory virtual.c
by Alexandre Julliard 25 Oct '01

25 Oct '01

Alexandre Julliard <julliard(a)winehq.com> writes: > It's used at least in debug events, so yes it's possible that the > debugger will try to use the handle to read the file. Probably better > to close it completely when on removable media; and we'll need to do > this for dlls too. I'll try to come up with something. OK how about this? Index: loader/pe_image.c =================================================================== RCS file: /opt/cvs-commit/wine/loader/pe_image.c,v retrieving revision 1.99 diff -u -r1.99 pe_image.c --- loader/pe_image.c 2001/10/02 17:49:20 1.99 +++ loader/pe_image.c 2001/10/24 19:39:21 @@ -667,6 +667,12 @@ if (nt->FileHeader.Characteristics & IMAGE_FILE_DLL) { + if (hFile) + { + UINT drive_type = GetDriveTypeA( wm->short_filename ); + /* don't keep the file handle open on removable media */ + if (drive_type == DRIVE_REMOVABLE || drive_type == DRIVE_CDROM) hFile = 0; + } SERVER_START_REQ( load_dll ) { req->handle = hFile; Index: scheduler/process.c =================================================================== RCS file: /opt/cvs-commit/wine/scheduler/process.c,v retrieving revision 1.162 diff -u -r1.162 process.c --- scheduler/process.c 2001/10/03 18:40:10 1.162 +++ scheduler/process.c 2001/10/24 19:39:22 @@ -327,6 +327,17 @@ lstrcpynA( main_exe_name, full_argv0, sizeof(main_exe_name) ); } + if (main_exe_file) + { + UINT drive_type = GetDriveTypeA( main_exe_name ); + if (drive_type == DRIVE_REMOVABLE || drive_type == DRIVE_CDROM) + { + /* don't keep the file handle open on removable media */ + CloseHandle( main_exe_file ); + main_exe_file = 0; + } + } + /* Retrieve entry point address */ entry = (LPTHREAD_START_ROUTINE)((char*)current_process.module + PE_HEADER(current_process.module)->OptionalHeader.AddressOfEntryPoint); Index: server/process.c =================================================================== RCS file: /opt/cvs-commit/wine/server/process.c,v retrieving revision 1.70 diff -u -r1.70 process.c --- server/process.c 2001/07/14 00:50:30 1.70 +++ server/process.c 2001/10/24 19:39:22 @@ -788,8 +788,9 @@ /* signal the end of the process initialization */ DECL_HANDLER(init_process_done) { - struct file *file; + struct file *file = NULL; struct process *process = current->process; + if (!process->init_event) { fatal_protocol_error( current, "init_process_done: no event\n" ); @@ -798,11 +799,10 @@ process->exe.base = req->module; process->exe.name = req->name; - if (req->exe_file && (file = get_file_obj( current->process, req->exe_file, GENERIC_READ ))) - { - if (process->exe.file) release_object( process->exe.file ); - process->exe.file = file; - } + if (req->exe_file) file = get_file_obj( current->process, req->exe_file, GENERIC_READ ); + if (process->exe.file) release_object( process->exe.file ); + process->exe.file = file; + generate_startup_debug_events( current->process, req->entry ); set_event( process->init_event ); release_object( process->init_event ); -- Alexandre Julliard julliard(a)winehq.com

2 1

ddraw fullscreen-app problem in latest CVS
by TAKESHIMA Hidenori 25 Oct '01

25 Oct '01

I can run some full-screen app in 2001/10/20 cvs. but, in the latest cvs, wine may crash in creating the fullscreen-primary surface... (I don't know why, but since wine-server protocol has been updated?????) ddrawtst.c is a minimal test program that crashes the latest cvs. My environment is: debian2.3-woody, XFree86-4.1.0-7. No permission to access /dev/kmem directly.

1 0

Re: Registry: Recursive key delete patch
by Gerard Patel 24 Oct '01

24 Oct '01

At 02:52 PM 24/10/2001 -0400, you wrote: > > This patch permits the recursive deletion of registry >keys that also contain subkeys. <snip> I think that the MSDN article about RegDeleteKey states that this is a win9x specific behaviour. Gerard

1 0

Re: ptrace differences in kernel 2.4.7
by Alexandre Julliard 24 Oct '01

24 Oct '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > well, you said the error was 5 (EIO), so this EPERM stuff > shouldn't be in cause No, 5 is the Windows code (ERROR_ACCESS_DENIED), which is what EPERM translates to. -- Alexandre Julliard julliard(a)winehq.com

1 0

IS6: Problem in ITypeInfo_fnGetContainingTypeLib
by Uwe Bonnes 24 Oct '01

24 Oct '01

Hallo, after clearing up my home brewn problems I tried the IS6 installer for Analog Devices Visual DSP one more time. No it proceeds much longer but crashes in ITypeInfo_fnGetContainingTypeLib trace:ole:SysAllocStringLen => 0x4043ac28 L"Comcat" trace:ole:SysAllocStringLen => 0x40452894 L"" trace:ole:SysFreeString (L"Comcat") trace:ole:VariantClear (0x41576850) <repeated with several adresses> trace:ole:VariantClear (0x415767e0) trace:ole:SysAllocStringLen => 0x4043ac28 L"<Data>" trace:ole:SysAllocStringLen => 0x4042d044 L"" trace:ole:SysFreeString (L"<Data>") trace:ole:SysFreeString (L"") trace:ole:PSOAStub_Invoke invoked method returned with HRESULT 00000000 trace:ole:TL_Marshal Marshaling 0x41576c40 trace:ole:ITypeInfo_fnGetNames (0x4041753c) memid=0x00000014 Maxname=16 trace:ole:SysAllocStringLen => 0x4043ac28 L"OpenCAB" trace:ole:SysAllocStringLen => 0x4043a174 L"File" trace:ole:SysAllocStringLen => 0x40436f24 L"pVal" trace:ole:SysFreeString (L"OpenCAB") trace:ole:TL_Marshal parameter 0 trace:ole:TL_Marshal name : L"File" trace:ole:SysFreeString (L"File") trace:ole:TL_Marshal type : 8 trace:ole:TL_Marshal flags : 01 trace:ole:TL_CleanupType freeing BSTR 0x40409fe4 trace:ole:SysFreeString (L"J:\\ad-vdsp\\ADI\\data1.hdr") trace:ole:TL_Marshal parameter 1 trace:ole:TL_Marshal name : L"pVal" trace:ole:SysFreeString (L"pVal") trace:ole:TL_Marshal type : 26 trace:ole:TL_Marshal flags : 0a trace:ole:TL_MarshalType dereferencing PTR 0x40415908 <= 0x41576c48 trace:ole:TL_MarshalType dereferencing PTR 0x41104844 <= 0x40415908 trace:ole:TL_MarshalType reftype: 2 wine: Unhandled exception, starting debugger... WineDbg starting... on pid 96ef3a0 <..>. No debug information in 32bit DLL 'X11DRV.DLL' (0x40ac2000) Unhandled exception: page fault on read access to 0x00000004 in 32-bit code (0x40a653f5). In 32-bit mode. 0x40a653f5 (ITypeInfo_fnGetContainingTypeLib+0x35 [typelib.c:4303] in liboleaut32.so): movl 0x4(%edx),%eax 4303 ITypeLib2_AddRef(*ppTLib); Wine-dbg>bt bt Backtrace: =>0 0x40a653f5 (ITypeInfo_fnGetContainingTypeLib+0x35(iface=0x4041753c, ppTLib=0x41576a38, pIndex=0x41576a3c) [typelib.c:4303] in liboleaut32.so) (ebp=41576a10) 1 0x40a6518d (ITypeInfo_fnGetRefTypeInfo+0xed(iface=0x4041753c, hRefType=0x2, ppTInfo=0x41576a70) [typelib.c:4209] in liboleaut32.so) (ebp=41576a40) 2 0x40a587e8 (TL_MarshalType+0x358(pStm=0x40409e38, pInfo=0x4041753c, pType=0x404178fc, args=0x41104844, first=0x0, is_iid=0x41576d18) [proxy.c:206] in liboleaut32.so) (ebp=41576a8c) 3 0x40a58729 (TL_MarshalType+0x299(pStm=0x40409e38, pInfo=0x4041753c, pType=0x404178b4, args=0x40415908, first=0x0, is_iid=0x41576d18) [proxy.c:181] in liboleaut32.so) (ebp=41576ae4) 4 0x40a58729 (TL_MarshalType+0x299(pStm=0x40409e38, pInfo=0x4041753c, pType=0x40417898, args=0x41576c48, first=0x0, is_iid=0x41576d18) [proxy.c:181] in liboleaut32.so) (ebp=41576b3c) 5 0x40a58e8a (TL_Marshal+0x24a(pStm=0x40409e38, pInfo=0x4041753c, pDesc=0x40417800, dwFlag=0x2, args=0x41576c48, res=0x0, is_iid=0x41576d18, id=0x41576d18) [proxy.c:358] in liboleaut32.so) (ebp=41576bc4) 6 0x40a5a249 (PSOAStub_Invoke+0x779(iface=0x40416e24, pMsg=0x41576d60, pChannel=0x40409d0c) [proxy.c:778] in liboleaut32.so) (ebp=41576d28) 7 0x409a219e (LRPC_process+0xce(chan=0x40409d0c) [compobj.c:1167] in libole32.so) (ebp=41576da0) 8 0x409a247f (LRPC_feed+0x23f(lClass=0x40408bd4, hPipe=0x58) [compobj.c:1245] in libole32.so) (ebp=41576e34) 9 0x409a25e0 (LRPC_server_thread+0x130(the_arg=0x40408bd4) [compobj.c:1269] in libole32.so) (ebp=41576f1c) 10 0x400e0cf8 (THREAD_Start+0x98 [thread.c:271] in libntdll.so) (ebp=41576f38) 11 0x400dfef8 (SYSDEPS_StartThread+0x38(teb=0x41587000) [sysdeps.c:72] in libntdll.so) (ebp=41576ff4) 12 0x40350baa (NTDLL.DLL.memcpy+0x5c64a in libc.so.6) (ebp=00000000) Can anything be done about that? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 3

Re: wine/memory virtual.c
by Alexandre Julliard 24 Oct '01

24 Oct '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Since main_exe_file is apparently never used again anyway after > init_process_done, I've simply used the following hack to close the .exe > file on the wineserver side, assuming the server file object only needs to > exist to detect sharing violations, not for actually ever accessing the > file again: It's used at least in debug events, so yes it's possible that the debugger will try to use the handle to read the file. Probably better to close it completely when on removable media; and we'll need to do this for dlls too. I'll try to come up with something. -- Alexandre Julliard julliard(a)winehq.com

1 0

ptrace differences in kernel 2.4.7
by Simon Britnell 24 Oct '01

24 Oct '01

Having reviewed the changelog for Linux 2.4.7, I find that the ptrace attach code was amalgamated from many architecture dependant files into one function : ptrace_attach. This function differs from previous functions on i386 in that it returns EPERM if: 1) task->mm is NULL 2) task->pid <= 1 3) !task->mm->dumpable whereas pre 2.4.7 was !task->dumpable Further investigation shows that dumpable has been moved from task_struct to mm_struct. My investigation has not been sufficient to determine the final cause, but most things can be overridden by CAP_SYS_PTRACE, which I'll look into tomorrow PM. G'night all. __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

2 1

InstallShield 6 - success
by Ove Kaaven 24 Oct '01

24 Oct '01

Apart from the two patches I just submitted to wine-patches, a stdole32.tlb from real Windows, and the registry entries in winedefault.reg, you need my interprocess com hacks, which I've now put on WineHQ: http://www.winehq.com/~ovek/install.diff The installation progress bar doesn't seem to display for some reason (might be a repaint issue or something else related to Alexandre's latest work, or something completely different, don't know), but anyway, even if it doesn't tell you its progress, it actually successfully installs now! I hope I can get enough time to structure that interprocess com stuff properly, so that it can work the way MS designed it, which involves RPCRT4.dll and friends...

6 5

Re: wine/memory virtual.c
by Ove Kaaven 24 Oct '01

24 Oct '01

On Tue, 23 Oct 2001, Alexandre Julliard wrote: > Modified files: > memory : virtual.c > > Log message: > Try to use read instead of mmap for files on removable media, so that > we don't need to keep the mapping handle open. OK, I see that you did this part too, which I hadn't submitted yet... but there's still one thing missing; the .exe file is still open inside the wineserver, still having two outstanding references: - main_exe_file in scheduler/process.c - process->exe.file in server/process.c Since main_exe_file is apparently never used again anyway after init_process_done, I've simply used the following hack to close the .exe file on the wineserver side, assuming the server file object only needs to exist to detect sharing violations, not for actually ever accessing the file again: --- server/process.c 2001/03/05 22:55:56 1.1.1.9 +++ server/process.c 2001/10/19 16:40:52 1.4 @@ -802,6 +802,8 @@ { if (process->exe.file) release_object( process->exe.file ); process->exe.file = file; + /* close the unix file, so the media the file was on can be changed */ + remove_select_user( (struct object *)file ); } generate_startup_debug_events( current->process, req->entry ); set_event( process->init_event ); Maybe you have a better way to do it?

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel