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

startrek voyager elite forces

by G.LeeJ

hi.. I thought for sure someone had this working in linux...i tried but it craps out with: ------- error occured during move data porcess:13 Component: Program Files File Group:Program Files File:M:\setup\efgamesx86.dll but hey I was impressed as I had sounds working in install...:) thx for any help :) lee -===

Oct. 24, 2001

Re: wine/memory virtual.c

by Ove Kaaven

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?

Oct. 24, 2001

Re: Latest in the homeworld/wineoss saga.

by Simon Britnell

--- Ove Kaaven <ovehk(a)ping.uio.no> wrote: > Well, since you know that it uses dsound, i.e. not > waveout directly, why not add +dsound to the > debugmsg command, and look for bugs in Wine's > dsound implementation? Good call, I'll try that tonight. I'm going into hospital for n days tomorrow for surgery ( 1<n<5), so my follow up post will be delayed a little. > Also, perhaps check that the bug isn't already > fixed in WineX, since there may be bugfixes in > WineX not yet submitted to Wine. I'm actually running winex from the sourceforge cvs. I've subscribed to transgaming too, although the website doesn't acknowledge my worldpay transaction yet. I'm currently also examining a ptrace failure which is making it difficult to debug wine and mulling over the nature of the failure in hope of some insight about how it's failing. I think I need to examine the wineserver scheduling more closely as the hang I mentioned is a CPU busy hang involving wineserver and two wine processes. __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

Oct. 24, 2001

Re: IS6: Problem in ITypeInfo_fnGetContainingTypeLib

by Uwe Bonnes

>>>>> "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: 2890181 08069d78:Ret kernel32.HeapFree() retval=00000001 ret=40940358 2890182 trace:ole:ITypeInfo_fnReleaseFuncDesc (0x40433d6c)->(0x4043409c) 2890183 trace:ole:ITypeInfo_fnRelease (0x40433d6c)->(2) 2890184 08069d78:Call kernel32.FindResourceExA(00400000,00000006,00000901,00000009) ret=00403f97 2890185 08069d78:Ret kernel32.FindResourceExA() retval=00000000 ret=00403f97 2890186 08069d78:Call kernel32.FindResourceExA(00400000,00000006,00000901,00000409) ret=00403fb5 2890187 08069d78:Ret kernel32.FindResourceExA() retval=00408648 ret=00403fb5 2890188 08069d78:Call kernel32.LoadResource(00400000,00408648) ret=00403fd9 2890189 08069d78:Ret kernel32.LoadResource() retval=0040cbe0 ret=00403fd9 2890190 08069d78:Call oleaut32.SysFreeString(00000000) ret=0040401f 2890191 08069d78:Ret oleaut32.SysFreeString() retval=00000000 ret=0040401f 2890192 08069d78:Call oleaut32.SysAllocString(0040d10a L"Setup failed to run installation:") ret=00404026 2890193 08069d78:Call kernel32.lstrlenW(0040d10a L"Setup failed to run installation:") ret=409b36ce 2890194 08069d78:Ret kernel32.lstrlenW() retval=00000021 ret=409b36ce 2890195 08069d78:Call kernel32.HeapAlloc(403a0000,00000000,00000048) ret=409b381c 2890196 08069d78:Ret kernel32.HeapAlloc() retval=415e33e4 ret=409b381c 2890197 trace:ole:SysAllocStringLen => 0x415e33e8 L"Setup failed to run installation:" 2890198 08069d78:Ret oleaut32.SysAllocString() retval=415e33e8 ret=00404026 2890199 08069d78:Call ntdll.RtlUnwind(40616f40,004050ac,00000000,00000000) ret=004050ac 2890200 096fbf68:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000001 ret=406fa09d 2890201 096fbf68:Call x11drv.MsgWaitForMultipleObjectsEx(00000000,00000000,00000000,00000000,00000000) ret=406f9d70 Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Oct. 24, 2001

