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

Re: critical section timeout for the dsound_test

by Sylvain Petreolle

I had the issue with this version of the driver. Now im using the 1.0-4191 and the problem is still here. But we don't have the source to look into it, and I don't know any site/mail adress to complain about this. PS : it seems I have the same using real winxp when watching dvds, but it is unconfirmed for the moment. --- Enrico Horn <EnricoHorn(a)t-online.de> a écrit : > Hi, > On Wednesday 18 December 2002 12:23, Sylvain Petreolle wrote: > > I have same issue, but the debugger manages to start and "ends" in > the > > X video binary. > > > no debugger for me, just the message. > > > Could be a stupid question, but what is your VIDEO driver ? > > Mine is nVidia binary, and I have got some problems with it. > > I have reproductible crashes with it (like this test) for a long > time. > > Don't worry, I know this is a dsound test... :) > > > yes i use the nvidia binary driver too, mine is version 1.0-3123 > Which one do you use? > Did you try to use the included nv driver? > I get some crashes in libGL esp. when closing an app. > I have always ignored those since they seemed nvidia's fault to me. > > Ciao > Farmboy > farmboy1(a)subdimension.com > > > > ===== > > Sylvain Petreolle > > spetreolle(a)users.sourceforge.net > > Fight against Spam ! http://www.euro.cauce.org/en/index.html > > ICQ #170597259 > > > > "Don't think you are. Know you are." Morpheus in Matrix, chapter > 15. > > > > ___________________________________________________________ > > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > > Yahoo! Mail : http://fr.mail.yahoo.com > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Dec. 19, 2002

Re: [D3D8 PATCH] d3d8 shaders update - VS2

by Fabian Cenedese

> > >/* note about reason for commenting block */ > > >#if 0 > > >code > > >code /* comments */ > > >code > > >#endif > > > > Whereas this is the solution with the least work it's also hard to > spot. If > > using > > a text editor with syntax coloring it all looks the same. But if a code > isn't > > effective I'd like to see that. > >Actually it could be considered as an editor fault if it changes color for >commented out code but doesn't recognize the #if 0/#endif construct. I wouldn't say so. A comment is easily recognized by the chars /* */ or //. But to get a #if 0 or #if _ANYTHING you really need a language dependant preprocessor which goes beyond a normal text editor, even one with syntax coloring. Do you have such a text editor that finds #if's? bye Fabi

Dec. 19, 2002

Re: [D3D8 PATCH] d3d8 shaders update - VS2

by Dmitry Timoshkov

"Fabian Cenedese" <Cenedese(a)indel.ch> wrote: > >The best way I know to create block comments *without* tampering with > >interior comments is like this: > > > >/* note about reason for commenting block */ > >#if 0 > >code > >code /* comments */ > >code > >#endif > > Whereas this is the solution with the least work it's also hard to spot. If > using > a text editor with syntax coloring it all looks the same. But if a code isn't > effective I'd like to see that. Actually it could be considered as an editor fault if it changes color for commented out code but doesn't recognize the #if 0/#endif construct. -- Dmitry.

Dec. 19, 2002

Re: [D3D8 PATCH] d3d8 shaders update - VS2

by Fabian Cenedese

>The best way I know to create block comments *without* tampering with >interior comments is like this: > >/* note about reason for commenting block */ >#if 0 >code >code /* comments */ >code >#endif Whereas this is the solution with the least work it's also hard to spot. If using a text editor with syntax coloring it all looks the same. But if a code isn't effective I'd like to see that. That's why I really comment it out. But this is just my personal opinion, besides that nothing's wrong with the above. bye Fabi A: No, see http://www.netmeister.org/news/learn2quote.html Q: Should I include quotations after my reply ?

Dec. 19, 2002

Re: Update to patches sgml

by Dimitrie O. Paun

On December 18, 2002 07:10 pm, Tony Lambregts wrote: > In an effort to start a flame war <g> I decided to add a few notes about > style to patches.sgml and while I was at it I added a note about being > able to submit non cvs patches. + Patches should be attached so that they can be read inline. This + may mean some more work for you. However it allows others to review + your patch easily and increase the chances of it not being + overlooked or forgotten. This should read "Patches should be inlined (if you can configure your email client to not wrap lines), or attached as text/plain attachements...." -- Dimi.

Dec. 19, 2002

Re: mingwrap -> mingcc

by David Fraser

Francois Gouget wrote: >On Wed, 18 Dec 2002, Dimitrie O. Paun wrote: > > > >>On December 18, 2002 03:36 pm, Francois Gouget wrote: >> >> >[...] > > >>> winegcc >>> >>> >>Why not wgcc? >> >> > >I had the impression that we were going away from just using 'w' as the >prefix and more towards using 'wine'. So I'm proposing both forms. > > > >>So I am OK with the following: >> wgcc >> mingcc >> wmingcc >> >> > >I think the ones I prefer are 'wgcc' and 'winegcc'. In both cases we can >add variants: wcl / winecl (Visual C++), wbcc / winebcc (Borland C++ if >memory serves), etc. > > > I'm all for winegcc and these variants. It's not that much longer to type, it's much clearer (nobody's going to look at their /usr/bin directory and think 'what's wgcc?'), and most of the time it's going to be in a Makefile anyway. David

Dec. 19, 2002

RE: Win2000 Conformance Test Results...

by Kye Lewis

XP Results Round 2: ** If a test is not listed here, then it has passed ** advapi32_test registry: No Change Note: Test now always has 3 failures, No cases of more failures are apparent. kernel32_test process: No Change netapi32_test access: No Change shell32_test shfileop: No Change user32_test sysparams: No Change Thanks, Kye Lewis LinksOS Project Administrator LinksOS Web Team Leader kyethespy(a)softhome.net (New email address! kyethespy(a)liquid2k.com will still work, but please send all emails now to new email) "640k ought to be enough for anyone!" - Bill Gates ================================= LinksOS: Linking you to the world http://linksos.cjb.net http://linksos.sourceforge.net/ http://linksos.oxygen-x.net/ Now with Bugzilla and phpBB installed :) ================================= -----Original Message----- From: wine-devel-admin(a)winehq.com [mailto:wine-devel-admin(a)winehq.com] On Behalf Of Francois Gouget Sent: Friday, December 13, 2002 8:58 AM To: David Fraser Cc: Kye Lewis; wine-devel(a)winehq.org Subject: Re: Win2000 Conformance Test Results... Hmmm, I meant to send this two days ago... On Tue, 10 Dec 2002, David Fraser wrote: [...] > for kernel32_test path, I got this additional error (before all the others) I have made tons of fixes to the kernel/path test and it should now work much better. I just uploaded the new version of the tests compiled from my sources. One can download them from the usual URL: http://fgouget.free.fr/wine/winetests.zip [...] > >process: 116 tests executed, 0 marked as todo, 4 failures. > > > Exactly the same except I have 10 messages interspersed with these, saying: > tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. > Why these extra messages? Because this executable invokes itself to test CreateProcess. And each time it exits it prints statistics about how many tests passed and failed, although the child processes are not actually performing any test. So these messages can be ignored. > >h:\wine\wine\dlls\shlwapi\tests\shreg.c:218: Test failed: (6) > >h:\wine\wine\dlls\shlwapi\tests\shreg.c:219: Test failed: (6,43) > >h:\wine\wine\dlls\shlwapi\tests\shreg.c:220: Test failed: (3435973836) [...] > Same but I get 0 for all your 3435973836 which is 0xcccccccc. Must be a > debug/release build thing - variable not being initialized. Should not be the case. The code does: dwType = -1; dwRet = SHQueryValueExA( hKey, "Test3", NULL, &dwType, NULL, &dwSize); ok( dwType == REG_SZ, "(%lu)" , dwType); So we should either get -1 or something that makes sense, not 0xcccccccc. This needs to be investigated more. > Should we print out some of these results in hex as well to make life > easier? We should print them in just one format, decimal or hex, whichever makes more sense. > >I will now be concentrating on working out what is wrong with these > >tests :) Yep, I think this is priority number one now. Running the tests on more platforms would only return pretty much the same list of bugs again and again. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

Dec. 19, 2002

[D3D8 Patch] vertex shader integration + fixes - VS3

by Raphaël Junqueira

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again, this patch enable pixel shader rendering into D3D8 (and correct some stupid bugs i have) Changelog: - intergration with DrawPrimitive - remove non-esthetic c++ comments into c comments block ;) - more more debug Problems: - very slow - i have problem with textures, if people can look at code ... TODO: - better integrate vertex shader with draw primitive (maybe we have to splt DrawPrimitive) - optimize software emulation - hardware vertex shader program support (using auto-detect caps) - syntax validity of vertex shader declaration and vexter shader function code (Validate*Shader functions) - vertex shader compilator (in D3DX8) - pixel shaders can people test this, using simple shaders programs please ? thx, Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ARUYp7NA3AmQTU4RAn+QAJ0V2R3CugfcYJlygJUMAOhJXj68bQCfQxfH txo29ZkJSbuudmaxhYGUJSw= =Hw4m -----END PGP SIGNATURE-----

Dec. 19, 2002

Wineconsole 'regression'

by Lionel Ulmer

Hi all, Since the introduction of the 'ncurses' driver for the wineconsole program, the only program using the console is completely broken (IDA). Well, it actually starts faster than with the USER back-end but after that it's mostly unusable. I looked at the wineconsole code and it does not seem that there is a configure option or any other mean to have wineconsole act as before (ie to use the slow but working USER driver). So : 1) I did not look long enough 2) I should stop bitching and fix the ncurses driver What irks me is that the debugger is still working as before (ie not very stable, but at least not buggy in an xterm :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/

Dec. 18, 2002

Re: mingwrap -> mingcc

by Francois Gouget

On Wed, 18 Dec 2002, Dimitrie O. Paun wrote: > On December 18, 2002 03:36 pm, Francois Gouget wrote: [...] > > winegcc > > Why not wgcc? I had the impression that we were going away from just using 'w' as the prefix and more towards using 'wine'. So I'm proposing both forms. > So I am OK with the following: > wgcc > mingcc > wmingcc I think the ones I prefer are 'wgcc' and 'winegcc'. In both cases we can add variants: wcl / winecl (Visual C++), wbcc / winebcc (Borland C++ if memory serves), etc. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.

Dec. 18, 2002

Re: strcasecmp

by Francois Gouget

On Wed, 18 Dec 2002, Uwe Bonnes wrote: [...] > Are you sure that wxWindows doesn't do a > > #ifdef __WIN__ > #define strcasecmp stricmp > #endif > > somewhere? I sort of suspect something like this. And then the big question is why don't we get this #define when compiling with Wine? There is the same issue gethostname(). Visual C++ does not define it in the msvcrt headers so how does one compile wxWindows with visual C++? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

Dec. 18, 2002

Re: strcasecmp

by Dimitrie O. Paun

On December 18, 2002 05:06 pm, Francois Gouget wrote: > There is the same issue gethostname(). Visual C++ does not define it in > the msvcrt headers so how does one compile wxWindows with visual C++? Because these are apps that compile under MinGW using their headers for libc, not the crtdll/msvcrt ones. In theory, we should compile such apps using the native libc headers, but that does not work. And it does not work because of -fwchar-short, which is a must... So we are in a bit of a bind: we _have_ to use msvcrt, but the app expects functions that are present only in the Unix/MinGW headers. What do we do? -- Dimi.

Dec. 18, 2002

DLL-Loading

by efm.Pieschel＠t-online.de

Hello, is there any possibility to load a win32-dll from a Linux program? Thank You for Your response. Bye. Martin

Dec. 18, 2002

Re: strcasecmp

by Uwe Bonnes

>>>>> "Dimitrie" == Dimitrie O Paun <dpaun(a)rogers.com> writes: Dimitrie> On December 18, 2002 03:29 pm, Francois Gouget wrote: >> Actually I don't see strcasecmp defined anywhere on Windows, which is >> a bit strange. Should we remove it? Which application uses it? Dimitrie> wxWindows. Are you sure that wxWindows doesn't do a #ifdef __WIN__ #define strcasecmp stricmp #endif somewhere? 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. 18, 2002

Re: Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library

by Francois Gouget

