- wine-devel - winehq.org

Re: PATCH: wine_dbgstr_an()
by Andreas Mohr 17 Oct '01

17 Oct '01

On Tue, Oct 16, 2001 at 10:58:01PM +0200, Johan Gill wrote: > Relay tracing would crash if it came upon a function call with an invalid > pointer as a parameter. > + return "(invalid)"; Hmm, is there any reason why you just return "(invalid)" ? IMHO this can be very misleading, as some programs use strings such as "invalid", "NOT_VALID" or whatever to have something to compare against to check for a valid return. Furthermore it doesn't indicate at all that this string content originates from within wine due to an invalid function argument. I'd use something like: "WINE RELAY: invalid string pointer !" or so. And, even better, sprintf() the string pointer value into a static buffer to be used as a replacement, so that the output of this buffer looks like: "WINE RELAY: invalid string pointer 0x00045213 !". -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

Re:Pajama Sam 2 and other games
by Eric Pouech 16 Oct '01

16 Oct '01

regarding the sound issues, there still may be some races in the buffer playback. however, there's no specification of sound latency under windows (how many buffers shall be queued in advance to ensure proper playback...). So, there's no guarantee on Wine right now of the latency to expect (in fact, I assume that wine's latency may be higher that Windows one, however I didn't check it). Which means that some program may run fine under windows and have some "holes" in their playback under wine. However, what's less understandable is that the program hangs (or at least doesn't provide any new sound) could run the program with -debugmsg +wave,+mmsys and send me the compreseed output. (BTW, if you want to look at the code, it's in dlls/winmm/wineoss/audio.c) A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

1 0

Pajama Sam 2 and other games
by Ori Pessach 16 Oct '01

16 Oct '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I've been trying to run several games from Humongous Entertainment under wine 20011007, installed from an RPM. They run, except for a couple of problems: The first problem is that the sound pauses sometimes. While the sound is paused, the animation animation still plays. It seems like the introduction of a new sound into the mix makes it more likely for the sound to pause. Eventually, the sound will die completely, with the message: err:wave:wodPlayer_Message buffer overflow !? written to stdout. The game will halt at that point, hanging wine. At that point I can do a 'killall wine', and rerun it. The second problem is with the cursor: When you pick up an object, the games modify the cursor to a picture of the object. This doesn't work under wine, and the cursor just disappears. It reappears when you drop the object. The games seem to use the WaveOut API's to play sounds, and the background music is a PCM, not MIDI. From my days writing similar games, I remember that the only way to have low-latency sound mixing using WaveOut was to stop and restart the device, feeding it fresh buffers with the new sounds mixed in. If none of this rings a bell with anybody, I don't mind taking a look at the sound code, to try to figure out what's broken. The cursor problem probably has something to do with trying to create a cursor object from a color bitmap, but I'm just guessing. I'm not even sure what the cursor is supposed to look like, as I've never ran the games under Windows... Any ideas? Thanks, Ori Pessach -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7zG/wRWZDICaLP5ERAktsAKDLW/1hnRwJVfAExvOj24tMtvULogCg+RsA UcS6RDI6knfCr/yKeVYZVas= =zg/k -----END PGP SIGNATURE----- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

1 0

Re: wine/port.h #include fixes
by Roger Fujii 15 Oct '01

15 Oct '01

fgouget(a)codeweavers.com wrote: > Doing this (except for port.h) I have a tree that builds on Solaris > with no _FILE_OFFSET_BITS warning. So if the above sounds good, I have > patches that are almost ready. > does this build run on solaris? I've been trying for the last couple of days to get the beast to run (compiles ok), but it segfaults in various places (currently in NtCurrentTeb()). This in on a solaris 8 dual CPU unit. This is using gas/gld (results were worse with as/ld). Any pointers on debugging this thing? Thanks. -r -- Roger Fujii <rmf(a)lookhere.com> Underemployed, and trying to keep it that way....

2 2

Messy diff
by Johan Gill 15 Oct '01

15 Oct '01

I found that there were problems with --debugmsg=+relay when hitting a function call with an invalid pointer as parameter. wine_dbgstr_an() would try to dereference the pointer, resulting in a crash. Here's a patch for it. If anything is done the wrong way, please comment on it. /Johan Gill, johane(a)lysator.liu.se

1 0

RE: wine/port.h #include fixes
by Patrik Stridvall 15 Oct '01

15 Oct '01

> François Gouget wrote: > > > > This is a followup on the previous config.h patch, this > time tackling > > the wine/port.h case. > > Hmmm, I see it has been applied to CVS already. But I'm > not too happy > with it anymore :-/ > > I found a problem with 'dlls/winsock/async.c' and > 'dlls/winsock/socket.c' and the DELETE macro. > * DELETE is defined in winnt.h > * DELETE is also defined by a socket-related Solaris header > (arpa/nameser_compat.h, included indirectly) > * so winnt.h undefs DELETE and then defines our value Yes. That is a problem. ERR IIRC is another problem on Solaris. That is why #include "debugtools.h" is always done after all other includes. > * 'wine/port.h' includes 'winnt.h'. So if we include it > first and then > include the Solaris header we get a redefinition error. No it doesn't. At least not any longer. >From "cvs log include/wine.h": < revision 1.15 < date: 2001/07/26 21:43:29; author: julliard; state: Exp; lines: +1 -1 < Patrik Stridvall <ps(a)leissner.se> < Removed inclusion of winnt.h because the porting layer shouldn't < include Windows specific stuff. Note that as the comment says we shouldn't include Windows specific stuff in the porting layer. > One possible solution would be to handle DELETE differently, e.g. > prefix it in Wine, and not prefix it for Winelib, or something like > that. But wine/port.h is not the only header that needs to include > 'config.h'. There is also: > > cdrom.h console.h > ts_shape.h ts_xf86dga.h ts_xf86dga2.h ts_xf86vmode.h ts_xlib.h > ts_xpm.h ts_xresource.h ts_xshm.h ts_xutil.h ts_xvideo.h > wine_gl.h > x11drv.h > > I think it would be wrong to move all these #includes so that they > are first. Plus for the ts_*.h headers I am not sure it would be very > good. Also #including config.h in these is a bit pointless > since we know > that the file including them will need to include config.h too. Sounds reasonable. > So I propose the following instead: > * config.h has no multiple include protection. Add one > (__WINE_CONFIG_H > macro). > * modify the above headers so that they don't include config.h but > contain the following instead: > #ifndef __WINE_CONFIG_H > # error You must include config.h to use this header > #endif > This will make sure that no-one forgets to include config.h when > necessary. > * modify all files that include the above headers so that > they include > config.h as the first header. This actually requires relatively little > work. That is probably a good idea. > * do the same for port.h > * debugtools.h also uses config.h because it needs NO_DEBUG_MSGS and > NO_TRACE_MSGS. Modify configure.in so that these are put on > the command > line instead. They are not the of the same nature as the other macros > anyway: they are completely system independent. Also this will make it > possible to use the Wine debug macros in Winelib applications. Then > debugtools.h will no longer need to #include config.h. This cuts the > number of files causing trouble in about half. That is probably a good idea too. > * there are 3 other files that #include config.h for no good reason > that I can see: gdi.h, heap.h and thread.h. Remove the #includes from > there. Anyway, winapi_check ensures that all the .c files that need > config.h already include it directly. Yes. However that algoritm (or rather heuristics) that decide this is not perfect but it catch most of the cases and the compiler catches a few more and the linker most (all?) of the rest. > * maybe modify winapi_check to make sure that no header file includes > 'config.h' (this would be the frosting on the cake) This is easy. I will do that if Alexandre accept a patch what requires this. > Doing this (except for port.h) I have a tree that builds on Solaris > with no _FILE_OFFSET_BITS warning. So if the above sounds good, I have > patches that are almost ready. Ah. Good.

1 0

Re: wine/port.h #include fixes
by François Gouget 15 Oct '01

15 Oct '01

François Gouget wrote: > > This is a followup on the previous config.h patch, this time tackling > the wine/port.h case. Hmmm, I see it has been applied to CVS already. But I'm not too happy with it anymore :-/ I found a problem with 'dlls/winsock/async.c' and 'dlls/winsock/socket.c' and the DELETE macro. * DELETE is defined in winnt.h * DELETE is also defined by a socket-related Solaris header (arpa/nameser_compat.h, included indirectly) * so winnt.h undefs DELETE and then defines our value * 'wine/port.h' includes 'winnt.h'. So if we include it first and then include the Solaris header we get a redefinition error. One possible solution would be to handle DELETE differently, e.g. prefix it in Wine, and not prefix it for Winelib, or something like that. But wine/port.h is not the only header that needs to include 'config.h'. There is also: cdrom.h console.h ts_shape.h ts_xf86dga.h ts_xf86dga2.h ts_xf86vmode.h ts_xlib.h ts_xpm.h ts_xresource.h ts_xshm.h ts_xutil.h ts_xvideo.h wine_gl.h x11drv.h I think it would be wrong to move all these #includes so that they are first. Plus for the ts_*.h headers I am not sure it would be very good. Also #including config.h in these is a bit pointless since we know that the file including them will need to include config.h too. So I propose the following instead: * config.h has no multiple include protection. Add one (__WINE_CONFIG_H macro). * modify the above headers so that they don't include config.h but contain the following instead: #ifndef __WINE_CONFIG_H # error You must include config.h to use this header #endif This will make sure that no-one forgets to include config.h when necessary. * modify all files that include the above headers so that they include config.h as the first header. This actually requires relatively little work. * do the same for port.h * debugtools.h also uses config.h because it needs NO_DEBUG_MSGS and NO_TRACE_MSGS. Modify configure.in so that these are put on the command line instead. They are not the of the same nature as the other macros anyway: they are completely system independent. Also this will make it possible to use the Wine debug macros in Winelib applications. Then debugtools.h will no longer need to #include config.h. This cuts the number of files causing trouble in about half. * there are 3 other files that #include config.h for no good reason that I can see: gdi.h, heap.h and thread.h. Remove the #includes from there. Anyway, winapi_check ensures that all the .c files that need config.h already include it directly. * maybe modify winapi_check to make sure that no header file includes 'config.h' (this would be the frosting on the cake) Doing this (except for port.h) I have a tree that builds on Solaris with no _FILE_OFFSET_BITS warning. So if the above sounds good, I have patches that are almost ready. -- François Gouget fgouget(a)codeweavers.com

1 0

Re: [Fwd: file inheritance]
by Alexandre Julliard 13 Oct '01

13 Oct '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > this patch hasn't been committed yet > is there any issue Alexandre ? None, except that the patch conflicts with Mike's changes that I committed a few days ago. I was hoping you would submit an updated patch so I wouldn't have to merge it myself ;-) -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: olepicture.c patch
by Francois Gouget 13 Oct '01

