August 2004 - Wine-Devel - list.winehq.org

Re: Ignore WS_MINIMIZE and WS_MAXIMIZE in SetWindowLong

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > According to this URL a number of WS_ flags cannot be changed after > the window is created (using SetWindowLong): > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinU… > This patch uses that information and ignores just the WS_MINIMIZE and > WS_MAXIMIZE styles in SetWindowLong. That MSDN page implies that pretty much all styles can't be modified, which is definitely not true. I must say I would be surprised if WS_MAXIMIZE and WS_MINIMIZE were handled differently from the rest. Could you please provide a test case? -- Alexandre Julliard julliard(a)winehq.org

Aug. 24, 2004

Re: CreateRemoteThread and related stuff (patch)

by Alexander Yaworsky

Hello > There is no need to export __wine_is_current_process from ntdll and use > it here when standard win32 apis will suffice. > Well, not quite. You can open another handle to the process using > DuplicateHandle or something else, so you need to go via the server. The > simplest way to do this using Win32 is: > if (GetProcessId(handle) == GetCurrentProcessId()) You miss. It seems we really need __wine_is_current_process. > >+ if( ! WriteProcessMemory( hProcess, &info, &local_info, > > > This looks wrong. &info? Don't you mean just info? Yes! Thanks. > >+ if ((process = get_process_from_handle( req->handle, > >+ PROCESS_CREATE_THREAD > >+ | PROCESS_QUERY_INFORMATION > >+ | PROCESS_VM_OPERATION > >+ | PROCESS_VM_READ | PROCESS_VM_WRITE ))) > > > > > I would argue that it is perfectly alright for the access rights to be > just PROCESS_QUERY_INFORMATION here. Maybe. But with the full set of access rights CreateRemoteThread will return earlier in case of error. > Is it really necessary to perform the action required for remote > invocation of some operation asynchronously? It seems to add a lot of > unneeded complexity. What shall we do with csVirtual critical section in ntdll/virtual.c?

Aug. 24, 2004

Re: A new regression

by Alexandre Julliard

"Ivan Leo Puoti" <puoti(a)inwind.it> writes: >> (with screenshots, if possible). > before the patch > http://www003.portalis.it/115/download/1.png > and after it > http://www003.portalis.it/115/download/2.png The problem is that the app uses OpenGL for painting, and OpenGL doesn't support the IncludeInferiors clipping mode. Fixing that properly will require getting rid of X windows for child windows, but in the meantime I have added a workaround that should work in most cases. -- Alexandre Julliard julliard(a)winehq.org

Aug. 24, 2004

Re: A new regression

by Ivan Leo Puoti

> (with screenshots, if possible). before the patch http://www003.portalis.it/115/download/1.png and after it http://www003.portalis.it/115/download/2.png The app is a free download. Ivan.

Aug. 23, 2004

Re: Compile on AMD Opetron

by Marcus Meissner

On Mon, Aug 23, 2004 at 09:41:55AM -0500, Chuck Hall wrote: > > Hi Chuck, > > > > --- chall(a)bcrl.stcloudstate.edu wrote: > >> If you need access to a AMD Opetron box I can setup remote access > >> (via > >> SSH) so you can test the code, or I can try the patches (if any) > >> sent. > > > > I have quite a few patches for native Opertron x86-64 support on my > > account at sourceforge but I doubt you want a 64bit wine as it wont let > > you run any normal Windows apps. Try passing -m32 to gcc to see if it > > clears up. > > > > Thanks > > Steven > > > > While you are right about not wanting 64bit wine, it still does not solve > the problem of the interlocked function missing. I still get the same > problem of the function not existing. > > I did try setting the build and the host variable to i686 in configure. > When I get to the make part it states that the asm is not a valid 64 bit > base/index expression. > > Would you mind adding a link to your website so I can try the patches? Use: export LD="ld -m elf_i386" CC="gcc -m32" AS="gcc -c -m32" ./configure --prefix=/usr --x-libraries=/usr/X11R6/lib make depend all to build on amd64. Ciao, Marcus

Aug. 23, 2004

Re: DbgHelp: Fix for Includes with Relative Paths

by Eric Pouech

which means that: - we create a new compilation unit (for example) on 2205 => this gives the source directory - we start the main compilation unit on 2206 => /home/dm/wine/dlls/dbghelp/elf_module.c - in this CU, we start a new include file (on xxxx), => /home/dm/wine/dlls/dbghelp/../../include/winbase.h - ... - we close the CU on 4978 Basically, as I wrote, you don't need two different beasts: currpath and srcpath. They refer to the same object, but the code is wrong. We should: - store the current directory on first SO (or the SO ended by a '/', which would be better) - on a non NULL SO, not ended by a '/' create a new compilation unit by concatening curr dir and the file name (or if file name is absolute, use the filename) - for each SOL, get the file name by concatening the curr dir with the file name (this operation is the same as above). - nuke the curr dir when getting a NULL SO current code is wrong as it creates two compilands for each compilation unit (one for each non NULL SO) A+

Aug. 23, 2004

Re: DbgHelp: Fix for Includes with Relative Paths

by Robert Shearman

Eric Pouech wrote: > Robert Shearman a écrit : > >> Hi, >> >> On startup, the debugger usually prompted me to type the path where >> "/winternl.h" can be found. This was due to the path being stored >> internally as "../../include/winternl.h", i.e. relative to the source >> directory. This patch adds the ability to store the source directory >> and then use it when encountering an include path of this type to get >> the full path, which means no more prompting. >> >> Rob >> >> Changelog: >> Store the current source directory and use it when encountering a >> relative include so that the full path to it is stored instead. >> > Robert, normally currpath is supposed to be the directory where the > file has been compiled. So, IMO currpath and srcpath duplicate the > same stuff. > > Does it mean that you only get one N_SO per compilation unit ? (the > code assumes two: the first one for the dir, the second for the path). [dm(a)rob dm]$ objdump -G /usr/local/lib/wine/dbghelp.dll.so | grep " SO " | more 0 SO 0 0 00015d9c 11 /home/dm/wine/dlls/dbghelp/ 1 SO 0 0 00015d9c 1 dbghelp.c 2204 SO 0 0 000163b9 0 2205 SO 0 0 000163bc 11 /home/dm/wine/dlls/dbghelp/ 2206 SO 0 0 000163bc 166272 elf_module.c 4978 SO 0 0 00017c24 0 4979 SO 0 0 00017c24 11 /home/dm/wine/dlls/dbghelp/ 4980 SO 0 0 00017c24 346388 image.c 6782 SO 0 0 00017cf6 0 ... The real problem is the N_SOL entries, which is what the patch fixes: [dm(a)rob dm]$ objdump -G /usr/local/lib/wine/dbghelp.dll.so | grep " SOL " | more 1917 SOL 0 0 00015ddf 35504 ../../include/winbase.h 1934 SOL 0 0 00015dec 1 dbghelp.c 1941 SOL 0 0 00015e16 35504 ../../include/winbase.h 1946 SOL 0 0 00015e56 1 dbghelp.c 2013 SOL 0 0 00015fc6 35504 ../../include/winbase.h 2016 SOL 0 0 00015fda 1 dbghelp.c 2020 SOL 0 0 00015ff1 35504 ../../include/winbase.h 2023 SOL 0 0 00016020 1 dbghelp.c ... Rob

Aug. 23, 2004

Re: DbgHelp: Fix for Includes with Relative Paths

by Eric Pouech

Robert Shearman a écrit : > Hi, > > On startup, the debugger usually prompted me to type the path where > "/winternl.h" can be found. This was due to the path being stored > internally as "../../include/winternl.h", i.e. relative to the source > directory. This patch adds the ability to store the source directory and > then use it when encountering an include path of this type to get the > full path, which means no more prompting. > > Rob > > Changelog: > Store the current source directory and use it when encountering a > relative include so that the full path to it is stored instead. > Robert, normally currpath is supposed to be the directory where the file has been compiled. So, IMO currpath and srcpath duplicate the same stuff. Does it mean that you only get one N_SO per compilation unit ? (the code assumes two: the first one for the dir, the second for the path). A+

Aug. 23, 2004

Re: Compiling Wine on Windows

by Steven Edwards

Hi Todd, --- "Todd S." <sias.programming(a)suessweb.com> wrote: > My name is Todd, and I am trying to compile the Wine DLLs within a > Windows XP DOS-Box. I am using MingW with a newer version of Make, > GCC, G++, etc. I type "make" within the directory and all that is > returned is: "make: *** No targets specified and no makefile found. > Stop.". > > Do I need a different version of "Make" or do I just need something > else? You need MSYS from the mingw project so you can run ./configure I think you may also need the MSYS-DTK for bison and flex. Thanks Steven _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush

Aug. 23, 2004

Compiling Wine on Windows

by Todd S.

Dear wine-devel Forum, My name is Todd, and I am trying to compile the Wine DLLs within a Windows XP DOS-Box. I am using MingW with a newer version of Make, GCC, G++, etc. I type "make" within the directory and all that is returned is: "make: *** No targets specified and no makefile found. Stop.". Do I need a different version of "Make" or do I just need something else? Thanks, Todd Suess

Aug. 23, 2004