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. 18, 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. 18, 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. 17, 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. 17, 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. 17, 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. 17, 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. 17, 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. 17, 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. 17, 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. 17, 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