Re: err:heap:HEAP_ValidateInUseArena
John == John K Hohm [EMAIL PROTECTED] writes: John I am implementing a COM object in comcat.dll that allocates itself John with HeapAlloc and frees itself on its last Release with HeapFree. John I am using it in a simple test program that creates it and John releases it, and when the Release happens I get this: John err:heap:HEAP_ValidateInUseArena Heap 4034: in-use arena John 40378878 next block has PREV_FREE flag John It seems to be saying that I'm freeing an already-free block. I John ran the test program with --debugmsg trace+all, and I can see that John, those problems are normally caused by writing more memory then allocates, resulting in heap corruption. A good way to look after the problem is to run with --debugmsg -relay=x11drv,+heap, as the +heap argument checks the heap on every heap operation and the result doesn't get so cluttered as with +all. Eventually +ole might be helpfull, as comcat used the ole chanel. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Problem after update
Hello I make cvs update -RdP configure make depend make ./snmpapi.spec:6: Expected name, id, length or ordinal make[2]: *** [snmpapi.spec.c] Error 1 make[2]: Leaving directory `/home/marcelo/wine/cvs/wine/dlls/snmpapi' make[1]: *** [snmpapi/snmpapi.dll.so] Error 2 make[1]: Leaving directory `/home/marcelo/wine/cvs/wine/dlls' make: *** [dlls] Error 2 what happen? the syntax of cvs that i use are correct...? Thanks Marcelo
Re: Problem after update
Marcelo == Marcelo Welter [EMAIL PROTECTED] writes: Marcelo Hello I make cvs update -RdP configure make depend make Marcelo ./snmpapi.spec:6: Expected name, id, length or ordinal make[2]: Marcelo *** [snmpapi.spec.c] Error 1 make[2]: Leaving directory Marcelo `/home/marcelo/wine/cvs/wine/dlls/snmpapi' make[1]: *** Marcelo [snmpapi/snmpapi.dll.so] Error 2 make[1]: Leaving directory Marcelo `/home/marcelo/wine/cvs/wine/dlls' make: *** [dlls] Error 2 Marcelo what happen? the syntax of cvs that i use are correct...? Try make distclean ./configure make depend make and look if the error persists. After heavy reorganization like in the last days, some things may not fit any more. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Component owner for window management/painting
Any volunteers for handing this kind of problems? Andriy __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
Re: Patch - check for msghdr.msg_control on Sparc-Solaris
I think it would be better to do it using a technique similar to how it is done in scheduler/client.c on line 255: Makes sense to me - it wasn't obvious that msg_control and msg_accrights are always mutually exclusive, which is why I added a separate test... But if we're sure they are always mutally exclusive, this approach makes more sense... Warren
Re: Problem after update
--- Marcelo Welter [EMAIL PROTECTED] a écrit : Hello I make cvs update -RdP configure make depend make What are the changes if I run 'cvs -RdP' instead of 'cvs -AdP' ? I had a look at CVS manual but I'm not sure what is meant of. ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: Fix for focus loops
On Sun, May 12, Alexandre Julliard wrote: Actually all the problems you list apply only to unmanaged mode. Fixing that mode to be ICCCM compliant is fairly low priority, and probably quite hopeless. In fact the whole concept of unmanaged mode is flawed, and it will probably be replaced by a managed-with-no-decorations mode (with a few exceptions for menus etc.) once we have the proper support for doing actions like min/maximize through the window manager. I'm sorry to sound disrespectful, but I believe that many of those problems I have listed do apply to managed mode, at least if decorations are drawn by Wine. Think about the following scenario: - User has set window manager into mode where focus is not automatically given to new windows (can be done at least with WindowMaker). - User starts Wine program from xterm command line. - New Wine window is opened, Wine activates window, calls X11DRV_SetFocus and draws active caption bar. However, this is wrong since window manager has kept focus on xterm window and Wine should have drawn passive caption bar. You are partially correct in the fact that this kind of problems are unlikely to cause serious problems in managed mode. However, they still are bugs, potentially quite visible bugs, too, depending on what (ICCCM compliant) window manager is being used and how that window manager has been configured. -- Jukka Heinonen http://www.iki.fi/jhei/
Re: Fix for focus loops
Jukka Heinonen [EMAIL PROTECTED] writes: I'm sorry to sound disrespectful, but I believe that many of those problems I have listed do apply to managed mode, at least if decorations are drawn by Wine. But Wine doesn't draw the decorations in managed mode. It may do it once we do the managed-with-no-decorations mode I mentioned, but there are much larger problems with that to be solved first. -- Alexandre Julliard [EMAIL PROTECTED]
Problem in scheduler/process.c
ok, so I have found the cause of the problem in
scheduler/process.c that is making ut-based installers
not work.
the problem is the code from line 450 to line 461
inclusive.
in all programs, PROCESS_InitWine is called from int
main in miscemu/main.c, then open_winelib_app is
called from PROCESS_InitWine (always) where things go
wrong...
in a normal program, 1 of 2 things (im not sure which
though) happens...
1) line 451 evaluates to false so that section is
skipped and then line 461 is also evaluated to false,
so it is also skipped, so open_winelib_app returns
either null or (not sure of the difference)
-or-
2) line 451 evaluates to true, and then 457 also
evaluates to true, so open_winelib_app returns NULL.
with the ut-based installer that is the case, but the
Setup.exe that is on the root of the cd acts
differently...
1) 451 evaluates to false and then 461 evaluates to
true, causing wine to attempt to load the real
installer (called by the one in the root of the cd) as
a .so, which doesn't work.
-or-
2) 451 evaluates to true and 457 evaluates to false,
so it goes on to 461, which evaluates to true...
with winelib apps the same thing happens as with the
root-of-cd installer except that the .so file does
exist and so it gets loaded...
so, i think what needs to be done is a check in
PROCESS_InitWine for the kind of binary (windows or
winelib). and if it is a winelib binary, then run
call open_winelib_app, otherwise proceed with normal
loading...
probably the easiest way to do this would be like this
line 491-494
if (argv[0] != 'wine')
{
if (open_winelib_app( app_argv )) goto found;
}
that way you could probably completely remove lines
450-459 which are in open_winelib_app, since all it
does is check to make sure argv[0] doesn't equal
wine...
i would try this method out and submit it, but i won't
be back at home until tonight, so i can't make any
diff's. if someone wants to give it a go and let us
know if it works, please give me credit for the
_idea_.
hopefully this solves some other problems too...
comments appreciated.
-Dustin
__
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
Mingw devel stuff Part2
Sorry about that I hit the send button to soon. OK when I try build shlwapi.dll I'm getting this Administrator@LAPTOP /cygdrive/d/src/winehq/wine/dlls/shlwapi $ make dllwrap --add-stdcall-alias --def shlwapi.spec.def --implib shlwapi.a -o shlwapi .dll ordinal.o path.o reg.o regstream.o shlwapi_main.o string.o url.o shlwa pi.dll.dbg.o -L../../dlls -luser32 -lgdi32 -ladvapi32 -lkernel32 -L../../library -lwine -L../../ole -lwine_uuid -L../../unicode -lwine_unicode -lm Warning: resolving ___wine_dbgstr_guid by linking to __impwine_dbgstr_guid ( auto-import) Warning: resolving ___wine_dbgstr_an by linking to __impwine_dbgstr_an (auto -import) Warning: resolving ___wine_dbgstr_wn by linking to __impwine_dbgstr_wn (auto -import) ordinal.o(.text+0x52d6):ordinal.c: undefined reference to `wctype_table' ordinal.o(.text+0x52eb):ordinal.c: undefined reference to `wctype_table' path.o(.text+0x74d6):path.c: undefined reference to `casemap_lower' path.o(.text+0x74eb):path.c: undefined reference to `casemap_lower' path.o(.text+0x751a):path.c: undefined reference to `casemap_upper' path.o(.text+0x752f):path.c: undefined reference to `casemap_upper' path.o(.text+0x7752):path.c: undefined reference to `wctype_table' path.o(.text+0x7767):path.c: undefined reference to `wctype_table' string.o(.text+0x1d2d):string.c: undefined reference to `wvsnprintfA@16' string.o(.text+0x1d61):string.c: undefined reference to `wvsnprintfW@16' string.o(.text+0x1d8e):string.c: undefined reference to `casemap_upper' string.o(.text+0x1da3):string.c: undefined reference to `casemap_upper' url.o(.text+0x4426):url.c: undefined reference to `wctype_table' url.o(.text+0x443b):url.c: undefined reference to `wctype_table' fu01.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu02.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu04.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu05.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu06.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu07.o(.idata$3+0xc): more undefined references to `libwine_a_iname' follow nmth00.o(.idata$4+0x0): undefined reference to `_nmwine_dbgstr_guid' nmth03.o(.idata$4+0x0): undefined reference to `_nmwine_dbgstr_an' nmth09.o(.idata$4+0x0): undefined reference to `_nmwine_dbgstr_wn' collect2: ld returned 1 exit status dllwrap: gcc exited with status 1 make: *** [shlwapi.dll] Error 1 Every revolution was once a thought in one man's mind - Ralph Waldo Emerson
Mingw Port Information and Questions
OK so we the latest changes I do need to build libwine.dll right? I can if I link it to msvcrt.a but ig I don't I get the following Administrator@LAPTOP /cygdrive/d/src/winehq/wine/library $ make dllwrap --add-stdcall-alias --export-all --implib libwine.a -o libwine.dll debug .o errno.o ldt.o loader.o port.o dllwrap: no export definition file provided dllwrap: creating one, but that may not be what you want debug.o(.text+0x8d4):debug.c: undefined reference to `_imp___iob' loader.o(.text+0x4c4):loader.c: undefined reference to `_assert' loader.o(.text+0x614):loader.c: undefined reference to `_assert' port.o(.text+0x4):port.c: undefined reference to `_errno' port.o(.text+0x30):port.c: undefined reference to `_errno' port.o(.text+0x48):port.c: undefined reference to `_errno' port.o(.text+0x60):port.c: undefined reference to `_errno' port.o(.text+0x78):port.c: undefined reference to `_errno' port.o(.text+0x90):port.c: more undefined references to `_errno' follow collect2: ld returned 1 exit status dllwrap: gcc exited with status 1 make: *** [libwine.dll] Error 1 Also when I try to build shlwapi.dll I get this
Re: Mingw devel stuff Part2
Steven Edwards [EMAIL PROTECTED] writes:
Sorry about that I hit the send button to soon.
OK when I try build shlwapi.dll I'm getting this
Does it work better with this patch?
Index: include/wine/debug.h
===
RCS file: /opt/cvs-commit/wine/include/wine/debug.h,v
retrieving revision 1.3
diff -u -r1.3 debug.h
--- include/wine/debug.h17 May 2002 02:55:48 - 1.3
+++ include/wine/debug.h17 May 2002 18:50:54 -
@@ -87,13 +87,6 @@
#endif /* __GNUC__ */
-extern const char * (*__wine_dbgstr_an)( const char * s, int n );
-extern const char * (*__wine_dbgstr_wn)( const WCHAR *s, int n );
-extern const char * (*__wine_dbgstr_guid)( const struct _GUID *id );
-extern int (*__wine_dbg_vprintf)( const char *format, va_list args );
-extern int (*__wine_dbg_vlog)( int cls, const char *channel,
- const char *function, const char *format, va_list args
);
-
/*
* Exported definitions and macros
@@ -102,11 +95,11 @@
/* These function return a printable version of a string, including
quotes. The string will be valid for some time, but not indefinitely
as strings are re-used. */
-inline static const char *wine_dbgstr_guid( const struct _GUID *id ) { return
__wine_dbgstr_guid(id); }
-inline static const char *wine_dbgstr_an( const char * s, int n ) { return
__wine_dbgstr_an(s, n); }
-inline static const char *wine_dbgstr_wn( const WCHAR *s, int n ) { return
__wine_dbgstr_wn(s, n); }
-inline static const char *wine_dbgstr_a( const char *s ) { return __wine_dbgstr_an(
s, -1 ); }
-inline static const char *wine_dbgstr_w( const WCHAR *s ) { return __wine_dbgstr_wn(
s, -1 ); }
+extern const char *wine_dbgstr_guid( const struct _GUID *id );
+extern const char *wine_dbgstr_an( const char * s, int n );
+extern const char *wine_dbgstr_wn( const WCHAR *s, int n );
+extern const char *wine_dbgstr_a( const char *s );
+extern const char *wine_dbgstr_w( const WCHAR *s );
extern int wine_dbg_printf( const char *format, ... ) __WINE_PRINTF_ATTR(1,2);
extern int wine_dbg_log( int cls, const char *ch, const char *func,
@@ -140,11 +133,11 @@
#ifdef __WINE__
/* Wine uses shorter names that are very likely to conflict with other software */
-inline static const char *debugstr_an( const char * s, int n ) { return
__wine_dbgstr_an( s, n ); }
-inline static const char *debugstr_wn( const WCHAR *s, int n ) { return
__wine_dbgstr_wn( s, n ); }
-inline static const char *debugstr_guid( const struct _GUID *id ) { return
__wine_dbgstr_guid(id); }
-inline static const char *debugstr_a( const char *s ) { return __wine_dbgstr_an( s,
-1 ); }
-inline static const char *debugstr_w( const WCHAR *s ) { return __wine_dbgstr_wn( s,
-1 ); }
+inline static const char *debugstr_an( const char * s, int n ) { return
+wine_dbgstr_an( s, n ); }
+inline static const char *debugstr_wn( const WCHAR *s, int n ) { return
+wine_dbgstr_wn( s, n ); }
+inline static const char *debugstr_guid( const struct _GUID *id ) { return
+wine_dbgstr_guid(id); }
+inline static const char *debugstr_a( const char *s ) { return wine_dbgstr_an( s, -1
+); }
+inline static const char *debugstr_w( const WCHAR *s ) { return wine_dbgstr_wn( s, -1
+); }
#define TRACE WINE_TRACE
#define TRACE_(ch) WINE_TRACE_(ch)
Index: include/wine/library.h
===
RCS file: /opt/cvs-commit/wine/include/wine/library.h,v
retrieving revision 1.11
diff -u -r1.11 library.h
--- include/wine/library.h 16 May 2002 23:16:01 - 1.11
+++ include/wine/library.h 17 May 2002 18:50:54 -
@@ -43,6 +43,13 @@
/* debugging */
+extern const char * (*__wine_dbgstr_an)( const char * s, int n );
+extern const char * (*__wine_dbgstr_wn)( const WCHAR *s, int n );
+extern const char * (*__wine_dbgstr_guid)( const struct _GUID *id );
+extern int (*__wine_dbg_vprintf)( const char *format, va_list args );
+extern int (*__wine_dbg_vlog)( int cls, const char *channel,
+ const char *function, const char *format, va_list args
+);
+
extern void wine_dbg_add_option( const char *name, unsigned char set, unsigned char
clear );
/* portability */
Index: library/debug.c
===
RCS file: /opt/cvs-commit/wine/library/debug.c,v
retrieving revision 1.6
diff -u -r1.6 debug.c
--- library/debug.c 17 May 2002 04:17:48 - 1.6
+++ library/debug.c 17 May 2002 18:50:55 -
@@ -337,3 +337,30 @@
int (*__wine_dbg_vprintf)( const char *format, va_list args ) = default_dbg_vprintf;
int (*__wine_dbg_vlog)( int cls, const char *channel, const char *function,
const char *format, va_list args ) = default_dbg_vlog;
+
+/* wrappers to use the function pointers */
+
+const char *wine_dbgstr_guid( const struct _GUID *id )
+{
+return
Bugzilla bug 297: implement PeekNamedPipe.
* Andriy Palamarchuk ([EMAIL PROTECTED]) wrote: If anybody starts to work on the bug, please take this bug and keep it updated. Hi all, Newbie developer alert! I've been meaning to do something with this bug for a while now, as it seriously cripples my killer-app that's keeping me running Windows. Basically, I've had a look through the sources, and found out what I've got to do with the dll/server communication (I think!). I've fleshed out the PeekNamedPipe API Handler call (peek_named_pipe() in dlls/kernel/sync.c) to do a SERVER_REQUEST, and put in what I think needs putting in the server to handle said request (server/protocol.def has been modified with the requisite structure). Now, the problem I have is that the peek_named_pipe function that gets called inside the server (declared with a DECL_HANDLER) seems from the name (and it's associated function group too) that it's implementation should be in the file server/named_pipe.c, but it seems to me that this handler is more like a file read operation, and the other handlers in server/named_pipe.c are more to do with the housekeeping of a pipe. My question is, then, should the server's implementation of peek_named_pipe go in named_pipe.c, or somewhere else (where?). Also, PeekNamedPipe has two types of call - one where the call is returning the data ahead of a read, and one where it just returns the amount of bytes waiting. My program only uses one of these types; the return amount of data waiting type, and so I have no way of knowing if I've implemented the returns data type of call correctly. This means there's still a FIXME in one branch - does this make any patch I'd submit unnacceptable? Cheers, Dave.
Weird parameters with LVM_GETSUBITEMRECT
A recent change to dlls/comctl32/listview.c implemented GetSubItemRect,
but this causes Xnews to hang when selecting a newsgroup from the list.
I don't think the change itself is at fault, but it may have uncovered a
bug elsewhere. The app gets a message LVM_GETSUBITEMRECT (4152) with
the following parameters:
wParam: 1078422692 (0x40476ca4)
lParam: 1078422612 (0x40476c54)
wParam should be a small integer (an index into the listview items) and
lParam is a pointer to a RECT:
*(LPRECT)lParam: {left = 2, top = 1079544291,
right = 28246089, bottom = 1079843718}
or {left = 0x2, top = 0x405889e3,
right = 0x1af0049, bottom = 0x405d1b86}
lParam-left is reasonable, but lParam-top should be a small index.
Note that wParam, lParam, and lParam-top are fairly close numerically.
The function LISTVIEW_GetSubItemRect then tries to loop from 0 to that
huge number, causing the hang. I put a sanity check inside that
function to stop it from going past GETITEMCOUNT and that works, but I
want to see if I can fix it the right way.
--
Paul RupeShe smiled, in the
end.
p r u p e m y r e a l b o x . c o m
| Oppose government police-ware on your PC!
| Stop the Consumer Broadband and Digital Television Promotion Act!
| http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html
--
RE: Mingw devel stuff Part2
Does it work better with this patch? I'm having touble applying the patch, should it just be the standard Patch -p0../patch.diff This is what happens on every part patching file `include/wine/debug.h' patch: malformed patch at line 17: -102,11 +95,11 Thanks Steven Every revolution was once a thought in one man's mind - Ralph Waldo Emerson
nasty NTDLL_vsnwprintf bug?!?
My heap corruption problem turned out to be a bug in swprintf (well,
really in NTDLL_vsnwprintf), I think. I tried formatting like this:
WCHAR keyname[21] = { 'C', 'o', 'm', 'p', 'o', 'n', 'e', 'n',
't', ' ', 'C', 'a', 't', 'e', 'g', 'o',
'r', 'i', 'e', 's', 0 };
WCHAR fmt[4] = { '%', 'l', 'X', 0 };
swprintf(This-xlcid, fmt, lcid);
My poor little WCHAR xlcid[9] member of This was seriously overflowed by
the string L409Component Categories. The following patch fixes what
appears to be a format reading bug in NTDLL_vsnwprintf. I didn't just
send it to wine-patches because it's not my area and it seems unlikely
such a bad bug could hang around in such a function. Then again, I don't
see many uses of swprintf in the source; should I be using something
better for sprintf's of WCHAR's?
--- dlls/ntdll/wcstring.c.~1.15.~ Thu May 16 19:59:27 2002
+++ dlls/ntdll/wcstring.c Fri May 17 23:09:21 2002
-451,10 +451,7
}
if (*iter == (WCHAR)L'h' ||
*iter == (WCHAR)L'l')
- {
*fmta++ = *iter++;
- *fmta++ = *iter++;
- }
switch (*iter)
{
