April 2003 - Wine-Devel - list.winehq.org

Re: wine/ files/dos_fs.c dlls/kernel/tests/file.c
by Uwe Bonnes April 17, 2003

April 17, 2003

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)wine.codeweavers.com> writes: Alexandre> ChangeSet ID: 7890 CVSROOT: /opt/cvs-commit Module name: wine Alexandre> Changes by: julliard(a)wine.codeweavers.com 2003/04/16 21:10:04 Alexandre> Modified files: files : dos_fs.c dlls/kernel/tests: file.c Alexandre> Log message: Uwe Bonnes Alexandre> <bon(a)elektron.ikp.physik.tu-darmstadt.de> FindFirstFile on Alexandre> root directory should fail. Alexandre> Patch: http://cvs.winehq.com/patch.py?id=7890 @@ -1937,7 +1937,6 @@ UINT codepage; data->dwReserved0 = data->dwReserved1 = 0x0; - if (!lpFileName) return 0; if (lpFileName[0] == '\\' && lpFileName[1] == '\\') { ERR("UNC path name\n"); This first patch thunk wasn't in the patch I sent. Is this intentional? 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

Re: wine/include/msvcrt malloc.h
by Dimitrie O. Paun April 17, 2003

April 17, 2003

On Wed, 16 Apr 2003, Alexandre Julliard wrote: > Log message: > Fixed alloca handling the way mingw does it (reported by Vincent > Béron). > #ifndef USE_MSVCRT_PREFIX > -static inline void* alloca(MSVCRT(size_t) i) { return _alloca(i); } > +# ifdef __GNUC__ > +# define _alloca(x) __builtin_alloca((x)) > +# define alloca(x) __builtin_alloca((x)) > +# endif > #endif /* USE_MSVCRT_PREFIX */ If we know it's GNUC, isn't it better to use the alias feature, so we don't run into problems with the macros, like we use to? -- Dimi.

2 1

RE: What happend to the Stdole2 / Stdole32 (RESEND) patch fromRobert Shearman
by Robert Shearman April 17, 2003

April 17, 2003

> -----Original Message----- > From: Uwe Bonnes [mailto:bon(a)elektron.ikp.physik.tu-darmstadt.de] > Sent: 02 April 2003 14:40 > To: Robert Shearman > Subject: Re: What happend to the Stdole2 / Stdole32 (RESEND) patch > fromRobert Shearman > > > >>>>> "Robert" == Robert Shearman <R.J.Shearman(a)warwick.ac.uk> writes: > > >> what happend to the stdole32.tlb patch that Robert sent > around 22.1? > Robert> It was rejected on the grounds that we shouldn't have binary > Robert> files in CVS and we can't generate the .tlb files at > the moment. > > Did you generate the files from some source you wrote? Yes. > What compiler was used? MkTypLib from MS Platform SDK > What constraints are put on distributing those generated files? None, as far as I could tell. > The present need for stdole*.tlb from a windows installation is > unsatisfactory. Agreed. > Bye > > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Hope this helps and sorry for not getting back to you sooner, Rob

1 0

Winelib MFC?
by Christopher Thielen April 17, 2003

April 17, 2003

Hello, I've written an application in MFC which runs beautifully in wine. I'd like to distribute a Winelib version, so Unix users don't need wine. Can I recompile MFC applications with Winelib? Is this possible? -- chris (chris(a)luethy.net)

3 4

wild pointers in current named pipe implementation?
by Dan Kegel April 17, 2003

April 17, 2003

I know Mike is planning to rewrite the named pipe implementation, but the current implementation could use a little love while we're waiting for the new one. So I'm looking into the recent user complaint about FlushFileBuffers and named pipes, in hopes I can find a very simple patch that will tide us over until the new named pipes code is ready (whenever that might be; Mike's busy on other things at the moment). So I added an early call to FlushFileBuffers in the named pipe regression test (see attached patch). While poking around in wineserver, I found a few places where pointers were not set to NULL after being invalidated, and after I added the missing statements to set them to NULL, wineserver started behaving badly on the regression test. A run of wineserver under valgrind showed a null pointer access, so I added a couple null pointer check asserts (see attached patch). And sure enough, they fire. So the question is -- did I screw up, or did I uncover a real issue? The answer will help me as I continue digging into the FlushFileBuffers named pipe bug report (and testing possible simple enhancements to the current named pipe implementation). Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 Index: server/object.c =================================================================== RCS file: /home/wine/wine/server/object.c,v retrieving revision 1.27 diff -d -u -r1.27 object.c --- server/object.c 19 Feb 2003 00:33:33 -0000 1.27 +++ server/object.c 14 Apr 2003 16:59:45 -0000 @@ -193,6 +193,7 @@ struct object *grab_object( void *ptr ) { struct object *obj = (struct object *)ptr; + assert( obj ); assert( obj->refcount < INT_MAX ); obj->refcount++; return obj; Index: server/named_pipe.c =================================================================== RCS file: /home/wine/wine/server/named_pipe.c,v retrieving revision 1.22 diff -d -u -r1.22 named_pipe.c --- server/named_pipe.c 4 Apr 2003 22:26:34 -0000 1.22 +++ server/named_pipe.c 14 Apr 2003 16:59:45 -0000 @@ -163,6 +163,7 @@ static struct fd *pipe_user_get_fd( struct object *obj ) { struct pipe_user *user = (struct pipe_user *)obj; + assert(user->fd); return (struct fd *)grab_object( user->fd ); } @@ -200,8 +201,11 @@ if (user->prev) user->prev->next = user->next; else user->pipe->users = user->next; if (user->thread) release_object(user->thread); + user->thread = NULL; release_object(user->pipe); + user->pipe = NULL; if (user->fd) release_object( user->fd ); + user->fd = NULL; } static int pipe_user_get_poll_events( struct fd *fd ) Index: dlls/kernel/tests/pipe.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/tests/pipe.c,v retrieving revision 1.2 diff -d -u -r1.2 pipe.c --- dlls/kernel/tests/pipe.c 25 Feb 2003 03:56:43 -0000 1.2 +++ dlls/kernel/tests/pipe.c 14 Apr 2003 16:59:45 -0000 @@ -86,6 +86,10 @@ /* lpSecurityAttrib */ NULL); ok(hnp != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + if (!FlushFileBuffers(hnp)) { + /* we'll add a check here once we know how windows behaves */ + fprintf(stderr, "FlushFileBuffers on new pipe failed, err %d\n", GetLastError()); + } hFile = CreateFileA(PIPENAME, GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, 0); todo_wine