13 Oct '01

Wouldn't this be better (do the trick inside the #ifdef HAVE_JPEGLIB_H): #ifdef HAVE_LIBJPEG /* This is a hack, so jpeglib.h does not redefine INT32 and the like*/ #define XMD_H #ifdef HAVE_JPEGLIB_H +# define UINT16 JPEG_UINT16 # include <jpeglib.h> +# undef UINT16 #endif #endif -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.

1 0

Re: added missing CloseHandle
by eric pouech 13 Oct '01

13 Oct '01

Kai Morich wrote: > > * dlls/shell32/shell.c > Kai Morich <mail(a)kai-morich.de> > InternalExtractIcon16 forgot to close file handle > > p.s. that's the reason why my last mail had no attachment, because the mailprogram couldn't open the still opened attachment file since we don't use the handle afterwards, it seems like OF_EXIST as a flag to OpenFile would be a much better way to handle this my 2 cents A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Re: Don't TRACE NULL strings
by Dmitry Timoshkov 13 Oct '01

13 Oct '01

"FranГois Gouget" <fgouget(a)codeweavers.com> wrote: > - TRACE("(%p %p %x)\n",pidl,szOut,uOutSize); > + TRACE("(%p %p %x)\n",pidl,debugstr_a(szOut),uOutSize); ^^ ^^^^^^^^^^^^^^^^^ Please recheck for pointer format vs. string argument mismatches. -- Dmitry.

1 0

Re: PATCH: Fix LoadCursor() under win9x
by Marcus Meissner 13 Oct '01

13 Oct '01

On Fri, Oct 12, 2001 at 03:16:04PM +0200, Johan Gill wrote: > LoadCursor() should return 0 if we emulate win9x and the second parameter > is an invalid pointer. > + if (HIWORD(name)) > + if (GetVersion() & 0x80000000) /* win9x */ > + if (IsBadReadPtr(name, 4)) > + return 0; This code is unclean: It should not check for versions. It should not use IsBadReadPtr(), but IsBadStringPtrA(). It should not use IsBad* functions, but an exception handler. I would suggest the patch below. Ciao, Marcus Changelog: Handle bad pointer arguments to LoadImageA() (and functions calling LoadImageA) with an exception handler. Index: cursoricon.c =================================================================== RCS file: /home/wine/wine/windows/cursoricon.c,v retrieving revision 1.35 diff -u -r1.35 cursoricon.c --- cursoricon.c 2001/10/05 19:38:14 1.35 +++ cursoricon.c 2001/10/12 16:50:03 @@ -36,6 +36,7 @@ #include "wingdi.h" #include "wine/winbase16.h" #include "wine/winuser16.h" +#include "wine/exception.h" #include "heap.h" #include "palette.h" #include "bitmap.h" @@ -2174,14 +2175,29 @@ * FIXME: implementation lacks some features, see LR_ defines in winuser.h */ +/* filter for page-fault exceptions */ +static WINE_EXCEPTION_FILTER(page_fault) +{ + if (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION) + return EXCEPTION_EXECUTE_HANDLER; + return EXCEPTION_CONTINUE_SEARCH; +} + HANDLE WINAPI LoadImageA( HINSTANCE hinst, LPCSTR name, UINT type, INT desiredx, INT desiredy, UINT loadflags) { HANDLE res; LPWSTR u_name; - if (HIWORD(name)) u_name = HEAP_strdupAtoW(GetProcessHeap(), 0, name); - else u_name=(LPWSTR)name; + __TRY { + if (HIWORD(name)) u_name = HEAP_strdupAtoW(GetProcessHeap(), 0, name); + else u_name=(LPWSTR)name; + } + __EXCEPT(page_fault) { + SetLastError( ERROR_INVALID_PARAMETER ); + return 0; + } + __ENDTRY res = LoadImageW(hinst, u_name, type, desiredx, desiredy, loadflags); if (HIWORD(name)) HeapFree(GetProcessHeap(), 0, u_name); return res;

