wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

wine nolonger accepts mIRC dcc's
by mdew 27 Oct '01

27 Oct '01

when someone attempts to send you a file... i receive this in my status window. [06:12] DCC Get of sample_files.zip from Joe_dude: * Break: at one stage, wine+mirc did work..

1 1

WINE and Haxial programs
by haxial 27 Oct '01

27 Oct '01

Hi There My company produces a few programs that run on Windows and MacOS. Some of the users of these programs have been experimenting using WINE to run the programs on Linux. This is what they have been saying: "the KDX server runs FLAWLESSLY, 100% perfect, better than solitaire runs" However, there is one caveat to the above: I'm told that text input doesn't work when running KDX using WINE on Linux. I was wondering if I would be able to work with WINE developers in making KDX run perfectly on Linux using WINE. I think you would find this to be an easier task than usual because KDX only uses a *minimal* amount of windoze APIs. For example, KDX implements it's own GUI, it does not use the windoze API for that. Also, KDX even implements it's own graphics routines, it does not use the windoze GDI functions (except for the final step of getting the images onto the screen). KDX loads no obscure DLL's, it's just a single .exe file. It does not use MDI or any crap like that. It does not access the registry. It does not use MFC. So I think it would be much easier for WINE than your average windoze program. Which probably explains why it's already running well, except there is some bug, probably a minor little thing, that is preventing text input from working. The website is: http://www.haxial.com Thanks.

1 0

ReadFile behaviour on COMs
by Mike McCormack 27 Oct '01

27 Oct '01

Hey Uwe, There is still a number of problems with the COMM code that i am slowly fixing. They are: * comm ports opened without FILE_FLAG_OVERLAPPED don't use (any) read and write timeouts (patch in the works) * comm timeouts don't work 100% correctly * WaitCommEvent only works for EV_RXCHAR (difficult to solve correctly) Sounds like your problem might be related to #2. There are a few special cases for the values in the COMMTIMEOUTS structure that aren't being dealt with at the moment. Could you please post a -debugmsg +file,+comm trace and i'll have a look at it on Monday. Additionally, if the software is available online somewhere, please post a link to it. Mike ps. when you say the right byte, you mean the first byte, right? > Hallo, > > somebody showed me an application speaking to a device > connected to the serial port. The application failed after some > successfull communication steps. As the protocoll is available > in some other (open source programm) we could see that the > program requested two bytes from the device , but ReadFile only > delivered one byte (with that byte beeing the right one of the > expected two byte sequence). > > I suspect ReadFile to be the culprit. While the api description > tells to read all requested bytes ( beside of real errors), our > implementation happilies returns fewer bytes than requested. In > the case of COM devices, all timeouts of the SetCommTimeout > structure should be checked two. > > Anyone with an implementaion for that? > > Bye > -- > Uwe Bonnes ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

problem with virtualdub.
by Roger Fujii 26 Oct '01

26 Oct '01

