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

(no subject)
by Andriy Palamarchuk Oct. 26, 2001

Oct. 26, 2001

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 Oct. 26, 2001

Oct. 26, 2001

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 Oct. 26, 2001

Oct. 26, 2001

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(a)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 Oct. 25, 2001

Oct. 25, 2001

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 Oct. 25, 2001

Oct. 25, 2001

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 Oct. 25, 2001

Oct. 25, 2001

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 Oct. 25, 2001

Oct. 25, 2001

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 Oct. 25, 2001

Oct. 25, 2001

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 Oct. 25, 2001

Oct. 25, 2001

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 Oct. 24, 2001

Oct. 24, 2001

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 Oct. 24, 2001

Oct. 24, 2001

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 Oct. 24, 2001

Oct. 24, 2001

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 Oct. 24, 2001

Oct. 24, 2001

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 Oct. 24, 2001

Oct. 24, 2001

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 Oct. 24, 2001

Oct. 24, 2001

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 Oct. 24, 2001

Oct. 24, 2001

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 Oct. 24, 2001

Oct. 24, 2001

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 Oct. 24, 2001

Oct. 24, 2001

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 Oct. 24, 2001

Oct. 24, 2001

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 Oct. 24, 2001

Oct. 24, 2001

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

Re: usleep in winmm/wineoss audio
by Simon Britnell Oct. 24, 2001

Oct. 24, 2001

--- eric pouech <eric.pouech(a)wanadoo.fr> wrote: > after, rereading my old code, there's nothing wrong > (at first glance) here some invocations (like close, > reset) need to be synchronous > (the calling thread blocks until the rendering > thread is done with the message), some others (like > adding a wavehdr for play back) > are asynchronous, hence the difference I added a WaitForSingleObject late last PM as an experiment. The results were ... interesting. The first thing I noticed was that my problem attaching to the process went away, ie. winedbg started to work. The second thing that happened was that the problem I experience went from being intermittant to constant and now also invariably throws a page fault exception (in the same place it intermittantly threw an exception). Tracing back from that page fault is proving difficult as the page fault occurs with a value that's been stored on the heap at some prior point in the execution. Any tips for rapid location of where it's being stored? I suspect it's a null return from a wine system call. > so, back to square 1. can you at least trace the > program with > -debugmsg +wave (and still capture the hanging ?) Unfortunately, turning -debugmsg +wave on has so far made the problem go away. I'll have another couple of attempts this PM as its been quite intermittant. Also, it occurs to me to try -debugmsg +wave with the (broken) WaitForSingleObject patch I mentioned above. __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

3 8

Re: Shlwapi functions _29, _30, _31
by Alexandre Julliard Oct. 24, 2001

Oct. 24, 2001

"Guy L. Albertelli" <galberte(a)neo.lrun.com> writes: > I assume that the differences may be due to revisions of the Unicode > standard, but that is an assumption only. Yes, there are some differences between our Unicode tables and the Windows ones. It shouldn't really matter, and if it does it's easy to fix. The important thing is to make sure everything uses the tables in libwine_unicode so that there is only one place to fix if necessary. -- Alexandre Julliard julliard(a)winehq.com

1 0

Shlwapi functions _29, _30, _31
by Guy L. Albertelli Oct. 24, 2001

Oct. 24, 2001

Alexandre, Thank you for simplifing these functions when you committed them. I thought you might want to know that they do act slightly differently from the versions in the native shlwapi.dll (version 5.50.4807.2300): _29 (iswspace) - extra TRUE for 0x1680, 0x202f _30 (iswblank) - missing TRUE for 0x3000 _31 (iswpunct) - missing TRUE for 0x00aa, 0x00b5, 0x00bb, 0x0192, 0x05ba - extra TRUE for 0x02df, 0x02ea-0x02ee, 0x0346-0x034e, 0x0361, 0x0488-0x0489, 0x058a, 0x0591-0x05a1, 0x05a3-0x05af, 0x05c4, 0x0653-0x0655 (+ probably many more - I stopped comparing here). I assume that the differences may be due to revisions of the Unicode standard, but that is an assumption only. Guy Albertelli <<galberte(a)neo.lrun.com>>

1 0

Re: The big winsock patch
by Alexandre Julliard Oct. 23, 2001

Oct. 23, 2001

Francois Gouget <fgouget(a)free.fr> writes: > Make winsock.h and winsock2.h independent from the Unix headers > Make them compatible with both the Unix C headers and the MSVCRT > headers > Ensure compatibility with the Unix headers via the USE_WS_PREFIX macro > Add WINE_NOWINSOCK: prevents winsock.h from being included > from windows.h when defined > Add ws2tcpip.h, move definitions to the right header I don't like the WS_API preprocessor abuse. It would be much better to declare function prototypes and typedefs explicitly, even if it requires a bit more typing. Your solution makes it hard to find out what gets defined when, and will break tools that extract information from header files. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: mediatype patch
by Alexandre Julliard Oct. 23, 2001

Oct. 23, 2001

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Save a disk file's media type in the server object. OK for the storing part, but why do you return it in the get_file_info request? Shouldn't it rather be in something like get_mapping_info? -- Alexandre Julliard julliard(a)winehq.com

2 1