Re: mingw32 port and cygwin
"Steven Edwards" <[EMAIL PROTECTED]> writes: > I'm having a bitch of a time with configure on mingw. I understand not > wanting to #ifdef OSNAME in the wine source tree and how this would be a > pain if a project forked. Would you be opposed to a #ifdef statement for > mingw? Not necessarily, if there are compiler differences an #ifdef may be appropriate, we have some for gcc too. In other cases there could be better alternatives. Why don't you post your problems on this list so that people can suggest solutions? -- Alexandre Julliard [EMAIL PROTECTED]
mingw32 port and cygwin
I'm having a bitch of a time with configure on mingw. I understand not wanting to #ifdef OSNAME in the wine source tree and how this would be a pain if a project forked. Would you be opposed to a #ifdef statement for mingw? Thanks Steven _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: New to wine
Patrik Stridvall <[EMAIL PROTECTED]> writes: > Hmm. That reminds me. I experimented with this some year ago but I > have no distinct memory of asking Alexandre whether he wanted a > patch that does this for Wine. Then I forgot about it. > > Alexandre: > Will you accept a patch that does this? I don't think that's necessary anymore. (WINAPI *func) should work fine in gcc too. -- Alexandre Julliard [EMAIL PROTECTED]
Problems building wrc on mingw
bison -y -v -d -t ./parser.y conflicts: 2 shift/reduce gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -o y.tab.o y.tab.c gcc: y.tab.c: No such file or directory gcc: No input files make: *** [y.tab.o] Error 1 I've got the -v option going but I can't get a debug output form bison to figure out whats going wrong. Anyone got any ideas? Thanks Steven _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Fix for MoveFileExA
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Wednesday 30 January 2002 21:41 schrieb Uwe Bonnes: > > "Francois" == Francois Gouget <[EMAIL PROTECTED]> writes: > > Francois> On Wed, 30 Jan 2002, Gerhard W. Gruber wrote: > ... > Francois>I believe that Windows stores the list of files to > Francois> move/delete somewhere in the registry. We should probably do > Francois> the same... It seems that adding keys in the registry would > be Francois> better than creating new files in any case. > > At least Win95 and decendants store the file in /wininit.ini. Yes, because registry access isn't available yet when wininit.ini is handled during booting. That's what happens during the "Configuration files are being updated" ... "Done" (roughly translated from German, guess you know what I mean) while the boot logo is displayed. BTW, no idea why they call it "configuration files" :) Imagine kernel32, advapi or something else is being replaced...can't use the registry for it. The format of wininit.ini is pretty simple: ever line is like newname=oldname and causes the file named oldname to be renamed to newname. If newname is nul, the file is deleted. - -- Malte Starostik PGP: 1024D/D2F3C787 [C138 2121 FAF3 410A 1C2A 27CD 5431 7745 D2F3 C787] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8WJWMVDF3RdLzx4cRApncAKCFLIv32C+97uaTRq4UfXpFYFBASQCfezGw R80SYovvkyrywtu94xj+PnU= =NmRY -END PGP SIGNATURE-
Re: Pajama Sam's unmanaged window
On Mon, 28 Jan 2002, Ori Pessach wrote: > - Changed is_window_managed()'s default return value to TRUE Perhaps remove the cruft this leaves behind, then. > - In tooltips.c, TOOLTIPS_NCCreate(), I set the WS_EX_TOOLWINDOW bit in the > tooltip's dwExStyle field. This, I believe, is the right thing to do > regardless of WM considerations, since MSDN specifies that tooltip windows > have that bit set. > >(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/CommCtls/ToolTip/Styles.asp) Then I suggest you submit this piece of the patch to wine-patches independently of the rest of this. > - In menu.c, I replaced CreateWindowA() with CreateWindowExA(), passing > WS_EX_TOOLWINDOW as the first parameter. I'm not so sure about this one. I > don't know whether Windows does this (Win16 surely doesn't), and if it > doesn't, it might break apps that examine those bits. Since this is probably not the case, perhaps it's better to check for the popup menu class in is_window_managed(), something like if (GetClassLongA(win->hwndSelf, GCW_ATOM) == POPUPMENU_CLASS_ATOM) return FALSE; > With these changes, Pajama Sam works correctly, except for the KDE panel > problem. I'm currently looking at that issue.
Re: Fix for MoveFileExA
On Wed, 30 Jan 2002 10:21:57 -0800 (PST), Francois Gouget <[EMAIL PROTECTED]> wrote: > Only Alexandre has commit access to the CVS. To submit code for >inclusion in Wine you should post a 'diff -u' patch to >'[EMAIL PROTECTED]'. There everyone will be able to review it and >Alexandre will apply it if he thinks it's ok. The Wine Developpers Guide >has slightly more detailed instructions: > > http://wine.codeweavers.com/docs/wine-devel/patches.shtml Thanks for the link. I would have thought it a bit weird anyway if anybody would have write access to such a big project. :) > You can also post your patch to wine-devel if you want help. There we >can all discuss what 'the right fix' is :-) Basically it is just the question if there is a file where global names or variables are collected. I don't know if such a thing exists, but I think it has to because I guess that certain parameters like the command line switches have to be available almost anywhere. > I believe that Windows stores the list of files to move/delete >somewhere in the registry. We should probably do the same... It seems >that adding keys in the registry would be better than creating new files >in any case. OK. I take a look at how windows handles this. Of course it is a better way to do it the way, windows handles it to be as compatible to the original as possible. Actually I would have preferred to start with a different function, but then I thought this functions is nice and easy to start working on wine. :) It's a bit complex. :) -- Bye, Gerhard If you think education is expensive, try ignorance.
Re: Current CVS doesn't compile
On Wed, 30 Jan 2002, Bernhard Rosenkraenzer wrote: > dlls/Makefile.in refers to msvcrt20, but the directory doesn't exist. > Guess someone forgot a "cvs add". Alternatively, someone forgot "cvs update -PAd"
Re: Current CVS doesn't compile
On Wed, 30 Jan 2002, Bernhard Rosenkraenzer wrote: > dlls/Makefile.in refers to msvcrt20, but the directory doesn't exist. > Guess someone forgot a "cvs add". Msvcrt20 does exist and is not even empty. Either you did your update at the wrong instant, you need the '-A' option, or something went wrong during the update. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS
Current CVS doesn't compile
dlls/Makefile.in refers to msvcrt20, but the directory doesn't exist. Guess someone forgot a "cvs add". LLaP bero -- This message is provided to you under the terms outlined at http://www.bero.org/terms.html
Re: Fix for MoveFileExA
> "Francois" == Francois Gouget <[EMAIL PROTECTED]> writes: Francois> On Wed, 30 Jan 2002, Gerhard W. Gruber wrote: ... Francois>I believe that Windows stores the list of files to Francois> move/delete somewhere in the registry. We should probably do Francois> the same... It seems that adding keys in the registry would be Francois> better than creating new files in any case. At least Win95 and decendants store the file in /wininit.ini. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: CreateProcess API - undocumented use
> "Ricardo" == Ricardo <[EMAIL PROTECTED]> writes: Ricardo> hi, I have a program that use the CreateProcess API with Ricardo> dwFileAttribute as a parameter. But not to use in the command Ricardo> line. It's used to write some data into a file and then another Ricardo> program read that file. But this isn't working. I'm not a Ricardo> programmer, I'm just testing the program. Does anybody know how Ricardo> can the program be changed, or wine patched, to solve this? Ricardo> thanks, Ricardo Run with debugmsg and show us what you think is going on. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
CreateProcess API - undocumented use
hi, I have a program that use the CreateProcess API with dwFileAttribute as a parameter. But not to use in the command line. It's used to write some data into a file and then another program read that file. But this isn't working. I'm not a programmer, I'm just testing the program. Does anybody know how can the program be changed, or wine patched, to solve this? thanks, Ricardo
Re: Fix for MoveFileExA
On Wed, 30 Jan 2002, Gerhard W. Gruber wrote: > Also I don't want to submit it right now because my current fix is a bit ugly. > The fix is applied for files that should be moved or deleted when windows > boots after an application is installed. Currently there was a message telling > the user that he has to delete/rename the specified files. Now I added some > code that writes an entry in (WINECONFIG)/bootmove and (WINECONFIG)/bootdel > when these functions are called. I also added some code in loader/main.c that > checks if these files exists and if they do it will open them and > deletes/renames the specified files. I hope this solution is acceptable. :) > The only ugly thing about this is that the filenames for bootmove and bootdel > are curerntly hardcoded where I need them. I don't know if there is a global > space somewhere where I can add some fixed names so I did it this way for now, > but this is not the best way in case the names should be changed or something > and also I don't like hardecoded names. > > Another drawback of this approach is that it would be possible that more than > one process is writing or reading at the same time there could be potential > problems, so I'd like to hear some opinions if this is ok. Windows stores this information in c:\windows\wininit.ini, and several installers access this file directly. Using Get/SetPrivateProfileString should make accessing the file better protected from simultaneous access. Format of wininit.ini: [rename] c:\newfilename=c:\oldfilename nul=c:\filetodelete I think Andreas Mohr may already have done some work on this though?
Re: Fix for MoveFileExA
On Wed, 30 Jan 2002, Gerhard W. Gruber wrote: > I just wrote a fix for a fixme located in MoveFileExA. Since this is the first > time I'm writing something for wine I wanted to ask how I shall proceed now. > Shall I simply add it into the CVS or does it have to go somewhere for > revision? Only Alexandre has commit access to the CVS. To submit code for inclusion in Wine you should post a 'diff -u' patch to '[EMAIL PROTECTED]'. There everyone will be able to review it and Alexandre will apply it if he thinks it's ok. The Wine Developpers Guide has slightly more detailed instructions: http://wine.codeweavers.com/docs/wine-devel/patches.shtml > Also I don't want to submit it right now because my current fix is a bit ugly. You can also post your patch to wine-devel if you want help. There we can all discuss what 'the right fix' is :-) > The fix is applied for files that should be moved or deleted when windows > boots after an application is installed. Currently there was a message telling > the user that he has to delete/rename the specified files. Now I added some > code that writes an entry in (WINECONFIG)/bootmove and (WINECONFIG)/bootdel > when these functions are called. I also added some code in loader/main.c that > checks if these files exists and if they do it will open them and > deletes/renames the specified files. I hope this solution is acceptable. :) I believe that Windows stores the list of files to move/delete somewhere in the registry. We should probably do the same... It seems that adding keys in the registry would be better than creating new files in any case. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.
Fix for MoveFileExA
I just wrote a fix for a fixme located in MoveFileExA. Since this is the first time I'm writing something for wine I wanted to ask how I shall proceed now. Shall I simply add it into the CVS or does it have to go somewhere for revision? Also I don't want to submit it right now because my current fix is a bit ugly. The fix is applied for files that should be moved or deleted when windows boots after an application is installed. Currently there was a message telling the user that he has to delete/rename the specified files. Now I added some code that writes an entry in (WINECONFIG)/bootmove and (WINECONFIG)/bootdel when these functions are called. I also added some code in loader/main.c that checks if these files exists and if they do it will open them and deletes/renames the specified files. I hope this solution is acceptable. :) The only ugly thing about this is that the filenames for bootmove and bootdel are curerntly hardcoded where I need them. I don't know if there is a global space somewhere where I can add some fixed names so I did it this way for now, but this is not the best way in case the names should be changed or something and also I don't like hardecoded names. Another drawback of this approach is that it would be possible that more than one process is writing or reading at the same time there could be potential problems, so I'd like to hear some opinions if this is ok. -- Bye, Gerhard If you think education is expensive, try ignorance.
Re: err:ntdll:RtlpWaitForCriticalSection section 0xXXXXXXX "?" wait timed out, retrying (60sec) fs = XXXX
HI, I submitted it a while ago, but it was never committed for some reason. This patch is probably just a band-aid to a larger problem... Dave Hawkes - Original Message - From: "Sylvain Petreolle" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, January 30, 2002 10:34 AM Subject: Re: err:ntdll:RtlpWaitForCriticalSection section 0xXXX "?" wait timed out, retrying (60sec) fs = > Hi, > > that helps a lot ! programs run faster and faster now. > thanks. > > If this has no unwanted effects with other programs, > could this be commited ? this gives really a speed > improvement. > > --- Dave Hawkes <[EMAIL PROTECTED]> a écrit : > > > I have attached a patch which makes some of my > > applications start TEN times > > quicker (so no timeout message), you may want to > > recompile wine with this > > patch and see if it helps. > > > > Dave Hawkes > > > > > ___ > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > Yahoo! Mail : http://fr.mail.yahoo.fr > > >
Re: err:ntdll:RtlpWaitForCriticalSection section 0xXXXXXXX "?" wait timed out, retrying (60sec) fs = XXXX
Hi, that helps a lot ! programs run faster and faster now. thanks. If this has no unwanted effects with other programs, could this be commited ? this gives really a speed improvement. --- Dave Hawkes <[EMAIL PROTECTED]> a écrit : > > I have attached a patch which makes some of my > applications start TEN times > quicker (so no timeout message), you may want to > recompile wine with this > patch and see if it helps. > > Dave Hawkes > ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.fr
Re: err:ntdll:RtlpWaitForCriticalSection section 0xXXXXXXX "?" wait timed out, retrying (60sec) fs = XXXX
I'll try this this afternoon. I must say i had this message even with a application that only used ONE window (okay, was a big program...) Thanks for the information. --- Dave Hawkes <[EMAIL PROTECTED]> a écrit : > This can happen with some large applications that > have a lot of windows when > they initially start. It takes a LOT longer to > complete the initial redraw > under wine than windows and this can cause the > message to occur. However it > will not cause an error as the CriticalSection will > wait a further 5 minutes > before really timing out. > > I have attached a patch which makes some of my > applications start TEN times > quicker (so no timeout message), you may want to > recompile wine with this > patch and see if it helps. > > Dave Hawkes > > - Original Message - > From: "Sylvain Petreolle" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Wednesday, January 30, 2002 2:55 AM > Subject: err:ntdll:RtlpWaitForCriticalSection > section 0xXXX "?" wait > timed out, retrying (60sec) fs = > > > > Hi, > > > > Like many users now, > > I have this message when I launch some programs : > > > > err:ntdll:RtlpWaitForCriticalSection section > 0xXXX > > "?" wait timed out, retrying (60sec) fs = > > > > To clear the situtation : What does this message > means > > and what could be done to make it disappear ? > > > > Some users have made post with these and have got > no response... > > > > > ___ > > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite > et en français ! > > Yahoo! Mail : http://fr.mail.yahoo.fr > > > > > > > > ATTACHMENT part 2 application/octet-stream name=paint.diff ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.fr
Re: err:ntdll:RtlpWaitForCriticalSection section 0xXXXXXXX "?" wait timed out, retrying (60sec) fs = XXXX
This can happen with some large applications that have a lot of windows when they initially start. It takes a LOT longer to complete the initial redraw under wine than windows and this can cause the message to occur. However it will not cause an error as the CriticalSection will wait a further 5 minutes before really timing out. I have attached a patch which makes some of my applications start TEN times quicker (so no timeout message), you may want to recompile wine with this patch and see if it helps. Dave Hawkes - Original Message - From: "Sylvain Petreolle" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, January 30, 2002 2:55 AM Subject: err:ntdll:RtlpWaitForCriticalSection section 0xXXX "?" wait timed out, retrying (60sec) fs = > Hi, > > Like many users now, > I have this message when I launch some programs : > > err:ntdll:RtlpWaitForCriticalSection section 0xXXX > "?" wait timed out, retrying (60sec) fs = > > To clear the situtation : What does this message means > and what could be done to make it disappear ? > > Some users have made post with these and have got no response... > > ___ > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > Yahoo! Mail : http://fr.mail.yahoo.fr > > > paint.diff Description: Binary data
Re: New to wine
--- Rolf Kalbermatter <[EMAIL PROTECTED]> wrote: > I tried to > use the Visual C 5 compiler > on my windows system to compile the shell32 dll and > found some problems > with that. There is gcc compiler for Windows (see Cygwin and MinGW projects). I myself use Cygwin to compile Wine tests on Windows. However, never tried to compile parts of Wine. Andriy Palamarchuk __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com
Re: Prob with freetype...
On Tue, Jan 29, 2002 at 09:26:34PM +, Meths wrote: > Didn't see anyone mention this so... > > When compiling CVS tonight... > > gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 > -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT > -I/usr/X11R6/include -o freetype.o freetype.c > freetype.c: In function `WineEngGetGlyphOutline': > freetype.c:947: `FT_Angle' undeclared (first use in this function) > freetype.c:947: (Each undeclared identifier is reported only once > freetype.c:947: for each function it appears in.) > freetype.c:947: parse error before `angle' > freetype.c:993: `angle' undeclared (first use in this function) > freetype.c:1003: warning: implicit declaration of function > `FT_Vector_Rotate' > freetype.c:1059: warning: implicit declaration of function `FT_Cos' > freetype.c:1060: warning: implicit declaration of function `FT_Sin' > make[2]: *** [freetype.o] Error 1 > make[2]: Leaving directory `/root/cvs_root/wine/dlls/gdi' > make[1]: *** [gdi/libgdi32.so] Error 2 > make[1]: Leaving directory `/root/cvs_root/wine/dlls' > make: *** [dlls] Error 2 Upgrade your freetype to 2.0.3 . bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg07290/pgp0.pgp Description: PGP signature
RE: New to wine
> All wine headers seem to declare function pointers like > > WINAPI (*) > > Visual C 5 does not like the WINAPI (eg __stdcall) outside of > the brackets and requires: > > (WINAPI *)() [snip] > Maybe there is someone on this list which can give me an > direct answer to this. If you want to compile with Visual C++ you will have to do something like below. #ifdef __GNUC__ #define WINAPI_PTR * WINAPI #else #define WINAPI_PTR WINAPI * #endif And replace all WINAPI function with: (WINAPI_PTR )() Hmm. That reminds me. I experimented with this some year ago but I have no distinct memory of asking Alexandre whether he wanted a patch that does this for Wine. Then I forgot about it. Alexandre: Will you accept a patch that does this?
New to wine
Hello I happened to find wine when researching some undocumented stuff in shell32.dll for my own shell extensions I had written. It was interesting to see how things may be done in windows. I also identified some parts in the wine shell32 which need more attention and plan to submit some patches concerning that after I have familiarized myself a little more with wine. Since I had no Linux system at my hands I tried to use the Visual C 5 compiler on my windows system to compile the shell32 dll and found some problems with that. Separate from some wine specific project definitions which need to be made for Visual C to process the wine headers Iand which I probably haven't done all properly) there was one problem with function pointer definitions. All wine headers seem to declare function pointers like WINAPI (*) Visual C 5 does not like the WINAPI (eg __stdcall) outside of the brackets and requires: (WINAPI *)() I could also not find any comprehensible ANSI C description which would care to explain what would be the correct way of function pointer declarations with a calling convention identifier. I tried to figure out how this could be solved. Declaring WINAPI to be empty and telling Visual C to use __stdcall as default gives other problems with internal wine functions without explicit calling convention declaration and with a variable argument list, which requires __cdecl. The only way I could find was to adjust the function pointer definitions in the affected headers. Of course this goes quite far and might cause problems with other compilers. As I will soon have a new development machine on which I will install Linux alongside of Windows I can fairly easily check if this would cause problems with gcc, but wine seems to care for more compilers than that and I have no idea if such a change would cause problems (it probably would anyhow :-| ). Maybe there is someone on this list which can give me an direct answer to this. Rolf Kalbermatter
