- Wine-Devel - list.winehq.org

small updates to debugger.sgml
by Tony Lambregts Dec. 7, 2002

Dec. 7, 2002

Before I could feel right about adding "Advanced Debugging Techniques" to the documnetation I needed to update the documentation on the debugger. There is still one section that is out of date (that I am aware of). The section that I am refering to is as follows > Program hangs, nothing happens > > Switch to UNIX shell, get the process-ID using ps -a | grep wine, and > do a kill -HUP <pid> (without the < and >). Wine will then enter its > internal debugger and you can proceed as explained above. Also, you > can use --debug switch and then you can get into internal debugger by > pressing Ctrl-C in the terminal where you run Wine. > This is _wrong_ since neither work. I have added a fix me message in front of this since I am unable to come up with anything usefull to replace it. If anyone has a usefull suggestion I would appreciate it. Change log: Update the debugger documentation for current usage. Files: /documnetation/debugger.sgml -- Tony Lambregts Index: debugger.sgml =================================================================== RCS file: /home/wine/wine/documentation/debugger.sgml,v retrieving revision 1.13 diff -u -r1.13 debugger.sgml --- debugger.sgml 1 Oct 2002 18:13:09 -0000 1.13 +++ debugger.sgml 29 Nov 2002 06:08:53 -0000 @@ -271,8 +271,9 @@ <para> This file describes where to start debugging Wine. If at any point you get stuck and want to ask for help, please read the - file <filename>documentation/bugreports</filename> for - information on how to write useful bug reports. + <emphasis>How to Report A Bug</emphasis> section of the + <emphasis>Wine Users Guide</emphasis> for information on how to write + useful bug reports. </para> <sect2> @@ -311,8 +312,7 @@ <para> Steps to debug a crash. You may stop at any step, but please report the bug and provide as much of the information - gathered to the newsgroup or the relevant developer as - feasible. + gathered to the bug report as feasible. </para> <orderedlist> @@ -362,17 +362,26 @@ If you have found a misbehaving function, try to find out why it misbehaves. Find the function in the source code. Try to make sense of the arguments passed. Usually there is - a <function>TRACE(<channel>,"(...)\n");</function> at - the beginning of the function. Rerun wine with + a <function>WINE_DEFAULT_DEBUG_CHANNEL(<channel>);</function> + at the beginning of the file. Rerun wine with <parameter>-debugmsg +xyz,+relay</parameter> added to the commandline. </para> + <para> + Occasionally there are additional debug channels defined at the + begining of the file in the form. + <function>WINE_DECLARE_DEBUG_CHANNEL(<channel>);</function> + If so the offending fuction may also uses one of these alternate + channels. Look through the the function for + <function>TRACE_(<channel>)(" ... /n");</function> and add any + additional channels to the commandline. + </para> </listitem> <listitem> <para> Additional information on how to debug using the internal debugger can be found in - <filename>debugger/README</filename>. + <filename>programs/winedbg/README</filename>. </para> </listitem> <listitem> @@ -386,29 +395,25 @@ </listitem> <listitem> <para> - If even that isn't enough, add more debug output for - yourself into the functions you find relevant. See - <filename>documentation/debug-msgs</filename>. You might + If even that isn't enough, add more debug output for yourself + into the functions you find relevant. See The section on Debug + Logging in this guide for more information. You might also try to run the program in <command>gdb</command> instead of using the WINE-debugger. If you do that, use <parameter>handle SIGSEGV nostop noprint</parameter> to disable the handling of seg faults inside - <command>gdb</command> (needed for Win16). If you don't use - the <parameter>--desktop</parameter> or - <parameter>--managed</parameter> option, start the WINE - process with <parameter>--sync</parameter>, or chances are - good to get X into an unusable state. + <command>gdb</command> (needed for Win16). </para> </listitem> <listitem> <para> - You can also set a breakpoint for that function. Start wine - with the <parameter>--debug</parameter> option added to the - commandline. After loading the executable wine will enter - the internal debugger. Use <parameter>break - KERNEL_LSTRLEN</parameter> (replace by function you want - to debug, CASE IS RELEVANT) to set a breakpoint. Then use - <command>continue</command> to start normal + You can also set a breakpoint for that function. Start wine + useing <command>winedbg</command> instead of + <command>wine</command>. Once the debugger is is running enter + <command>break</command> <parameter>KERNEL_LSTRLEN</parameter> + (replace by function you want to debug, CASE IS RELEVANT) + to set a breakpoint. Then + use <command>continue</command> to start normal program-execution. Wine will stop if it reaches the breakpoint. If the program isn't yet at the crashing call of that function, use <command>continue</command> again @@ -425,6 +430,7 @@ <title>Program hangs, nothing happens</title> <para> + <emphasis>Fix me - this is out of date </emphasis> Switch to UNIX shell, get the process-ID using <command>ps -a | grep wine</command>, and do a <command>kill -HUP <pid></command> (without the < and >). Wine will @@ -449,8 +455,7 @@ </para> <para> Since the failure happens usually directly before setting up - the Messagebox you can start wine with - <parameter>--debug</parameter> added to the commandline, set a + the Messagebox you can start winedbg and set a breakpoint at <function>MessageBoxA</function> (called by win16 and win32 programs) and proceed with <command>continue</command>. With <parameter>--debugmsg