Re: IS6: Problem in ITypeInfo_fnGetContainingTypeLib

by Ove Kaaven

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 Try Malte's typelib refcounting patch, somewhere on wine-patches.

Oct. 24, 2001

Re: Latest in the homeworld/wineoss saga.

by Ove Kaaven

On Wed, 24 Oct 2001, Simon Britnell wrote: > I've run -debugmsg +wave with and without the > synchronous wodWrite patch. The results are fairly > large so I won't send them unless you feel they're > particularly useful. Well, since you know that it uses dsound, i.e. not waveout directly, why not add +dsound to the debugmsg command, and look for bugs in Wine's dsound implementation? Also, perhaps check that the bug isn't already fixed in WineX, since there may be bugfixes in WineX not yet submitted to Wine.

Oct. 24, 2001

IS6: Problem in ITypeInfo_fnGetContainingTypeLib

by Uwe Bonnes

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 ----------

Oct. 24, 2001

Re: InstallShield 6 - success

by Duane Clark

Uwe Bonnes wrote: >>>>>>"Uwe" == Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >>>>>> > > ... > Uwe> Is this problem IS6 related? > > To follow up my own question: This problem doesn't seem IS6 related. I have > other programms hanging in the splash screen with this > MsgWaitForMultipleObjectsEx pattern that ran before. > > I checked for the patches in my tree, and none of them seems related to taht > problems. Do other people see this problem? > > Bye >

Oct. 24, 2001

Re: Lindows

by Bill Medland

"Uwe Bonnes" <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote in message news:15318.41605.821621.615884(a)hertz.ikp.physik.tu-darmstadt.de... > Hallo, > > does anybody know more about "Lindows" than the sparse information they > annouce on their webpage and the press releases? > > I don't think they reimplemented the win32 api, so I guess they use wine > code. According to LinuxToday, Yes they are basing it on Wine. Navigate from Lindows.com and they have a load of press stuff at the bottom of the page. Bill

Oct. 24, 2001

datacache bug

by giorgian

hi all, as i wrote few days ago, there's a problem with the DataCache_GetAdvise function in dlls/ole32/datacache.c: the call (this->sinkInterface)->lpVtbl->QueryInterface(this->sinkInterface, &IID_IAdviseSink, (void**)ppAdvSink); crashes since this->sinkInterface is NULL. executing the program with the --debugmsg +relay option i've seen that there are no calls to DataCache_SetAdvise before this call, the sinkInferface field is not initialized. but the program works well under M$window$. looking here and there in the source, i tried to replace this call with this->lpvtbl2->QueryInterface(this->lpvtbl2, &IID_IAdviseSink, (void**)ppAdvSink); i don't know why, but it works. ok, what should i do now to let the world know this? thanks -- Pietro Giorgianni, Icube s.r.l. (via Ridolfi, 15 - Pisa (Italy)) giorgian(a)icube.it

Oct. 24, 2001

Lindows

by Uwe Bonnes

Hallo, does anybody know more about "Lindows" than the sparse information they annouce on their webpage and the press releases? I don't think they reimplemented the win32 api, so I guess they use wine code. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Oct. 24, 2001

Re: InstallShield 6 - success

by Uwe Bonnes

>>>>> "Ove" == Ove Kaaven <ovehk(a)ping.uio.no> writes: Ove> Apart from the two patches I just submitted to wine-patches, a Ove> stdole32.tlb from real Windows, and the registry entries in Ove> winedefault.reg, you need my interprocess com hacks, which I've now Ove> put on WineHQ: http://www.winehq.com/~ovek/install.diff These two patches have been aplied now, if I read wine-cvs right. Ove> The installation progress bar doesn't seem to display for some Ove> reason (might be a repaint issue or something else related to Ove> Alexandre's latest work, or something completely different, don't Ove> know), but anyway, even if it doesn't tell you its progress, it Ove> actually successfully installs now! Ove> I hope I can get enough time to structure that interprocess com Ove> stuff properly, so that it can work the way MS designed it, which Ove> involves RPCRT4.dll and friends... I patched with the file above on a recent CVS tree. Trying to run the installer for the Analog Devices Visual DSP, the process hangs with unrefreshed areas. 1853 096ed958:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,404007dc,ffffffff,00000000,00000000) ret=406fa09d 1854 08069d78:Ret kernel32.GetFileAttributesA() retval=00000020 ret=4001fabb 1855 08069d78:Call kernel32.GetTempFileNameA(40616270 "C:\\Programme\\Gemeinsame Dateien\\InstallShield\\engine\\6\\Intel 32\\ 1855 ",40021d39 "ver",00000000,40615a70) ret=4001fba4 1856 08069d78:Ret kernel32.GetTempFileNameA() retval=000096a5 ret=4001fba4 1857 08069d78:Call kernel32.OpenFile(40615a70 "C:\\Programme\\Gemeinsame Dateien\\InstallShield\\engine\\6\\Intel 32\\ver96a5.tmp",406158e4,00001000) ret=4001fbe3 1858 08069d78:Ret kernel32.OpenFile() retval=00000048 ret=4001fbe3 1859 08069d78:Call lz32.LZCopy(00000400,00000048) ret=4001fc0d 3386 08069d78:Call kernel32._lread(00000044,40403dd0,00000800) ret=404f7284 3387 096ed958:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000001 ret=406fa09d 3388 096ed958:Call x11drv.MsgWaitForMultipleObjectsEx(00000000,00000000,00000000,00000000,00000000) ret=406f9d70 3389 096ed958:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000102 ret=406f9d70 3390 096ed958:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,404007dc,ffffffff,00000000,00000000) ret=406fa09d 3391 096ed958:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000001 ret=406fa09d 3392 096ed958:Call x11drv.MsgWaitForMultipleObjectsEx(00000000,00000000,00000000,00000000,00000000) ret=406f9d70 3393 096ed958:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000102 ret=406f9d70 3394 096ed958:Call window proc 0x40a34000 (hwnd=00010020,msg=WM_NCHITTEST,wp=00000000,lp=00560017) 3395 096ed958:Ret window proc 0x40a34000 (hwnd=00010020,msg=WM_NCHITTEST,wp=00000000,lp=00560017) retval=00000001 3396 096ed958:Call window proc 0x40a34000 (hwnd=00010020,msg=WM_SETCURSOR,wp=00010020,lp=02000001) 3397 096ed958:Ret window proc 0x40a34000 (hwnd=00010020,msg=WM_SETCURSOR,wp=00010020,lp=02000001) retval=00000236 3398 096ed958:Call window proc 0x40a34000 (hwnd=00010020,msg=WM_MOUSEMOVE,wp=00000000,lp=00560017) 3399 096ed958:Ret window proc 0x40a34000 (hwnd=00010020,msg=WM_MOUSEMOVE,wp=00000000,lp=00560017) retval=00000000 3400 096ed958:Call x11drv.MsgWaitForMultipleObjectsEx(00000000,00000000,00000000,00000000,00000000) ret=406f9d70 3401 096ed958:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000102 ret=406f9d70 The x11drv.MsgWaitForMultipleObjectsEx seems to loop forever. There are several temp file with exactly the same size from former runs Is this problem IS6 related? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Oct. 24, 2001

ptrace differences in kernel 2.4.7

by Simon Britnell

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

Oct. 24, 2001

Latest in the homeworld/wineoss saga.

by Simon Britnell

I've attacked homeworld for a couple of hours with IDA free and none of the places that set the value of the NULL pointer are remotely close to a waveOutWrite call. I've run -debugmsg +wave with and without the synchronous wodWrite patch. The results are fairly large so I won't send them unless you feel they're particularly useful. To summarise: Both have 2 wodOpen calls. Both produce "Oooch buffer underrun" messages. The synchronous wodWrite version does only one wodWrite and a large number of Oooch messages. The asynchronous one produces one Oooch per wodWrite. Here's a more detailed description of the fault, followed by a couple of ideas on what's really going wrong: -- DESCRIPTION OF STARTUP -- The game starts with a 2D animated Sierra online logo followed by an animated relic logo and then drops into the game menus which are 2D graphics. mode. There are 3 distinct behaviours by the game: 1) Immediately prior to playing the Sierra logo, the game produces an exception report complaining of a page fault referencing 0x0000000. The animation starts and plays behind the exception dialog, but there is no sound. If the exception dialog is ignored, it disappears when the game menu is drawn. The menus can be navigated until either the graphics mode is changed or the actual game is started at which time wine hangs. top shows 30% of CPU taken by each of two wine processes and a wineserver. Tracing with remote gdb shows WaitForSingleObject in the stack traces, when they can be seen (Usually by running gdb as root). I usually have trouble getting the correct symbols loaded. 2) As per (1) above, but no exception dialog appears. 3) The game starts and runs with sound. There is no hang. While writing this, I had an idea. More to follow in a later post :) __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

Oct. 24, 2001

Re: PATCH: revert version change

by Francois Gouget

Here is a patch based on the information I got from WinMe and WinXP. It adds support for both, fixes the 16bit version of Win2000 and confirms its other values from SP2. I also updated the comment about the various versions of Win95 and changed the CSDVersion field to match their Windows values. Could people check and complete this info, especially for Win95sp1 (950a) and the various Win95osr2. Also if anyone knows how to check the dos version reported by NT... Here is the info I collected here: Win95: GetVersion16= 0x5f03 GetVersion: version = 0xc0000004 GetVersionInfoEx: size = 148 major = 4 minor = 0 build = 0x40003b6 platform = VER_PLATFORM_WIN32_WINDOWS CSDVersion= "" Win98: GetVersion16=0x5f03 GetVersion: version = 0xc0000a04 GetVersionInfoEx: size = 148 major = 4 minor = 10 build = 0x40a07ce platform = VER_PLATFORM_WIN32_WINDOWS CSDVersion= " " Win98SE: GetVersion16= 0x5f03 GetVersion: version = 0xc0000a04 GetVersionInfoEx: size = 148 major = 4 minor = 10 build = 0x40a08ae platform = VER_PLATFORM_WIN32_WINDOWS CSDVersion= " A " WinMe: GetVersion16= 0x5f03 GetVersion: version = 0xc0005a04 GetVersionInfoEx: size = 148 major = 4 minor = 90 build = 0x45a0bb8 platform = VER_PLATFORM_WIN32_WINDOWS CSDVersion= " " NT40sp5: GetVersion16= 0xa03 GetVersion: version = 0x05650004 GetVersionInfoEx: size = 148 major = 4 minor = 0 build = 0x565 platform = VER_PLATFORM_WIN32_NT CSDVersion= "Service Pack 5" NT40sp6: GetVersion16= 0xa03 GetVersion: version = 0x05650004 GetVersionInfoEx: size = 148 major = 4 minor = 0 build = 0x565 platform = VER_PLATFORM_WIN32_NT CSDVersion= "Service Pack 6" Win2000sp2: GetVersion16= 0x5f03 GetVersion: version = 0x08930005 GetVersionInfoEx: size = 148 major = 5 minor = 0 build = 0x893 platform = VER_PLATFORM_WIN32_NT CSDVersion= "Service Pack 2" WinXP: GetVersion16= 0x5f03 GetVersion: version = 0x0a280105 GetVersionInfoEx: size = 148 major = 5 minor = 1 build = 0xa28 platform = VER_PLATFORM_WIN32_NT CSDVersion= "" -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?

Oct. 24, 2001