there seems to be a funky problem with virtualdub (http://virutaldub.sourceforge.net). Get differing results between solaris and linux, but both seems to fail before the app comes up. Under solaris, it seems like something is screwed up with the loader - when it tries to load the binary, it dies in dump_exports because what's at pe_exports is just garbage. Not sure where it's dying under linux (probably the same place) - don't have a devel environment there (yet). Nothing unusual seems to happen before it gets there (both solaris/linux binaries run sol.exe and other stuff just fine). My suspicion is that the IMAGE_DIRECTORY_ENTRY_EXPORT data isn't pointing to what wine thinks is there, but would like someone who knows more about the loader to say something.... can anyone help shed more light onto this? -r

1 0

Re: none
by Alexandre Julliard 26 Oct '01

26 Oct '01

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Ok, how about this: > Each system parameter has "is_loaded" flag which shows > whether the parameter is loaded or not. Parameters, > stored directly in SysParametersInfo are loaded from > registry only when they are requested and the flag is > "false", after the loading the flag is set to "true". > On interprocess notification of the parameter change > the corresponding parameter flag is set to "false". > The parameter will be reloaded when it is requested > the next time. Yes, something like this would work. > Are there any existing implementations of > communication between Wine processes I can use as an > example? You want to use some variant of SendMessage in this case, probably a broadcast SendNotifyMessage with an internal message code (adding a WM_WINE_ case in dlls/user/message.c). > Do you still think it is better don't affect X > settings from Wine? Yes. > While we are on this - what about other my patch - > "hello5.c"? It fixes a warning and an error message I > got when I tried to compile hello5.c. The error depends on the compiler version. You should check the DUMMYUNIONNAME defines if you want to make it work for all platforms. I'm not sure it's worth the trouble though. -- Alexandre Julliard julliard(a)winehq.com

1 0

(no subject)
by Andriy Palamarchuk 26 Oct '01

26 Oct '01

Alexandre Julliard wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > >>Do you think it is better to do lazy loading for most >>parameters? >> > > Yes definitely. Ok, how about this: Each system parameter has "is_loaded" flag which shows whether the parameter is loaded or not. Parameters, stored directly in SysParametersInfo are loaded from registry only when they are requested and the flag is "false", after the loading the flag is set to "true". On interprocess notification of the parameter change the corresponding parameter flag is set to "false". The parameter will be reloaded when it is requested the next time. Parameters, backed by GetSystemMetrics are processed differently. These parameters are always loaded. They are reloaded right away on interprocess change notification. We can't do lazy loading because GetSystemMetrics returns its values from system metrics array and we don't want to complicate this function. I'm going to implement the flags as a bit array. Index constants for this array will be defined separately. >>I'll think about it more. Originally I planned to >>broadcast change notification across processes and use >>the reload function in other process to refresh values >>from registry. The problem with this approach is when >>a parameter is changed without saving. >> > > A possibility could to create a volatile registry branch to save > parameters that aren't permanently saved. This way they would be > accessible from other processes. Thank you for the idea. Are there any existing implementations of communication between Wine processes I can use as an example? Disregard the patches "SystemParametersInfo / GetSystemMetrics", "SPI_GET/SETBORDER". I'll implement the discussed above changes and resubmit them. Do you still think it is better don't affect X settings from Wine? Please let me know. While we are on this - what about other my patch - "hello5.c"? It fixes a warning and an error message I got when I tried to compile hello5.c. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

1 0

ReadFile behaviour on COMs
by Uwe Bonnes 26 Oct '01

26 Oct '01

Hallo, somebody showed me an application speaking to a device connected to the serial port. The application failed after some successfull communication steps. As the protocoll is available in some other (open source programm) we could see that the program requested two bytes from the device , but ReadFile only delivered one byte (with that byte beeing the right one of the expected two byte sequence). I suspect ReadFile to be the culprit. While the api description tells to read all requested bytes ( beside of real errors), our implementation happilies returns fewer bytes than requested. In the case of COM devices, all timeouts of the SetCommTimeout structure should be checked two. Anyone with an implementaion for 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 ----------

1 0

(no subject)
by Mike McCormack 26 Oct '01

26 Oct '01

Hi Andreas, i had a bit more free time, so i tracked down the rendering problem in NetTerm a bit more. The problem occurs after SelectVisRgn16 is called with the same region as that currently selected in the DC. (eg. dc->hVisRgn == hrgn ). I made a dodgy patch to fix the problem by incrementing the reference count of the region in this case, but i don't know how to fix it properly, because i don't know much about region handling. With the dodgy patch, NetTerm's windows paints properly. Perhaps perhaps you or somebody has a better way to fix the problem? Mike Andreas Mohr wrote: > On Tue, Oct 09, 2001 at 11:35:39AM +1000, Mike McCormack wrote: > > > > Hi All, > > > > i'm trying to solve a comms problem in NetTerm > > http://www.securenetterm.com/ but i've run into another problem. > > > > The rendering in NetTerm fails almost completely. I > > Yep, I strongly suspect a reference count problem here, too. > ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: cursor visibility problem
by Alexandre Julliard 25 Oct '01

25 Oct '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > In Alexandre's new windowing architecture, we have in > dlls/x11drv/window.c, line 119, this: > > attr->cursor = X11DRV_GetCursor( display, GlobalLock16(GetCursor()) ); > > Problem: what if ShowCursor(FALSE) is called to hide the cursor *before* > the window was created? Yup, GetCursor still returns the current (arrow) > cursor, so the new window gets associated with a visible cursor, though > the app would expect the cursor to remain hidden. Yes, cursor handling has some problems right now. It also needs to be a lot more clever about setting the cursor on child windows, and not walk the full list of top-level windows on every SetCursor. It will be fixed eventually, but it's not my top priority right now. -- Alexandre Julliard julliard(a)winehq.com

1 0

cursor visibility problem
by Ove Kaaven 25 Oct '01

25 Oct '01

In Alexandre's new windowing architecture, we have in dlls/x11drv/window.c, line 119, this: attr->cursor = X11DRV_GetCursor( display, GlobalLock16(GetCursor()) ); Problem: what if ShowCursor(FALSE) is called to hide the cursor *before* the window was created? Yup, GetCursor still returns the current (arrow) cursor, so the new window gets associated with a visible cursor, though the app would expect the cursor to remain hidden. Diablo II is currently known to suffer from this problem... it has too many cursors visible. I haven't come up with a very clean solution to this... ideas?

1 0

winelib works only in debugmsg mode
by Guilherme Kunz 25 Oct '01

25 Oct '01

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

1 0

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

Latest in the homeworld/wineoss saga.
by Simon Britnell 24 Oct '01

24 Oct '01

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

2 2

Lindows
by Uwe Bonnes 24 Oct '01

24 Oct '01

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

2 1

datacache bug
by giorgian 24 Oct '01

24 Oct '01

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

1 0

Re: PATCH: revert version change
by Francois Gouget 24 Oct '01

24 Oct '01

On Tue, 23 Oct 2001, Marcus Meissner wrote: > Hi, > > There was following change to misc/version.c: > revision 1.44 > date: 2001/07/27 23:57:38; author: julliard; state: Exp; lines: +1 -1 > Bob Goodwin <goodie1(a)pacbell.net> > Fix the 16bit win95 version. > > This makes for instance InstallShield, that uses DOS3CALLs to check for win95, > report a Bad Windows Version. (Installer of Monkey Island 3) > > Reference wine-devel post is: > http://www.winehq.com/hypermail/wine-devel/2001/07/0085.html > > If there is a testprogram, I can still boot Windows 95... Ladislav Sladecek <lsla(a)post.cz> posted a program to check the 16bit version back in august: http://www.winehq.com/hypermail/wine-devel/2001/08/0275.html I think the revert is the right thing to do. And this is what I get on the Win95 computers I have access to. I also recently found that quite a few installers are not happy with 0x0304. I attached Ladislav's 16bit test application and also attached a application I wrote that dumps what the 32bit GetVersion and GetVersionEx return. Bob, how did you come up with 0x07000304? Was it from the Daggerfall application or from a windows computer? If the latter, then could you run the attached tests and report what the results? Here are the result of the tests I have done here: * Win95 (the original version): It does indeed return 0x5f03 in 16bit mode. The CSDVersion does not seem to match in 32bit mode: GetVersion: version = 0xc0000004 GetVersionInfoEx: size = 148 major = 4 minor = 0 build = 0x40003b6 platform = VER_PLATFORM_WIN32_WINDOWS CSDVersion= "" vs. "Win95" in Wine I don't know if this could cause problems. * Win98SE: Returns 0x5f03 in 16bit mode, like Wine. No problem in 16bit mode. In 32bit mode I get some discrepencies, probably because this is SE and not the original 98: GetVersion: version = 0xc0000a04 GetVersionInfoEx: size = 148 major = 4 minor = 10 build = 0x40a08ae vs. 0x40A07CE in Wine platform = VER_PLATFORM_WIN32_WINDOWS CSDVersion= " A " vs. "Win98" in Wine * NT4: Everything is fine. Tonight I hope to get results for Win2000 and WinXP. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

1 1

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