2 2

winemaker
by lawson_whitney＠juno.com 13 Oct '01

13 Oct '01

Good day! I like winemaker, but it frustrates me. Given a standard wine installation (from source in /oof/wine, ./configure, make depend && make, make install) and a little winelib program with a handmade .spec file in subdirectory wlp, and the command winemaker --nosource-fix --console --nogenerated-specs \ --single-target toj2 wlp why does it make a configure script that can find -lwine, but can not find -lntdll - ? They are both in /usr/local/lib ... checking whether we can build a Linux dll... yes checking whether we need to define __i386__... no checking for g++ -fpermissive option... yes checking for g++ -fno-for-scope option... yes checking for windef.h header... /usr/local/include/wine checking for -lwine... checking for libntdll.so... configure: error: Could not find the Wine dlls (libntdll.so) The Winelib program is responsible to bring you this letter, but I had to hand-hack some scripts to get it to compile. Well, it may take me a while, but you or I will solve it. Regards, Lawson ---oof---

2 6

Re: PATCH: Fix LoadCursor() under win9x
by Alexandre Julliard 12 Oct '01

12 Oct '01

Andreas Mohr <u4t5s0yq1001(a)sneakemail.com> writes: > Using your exception handler, LoadCursor() *always* returns 0 > on invalid parameter, which is WRONG in the NT 4 case > since it continues program execution without crashing. > > --> GetVersion() is required, check was (nearly) right IMHO. > Probably the best solution would be to use both an exception handler and > call GetVersion() on exception. Come on Andreas, we've been through this before. A version check must be added *only* when there is a real-life application that demonstrably depends on the version difference for proper behavior. So if you want the version check you'll have to show us an application that needs the crash in order to work right... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winebuild and circular DLL dependencies
by Alexandre Julliard 12 Oct '01

12 Oct '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > well, I think we need to differentiate two things: > - circular deps in normal imports > - circular refs of DLLs for delayed imports I consider that both are wrong. I think it's important to maintain proper layers and ensure that dll dependencies always go in one direction. Of course this is not always possible thanks to Microsoft design (or lack of it); but in the cases where we need to hack something I want it to be very explicit that something unusual is going on. If we make it so that any dll can easily import any other one, we'll quickly end up with an inextricable mess of cross-dll dependencies, simply because adding an import in the spec file for any dll that you may need is so much easier than having to use GetProcAddress and think about minimizing inter-dll calls because they are a pain to do. So there aren't really technical reasons we cannot do it, the issue is enforcing a structure by not making it too easy to do things the wrong way. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winebuild and circular DLL dependencies
by Alexandre Julliard 12 Oct '01

12 Oct '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Well, can this be done with delayed imports yet? I have a situation here > where ole32 imports stuff from rpcrt4 (windows uses delayed imports for > that), and rpcrt4 imports stuff from ole32 (again, windows uses delayed > imports). It would be nice if I could use the winebuild delayed import > mechanism to achieve this, instead of doing it manually with callout > tables and stuff... but I suppose winebuild has to be changed to read > the .spec files instead of using nm on compiled libraries... anyone > working on it? No, and I don't think it's a desirable feature, it's too error-prone. Besides, circular dependencies are really something to avoid, so it must not be too easy to do... (what does rpcrt4 need from ole32 BTW?) -- Alexandre Julliard julliard(a)winehq.com

3 2

BUG: mouse_event does not move pointer for relative coordinates
by Andriy P 12 Oct '01

12 Oct '01

The attached test program moves pointer under Windows NT. Under Wine the pointer changes position on move request in absolute coordinates and does not move for relative coordinates. I found out that variables PosX and PosY ARE updated in queue_mouse_event in windows/input.c. Can somebody give me a hint where to go from there? I don't see further any difference in processing between absolute and relative movement. In case somebody will fix this bug, don't worry about different relative distance reported under Windows and in Wine. I alredy fixed that part and will submit the patch soon. Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

1 0

Re:winebuild and circular DLL dependencies
by Eric Pouech 12 Oct '01

12 Oct '01

well, I must have this somewhere in my tree, but didn't publish it because Alexandre was somehow reluctant to use this type of features (not the reading of missing symbols from .spec files, but the circular deps). Alexandre, any "new" comments ? A+ > Well, can this be done with delayed imports yet? I have a situation here > where ole32 imports stuff from rpcrt4 (windows uses delayed imports for > that), and rpcrt4 imports stuff from ole32 (again, windows uses delayed > imports). It would be nice if I could use the winebuild delayed import > mechanism to achieve this, instead of doing it manually with callout > tables and stuff... but I suppose winebuild has to be changed to read > the .spec files instead of using nm on compiled libraries... anyone > working on it? > > > > --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

1 0

winebuild and circular DLL dependencies
by Ove Kaaven 12 Oct '01

12 Oct '01

Well, can this be done with delayed imports yet? I have a situation here where ole32 imports stuff from rpcrt4 (windows uses delayed imports for that), and rpcrt4 imports stuff from ole32 (again, windows uses delayed imports). It would be nice if I could use the winebuild delayed import mechanism to achieve this, instead of doing it manually with callout tables and stuff... but I suppose winebuild has to be changed to read the .spec files instead of using nm on compiled libraries... anyone working on it?

1 0

Re: Nasty Evil Memory Fragmentation fix
by Alexandre Julliard 11 Oct '01

11 Oct '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Not that much. Wine's allocator already implements the *features* of that > allocator (boundary tags, bins), it just doesn't implement all the > *strategies* used for selecting which free block to allocate memory from > (though the only big things we lack there is "best fit" and "wilderness > preservation", the latter of which Alexandre talked about). Well, we do have (almost) best fit, that's the only reason for having multiple free lists. It's just that we probably need more bins sizes to make it really useful. > We just need > to make sure Wine's free block selection routine uses the same strategies > as this allocator, and we'd get exactly the same performance as that > allocator, but without replacing the whole thing and sacrificing the > compatibility we have or introducing new bugs. Well, this depends how easy it is to plug the new allocator in; but if it doesn't require too many changes, it will certainly introduce less bugs than trying to tweak the existing code. Plus all the profiling work has been done already, which would have to be done on the Wine code. -- Alexandre Julliard julliard(a)winehq.com

1 0

FIXME:pthread_rwlock_rdlock
by 510045342665-0001＠t-online.de 11 Oct '01

11 Oct '01

Hi, I am running a compiler with wine. There are many fixme message that I can't switch off. What do they mean, is someone working on it, is the problem serious ? Not having them at stdout would be great :-) as the compiler output + wine fixmes get a little confusing... [scan1.c] FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock --Dirk

