wine-devel

wine-devel@winehq.org

9 participants
84457 discussions

Re: Set TZ environment variable when not set
by Michael Stefaniuc 16 Apr '03

16 Apr '03

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 16 Apr '03

16 Apr '03

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 16 Apr '03

16 Apr '03

> 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 16 Apr '03

16 Apr '03

"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 16 Apr '03

16 Apr '03

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 16 Apr '03

16 Apr '03

"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 16 Apr '03

16 Apr '03

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 16 Apr '03

16 Apr '03

> 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 16 Apr '03

16 Apr '03

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 16 Apr '03

16 Apr '03

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 15 Apr '03

15 Apr '03

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 15 Apr '03

15 Apr '03

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

manual patch tracking system for ntdll
by thomas.mertes＠gmx.at 15 Apr '03

15 Apr '03

Hello Since I am following the ntdll development, I noticed some not applied patches: - Ntdll atom stuff: http://www.winehq.com/hypermail/wine-patches/2003/04/0064.html - Ntdll atom tests. http://www.winehq.com/hypermail/wine-patches/2003/04/0065.html The tests where verified by Dmitry Timoshkov in this mail: http://www.winehq.com/hypermail/wine-devel/2003/04/0192.html - Resend: Implement some ACE functions http://www.winehq.com/hypermail/wine-patches/2003/04/0129.html IMHO, if a patch is correct (can be verified by tests) it should be applied, even if no application needs this functions (at the moment). If this functions are needed later, some implementation (with FIXMEs) is already there as base for further development. This is easier than looking for a (possibly outdated) patch in the archieves. I see the wine source also as a information repository, which is easier to access, than a patch archive. In the worst case it should be possible that a function is accepted but deactivated with #ifdef. Greetings Thomas Mertes -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!

3 2

Re: Fall back to ttydrv
by Dimitrie O. Paun 15 Apr '03

15 Apr '03

On April 14, 2003 06:11 pm, Uwe Bonnes wrote: > + MESSAGE( "Falling back to ttydrv\n"); Again, I'd say this message is not appropriate, especially now that the user has to enable this configurations. For people using command line tools under Wine will be just pure spam. -- Dimi.

5 6

Cross compiling tests
by Hans Leidekker 15 Apr '03

15 Apr '03