On Wed, 18 Dec 2002, Dimitrie O. Paun wrote: > On December 18, 2002 03:28 am, Francois Gouget wrote: > > * if you want maximum compatibility, then use the msvcrt headers. Then > > you will not have that problem. > > To clarify this point: this app (actually library: wxWindows) when compiled > under MinGW expects stuff in headers that are not present in msvcrt headers > (such as gethostname()). So, for maximum compatibility, we need to support > native Unix headers. :) This seems a bit strange. So you say that on Linux sys/types.h causes FD_CLR to be defined. That was not the case last time I checked (admitedly months ago). Maybe it's a new glibc or gcc thing? (ok, checked, it is the case :-( that's new) The goal of the FD_CLR check was to 'gracefully' deal with source files that do: #include <stdlib.h> #include <windows.h> This would cause FD_CLR and more importantly fd_set, timeval and select to already be defined with incompatible types/prototypes. So, back to the sys/types.h issue. We apparently very much self-trigger the same issue with sys/types.h. So I'll move the FD_CLR section and post a patch. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware

Dec. 18, 2002

Re: strcasecmp

by Francois Gouget

On Wed, 18 Dec 2002, Dimitrie O. Paun wrote: > On December 18, 2002 03:29 pm, Francois Gouget wrote: > > Actually I don't see strcasecmp defined anywhere on Windows, which is a > > bit strange. Should we remove it? Which application uses it? > > wxWindows. Does it compile with Visual C++? I guess not if it's using strcasecmp. But the msvcrt headers are Visual C++ headers so I'm not sure they should contain stuff like strcasecmp. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Dieu dit: "M-x Lumière". Et la lumière fut.

Dec. 18, 2002

Re: mingwrap -> mingcc

by Dimitrie O. Paun

On December 18, 2002 03:36 pm, Francois Gouget wrote: > Shouldn't we have 'wine' somewhere in the name to avoid possible > conflicts? Of course it would be nice to also have something that > reminds of mingw so that we can later have other wrappers for Visual > C++, Borland C++, etc. (if the need arises, I don't see it right now) > > So: > wcc I suggest this one initially, but Alexandre objected (rightfully so) that it is too generic. It's a nice name, but we might need wrappers for different things in the future, and it does not scale. Besides, we want the name to say that we make gcc look like MinGW. > wgcc This one can work too, not bad. In fact, I like it: short, and to the point. The MinGW compiler is still called gcc, so this works out very nicely. > wincc > wingcc Long, and undescriptive. I'd say no. > winecc Too generic, it's the same (but longer :)) as wcc. > winegcc Why not wgcc? > wmingcc This can work too. So I am OK with the following: wgcc mingcc wmingcc Probably wgcc is the nicest, shortest, and maybe most easily recognizable for people. Alexandre, if renaming is acceptable, take your pick! :) just s/mingcc/<your pick>/g into the patch... -- Dimi.

Dec. 18, 2002

Re: strcasecmp

by Dimitrie O. Paun

On December 18, 2002 03:29 pm, Francois Gouget wrote: > Actually I don't see strcasecmp defined anywhere on Windows, which is a > bit strange. Should we remove it? Which application uses it? wxWindows. -- Dimi.

Dec. 18, 2002

Re: mingwrap -> mingcc

by Francois Gouget

On Wed, 18 Dec 2002, Dimitrie O. Paun wrote: [...] > Hi, > > I know this is a real off beat request: rename mingwrap to mingcc. > It is even so much stranger as I named the thing mingwrap. But to > be honest, I never liked the name, I think it is misleading. Shouldn't we have 'wine' somewhere in the name to avoid possible conflicts? Of course it would be nice to also have something that reminds of mingw so that we can later have other wrappers for Visual C++, Borland C++, etc. (if the need arises, I don't see it right now) So: wcc wgcc wincc wingcc winecc winegcc wmingcc -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

Dec. 18, 2002

Re: strcasecmp

by Francois Gouget

On Wed, 18 Dec 2002, Dimitrie O. Paun wrote: > > We don't have a _strcasecmp in msvcrt, but wew do have a _stricmp, > which seems to be doing the same thing. > > ChangeLog > Map strcasecmp to _stricmp. Actually I don't see strcasecmp defined anywhere on Windows, which is a bit strange. Should we remove it? Which application uses it? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.

Dec. 18, 2002

Re: [D3D8 PATCH] d3d8 shaders update - VS2

by Raphaël Junqueira

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 18 December 2002 09:21, Francois Gouget wrote: > On Wed, 18 Dec 2002, Raphaël Junqueira wrote: > > On Wednesday 18 December 2002 02:08, Tony Lambregts wrote: > > [...] > > > > <nitpick> C++ style comments are strongly discouraged </nitpick> > > > > Hi, > > > > yes, i know but this comment is INTO a block comment ;) > > and C comments will break the block comment > > The susual trick in such cases is to leave a space between the '*' and > > the '/': > > object->functionLength = 1; /* no Function defined use fixed function > > vertex processing * / ok, why not anyway this comment will be removed soon, it's here only for remembering me for HAL support and code cleaning ;) regards, Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ANmXp7NA3AmQTU4RAt4VAJ9zMCPu5jpmnU/igd3a2cll0rqY0wCeNO6M cAUJAoj9V1IsDBY2uWfXlgw= =XLbE -----END PGP SIGNATURE-----

Dec. 18, 2002

Re: [D3D8 PATCH] d3d8 shaders update - VS2

by Jeff Smith

The best way I know to create block comments *without* tampering with interior comments is like this: /* note about reason for commenting block */ #if 0 code code /* comments */ code #endif >From: Fabian Cenedese <Cenedese(a)indel.ch> > >> > >- object->functionLength = 1; /* no Function defined use fixed >> > > function vertex processing */ + object->functionLength = 1; // >>no >> > > Function defined use fixed function vertex processing >> > >> > <nitpick> C++ style comments are strongly discouraged </nitpick> >> >>yes, i know but this comment is INTO a block comment ;) >>and C comments will break the block comment > >What I usually do in such a case is change the existing tags like that: > >code /* comment */ > >becomes (note the spaces in the tags). > >/* block comment >code / * comment * / >*/ > >Like that you still see where the comment was but it doesn't end the block >anymore. Of course if the block comment gets removed you have to change >the tags back. > >bye Fabi _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

Dec. 18, 2002

Re: Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library

by Dimitrie O. Paun

On December 18, 2002 03:28 am, Francois Gouget wrote: > * if you want maximum compatibility, then use the msvcrt headers. Then > you will not have that problem. To clarify this point: this app (actually library: wxWindows) when compiled under MinGW expects stuff in headers that are not present in msvcrt headers (such as gethostname()). So, for maximum compatibility, we need to support native Unix headers. :) -- Dimi.

Dec. 18, 2002

Re: Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library

by Dimitrie O. Paun

On December 18, 2002 03:28 am, Francois Gouget wrote: > Or did you really mean that winsock.h includes sys/types.h which then > includes sys/select.h which defines FD_CLR? If that's the case then a > bit of reordering of code in winsock.h should solve the problem.` Indeed, that is the problem. At line 60 in include/winsock.h we have: #ifndef __WINE_USE_MSVCRT /* Get the u_xxx types from the Unix headers. They will do and doing it * this way will avoid redefinitions. But on FreeBSD we may get macros * and prototypes for htonl & co. This means the functions will not be * called because of the macros. So this should not harm us too much unless * we try to define our own prototypes (different calling convention). */ # include <sys/types.h> So this seems to try to solve the problem, but it is the very thing that causes it. It looks like you tried to make winsock.h work together with the Unix headers, so any insight into this problem will be highly appreciated. -- Dimi.

Dec. 18, 2002

re: wmc and ElectricFence

by Sylvain Petreolle

seems like I will have a look on valgrind... it gives more information. --- Dan Kegel <dank(a)kegel.com> a écrit : > Sure enough, valgrind finds something to complain about: > > $ cd dlls/kernel > $ make messages/winerr_enu.mc.rc > LD_LIBRARY_PATH="../../library:../../unicode:$LD_LIBRARY_PATH" > valgrind ../../tools/wmc/wmc -i -U -H > /dev/null -o messages/winerr_enu.mc.rc messages/winerr_enu.mc > ... > ==7935== Invalid read of size 4 > ==7935== at 0x804B7A4: yyparse (./mcy.y:232) > ==7935== by 0x804A4B3: main (wmc.c:256) > ==7935== by 0x420158D3: __libc_start_main (in > /lib/i686/libc-2.2.93.so) > ==7935== by 0x8048E50: (within > /home/dank/wine-20021125/tools/wmc/wmc) > ==7935== Address 0x4106E5E4 is 8 bytes inside a block of size 24 > free'd > ==7935== at 0x4015D715: free (vg_clientfuncs.c:182) > ==7935== by 0x804B79A: yyparse (./mcy.y:231) > ==7935== by 0x804A4B3: main (wmc.c:256) > ==7935== by 0x420158D3: __libc_start_main (in > /lib/i686/libc-2.2.93.so) > > Recompiling wmc with -O0 and rerunning, I get > ==7970== Invalid read of size 4 > ==7970== at 0x804C73E: yyparse (./mcy.y:232) > ==7970== by 0x804AA3B: main (wmc.c:256) > ==7970== by 0x420158D3: __libc_start_main (in > /lib/i686/libc-2.2.93.so) > ==7970== by 0x8048D6C: (within > /home/dank/wine-20021125/tools/wmc/wmc) > ==7970== Address 0x4106E5E4 is 8 bytes inside a block of size 24 > free'd > ==7970== at 0x4015D715: free (vg_clientfuncs.c:182) > ==7970== by 0x804D2F4: do_add_token (./mcy.y:434) > ==7970== by 0x804C731: yyparse (./mcy.y:231) > ==7970== by 0x804AA3B: main (wmc.c:256) > > Looking at y.tab.c, I see the bug is that do_add_token > sometimes frees its 2nd argument, which trips up the > following line sometimes. Here's the sequence that crashed: > > do_add_token(tok_language, yyvsp[-6].tok, "language"); > if(!find_language(yyvsp[-6].tok->token) && > !find_cpxlat(yyvsp[-6].tok->token)) > > These come from mcy.y: > > do_add_token(tok_language, $1, "language"); > if(!find_language($1->token) && !find_cpxlat($1->token)) > > Can someone who knows wmc have a look? > - Dan > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Dec. 18, 2002

re: wmc and ElectricFence

by Dan Kegel

Sure enough, valgrind finds something to complain about: $ cd dlls/kernel $ make messages/winerr_enu.mc.rc LD_LIBRARY_PATH="../../library:../../unicode:$LD_LIBRARY_PATH" valgrind ../../tools/wmc/wmc -i -U -H /dev/null -o messages/winerr_enu.mc.rc messages/winerr_enu.mc ... ==7935== Invalid read of size 4 ==7935== at 0x804B7A4: yyparse (./mcy.y:232) ==7935== by 0x804A4B3: main (wmc.c:256) ==7935== by 0x420158D3: __libc_start_main (in /lib/i686/libc-2.2.93.so) ==7935== by 0x8048E50: (within /home/dank/wine-20021125/tools/wmc/wmc) ==7935== Address 0x4106E5E4 is 8 bytes inside a block of size 24 free'd ==7935== at 0x4015D715: free (vg_clientfuncs.c:182) ==7935== by 0x804B79A: yyparse (./mcy.y:231) ==7935== by 0x804A4B3: main (wmc.c:256) ==7935== by 0x420158D3: __libc_start_main (in /lib/i686/libc-2.2.93.so) Recompiling wmc with -O0 and rerunning, I get ==7970== Invalid read of size 4 ==7970== at 0x804C73E: yyparse (./mcy.y:232) ==7970== by 0x804AA3B: main (wmc.c:256) ==7970== by 0x420158D3: __libc_start_main (in /lib/i686/libc-2.2.93.so) ==7970== by 0x8048D6C: (within /home/dank/wine-20021125/tools/wmc/wmc) ==7970== Address 0x4106E5E4 is 8 bytes inside a block of size 24 free'd ==7970== at 0x4015D715: free (vg_clientfuncs.c:182) ==7970== by 0x804D2F4: do_add_token (./mcy.y:434) ==7970== by 0x804C731: yyparse (./mcy.y:231) ==7970== by 0x804AA3B: main (wmc.c:256) Looking at y.tab.c, I see the bug is that do_add_token sometimes frees its 2nd argument, which trips up the following line sometimes. Here's the sequence that crashed: do_add_token(tok_language, yyvsp[-6].tok, "language"); if(!find_language(yyvsp[-6].tok->token) && !find_cpxlat(yyvsp[-6].tok->token)) These come from mcy.y: do_add_token(tok_language, $1, "language"); if(!find_language($1->token) && !find_cpxlat($1->token)) Can someone who knows wmc have a look? - Dan

Dec. 18, 2002

Re: critical section timeout for the dsound_test

by Sylvain Petreolle

I have same issue, but the debugger manages to start and "ends" in the X video binary. Could be a stupid question, but what is your VIDEO driver ? Mine is nVidia binary, and I have got some problems with it. I have reproductible crashes with it (like this test) for a long time. Don't worry, I know this is a dsound test... :) --- Enrico Horn <farmboy1(a)subdimension.com> a écrit : > Hi, Should this happen? > > ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p > dsound_test.exe.so dsound.c && touch dsound.ok > fixme:dsound:IDirectSoundImpl_SetCooperativeLevel > (0x403bab28,00010020,2):stub > fixme:dsound:IDirectSoundImpl_SetCooperativeLevel > (0x403bab28,00010020,2):stub > err:ntdll:RtlpWaitForCriticalSection section 0x400e40e4 > "../../loader/module.c: loader_section" wait timed out, retrying (60 > sec) > tid=080ddc30 > wine: Unhandled exception, starting debugger... > err:ntdll:RtlpWaitForCriticalSection section 0x400e40e4 > "../../loader/module.c: loader_section" wait timed out, retrying (60 > sec) > tid=080ddc30 > err:seh:EXC_DefaultHandling Unhandled exception code c0000194 flags 0 > addr > 0x400b3ce4 > > Wine is from CVS just updated this morning. > make test will continue despite these errors. > > Have fun > Farmboy > farmboy1(a)subdimension.com > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Dec. 18, 2002

Re: How long does it take *you* to build wine?

by Dan Kegel

Summary of wall clock time from clean "time make" for 20021125: dk, gcc2.94, debian 3.0: 8 min : dual 1.4GHz P4 Xeon, 512 MB RAM, 256KB L2 cache each dk, gcc3.2, red hat 8.0: 16min 1sec: distcc with dual 650MHz, 750MHz laptop, and a 1.1GHz celeron 17min 21sec: dual 650MHz PIII, 400 MB RAM, 256KB L2 cache each, 7200RPM disk 19min : 1.4GHz Athlon, 256 MB RAM, 256KB L2 cache 30min : 750MHz PIII laptop, 400 MB RAM mf, ? 16m56s : 1.8 GHz P4 ms, ? 30min : 900MHz athlon, 512 MB RAM "much faster than this with ccache -- was going to buy new motherboard, now I'll wait" bm, gcc2.95rh, red hat 7.3: 47m0s : 450MHz Celeron, 128MB jm, gcc3.2 47m41s : 550MHz athlon, 192 MB Ram tl, ?: 180m : 300MHz Pentium II, 96 MB RAM am, ? >>> 180m : 133MHz Pentium I, 64 MB RAM My impressions -- * gcc2.9x is probably a fair bit faster than gcc3.2 * ccache is a win * distcc is only a win if you have several equally fast machines * athlons don't do quite as well as their clock speed would indicate * dual processors go twice as fast as single processors (imagine that)

Dec. 18, 2002

COM conformance test suite?

by Dan Kegel

Now that the Wine regression tests are starting to shape up, and people are starting to be able to run Visual Basic apps, maybe it's time for us to start thinking about getting ahold of the COM conformance test suite the Open Group did as a companion for their ActiveX standard definition. The Open Group was willing to discuss this, but last time I checked, they wanted to know what was in it for them. (Well, they're not the Free Group, after all.) In particular, they thought it might take them a bit of work to separate the conformance test suite out from their "reference implementation" of ActiveX for Unix. Given that attitude, the best strategy is probably to start implementing our own test suite for the APIs in question, and shame them into opening theirs :-) For those who haven't seen it yet, the Open Group's ActiveX spec (http://www.opengroup.org/onlinepubs/009899899/ ) is perhaps the only document defining Win32 API calls in a standards-body-like-way. (The Tru64 Unix doc, http://www.tru64unix.compaq.com/com/documentation/building/ contains some related material. Might be worth archiving this before it goes offline as HP discontinues Tru64 Unix.) The Open Group spec only covers a little bit of Win32, but it sure looks like a useful bit. The #include files it seems to define are: #include <comcat.h> #include <oaidl.h> #include <objbase.h> #include <objidl.h> #include <ocidl.h> #include <ole2.h> #include <oleauto.h> #include <olectl.h> #include <oleidl.h> #include <unknwn.h> #include <urlmon.h> #include <winerror.h> #include <winnls.h> #include <winreg.h> which is a fair chunk. - Dan p.s. My cat is helping test mozilla 1.3alpha. She discovered just now that running across the keyboard causes that app to abort with sig 11...

Dec. 18, 2002

wmc and ElectricFence

by Sylvain Petreolle

Looking for memleaks in wine, I tried to compile the current CVS and link with ElectricFence. I did LDFLAGS=-lefence ./configure. Running make in dlls/kernel detects a problem in wmc (hope its not in ElectricFence ;)): make[2]: Entre dans le répertoire `/home/wine/dlls/kernel' LD_LIBRARY_PATH="../../library:../../unicode:$LD_LIBRARY_PATH" ../../tools/wmc/wmc -i -U -H /dev/null -o messages/winerr_enu.mc.rc messages/winerr_enu.mc Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens <bruce(a)perens.com> messages/winerr_enu.mc:19: Oops, segment violation make[2]: *** [messages/winerr_enu.mc.rc] Abandon make[2]: Quitte le répertoire `/home/wine/dlls/kernel' make[1]: *** [kernel] Erreur 2 make[1]: Quitte le répertoire `/home/wine/dlls' make: *** [dlls] Erreur 2 ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Dec. 18, 2002

critical section timeout for the dsound_test

by Enrico Horn

Hi, Should this happen? ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c && touch dsound.ok fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403bab28,00010020,2):stub fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403bab28,00010020,2):stub err:ntdll:RtlpWaitForCriticalSection section 0x400e40e4 "../../loader/module.c: loader_section" wait timed out, retrying (60 sec) tid=080ddc30 wine: Unhandled exception, starting debugger... err:ntdll:RtlpWaitForCriticalSection section 0x400e40e4 "../../loader/module.c: loader_section" wait timed out, retrying (60 sec) tid=080ddc30 err:seh:EXC_DefaultHandling Unhandled exception code c0000194 flags 0 addr 0x400b3ce4 Wine is from CVS just updated this morning. make test will continue despite these errors. Have fun Farmboy farmboy1(a)subdimension.com

Dec. 18, 2002

Re: Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library

by Francois Gouget

On Wed, 18 Dec 2002, Dimitrie O. Paun wrote: > Folks, > > This does not work (<= is include): > winsock.h > <= sys/types.h > <= sys/select.h > > BANG! FD_CLR gets defined before we have a chance to manipulate it. > > Any ideas on how to fix this? I assume this is for Winelib. Then here are your choices as I see them: * if you want maximum compatibility, then use the msvcrt headers. Then you will not have that problem. * if you want to use the regular Unix headers, then the price will be a tinybit of reordering of the #includes so that sys/types.h gets included after sys/types.h and that should work too. Unfortunately I don't think there is any other solution. Or did you really mean that winsock.h includes sys/types.h which then includes sys/select.h which defines FD_CLR? If that's the case then a bit of reordering of code in winsock.h should solve the problem.` -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !

Dec. 18, 2002

Re: [D3D8 PATCH] d3d8 shaders update - VS2

by Francois Gouget

On Wed, 18 Dec 2002, Raphaël Junqueira wrote: > > On Wednesday 18 December 2002 02:08, Tony Lambregts wrote: [...] > > <nitpick> C++ style comments are strongly discouraged </nitpick> > > Hi, > > yes, i know but this comment is INTO a block comment ;) > and C comments will break the block comment The susual trick in such cases is to leave a space between the '*' and the '/': > object->functionLength = 1; /* no Function defined use fixed function vertex processing * / -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.

Dec. 18, 2002

Re: [D3D8 PATCH] d3d8 shaders update - VS2

by Fabian Cenedese

> > >- object->functionLength = 1; /* no Function defined use fixed > > > function vertex processing */ + object->functionLength = 1; // no > > > Function defined use fixed function vertex processing > > > > <nitpick> C++ style comments are strongly discouraged </nitpick> > >yes, i know but this comment is INTO a block comment ;) >and C comments will break the block comment What I usually do in such a case is change the existing tags like that: code /* comment */ becomes (note the spaces in the tags). /* block comment code / * comment * / */ Like that you still see where the comment was but it doesn't end the block anymore. Of course if the block comment gets removed you have to change the tags back. bye Fabi

Dec. 18, 2002

Include_winsock_h_before_stdlib_h_or_use_the_MSVCRT_library

by Dimitrie O. Paun

Folks, This does not work (<= is include): winsock.h <= sys/types.h <= sys/select.h BANG! FD_CLR gets defined before we have a chance to manipulate it. Any ideas on how to fix this? -- Dimi.

Dec. 18, 2002

Re: [D3D8 PATCH] d3d8 shaders update - VS2

by Raphaël Junqueira

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 18 December 2002 02:08, Tony Lambregts wrote: > Raphaël Junqueira wrote: > > [snip] > > > object->declLength = i + 1; > >- object->function = pFunction; > > if (NULL != pFunction) { > > for (i = 0; 0xFFFFFFFF != pFunction[i]; ++i) ; > > object->functionLength = i + 1; > > } else { > >- object->functionLength = 1; /* no Function defined use fixed > > function vertex processing */ + object->functionLength = 1; // no > > Function defined use fixed function vertex processing > > <nitpick> C++ style comments are strongly discouraged </nitpick> Hi, yes, i know but this comment is INTO a block comment ;) and C comments will break the block comment regards, Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ACUcp7NA3AmQTU4RAtIVAKCBGBj62TB1Fu2URiFGNUBPlrKqrwCfbVqR B5J4LRyILcOX5k0bgs8xf08= =3ITV -----END PGP SIGNATURE-----

Dec. 18, 2002

Re: running cygwin apps(gcc etc.) under wine

by Dmitry Timoshkov

"Chris Morgan" <cmorgan(a)alum.wpi.edu> wrote: > Ahh, very cool. Is there anything we can do to keep cygwin from replacing > wines/libc's fork with its own and presumably fix this problem? I'm afraid it's impossible to replace cygwin's fork by an one from libc. Cygwin makes some assumptions about "environment" where it runs and accordingly patches virtual memory of a newly created process to mimic fork behaviour. -- Dmitry.

Dec. 18, 2002

Re: running cygwin apps(gcc etc.) under wine

by Chris Morgan

Ahh, very cool. Is there anything we can do to keep cygwin from replacing wines/libc's fork with its own and presumably fix this problem? Chris On Tuesday 17 December 2002 10:34 pm, Dmitry Timoshkov wrote: > <chrismorgan(a)rcn.com> wrote: > > Trying to run my work related code build process under wine results in > > some failures with cygwin's gcc. Even with a simple hello > > world.c file and 'gcc -o test test.c' I get: > > 0 [main] gcc -134958416 sync_with_child: child 134963016(0xB0) died > > before initialization with status code 0x1 2599 [main] gcc -134958416 > > sync_with_child: *** child state waiting for longjmp 1335488 [main] gcc > > -134958416 sync_with_child: child 134968376(0xC0) died before > > initialization with status code 0x1 1337536 [main] gcc -134958416 > > sync_with_child: *** child state waiting for longjmp 3711485 [main] gcc > > -134958416 sync_with_child: child 134969736(0xD0) died before > > initialization with status code 0x1 3713593 [main] gcc -134958416 > > sync_with_child: *** child state waiting for longjmp 8125556 [main] gcc > > -134958416 sync_with_child: child 134970152(0xE0) died before > > initialization with status code 0x1 8127752 [main] gcc -134958416 > > sync_with_child: *** child state waiting for longjmp gcc: vfork: Resource > > temporarily unavailable > > > > Any ideas why this is occuring? Is this due to issues with pthreads? > > Very likely this is due to the implementation of 'fork' in cygwin.

Dec. 18, 2002

Re: running cygwin apps(gcc etc.) under wine

by Dimitrie O. Paun

On December 18, 2002 12:22 am, Chris Morgan wrote: > Ahh, very cool. Is there anything we can do to keep cygwin from replacing > wines/libc's fork with its own and presumably fix this problem? I would say: why doesn't cygwin's fork work on top of wine? I'd say that needs to be fixed, if possible. Using the native fork should be fairly simple, but it does defeat the purpose a bit... -- Dimi.

Dec. 18, 2002

Re: wineboot - adapting to wine build env

by Sylvain Petreolle

Reading wine-cvs archive, I see that the patch doesn't create the programs/wineboot directory in the repository. Is this point mandatory ? ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Dec. 18, 2002

Re: Documentation cleanup for Relay|Snoop-Include|Exclude

by Dmitry Timoshkov

"Uwe Bonnes" <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > +.I --debugmsg -relay > +will turn on all relay messages. For more control on including or excluding > +functions and dlls look into the [Debug] section of the wine configuration file. Shouldn't it be '+relay'? -- Dmitry.

Dec. 18, 2002

Re: running cygwin apps(gcc etc.) under wine

by Dmitry Timoshkov

<chrismorgan(a)rcn.com> wrote: > Trying to run my work related code build process under wine results in some failures with cygwin's gcc. Even with a simple hello world.c file and 'gcc -o test test.c' I get: > > 0 [main] gcc -134958416 sync_with_child: child 134963016(0xB0) died before initialization with status code 0x1 > 2599 [main] gcc -134958416 sync_with_child: *** child state waiting for longjmp > 1335488 [main] gcc -134958416 sync_with_child: child 134968376(0xC0) died before initialization with status code 0x1 > 1337536 [main] gcc -134958416 sync_with_child: *** child state waiting for longjmp > 3711485 [main] gcc -134958416 sync_with_child: child 134969736(0xD0) died before initialization with status code 0x1 > 3713593 [main] gcc -134958416 sync_with_child: *** child state waiting for longjmp > 8125556 [main] gcc -134958416 sync_with_child: child 134970152(0xE0) died before initialization with status code 0x1 > 8127752 [main] gcc -134958416 sync_with_child: *** child state waiting for longjmp > gcc: vfork: Resource temporarily unavailable > > Any ideas why this is occuring? Is this due to issues with pthreads? Very likely this is due to the implementation of 'fork' in cygwin. -- Dmitry.

Dec. 18, 2002

Re: running cygwin apps(gcc etc.) under wine

by Sylvain Petreolle

strange... did you try running cygwin precompiled binaries ? some commands seems to work. maybe im not seeing something but all shells I try to execute with wcmd just logout immediately when you run it. otherwise other commands seem to be fine. if gcc is creating subprocesses, I have the same issue with shells. they try to execute some external commands and fail. maybe the whole cygwin procedure to run cygwin binaries doesnt work with our code. --- chrismorgan(a)rcn.com a écrit : > Trying to run my work related code build process under wine results > in some failures with cygwin's gcc. Even with a simple hello world.c > file and 'gcc -o test test.c' I get: > > 0 [main] gcc -134958416 sync_with_child: child 134963016(0xB0) > died before initialization with status code 0x1 > 2599 [main] gcc -134958416 sync_with_child: *** child state waiting > for longjmp > 1335488 [main] gcc -134958416 sync_with_child: child 134968376(0xC0) > died before initialization with status code 0x1 > 1337536 [main] gcc -134958416 sync_with_child: *** child state > waiting for longjmp > 3711485 [main] gcc -134958416 sync_with_child: child 134969736(0xD0) > died before initialization with status code 0x1 > 3713593 [main] gcc -134958416 sync_with_child: *** child state > waiting for longjmp > 8125556 [main] gcc -134958416 sync_with_child: child 134970152(0xE0) > died before initialization with status code 0x1 > 8127752 [main] gcc -134958416 sync_with_child: *** child state > waiting for longjmp > gcc: vfork: Resource temporarily unavailable > > Any ideas why this is occuring? Is this due to issues with pthreads? > > Thanks, > Chris > > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Dec. 18, 2002

Re: windows visual view ?

by Tom Wickline

Dimitrie O. Paun wrote: > On December 16, 2002 01:08 pm, Francois Gouget wrote: > >>Would this be more or less what you are looking for? > > > That's OK, but I was looking for some of them architecture > diagrams that explain the interaction between processes > and wineserver. Something to shed some light on the more > obscure corners of wine. This ones are OK, but we kinda already > know that yeah, Wine is build on top on Linux... :) > I was thinking of this after a discussion on our LUG mailing list about Networking.. here is kinda how my network is set up .. Cable Modem (RoadRunner) | Broadband Router | | Win2KComputer | | Linux Box with NAT Firewall (ipchains or iptables) | Hub | Some hobby computers here is my friends Cable modem -- Hub -- Linux firewall -- Switch ------- Linux server | |--- NT4 tower | |--- Access point | |---- Powerline bridges -- Hub -- Playstation 2 I was just wondering if anyone had made a windows / OS diagram ? and then if you made a Wine diagram how would it look ? Thanks Tom

Dec. 18, 2002

Re: [D3D8 PATCH] d3d8 shaders update - VS2

by Tony Lambregts

Raphaël Junqueira wrote: [snip] > object->declLength = i + 1; >- object->function = pFunction; > if (NULL != pFunction) { > for (i = 0; 0xFFFFFFFF != pFunction[i]; ++i) ; > object->functionLength = i + 1; > } else { >- object->functionLength = 1; /* no Function defined use fixed function vertex processing */ >+ object->functionLength = 1; // no Function defined use fixed function vertex processing > > <nitpick> C++ style comments are strongly discouraged </nitpick> -- Tony Lambregts

Dec. 18, 2002

Re: wineboot - adapting to wine build env

by Matthew Davison

On Tue, 2002-12-17 at 19:23, Shachar Shemesh wrote: > If anyone did not understand, my previous post was with Andy's > implementation of wineboot. This post is with the changes to the rest of > Wine to make wineboot fit in better. > > Also - my previous patch included a Makefile file by mistake. Please > ignore and sorry for the noise. > > Changelog: > Shachar Shemesh <winecode(a)sun.consumer.org.il> > > * Add wineboot to the makefiles so it will compile > * Add wineboot's configs to the default config file > > I have some work to the RunOnceEx section of wineboot, once (and if) Andy's version is commited will send a patch. (the work involves a couple of bugfixes and some work on the rundll type calls(ones with | symbols)) > > ______________________________________________________________________ > > Index: configure.ac > =================================================================== > RCS file: /home/sun/sources/cvs/wine/configure.ac,v > retrieving revision 1.112 > diff -u -r1.112 configure.ac > --- configure.ac 17 Dec 2002 01:49:17 -0000 1.112 > +++ configure.ac 17 Dec 2002 17:57:55 -0000 > @@ -1494,6 +1494,7 @@ > programs/uninstaller/Makefile > programs/view/Makefile > programs/wcmd/Makefile > +programs/wineboot/Makefile > programs/wineconsole/Makefile > programs/winedbg/Makefile > programs/winefile/Makefile > Index: documentation/samples/config > =================================================================== > RCS file: /home/sun/sources/cvs/wine/documentation/samples/config,v > retrieving revision 1.37 > diff -u -r1.37 config > --- documentation/samples/config 13 Dec 2002 02:26:18 -0000 1.37 > +++ documentation/samples/config 17 Dec 2002 18:51:49 -0000 > @@ -67,6 +67,29 @@ > ;"ShowDotFiles" = "1" > "ShellLinker" = "wineshelllink" > > +[wineboot] > +"BootConfig_Enable" = "1" > +# do a dry run, i.e. show what to do, but don't act > +"BootConfig_DryRun" = "0" > +# extra verbosity on console > +"BootConfig_TTY_Verbose" = "0" > +# extra quiet on console > +"BootConfig_TTY_Quiet" = "0" > +# process wininit.ini ? > +"WininitIni_Execute" = "1" > +"RunServicesOnce_Execute" = "1" > +"RunServicesHKLM_Execute" = "1" > +"RenameFiles_Execute" = "1" > +"RunOnceHKLM_Execute" = "1" > +"RunOnceEx_Execute" = "1" > +"WinIniLoad_Execute" = "1" > +"WinIniRun_Execute" = "1" > +"RunHKLM_Execute" = "1" > +"RunHKCU_Execute" = "1" > +"StartupFolderCommon_Execute" = "1" > +"StartupFolderUser_Execute" = "1" > +"RunOnceHKCU_Execute" = "1" > + > # <wineconf> > > [Version] > Index: programs/Makefile.in > =================================================================== > RCS file: /home/sun/sources/cvs/wine/programs/Makefile.in,v > retrieving revision 1.32 > diff -u -r1.32 Makefile.in > --- programs/Makefile.in 2 Dec 2002 21:17:05 -0000 1.32 > +++ programs/Makefile.in 17 Dec 2002 17:57:08 -0000 > @@ -22,6 +22,7 @@ > uninstaller \ > view \ > wcmd \ > + wineboot \ > wineconsole \ > winedbg \ > winefile \ -- Matthew Davison <m.davison(a)virgin.net>

Dec. 17, 2002

running cygwin apps(gcc etc.) under wine

by chrismorgan＠rcn.com

Trying to run my work related code build process under wine results in some failures with cygwin's gcc. Even with a simple hello world.c file and 'gcc -o test test.c' I get: 0 [main] gcc -134958416 sync_with_child: child 134963016(0xB0) died before initialization with status code 0x1 2599 [main] gcc -134958416 sync_with_child: *** child state waiting for longjmp 1335488 [main] gcc -134958416 sync_with_child: child 134968376(0xC0) died before initialization with status code 0x1 1337536 [main] gcc -134958416 sync_with_child: *** child state waiting for longjmp 3711485 [main] gcc -134958416 sync_with_child: child 134969736(0xD0) died before initialization with status code 0x1 3713593 [main] gcc -134958416 sync_with_child: *** child state waiting for longjmp 8125556 [main] gcc -134958416 sync_with_child: child 134970152(0xE0) died before initialization with status code 0x1 8127752 [main] gcc -134958416 sync_with_child: *** child state waiting for longjmp gcc: vfork: Resource temporarily unavailable Any ideas why this is occuring? Is this due to issues with pthreads? Thanks, Chris

Dec. 17, 2002

Re: First part of patch to extend functionality of SHFileOperation

by Ryan Cumming

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On December 17, 2002 14:06, Rolf Kalbermatter wrote: > +#define ASK_DELETE_MULTIP LE_ITEM 3 I'm assuming you didn't mean to include that first space... - -Ryan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE9/6RlLGMzRzbJfbQRAhdiAKCSn9ZOaXSgI2NxaH+u24r31WX5gQCdEvO4 2vD9LwIKWXrPQzANzJYUVTQ= =AEyu -----END PGP SIGNATURE-----

Dec. 17, 2002

Re: PATCH: implemented Fiber APIs

by Alexandre Julliard

Alberto Massari <alby(a)exln.com> writes: > It's just a matter of deciding what is best from a maintenance point > of view: grouping the working code or grouping the functions. > There are valid arguments in favour of both styles, and I have no > strong feelings, so I will submit the new patch shortly. > In any case... what is the policy in this case? In general, the right approach is to implement an emulation for the missing functions in port.c and don't have a single #ifdef inside the code itself. In this particular case, the right fix is to not use ucontext at all, but setjmp/longjmp instead. Actually I have a patch that does this, I'll merge it in. -- Alexandre Julliard julliard(a)winehq.com

Dec. 17, 2002

Re: PATCH: implemented Fiber APIs

by Dimitrie O. Paun

On December 17, 2002 04:59 am, Alberto Massari wrote: > It's just a matter of deciding what is best from a maintenance point of > view: grouping the working code or grouping the functions. I would say grouping the working code is preferable (second patch you sent) as the ugliness does not interfere with one's reading of the code. > There are valid arguments in favour of both styles, and I have no strong > feelings, so I will submit the new patch shortly. > In any case... what is the policy in this case? In general we don't go for either method, but rather we test for the feature in port.h, and if absent we have our own implementation in port.c. But it doesn't work well in this case. >From my point of view, your second patch is better than the first. Another way of doing it is stubbing the *context functions like so: #ifndef HAVE_U_CONTEXT typedef struct ucontext { } ucontext_t; int getcontext (ucontext_t *ucp) { return -1; } int setcontext (const ucontext_t *ucp) { return -1; } int swapcontext (ucontext_t *oucp, ucontext_t *ucp) { return -1; } void makecontext(ucontext_t *ucp, void *func(), int argc, ...) { return -1; } #endif -- Dimi.

Dec. 17, 2002

Re: Excluding whole dlls from a relay log, was Re: [RESENT (20021013)]...

by Dmitry Timoshkov

"Uwe Bonnes" <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > Please let me know in what way the user is supposed to exclude whole dlls > from a relay trace so I can fix the behaviour and docs. [Debug] "RelayExclude" = "user32.*;x11drv.*" should work. -- Dmitry.

Dec. 17, 2002

Re: How long does it take *you* to build wine?

by Alberto Massari

At 22.51 15/12/2002 -0800, Dan Kegel wrote: >[..] > >So how long does it take *you* to do a clean build >(just the 'make' part after 'make depend', say) of >Wine-20021125? On a notebook with a Pentium III-M 600MHz, 256Mb of RAM, (Mandrake 9 with gcc 3.2): 41m:32s Alberto ------------------------------- Alberto Massari eXcelon Corp. http://www.StylusStudio.com

Dec. 17, 2002

Re: PATCH: implemented Fiber APIs

by Alberto Massari

At 02.02 17/12/2002 -0500, Dimitrie O. Paun wrote: >On December 16, 2002 02:37 pm, Alberto Massari wrote: > > +void WINAPI SwitchToFiber(LPVOID lpFiber) > > +{ > > +#ifdef HAVE_UCONTEXT_H > > + PHFIBER pFiber,pCurrentFiber; > > + pFiber=(PHFIBER)lpFiber; > > + pCurrentFiber=(PHFIBER)TlsGetValue(fiber_tls_index); > > + TRACE("Switching from %p to %p\n",pFiber,pCurrentFiber); > > + TlsSetValue(fiber_tls_index,pFiber); > > + swapcontext(&pCurrentFiber->context,&pFiber->context); > > +#else > > + FIXME("stub\n"); > > +#endif > > +} > >Can you (pretty) please do without the ifdefs? They can probably >be located in only one spot, if you need to test for HAVE_UCONTEXT_H. I added them when I realized that ucontext.h could not be present on some systems, as "configure" tests for its presence and adds that preprocessor directive. The alternative layout would be #ifdef HAVE_UCONTEXT_H #include <ucontext.h> LPVOID WINAPI ConvertThreadToFiber(... { .... } LPVOID WINAPI CreateFiber(... { .... } .... #else LPVOID WINAPI ConvertThreadToFiber(... { FIXME("stub\n"); } LPVOID WINAPI CreateFiber(... { FIXME("stub\n"); } ... #endif It's just a matter of deciding what is best from a maintenance point of view: grouping the working code or grouping the functions. There are valid arguments in favour of both styles, and I have no strong feelings, so I will submit the new patch shortly. In any case... what is the policy in this case? a) there is an HOWTO on the subject, that I didn't read :-( b) there is no previous agreement on this, and Alexandre decides c) there is no previous agreement on this, and a poll is submitted to the mailing list d) other options Alberto ------------------------------- Alberto Massari eXcelon Corp. http://www.StylusStudio.com

Dec. 17, 2002

Re: How long does it take *you* to build wine?

by Alberto Massari

Nobody can beat my old Pentium 133 with 64 Mb.... it usually took more than 4 hours to just do a "make" after a refresh.... If you are really curious, I can time how long it takes to do a full build.... Alberto At 20.12 16/12/2002 -0700, Tony Lambregts wrote: >Bill Medland wrote: > >>On December 15, 2002 10:51 pm, Dan Kegel wrote: >>snip >> >> >>>So how long does it take *you* to do a clean build >>>(just the 'make' part after 'make depend', say) of >>>Wine-20021125? >>>- Dan >>> >> >>(I was wondering if mine was the slowest!) >>real - 47m0.357 >>user-43m1.631 >>sys-2m51.668 >> >>Celeron 450 with 128MB running RedHat 7.3 >> >>snip >> >No yours is fast compared to my <blush> 300mhz pentium with 96mb of ram >(around 3 hours) </blush> > >-- > >Tony Lambregts > > >

Dec. 17, 2002

Excluding whole dlls from a relay log, was Re: [RESENT (20021013)]...

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> Changelog: relay32/relay386.c: check_relay_include Treat whole dlls >> as advertised Alexandre> IMO the current behavior is correct. If the documentation Alexandre> says otherwise it needs to be fixed. I don't see any chance to exclude a whole dll from relay debugging in the present scheme. In most cases one doesn't want to see the output from x11drv and gdi32. Do we really want to deny such a user request? Or has the ability to do it on the command line (like --debugmsg -relay=x11drv") only been broken by chance and needs fixing? Please let me know in what way the user is supposed to exclude whole dlls from a relay trace so I can fix the behaviour and docs. 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. 17, 2002

Compiling problem

by winedevel＠007mundo.com

Hello, i have this compiling problem (sorry if this isn't the correct list, if yes, please let me know) make[2]: *** [ppy.tab.c] core dumped .. make[1]: *** [wrc/__depend__] Error 2 .. make: *** [tools/__depend__] Error 2 and what? Thanks ----------------------------------------------------- Obtenga su mail gratis con 007 Mundo www.007mundo.com -----------------------------------------------------

Dec. 17, 2002

Re: windows visual view ?

by Dimitrie O. Paun

On December 16, 2002 01:08 pm, Francois Gouget wrote: > Would this be more or less what you are looking for? That's OK, but I was looking for some of them architecture diagrams that explain the interaction between processes and wineserver. Something to shed some light on the more obscure corners of wine. This ones are OK, but we kinda already know that yeah, Wine is build on top on Linux... :) -- Dimi.

Dec. 17, 2002

Re: PATCH: implemented Fiber APIs

by Dimitrie O. Paun

On December 16, 2002 02:37 pm, Alberto Massari wrote: > +void WINAPI SwitchToFiber(LPVOID lpFiber) > +{ > +#ifdef HAVE_UCONTEXT_H > + PHFIBER pFiber,pCurrentFiber; > + pFiber=(PHFIBER)lpFiber; > + pCurrentFiber=(PHFIBER)TlsGetValue(fiber_tls_index); > + TRACE("Switching from %p to %p\n",pFiber,pCurrentFiber); > + TlsSetValue(fiber_tls_index,pFiber); > + swapcontext(&pCurrentFiber->context,&pFiber->context); > +#else > + FIXME("stub\n"); > +#endif > +} Can you (pretty) please do without the ifdefs? They can probably be located in only one spot, if you need to test for HAVE_UCONTEXT_H. -- Dimi.

Dec. 17, 2002

Re: stub handling

by Dimitrie O. Paun

On December 16, 2002 08:42 pm, Alexandre Julliard wrote: > We need to implement them, importing stubs no longer works (but of > course you can do a stub implementation instead ;-) Of, of, of, of, offff... :) ChangeLog Add stubs for {Start,End}{Doc,Page}Printer. Index: dlls/winspool/info.c =================================================================== RCS file: /var/cvs/wine/dlls/winspool/info.c,v retrieving revision 1.61 diff -u -r1.61 info.c --- dlls/winspool/info.c 12 Nov 2002 02:22:24 -0000 1.61 +++ dlls/winspool/info.c 17 Dec 2002 06:43:09 -0000 @@ -1274,6 +1274,51 @@ } /***************************************************************************** + * EndDocPrinter [WINSPOOL.@] + */ +BOOL WINAPI EndDocPrinter(HANDLE hPrinter) +{ + FIXME("(hPrinter=%p): stub\n", hPrinter); + return FALSE; +} + +/***************************************************************************** + * EndPagePrinter [WINSPOOL.@] + */ +BOOL WINAPI EndPagePrinter(HANDLE hPrinter) +{ + FIXME("(hPrinter=%p): stub\n", hPrinter); + return FALSE; +} + +/***************************************************************************** + * StartDocPrinterA [WINSPOOL.@] + */ +DWORD WINAPI StartDocPrinterA(HANDLE hPrinter, DWORD Level, LPBYTE pDocInfo) +{ + FIXME("(hPrinter=%p, Level=0x%lx, pDocInfo=%p): stub\n", hPrinter, Level, pDocInfo); + return FALSE; +} + +/***************************************************************************** + * StartDocPrinterW [WINSPOOL.@] + */ +DWORD WINAPI StartDocPrinterW(HANDLE hPrinter, DWORD Level, LPBYTE pDocInfo) +{ + FIXME("(hPrinter=%p, Level=0x%lx, pDocInfo=%p): stub\n", hPrinter, Level, pDocInfo); + return FALSE; +} + +/***************************************************************************** + * StartPagePrinter [WINSPOOL.@] + */ +BOOL WINAPI StartPagePrinter(HANDLE hPrinter) +{ + FIXME("(hPrinter=%p): stub\n", hPrinter); + return FALSE; +} + +/***************************************************************************** * GetFormA [WINSPOOL.@] */ BOOL WINAPI GetFormA(HANDLE hPrinter, LPSTR pFormName, DWORD Level, Index: dlls/winspool/winspool.drv.spec =================================================================== RCS file: /var/cvs/wine/dlls/winspool/winspool.drv.spec,v retrieving revision 1.16 diff -u -r1.16 winspool.drv.spec --- dlls/winspool/winspool.drv.spec 4 Nov 2002 23:53:42 -0000 1.16 +++ dlls/winspool/winspool.drv.spec 17 Dec 2002 06:01:17 -0000 @@ -56,8 +56,8 @@ @ stdcall DocumentPropertiesA(long long ptr ptr ptr long) DocumentPropertiesA @ stdcall DocumentPropertiesW(long long ptr ptr ptr long) DocumentPropertiesW @ stub EXTDEVICEMODE -@ stub EndDocPrinter -@ stub EndPagePrinter +@ stdcall EndDocPrinter(long) EndDocPrinter +@ stdcall EndPagePrinter(long) EndPagePrinter @ stub EnumFormsA @ stub EnumFormsW @ stdcall EnumJobsA(long long long long ptr long ptr ptr) EnumJobsA @@ -127,8 +127,8 @@ @ stub SpoolerInit @ stub StartDocDlgA @ stub StartDocDlgW -@ stub StartDocPrinterA -@ stub StartDocPrinterW -@ stub StartPagePrinter +@ stdcall StartDocPrinterA(long long ptr) StartDocPrinterA +@ stdcall StartDocPrinterW(long long ptr) StartDocPrinterW +@ stdcall StartPagePrinter(long) StartPagePrinter @ stub WaitForPrinterChange @ stdcall WritePrinter(long ptr long ptr) WritePrinter -- Dimi.

Dec. 17, 2002

Re: wrc options

by Dimitrie O. Paun

On December 9, 2002 04:57 pm, Francois Gouget wrote: > I agree with that one. As it is wrc just convert the filenames to > lowercase before trying to include them which is just plain wrong. In > particular it causes compilation errors if the file really has a > mized-case which is not that uncommon. ChangeLog Remove the -L wrc option, as no automatic fudging of filenames can ever be correct. Index: tools/wrc/parser.y =================================================================== RCS file: /var/cvs/wine/tools/wrc/parser.y,v retrieving revision 1.33 diff -u -r1.33 parser.y --- tools/wrc/parser.y 15 Aug 2002 21:57:36 -0000 1.33 +++ tools/wrc/parser.y 17 Dec 2002 05:33:45 -0000 @@ -2694,11 +2694,6 @@ *cptr = '/'; } - /* Convert to lower case. Seems to be reasonable to do */ - for(cptr = str->str.cstr; !leave_case && *cptr; cptr++) - { - *cptr = tolower(*cptr); - } return str; } Index: tools/wrc/wrc.c =================================================================== RCS file: /var/cvs/wine/tools/wrc/wrc.c,v retrieving revision 1.21 diff -u -r1.21 wrc.c --- tools/wrc/wrc.c 12 Dec 2002 22:23:55 -0000 1.21 +++ tools/wrc/wrc.c 17 Dec 2002 05:32:44 -0000 @@ -104,7 +104,6 @@ " -I path Set include search dir to path (multiple -I allowed)\n" " -J Do not search the standard include path\n" " -l lan Set default language to lan (default is neutral {0, 0})\n" - " -L Leave case of embedded filenames as is\n" " -m Do not remap numerical resource IDs\n" " -n Do not generate .s file\n" " -N Do not preprocess input\n" @@ -252,12 +251,6 @@ int auto_register = 0; /* - * Set when the case of embedded filenames should not be converted - * to lower case (-L option) - */ -int leave_case = 0; - -/* * The output byte-order of resources (set with -B) */ int byteorder = WRC_BO_NATIVE; @@ -433,9 +426,6 @@ error("Language %04x is not supported",lan); currentlanguage = new_language(PRIMARYLANGID(lan), SUBLANGID(lan)); } - break; - case 'L': - leave_case = 1; break; case 'm': remap = 0; Index: tools/wrc/wrc.h =================================================================== RCS file: /var/cvs/wine/tools/wrc/wrc.h,v retrieving revision 1.24 diff -u -r1.24 wrc.h --- tools/wrc/wrc.h 31 May 2002 23:41:01 -0000 1.24 +++ tools/wrc/wrc.h 17 Dec 2002 05:32:50 -0000 @@ -64,7 +64,6 @@ extern DWORD codepage; extern int pedantic; extern int auto_register; -extern int leave_case; extern int byteorder; extern int preprocess_only; extern int no_preprocess; -- Dimi.

Dec. 17, 2002

Re: Serious problem with / and mount points

by Sylvain Petreolle

--- Tony Lambregts <tony_lambregts(a)telusplanet.net> a écrit : > Jeff Smith wrote: > > > What I have so far: > > in files/dos_fs.c:1343, drive is receiving the value -1. > > at line 1358, this is blindly added to 'A'. As you may > > know, in ASCII, 'A' - 1 = '@'. The problem is that we don't check the status of DRIVE_FindDriveRoot, as you spotted it. The sources clearly states that -1 is error. > > > > The next step is to determine why DRIVE_FindDriveRoot is > > returning -1. > > Well the reason DRIVE_FindDriveRoot is returning -1 is that > DOSDrives[drive].ino does not equal st.st_ino anymore. Line 440 of > drive.c is as follows > > if ((DOSDrives[drive].dev == st.st_dev) && > (DOSDrives[drive].ino == st.st_ino)) > > > > > > > > > > BTW, the same occurred in the reverse situation: > > (konsole) mount /mnt/cdrom > > (konsole) wcmd > > (wcmd) D: > > (wcmd) dir > > (konsole) umount /mnt/cdrom > > (wcmd) dir > > Now I am at @> > > If I remount and dir again, I am back to D> > > > Same problem with floppys too. > > -- > > Tony Lambregts > > > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Dec. 17, 2002

Re: linking between wine books

by Tony Lambregts

Bill Medland wrote: >What to people think? Should we be linking between different books in the >wine-doc set? > >I had put a link from wine-user to a section in wine-devel. The pdf was happy >enough with it but the sgm-to-html choked on it. Easiest solution is to drop >the link. Otherwise can someone point me at an example where it works? > > > Linking between books at a local level only works <easily> if you are building as a set. If you are building just one book then AFAIK there is no way to tell it about an id in another book. (One way around it is to point to the tag point in the winehq documentation). If anyone knows different please speak up. -- Tony Lambregts

Dec. 17, 2002

Re: include msvcrt/ fix (take 2)

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > What about this one? Currently {ming,wine}wrap are badly broken. > > I hope this one is rather uncontroversial, but it does depend on > that bit from crtdll, and I think that is the problem. I'd prefer that we simply get rid of these includes. This avoids having to do hacks in crtdll that will need to be removed later anyway. -- Alexandre Julliard julliard(a)winehq.com

Dec. 17, 2002

Re: include msvcrt/ fix (take 2)

by Dimitrie O. Paun

On December 14, 2002 02:10 pm, Dimitrie O. Paun wrote: > ChangeLog > Do not explicitly include msvcrt files from msvcrt headers. > Include windef.h instead of winnt.h to get all appropriate types. Alexandre, What about this one? Currently {ming,wine}wrap are badly broken. I hope this one is rather uncontroversial, but it does depend on that bit from crtdll, and I think that is the problem. -- Dimi.

Dec. 17, 2002

Re: How long does it take *you* to build wine?

by Tony Lambregts

Bill Medland wrote: >On December 15, 2002 10:51 pm, Dan Kegel wrote: >snip > > >>So how long does it take *you* to do a clean build >>(just the 'make' part after 'make depend', say) of >>Wine-20021125? >>- Dan >> >> > >(I was wondering if mine was the slowest!) >real - 47m0.357 >user-43m1.631 >sys-2m51.668 > >Celeron 450 with 128MB running RedHat 7.3 > >snip > > No yours is fast compared to my <blush> 300mhz pentium with 96mb of ram (around 3 hours) </blush> -- Tony Lambregts

Dec. 17, 2002

Re: stub handling

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > printing.o: In function `printer_start_job': > printing.o(.text+0x1fa): undefined reference to `EndDocPrinter' > printing.o(.text+0x20a): undefined reference to `EndPagePrinter' > printing.o(.text+0x237): undefined reference to `StartDocPrinterA' > printing.o(.text+0x24a): undefined reference to `StartPagePrinter' > printing.o: In function `printer_finish_job': > printing.o(.text+0x2b6): undefined reference to `EndPagePrinter' > printing.o(.text+0x2bd): undefined reference to `EndDocPrinter' > collect2: ld returned 1 exit status > > How shall we proceed? We need to implement them, importing stubs no longer works (but of course you can do a stub implementation instead ;-) -- Alexandre Julliard julliard(a)winehq.com

Dec. 17, 2002

Re: regression - 'wine notepad.exe' now has fixme

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > >>>>> "Dan" == Dan Kegel <dkegel(a)ixiacom.com> writes: > > Dan> With today's cvs, I see fixme:win:SetWindowTextA cannot set text > Dan> "Notepad - (untitled)" of other process window (nil) when I run > Dan> notepad.exe. This also happens with wine20021125, but not with > Dan> wine20020904. > > SetWindowText can not yet set the text across process boundary. But more > functions do the right thing and use SetWindowText and not a workaround or > don't use it at all. So this is not a regression. Actually the window is (nil) so this is not an inter-process issue at all; the error message is a bit misleading in that case. And if it didn't happen before then it's clearly a regression. -- Alexandre Julliard julliard(a)winehq.com

Dec. 17, 2002

Re: How long does it take *you* to build wine?

by Bill Medland

On December 15, 2002 10:51 pm, Dan Kegel wrote: snip > So how long does it take *you* to do a clean build > (just the 'make' part after 'make depend', say) of > Wine-20021125? > - Dan (I was wondering if mine was the slowest!) real - 47m0.357 user-43m1.631 sys-2m51.668 Celeron 450 with 128MB running RedHat 7.3 snip -- Bill Medland

Dec. 17, 2002

Re: [RESENT (20021013)]RelayExclude/Include

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Changelog: > relay32/relay386.c: check_relay_include > Treat whole dlls as advertised IMO the current behavior is correct. If the documentation says otherwise it needs to be fixed. -- Alexandre Julliard julliard(a)winehq.com

Dec. 16, 2002

Re: How long does it take *you* to build wine?

by Joerg Mayer

On Sun, Dec 15, 2002 at 10:51:59PM -0800, Dan Kegel wrote: > So how long does it take *you* to do a clean build > (just the 'make' part after 'make depend', say) of > Wine-20021125? current cvs on an athlon 550 with 192 M Ram and gcc 3.2: real 47m40.902s user 40m25.200s sys 3m1.410s Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Dec. 16, 2002

linking between wine books

by Bill Medland

What to people think? Should we be linking between different books in the wine-doc set? I had put a link from wine-user to a section in wine-devel. The pdf was happy enough with it but the sgm-to-html choked on it. Easiest solution is to drop the link. Otherwise can someone point me at an example where it works? -- Bill Medland

Dec. 16, 2002

Re: winmm test extension

by Francois Gouget

On Mon, 16 Dec 2002, Paul Millar wrote: [...] > In the future, there might be many interactive tests: or at least, ones > that require someone to sit in front of the computer. These could all be > turned off by default, but could be turned on through an option to > runtest, or via an environment variable (WINETEST_INTERACTIVE). > > Does this sound reasonable? Sounds reasonable to me. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

Dec. 16, 2002

Re: fdopen behaviour correction

by Uwe Bonnes

>>>>> "Bill" == Bill Currie <bill(a)taniwha.org> writes: Bill> fdopen is not supposed to rewind the file descriptor being given a Bill> FILE *. Proof of this comes from quakeforge working in windows Bill> natively but not in wine without the attatched patch. Bill> ChangeLog * dlls/msvcrt/file.c don't rewind the file after Bill> creating the FILE* handle It is good to have a test case for such cases in wine/dlls/msvcrt/tests. 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. 16, 2002

Re: winmm test extension

by Paul Millar

On Mon, 16 Dec 2002, Francois Gouget wrote: > How to make it play a sound? > Simple. Just pass the 'play' parameter to the test. Playing a sound is a nice idea, but perhaps there's a more general way of choosing to hear it. In the future, there might be many interactive tests: or at least, ones that require someone to sit in front of the computer. These could all be turned off by default, but could be turned on through an option to runtest, or via an environment variable (WINETEST_INTERACTIVE). Does this sound reasonable? (no pun intended ;) ---- Paul Millar

Dec. 16, 2002

stub handling

by Dimitrie O. Paun

Alexandre, In the past functions that were declared stubs in the .spec file got a dummy definition, so programs using them could link. This doesn't seem to be the case anymore: mingwrap -mwindows -mno-cygwin -s -o putty.exe be_all.o cmdline.o ldisc.o \ ldiscucs.o logging.o misc.o noise.o pageantc.o portfwd.o \ printing.o proxy.o raw.o rlogin.o settings.o sizetip.o ssh.o \ sshaes.o sshblowf.o sshbn.o sshcrc.o sshcrcda.o sshdes.o \ sshdh.o sshdss.o sshmd5.o sshpubk.o sshrand.o sshrsa.o \ sshsh512.o sshsha.o sshzlib.o telnet.o terminal.o tree234.o \ unicode.o version.o wcwidth.o wildcard.o win_res.res.o \ winctrls.o windlg.o window.o winnet.o winstore.o winutils.o \ x11fwd.o -ladvapi32 -lcomctl32 -lcomdlg32 -lgdi32 -limm32 \ -lshell32 -luser32 -lwinmm -lwinspool -lwsock32 printing.o: In function `printer_start_job': printing.o(.text+0x1fa): undefined reference to `EndDocPrinter' printing.o(.text+0x20a): undefined reference to `EndPagePrinter' printing.o(.text+0x237): undefined reference to `StartDocPrinterA' printing.o(.text+0x24a): undefined reference to `StartPagePrinter' printing.o: In function `printer_finish_job': printing.o(.text+0x2b6): undefined reference to `EndPagePrinter' printing.o(.text+0x2bd): undefined reference to `EndDocPrinter' collect2: ld returned 1 exit status How shall we proceed? -- Dimi.

Dec. 16, 2002

Re: resend: ConvertThreadToFiber stub

by Rein Klazes

On Mon, 16 Dec 2002 13:47:10 -0600, you wrote: > On Monday 16 December 2002 01:08 pm, Rein Klazes wrote: > > Use this one, the previous patch wasn't clean > > > > > > Changelog: > > > > dlls/kernel : kernel32.spec > > scheduler : thread.c > > > > Add a stub for ConvertThreadToFiber > > > > Rein. > > funny, I recently implemented same but never submitted. using HTML Help > by any chance? Yes, so I can use the the MSDN library help files. Rein. -- Rein Klazes rklazes(a)xs4all.nl

Dec. 16, 2002

Re: resend: ConvertThreadToFiber stub

by Greg Turner

On Monday 16 December 2002 01:08 pm, Rein Klazes wrote: > Use this one, the previous patch wasn't clean > > > Changelog: > > dlls/kernel : kernel32.spec > scheduler : thread.c > > Add a stub for ConvertThreadToFiber > > Rein. funny, I recently implemented same but never submitted. using HTML Help by any chance? -- gmt

Dec. 16, 2002

Re: winmm test extension

by Francois Gouget

Hi Dan, Dan Kegel wrote: [...] > I may have a counterexample. The patch I submitted recently was > to fix a hang in playing sound. So if you add a timeout to > your test, it would at least verify that sounds played in > the proper amount of time, and didn't hang wine. Yes, there are a number of failure modes that could be tested automatically. Wine could crash for instance... What I could do is modify the test to play silence by default, and only play an actual tone if the user asks for it. I should also document the goals of playing a tone a bit more in the test itself. Maybe printing a trace telling the user how to play a tone could be nice (otherwise it's hard for someone running the test to know that the test has options). The message could look something like: winmm.c: Playing silence, use 'tone' option for an actual tone The idea of timing the sound and verifying that it does not play in less time than it's supposed to could work too. I'm a bit worried by that but I guess all that can happen is that we will overestimate the time it took to play the tone, not underestimate it. Well, if nobody objects I can add all that to the test once it's committed. -- Francois Gouget fgouget(a)codeweavers.com

Dec. 16, 2002

Re: winmm test extension

by Dan Kegel

Francois Gouget wrote: > This test extends the winmm test and makes it possible to play actual > sound. Of course the test will not do that unless you specifically ask > for it: > * I doubt anyone would be happy to do 'make test' in Wine's main > directory and to get annoying long beeps comming out of their computer > * tests are usually run unattended and there is not much point playing > the sounds if no-one listens to them to make sure they got played > correctly. > > So what does it do? > For each supported format it plays the international 'LA', i.e. a 440Hz > sinusoid. It is expected that on some sound cards and for some formats > the signal will have to be converted from 8 to 16 bit or from mono to > stereo, or even resampled. Normally this should not affect the sound > being played so you should keep hearing the same tone. If that's not the > case then something went wrong during th I may have a counterexample. The patch I submitted recently was to fix a hang in playing sound. So if you add a timeout to your test, it would at least verify that sounds played in the proper amount of time, and didn't hang wine. - Dan

Dec. 16, 2002

Re: DrawCaptionTempW patch

by Rein Klazes

On Mon, 16 Dec 2002 19:45:51 +0100, you wrote: > >>>>> "Rein" == Rein Klazes <rklazes(a)xs4all.nl> writes: > > Rein> Hi, This bug caused uninitialised height and width data to be fed > Rein> to the font rasterizer, allocating more then 1.2 GB of VM. > > What action or program triggered that bug? TheBat! email program. It has stopped working for some time, perhaps two months. Rein. -- Rein Klazes rklazes(a)xs4all.nl

Dec. 16, 2002

Re: DrawCaptionTempW patch

by Uwe Bonnes

>>>>> "Rein" == Rein Klazes <rklazes(a)xs4all.nl> writes: Rein> Hi, This bug caused uninitialised height and width data to be fed Rein> to the font rasterizer, allocating more then 1.2 GB of VM. What action or program triggered that bug? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Dec. 16, 2002

Re: windows visual view ?

by Francois Gouget

On Mon, 16 Dec 2002, Tom Wickline wrote: > Is was just wondering if there was any type of Windows visaul view ? > view as in how evreything is layed out ? and how wine compares to Win32 ? > Say if you had a visual view of how win32 is layed out and just how > close wine comes to this . Would this be more or less what you are looking for? * Windows Architecture http://www.lugod.org/presentations/crossover/Diapositive5.html * Wine Architecture http://www.lugod.org/presentations/crossover/Diapositive6.html * API stats (the 'diff' part) http://fgouget.free.fr/wine/winapi_stats-en.shtml -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

Dec. 16, 2002

It now hangs when running an install shield

by Ben Clewett

Wine, You gues have already given me loada help, but straight onto my next stage, and I get (my old friend) the Wine Console error traceback. Running an Install Shield instalation, starts OK, gets past the initial 'Install Shield will now guide you through your instalation'. Then blanks the screen for about ten minutes, returning with the console showing: Unhandles exception: page fault on write access to E:\_ITSTMP.DIR\_INS55765._WP): movl %eax,0x28(%edx,%ecx,4) Looked in /tmp/winetmp-root/_ITSTMP.DIR/* & can't see anything wrong. 'df' shows a few dozen gig free. And clues? I hope at the end of this, I can return the great feedback by answering some questions my self :) Ben

Dec. 16, 2002

Workaround for Wine to produce dead-keys with Brazilian ABNT-2 keyboards

by Mauro Carvalho Chehab

I spent a lot of time looking for a solution for using my Brasilian ABNT-2 keyboard. I've already sent a new patch to wine-patches in order to correct keytables and vkey tables. But it remained a small problem: It was NOT generating the correct dead-key codes. So, I developed a *workaround*. This patch has to be applyied to dlls/x11drv/keyboard.c (It was tested with CVS 20021125). I advice that it wil work only for ABNT-2 keyboards. ---------------------------------------------------------------------------------------------------------------------------------------- --- keyboard.c 2002-11-28 22:33:07.000000000 -0200 +++ keyboard.c 2002-12-16 15:10:07.000000000 -0200 @@ -1759,6 +1794,10 @@ else TRACE("Found keycode %d (0x%2X)\n",e.keycode,e.keycode); ret = XLookupString(&e, (LPVOID)lpChar, 2, &keysym, NULL); + +/* Gambiarra para funcionarem os acentos em teclado ABNT-2 */ +if ((e.keycode==48)||(e.keycode==34)||((e.keycode==15)&&(e.state & ShiftMask))) ret=0; + wine_tsx11_unlock(); if (ret == 0)

Dec. 16, 2002

Re: How long does it take *you* to build wine?

by Drew Ogle

On Sun, 15 Dec 2002, Dan Kegel wrote: > I got tired of waiting for wine to build, and started looking > for ways to speed it up. > > Wine-20021125? > - Dan Well, with a dual 1800+ MP system ( cvs from 20021216 ) takes real 6m49.808s user 12m0.330s done with make -j2 > > p.s. > No fair using ccache! That's the next tool I want to investigate; > it's probably the biggest win of all, at least for regression > testing. > >

Dec. 16, 2002

Re: Wine, Windows.Forms on Linux, GC and segfaults.

by Marcus Meissner

On Wed, Dec 11, 2002 at 01:05:32PM -0500, Miguel de Icaza wrote: > Hello, > > > > The problem is that by the time that Wine has been initialized, > > > using setjmp/longjmp will always lead to a crash. The code > > > in pthreads > > > that performs the longjmp will first try to invoke the pthread cleanup > > > routines, and then invoke longjmp. This never happens. > > > > You can't and needn't link with -lpthread. Wine has its own > > pthread implmentation. > > > > I tried your included code and it works just fine unless you > > link with -lpthread, then it crashes in the same way as in your > > attached picture. But then you should never link Wine with > > -lpthread so that is not really a bug. > > > > Of course Wine pthread implementation it not in any way complete > > so some function might be missing and some might only be only > > partially implemented and of course some might be incorrectly > > implemented. > > > > So please try again without linking with -lpthread. > > The problem is that this is very hard for us to do as two of the > underlying libraries we are using (libmono and libgc) both link against > pthread to achieve their threading capabilities. > > It might be better to investigate what are Wine's requirements for > having its own pthread implementation, and have those changed pushed to > the maintainers of pthreads. > > In particular, we are interested in using WineLib, maybe it would be > possible to have WineLib use the standard pthread implementation instead > of rolling its own? This would be very difficult. WINE implements the Win32 threading/process and synchronisation model. It needs to use the OS native threads so it gets the stack maintenance and the correct handling of the %fs. So WINE cannot change to pthreads without major hacks to the pthread library I guess. Ciao, Marcus

Dec. 16, 2002

windows visual view ?

by Tom Wickline

Is was just wondering if there was any type of Windows visaul view ? view as in how evreything is layed out ? and how wine compares to Win32 ? Say if you had a visual view of how win32 is layed out and just how close wine comes to this . If there was a negitive of Win-ME for example and one of wine how would wine look if it was layed on top of the Win-ME negitive ? I am trying to view Win32 in my head and wine and how they ( scope ) up..... could this cause a brain hemorrhage ?? ......... :) comments , flames , views, insight most welcome Tom

Dec. 16, 2002

Quick silly question, registering DLL's

by Ben Clewett

Forgive any stupidness implied, I am UNIX not MS! How does one check whether a DLL is registered, and how does one actually register a DLL in wine? Thanks,

Dec. 16, 2002

Re: VarOr / oleaut32

by us＠the-edmeades.demon.co.uk

> It's a VB6 application of our own description. I have not had a chance > to hack the source code to see where it comes into play, but probably > something to do with a third party DLL we use for remote database > connectivity. There's a significant number of Var* routines not implemented. I implemented the missing ones for a VB6 app I had written, but each app executes different ones, so there's still quite a few missing. If you try the patch already submitted, see if you get further and potentially hit other missing functions. Most of the missing fn's are not too bad to implement, so keep reporting them Jason

Dec. 16, 2002

Re: How long does it take *you* to build wine?

by Michael Stefaniuc

On Sun, Dec 15, 2002 at 10:51:59PM -0800, Dan Kegel wrote: > It does look like distributing the load helps a tiny > bit, but it's not clear it's a big win over just building > on the dual 650MHz machine. > The fastest build I've seen so far is 19 minutes. I'm pretty > sure I'm not doing things optimally yet. > > So how long does it take *you* to do a clean build > (just the 'make' part after 'make depend', say) of > Wine-20021125? On a athlon 900 with 512 MB RAM it takes about 30 minutes for a full build, but only for the first run. On the second run it takes about 3-4 minutes :). Ok, i'm using ccache and it realy paid out during my -DSTRICT work. The cache hit rate had varied between 30% and 80%, depending what i've done. You get 30% - 40% hitrate for normal updates from cvs without doing a "make clean". > No fair using ccache! That's the next tool I want to investigate; > it's probably the biggest win of all, at least for regression > testing. I've thought about buying a new computer before i started to use ccache. With ccache i'll wait for the Hammer. 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

Dec. 16, 2002

Re: VarOr / oleaut32

by Andreas Mohr

On Mon, Dec 16, 2002 at 09:20:18AM +0000, Ben Clewett wrote: > us(a)the-edmeades.demon.co.uk wrote: > >Hiya, > > > >What app shows this? Can I get hold of it - I should be able to knock > >something up for it as a test regardless, but it might not be til mid next > >week. > > > >Jason > > > > It's a VB6 application of our own description. I have not had a chance > to hack the source code to see where it comes into play, but probably > something to do with a third party DLL we use for remote database > connectivity. > > Thanks for the offer of a fix. > > I was hoping there was a generic fault, and somebody might have a > generic fix. Since it seems to be more indepth, I will try any get an > exact location of location of failure first. Even though I now implemented VarOr, I guess you might want to be careful about that and use a native oleaut32 instead, since oleaut32 contains tons of variant calculation functions (mul, add, and, xor, various conversions, div, round), so if there's *any* bug in there affecting some function your program uses, boom goes your data eventually. That's why I'd use native oleaut32 for production use. OTOH I'm still waiting for some builtin oleaut32 test reports ;) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

Dec. 16, 2002

Re: VarOr / oleaut32

by Ben Clewett

us(a)the-edmeades.demon.co.uk wrote: > Hiya, > > What app shows this? Can I get hold of it - I should be able to knock something up for it as a test regardless, but it might not be til mid next week. > > Jason > It's a VB6 application of our own description. I have not had a chance to hack the source code to see where it comes into play, but probably something to do with a third party DLL we use for remote database connectivity. Thanks for the offer of a fix. I was hoping there was a generic fault, and somebody might have a generic fix. Since it seems to be more indepth, I will try any get an exact location of location of failure first. Ben

Dec. 16, 2002

Re: How long does it take *you* to build wine?

by Martin Fuchs

Here are my timings for a 1.8 GHz P4: time ./configure real 0m55.767s user 0m15.590s sys 0m14.530s time make clean real 0m9.166s user 0m2.980s sys 0m2.270s time make real 16m55.724s user 11m47.180s sys 1m2.460s I wonder, if it's really necessary to change configure scripts and do a "configure/make clean all" that often as it's done right now. The good thing about it is, that it shows how well Linux' mutlitasking does work compared to Windows. You can just let it build it in the background and do other things meanwhile. ;-) -- Martin Fuchs martin-fuchs(a)gmx.net

Dec. 16, 2002

Re: How long does it take *you* to build wine?

by Dan Kegel

Dan Kegel wrote: > So how long does it take *you* to do a clean build > (just the 'make' part after 'make depend', say) of > Wine-20021125? OK, got some numbers building 20021125 on my home machines: 30min : 750MHz PIII laptop 17min 21sec: dual 650MHz PIII, 7200RPM disks, make -j2 16min 1sec: distcc on the dual 650MHz as localhost, 750MHz laptop, and a 1.1GHz celeron, make -j4 And on another machine not at home: 8 min : dual 1.2GHz P4 Xeon, make -j2 So the fastest build I've seen so far (not including configure or make depend) is about 8 minutes. distcc seems to help a tiny bit. it's kind of looking like I should get a faster motherboard if I want sub-ten-minute builds. Next step should be to measure benefit of using ccache when searching through cvs for the patch that broke something, but I'll probably just go out and get a faster motherboard. I want one with gigabit ethernet onboard; pricewatch says $320 for an Asus A7V8X with "2400" Athlon XP, $353 for an Asus P4PE with 2.4GHz P4. Hmm. I bet either one of those would get me Wine builds below ten minutes... Does anyone have a good recipe for building an inexpensive machine that can build Wine quickly? - Dan

Dec. 16, 2002

How long does it take *you* to build wine?

by Dan Kegel

I got tired of waiting for wine to build, and started looking for ways to speed it up. I have three systems handy: a dual 650MHz PIII, a 750MHz PIII laptop, and a 1.1 GHz Celeron with shared memory video (i.e. dog slow). To see if a parallel compile would help, I installed Red Hat 8.0 on all systems, and installed the RPM for distcc from http://distcc.samba.org. I then timed how long it took to do a 'make' after 'make clean' in a recent copy of the wine tree. It does look like distributing the load helps a tiny bit, but it's not clear it's a big win over just building on the dual 650MHz machine. The fastest build I've seen so far is 19 minutes. I'm pretty sure I'm not doing things optimally yet. So how long does it take *you* to do a clean build (just the 'make' part after 'make depend', say) of Wine-20021125? - Dan p.s. No fair using ccache! That's the next tool I want to investigate; it's probably the biggest win of all, at least for regression testing.

Dec. 16, 2002

Re: regression - 'wine notepad.exe' now has fixme

by Uwe Bonnes

>>>>> "Dan" == Dan Kegel <dkegel(a)ixiacom.com> writes: Dan> With today's cvs, I see fixme:win:SetWindowTextA cannot set text Dan> "Notepad - (untitled)" of other process window (nil) when I run Dan> notepad.exe. This also happens with wine20021125, but not with Dan> wine20020904. SetWindowText can not yet set the text across process boundary. But more functions do the right thing and use SetWindowText and not a workaround or don't use it at all. So this is not a regression. 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. 15, 2002

GetWindowTextLengthA()/WM_GETTEXTLENGTH issue

by Andreas Mohr

Hi all, Steuertipps PC 2003 (yeah, right, it's that time of the year again ;) has corrupted button text - drawing beyond the last actual string character. This is because the supplied OWL (Borland, I believe ?) DLL calls DrawTextA with twice the amount of string length (yeah, must be a Unicode issue, of course... :), thus forcing DrawTextA into drawing way too much. (side note: OWL seems to implement its own custom buttons) This doubled value comes from GetWindowTextLengthA() (0x14 bytes instead of 0x0e bytes), which thus comes from WM_GETTEXTLENGTH. WINPROC_UnmapMsg32ATo32W does for a WM_GETTEXTLENGTH unmapping: case WM_GETTEXTLENGTH: case CB_GETLBTEXTLEN: case LB_GETTEXTLEN: /* there may be one DBCS char for each Unicode char */ return result * 2; The button text in question is: L"&Schlie\00dfen" (aka "&Schliessen") (so it's a Unicode string with 0x0e units) MSDN says that both WM_GETTEXTLENGTH and GetWindowTextLength return inexact amounts of string lengths for certain Unicode/DBCS combos (and always at least as much as the minimum storage it requires). However, I guess that we really *shouldn't* double the string length in this case (I guess we better avoid that corruption ;). Hmm, any idea how the unmapping can be improved ? To me it seems that the generic unmapping in WINPROC_UnmapMsg32ATo32W is exactly the place where s^Hcrap happens. (there seems to be a pretty direct connection between GetWindowTextLengthA and DrawTextA) Andreas Mohr

Dec. 15, 2002

Re: docu patch

by Dimitrie O. Paun

On December 15, 2002 07:25 am, Andreas Mohr wrote: > - comment out mapping to home drive in default config and add > a comment on why we don't include it This renders Wine useless for all but the most trivial of tasks. But maybe playing winmine is good enough ... :) If we want to be really secure, we should recommend that the user removes the floppy drive, and _all_ network cards, as there are virii that are known to use such mediums... :))) -- Dimi.

Dec. 15, 2002

SHELL32.DLL.ILFindLastID segfault

by Dimitrie O. Paun

If you run the winGTK installer (wingtk-0.2.exe, available from http://wingtk.sourceforge.net/) and click on the "Browse" button to select the installation directory, you get: [dimi(a)dimi wine.src]$ wine ~/dev/wine/wingtk-0.2.exe fixme:shell:BrsFolderDlgProc flags 1 not implemented wine: Unhandled exception, starting debugger... fixme:console:SetConsoleCtrlHandler (0x4057e554,1) - no error checking or testing yet And the backtrace is: Wine-dbg>bt Backtrace: =>0 0x40a0707a (SHELL32.DLL.ILFindLastID+0x3e in shell32.dll.so) (ebp=40761750) 1 0x40a0884e (SHELL32.DLL.SHGetPathFromIDListW+0x1be in shell32.dll.so) (ebp=40761774) 2 0x40a0b0bf (SHELL32.DLL.SHGetFileInfoA+0x2e7 in shell32.dll.so) (ebp=40761c9c) 3 0x40a0b745 (SHELL32.DLL.SHGetFileInfoW+0x8d in shell32.dll.so) (ebp=40761e28) 4 0x409fec9f (SHELL32.DLL.SHGetFreeDiskSpace+0x213f in shell32.dll.so) (ebp=40762108) 5 0x409fecde (SHELL32.DLL.SHGetFreeDiskSpace+0x217e in shell32.dll.so) (ebp=40762124) 6 0x409fef9a (SHELL32.DLL.SHGetFreeDiskSpace+0x243a in shell32.dll.so) (ebp=407623dc) 7 0x409fec2d (SHELL32.DLL.SHGetFreeDiskSpace+0x20cd in shell32.dll.so) (ebp=40762400) 8 0x409ff35e (SHELL32.DLL.SHGetFreeDiskSpace+0x27fe in shell32.dll.so) (ebp=4076241c) 9 0x4089d13f (USER32.DLL.GetTaskmanWindow+0xbb in user32.dll.so) (ebp=40762440) 10 0x4089d19d (USER32.DLL.GetTaskmanWindow+0x119 in user32.dll.so) (ebp=4076246c) 11 0x408a210a (USER32.DLL.CallWindowProcW+0xda in user32.dll.so) (ebp=407624a0) 12 0x40879ed8 (USER32.DLL.DefDlgProcW+0x44 in user32.dll.so) (ebp=407624cc) 13 0x4089d13f (USER32.DLL.GetTaskmanWindow+0xbb in user32.dll.so) (ebp=407624f0) 14 0x4089d19d (USER32.DLL.GetTaskmanWindow+0x119 in user32.dll.so) (ebp=4076251c) 15 0x408a19dd (USER32.DLL.GetTaskmanWindow+0x4959 in user32.dll.so) (ebp=40762544) 16 0x408a1ffe (USER32.DLL.CallWindowProcA+0xda in user32.dll.so) (ebp=40762578) 17 0x408b20d4 (USER32.DLL.IsCharAlphaW+0x2b90 in user32.dll.so) (ebp=407625d4) 18 0x408b2d9e (USER32.DLL.SendMessageTimeoutA+0x1ba in user32.dll.so) (ebp=4076263c) 19 0x408b2e25 (USER32.DLL.SendMessageA+0x31 in user32.dll.so) (ebp=40762668) 20 0x4087d005 (USER32.DLL.DefWindowProcW+0x1885 in user32.dll.so) (ebp=407626f8) 21 0x4087d87c (USER32.DLL.DialogBoxParamW+0x44 in user32.dll.so) (ebp=40762728) 22 0x409ff691 (SHELL32.DLL.SHBrowseForFolder+0xd1 in shell32.dll.so) (ebp=40762770) 23 0x00405575 (wingtk-0.2.exe.EntryPoint+0x1017 in F:\dev\wine\wingtk-0.2.exe) (ebp=407629c0) 24 0x4089d13f (USER32.DLL.GetTaskmanWindow+0xbb in user32.dll.so) (ebp=407629e4) 25 0x4089d19d (USER32.DLL.GetTaskmanWindow+0x119 in user32.dll.so) (ebp=40762a10) 26 0x408a1ade (USER32.DLL.GetTaskmanWindow+0x4a5a in user32.dll.so) (ebp=40762a38) 27 0x408a2129 (USER32.DLL.CallWindowProcW+0xf9 in user32.dll.so) (ebp=40762a6c) 28 0x40879ed8 (USER32.DLL.DefDlgProcW+0x44 in user32.dll.so) (ebp=40762a98) 29 0x4089d13f (USER32.DLL.GetTaskmanWindow+0xbb in user32.dll.so) (ebp=40762abc) 30 0x4089d19d (USER32.DLL.GetTaskmanWindow+0x119 in user32.dll.so) (ebp=40762ae8) 31 0x408a210a (USER32.DLL.CallWindowProcW+0xda in user32.dll.so) (ebp=40762b1c) 32 0x408b2073 (USER32.DLL.IsCharAlphaW+0x2b2f in user32.dll.so) (ebp=40762b78) 33 0x408b2bc9 (USER32.DLL.SendMessageTimeoutW+0x135 in user32.dll.so) (ebp=40762bdc) 34 0x408b2de9 (USER32.DLL.SendMessageW+0x31 in user32.dll.so) (ebp=40762c08) 35 0x40850e65 (USER32.DLL.UnregisterDeviceNotification+0xc8d1 in user32.dll.so) (ebp=40762ce0) 36 0x40851269 (USER32.DLL.UnregisterDeviceNotification+0xccd5 in user32.dll.so) (ebp=40762d04) 37 0x4089d13f (USER32.DLL.GetTaskmanWindow+0xbb in user32.dll.so) (ebp=40762d28) 38 0x4089d19d (USER32.DLL.GetTaskmanWindow+0x119 in user32.dll.so) (ebp=40762d54) 39 0x408a210a (USER32.DLL.CallWindowProcW+0xda in user32.dll.so) (ebp=40762d88) 40 0x40886a56 (USER32.DLL.DispatchMessageW+0x96 in user32.dll.so) (ebp=40762dcc) 41 0x4087de12 (USER32.DLL.IsDialogMessageW+0x96 in user32.dll.so) (ebp=40762de4) 42 0x4087d6a1 (USER32.DLL.CreateDialogIndirectParamW+0xe1 in user32.dll.so) (ebp=40762e28) 43 0x4087d826 (USER32.DLL.DialogBoxParamA+0x52 in user32.dll.so) (ebp=40762e44) 44 0x00404cef (wingtk-0.2.exe.EntryPoint+0x791 in F:\dev\wine\wingtk-0.2.exe) (ebp=00420160) 45 0x74676e69 (SHLWAPI.DLL..reloc+0x3a5de69) (ebp=775c3a63) Wine-dbg> -- Dimi.

Dec. 15, 2002

Re: crtdll revisited

by Dimitrie O. Paun

On December 13, 2002 02:32 am, Dimitrie O. Paun wrote: > The msvcrt/ removal patch allows for a simpler fix to > the crtdll problem. > > I don't include a ChangeLog because if you like this one, > you should commit it together with the msvcrt/ removal patch, > as it's part of the same logical unit of work. While this works OK, it does break 'make depend' so... -- Dimi.

Dec. 15, 2002