1 0

Re: Nasty Evil Memory Fragmentation fix
by Alexandre Julliard 11 Oct '01

11 Oct '01

Gavriel State <gav(a)transgaming.com> writes: > We ended up creating a new subheap every time one of these larger > blocks came along. The new space from the subheap then went to > the top of the freelist, so all the small allocations then filled > it up until the next large block allocation. IE: We never got a > chance to reuse freed blocks in older subheaps - at least not > very well. That's why we have multiple free lists. The code is using the Win95 values now, but there is no reason we couldn't add a few larger values in the HEAP_freeListSizes array, instead of creating a new mechanism. > Despite the workaround, we're still not too pleased with the current > heap allocator. It's quite slow, and still not as efficient as > it could be. It would probably be worth the effort to integrate > a new allocator - anyone know if there's a high-quality Wine-license- > compatible allocator out there? A new allocator would definitely be a good thing. This one was done the way it is in order to use a compatible memory layout, but it turns out this is not necessary so we could scrap it. -- Alexandre Julliard julliard(a)winehq.com

3 3

Re: fixed FILE_GetUnixHanlde for sockets
by Andreas Mohr 11 Oct '01

11 Oct '01

On Thu, Oct 11, 2001 at 06:53:33PM +0200, Kai Morich wrote: > added sock_get_info in server/sock.c (patch includes changelog) "Patch includes changelog". hmm, patch. which patch ? which changelog ? ;-) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

SHGetSpecialFolderPathA and CSIDL_FOLDER_MASK
by Chris Green 11 Oct '01

11 Oct '01

I've been looking at this function, and I am starting to suspect we have the wrong definition of CSIDL_FOLDER_MASK (currently 0x00ff). What I've been seeing (eg. installing MS Office 97) seems to imply that only the lower 6 bits, rather than 8, are related to the folder, and the others are something else. Does anyone else think that the mask should be 0x003f? regards Chris _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

Re: Nasty Evil Memory Fragmentation fix
by Alexandre Julliard 11 Oct '01

11 Oct '01