2 3

Re: Some fixes in capabilities
by Andreas Mohr Dec. 7, 2002

Dec. 7, 2002

On Tue, Nov 26, 2002 at 10:23:55PM +0100, Lionel Ulmer wrote: > Hi all, > > As long as we do not support multi-texturing in our D3D driver, fill the > caps properly. Now SS2 does not try to do multitexturing anymore (not that > it actually works now, it's just that it would break less :-) ). > > Note: is there a way from DLL X to activate relay debugging ? What happens > is that SS2 somehow freezes at one point and doing a relay trace from > the start is about a 3 GB file... So what I would like to do is at a > specific function in the D3D code that I know to be just before the > freeze, call 'activate relay' and voila, I have relaying on :-) (to be > able to do that for all DLLs would be even better). > > But well, considering DLL separation and all that, I doubt that this > would be possible :-/ Oh pleeeeze... I thought that at least the Wine developers are reading the wine docu properly... ;-) Let's see... first you use completely inacceptable words, and then you admit to never reading the docu... bad, bad, very bad guy. :) Read wine.man. It explains how to do relay logging for a single DLL. Although I'm afraid that this might actually be broken at the moment maybe :-\ -- "My attitude is, everybody should try competing with Microsoft once in their life. Once." - Marc Andreessen, former Netscape lead employee, in a "browser wars" interview

7 8

Regression in wineconsole
by Tony Lambregts Dec. 7, 2002

Dec. 7, 2002

Lately I have been having a problem with wineconsole spitting out the following errors and failing to load. err:wineconsole:WCUSER_SetFont wrong font err:wineconsole:WCUSER_SetFont wrong font err:wineconsole:WCUSER_SetFont wrong font err:wineconsole:WCUSER_SetFont wrong font err:wineconsole:WINECON_Fatal Couldn't find a decent font, aborting I had the stock RedHat 7.2 fonts loaded as well as the stock ms-windows when I first got this error. Now I have installed the XFree86 font from Ximian and it still cannot find a "decent" font. At this point with several hundred fonts to choose from I am suprised that it could not find one that it liked. In the past (upto the middle of November) wineconsole was quite happy with "clean 10". Does anyone have a suggestion on what should I do. -- Tony Lambregts

2 3

[RFC] winewrap
by Dimitrie O. Paun Dec. 7, 2002

Dec. 7, 2002