Hi, I'm trying to cross compile the regression tests using MinGW as a cross compiler (i.e. I have installed the MinGW cross compiler on Linux and run 'make crosstest'). First problem I encountered was that my versions of the compiler and dlltool weren't detected at configure stage. Mine are called i386-mingw-gcc and i386-mingw-dlltool, whereas configure looks for i586-mingw32msvc-gcc and i586-mingw32msvc-dlltool. I've sent a patch to wine-patches that adds the former names to the configure check. Second major problem happens at the build stage. The Makefile for a test specifies -L$(DLLDIR) when linking the test executables, which is where the *Wine* libraries reside. I think this is wrong, we should link against the target platform libraries (MinGW in this case) when cross compiling. Removing -L$(DLLDIR) from the Makefile also solves a conflict that arises from the fact that both MinGW and Wine have an implementation of the C runtime: make crosstest i386-mingw32-gcc generated.cross.o testlist.cross.o -o urlmon_crosstest.exe -L../../../dlls -lurlmon -lm ../../../dlls/libmsvcrt.a(ds00443.o)(.text+0x0): multiple definition of `atexit' /usr/local/lib/gcc-lib/i386-mingw32/3.2.2/../../../../i386-mingw32/lib/crt2.o(.text+0x230):/usr/src/redhat/BUILD/mingw-2.4/mingw-runtime-2.4/crt1.c:266: first defined here ../../../dlls/libmsvcrt.a(ds00319.o)(.text+0x0): multiple definition of `_onexit' /usr/local/lib/gcc-lib/i386-mingw32/3.2.2/../../../../i386-mingw32/lib/crt2.o(.text+0x250):/usr/src/redhat/BUILD/mingw-2.4/mingw-runtime-2.4/crt1.c:274: first defined here Patch sent to wine-patches. Now most tests happily compile ;-). I have two tests left that have problems linking. It appears that they use symbols that are not available in any import library (not even Wine's): i386-mingw32-gcc dsound.cross.o testlist.cross.o -o dsound_crosstest.exe -ldsound -luser32 -lkernel32 -lm dsound.cross.o(.text+0x1656): In function `dsenum_callback': /usr/local/src/wine-cvs/wine/dlls/dsound/tests/dsound.c:403: undefined reference to `wine_dbgstr_guid' dsound.cross.o(.text+0x24dd): In function `dscenum_callback': /usr/local/src/wine-cvs/wine/dlls/dsound/tests/dsound.c:649: undefined reference to `wine_dbgstr_guid' make: *** [dsound_crosstest.exe] Error 1 The wine_ prefix suggests that this is a Wine internal function, so it will never be avaliable on Windows/MinGW. Can these be removed? Or is there an alternative that works on all platforms? This is the other one that fails: i386-mingw32-gcc safearray.cross.o vartest.cross.o testlist.cross.o -o oleaut32_crosstest.exe -loleaut32 -lm safearray.cross.o(.text+0x1496): In function `func_safearray': /usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:277: undefined reference to `IID_IUnknown' safearray.cross.o(.text+0x14d1):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:278: undefined reference to `IID_IUnknown' safearray.cross.o(.text+0x150e):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:281: undefined reference to `IID_IDispatch' safearray.cross.o(.text+0x1549):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:282: undefined reference to `IID_IDispatch' make: *** [oleaut32_crosstest.exe] Error 1 Same problem I guess. Any suggestion as to how this one might be fixed is welcome. -Hans

3 10

mouse_event()
by Brad Campbell 15 Apr '03

15 Apr '03

G'day all, I have been doing some testing of the mouse_event call in windows and wine. There is only one incompatibility that I can see. In windows 95, a call to mouse_event does not _move_ the mouse pointer, whereas in wine, the mouse pointer follows the mouse. In windows, I have to make a call to mouse_event then another call to setcursorpos() to make the pointer follow the mouse. When using a touchscreen for input, we use a setcursorpos() call to move the mouse pointer off the screen, and then just feed windows mouse_event calls with the position and button state. This works under wine, but of course the pointer follows the mouse_event. It looks like this would be difficult to fix as from what I can see the pointer movement seems to be pretty closely tied to the mouse position. Any ideas? -- Brad.... /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \

1 0

Re: Better fix for named pipe problem.
by Gregory M. Turner 14 Apr '03

14 Apr '03

FYI fixing the linewraps in the patch and applying does indeed stop the wineserver from crashing using the experimental pipe.c, and runs fine against CVS's pipe.c. However, also FWIW, using the experimental pipe.c from Bill, I still get a pipe.ok when I shouldn't doing make test... -- gmt "Democracy is the theory that holds that the common people know what they want, and deserve to get it good and hard." HL Mencken

1 0

re: Is it possible to call DLL functions from a Linux program?
by Dan Kegel 14 Apr '03

14 Apr '03

Eloy wrote: > Now, I want to run this program natively under Linux - I mean, I don't > want to run wcmd because that requires an X server. I suggest just running your little Windows program under Wine. Don't use wcmd, you don't need it. For instance, in my ~/bin, I have a shell script winword which just contains wine -- "c:\\Program Files\\Microsoft Office\\Office\\winword.exe" "$@" That more or less lets me run microsoft word from the commandline. You can configure wine to not require X. I've done it on some commandline Windows programs I wanted to use in shell scripts on Linux. It was and is a pain, I believe, because so few of the Wine developers use commandline Windows programs without X, but it is doable. (And maybe it's easier than it used to be; I don't know.) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

3 6

Bug: "Type" = "cdrom" allows writing !!
by Sylvain Petreolle 14 Apr '03

14 Apr '03

Trying to run "dir >test" in a drive set to "Type" = "Cdrom" will create a test file containing the directory listing. Test case: [Drive W] "Path" = "/home/wine" "Type" = "cdrom" "Label" = "WineSrc" "Filesystem" = "win95" [syl@snoop wine]$ ls -l z ls: z: No such file or directory [syl@snoop wine]$ wcmd fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (French keyboard layout) for scancode mapping. Please define your layout in windows/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. WCMD Version 0.17 W:\>dir >z W:\>exit [syl@snoop wine]$ ls -l z -rw-r--r-- 1 syl wine 2413 Apr 14 23:59 z ===== 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

Re: OLE storage SetFilePointer fix
by Dimitrie O. Paun 14 Apr '03

14 Apr '03

On Sat, 12 Apr 2003, Andreas Mohr wrote: > P.S.: Alexandre, I'd REALLY like you to finally put a patch status > tracking system in place. The number of people submitting patches > for the second, third, bazillionth time is astonishing (I speak > from my very own experience, too!). I really don't know how many very > valuable Wine patches got lost due to not getting applied without any > status reply whatsoever... > (particularly the ones from "foreigners") > Someone recently said (in WWN) that patch management was perfect or > something to that extent. I better don't comment on that statement, > you know my hot temper ;) > OK, it's definitely not awful, but I guess it could be better. First off, I don't think the current system is bad. Second, I was the one this in the WWN (so sue me :P). Any system that we would put in place would have to work with email just like the current one. Other suck big time, see the SF one. Once you notice that, you realize that the problem is not the system, but rather that Alexandre needs to reply to patches he rejects, wether through email/web based form/what have you. Don't get me wrong -- I've been multiple times at the rejecting end of this, and it's frustrating. But in retrospective, it's all for a better Wine, and I'd be hard pressed to produce a patch which got rejected by Alexandre, and which I still think should be applied. Also, your assesment that 'very many valuable Wine patches got lost' is a gross exageration. In fact, please produce 3 such patches that got lost in the last year (heck, in the last 3 years for that matter). I think you'll have a hard time finding a single such patch in the last X years (choose X as you may) that match your description. There is good reason for this: people put work into their patches, and if they don't get apply, they ask why. This is where I don't understand Alexandre: he will eventually have to reply to such questions, why not do it proactively, it's the same amount of work, me thinks. But I'm not the one putting in the time and effort to sort through the patches, so I may be missing many things. -- Dimi.

4 4

patch tracking system redux
by Dan Kegel 14 Apr '03

14 Apr '03

Steven Edwards (steven_ed4153(a)yahoo.com) wrote: > --- Dominik Strasser <Dominik.Strasser(a)t-online.de> wrote: >> The attached patch implements proxies in wininet to an extent that at >> least IE6 install works behind a firewall. >> >> ChangeLog: >> partially implement proxy support in wininet >> >> This is the third time I am sending this patch. Is anything wrong with it ? > > I think we are starting to see we need a patch tracking system =) I think Alexandre feels differently. Have you read http://www.winehq.com/hypermail/wine-devel/2003/04/0384.html ? I do know of one patch tracking system that works well (http://www.kernel.org/pub/linux/kernel/people/rusty/trivial/). It's restricted to "trivial" patches, and wouldn't handle the wininet proxy change, but might still be useful for Wine. I dunno. Alexandre silently ignored several of my patches recently, but that's just fine with me. They needed more work, and it was pretty obvious to me which direction I needed to go in to make him happy. Since I care about them, I will keep plugging away until they meet his criteria. - Dan

1 0

Re: lostwages/templates/en todo_lists.template
by Vincent Béron 14 Apr '03

14 Apr '03

Jeremy Newman a écrit: > ChangeSet ID: 7866 > CVSROOT: /opt/cvs-commit > Module name: lostwages > Changes by: jnewman(a)wine.codeweavers.com 2003/04/14 11:03:55 > > Modified files: > templates/en : todo_lists.template > > Log message: > Dimitrie O. Paun <dpaun(a)rogers.com> > Update TODO Lists to Wine 0.9 TODO v0.8 from: > Â http://www.dssd.ca/wine/Wine-0.9-TODO-0.8.html > > Patch: http://cvs.winehq.com/patch.py?id=7866 > > Old revision New revision Changes Path > 1.4 1.5 +281 -258 lostwages/templates/en/todo_lists.template It would be nice if my last name (and maybe other people's names) wouldn't be mangled. This is due to the <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> in the header of the page, but with the use of UTF-8 chars in the body. On Dimi's site it looks fine (same header, but use of iso-8859-1 chars in the body). It might be in the transfer that the characters get transformed (had to chase something akin to that yesterday with a text attachment in Evolution). Vincent

1 0

Is it possible to call DLL functions from a Linux program?
by Eloy A. Paris 14 Apr '03

14 Apr '03

Hi! Sorry if this has been covered before, but I could not find any answers in the archives or by Googling... Here's the situation: I have a Windows DLL and a small Windows program that calls functions from this DLL. The Windows program does not have a GUI (it's command-line based.) I have the C source code for this program, but don't have the source code for the DLL. I built the program with Visual C and was able to run it under WINE just fine with wcmd. Now, I want to run this program natively under Linux - I mean, I don't want to run wcmd because that requires an X server. The first question is: is this possible? (have a Unix program that calls functions from a native Windows DLL). I started experimenting with winelib, but am not sure if this is the correct way... If this is possible, how should I do it? I ran winemaker, configure, make, but am getting errors from winbebuild. Summarizing: I have the C source code. This C program calls function foo() that is in a Windows DLL. I want to run this program under Linux without the need for an X server. The program calls gets(), printf(), etc. I want these functions to be from my Linux's libc, not Windows'. Any help will be greatly appreciated. Thanks in advance! Eloy.- P.S. I read the winelib user guide, but couldn't find the answer there. If it is there, it's not clear to me :(

4 4

Re: Implement proxies in wininet
by Steven Edwards 14 Apr '03

14 Apr '03

--- Dominik Strasser <Dominik.Strasser(a)t-online.de> wrote: > The attached patch implements proxies in wininet to an extent that at > least IE6 install works behind a firewall. > > ChangeLog: > partially implement proxy support in wininet > > This is the third time I am sending this patch. Is anything wrong with it ? I think we are starting to see we need a patch tracking system =) Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com

1 0

Latest wine tarball not compiling with egcs and --disable-debug
by Gabriele 14 Apr '03

14 Apr '03

Hi all, I'm trying to compile wine 20030408 with a pretty old compiler which is gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) If I run the configure scipt without passing --disable-debug and --disable-trace and then make depend && make everything builds just fine. If I disable debug and trace and then run make I get some errors. The first problem is with some defines in debug.c ../../include/wine/debug.h:84: warning: invalid character in macro parameter name ../../include/wine/debug.h:84: badly punctuated parameter list in `#define' I had to add a string before the '...' to bypass the error: #ifdef NO_DEBUG_MSGS #define WINE_WARN(arg...) do { } while(0) #define WINE_WARN_(ch) WINE_WARN #define WINE_FIXME(arg...) do { } while(0) #define WINE_FIXME_(ch) WINE_FIXME #endif The other error is the following : make[2]: Entering directory `/home/gabriele/wine-20030408/dlls/oleaut32' gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -gstabs+ -fPIC -D__WINESRC__ -D_OLEAUT32_ -DCOM_NO_WINDOWS_H -D_REENTRANT -o typelib.o typelib.c typelib.c: In function `ITypeLib2_fnGetTypeComp': typelib.c:3393: warning: unused variable `This' typelib.c: In function `ITypeLib2_fnReleaseTLibAttr': typelib.c:3584: warning: unused variable `This' typelib.c: In function `ITypeLib2_fnGetLibStatistics': typelib.c:3629: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnGetTypeComp': typelib.c:3870: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnAddressOfMember': typelib.c:4765: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnCreateInstance': typelib.c:4778: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnGetMops': typelib.c:4790: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnReleaseTypeAttr': typelib.c:4828: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnReleaseFuncDesc': typelib.c:4840: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnReleaseVarDesc': typelib.c:4851: warning: unused variable `This' gcc: Internal compiler error: program cc1 got fatal signal 11 make[2]: *** [typelib.o] Error 1 make[2]: Leaving directory `/home/gabriele/wine-20030408/dlls/oleaut32' make[1]: *** [oleaut32] Error 2 make[1]: Leaving directory `/home/gabriele/wine-20030408/dlls' make: *** [dlls] Error 2

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel