December 2002 - Wine-Devel - list.winehq.org

Re: Where to use dosdev

by Eric Pouech

György 'Nog' Jeney a écrit : > > >>Should we also use the functions in the devices.c to > >> implement all functions on devices like ioctls etc.? > > for the other int21 (disk read/write for instance), yes ioctl are the > > way to go > > I don't quite understand your english here, please excuse my French ;-) > are you saying that ioctls in > int21 _should_ be implemented using functions from devices.c (like > DOSDEV_IoctlRead/DOSDEV_IoctlWrite)? I was referring to DeviceIoControl calls (if you really want to only use exported functions from kernel in order to implement int 21h and device related traps) A+

Dec. 7, 2002

Re: small updates to debugger.sgml

by Eric Pouech

> How is this instead then? fine with me A+

Dec. 7, 2002

Re: Some fixes in capabilities

by Eric Pouech

> My appologies. (I am a VERY thick at times) I think most of my problems > with this is that I am/was doing it (The Wrong Way) (C) OK. I think I > should clarify since I brought it up There are two ways of getting > extraneous messages from winedbg in the log. > > 1). Starting winedbg with --debugmsg +(any channel you want a trace of) > ie: +loaddll > > 2). Any fixme message will get into the log regardless of whether it is > generated trough the app or winedbg. I would assume this also applies to > err and warn as well but I have not tested them this would apply to fixme and err which are turned on by default warn and trace are off by default > I think that now that I know about these two conditions (and avoid them) > I should be able to get a good clean log. the point 2/ is complely intented and should be kept as such regarding point 1/, what you can do is: - start your proces with wine foo --debugmsg +blabla - start winedbg - in winedbg, attach to the running process (using 'walk proc' to get the process id and 'attach pid') A+

Dec. 7, 2002

Re: Regression in wineconsole

by Eric Pouech

> So I don't really know for sure what fixed it. I could find > out for sure if you want <shrug> that's ok if it's fixed A+

Dec. 7, 2002

Re: [RFC] winewrap (2nd try)

by Dimitrie O. Paun

On December 6, 2002 03:12 pm, Alexandre Julliard wrote: > That would be a possibility, but you'd need some restructuring of > winebuild to do that (or have it exec itself which doesn't seem very > clean). I don't know, it feels cleaner to have a separate wrapper; Unfortunately, this doesn't work as nicely as a separate script, as I have to segragate the object files from resource files again, to pass only proper object files to gcc for linking. In the current script I have added a hack (assume files with .res in the name are resource files) to get around this problem, and be able to test the script out. I have tested this script with putty, and it works beautifully. At this point I still think it's better we integrate it into winebuild. Appart from the .res/.o detection, it avoids having to duplicate -m gui|cui handling, among other things. Comments welcomed, as usual. /* * 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/wait.h> #include <sys/stat.h> #ifdef HAVE_UNISTD_H # include <unistd.h> #endif #ifndef WINEDLLS #define WINEDLLS "/usr/local/lib/wine" #endif static const char *app_loader_script = "#!/bin/sh\n" "\n" "appname=\"%s\"\n" "# determine the application directory\n" "appdir=''\n" "case \"$0\" in\n" " */*)\n" " # $0 contains a path, use it\n" " appdir=`dirname \"$0\"`\n" " ;;\n" " *)\n" " # no directory in $0, search in PATH\n" " saved_ifs=$IFS\n" " IFS=:\n" " for d in $PATH\n" " do\n" " IFS=$saved_ifs\n" " if [ -x \"$d/$appname\" ]; then appdir=\"$d\"; break; fi\n" " done\n" " ;;\n" "esac\n" "\n" "# figure out the full app path\n" "if [ -n \"$appdir\" ]; then\n" " apppath=\"$appdir/$appname.exe.so\"\n" "else\n" " apppath=\"$appname.exe.so\"\n" "fi\n" "\n" "# determine the WINELOADER\n" "if ! [ -x \"$WINELOADER\" ]; then WINELOADER=\"wine\"; fi\n" "\n" "# and try to start the app\n" "exec \"$WINELOADER\" \"$apppath\" \"$@\"\n" ; static char *output_name; static char **lib_files, **obj_files; static int nb_lib_files, nb_obj_files; static int debug = 1; 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; if (debug) { 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, *p; int i, j, no_opt = 0; char *spec_name, *spec_c_name, *spec_o_name; char **spec_args, **comp_args, **link_args; FILE *file; 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."); if ( !(p = strstr(output_name, ".exe")) || *(p+4) ) output_name = strmake("%s.exe", output_name); 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."); no_opt = 1; break; default: error("Unknown option -%c\n", argv[i][1]); } continue; } /* it's a filename, add it to its list */ obj_files = realloc( obj_files, (nb_obj_files+1) * sizeof(*obj_files) ); obj_files[nb_obj_files++] = strdup(argv[i]); } spec_name = tempnam(0, 0); spec_c_name = strmake("%s.c", spec_name); spec_o_name = strmake("%s.o", spec_name); /* build winebuild's argument list */ spec_args = malloc( (nb_lib_files + nb_obj_files + 20) * sizeof (char *) ); j = 0; spec_args[j++] = "winebuild"; spec_args[j++] = "-fPIC"; spec_args[j++] = "-o"; spec_args[j++] = strmake("%s.c", spec_name); spec_args[j++] = "--exe"; spec_args[j++] = output_name; spec_args[j++] = "-m"; spec_args[j++] = "gui"; 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++] = "-o"; comp_args[j++] = spec_o_name; comp_args[j++] = "-c"; comp_args[j++] = spec_c_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.so", output_name); link_args[j++] = spec_o_name; for (i = 0; i < nb_obj_files; i++) if (!strstr(obj_files[i], ".res")) 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); unlink(spec_c_name); /* run gcc to link */ spawn(link_args); unlink(spec_o_name); /* create the loader script */ output_name[strlen(output_name) - 4] = 0; /* remove the .exe extension */ if ( !(file = fopen(output_name, "w")) ) error ("Can not create %s.", output_name); fprintf(file, app_loader_script, output_name); fclose(file); chmod(output_name, S_IXUSR | S_IXGRP | S_IXOTH); return 0; } -- Dimi.

Dec. 7, 2002

Janitorial Projects -- conformance tests --recruiting volunteers

by Tom Wickline

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

Dec. 7, 2002

Re: Registering DLL's

by Jaco Greeff

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

Dec. 7, 2002

Re: small updates to debugger.sgml

by Tony Lambregts

Eric Pouech wrote: >>>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. >>> >>> >the Ctrl-C should be working (if you did start the program under >winedbg) >A+ > > > > How is this instead then? Change Log: Update debugger documentation for when programs hangs. Files: debugger.sgml -- Tony Lambregts Index: debugger.sgml =================================================================== RCS file: /home/wine/wine/documentation/debugger.sgml,v retrieving revision 1.14 diff -u -r1.14 debugger.sgml --- debugger.sgml 30 Nov 2002 01:57:19 -0000 1.14 +++ debugger.sgml 7 Dec 2002 06:26:58 -0000 @@ -430,16 +430,12 @@ <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 - then enter its internal debugger and you can proceed as - explained above. Also, you can use - <parameter>--debug</parameter> switch and then you can get into - internal debugger by pressing - <keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo> in - the terminal where you run Wine. + Start the program with <command>winedbg</command> instead of + <command>wine</command>. When the program locks up switch to the + winedbg terminal and press + <keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo>. this + will stop the program and let you debug the program as you would for + a crash. </para> </sect2> @@ -664,11 +660,11 @@ to get a listing of the functions the program calls in its start function. Now you do a <programlisting> -wine --debug winfile.exe +winedbg winfile.exe </programlisting> </para> <para> - This way, you get into <command>Wine-dbg</command>. Now you + This way, you get into <command>winedbg</command>. Now you can set a breakpoint on any function the program calls in the start function and just type <userinput>c</userinput> to bypass the eventual calls of Winfile to this function

Dec. 7, 2002

Re: [RFC] winewrap

by Dimitrie O. Paun

On December 6, 2002 03:12 pm, Alexandre Julliard wrote: > I don't know, it feels cleaner to have a separate wrapper; I'd > suggest doing at least the first version that way, and once things are > cleared up maybe we can find a way to merge everything into winebuild > cleanly. Yes, I agree it feels cleaner to keep it as a wrapper, but current practice points in the other direction. Nevertheless, I fully agree that it makes sense to have the first cut done separately, so we better understand what the problem is before we do anything else. That being said, if we do plan to to integrate it into winebuild, I think we should do it sooner, rather than later, even at the expense of small temporary ugliness (e.g. fork winebuild from itself) in winebuild. We are in Wine 0.9 mode right now, and we should try hard to stabilize the utilities, and the *process*. The importance of said stabilization can not be overstated, as a bunch of other things depend on it, such as documentation, and other scripts (such as winemaker). And these dependents have been historically a _lot_ slower to change than C code. But most importantly, if people start using Winelib, it's going to be very hard to change established process as everyone's build system depends on it. Anyway, I will try to finish winewrap in it's current form, and we can evaluate merging it into winebuild when I'm done. -- Dimi.

Dec. 7, 2002

Re: Registering DLL's

by Dimitrie O. Paun

On December 7, 2002 12:37 am, Jaco Greeff wrote: > 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. Cool. Any other details other than "a bit further"? :))) Like a ETA for a preview version, or something to be integrated into the tree? Sorry for asking these things (I know people don't like ETAs in the free software world), but I think this is a cool development, and I'm quite excited by it. :) -- Dimi.

Dec. 7, 2002

Re: Registering DLL's

by Jaco Greeff

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

Dec. 7, 2002

Re: Where to use dosdev

by György 'Nog' Jeney

>>Should we also use the functions in the devices.c to >> implement all functions on devices like ioctls etc.? > for the other int21 (disk read/write for instance), yes ioctl are the > way to go I don't quite understand your english here, are you saying that ioctls in int21 _should_ be implemented using functions from devices.c (like DOSDEV_IoctlRead/DOSDEV_IoctlWrite)? nog.

Dec. 7, 2002

Latest wine cvs error

by Boris

I tried compiling the latest cvs and heres the error I get. make[2]: Leaving directory `/root/wine/tools/wrc' make[1]: Leaving directory `/root/wine/tools' make[1]: Entering directory `/root/wine/dlls' make[2]: Entering directory `/root/wine/dlls/ntdll' make[3]: Entering directory `/root/wine/dlls/ntdll/tests' LD_LIBRARY_PATH="../../../library:../../../unicode:$LD_LIBRARY_PATH" ../../../tools/winebuild/winebuild -fPIC -DSTRICT -DNONAMELESSUNION -DNONAMELESSSTRUCT -o ntdll_test.exe.spec.c -exe ntdll_test.exe -mcui error.o generated.o rtlbitmap.o rtlstr.o testlist.o -L../../../dlls -L.. -lntdll could not open .so file for kernel32.dll make[3]: *** [ntdll_test.exe.spec.c] Error 1 make[3]: Leaving directory `/root/wine/dlls/ntdll/tests' make[2]: *** [tests] Error 2 make[2]: Leaving directory `/root/wine/dlls/ntdll' make[1]: *** [ntdll] Error 2 make[1]: Leaving directory `/root/wine/dlls' make: *** [dlls] Error 2

Dec. 7, 2002

Re: Some fixes in capabilities

by Tony Lambregts

Eric Pouech wrote: >>While I am on the subject: as I mentioned in my other mail on this >>subject. Turning on gdi in winedbg (or any other channel/api that the >>debugger uses) will include calls from winedebug as well as the program >>I am debugging. This is an unhelpfull situation. >> >> >are you sure of this ? debug channels are only changed in the debugged >app, not in the debugger >aren't you looking at different threads ? > > > > My appologies. (I am a VERY thick at times) I think most of my problems with this is that I am/was doing it (The Wrong Way) (C) OK. I think I should clarify since I brought it up There are two ways of getting extraneous messages from winedbg in the log. 1). Starting winedbg with --debugmsg +(any channel you want a trace of) ie: +loaddll 2). Any fixme message will get into the log regardless of whether it is generated trough the app or winedbg. I would assume this also applies to err and warn as well but I have not tested them I think that now that I know about these two conditions (and avoid them) I should be able to get a good clean log. -- Tony Lambregts

Dec. 7, 2002

Re: Regression in wineconsole

by Tony Lambregts

Eric Pouech wrote: >>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. >> >> >does the font server use the old fonts ? or only the newest ones ? >the issue we have here is with freetype (or the wine interface) which >doesn't see fixed size fonts as fixed size fonts > >A+ > > > To start off this is not an issue for me any more. The patch that broke it for me was this one. http://www.winehq.com/hypermail/wine-cvs/2002/11/0136.html In the mean time it was either fixed by a later patch or something that I did. I.E., I did a "make clean" and reinstalled last night. Also there was a patch to xfont.c in the last couple of days if I recall corectlly. So I don't really know for sure what fixed it. I could find out for sure if you want <shrug> -- Tony Lambregts

Dec. 7, 2002

Re: Let --disable-debug actually do something

by Greg Turner

On Friday 06 December 2002 03:27 pm, Alexandre Julliard wrote: > "Medland, Bill" <Bill.Medland(a)accpac.com> writes: > > 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?) > > It's what it's supposed to do, but it's clearly broken, and has been > for a very long time, basically because no one uses it. > > A possible fix is to hack configure to pass the flags on the compiler > command-line; another is to remove the configure option completely > and just tell people who really want it to do something like: > > make clean > make all EXTRADEFS=-DNO_DEBUG_MSGS Unfortunately, I've seen packagers use it. Gentoo, for example, uses it. And I could see the logic: why would joe user want all these gibberish messages dumping onto the console while he's trying to work? So, eliminating this from configure might be a good call IMHO, at least until we get it working. Perhaps the wrapper scripts should control where the debugging output goes. I.E.: we could support (1) the usual stuff (2) appending debug output to a log file or (3) appending debug output to /dev/null, without messing with DNO_DEBUG_MSGS.... just a thought, -- gmt

Dec. 6, 2002

Re: Fix the winmm/wave tests

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > * dlls/winmm/tests/wave.c > > Error handling in waveOutOpen works now (patch has been in CVs for a > couple of weeks) -> removing the todo_wine This doesn't work for me: ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so wave.c && touch wave.ok err:wave:wodOpen Rate doesn't match (requested 2000000 Hz, got 48000 Hz) err:wave:wodOpen Rate doesn't match (requested 2000000 Hz, got 48000 Hz) wave.c:145: Test failed: opening the device at 2MHz should fail 0: rc=4 -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: Let --disable-debug actually do something

by Alexandre Julliard

"Medland, Bill" <Bill.Medland(a)accpac.com> writes: > 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?) It's what it's supposed to do, but it's clearly broken, and has been for a very long time, basically because no one uses it. A possible fix is to hack configure to pass the flags on the compiler command-line; another is to remove the configure option completely and just tell people who really want it to do something like: make clean make all EXTRADEFS=-DNO_DEBUG_MSGS -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: Cabinet FDICreate()

by Greg Turner

On Friday 06 December 2002 06:36 am, Patrik Stridvall wrote: > > 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? yes. > IIRC Greg Turner volunteer to do it however, also said I might take a > while before getting around to do it. indeed! > If not, install and use the native cabinet.dll instead. yes, this works like a charm. I'm looking into cabinet now. You are correct that, the fci.h and fdi.h functions ought to be relatively easy since we have the cabextract code gifted to us. The sticking point for me has been "Extract" which is undocumented, and used by the IE installers. I'm going to look at the .pdb symbols from XP in the hopes that they will give me a clue what the argument structure is... otherwise, I guess it's going to be trial and error or deducing the meaning from disassembly. Also, I will probably do the FDI and FCI functions last, and the "Extract" and "DeleteExtractedFiles" (or whatever it's called) first. The reason: this way I can be more confident that I have successfully ported the cabextract code to wine before I start changing the overall flow of the program and potentially create new, non-porting-related bugs. cabinet.dll may take some time, and I may multitask while I work on it by doing some RPCRT4 stuff, but it's basically at the top of my queue right now. Of course, that doesn't mean it still won't take forever :) -- gmt

Dec. 6, 2002

RE: Let --disable-debug actually do something

by Medland, Bill

-----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 > >

Dec. 6, 2002

re: Dll separation question

by Steven Edwards

--- Dan Kegel <dank(a)kegel.com> wrote: > 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 This is kind of what I work on when I have time for the ReactOS project. If a WINE dll works under Windows then as ReactOS is developed the same dll and API will be there for ReactOS. This doesnt always work for the lower level stuff like advapi, ntdll, kernel32 and others but the more higher level stuff is getting there. Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Dec. 6, 2002

RE: Let --disable-debug actually do something

by Medland, Bill

> -----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

Dec. 6, 2002

RE: FW: shell32.SHDefExtractIcon implementation take

by Rolf Kalbermatter

Mmmh, at first sight I thought damn how could this happen but then looking at it I don't think there is a problem. I do not return the memory which was allocated on the stack, but the HICONS allocated and returned by PrivateExtractIconsW in the hIcons array! So this shouldn't be a problem at all or are my brain cells garbled that much already? Rolf Kalbermatter > -----Original Message----- > From: Uwe Bonnes [mailto:bon(a)elektron.ikp.physik.tu-darmstadt.de] > Sent: Friday, December 06, 2002 9:53 PM > To: wine-devel(a)winehq.com > Cc: rolf.kalbermatter(a)citeng.com > Subject: Re: FW: shell32.SHDefExtractIcon implementation take > > > > > >>>>> "Rolf" == Rolf Kalbermatter <rolf.kalbermatter(a)citeng.com> writes: > +/**************************************************************************** > + * SHDefExtractIconW [SHELL32.@] > + */ > +HRESULT SHDefExtractIconW(LPCWSTR pszIconFile, int iIndex, UINT uFlags, > + HICON* phiconLarge, HICON* phiconSmall, UINT nIconSize) > +{ > + UINT ret; > + HICON hIcons[2]; > ^^^^^^^^ > > + WARN("%s %d 0x%08x %p %p %d, semi-stub\n", debugstr_w(pszIconFile),\ > iIndex, uFlags, phiconLarge, phiconSmall, nIconSize); > + > + ret = PrivateExtractIconsW(pszIconFile, iIndex, nIconSize, > nIconSize, hIcons, NULL, 2, LR_DEFAULTCOLOR); > + /* FIXME: deal with uFlags parameter which contains GIL_ flags */ > + if (ret == 0xFFFFFFFF) > + return E_FAIL; > + if (ret > 0) { > + *phiconLarge = hIcons[0]; > ^^^^^^^^^^^^ > Rolf, > > this doesn't look right to me: > > You allocate space on the function local stack, then hand out a pointer to > that memory and return from the function. No the function local stack is > undefined and the pointers are dangling. I think the heap should be used for > allocating the needed storage. > > Bye > > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Dec. 6, 2002

Re: Let --disable-debug actually do something

by Alexandre Julliard

"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. -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: FW: shell32.SHDefExtractIcon implementation take

by Uwe Bonnes

>>>>> "Rolf" == Rolf Kalbermatter <rolf.kalbermatter(a)citeng.com> writes: +/**************************************************************************** + * SHDefExtractIconW [SHELL32.@] + */ +HRESULT SHDefExtractIconW(LPCWSTR pszIconFile, int iIndex, UINT uFlags, + HICON* phiconLarge, HICON* phiconSmall, UINT nIconSize) +{ + UINT ret; + HICON hIcons[2]; ^^^^^^^^ + WARN("%s %d 0x%08x %p %p %d, semi-stub\n", debugstr_w(pszIconFile),\ iIndex, uFlags, phiconLarge, phiconSmall, nIconSize); + + ret = PrivateExtractIconsW(pszIconFile, iIndex, nIconSize, nIconSize, h\ Icons, NULL, 2, LR_DEFAULTCOLOR); + /* FIXME: deal with uFlags parameter which contains GIL_ flags */ + if (ret == 0xFFFFFFFF) + return E_FAIL; + if (ret > 0) { + *phiconLarge = hIcons[0]; ^^^^^^^^^^^^ Rolf, this doesn't look right to me: You allocate space on the function local stack, then hand out a pointer to that memory and return from the function. No the function local stack is undefined and the pointers are dangling. I think the heap should be used for allocating the needed storage. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Dec. 6, 2002

Re: [RESENT] Batch support for CreateProcess (2 of 3)

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > --- wine/programs/wcmd/builtins.c 24 Jul 2002 19:00:25 -0000 1.15 > +++ wine/programs/wcmd/builtins.c 6 Dec 2002 14:04:02 -0000 > @@ -406,7 +406,7 @@ > return; > } > if (test != negate) { > - WCMD_parameter (p, 2+negate, &s); > + WCMD_parameter (p, 2+negate+test, &s); This doesn't look right. The number of parameters doesn't depend on the result of the test. -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: [RFC] winewrap

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Well, in this case, why not merge winewrap into winebuild, and > maybe provide flags to do only certain steps, sort of like gcc? > > In fact, winebuild already follows this philosophy, so it seems > only natural. And we can avoid yet another small wrapper. That would be a possibility, but you'd need some restructuring of winebuild to do that (or have it exec itself which doesn't seem very clean). I don't know, it feels cleaner to have a separate wrapper; I'd suggest doing at least the first version that way, and once things are cleared up maybe we can find a way to merge everything into winebuild cleanly. -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: [RFC] winewrap

by Dimitrie O. Paun

On December 6, 2002 01:19 pm, Alexandre Julliard wrote: > The 32-bit ones do, so it would be possible to identify them. But > actually I could hack winebuild to do that itself, and then simply get > rid of the -r option. Well, in this case, why not merge winewrap into winebuild, and maybe provide flags to do only certain steps, sort of like gcc? In fact, winebuild already follows this philosophy, so it seems only natural. And we can avoid yet another small wrapper. -- Dimi.

Dec. 6, 2002

Re: what to do with include/wine/obj_base.h?

by Ove Kaaven

On 6 Dec 2002, Alexandre Julliard wrote: > Ove Kaaven <ovehk(a)ping.uio.no> writes: > > > 4) make widl not use macros at all, but emit full C and C++ definitions > > directly (this is what midl.exe does, it seems) > > I'd say this is the way to go if it's not too painful, it seems to be > the most flexible. In any case obj_base.h has to go, so if we keep the > macros they have to be put inside one of the standard headers, which > wouldn't be very clean. We may have to keep the macros anyway, there are headers that use them that can't be generated from IDL, like the DirectX headers. I suppose they could be converted to using the MS-style objbase.h macros by perl scripts or by rewriting them from api headers or something, but someone else would have to take on that task, I think. But I'll try to add a widl header generation mode that don't use macros, then.

Dec. 6, 2002

Re: [RFC] winewrap

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Nevermind that, now the question is: should I include the > script in winewrap? Otherwise, we have to install wineapploader, > and I don't quite see the point in that. We can have a --loader > option that allows you to use an external script if need be, > in which case we can maybe even simplify the generated script a bit. I think winewrap should be self-contained and not depend on an external script. The fact that we generate a script is just an implementation detail, at some point it may become an ELF binary so we don't want anybody to depend on that. -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: Janitorial Projects

by Dimitrie O. Paun

On December 6, 2002 01:40 pm, Alexandre Julliard wrote: > Yes, the DDK ones should be installed I think. toolhelp.h probably > not, it's a 16-bit thing that Winelib apps are not supposed to use. OK, here it is: ChangeLog Install DDK headers as well. Index: include/Makefile.in =================================================================== RCS file: /var/cvs/wine/include/Makefile.in,v retrieving revision 1.68 diff -u -r1.68 Makefile.in --- include/Makefile.in 3 Dec 2002 23:36:05 -0000 1.68 +++ include/Makefile.in 6 Dec 2002 18:38:37 -0000 @@ -23,11 +23,13 @@ d3d8caps.h \ d3d8types.h \ d3dcaps.h \ + d3dhal.h \ d3dtypes.h \ d3dvec.inl \ dde.h \ ddeml.h \ ddraw.h \ + ddrawi.h \ digitalv.h \ dinput.h \ dispdib.h \ @@ -38,6 +40,7 @@ docobj.h \ dplay.h \ dplobby.h \ + dsdriver.h \ dshow.h \ dsound.h \ fci.h \ @@ -65,6 +68,7 @@ mediaerr.h \ mediaobj.h \ minmax.h \ + mmddk.h \ mmreg.h \ mmsystem.h \ msacm.h \ @@ -72,7 +76,11 @@ mssip.h \ mswsock.h \ nb30.h \ + netspi.h \ nspapi.h \ + ntddcdrm.h \ + ntddscsi.h \ + ntddstor.h \ ntsecapi.h \ ntstatus.h \ oaidl.h \ -- Dimi.

Dec. 6, 2002

Re: Janitorial Projects

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Thanks! Alexandre, shouldn't we install these as well? Yes, the DDK ones should be installed I think. toolhelp.h probably not, it's a 16-bit thing that Winelib apps are not supposed to use. -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: Wine/FF7 midi help request

by Eric Pouech

> >fixme:winmm:MIDI_StreamOpen *lpuDeviceID=1 > >fixme:dsound:IDirectSoundImpl_SetCooperativeLevel > >(0x403ab930,0001003c,3):stub try changing in dlls/winmm/winmm.c lpwm->mld.uDeviceID = *lpuDeviceID = 0; into lpwm->mld.uDeviceID = *lpuDeviceID; and see what gives (the second fixme is harmless) A+

Dec. 6, 2002

Re: [RFC] winewrap

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Fair enough. But I would suggest we modify the script (as in the one > I sent) to allow the execution of the app out of _its_ build tree. > There isn't much point in requiring the app to be in the path, no? Sure, it should run from the build directory (though we should fall back to using the path if we don't find it there). Isn't that what the script already does? > Fine. What about the readelf hack? Should I open the file myself, > and check for the ELF signature. As far as I can say, the .res > files have no signature, right? The 32-bit ones do, so it would be possible to identify them. But actually I could hack winebuild to do that itself, and then simply get rid of the -r option. -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: [RFC] winewrap

by Dimitrie O. Paun

On December 6, 2002 01:19 pm, Alexandre Julliard wrote: > Sure, it should run from the build directory (though we should fall > back to using the path if we don't find it there). Isn't that what the > script already does? I don't remember now, there was something I didn't like. :) Nevermind that, now the question is: should I include the script in winewrap? Otherwise, we have to install wineapploader, and I don't quite see the point in that. We can have a --loader option that allows you to use an external script if need be, in which case we can maybe even simplify the generated script a bit. > The 32-bit ones do, so it would be possible to identify them. But > actually I could hack winebuild to do that itself, and then simply get > rid of the -r option. I think this is a better option, and the reason is that it would allow people to more easily use winebuild directly, which is preferable because the generated files will be in sync with the Makefile targets (whereas with winewrap, we're generating files the Makefile doesn't know about). -- Dimi.

Dec. 6, 2002

Re: Janitorial Projects

by Eric Pouech

"Dimitrie O. Paun" a écrit : > > On December 6, 2002 12:33 pm, Eric Pouech wrote: > > on the wine only header side, some headers listed as wine only are in > > fact part of the DDK > > IMO, we should list them as such > > I don't have a SDK/DDK to check against, I've just generated the list > as the headers we do _not_ install. Help with this would be greatly > appreciated. those are (at least) the one I know d3dhal.h 3D direct draw driver interface ddrawi.h direct draw driver interface dsdriver.h direct sound driver interface mmddk.h winmm driver interface netspi.h network provider interface ntddcdrm.h kernel cd rom ioctls ntddscsi.h kernel scsi ioctls ntddstor.h kernel mass storage ioctls this one has been deprecated on NT (but is still valid on 9x) toolhelp.h

Dec. 6, 2002

Re: Janitorial Projects

by Dimitrie O. Paun

On December 6, 2002 01:11 pm, Eric Pouech wrote: > those are (at least) the one I know > d3dhal.h 3D direct draw driver interface > ddrawi.h direct draw driver interface > dsdriver.h direct sound driver interface > mmddk.h winmm driver interface > netspi.h network provider interface > ntddcdrm.h kernel cd rom ioctls > ntddscsi.h kernel scsi ioctls > ntddstor.h kernel mass storage ioctls > > this one has been deprecated on NT (but is still valid on 9x) > toolhelp.h Thanks! Alexandre, shouldn't we install these as well? If so, I can submit a patch, and take them off the list. -- Dimi.

Dec. 6, 2002

Re: Winedbg and gcc 3.2

by Eric Pouech

Alberto Massari a écrit : > > Hi everybody, > a few weeks ago I changed my build machine from a RedHat 7.2 + gcc 2.9x to > a Mandrake 9.0 + gcc 3.2, and I noticed that I was unable to debug the Wine > libraries (I got messages like "No debug information in ELF > '/usr/local/lib/wine/xxxx.dll.so'), while gdb worked just fine. this has already been discussed a month ago (or so) > My questions at this point are: > - is this behavior typical of every gcc 3.2? or it's only Mandrake that > does it? generic to 3.2 > - is somebody going to change the "configure" script to detect such a > situation and specify "-gstabs" instead of "-g"? (I would volunteer myself, > but I am not expert in this field... I just hacked my copy to make it work > in my tree) the "current fix" is to use CFLAGS=-gstabs configure > - or should winedbg be improved to understand more debug formats, so that > it can handle whatever informations the "-g" option spits out? no dwarfII support is planned for winedbg you can also use the dbg proxy in wine if you want to use dwarf debug format A+

Dec. 6, 2002

Re: [RFC] winewrap

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Well, depends on what you call "work" :))) I've attached what I had > in mind for a generic wineapploader script. The problem I see with the symlink is that it's too fragile. As soon as you move/rename anything it breaks. Copying the script is already better, but I also think we should hardcode the app name instead of relying on $0, so that you can rename the script and it still works. > Also, should I delete the intermediate files? I think I should, > one can get to them by manually running winebuild. Yes, and you should use temp file names I think. -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: [RFC] winewrap

by Dimitrie O. Paun

On December 6, 2002 12:51 pm, Alexandre Julliard wrote: > The problem I see with the symlink is that it's too fragile. As soon > as you move/rename anything it breaks. Copying the script is already > better, but I also think we should hardcode the app name instead of > relying on $0, so that you can rename the script and it still works. Fair enough. But I would suggest we modify the script (as in the one I sent) to allow the execution of the app out of _its_ build tree. There isn't much point in requiring the app to be in the path, no? Moreover, many Win32 apps don't even have an install target to their Makefiles, so running out of the build tree is the only option. > > Also, should I delete the intermediate files? I think I should, > > one can get to them by manually running winebuild. > > Yes, and you should use temp file names I think. Fine. What about the readelf hack? Should I open the file myself, and check for the ELF signature. As far as I can say, the .res files have no signature, right? -- Dimi.

Dec. 6, 2002

Re: Where to use dosdev

by Eric Pouech

György 'Nog' Jeney a écrit : > > In some of the int21 routines it says that we should use > DOSDEV_Peek/Read/Write. it seems to be related to console only functions in that case, you could use directly the console functions >Should we also use the functions in the devices.c to > implement all functions on devices like ioctls etc.? for the other int21 (disk read/write for instance), yes ioctl are the way to go A+

Dec. 6, 2002

Re: Failure running 1998-era online manual

by Eric Pouech

> It sounds like mmioOpen's documentation at > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/m… > is incomplete; it doesn't describe what the function does when > there's no filename, just a +init, in the string passed to mmioOpen. > I tried patching the source for MMIO_ParseExtA to assume an extension of "" > in this case, but it didn't help, the program still exits. I'll try to look at it. (it may not even be mmio related) A+

Dec. 6, 2002

Re: Janitorial Projects

by Dimitrie O. Paun

On December 6, 2002 12:33 pm, Eric Pouech wrote: > on the wine only header side, some headers listed as wine only are in > fact part of the DDK > IMO, we should list them as such I don't have a SDK/DDK to check against, I've just generated the list as the headers we do _not_ install. Help with this would be greatly appreciated. -- Dimi.

Dec. 6, 2002

Re: Janitorial Projects

by Eric Pouech

"Dimitrie O. Paun" a écrit : > > Folks, > > I have updated the Janitorial section: > http://www.dssd.ca/wine/Wine-Fun.html#janitorial on the wine only header side, some headers listed as wine only are in fact part of the DDK IMO, we should list them as such A+

Dec. 6, 2002

Re: small updates to debugger.sgml

by Eric Pouech

> > 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. the Ctrl-C should be working (if you did start the program under winedbg) A+

Dec. 6, 2002

Re: what to do with include/wine/obj_base.h?

by Alexandre Julliard

Ove Kaaven <ovehk(a)ping.uio.no> writes: > 4) make widl not use macros at all, but emit full C and C++ definitions > directly (this is what midl.exe does, it seems) I'd say this is the way to go if it's not too painful, it seems to be the most flexible. In any case obj_base.h has to go, so if we keep the macros they have to be put inside one of the standard headers, which wouldn't be very clean. -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: [RFC] winewrap

by Dimitrie O. Paun

On December 6, 2002 12:16 pm, Alexandre Julliard wrote: > I don't think a symlink would work. IMO it should be a self-contained > thing that you can move around, copy to other machines, etc. Well, depends on what you call "work" :))) I've attached what I had in mind for a generic wineapploader script. But regardless, you want to simply output the script, or generate an ELF executable? Also, should I delete the intermediate files? I think I should, one can get to them by manually running winebuild. -- Dimi. #!/bin/sh # # Wrapper script to start a Winelib application once it is installed # # Copyright (C) 2002 Alexandre Julliard # # 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 # # determine the app Winelib library name appname=`basename "$0" .exe`.exe # determine the application directory appdir="" case "$0" in */*) # $0 contains a path, use it appdir=`dirname "$0"` ;; *) # no directory in $0, search in PATH saved_ifs=$IFS IFS=: for d in $PATH do IFS=$saved_ifs if [ -x "$d/$0" ]; then appdir="$d"; break; fi done ;; esac # figure out the full app path if [ -n "$appdir" ]; then apppath="$appdir/$appname.so" else apppath="$appname" fi # first try explicit WINELOADER if [ -x "$WINELOADER" ]; then exec "$WINELOADER" "$apppath" "$@"; fi # then default bin directory if [ -x "/usr/local/bin/wine" ]; then exec "/usr/local/bin/wine" "$apppath" "$@"; fi # now try the directory containing $0 if [ -x "$appdir/wine" ]; then exec "$appdir/wine" "$apppath" "$@"; fi # finally look in PATH exec wine "$appname" "$@"

Dec. 6, 2002

Re: how to switch between threads

by Eric Pouech

> How dose debuggers handle MultiThreaded Applications? > Can i Shit to different Thread to exmine where is it > when the program Halted? when you've hit a bp, you can use bt 1234 to see the backtrace of thread 1234 (where 1234 is the thread id) a good way to know thread ids is to call walk proc and walk thread once the debugger is handling an exception (single step, breakpoint...), all threads of the process are stopped, so you can look at whatever you want however, there's no way (currently) to restart a specific thread (only). we're always in a all or nothing fashion A+

Dec. 6, 2002

Re: [RFC] winewrap

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > One possible option is to modify wineapploader so we > simply symlink to it. I have a version of this around. > Is this acceptable? I don't think a symlink would work. IMO it should be a self-contained thing that you can move around, copy to other machines, etc. -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: Some fixes in capabilities

by Eric Pouech

> While I am on the subject: as I mentioned in my other mail on this > subject. Turning on gdi in winedbg (or any other channel/api that the > debugger uses) will include calls from winedebug as well as the program > I am debugging. This is an unhelpfull situation. are you sure of this ? debug channels are only changed in the debugged app, not in the debugger aren't you looking at different threads ? A+

Dec. 6, 2002