October 2001 - Wine-Devel - list.winehq.org

winelib works only in debugmsg mode

by Guilherme Kunz

Hi, I have compiled a program with mfc using winemaker and when a run the program "./dlg" show a messagebox "Could not get address of WinMain", i am linking the mfc static mode. but when i run "./dlg --debugmsg +all &> debug.log" the program run right. gcc 2.96.85 kernel 2.2.19 Any idea ?? Thank you. Guilherme Kunz

Oct. 25, 2001

Re: wine/memory virtual.c

by Alexandre Julliard

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

Oct. 25, 2001

Re: wine/memory virtual.c

by Ove Kaaven

On 24 Oct 2001, Alexandre Julliard wrote: > 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? Well, though I haven't tested it yet (working on other stuff right now), if it works for you, it'll work for me.

Oct. 25, 2001

ddraw fullscreen-app problem in latest CVS

by TAKESHIMA Hidenori

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.

Oct. 25, 2001

Re: Registry: Recursive key delete patch

by Gerard Patel

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

Oct. 24, 2001

Re: wine/memory virtual.c

by Alexandre Julliard

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

Oct. 24, 2001

Re: ptrace differences in kernel 2.4.7

by Alexandre Julliard

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

Oct. 24, 2001

Re: IS6: Problem in ITypeInfo_fnGetContainingTypeLib

by Ove Kaaven

On Wed, 24 Oct 2001, Uwe Bonnes wrote: > >>>>> "Ove" == Ove Kaaven <ovehk(a)ping.uio.no> writes: > > Ove> On Wed, 24 Oct 2001, Uwe Bonnes wrote: > > >> 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 > > Ove> Try Malte's typelib refcounting patch, somewhere on wine-patches. > > After correcting pTypeLib into pTLib in Malte's patchh, Setup proceeded > much further. > > Then it reports a "Speicherschutzverletzung" (illegal memory access) and > freezes: When debugging InstallShield, it helps to add +seh to the debugmsg command line and look for recent thrown exceptions before the failure, and in particular it's fruitful to look for oleaut32 routines returning errors (retval=8xxxxxxx). But note that I have done several fixes to oleaut32 and stuff after testing several installers, most of these fixes are only in WineX CVS right now, I didn't have time to consider submitting them to Wine yet. As an example, this badness is necessary for two game installers I've tested: --- dlls/oleaut32/safearray.c 2001/10/04 13:43:59 1.1.1.8 +++ dlls/oleaut32/safearray.c 2001/10/16 17:33:01 1.3 @@ -356,7 +356,9 @@ *((BSTR*)pv) = pbstrReturnedStr; } else if( psa->fFeatures == FADF_VARIANT) { - HRESULT hr = VariantCopy(pv, elementStorageAddress); + HRESULT hr; + VariantInit(pv); + hr = VariantCopy(pv, elementStorageAddress); if (FAILED(hr)) { SafeArrayUnlock(psa); return hr;

Oct. 24, 2001

Re: wine/memory virtual.c

by Alexandre Julliard

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

Oct. 24, 2001

Re: ptrace differences in kernel 2.4.7

by eric pouech

Simon Britnell wrote: > > 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: well, you said the error was 5 (EIO), so this EPERM stuff shouldn't be in cause could try to strace the wineserver when the ptrace fails (it may should exactly what goes wrong) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Oct. 24, 2001