Gavriel State <gav(a)transgaming.com> writes: > This still doesn't help us: as Ove points out, we still end up allocating > from newly created free blocks even if old blocks would suit us better. But you want to use new blocks in general. The exception is that you want to avoid using the uncommitted part at the end of the heap, and I agree we could do a special case for that. But it has nothing to do with the size of the block. > I've had a brief look at the code referenced by Adam Moss (found at > http://g.oswego.edu/dl/html/malloc.html), and it looks like it would > be a vast improvement over Wine's current Heap manager. It even has > Windows code that uses VirtualAlloc to reserve actual memory. Yes, that would certainly be better that tweaking the existing code. You may want to look at ptmalloc too, it's supposed to be better at multi-threading (at least to get some ideas, the license is not 100% compatible with ours). -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Nasty Evil Memory Fragmentation fix
by Alexandre Julliard 11 Oct '01

11 Oct '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Well, after looking at some allocator algorithms, it seems to me there's > no reason to change neither the bin sizes nor the data structures. We just > have to change the free block selection algorithm - from my reading of the > code, right now it seems to always choose the *newest* (most recently > added) free block that's big enough. By changing it to always choose the > *oldest* free block instead, we'd already have a huge improvement. > (That's essentially the effect of Gav's patch, but only for big blocks, > but I suspect that could safely be done for *all* block sizes) I don't think that's a good idea. It's pretty bad for the cache and paging system to reuse oldest blocks first. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wine/ include/win.h include/wine/server_protoc ...
by Gerard Patel 10 Oct '01

10 Oct '01

At 06:46 PM 10/10/2001 +0200, you wrote: >No the application does a SendMessage > >096ed3f8:Call user32.SendMessageA(ffffffff,0000c00c,00000000,00000000) ret=004141aa ffffffff = Broadcast message. Take a look at this /*********************************************************************** * broadcast_message_callback * * Helper callback for broadcasting messages. */ static BOOL CALLBACK broadcast_message_callback( HWND hwnd, LPARAM lparam ) { struct send_message_info *info = (struct send_message_info *)lparam; if (!(GetWindowLongW( hwnd, GWL_STYLE ) & (WS_POPUP|WS_CAPTION))) return TRUE; GetWindowLong does not work currently between processes. There are a lot to do for the whole of Apis to work between processes yes, but there is not so much remaining for this kind of installer to work IMO. Gerard

1 0

Buisness Apps
by Nick Hudson 10 Oct '01

10 Oct '01

Greetings, Has anyone got Quick Books Pro 2001 and ACT! 2000 to run on wine? In quick books I get this error when it goes to install it: fixme:ole:CoGetClassObject CLSCTX_LOCAL_SERVER not supported! and it says that the set up failed..... in ACT! 2001 I the install stalls out when I have to say what country I am in.... I have to ctrl+alt+F1 and do a killall to get rid of it. Also its not seeing my ethernet connection.... do I need to add anything to the config file to make this work right? I was trying to install IE over the web.... As far as I can tell it doesnt see that im on the network Thanks Nick Hudson

1 0

Re: wine/ include/win.h include/wine/server_protoc ...
by Alexandre Julliard 10 Oct '01

10 Oct '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > The WIN_FindWndPtr message flooded the xterm during install, so I supected > soething still wrong... There are still a *lot* of functions that need to be adapted for handles belonging to other processes, so yes if you run multiple processes right now you'll most likely get flooded with messages. Working on it... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wine/ include/win.h include/wine/server_protoc ...
by Alexandre Julliard 10 Oct '01

10 Oct '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > No the application does a SendMessage > > 096ed3f8:Call user32.SendMessageA(ffffffff,0000c00c,00000000,00000000) ret=004141aa > err:win:WIN_FindWndPtr window 1002a belongs to other process > err:win:WIN_FindWndPtr window 10021 belongs to other process > err:win:WIN_FindWndPtr window 10029 belongs to other process > 096ed3f8:Ret user32.SendMessageA() retval=00000001 ret=004141aa > 096ed3f8:Call user32.SendMessageA(ffffffff,0000c00d,00000000,00000000) ret=004141bc > err:win:WIN_FindWndPtr window 1002a belongs to other process > err:win:WIN_FindWndPtr window 10021 belongs to other process > err:win:WIN_FindWndPtr window 10029 belongs to other process > 096ed3f8:Ret user32.SendMessageA() retval=00000001 ret=004141bc > > 096ed3f8 is a process created with Winexec, so I expect it to be a > sibling. Why isn't the WindowsFunction of at least that process called? It will be called only if the process has created a top-level window. Could you check if this is the case? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: CommandLineToArgvW fix
by Eric Pouech 10 Oct '01

10 Oct '01

just a last question (that I didn't check) what if the process name contains spaces like: C:\Program Files\foo\bar.exe what does Windows do ? returns in argv[0] "C:\Program" or "C:\Program Files". The later would also require testing of existence of the directories (doing a more semantical approach while current implementation is purely syntaxical) A+ > > > Here's another version that uses GlobalLock... > I also retested in Windows and I believe the comment about spaces was > wrong. > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > It really galls me that most of the computer power in the world > is wasted on screen savers. > Chris Caldwell from the GIMPS project > http://www.mersenne.org/prime.htm > --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

2 1

Re: wine/ include/win.h include/wine/server_protoc ...
by Gerard Patel 10 Oct '01

10 Oct '01

At 04:55 PM 10/10/2001 +0200, you wrote: . > Alexandre> Implemented inter-process FindWindow(). > >Shouldn't this avoid errors like these: >err:win:WIN_FindWndPtr window 1002a belongs to other process >err:win:WIN_FindWndPtr window 10021 belongs to other process >err:win:WIN_FindWndPtr window 10029 belongs to other process Handles of other process windows can be returned by FindWindow, yes. But current Wine returns them also in enumeration functions, like EnumWindows. A functions like SetCursor, when trying to set the cursor for all desktop children, triggers this kind of message. The error message shows that Wine development is not complete because some function fails between processes (in SetCursor case, it is X11DRV_get_whole_window), not necessarily a problem in FindWindow. Try to lookup the origin for the handles : it is a problem only if the app get them from a FindWindow call. Gerard

2 1

Re: Compiling WINE on solaris 7
by Jeremy White 10 Oct '01

10 Oct '01

> > First I thought this was a problem caused by the SUN as, but then I > installed the GNU as, and typed > "make clean; rm config.cache; configure && make depend && make" > but the problem remained. I suspect that the problem is that gcc is still invoking 'as' instead of 'gas'. My understanding is the only clean way to get gcc to use the GNU binutils is to rebuild it with such support. What we've done is very hackish, but seems to work - place symlinks called 'as', 'cc', and 'ld' that point to the respective GNU tools ahead of the 'normal' SUN tools in the PATH. HTH Jer

1 0

Re: wine/ include/win.h include/wine/server_protoc ...
by Uwe Bonnes 10 Oct '01

10 Oct '01

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: ... Alexandre> Implemented inter-process FindWindow(). Shouldn't this avoid errors like these: err:win:WIN_FindWndPtr window 1002a belongs to other process err:win:WIN_FindWndPtr window 10021 belongs to other process err:win:WIN_FindWndPtr window 10029 belongs to other process These errors still happens with the Quicklogic Installer. 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

Nasty Evil Memory Fragmentation fix
by Gavriel State 10 Oct '01

10 Oct '01

We just spent about 3 days tracking down a very subtle memory fragmentation problem in an app we're working on. The problem: App allocates lots of little blocks, then a few large blocks, then lots of little blocks. Throughout this process, many blocks would be freed from all over the heap. Repeat ad infinitum. We ended up creating a new subheap every time one of these larger blocks came along. The new space from the subheap then went to the top of the freelist, so all the small allocations then filled it up until the next large block allocation. IE: We never got a chance to reuse freed blocks in older subheaps - at least not very well. This fix addresses the problem by pushing 'large' freed blocks to the end of the free list, leaving 'small' blocks at the front, to be found sooner. The size of 'large' vs 'small' is tunable. Despite the workaround, we're still not too pleased with the current heap allocator. It's quite slow, and still not as efficient as it could be. It would probably be worth the effort to integrate a new allocator - anyone know if there's a high-quality Wine-license- compatible allocator out there? -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com --- heap.c Wed Sep 26 19:11:21 2001 +++ /home/gavriels/transgaming/wine/memory/heap.c Tue Oct 9 23:53:15 2001 @@ -59,6 +59,8 @@ #define QUIET 1 /* Suppress messages */ #define NOISY 0 /* Report all errors */ +#define FREE_BLOCK_INSERTION_THRESHOLD 4096 + #define HEAP_NB_FREE_LISTS 4 /* Number of free lists */ /* Max size of the blocks on the free lists */ @@ -229,11 +231,11 @@ /*********************************************************************** - * HEAP_InsertFreeBlock + * HEAP_InsertFreeBlockAtFront * - * Insert a free block into the free list. + * Insert a free block into the front of the free list. */ -static void HEAP_InsertFreeBlock( HEAP *heap, ARENA_FREE *pArena ) +static void HEAP_InsertFreeBlockAtFront( HEAP *heap, ARENA_FREE *pArena ) { FREE_LIST_ENTRY *pEntry = heap->freeList; while (pEntry->size < pArena->size) pEntry++; @@ -244,6 +246,31 @@ pEntry->arena.next = pArena; } +/*********************************************************************** + * HEAP_InsertFreeBlockAtEnd + * + * Insert a free block into the end of the free list. + */ +static void HEAP_InsertFreeBlockAtEnd( HEAP *heap, ARENA_FREE *pArena ) +{ + FREE_LIST_ENTRY *pEntry = heap->freeList; + + /* Determine which free list contains blocks of the appropriate size. */ + while (pEntry->size < pArena->size) pEntry++; + + /* But we want to put this block on the end of said appropriate free list. + * So instead, find the list for the next size up, knowing that they are + * all connected. */ + if (++pEntry == heap->freeList+HEAP_NB_FREE_LISTS) + pEntry = heap->freeList; + + pArena->size |= ARENA_FLAG_FREE; + pArena->next = &pEntry->arena; + pArena->prev = pEntry->arena.prev; + + pArena->next->prev = pArena; + pArena->prev->next = pArena; +} /*********************************************************************** * HEAP_FindSubHeap @@ -372,7 +399,11 @@ /* Last, insert the new block into the free list */ pFree->size = size - sizeof(*pFree); - HEAP_InsertFreeBlock( subheap->heap, pFree ); + + if ((pFree->size & ARENA_SIZE_MASK) > FREE_BLOCK_INSERTION_THRESHOLD) + HEAP_InsertFreeBlockAtEnd( subheap->heap, pFree ); + else + HEAP_InsertFreeBlockAtFront( subheap->heap, pFree ); }

2 1

Fwd: Re: Remove annoying fatal_error() after wineserver crash
by Malte Starostik 10 Oct '01

10 Oct '01

Seems I'm too used to mailing lists which set Reply-to to the list... Am Wednesday 10 October 2001 01:15 schrieben Sie: > Malte Starostik <malte(a)kde.org> writes: > > not sure about the reason for that "the socket exists, but I can't > > connect" message, but IMHO it's pretty annoying. I hit this fatal_exit() > > very often while debugging reaktivate. And in such cases - or when > > starting an app from a desktop / startmenu icon - when wine's STDERR goes > > to ~/.xsession-errors instead of a shell, the user has no chance to > > figure why an app won't start. Well, long story, short patch which Works > > for Me (TM) but I don't know if there's anything wrong with doing this... > > The problem with this is that it creates a race condition and we may > end up with two servers running in the same directory, which is bad. > > The error message should only happen when a previous server has > crashed, which is a critical error (the server should never crash no > matter what the app does). In that case you should also have a core > file in the same directory as the socket, which you can use to debug > and fix the crash. Thanks for the hint, I'll try to reproduce it with an appropriate ulimit set. But right, an actual wineserver crash didn't happen in a while. Unfortunately I have some system instability currently, so many times the message was caused by a stale socket lying around after a solid lockup of my box. What tends to happen rather often though is that wineserver keeps running after I quit all windows/winelib apps and consumes 100% CPU. In some of such cases, it'll only die on SIGKILL, which also leaves a socket around. I agree that neither a system lockup nor a hanging wineserver should happen though :) Maybe there could be a wineserver.pid file in the same dir and only if the process identified therein doesn't exist anymore, the socket will be autoremoved? But after all it's not too big a problem, guess there are more important issues. -- Malte Starostik PGP: 1024D/D2F3C787 [C138 2121 FAF3 410A 1C2A 27CD 5431 7745 D2F3 C787]

2 1

Re: Remove annoying fatal_error() after wineserver crash
by Alexandre Julliard 09 Oct '01

09 Oct '01

Malte Starostik <malte(a)kde.org> writes: > not sure about the reason for that "the socket exists, but I can't connect" > message, but IMHO it's pretty annoying. I hit this fatal_exit() very often > while debugging reaktivate. And in such cases - or when starting an app from > a desktop / startmenu icon - when wine's STDERR goes to ~/.xsession-errors > instead of a shell, the user has no chance to figure why an app won't start. > Well, long story, short patch which Works for Me (TM) but I don't know if > there's anything wrong with doing this... The problem with this is that it creates a race condition and we may end up with two servers running in the same directory, which is bad. The error message should only happen when a previous server has crashed, which is a critical error (the server should never crash no matter what the app does). In that case you should also have a core file in the same directory as the socket, which you can use to debug and fix the crash. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: SHGetSpecialFolderPathA
by Chris Green 09 Oct '01

09 Oct '01

That's the last time _I_ send a patch in the early hours of the morning! I missed a few commas... This one is better... Index: include/shlobj.h =================================================================== RCS file: /home/wine/wine/include/shlobj.h,v retrieving revision 1.47 diff -u -3 -p -r1.47 shlobj.h --- include/shlobj.h 2000/09/26 00:00:59 1.47 +++ include/shlobj.h 2001/10/09 21:53:39 @@ -461,6 +461,9 @@ HRESULT WINAPI SHGetSpecialFolderLocatio #define CSIDL_SENDTO 0x0009 #define CSIDL_BITBUCKET 0x000a #define CSIDL_STARTMENU 0x000b +#define CSIDL_MYDOCUMENTS 0x000c +#define CSIDL_MYMUSIC 0x000d +#define CSIDL_MYVIDEO 0x000e #define CSIDL_DESKTOPDIRECTORY 0x0010 #define CSIDL_DRIVES 0x0011 #define CSIDL_NETWORK 0x0012 @@ -473,6 +476,7 @@ HRESULT WINAPI SHGetSpecialFolderLocatio #define CSIDL_COMMON_DESKTOPDIRECTORY 0x0019 #define CSIDL_APPDATA 0x001a #define CSIDL_PRINTHOOD 0x001b +#define CSIDL_LOCAL_APPDATA 0x001c #define CSIDL_ALTSTARTUP 0x001d #define CSIDL_COMMON_ALTSTARTUP 0x001e #define CSIDL_COMMON_FAVORITES 0x001f @@ -494,8 +498,17 @@ HRESULT WINAPI SHGetSpecialFolderLocatio #define CSIDL_COMMON_ADMINTOOLS 0x002f #define CSIDL_ADMINTOOLS 0x0030 #define CSIDL_CONNECTIONS 0x0031 +#define CSIDL_COMMON_MUSIC 0x0035 +#define CSIDL_COMMON_PICTURES 0x0036 +#define CSIDL_COMMON_VIDEO 0x0037 +#define CSIDL_RESOURCES 0x0038 +#define CSIDL_RESOURCES_LOCALIZED 0x0039 +#define CSIDL_COMMON_OEM_LINKS 0x003a +#define CSIDL_CDBURN_AREA 0x003b +#define CSIDL_COMPUTERSNEARME 0x003d #define CSIDL_FOLDER_MASK 0x00ff - +#define CSIDL_FLAG_PER_USER_INIT 0x0800 +#define CSIDL_FLAG_NO_ALIAS 0x1000 #define CSIDL_FLAG_DONT_VERIFY 0x4000 #define CSIDL_FLAG_CREATE 0x8000 Index: dlls/shell32/shellpath.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/shellpath.c,v retrieving revision 1.56 diff -u -3 -p -r1.56 shellpath.c --- dlls/shell32/shellpath.c 2001/08/16 18:49:57 1.56 +++ dlls/shell32/shellpath.c 2001/10/09 21:53:41 @@ -660,7 +660,7 @@ static const CSIDL_DATA CSIDL_Data[] = "Desktop", "Desktop" }, - { /* CSIDL_INTERNET (??) */ + { /* CSIDL_INTERNET */ 0, 1, /* FIXME */ NULL, NULL, @@ -715,22 +715,22 @@ static const CSIDL_DATA CSIDL_Data[] = "Start Menu", "Start Menu" }, - { /* not known */ - 0, 0, + { /* CSIDL_MYDOCUMENTS */ + 0, 1, /* FIXME */ NULL, NULL, }, - { /* not known */ - 0, 0, + { /* CSIDL_MYMUSIC */ + 0, 1, /* FIXME */ NULL, NULL, }, - { /* not known */ - 0, 0, + { /* CSIDL_MYVIDEO */ + 0, 1, /* FIXME */ NULL, NULL, }, - { /* not known */ + { /* unassigned */ 0, 0, NULL, NULL, @@ -795,8 +795,8 @@ static const CSIDL_DATA CSIDL_Data[] = "PrintHood", "PrintHood" }, - { /* not known */ - 0, 0, + { /* CSIDL_LOCAL_APPDATA */ + 0, 0, /* FIXME */ NULL, NULL, }, @@ -904,6 +904,66 @@ static const CSIDL_DATA CSIDL_Data[] = 0, 1, /* FIXME */ NULL, NULL + }, + { /* unassigned 32*/ + 0, 0, + NULL, + NULL, + }, + { /* unassigned 33*/ + 0, 0, + NULL, + NULL, + }, + { /* unassigned 34*/ + 0, 0, + NULL, + NULL, + }, + { /* CSIDL_COMMON_MUSIC */ + 0, 0, /* FIXME */ + NULL, + NULL, + }, + { /* CSIDL_COMMON_PICTURES */ + 0, 0, /* FIXME */ + NULL, + NULL, + }, + { /* CSIDL_COMMON_VIDEO */ + 0, 0, /* FIXME */ + NULL, + NULL, + }, + { /* CSIDL_RESOURCES */ + 0, 0, /* FIXME */ + NULL, + NULL, + }, + { /* CSIDL_RESOURCES_LOCALIZED */ + 0, 0, /* FIXME */ + NULL, + NULL, + }, + { /* CSIDL_COMMON_OEM_LINKS */ + 0, 0, /* FIXME */ + NULL, + NULL, + }, + { /* CSIDL_CDBURN_AREA */ + 0, 0, /* FIXME */ + NULL, + NULL, + }, + { /* unassigned 3C */ + 0, 0, + NULL, + NULL, + }, + { /* CSIDL_COMPUTERSNEARME */ + 0, 0, /* FIXME */ + NULL, + NULL, } }; #undef HKCU @@ -926,7 +986,7 @@ BOOL WINAPI SHGetSpecialFolderPathA ( TRACE("0x%04x,%p,csidl=%lu,0x%04x\n", hwndOwner,szPath,csidl,bCreate); - if ((folder > CSIDL_CONNECTIONS) || (CSIDL_Data[folder].hRootKey == 0)) + if ((folder > CSIDL_COMPUTERSNEARME) || (CSIDL_Data[folder].hRootKey == 0)) { ERR("folder unknown or not allowed\n"); return FALSE; _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

1 0

Re: Service Pack Information in registry
by Nerijus Baliunas 09 Oct '01

09 Oct '01

On Mon, 8 Oct 2001 22:36:27 +0200 Stefan Leichter <Stefan.Leichter(a)camline.com> wrote: SL> Hello, SL> SL> during some investigations on CEMW i found a posting from Nerijus Baliunas SL> <nerijus(a)users.sourceforge.net> that contains the registry information to SL> make the installer of IE 4.0 thinking the SP3 is installed on a NT 4.0 system. SL> SL> Tschüß Stefan SL> SL> --- wine-20011004/winedefault.reg Fri Oct 5 13:12:57 2001 SL> +++ wine/winedefault.reg Mon Oct 8 22:25:33 2001 SL> @@ -100,6 +100,13 @@ SL> "OEMCP"="437" SL> SL> # SL> +# Win NT 4.0 with Service Pack 3 SL> +# SL> + SL> +[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Windows] SL> +"CSDVersion"="768" Maybe better to use "1536"? It means Service Pack 6. Regards, Nerijus

1 0

Half-Life hangs on "Loading"
by mdew 09 Oct '01

09 Oct '01

... warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ Windows/System' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ Windows' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ Windows' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ Windows/System' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/tmp' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew' FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock warn:file:CreateDirectoryA Error 'File exists' trying to create directory '/home /mdew/fake_windows/SAVE' warn:dosfs:DOSFS_FindUnixName '*.HL?' not found in '/home/mdew/fake_windows/SAVE ' warn:dosfs:DOSFS_FindUnixName 'pak1.pak' not found in '/home/mdew/fake_windows/S IERRA/Half-Life/valve' warn:file:CreateFileA Unable to get full filename from 'C:\SIERRA\Half-Life\valv e\pak1.pak' (GLE 2) warn:dosfs:DOSFS_FindUnixName 'custom.hpk' not found in '/home/mdew/fake_windows /SIERRA/Half-Life/valve' warn:file:CreateFileA Unable to get full filename from 'C:\SIERRA\Half-Life\valv e\custom.hpk' (GLE 2) warn:dosfs:DOSFS_FindUnixName 'palette.lmp' not found in '/home/mdew/fake_window s/SIERRA/Half-Life/valve/gfx' warn:gdi:GDI_GetObjPtr Invalid handle 0 warn:gdi:GDI_GetObjPtr Invalid handle 0 fixme:font:GetCharABCWidthsW (27f0,0000,00ff,0x41ccc8b4), returns slightly bogus values. warn:gdi:GDI_GetObjPtr Invalid handle 0 warn:gdi:GDI_GetObjPtr Invalid handle 0 fixme:font:GetCharABCWidthsW (27f8,0000,00ff,0x41ccd940), returns slightly bogus values. warn:gdi:GDI_GetObjPtr Invalid handle 0 warn:gdi:GDI_GetObjPtr Invalid handle 0 fixme:font:GetCharABCWidthsW (2800,0000,00ff,0x41cce9cc), returns slightly bogus values. warn:gdi:GDI_GetObjPtr Invalid handle 0 warn:gdi:GDI_GetObjPtr Invalid handle 0 fixme:font:GetCharABCWidthsW (2808,0000,00ff,0x41ccfa58), returns slightly bogus values. warn:dosfs:DOSFS_FindUnixName 'GameUI.dll' not found in '/home/mdew/fake_windows /SIERRA/Half-Life/valve/cl_dlls' warn:dosfs:DOSFS_FindUnixName 'cl_dlls\GameUI.dll' not found in '/home/mdew/fake _windows/SIERRA/Half-Life' warn:module:MODULE_LoadLibraryExA Failed to load module 'C:\WINDOWS\SYSTEM'; err or=0x00000002, FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock warn:module:BUILTIN32_dlopen cannot open .so lib for builtin client.dll: libclie nt.so: cannot open shared object file: No such file or directory FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock warn:win32:ELF_LoadLibraryExA failed to load libclient.so: libclient.so: cannot open shared object file: No such file or directory warn:dosfs:DOSFS_FindUnixName 'KERNEL32.dll' not found in '/home/mdew/fake_windo ws/SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'KERNEL32.dll' not found in '/home/mdew/fake_windo ws/SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'USER32.dll' not found in '/home/mdew/fake_windows /SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'USER32.dll' not found in '/home/mdew/fake_windows /SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'WINMM.dll' not found in '/home/mdew/fake_windows/ SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'WINMM.dll' not found in '/home/mdew/fake_windows/ SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'WSOCK32.dll' not found in '/home/mdew/fake_window s/SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'WSOCK32.dll' not found in '/home/mdew/fake_window s/SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'Bin/TrackerUI.dll' not found in '/home/mdew/fake_ windows/SIERRA/Half-Life/valve' warn:dosfs:DOSFS_FindUnixName 'sound/materials.txt' not found in '/home/mdew/fak e_windows/SIERRA/Half-Life/valve' warn:dosfs:DOSFS_FindUnixName 'sound/materials.txt' not found in '/home/mdew/fak e_windows/SIERRA/Half-Life/valve' warn:dosfs:DOSFS_FindUnixName 'sound/sentences.txt' not found in '/home/mdew/fak e_windows/SIERRA/Half-Life/valve' warn:dosfs:DOSFS_FindUnixName 'dsound.dll' not found in '/home/mdew/fake_windows /SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'dsound.dll' not found in '/home/mdew/fake_windows /SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'winmm.dll' not found in '/home/mdew/fake_windows/ SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'winmm.dll' not found in '/home/mdew/fake_windows/ SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'kernel32.dll' not found in '/home/mdew/fake_windo ws/SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'kernel32.dll' not found in '/home/mdew/fake_windo ws/SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ Windows/System' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ Windows' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ Windows' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ Windows/System' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/tmp' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew' fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4040f398,00030048,3):stub err:ntdll:RtlpWaitForCriticalSection section 0x4040f71c "?" wait timed out, retr ying (60 sec) fs=0337 This is a fake windows install straight from the HL CD... using wine 20011004 sid debs.

1 1

using a webcam driver for windows
by Hrafnkell Eiríksson 09 Oct '01

09 Oct '01

Hi This might be a silly question, but would it be possible to use wine with a parallel port webcam driver and an windows application to show images to use a webcam in linux that only has windows suport? I'm thinking about how to get my Logitech QuickCam VC to work in linux :) I know that wine can to some extent access the parallel port in linux. I'm not very familiar with the inner workings of windows, but I guess the camera driver is something called .VxD? Would it be possible to let wine use that somehow? Or does wine not work at that low level? If it is possible to do this, is there something that a guy armed with a C compiler but almost no understanding of windows and wine internals can get working? Thanks Hrafnkell

1 0

Rendering problem in NetTerm
by Mike McCormack 09 Oct '01

09 Oct '01

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. Its main window ends up with only the boarders drawn and will draw some toolbar buttons if i move the mouse over them. The following message appears repeatedly in the debug log: err:region:CombineRgn Invalid rgn=1096 i did a bit of tracing of the app and found that the region 1096 is created, used by a DC, destroyed, then used again. Is it possible that the reference count of the region is incremented when it is used in some way by a DC? A similar problem to the reference counting one Uwe Bonnes discovered (see message to this list on 16 Aug)? Mike >---------- Forwarded message ---------- >Date: Fri, 14 Sep 2001 18:41:04 -0300 >From: Raul Dias <chaos(a)swi.com.br> >Reply-To: wine-users(a)winehq.com >To: wine-users(a)winehq.com >Subject: wine serial support > >Hi, > >I use wine to run a terminal emulator (NetTerm). >It connects to a Linux Server (it was meant to run from windows) that runs a commerce software. > >This Linux commerce software sends the terminal emulator escape codes to interface with a >"ticket" printer attached to a serial port. > >The reason to go thru all this problem is that the printer has a proprietary, closed source driver >for windows only and interface only with netterm. > >With wine 20001026 this works greatfull. The application takes 3 seconds to startup >in a P133 machine. > >However, the serial communication part does not work with the later versions of wine >like 20010731. The application reports as if there is no serial port and wine complains >with some fixmes about comm support. > >Did wine suffered a big serial change over the last year? > >Now the important thing: >What can I do to help debug this problem (and make it work >on latest wine versions)? >Run it in the latest wine with --debugmsg +all is enough? > > >Regards, > >Raul Dias ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

Re: CommandLineToArgvW fix
by Alexandre Julliard 09 Oct '01

09 Oct '01

Francois Gouget <fgouget(a)free.fr> writes: > The problem is that CommandLineToArgvW is supposed to return a > pointer, not a handle. But I cannot do: > > hargv=GlobalAlloc(...); > argv=GlobalLock(hargv); > ... > return argv; Sure you can do that, as long as the allocation is GMEM_FIXED GlobalLock doesn't touch the lock count so you don't need to unlock it. It's basically just a glorified typecast. > Sigh. What a stupid memory API. Here I have to agree... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: CommandLineToArgvW fix
by Alexandre Julliard 09 Oct '01

09 Oct '01

Francois Gouget <fgouget(a)free.fr> writes: > Grrr, HGLOBAL is not a void* pointer... yet => casts :-( GlobalLock would be better... -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wine/windows painting.c
by Alexandre Julliard 08 Oct '01

08 Oct '01

Duane Clark <dclark(a)leewardfpga.com> writes: > This patch, despite being very simple, has the surprising affect of > causing names of files and icons in the file open dialog of one of my > apps to become invisible when I change directories. I can get individual > names to show up again if I click in the general area of the name, and > all of them show up if I click in the general area of where I know the > scrollbar to be (it is also invisible). Does this make any difference? Index: windows/painting.c =================================================================== RCS file: /opt/cvs-commit/wine/windows/painting.c,v retrieving revision 1.58 diff -u -r1.58 painting.c --- windows/painting.c 2001/10/05 19:47:42 1.58 +++ windows/painting.c 2001/10/08 20:19:22 @@ -712,8 +712,6 @@ if (flags & RDW_UPDATENOW) { - /* process pending events and messages before painting */ - MsgWaitForMultipleObjects( 0, NULL, FALSE, 0, QS_ALLINPUT ); if (wndPtr->hrgnUpdate) /* wm_painticon wparam is 1 */ SendMessageW( hWnd, (bIcon) ? WM_PAINTICON : WM_PAINT, bIcon, 0 ); } @@ -818,6 +816,11 @@ r.top, r.right, r.bottom, hrgnUpdate, flags ); } } + + + /* process pending events and messages before painting */ + if (flags & RDW_UPDATENOW) + MsgWaitForMultipleObjects( 0, NULL, FALSE, 0, QS_ALLINPUT ); /* prepare an update region in window coordinates */ -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: Make serial fd blocking mode depend on FILE_FLAG_OVERLAPPED (Updated)
by lawson_whitney＠juno.com 08 Oct '01