5 14

Re: Duplicate messages
by Michal Janusz Miroslaw April 17, 2003

April 17, 2003

> I receive duplicate messages with following headers. Could people please > look after their setup? It's my fault. Apologies for everyone. My fetchmail went crazy and I wasn't fast enough to stop it. :( -- Michal Miroslaw

1 0

Duplicate messages
by Uwe Bonnes April 17, 2003

April 17, 2003

Hallo, I receive duplicate messages with following headers. Could people please look after their setup? Thanks Return-Path: <wine-devel-admin(a)winehq.com> Received: from mailserver2.hrz.tu-darmstadt.de (mailserver2.hrz.tu-darmstadt.de [130.83.22.129]) by elektron.ikp.physik.tu-darmstadt.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id h3HDs0j28561 for <bon(a)elektron.ikp.physik.tu-darmstadt.de>; Thu, 17 Apr 2003 15:54:00 +0200 Received: from ziemniak.ustronie.pw.edu.pl (czuby.resetnet.pl [62.233.189.254]) by mailserver2.hrz.tu-darmstadt.de (8.12.9/8.12.8) with ESMTP id h3HDqNdj008074 for <bon(a)elektron.ikp.physik.tu-darmstadt.de>; Thu, 17 Apr 2003 15:52:25 +0200 Received: (qmail 7122 invoked by uid 1000); 17 Apr 2003 13:56:56 -0000 Received: from mion.elka.pw.edu.pl [194.29.160.35] by localhost with IMAP (fetchmail-6.2.2) for mirq-forwarded(a)localhost (single-drop); Thu, 17 Apr 2003 15:56:55 +0200 (CEST) Received: from [198.144.4.3] ([198.144.4.3]:39372 "EHLO wine.codeweavers.com") by mion.elka.pw.edu.pl with ESMTP id <S318308AbTDQAbg>; Thu, 17 Apr 2003 02:31:36 +0200 Received: from localhost.localdomain (wine [127.0.0.1]) by wine.codeweavers.com (8.11.6/8.11.6) with ESMTP id h3H0BHG22385; Wed, 16 Apr 2003 19:11:17 -0500 Received: from mail.wine.dyndns.org (adsl-64-142-4-165.sonic.net [64.142.4.165]) by wine.codeweavers.com (8.11.6/8.11.6) with ESMTP id h3H0A5G22281 for <wine-devel(a)winehq.com>; Wed, 16 Apr 2003 19:10:05 -0500 -- 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

Re: wineinstall: use pwd and drop ttydrv
by Steven Edwards April 17, 2003

April 17, 2003

--- Vincent B�ron <vberon(a)mecano.gme.usherb.ca> wrote: > Testing as shown that either x11drv or ttydrv could be set, even without > X present, as long as the app doesn't use user or gdi. > Also, the second change allows to build from anywhere, not limited to > one of the pre-mapped drives. > > Changelog: > Don't change to ttydrv to install registry, regedit doesn't use X. > Make sure the current dir is mapped in DOS. regedit will use user32 and friends if the ReactOS changes are merged in. ATM our regedit is read only when you use the GUI but you can still use the command-line for writes. __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com

1 0

winsock.h portability patch causing portability problem
by Gerald Pfeifer April 17, 2003

April 17, 2003

Alexandre, I am afraid the following patch revision 1.52 date: 2003/03/31 23:56:35; author: julliard; state: Exp; lines: +63 -60 Try to make winsock.h more portable (based on a patch by Francois Gouget). actually caused a portability problem for FreeBSD. /usr/bin/gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -fPIC -D_REENTRANT -o pipe.o pipe.c In file included from ../../../include/winsock2.h:47, from ../../../include/windows.h:62, from ../../../include/rpc.h:22, from ../../../include/wtypes.h:2, from pipe.c:34: ../../../include/winsock.h:925: conflicting types for `htonl' /usr/include/machine/endian.h:63: previous declaration of `htonl' ../../../include/winsock.h:926: conflicting types for `htons' /usr/include/machine/endian.h:64: previous declaration of `htons' ../../../include/winsock.h:927: conflicting types for `ntohl' /usr/include/machine/endian.h:65: previous declaration of `ntohl' ../../../include/winsock.h:928: conflicting types for `ntohs' /usr/include/machine/endian.h:66: previous declaration of `ntohs' gmake[3]: *** [pipe.o] Error 1 gmake[3]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/kernel/tests' gmake[2]: *** [tests] Error 2 gmake[2]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/kernel' The FreeBSD declarations are unsigned long htonl __P((unsigned long)); unsigned short htons __P((unsigned short)); unsigned long ntohl __P((unsigned long)); unsigned short ntohs __P((unsigned short)); Sorry, Gerald

2 6

Re: Set TZ environment variable when not set
by Alexandre Julliard April 17, 2003

April 17, 2003

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Changelog: > memory/environ.c: build_environment > Set the TZ value to GMT0, if TZ is not set > > Synplify.exe from the Quicklogic FPGA suite refused to work with the demo > license. Setting TZ to any value made it work. You should set it in your environment then, this doesn't belong in Wine. -- Alexandre Julliard julliard(a)winehq.com

4 4

RE: remove server silliniess
by Patrik Stridvall April 17, 2003

April 17, 2003

> On Thursday 17 April 2003 02:13 am, Fabian Cenedese wrote: > > >> remove run-time checks of compile-time constants. > > > > > >I dearly wish that there were a way of doing compile-time > assertion, but > > > there isn't, so it has to be done by a runtime assertion. > > > > Well, there seem to be some reasonable tricks for that: > > http://www.jaggersoft.com/pubs/CVu11_3.html > > http://www.panelsoft.com/murphyslaw/apr01.htm > > > > This is for C++ but maybe also adaptable for C: > > http://www.boost.org/libs/static_assert/static_assert.htm > > > > bye Fabi > > ah, the hidden powers of the preprocessor -- how it drives us > to obsfucation > with it's robotic stupidity... I wonder, is cpp a turing > machine? I don't think so. > Makes me > want to implement vim as a sed script ;) :-) > nonetheless, considering one must sometimes make do with what > one has, that > array-of-zero trick is super-clever... perhaps I'll actually make a > constructive patch out of this debacle yet.. Note that Wine already have a macro for this that is not a Wine specific invention but is rather a feature of the Win32 API. >From include/winnt.h: /* Compile time assertion */ #if defined(_MSC_VER) # define C_ASSERT(e) typedef char __C_ASSERT__[(e)?1:-1] #elif defined(__GNUC__) # define C_ASSERT(e) extern char __C_ASSERT__[(e)?1:-1] #endif

1 0

winedbg regression?
by Mike Hearn April 17, 2003

April 17, 2003

Hi, For the past week or so winedbg has refused to start, it just hangs whenever it tries to attach to a pid. Some traces indicate it's getting an access denied error when trying to attach? Not sure why i'd be getting that. I thought it was just my tree at first but Splinter on IRC says he has the same problem. Does anybody else see this?

6 9

Re: div in msvcrt
by Alexandre Julliard April 17, 2003

April 17, 2003

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > This was in msvcrt/stdlib.h since version 1.1, probably straight from > mingw. It caused some problems because div_t is a structure, not a long > long (same thing for ldiv_t). > > Changelog: > Fixed the definition of div/ldiv. This won't work, the calling sequence on i386 is not compatible. I'm not sure there's a good solution for that one... -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Set TZ environment variable when not set
by Michael Stefaniuc April 16, 2003

April 16, 2003

On Wed, Apr 16, 2003 at 09:05:28PM +0200, Uwe Bonnes wrote: > Changelog: > memory/environ.c: build_environment > Set the TZ value to GMT0, if TZ is not set > > Synplify.exe from the Quicklogic FPGA suite refused to work with the demo > license. Setting TZ to any value made it work. GMT0 should be a good > approach. > > Awaiting the "flame war" about noise level for that silent change :-) Well, can't help with that but we could start a new flame war about why UTC is better for this then GMT0. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