Hi folks, Here is the first cut at winewrap, as described here: http://www.dssd.ca/wine/Winelib-Apps.html What it does at the moment: -- invokes winebuild to create the .spec.c file -- compiles the .spec.s file -- links in everything, and generates the .exe.so file What remains to be done: -- generate the actual executable. One possible option is to modify wineapploader so we simply symlink to it. I have a version of this around. Is this acceptable? Comments welcomes. /* * Wine wrapper: takes care of internal details for linking. * * Copyright 2002 Dimitrie O. Paun * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include "config.h" #include "wine/port.h" #include <stdio.h> #include <string.h> #include <stdarg.h> #include <stdlib.h> #include <sys/param.h> #include <sys/wait.h> #ifdef HAVE_UNISTD_H # include <unistd.h> #endif #ifndef WINEDLLS #define WINEDLLS "/usr/local/lib/wine" #endif static char *output_name; static char **lib_files, **res_files, **obj_files; static int nb_lib_files, nb_res_files, nb_obj_files; void error(const char *s, ...) { va_list ap; va_start(ap, s); fprintf(stderr, "Error: "); vfprintf(stderr, s, ap); fprintf(stderr, "\n"); va_end(ap); exit(2); } char *strmake(const char *fmt, ...) { int n, size = 100; char *p; va_list ap; if ((p = malloc (size)) == NULL) return NULL; while (1) { va_start(ap, fmt); n = vsnprintf (p, size, fmt, ap); va_end(ap); if (n > -1 && n < size) return p; if (n > -1) size *= 2; if ((p = realloc (p, size)) == NULL) return NULL; } } void spawn(char *const argv[]) { int pid, status, i; for(i = 0; argv[i]; i++) printf("%s ", argv[i]); printf("\n"); if ((pid = fork()) == 0) execvp(argv[0], argv); else if (wait(&status) > 0) { if (WEXITSTATUS(status) == 0) return; else error("%s failed.", argv[0]); } perror(0); exit(1); } int main(int argc, char **argv) { char *library = 0; int i, j, len, is_object, no_opt = 0; char cmd[PATH_MAX]; char **spec_args, **comp_args, **link_args; for (i = 1; i < argc; i++) { if (!no_opt && argv[i][0] == '-') { switch (argv[i][1]) { case 'o': if (argv[i][2]) output_name = strdup(argv[i]+ 2); else if (i + 1 < argc) output_name = strdup(argv[++i]); else error("The -o switch takes an argument\n."); len = strlen(output_name); if (len > 4 && strcmp(output_name + len - 4, ".exe") == 0) output_name[len - 4] = 0; break; case 'l': if (argv[i][2]) library = argv[i]+ 2; else if (i + 1 < argc) library = argv[++i]; else error("The -l switch takes an argument\n."); if (strcmp(library, "winspool") == 0) library = "winspool.drv"; lib_files = realloc( lib_files, (nb_lib_files+1) * sizeof(*lib_files) ); lib_files[nb_lib_files++] = strdup(library); break; case '-': if (argv[i][2]) error("No long option supported\n"); no_opt = 1; break; default: error("Unknown option -%c\n", argv[i][1]); } continue; } /* it's a filename, not an option: test if it is a resource */ snprintf(cmd, sizeof(cmd), "readelf -V %s >/dev/null 2>/dev/null", argv[i]); is_object = (system(cmd) == 0); /* add it to its respective list */ if (is_object) { obj_files = realloc( obj_files, (nb_obj_files+1) * sizeof(*obj_files) ); obj_files[nb_obj_files++] = strdup(argv[i]); } else { res_files = realloc( res_files, (nb_res_files+1) * sizeof(*res_files) ); res_files[nb_res_files++] = strdup(argv[i]); } } /* build winebuild's argument list */ spec_args = malloc( (nb_lib_files + nb_obj_files + nb_res_files * 2 + 20) * sizeof (char *) ); j = 0; spec_args[j++] = "winebuild"; spec_args[j++] = "-fPIC"; spec_args[j++] = "-o"; spec_args[j++] = strmake("%s.spec.c", output_name); spec_args[j++] = "--exe"; spec_args[j++] = strmake("%s.exe", output_name); spec_args[j++] = "-m"; spec_args[j++] = "gui"; for (i = 0; i < nb_res_files; i++) { spec_args[j++] = "-r"; spec_args[j++] = res_files[i]; } for (i = 0; i < nb_obj_files; i++) spec_args[j++] = obj_files[i]; spec_args[j++] = "-L" WINEDLLS; for (i = 0; i < nb_lib_files; i++) spec_args[j++] = strmake("-l%s", lib_files[i]); spec_args[j++] = "-lmsvcrt"; spec_args[j] = 0; /* build gcc's argument list */ comp_args = malloc (20 * sizeof (char *) ); j = 0; comp_args[j++] = "gcc"; comp_args[j++] = "-fPIC"; comp_args[j++] = "-c"; comp_args[j++] = strmake("%s.spec.c", output_name); /* build ld's argument list */ link_args = malloc( (nb_obj_files + 20) * sizeof (char *) ); j = 0; link_args[j++] = "gcc"; link_args[j++] = "-shared"; link_args[j++] = "-Wl,-Bsymbolic"; link_args[j++] = "-lwine"; link_args[j++] = "-lm"; link_args[j++] = "-o"; link_args[j++] = strmake("%s.exe.so", output_name); link_args[j++] = strmake("%s.spec.o", output_name); for (i = 0; i < nb_obj_files; i++) link_args[j++] = obj_files[i]; link_args[j] = 0; /* run winebuild to get the .spec.c file */ spawn(spec_args); /* compile the .spec.c file */ spawn(comp_args); /* run gcc to link */ spawn(link_args); return 0; } -- Dimi.