08 Oct '01

On Mon, 8 Oct 2001, Mike McCormack wrote: > > Hi Eric, > > Same patch as before, with the inherit flag added back in to the > server protocol. > > Mike > > ChangeLog: > * make serial fd blocking mode depend on FILE_FLAG_OVERLAPPED > I don't expect this will bother juno version 2. If you get this, it doesn't. Lawson --- >> Build a better mousetrap, and the world will build a better mouse.>> - Proverbs of Hell Revisited

1 1

Re: PATCH: shut up pthread fixme
by Alexandre Julliard 08 Oct '01

08 Oct '01

Marcus Meissner <marcus(a)jet.franken.de> writes: > Changelog: > Remove the harmless and confusing pthread locking fixme messagess. Agreed for pthread_kill_other_threads_np, but I don't think the pthread_rwlock ones are really harmless. We should really do some kind of locking in there, we can't just ignore them. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wine/windows painting.c
by Duane Clark 08 Oct '01

08 Oct '01

> ChangeSet ID: 1002311262337796173989773 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard@wine2. 01/10/05 15:47:42 > > Modified files: > windows : painting.c > > Log message: > Process pending events before sending WM_PAINT on RDW_UPDATENOW. > > Patch: http://cvs.winehq.com/patch.py?id=1002311262337796173989773 > This patch, despite being very simple, has the surprising affect of causing names of files and icons in the file open dialog of one of my apps to become invisible when I change directories. I can get individual names to show up again if I click in the general area of the name, and all of them show up if I click in the general area of where I know the scrollbar to be (it is also invisible). Duane

4 3

Re: CommandLineToArgvW fix
by Alexandre Julliard 08 Oct '01

08 Oct '01

Francois Gouget <fgouget(a)free.fr> writes: > On Mon, 8 Oct 2001, Malte Starostik wrote: > > > Don't free cmdline as the return values point into that string. It's the > > caller's responsibility to GlobalFree() this according to msdn. > > Ok, I tested my patch and it works. So I propose it here. If the caller is supposed to call GlobalFree on the returned value, it would be much cleaner to allocate it with GlobalAlloc. -- Alexandre Julliard julliard(a)winehq.com

1 0

CVS mirror
by davep 08 Oct '01

08 Oct '01

Checking CVS for the first time in several weeks today, I was surprised to discover that there had been no commits in all that time. Surprising since many changes had been discussed here over that period. Anyway I re-discovered that a long while ago I had put this in my /etc/hosts: 130.225.13.222 cvs.winehq.com presumably at a time when the main CVS was inaccessible. This address still holds a CVS repository for Wine but doesn't seem to be kept up to date. I hope no-one else has made the same mistake ;-) Dave Pickles

1 0

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