3 4

Re: Fallback to ttydrv (third attempt)
by Alexandre Julliard April 16, 2003

April 16, 2003

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Index: wine/dlls/user/user_main.c > =================================================================== > RCS file: /home/wine/wine/dlls/user/user_main.c,v > retrieving revision 1.50 > diff -u -r1.50 user_main.c > --- wine/dlls/user/user_main.c 3 Dec 2002 23:34:54 -0000 1.50 > +++ wine/dlls/user/user_main.c 15 Apr 2003 11:05:08 -0000 > { > count = sizeof(buffer); > RegQueryValueExA( hkey, "GraphicsDriver", 0, &type, buffer, &count ); > + count = sizeof(buffer2); > + RegQueryValueExA( hkey, "TTYdrvFallback", 0, &type, buffer2, &count ); > RegCloseKey( hkey ); > } > + > + if (!strcasecmp("x11drv",buffer) && > + (GetEnvironmentVariableA("DISPLAY",buffer1,MAX_PATH-1) == 0) && > + !strcasecmp("y",buffer2)) USER has no business checking the DISPLAY variable, that's an X11 thing. The right way to do this would be to make x11drv fail its initialization in that case, and have USER check for that. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: winedbg improvement - display
by Pouech Eric DMI AEI CAEN April 16, 2003

April 16, 2003

> Objet : winedbg improvement - display > I've just hacked winedbg 'display' handling. It now allows for temporary > disabling of displays and restricting them to one function. Look for > yourselves, comments welcome. :) since I'm away from home on a poor remote connection, I couldn't spend much time on this from a first look, enable/disable facility is fine but, here are, at least, two remarks : - first, I don't think we should have two ways of expressing the same thing (like disable display 1 and display disable 1). IMO, we should stick the former form (as we currently do) (I agree that current undisplay 1 and delete display 1 are may be a bit overkill too) - secondly, and most important, I don't like storing the frame context in the display information. I don't see how you're going to ensure that we got a correct context for evaluating an expression. Keeping the local frame name isn't even sufficient when calling the same function recursively. What I'm afraid of here is the user's perception of this specific context for evaluation. I know gdb has some of those tricks (i.e. that no one, except the one who wrote the code, is going to understand what context is going to be used for evaluating the expression). I really wonder what gdb does here. A+

2 1

Re: remove server silliniess
by Alexandre Julliard April 16, 2003

