- Wine-devel - list.winehq.org

Unicode question
by Rolf Kalbermatter 07 Dec '02

07 Dec '02

Hello, In trying to get shell32 a little bit more Unicodified I came across this function ParseFieldA which is taken from shellord.c. I'm quite unfamiliar with Unicode so I still have to learn a lot. I have finally found most of the string manipulation functions which work for Unicode but when it comes down to simple character comparison I'm a little bit in the dark here. Some code snippets elsewhere in wine make me believe that for the english charset WCHAR == char is actually mostly true. However I wonder if this can be relied on in code. For instance the Unicode version of ParseField would in that case look like this but I really want the opinion of someone else on, if the code if (*src++ == ',') nField--; is actually working as expected on all systems independent of the actually used charsets for the local languages. And has anyone a good idea what the semi-stub would mean for this function? Maybe that it should ignore commas in quoted strings? /************************************************************************* * ParseFieldW [internal] * * copies a field from a ',' delimited string * * first field is nField = 1 */ DWORD WINAPI ParseFieldW(LPCWSTR src, DWORD nField, LPWSTR dst, DWORD len) { WARN("(%s,0x%08lx,%p,%ld) semi-stub.\n", debugstr_w(src), nField, dst, len); if (!src || !src[0] || !dst || !len) return 0; /* skip n fields delimited by ',' */ while (nField > 1) { if (*src == 0x0) return FALSE; if (*src++ == ',') nField--; } /* copy part till the next ',' to dst */ while ( *src != 0x0 && *src != ',' && (len--)>0 ) *(dst++) = *(src++); /* finalize the string */ *dst = 0x0; return TRUE; } Rolf Kalbermatter

4 3

RE: Let --disable-debug actually do something
by Medland, Bill 07 Dec '02

07 Dec '02

> -----Original Message----- > From: Alexandre Julliard [mailto:julliard(a)winehq.com] > 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. Oh. So how is setting --disable-debug supposed to result in the FIXMES being compiled out? I just don't understand what is supposed to be happening here; all I know is that it isn't working. (Or is that not what it is supposed to do?) a) --disable-debug results in the settings in config.h changing. b) wine/debug.h tests that setting that becomes defined in config.h, in order to reduce FIXME to a basically null statement. c) dlls/user/hook.c, for example, includes a FIXME statement. neither hook.c nor debug.h include config.h so if I insert #ifndef NO_DEBUG_MSGS #error I was right #endif just before the fixme of NotifyWinEvent then it tells me I am right. I can only think of two ways that setting --disable-debug could be expected to result in the FIXMES being compiled out (which I presume is what is supposed to happen). Either it is supposed to result in a change to the makefiles so the -D NO_DEBUG_MSGS gets specified (and I see no indication of that) or else it results in a #define NO_DEBUG_MSGS at a suitable point that comes before it is actually needed (which appears to be the intention). So I presume that the problem is that config.h is not being included before its contents are needed. So the question is where should it be included. One solution would be to include it explicitly in every file that includes a WARN, FIXME or TRACE. Do you really want that? The other is to include it in the file that uses it (viz. debug.h). So tell me why I am an idiot and what solution you want me implement. I guess the simplest would be to drop --disable-debug from the configure. > > -- > Alexandre Julliard > julliard(a)winehq.com > Bill Medland

4 3

Where to use dosdev
by György 'Nog' Jeney 07 Dec '02

07 Dec '02

In some of the int21 routines it says that we should use DOSDEV_Peek/Read/Write. Should we also use the functions in the devices.c to implement all functions on devices like ioctls etc.? nog.

2 3

small updates to debugger.sgml
by Tony Lambregts 07 Dec '02

07 Dec '02

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 07 Dec '02

07 Dec '02

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 07 Dec '02

07 Dec '02

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 07 Dec '02

07 Dec '02

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 07 Dec '02

07 Dec '02

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 07 Dec '02

07 Dec '02

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 07 Dec '02

07 Dec '02

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