2 11

Janitorial Projects -- conformance tests --recruiting volunteers
by Tom Wickline Dec. 7, 2002

Dec. 7, 2002

We still need Win-95, Win-98SE, WinME, WinXP testers if anyone would like to Volinteer :)) If your new here and would like to help out this is a great way to get started.. You dont have to be a *programmer* And in the end your contribution will help out. I also think *someone* should make a list of all NON-PROGRAMING task that could be done by non programmers!!! And ask for Volunteers / Helpers There are many points of entry in any project.. We need to recruit Graphics Pro's to help this project as well !! Why ?? This would save the programmers alot of time... If others were doing these task. And they could do more important tasks. Just you $.02 Tom

1 0

Re: Registering DLL's
by Jaco Greeff Dec. 7, 2002

Dec. 7, 2002

On Sat, 7 Dec 2002 01:13:53 -0500, "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote : > Cool. Any other details other than "a bit further"? :))) > Like a ETA for a preview version, or something to be > integrated into the tree? *grin* I don't mind ETA's, it helps me focus. Second week in Jan 2003 for a preview and some serious feedback. I've only got about 4 days left before taking a bit of a break hence the longinsh delay. I've wanted to be quite a bit further along and have something out there by now, but this is problably better - it allows me to give serious attention to the feedback in Jan. Greetings, Jaco

1 0

Re: Registering DLL's
by Jaco Greeff Dec. 7, 2002

Dec. 7, 2002

On Fri, 6 Dec 2002 10:32:45 -0500, "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote : > On December 6, 2002 10:18 am, you wrote: > > You guys have got the ReactOS regedit based on Wine Regedit although it is > > read only atm. If someone is still planning on adopting it, then that will > > solve this part of the problem. > > Jaco was working on a cool too, I don't know what the status of that is: It is a bit further that the last staus update, we will need to see how it evolves as the configuration moves into the registry. Greetings, Jaco

2 1

RE: Cabinet FDICreate()
by Patrik Stridvall Dec. 6, 2002

Dec. 6, 2002

> The MSXML4 .msi package dies with : > > fixme:cabinet:FDICreate (0x525bee, 0x525bf3, 0x52668d, 0x525e99, > 0x525bf8, 0x525fb9, 0x526042, -1, 0x54a2a8): stub > > Is this scheduled to be implemented as part of the cabinet merge in > work? IIRC Greg Turner volunteer to do it however, also said I might take a while before getting around to do it. I, who did the stub, personally, haven't got much time to do it either. So don't hold you breath, unless you volunteer. Implementing it is not that hard I think especially since we got cabextract licensed under the LGPL for us. If not, install and use the native cabinet.dll instead.

2 1

RE: Let --disable-debug actually do something
by Medland, Bill Dec. 6, 2002

Dec. 6, 2002

-----Original Message----- > From: wine-devel-admin(a)winehq.com > [mailto:wine-devel-admin(a)winehq.com]On > Behalf Of Alexandre Julliard > Sent: Friday, December 06, 2002 12:53 PM > To: Medland, Bill > Cc: wine-devel(a)winehq.com > Subject: Re: Let --disable-debug actually do something > > > "Medland, Bill" <Bill.Medland(a)accpac.com> writes: > > > --- wine/include/wine/debug.h 5 Jul 2002 21:22:09 > -0000 1.5 > > +++ wine/include/wine/debug.h 4 Dec 2002 04:52:22 -0000 > > @@ -23,6 +23,7 @@ > > > > #include <stdarg.h> > > #include "windef.h" > > +#include "config.h" > > You can't do that, installed includes shouldn't depend on config.h. And why is the header that defines FIXME an installed include anyway? > > -- > Alexandre Julliard > julliard(a)winehq.com > >

1 0

re: Dll separation question
by Dan Kegel Dec. 6, 2002

Dec. 6, 2002

Martin.Wilck(a)fujitsu-siemens.com wrote: > when writing code for DLL X, which functions from other DLLs may I call? As a Wine outsider, let me make a wild guess: To a first approximation, a nice way of thinking about it might be Write new DLLs using only published Microsoft APIs already implemented in other Wine DLLs. Ideally, new DLLs would work as replacements if compiled and run on a real Windows box. (although of course a whole lot of DLLs probably can't meet that strict definition.) - Dan

2 1