April 16, 2003

"Gregory M. Turner" <gmturner007(a)ameritech.net> writes: > remove run-time checks of compile-time constants. What's wrong with that? and how do you propose to do the check then? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: WineHQ: whitespace
by Jeremy Newman April 16, 2003

April 16, 2003

On Tue, 2003-04-15 at 14:55, Dimitrie O. Paun wrote: > Jer, > > When you apply my patches, please try to no change the whitespace, as it > creates conflicts on my side, and I can't tell if you've changed anything. > > I think you applied my patches from Windows, and the line endings changed, > or something like that. Please don't accuse me of using Windows. I would never do such a thing. ;) The problem comes from copy/paste the patch from my email prog (Evolution) to my text editor (Anjuta). I my web code, I prefer to use 4 spaces for indenting, no tab characters please. Don't give me the spaces take more time to transfer over http crap, our web server uses gzip encoding. <g> The patch was rejected by the patch command, so I had to manually line by line apply it (ish). In the future, attachments will be preferred for patches. I may just decide to not apply them otherwise.

3 4

Re: Keyboard Problem solved, one solution ...
by Dmitry Timoshkov April 16, 2003

April 16, 2003

"Duncan Rubinger" <duncan(a)semanticedge.de> wrote: > I have a german keyboard layout and I'm using RH9 and KDE 3.1 > > After trying out some Keyboard layout settings I got the idea to > change one entry: > > From: > /*AltGrMask = event->state & 0x6000;*/ > > To: > AltGrMask = event->state; > > Now it works. Looks reasonable to me. Probably we have to be a bit picky what flags we want to save/restore. Does the attached patch work for you? -- Dmitry.

1 0

!IsWindowVisible && SetMenu
by Michal Janusz Miroslaw April 16, 2003

April 16, 2003

When an app creates window without a menu, and later adds the menu without showing the window first, window's size doesn't update. Removing one if() in menu.c (as in patch attached) fixes it. (At least in DesignWorks 3.20. The app still hangs after showing it's windows, but at least menu is ok :). Is it a good fix, or the update should happen somewhere else when window is not visible ? -- Michal Miroslaw Index: controls/menu.c =================================================================== RCS file: /home/wine/wine/controls/menu.c,v retrieving revision 1.163 diff -u -r1.163 menu.c --- controls/menu.c 7 Mar 2003 23:03:27 -0000 1.163 +++ controls/menu.c 16 Apr 2003 09:43:49 -0000 @@ -3779,7 +3779,6 @@ } SetWindowLongA( hWnd, GWL_ID, (LONG_PTR)hMenu ); - if (IsWindowVisible(hWnd)) SetWindowPos( hWnd, 0, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOMOVE | SWP_NOACTIVATE | SWP_NOZORDER | SWP_FRAMECHANGED ); return TRUE;

1 0

Re: winedbg regression?
by Mike Hearn April 16, 2003

April 16, 2003

> I had this one: > [Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug] 996976720 > "Auto"="1" > "Debugger"="winedbg.exe --debugmsg -all %ld %ld" > > removing the '.exe' and adding --auto did not help. But i found the patch that > broke winedbg for me: > > http://www.winehq.com/hypermail/wine-cvs/2003/03/0371.html Hmm, more of Alexandres deep threading code. I don't really want to unapply that as I have no idea what it does or what its dependancies are. Alexandre, could you take a look at why this patch might have broken winedbg? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

winedbg improvement - display
by Michal Janusz Miroslaw April 16, 2003

April 16, 2003

I've just hacked winedbg 'display' handling. It now allows for temporary disabling of displays and restricting them to one function. Look for yourselves, comments welcome. :) Patch follows, -- Michal Miroslaw index: programs/winedbg/Makefile.in =================================================================== RCS file: /home/wine/wine/programs/winedbg/Makefile.in,v retrieving revision 1.2 diff -u -r1.2 Makefile.in --- programs/winedbg/Makefile.in 15 Dec 2002 01:19:53 -0000 1.2 +++ programs/winedbg/Makefile.in 16 Apr 2003 03:04:56 -0000 @@ -31,6 +31,8 @@ @MAKE_PROG_RULES@ +DEFS += -DYYERROR_VERBOSE + y.tab.c y.tab.h: dbg.y $(YACC) -d -t $(SRCDIR)/dbg.y Index: programs/winedbg/dbg.y =================================================================== RCS file: /home/wine/wine/programs/winedbg/dbg.y,v retrieving revision 1.9 diff -u -r1.9 dbg.y --- programs/winedbg/dbg.y 1 Apr 2003 00:12:50 -0000 1.9 +++ programs/winedbg/dbg.y 16 Apr 2003 03:04:56 -0000 @@ -52,8 +52,6 @@ %token tCONT tPASS tSTEP tLIST tNEXT tQUIT tHELP tBACKTRACE tINFO tWALK tUP tDOWN %token tENABLE tDISABLE tBREAK tWATCH tDELETE tSET tMODE tPRINT tEXAM tABORT tVM86 -%token tCLASS tMAPS tMODULE tSTACK tSEGMENTS tSYMBOL tREGS tWND tLOCAL tEXCEPTION -%token tPROCESS tTHREAD tEOL tEOF %token tCLASS tMAPS tMODULE tSTACK tSEGMENTS tSYMBOL tREGS tWND tQUEUE tLOCAL tEXCEPTION %token tPROCESS tTHREAD tMODREF tEOL tEOF %token tFRAME tSHARE tCOND tDISPLAY tUNDISPLAY tDISASSEMBLE @@ -137,13 +135,6 @@ | tSHOW tDIR tEOL { DEBUG_ShowDir(); } | tDIR pathname tEOL { DEBUG_AddPath( $2 ); } | tDIR tEOL { DEBUG_NukePath(); } - | tDISPLAY tEOL { DEBUG_InfoDisplay(); } - | tDISPLAY expr tEOL { DEBUG_AddDisplay($2, 1, 0); } - | tDISPLAY tFORMAT expr tEOL{ DEBUG_AddDisplay($3, $2 >> 8, $2 & 0xff); } - | tDELETE tDISPLAY tNUM tEOL{ DEBUG_DelDisplay( $3 ); } - | tDELETE tDISPLAY tEOL { DEBUG_DelDisplay( -1 ); } - | tUNDISPLAY tNUM tEOL { DEBUG_DelDisplay( $2 ); } - | tUNDISPLAY tEOL { DEBUG_DelDisplay( -1 ); } | tCOND tNUM tEOL { DEBUG_AddBPCondition($2, NULL); } | tCOND tNUM expr tEOL { DEBUG_AddBPCondition($2, $3); } | tSOURCE pathname tEOL { DEBUG_Parser($2); } @@ -154,6 +145,7 @@ | tDETACH tEOL { return DEBUG_Detach(); /* FIXME: we shouldn't return, but since we cannot simply clean the symbol table, exit debugger for now */ } | list_command | disassemble_command + | display_command | set_command | x_command | print_command @@ -163,6 +155,22 @@ | walk_command | run_command | noprocess_state + ; + +display_command: + | tDISPLAY tEOL { DEBUG_InfoDisplay(); } + | tDISPLAY expr tEOL { DEBUG_AddDisplay($2, 1, 0, FALSE); } + | tDISPLAY tFORMAT expr tEOL{ DEBUG_AddDisplay($3, $2 >> 8, $2 & 0xff, FALSE); } + | tDISPLAY tLOCAL expr tEOL { DEBUG_AddDisplay($3, 1, 0, TRUE); } + | tDISPLAY tLOCAL tFORMAT expr tEOL { DEBUG_AddDisplay($4, $3 >> 8, $3 & 0xff, TRUE); } + | tDISPLAY tDELETE tNUM tEOL{ DEBUG_DelDisplay( $3 ); } + | tDISPLAY tDELETE tEOL { DEBUG_DelDisplay( -1 ); } + | tDISPLAY tENABLE tNUM tEOL{ DEBUG_EnableDisplay( $3, TRUE ); } + | tDISPLAY tDISABLE tNUM tEOL { DEBUG_EnableDisplay( $3, FALSE ); } + | tDELETE tDISPLAY tNUM tEOL{ DEBUG_DelDisplay( $3 ); } + | tDELETE tDISPLAY tEOL { DEBUG_DelDisplay( -1 ); } + | tUNDISPLAY tNUM tEOL { DEBUG_DelDisplay( $2 ); } + | tUNDISPLAY tEOL { DEBUG_DelDisplay( -1 ); } ; set_command: Index: programs/winedbg/debug.l =================================================================== RCS file: /home/wine/wine/programs/winedbg/debug.l,v retrieving revision 1.3 diff -u -r1.3 debug.l --- programs/winedbg/debug.l 30 Jan 2003 00:24:18 -0000 1.3 +++ programs/winedbg/debug.l 16 Apr 2003 03:04:56 -0000 @@ -58,6 +58,7 @@ %s WALK_CMD %s SHOW_CMD %s MODE_CMD +%s DISP_CMD %s NOCMD %x ASTRING_EXPECTED @@ -86,12 +87,12 @@ "0x"{HEXDIGIT}+ { sscanf(yytext, "%x", &yylval.integer); return tNUM; } {DIGIT}+ { sscanf(yytext, "%d", &yylval.integer); return tNUM; } -<FORMAT_EXPECTED>"/"{DIGIT}+{FORMAT} { char* last; +<DISP_CMD,FORMAT_EXPECTED>"/"{DIGIT}+{FORMAT} { char* last; yylval.integer = strtol( yytext+1, &last, 0 ) << 8; yylval.integer |= *last; return tFORMAT; } -<FORMAT_EXPECTED>"/"{FORMAT} { yylval.integer = (1 << 8) | yytext[1]; return tFORMAT; } +<DISP_CMD,FORMAT_EXPECTED>"/"{FORMAT} { yylval.integer = (1 << 8) | yytext[1]; return tFORMAT; } {STRING} { yylval.string = DEBUG_MakeSymbol(yytext); return tSTRING; } <ASTRING_EXPECTED>[^\n]+ { char* p = yytext; while (*p == ' ' || *p == '\t') p++; @@ -105,7 +106,7 @@ <INITIAL>enable|enabl|enab|ena { BEGIN(NOCMD); return tENABLE;} <INITIAL>disable|disabl|disab|disa|dis { BEGIN(NOCMD); return tDISABLE; } <INITIAL>disassemble|disassembl|disassemb|disassem|disasse|disass|disas { BEGIN(NOCMD); return tDISASSEMBLE; } -<INITIAL,INFO_CMD,DEL_CMD>display|displa|displ|disp { BEGIN(FORMAT_EXPECTED); return tDISPLAY; } +<INITIAL,INFO_CMD,DEL_CMD>display|displa|displ|disp { BEGIN(DISP_CMD); return tDISPLAY; } <INITIAL>undisplay|undispla|undispl|undisp|undis|undi|und { BEGIN(NOCMD); return tUNDISPLAY; } <INITIAL>delete|delet|dele|del { BEGIN(DEL_CMD); return tDELETE; } <INITIAL,NOPROCESS>quit|qui|qu|q { BEGIN(NOCMD); return tQUIT; } @@ -155,6 +156,11 @@ <INFO_CMD,WALK_CMD>window|windo|wind|win|wnd { return tWND; } <HELP_CMD>info|inf|in { return tINFO; } <MODE_CMD>vm86 { return tVM86; } +<DISP_CMD>local { BEGIN(FORMAT_EXPECTED); return tLOCAL; } +<DISP_CMD>delete|delet|dele|del { BEGIN(NOCMD); return tDELETE; } +<DISP_CMD>enable|enabl|enab|ena|en { BEGIN(NOCMD); return tENABLE; } +<DISP_CMD>disable|disabl|disab|disa|dis { BEGIN(NOCMD); return tDISABLE; } + <INITIAL,SHOW_CMD>directories|directorie|directori|director|directo|direct|direc|direc|dir { BEGIN(PATH_EXPECTED); return tDIR; } Index: programs/winedbg/debugger.h =================================================================== RCS file: /home/wine/wine/programs/winedbg/debugger.h,v retrieving revision 1.9 diff -u -r1.9 debugger.h --- programs/winedbg/debugger.h 1 Apr 2003 00:02:36 -0000 1.9 +++ programs/winedbg/debugger.h 16 Apr 2003 03:04:56 -0000 @@ -327,10 +327,11 @@ extern int DEBUG_ReadLine(const char* pfx, char* buffer, int size); /* debugger/display.c */ -extern int DEBUG_DoDisplay(void); -extern int DEBUG_AddDisplay(struct expr * exp, int count, char format); -extern int DEBUG_DelDisplay(int displaynum); -extern int DEBUG_InfoDisplay(void); +int DEBUG_DoDisplay(void); +int DEBUG_AddDisplay(struct expr * exp, int count, char format, int local_frame); +int DEBUG_DelDisplay(int displaynum); +int DEBUG_InfoDisplay(void); +int DEBUG_EnableDisplay(int displaynum, int enable); /* debugger/expr.c */ extern void DEBUG_FreeExprMem(void); @@ -386,6 +387,7 @@ struct datatype * type); extern BOOL DEBUG_Normalize(struct name_hash * nh ); void DEBUG_InfoSymbols(const char* str); +const char *DEBUG_GetSymbolName(const struct name_hash *); /* debugger/info.c */ extern void DEBUG_PrintBasic( const DBG_VALUE* value, int count, char format ); Index: programs/winedbg/display.c =================================================================== RCS file: /home/wine/wine/programs/winedbg/display.c,v retrieving revision 1.1 diff -u -r1.1 display.c --- programs/winedbg/display.c 13 Sep 2002 17:54:28 -0000 1.1 +++ programs/winedbg/display.c 16 Apr 2003 03:04:56 -0000 @@ -2,6 +2,7 @@ * File display.c - display handling for Wine internal debugger. * * Copyright (C) 1997, Eric Youngdale. + * Improved a bit by Michał Mirosław. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -27,130 +28,172 @@ #include <stdarg.h> -#define MAX_DISPLAY 25 +#define DISPTAB_DELTA 8 /* needs to be power of 2, search for MARK to see why :) */ -struct display -{ - struct expr * exp; - int count; - char format; +struct display { + struct expr *exp; + int count; + char format; + char enabled; + struct name_hash *frame_name; }; -static struct display displaypoints[MAX_DISPLAY]; +static struct display *displaypoints = NULL; +static unsigned int maxdisplays = 0, ndisplays = 0; -int -DEBUG_AddDisplay(struct expr * exp, int count, char format) +static struct name_hash *DEBUG_GetCurrentFrameName(void) { - int i; + struct name_hash *name; + unsigned int eip, ebp; - /* - * First find a slot where we can store this display. - */ - for(i=0; i < MAX_DISPLAY; i++ ) - { - if( displaypoints[i].exp == NULL ) - { - displaypoints[i].exp = DEBUG_CloneExpr(exp); - displaypoints[i].count = count; - displaypoints[i].format = format; - break; - } - } - - return TRUE; -} - -int -DEBUG_InfoDisplay(void) -{ - int i; - - /* - * First find a slot where we can store this display. - */ - for(i=0; i < MAX_DISPLAY; i++ ) - { - if( displaypoints[i].exp != NULL ) - { - DEBUG_Printf(DBG_CHN_MESG, "%d : ", i+1); - DEBUG_DisplayExpr(displaypoints[i].exp); - DEBUG_Printf(DBG_CHN_MESG, "\n"); - } - } - - return TRUE; -} - -int -DEBUG_DoDisplay(void) -{ - DBG_VALUE value; - int i; - - /* - * First find a slot where we can store this display. - */ - for(i=0; i < MAX_DISPLAY; i++ ) - { - if( displaypoints[i].exp != NULL ) - { - value = DEBUG_EvalExpr(displaypoints[i].exp); - if( value.type == NULL ) - { - DEBUG_Printf(DBG_CHN_MESG, "Unable to evaluate expression "); - DEBUG_DisplayExpr(displaypoints[i].exp); - DEBUG_Printf(DBG_CHN_MESG, "\nDisabling...\n"); - DEBUG_DelDisplay(i); - } - else - { - DEBUG_Printf(DBG_CHN_MESG, "%d : ", i + 1); - DEBUG_DisplayExpr(displaypoints[i].exp); - DEBUG_Printf(DBG_CHN_MESG, " = "); - if( displaypoints[i].format == 'i' ) - { - DEBUG_ExamineMemory( &value, - displaypoints[i].count, - displaypoints[i].format); - } - else - { - DEBUG_Print( &value, - displaypoints[i].count, - displaypoints[i].format, 0); + if (DEBUG_GetCurrentFrame(&name, &eip, &ebp)) + return name; + return NULL; +} + +int DEBUG_AddDisplay(struct expr *exp, int count, char format, int in_frame) +{ + int i; + + for (i = 0; i < ndisplays; i++) + if (displaypoints[i].exp == NULL) + break; + + if (i == maxdisplays) /* no space left - expand */ + displaypoints = DBG_realloc(displaypoints, + (maxdisplays += DISPTAB_DELTA) * sizeof(*displaypoints)); + + if (i == ndisplays) + ++ndisplays; + + displaypoints[i].exp = DEBUG_CloneExpr(exp); + displaypoints[i].count = count; + displaypoints[i].format = format; + displaypoints[i].enabled = TRUE; + displaypoints[i].frame_name = + (in_frame ? DEBUG_GetCurrentFrameName() : NULL); + + return TRUE; +} + +int DEBUG_InfoDisplay(void) +{ + int i; + + for (i = 0; i < ndisplays; i++) { + if (displaypoints[i].exp == NULL) + continue; + + if (displaypoints[i].frame_name) + DEBUG_Printf(DBG_CHN_MESG, "%d in %s%s : ", i + 1, + DEBUG_GetSymbolName(displaypoints[i].frame_name), + (displaypoints[i].enabled ? + (displaypoints[i].frame_name != DEBUG_GetCurrentFrameName() ? + " (out of scope)" : "") + : " (disabled)") + ); + else + DEBUG_Printf(DBG_CHN_MESG, "%d%s : ", i + 1, + (displaypoints[i].enabled ? "" : " (disabled)")); + DEBUG_DisplayExpr(displaypoints[i].exp); + DEBUG_Printf(DBG_CHN_MESG, "\n"); + } + + return TRUE; +} + +void DEBUG_PrintOneDisplay(int i) +{ + DBG_VALUE value; + + if (displaypoints[i].enabled) { + value = DEBUG_EvalExpr(displaypoints[i].exp); + if (value.type == NULL) { + DEBUG_Printf(DBG_CHN_MESG, "Unable to evaluate expression "); + DEBUG_DisplayExpr(displaypoints[i].exp); + DEBUG_Printf(DBG_CHN_MESG, "\nDisabling display %d ...\n", i + 1); + displaypoints[i].enabled = FALSE; + return; } - } } - } - return TRUE; + DEBUG_Printf(DBG_CHN_MESG, "%d : ", i + 1); + DEBUG_DisplayExpr(displaypoints[i].exp); + DEBUG_Printf(DBG_CHN_MESG, " = "); + if (!displaypoints[i].enabled) + DEBUG_Printf(DBG_CHN_MESG, "(disabled)\n"); + else + if (displaypoints[i].format == 'i') + DEBUG_ExamineMemory(&value, displaypoints[i].count, displaypoints[i].format); + else + DEBUG_Print(&value, displaypoints[i].count, displaypoints[i].format, 0); } -int -DEBUG_DelDisplay(int displaynum) -{ - int i; - - if( displaynum >= MAX_DISPLAY || displaynum == 0 || displaynum < -1 ) - { - DEBUG_Printf(DBG_CHN_MESG, "Invalid display number\n"); - return TRUE; - } - if( displaynum == -1 ) - { - for(i=0; i < MAX_DISPLAY; i++ ) - { - if( displaypoints[i].exp != NULL ) - { - DEBUG_FreeExpr(displaypoints[i].exp); - displaypoints[i].exp = NULL; - } - } - } - else if( displaypoints[displaynum - 1].exp != NULL ) - { - DEBUG_FreeExpr(displaypoints[displaynum - 1].exp); - displaypoints[displaynum - 1].exp = NULL; - } - return TRUE; +int DEBUG_DoDisplay(void) +{ + int i; + struct name_hash *cur_frame_name = DEBUG_GetCurrentFrameName(); + + for (i = 0; i < ndisplays; i++) { + if (displaypoints[i].exp == NULL || !displaypoints[i].enabled) + continue; + if (displaypoints[i].frame_name + && displaypoints[i].frame_name != cur_frame_name) + continue; + DEBUG_PrintOneDisplay(i); + } + + return TRUE; +} + +int DEBUG_DelDisplay(int displaynum) +{ + int i; + + if (displaynum > ndisplays || displaynum == 0 || displaynum < -1 + || displaypoints[displaynum - 1].exp == NULL) { + DEBUG_Printf(DBG_CHN_MESG, "Invalid display number\n"); + return TRUE; + } + + if (displaynum == -1) { + for (i = 0; i < ndisplays; i++) { + if (displaypoints[i].exp != NULL) { + DEBUG_FreeExpr(displaypoints[i].exp); + displaypoints[i].exp = NULL; + } + } + displaypoints = DBG_realloc(displaypoints, + (maxdisplays = DISPTAB_DELTA) * sizeof(*displaypoints)); + ndisplays = 0; + } else if (displaypoints[--displaynum].exp != NULL) { + DEBUG_FreeExpr(displaypoints[displaynum].exp); + displaypoints[displaynum].exp = NULL; + while (displaynum == ndisplays - 1 + && displaypoints[displaynum].exp == NULL) + --ndisplays, --displaynum; + if (maxdisplays - ndisplays >= 2 * DISPTAB_DELTA) { + maxdisplays = (ndisplays + DISPTAB_DELTA - 1) & ~(DISPTAB_DELTA - 1); /* MARK */ + displaypoints = DBG_realloc(displaypoints, + maxdisplays * sizeof(*displaypoints)); + } + } + return TRUE; } + +int DEBUG_EnableDisplay(int displaynum, int enable) +{ + --displaynum; + if (displaynum >= ndisplays || displaynum < 0 || displaypoints[displaynum].exp == NULL) { + DEBUG_Printf(DBG_CHN_MESG, "Invalid display number\n"); + return TRUE; + } + + displaypoints[displaynum].enabled = enable; + if (!displaypoints[displaynum].frame_name + || displaypoints[displaynum].frame_name == DEBUG_GetCurrentFrameName()) + DEBUG_PrintOneDisplay(displaynum); + + return TRUE; +} + Index: programs/winedbg/hash.c =================================================================== RCS file: /home/wine/wine/programs/winedbg/hash.c,v retrieving revision 1.7 diff -u -r1.7 hash.c --- programs/winedbg/hash.c 19 Feb 2003 03:41:48 -0000 1.7 +++ programs/winedbg/hash.c 16 Apr 2003 03:04:57 -0000 @@ -1314,6 +1314,11 @@ return TRUE; } +const char *DEBUG_GetSymbolName(const struct name_hash * sym) +{ + return sym->name; +} + #ifdef HAVE_REGEX_H static int cmp_sym_by_name(const void * p1, const void * p2) Index: programs/winedbg/info.c =================================================================== RCS file: /home/wine/wine/programs/winedbg/info.c,v retrieving revision 1.5 diff -u -r1.5 info.c --- programs/winedbg/info.c 14 Feb 2003 19:22:48 -0000 1.5 +++ programs/winedbg/info.c 16 Apr 2003 03:04:57 -0000 @@ -214,6 +214,8 @@ " stepi [N] nexti [N]", " x <addr> print <expr>", " display <expr> undisplay <disnum>", +" display local <expr> display delete <disnum>", +" display enable <disnum> display disable <disnum>", " delete display <disnum> pass", " bt frame <n>", " up down",

1 0

Fwd: Keyboard Problem solved, one solution ...
by Sylvain Petreolle April 16, 2003

April 16, 2003

What do you think of this fix ? ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Winelib _alloca/alloca linking problem
by Vincent Béron April 15, 2003

April 15, 2003

Ok, so this won't get into CVS (way too "hacked until it works for me and only me"), but I don't know where to look further. Can somebody explain me where _alloca is supposed to be implemented/forwarded/ends up being called? The provided small program should be able to compile with either _alloca or alloca being called. Under Winelib, with the current msvcrt headers, _alloca is not found at all and linking fails. With the included patch, the program runs. Should I add a forward in msvcrt.spec from _alloca to MSVCRT_alloca, which itself calls (glibc's) alloca? Or is there something obvious I missed? Vincent Index: wine/include/msvcrt/malloc.h =================================================================== RCS file: /home/wine/wine/include/msvcrt/malloc.h,v retrieving revision 1.5 diff -u -r1.5 malloc.h --- wine/include/msvcrt/malloc.h 22 Mar 2003 21:15:41 -0000 1.5 +++ wine/include/msvcrt/malloc.h 15 Apr 2003 23:34:34 -0000 @@ -79,9 +79,6 @@ } #endif - -#ifndef USE_MSVCRT_PREFIX -static inline void* alloca(MSVCRT(size_t) i) { return _alloca(i); } -#endif /* USE_MSVCRT_PREFIX */ +static inline void* _alloca(MSVCRT(size_t) i) { return alloca(i); } #endif /* __WINE_MALLOC_H */ #include <malloc.h> #include <stdio.h> #include <stdlib.h> char *mp() { char *p; p = _alloca(2); p[0] = 0x41; /* A */ p[1] = 0; return p; } int main(void) { char *p; p = mp(); printf("%02x %02x\n", p[0], p[1]); exit(0); return 0; }

1 0

Re: version patch
by Vincent Béron April 15, 2003

April 15, 2003

Andreas Mohr a écrit: > @@ -162,16 +174,18 @@ > }, > /* NT2K */ > { > + "Windows 2000", > 0x05005F03, > 0x08930005, > { > sizeof(OSVERSIONINFOA), 5, 0, 0x893, > VER_PLATFORM_WIN32_NT, "Service Pack 2", > - 2, 0, 0, VER_NT_WORKSTATION, 30 /* FIXME: Great, a reserved field with a value! */ > + 2, 0, 0, VER_NT_WORKSTATION, 30 /* FIXME: Great, a reserved field with a value! Is this correct? */ I still have this value (30) on 2K SP3. What do others have for 2K and XP (see attached program)? Besides, shouldn't we report SP3 for NT2K? And SP1 for XP? Vincent #include <windows.h> #include <stdio.h> typedef struct _OSVERSIONINFOEXAB { DWORD dwOSVersionInfoSize; DWORD dwMajorVersion; DWORD dwMinorVersion; DWORD dwBuildNumber; DWORD dwPlatformId; CHAR szCSDVersion[ 128 ]; // Maintenance string for PSS usage WORD wServicePackMajor; WORD wServicePackMinor; WORD wSuiteMask; BYTE wProductType; BYTE wReserved; } OSVERSIONINFOEXAB, *POSVERSIONINFOEXAB, *LPOSVERSIONINFOEXAB; int main(void) { OSVERSIONINFOEXAB ver; ver.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEXAB); GetVersionExA((OSVERSIONINFOA *) &ver); printf("%d %d %d %d %d \"%s\" %d %d %d %d %d\n", ver.dwOSVersionInfoSize, ver.dwMajorVersion, ver.dwMinorVersion, ver.dwBuildNumber, ver.dwPlatformId, ver.szCSDVersion, ver.wServicePackMajor, ver.wServicePackMinor, ver.wSuiteMask, ver.wProductType, ver.wReserved); exit(0); return 0; }

2 1