wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

Re: [Bug 751] Changed - GetDiskFreeSpace should return >2GB on some systems
by Andreas Mohr 31 May '02

31 May '02

Hi all, could you have a look at bug #751 and check the values on your Windows version and add a comment to the bug on what your version does ? (please don't forget to only check for partitions > 2GB !!) Thanks ! On Thu, May 30, 2002 at 11:19:14PM -0500, wine-bugs(a)winehq.com wrote: > http://bugs.winehq.com/show_bug.cgi?id=751 > > *** shadow/751 Thu May 30 23:18:08 2002 > --- shadow/751.tmp.27844 Thu May 30 23:19:14 2002 > *************** > *** 25,27 **** > --- 25,31 ---- > the selected emulated version, or always return the actual free size. > > I'll attach a small program to obtain the return values from GetDiskFreeSpaceA. > + > + ------- Additional Comments From vberon(a)mecano.gme.usherb.ca 2002-05-30 23:19 ------- > + Created an attachment (id=150) > + Test program to obtain the return values of GetDiskFreeSpaceA -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

2 1

Re: PATCH: libntddl.so not found
by Alexandre Julliard 31 May '02

31 May '02

Marcus Meissner <marcus(a)jet.franken.de> writes: > This adds a helpful messages for the users who do > ./configure > make > make install > and do not have /usr/local/lib in their ld.so.conf. I think this should be in the top-level Makefile to avoid having it scroll off the screen. Also it would be nice to check LD_LIBRARY_PATH to avoid needlessly scaring users who have a working config already. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: PATCH: libntddl.so not found
by Dustin Navea 31 May '02

31 May '02

Hmmm, I found some problems with this: +print NEWMAKE <<EOF; shouldn't that be printf ? + \@if test -f /etc/ld.so.conf -a -z "`grep \$(libdir) /etc/ld.so.conf`" ; \\ shouldn't that be \$(LIBDIR) + echo " Add the line '\$(libdir)' to /etc/ld.so.conf" ; \\ I think that escaping the $ in this line is unnecessary as it this prints "$(libdir)" instead of the contents of that variable, and also libdir should be capitalized there too... + echo " export LD_LIBRARY_PATH=\$(libdir):\$LD_LIBRARY_PATH" ; \\ Same as above except that it doesn't apply to \$LD_LIBRARY_PATH as we want "$LD_LIBRARY_PATH" to be printed... -Dustin __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

2 2

Re: Idea for people with priveleges
by Dustin Navea 31 May '02

31 May '02

--- Andriy Palamarchuk <apa3a(a)yahoo.com> wrote: > > --- Dustin Navea <speeddymon(a)yahoo.com> wrote: > > Well, AFAIK, there isn't reall a QA team, and if > > there > > is, they aren't checking out the bugs, because > > several > > bugs marked as resolved for over a year weren't > > closed > > until I went in and closed them.... > > Agree, we can simplify the things for now - skip > VERIFIED and RESOLVED steps in most cases - just > close > the bugs. > We can change the process later. > > Andriy > That is why I started this thread, we cant "just close the bugs" we have to resolve them first... We need 3 more options, probably would be easiest to implement in BugZilla 2.11: Close as Unresolved More information needed from User More testing Needed __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

1 0

Problem with 64-bit file functions declarations
by Andriy Palamarchuk 31 May '02

31 May '02

I'm researching an issue when started regedit.exe fails to export registry. This started to happen after Alexandre's patch which included "config.h" in the regedit source file. I found out this problem was triggered by declaration #define _FILE_OFFSET_BITS 64 in config.h. The test case: ******************************************** /* Set this to 64 to enable 64-bit file support on Linux */ #define _FILE_OFFSET_BITS 64 #include <stdio.h> #include <windows.h> void test_write(void) { FILE *f = fopen("1.reg", "w"); printf("sizeof FILE: %d\n", sizeof(FILE)); fputs("DEBUG1\n", f); fclose(f); } int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { test_write(); exit(0); } ******************************************** Comment out the macro definition and it works, with macro it creates file of 0 length. With the defined macro many file functions are defined as functions for 64-bit access and are linked to the native platform calls instead of msvcrt ones. Differences in precompilation output: Without macro: # 203 "/usr/include/stdio.h" 3 extern FILE *fopen (__const char *__restrict __filename, __const char *__restrict __modes) ; With macro: # 211 "/usr/include/stdio.h" 3 extern FILE *fopen (__const char *__restrict __filename, __const char *__restrict __modes) __asm__ ("" "fopen64"); The same happens for some other file functions. What is the correct fix for this problem? Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

3 4

fwait bug
by admiral coeyman 31 May '02

31 May '02

Developers, From what I've been reading on the subject, the best way of handling int 3d is to return successful. Any fpu emmulation that we'll do should not require the fwait. The problem is that I cannot find enough information on the subject to know what the successful return conditions for this interrupt are. On a system that detects an FPU, self-modifying code is used. The interrupts that emmulate the FPU functions are rewritten in the executable to use the machine code for the real FPU instructions. I'm not sure if that can be done with the current memory scheme since that is outside of my area. God Bless, --Robert 'Admiral' Coeyman -- --- May you live as long as you wish and age but a single day. http://www.dotguy.net/ admiral(a)corner.net Webmaster/ Linux Administrator Computer Co-Op/CornerNet

1 0

Re: [Bug 377] Changed - mIRC crashes while backspacing to erase entry
by Tony Lambregts 31 May '02

31 May '02

Sam'l Bassett wrote: >With: > > codeweavers-wine-20011108-5 > >and > > mIRC 5.91 > > Yep -- still has the problem > >On Thursday 30 May 2002 12:35 pm, wine-bugs(a)winehq.com wrote: > > >>http://bugs.winehq.com/show_bug.cgi?id=377 >> >> >> Why do you not post in bugzilla the link was given . The reports come from the people looking at your bug report in bugzilla, where you reported it in the first place. Thats where you should respond. Tony Lambregts.

1 0

Re: PATCH: win32/device.c -- addresses two warnings
by Marcus Meissner 30 May '02

30 May '02

On Thu, May 30, 2002 at 09:26:56AM +0200, Gerald Pfeifer wrote: > This addresses two compiler warnings seen on FreeBSD 4.5-RELEASE. > The first should appear on any non GNU/Linux-system, the second on > all systems. > > Gerald > > ChangeLog: > Move floppy_params into #ifdef linux. > Fix printf format in OpenVxDHandle(). > > Index: device.c > =================================================================== > RCS file: /home/wine/wine/win32/device.c,v > retrieving revision 1.63 > diff -u -3 -p -r1.63 device.c > --- device.c 25 May 2002 22:04:43 -0000 1.63 > +++ device.c 30 May 2002 07:24:18 -0000 > @@ -1187,12 +1187,6 @@ static const DWORD VWIN32_DriveTypeInfo[ > 0x4f24 /* 2.88 M */ > }; > > -static BYTE floppy_params[2][13] = > -{ > - { 0xaf, 0x02, 0x25, 0x02, 0x12, 0x1b, 0xff, 0x6c, 0xf6, 0x0f, 0x08 }, > - { 0xaf, 0x02, 0x25, 0x02, 0x12, 0x1b, 0xff, 0x6c, 0xf6, 0x0f, 0x08 } > -}; > - > /********************************************************************** > * VWIN32_ReadFloppyParams > * > @@ -1201,6 +1195,12 @@ static BYTE floppy_params[2][13] = > static VOID VWIN32_ReadFloppyParams(DIOC_REGISTERS *regs) > { > #ifdef linux > + static BYTE floppy_params[2][13] = > + { > + { 0xaf, 0x02, 0x25, 0x02, 0x12, 0x1b, 0xff, 0x6c, 0xf6, 0x0f, 0x08 }, > + { 0xaf, 0x02, 0x25, 0x02, 0x12, 0x1b, 0xff, 0x6c, 0xf6, 0x0f, 0x08 } > + }; > + I think this is not recommended C (and might fail on other compilers). Not that linux would have any other but gcc. Ciao, Marcus

1 0

Re:Please how do I post the following and get help? "VT_STREAMED_OBJECT out of MSMQ"
by Hans 30 May '02

30 May '02

I was looking at some of your postings recently and I thought that maybe you have come across the situation where you have tried to send a VT_STREAMED_OBJECT into (OleSaveToStream) a queue body and tried to retrieve it at a later time (OleLoadFromStream). I am struggling to work with this (I hope that the code is self explanatory): pMsgProps->aPropID[iter] = PROPID_M_BODY_TYPE; pMsgProps->aPropVar[iter].vt = VT_UI4; pMsgProps->aPropVar[iter].ulVal = VT_STREAMED_OBJECT; iter++; pMsgProps->aPropID[iter] = PROPID_M_BODY; pMsgProps->aPropVar[iter].vt = VT_VECTOR|VT_UI1; STATSTG stat; hResult = ptrStream0->Stat(&stat,STATFLAG_NONAME); pMsgProps->aPropVar[iter].caub.cElems = stat.cbSize.LowPart; pMsgProps->aPropVar[iter].caub.pElems = (unsigned char *)static_cast<void *>(ptrStream0); The above part seems to go through fine. But I cannot extract the information from the receiving end: IStream* ptrStream0 = reinterpret_cast<IStream*>(pMsgProps->aPropVar[3].caub.pElems); // the subscript 3 is where the message body is being extracted, also memory has been allocated as UCHAR in the ..pElems hResult = ptrStream0->Stat(&stat,STATFLAG_NONAME); // the above line of code gives you garbage values for both STATMSG.cbSize.(HighPart and LowPart) Do you think that you could help? Thanks. Hans

1 0

Re: Patch to fix bug_report.pl
by Andreas Mohr 30 May '02

30 May '02

On Thu, May 30, 2002 at 09:47:07AM -0600, Tony Lambregts wrote: > The bug_report.pl script was broken by the removal of -managed command > line option This patch fixes it. That's all fine and dandy, but I think the real fix is to a) nuke bug_report.pl or b) improve it *a lot* bug_report.pl is so darn old that the Wine version it had originally been written for is *completely* different from what we're using today. Thus bug_report.pl should at least strip all "irrelevant" bug lines (*CriticalSection, Interlocked*crement, Tls*, ...). Furthermore it should really include many more debug lines (we're also tracing wine internal dlls now sometimes !). I'd suggest about 1500 lines of censored output, if not even more. Otherwise you can just kiss the debug log goodbye in about 98.5% of all cases. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

3 2

Debug information
by tijs＠connectux.com 30 May '02

30 May '02

Hi, I compiled a simple Hello World test using VC++ 6.0, with default settings. This generates a .PDB file, which is not read by the most recent winedbg. Perhaps this is due to an overly strict sanity check. In debugger/msc.c I found the following check if ( mpd_nth->Signature != IMAGE_NT_SIGNATURE || mpd_nth->FileHeader.NumberOfSections != nth->FileHeader.NumberOfSections || !(mpd_nth->FileHeader.Characteristics & IMAGE_FILE_DEBUG_STRIPPED )) goto leave; Now unfortunately, the characteristics for my file are 0x10e, and hence the IMAGE_FILE_DEBUG_STRIPPED flag is not set. Disabling the check solves this problem, but perhaps I should try to instruct VC++ to enable the bit? Trying the same with Visual Studio .NET is somewhat more cumbersome. I haven't been able to read in the debugging information generated by C++ projects using winedbg. Has anyone else tried this? Greetings, -- Tijs van Bakel, ConnecTUX, <tijs(a)connectux.com>

2 3

RE: Stripping of whitespaces at the end of lines
by Patrik Stridvall 30 May '02

30 May '02

> Alexandre Julliard a écrit : > > > > Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > > > > > If Alexandre wants to do it locally, I support him (our > mailboxes will > > > appreciate). > > > > If you want me to do that please send me a script that I can run > > across the tree to do the change. Please don't send patches for this > > kind of things. > > > > -- > > Alexandre Julliard > > julliard(a)winehq.com > > Here it is. It only targets .c and .h files. Looks good. <shameless-plug-for-perl> However the script can be written much shorter in Perl find . -name '*.[ch]' | xargs perl -i -pe 's/[ \t]+$//; s/;;+$/;/' </shameless-plug-for-perl> > The diff was ~4MB in size between before and after. The savings in a > .tar.gz of the whole tree were modest, around 25KB. I have read through the diff (rather quickly) and it seem to be OK. In fact I can't think of anything in the C semantics that can make a difference if trailing whitespace or extra semicolon is removed. > Now to find a good set of arguments to feed indent(1) so we > all use the > same coding style... > > Not! ;) Good luck finding something that everybody can agree upon. :-)

3 2

RE: Stripping of whitespaces at the end of lines
by Medland, Bill 30 May '02

30 May '02

> -----Original Message----- > From: Vincent Béron [mailto:vberon@mecano.gme.usherb.ca] > Sent: Tuesday, May 28, 2002 10:44 PM > To: wine-patches(a)winehq.org > Subject: Stripping of whitespaces at the end of lines > > > This is the first post in a series of posts about the same > subject. The > plan is to post the rest in the following days (as the total is >2MB > uncompressed, I don't want to send it all at once). Each patch will be > compressed (diff.gz) for that same reason. > > Alexandre, if you don't intend to apply it, please say so (along with > why), so I won't post some big patches for nothing. > > Changelog > - Strips whitespaces at the end of some C lines. > > Vincent I would have thought it would be safer simply for Alexandre to do the stripping locally rather than posting a whole load of patches. At the same time how about agreeing the size of a tab or removing them altogether or agreeing always to use tabs for progra, indentation or ....; Bill

11 19

Re: PATCH: ImageList_LoadImageW (comctl32)
by Tony Lambregts 30 May '02

30 May '02

Sander van Leeuwen wrote: >Changelog: >- Match behaviour of ImageList_LoadImageA wrt cx parameter (when set to zero) > >Author: Sander van Leeuwen/Odin (sandervl(a)xs4all.nl) > > >--- imagelist.c Wed May 29 17:31:28 2002 >+++ imagelist.co Wed May 29 17:32:38 2002 >@@ -1907,19 +1907,6 @@ > if (uType == IMAGE_BITMAP) { > BITMAP bmp; > GetObjectA (handle, sizeof(BITMAP), &bmp); >- >- /* To match windows behavior, if cx is set to zero and >- the flag DI_DEFAULTSIZE is specified, cx becomes the >- system metric value for icons. If the flag is not specified >- the function sets the size to the height of the bitmap */ >- if (cx == 0) >- { >- if (uFlags & DI_DEFAULTSIZE) >- cx = GetSystemMetrics (SM_CXICON); >- else >- cx = bmp.bmHeight; >- } >- > nImageCount = bmp.bmWidth / cx; > > himl = ImageList_Create (cx, bmp.bmHeight, ILC_MASK | ILC_COLOR, > > > > > > Seems to me that you got this patch backward. - should + Tony Lambregts

1 0

Re: SafeDisc-1 semi-cleaned note...
by Laurent Pinchart 29 May '02

29 May '02

> i hope i am not asking to much by this, but is there > any chance you could send me a copy of the diff's with > some fixme comments so I know exactly which things > need to be cleaned up? I know that you said the > server suspension code needs to be checked, and the > 0x7ffe0000 page needs to be properly implemented, but > im not sure what all would need to be changed to get > this done. Ok, here's a first version of safedisc.safe.diff with comments. I don't think it's usefull to comment safedisc.dmca.diff for now, but if you need some information about it let me know. --- memory/emulate.c Thu Jan 1 01:00:00 1970 +++ memory/emulate.c Thu May 9 17:35:27 2002 @@ -0,0 +1,53 @@ +/* + * Emulation of privileged memory + * + * Copyright 2002 Laurent Pinchart + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include "windef.h" +#include "wingdi.h" +#include "wine/winuser16.h" +#include "module.h" +#include "wine/debug.h" + +WINE_DEFAULT_DEBUG_CHANNEL(virtual); + +#ifdef __i386__ + +/*********************************************************************** + * MEMORY_SharedUserData + * + * Handles exceptions for the SharedUserData access. + */ +BOOL MEMORY_SharedUserData( LPVOID arg, LPCVOID addr ) +{ + DWORD dwProtection; + BOOL ret; + + TRACE( "MEMORY_SharedUserData\n" ); + + ret = VirtualProtect( (LPVOID)0x7ffe0000, 0x10000, PAGE_READWRITE, &dwProtection ); + if ( ret ) + { + *(LPDWORD)0x7ffe0000 = 0x12345678; + ret = VirtualProtect( (LPVOID)0x7ffe0000, 0x10000, PAGE_READONLY, &dwProtection ); + } + + return ret; +} + +#endif /* __i386__ */ This is the emulation of "SharedUserData". SharedUserData is a page of memory located right before the kernel space (0x80000000), so at address 0x7ffe0000. It contains miscelaneous information, and is read-only in user space and read-write in kernel space. You can find more information about it in ntddk.h (not included in wine). We need 3 things here: 1) Write support for the other fields, not only TickCount (kernel timer). This is optional but quite easy for some fields. 2) Find a way to either remove the read rights after the read access, so that the next read access would trigger an exception again, and the information could be updated (this is IMHO *very* difficult), or periodically update the information contained in that page (mostly TickCount). The later should be easier, but implies a slow down. If would be nice to trigger that periodical update only after the first read of TickCount, so that programs which don't read it wouldn't suffer from that slow down. We could also remove the read rights after some time (instead of right after the read operation). That might be the best way, as it wouldn't imply a slow down (not periodical update). 3) Replace 0x12345678 with a correct value. Don't forget that secdrv.c needs to know that value (or at least a close enough value), so we need a portable and accurate way to set and retrieve it from inside wine. Index: dlls/ntdll/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/ntdll/Makefile.in,v retrieving revision 1.27 diff -u -r1.27 Makefile.in --- dlls/ntdll/Makefile.in 14 May 2002 20:55:01 -0000 1.27 +++ dlls/ntdll/Makefile.in 23 May 2002 18:54:33 -0000 @@ -32,6 +32,7 @@ $(TOPOBJDIR)/loader/ne/segment.c \ $(TOPOBJDIR)/memory/atom.c \ $(TOPOBJDIR)/memory/codepage.c \ + $(TOPOBJDIR)/memory/emulate.c \ $(TOPOBJDIR)/memory/environ.c \ $(TOPOBJDIR)/memory/global.c \ $(TOPOBJDIR)/memory/heap.c \ When emulate.c will be applied this will be too :-) Index: dlls/ntdll/signal_i386.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/signal_i386.c,v retrieving revision 1.35 diff -u -r1.35 signal_i386.c --- dlls/ntdll/signal_i386.c 16 May 2002 20:32:16 -0000 1.35 +++ dlls/ntdll/signal_i386.c 23 May 2002 18:54:40 -0000 @@ -679,6 +679,7 @@ { EXCEPTION_RECORD rec; DWORD page_fault_code = EXCEPTION_ACCESS_VIOLATION; + DWORD priv_instr_code = EXCEPTION_PRIV_INSTRUCTION; #ifdef CR2_sig /* we want the page-fault case to be fast */ @@ -708,8 +709,8 @@ case T_SEGNPFLT: /* Segment not present exception */ case T_PROTFLT: /* General protection fault */ case T_UNKNOWN: /* Unknown fault code */ - if (INSTR_EmulateInstruction( context )) return; - rec.ExceptionCode = EXCEPTION_PRIV_INSTRUCTION; + if (INSTR_EmulateInstruction( context, &priv_instr_code )) return; + rec.ExceptionCode = priv_instr_code; break; case T_PAGEFLT: /* Page fault */ #ifdef CR2_sig Index: include/miscemu.h =================================================================== RCS file: /home/wine/wine/include/miscemu.h,v retrieving revision 1.46 diff -u -r1.46 miscemu.h --- include/miscemu.h 10 Mar 2002 00:02:34 -0000 1.46 +++ include/miscemu.h 23 May 2002 18:54:49 -0000 @@ -167,7 +167,7 @@ extern UINT DOSMEM_MapLinearToDos(LPVOID); /* linear Wine to DOS */ /* memory/instr.c */ -extern BOOL INSTR_EmulateInstruction( CONTEXT86 *context ); +extern BOOL INSTR_EmulateInstruction( CONTEXT86 *context, DWORD *exception_code ); /* msdos/interrupts.c */ typedef void (WINAPI *INTPROC)(CONTEXT86*); Index: memory/instr.c =================================================================== RCS file: /home/wine/wine/memory/instr.c,v retrieving revision 1.15 diff -u -r1.15 instr.c --- memory/instr.c 11 May 2002 23:01:12 -0000 1.15 +++ memory/instr.c 23 May 2002 18:54:58 -0000 @@ -396,7 +396,7 @@ * * Emulate a privileged instruction. Returns TRUE if emulation successful. */ -BOOL INSTR_EmulateInstruction( CONTEXT86 *context ) +BOOL INSTR_EmulateInstruction( CONTEXT86 *context, DWORD *exception_code ) { int prefix, segprefix, prefixlen, len, repX, long_op, long_addr; SEGPTR gpHandler; @@ -686,7 +686,9 @@ case 0xcd: /* int <XX> */ if (long_op) { - ERR("int xx from 32-bit code is not supported.\n"); + ERR("int 0x%02x from 32-bit code is not supported.\n", instr[1]); + if (instr[1] == 0x01) + *exception_code = EXCEPTION_ACCESS_VIOLATION; break; /* Unable to emulate it */ } else This probably hasn't been applied because it lacks testing. It seems that some instructions which are emulated by wine (int 0x01 is one of them) should generate an EXCEPTION_PRIV_INSTRUCTION instead of EXCEPTION_ACCESS_VIOLATION. Or maybe my code is not clean enough to commit. I'd like to hear comments from Alexandre about this specific part of the patch. Index: include/wine/server_protocol.h =================================================================== RCS file: /home/wine/wine/include/wine/server_protocol.h,v retrieving revision 1.35 diff -u -r1.35 server_protocol.h --- include/wine/server_protocol.h 25 Apr 2002 22:58:59 -0000 1.35 +++ include/wine/server_protocol.h 23 May 2002 18:54:56 -0000 @@ -296,6 +296,7 @@ struct init_process_done_reply { struct reply_header __header; + int suspended; int debugged; }; @@ -3198,6 +3199,6 @@ struct get_window_properties_reply get_window_properties_reply; }; -#define SERVER_PROTOCOL_VERSION 79 +#define SERVER_PROTOCOL_VERSION 80 #endif /* __WINE_WINE_SERVER_PROTOCOL_H */ Index: scheduler/process.c =================================================================== RCS file: /home/wine/wine/scheduler/process.c,v retrieving revision 1.182 diff -u -r1.182 process.c --- scheduler/process.c 22 May 2002 21:32:50 -0000 1.182 +++ scheduler/process.c 23 May 2002 18:55:04 -0000 @@ -25,6 +25,7 @@ #include <ctype.h> #include <errno.h> #include <fcntl.h> +#include <signal.h> #include <stdlib.h> #include <stdio.h> #include <string.h> @@ -43,6 +44,7 @@ #include "wine/server.h" #include "options.h" #include "wine/debug.h" +#include "global.h" WINE_DEFAULT_DEBUG_CHANNEL(process); WINE_DECLARE_DEBUG_CHANNEL(relay); @@ -126,6 +128,9 @@ /* scheduler/pthread.c */ extern void PTHREAD_init_done(void); +/* memory/emulate.c */ +extern BOOL MEMORY_SharedUserData(LPVOID, LPCVOID); + extern BOOL MAIN_MainInit(void); typedef WORD (WINAPI *pUserSignalProc)( UINT, DWORD, DWORD, HMODULE16 ); @@ -416,6 +421,20 @@ SetStdHandle( STD_ERROR_HANDLE, current_startupinfo.hStdError ); } + /* Reserves a PAGE_NOACCESS at 0x7ffe0000. That page is used as shared + * memory between kernel space and user space (see SharedUserData in + * ntddk.h). It looks like it is at 0xffdf0000 on NT5. That is still to + * be checked. + */ + if ( VirtualAlloc( (LPVOID)0x7ffe0000, 0x10000, MEM_RESERVE|MEM_COMMIT, PAGE_NOACCESS ) == (LPCVOID)0x07ffe0000 ) + { + VIRTUAL_SetFaultHandler( (LPCVOID)0x7ffe0000, MEMORY_SharedUserData, 0 ); + } + else + { + WARN( "Unable to map SharedUserData, SafeDisc protection won't be supported\n" ); + } + /* Now we can use the pthreads routines */ PTHREAD_init_done(); @@ -440,7 +459,7 @@ */ static void start_process(void) { - int debugged, console_app; + int suspended, debugged, console_app; LPTHREAD_START_ROUTINE entry; WINE_MODREF *wm; HFILE main_file = main_exe_file; @@ -481,7 +500,8 @@ req->gui = !console_app; wine_server_add_data( req, main_exe_name, strlen(main_exe_name) ); wine_server_call( req ); - debugged = reply->debugged; + suspended = reply->suspended; + debugged = reply->debugged; } SERVER_END_REQ; @@ -513,6 +533,8 @@ PROCESS_CallUserSignalProc( USIG_PROCESS_LOADED, 0 ); /* Call UserSignalProc ( USIG_PROCESS_RUNNING ... ) only for non-GUI win32 apps */ if (console_app) PROCESS_CallUserSignalProc( USIG_PROCESS_RUNNING, 0 ); + + if (suspended) raise( SIGSTOP ); if (TRACE_ON(relay)) DPRINTF( "%08lx:Starting process %s (entryproc=%p)\n", Index: server/process.c =================================================================== RCS file: /home/wine/wine/server/process.c,v retrieving revision 1.83 diff -u -r1.83 process.c --- server/process.c 26 Apr 2002 19:05:18 -0000 1.83 +++ server/process.c 23 May 2002 18:55:07 -0000 @@ -382,6 +382,14 @@ } +/* signal the parent that a process init is finished */ +void process_init_done( struct process *process ) +{ + set_event( process->init_event ); + release_object( process->init_event ); + process->init_event = NULL; +} + /* get a process from an id (and increment the refcount) */ struct process *get_process_from_id( void *id ) { @@ -896,13 +904,27 @@ if ((process->exe.namelen = get_req_data_size())) process->exe.filename = memdup( get_req_data(), process->exe.namelen ); - generate_startup_debug_events( current->process, req->entry ); - set_event( process->init_event ); - release_object( process->init_event ); - process->init_event = NULL; + generate_startup_debug_events( process, req->entry ); if (req->gui) process->idle_event = create_event( NULL, 0, 1, 0 ); - if (current->suspend + current->process->suspend > 0) stop_thread( current ); - reply->debugged = (current->process->debugger != 0); + + reply->suspended = 0; + reply->debugged = (current->process->debugger != 0); + if (current->suspend + current->process->suspend > 0) + { + /* temporarily clear the init event so that ptrace functions work */ + struct event *init_event = process->init_event; + process->init_event = NULL; + stop_thread( current ); + process->init_event = init_event; + + if (current->attached) + { + reply->suspended = 1; + continue_thread( current ); /* it will suspend itself */ + return; + } + } + process_init_done( process ); } /* open a handle to a process */ Index: server/process.h =================================================================== RCS file: /home/wine/wine/server/process.h,v retrieving revision 1.27 diff -u -r1.27 process.h --- server/process.h 22 Mar 2002 00:21:23 -0000 1.27 +++ server/process.h 23 May 2002 18:55:07 -0000 @@ -90,6 +90,7 @@ extern struct thread *create_process( int fd ); extern struct process *get_process_from_id( void *id ); extern struct process *get_process_from_handle( handle_t handle, unsigned int access ); +extern void process_init_done( struct process *process ); extern int process_set_debugger( struct process *process, struct thread *thread ); extern int debugger_detach( struct process* process, struct thread* debugger ); Index: server/protocol.def =================================================================== RCS file: /home/wine/wine/server/protocol.def,v retrieving revision 1.36 diff -u -r1.36 protocol.def --- server/protocol.def 25 Apr 2002 22:58:59 -0000 1.36 +++ server/protocol.def 23 May 2002 18:55:12 -0000 @@ -276,6 +276,7 @@ int gui; /* is it a GUI process? */ VARARG(filename,string); /* file name of main exe */ @REPLY + int suspended; /* created suspended? */ int debugged; /* being debugged? */ @END Index: server/ptrace.c =================================================================== RCS file: /home/wine/wine/server/ptrace.c,v retrieving revision 1.14 diff -u -r1.14 ptrace.c --- server/ptrace.c 10 Mar 2002 00:18:36 -0000 1.14 +++ server/ptrace.c 23 May 2002 18:55:13 -0000 @@ -79,7 +79,12 @@ switch(sig) { case SIGSTOP: /* continue at once if not suspended */ - if (thread && (thread->process->suspend + thread->suspend)) break; + if (thread && (thread->process->suspend + thread->suspend)) + { + /* check if this was the self-suspend upon process init */ + if (thread->process->init_event) process_init_done( thread->process ); + break; + } /* fall through */ default: /* ignore other signals for now */ if (thread && get_thread_single_step( thread )) Index: server/trace.c =================================================================== RCS file: /home/wine/wine/server/trace.c,v retrieving revision 1.132 diff -u -r1.132 trace.c --- server/trace.c 26 Apr 2002 19:05:18 -0000 1.132 +++ server/trace.c 23 May 2002 18:55:20 -0000 @@ -441,6 +441,7 @@ static void dump_init_process_done_reply( const struct init_process_done_reply *req ) { + fprintf( stderr, " suspended=%d,", req->suspended ); fprintf( stderr, " debugged=%d", req->debugged ); } There are two patches in there. The first one sets a fault handler for the SharedUserData. This looks fine to me, and will probably be applied when memory/emulate.c will be applied. The second one has been written by Alexandre to fix the process suspension at creation time. Once again I'd like to hear from him to know what he doesn't like about the code, as he's the one who wrote it :-) Hope this helps. I'm available if you need more information Laurent Pinchart

3 9

Problem in winpos.c which ends in a infinite loop
by Christian Costa 29 May '02

29 May '02

Hi everyone, I tried to install the game Zork : Grand Inquisitor ( probably a win16 app) and the installer crashed. With the debugger, I Obtained the attached log. As you can see 1) CreateWindowExA is called (9170) 2) X11DRV_CreateWindow send the WM_CREATE message to the window (9168) 3) the window procedure of the app is executed (9162) and call SetForegroundWindow (9161) 4) WINPOS_SetActiveWindows is then called (9160) and send the WM_QUERYNEWPALETTE (9159) 5) When the windows procedure receive the message (9153), it call SetForegroundWindow (9152) 6) return to 4 Commenting the lines (see attached diff) in winpos.c wich send the WM_QUERYNEWPALETTE avoids the infinite loop and makes the installer work. The installer runs perfectly under Windows 98. It seems that the app's windows procedure does not expect a WM_QUERYNEWPALETTE message. If someone that knows this code well have an idea... else I will report this bug to bugzilla. Ciao, Christian 9084 0x40698fe2 (CallWindowProcW+0xb2(func=0x40ec0412, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:2831] in user32.dll.so) (ebp=405d428c) 9085 0x406a8e77 (call_window_proc+0xd7(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0, unicode=0x1) [message.c:1368] in user32.dll.so) (ebp=405d42e8) 9086 0x406a9ab1 (SendMessageTimeoutW+0xe1(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x405d436c) [message.c:1738] in user32.dll.so) (ebp=405d4348) 9087 0x406a9d37 (SendMessageW+0x37(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0) [message.c:1818] in user32.dll.so) (ebp=405d437c) 9088 0x40691780 (WINPOS_SetActiveWindow+0x230(hWnd=0x10021, fMouse=0x0, fChangeFocus=0x1) [winpos.c:1282] in user32.dll.so) (ebp=405d43d4) 9089 0x406909fa (SetForegroundWindow+0x7a(hwnd=0x10021) [winpos.c:762] in user32.dll.so) (ebp=405d43f0) 9090 0x0040535d (splash.exe..text+0x435d in H:\splash\splash.exe) (ebp=405d4644) 9091 0x406924dd (WINPROC_CallWndProc+0x8d(proc=0x404cc0, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:183] in user32.dll.so) (ebp=405d4674) 9092 0x40698989 (WINPROC_CallProc32WTo32A+0xc9(func=0x404cc0, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:2616] in user32.dll.so) (ebp=405d469c) 9093 0x40698fe2 (CallWindowProcW+0xb2(func=0x40ec0412, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:2831] in user32.dll.so) (ebp=405d46d0) 9094 0x406a8e77 (call_window_proc+0xd7(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0, unicode=0x1) [message.c:1368] in user32.dll.so) (ebp=405d472c) 9095 0x406a9ab1 (SendMessageTimeoutW+0xe1(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x405d47b0) [message.c:1738] in user32.dll.so) (ebp=405d478c) 9096 0x406a9d37 (SendMessageW+0x37(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0) [message.c:1818] in user32.dll.so) (ebp=405d47c0) 9097 0x40691780 (WINPOS_SetActiveWindow+0x230(hWnd=0x10021, fMouse=0x0, fChangeFocus=0x1) [winpos.c:1282] in user32.dll.so) (ebp=405d4818) 9098 0x406909fa (SetForegroundWindow+0x7a(hwnd=0x10021) [winpos.c:762] in user32.dll.so) (ebp=405d4834) 9099 0x0040535d (splash.exe..text+0x435d in H:\splash\splash.exe) (ebp=405d4a88) 9100 0x406924dd (WINPROC_CallWndProc+0x8d(proc=0x404cc0, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:183] in user32.dll.so) (ebp=405d4ab8) 9101 0x40698989 (WINPROC_CallProc32WTo32A+0xc9(func=0x404cc0, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:2616] in user32.dll.so) (ebp=405d4ae0) 9102 0x40698fe2 (CallWindowProcW+0xb2(func=0x40ec0412, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:2831] in user32.dll.so) (ebp=405d4b14) 9103 0x406a8e77 (call_window_proc+0xd7(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0, unicode=0x1) [message.c:1368] in user32.dll.so) (ebp=405d4b70) 9104 0x406a9ab1 (SendMessageTimeoutW+0xe1(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x405d4bf4) [message.c:1738] in user32.dll.so) (ebp=405d4bd0) 9105 0x406a9d37 (SendMessageW+0x37(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0) [message.c:1818] in user32.dll.so) (ebp=405d4c04) 9106 0x40691780 (WINPOS_SetActiveWindow+0x230(hWnd=0x10021, fMouse=0x0, fChangeFocus=0x1) [winpos.c:1282] in user32.dll.so) (ebp=405d4c5c) 9107 0x406909fa (SetForegroundWindow+0x7a(hwnd=0x10021) [winpos.c:762] in user32.dll.so) (ebp=405d4c78) 9108 0x0040535d (splash.exe..text+0x435d in H:\splash\splash.exe) (ebp=405d4ecc) 9109 0x406924dd (WINPROC_CallWndProc+0x8d(proc=0x404cc0, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:183] in user32.dll.so) (ebp=405d4efc) 9110 0x40698989 (WINPROC_CallProc32WTo32A+0xc9(func=0x404cc0, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:2616] in user32.dll.so) (ebp=405d4f24) 9111 0x40698fe2 (CallWindowProcW+0xb2(func=0x40ec0412, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:2831] in user32.dll.so) (ebp=405d4f58) 9112 0x406a8e77 (call_window_proc+0xd7(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0, unicode=0x1) [message.c:1368] in user32.dll.so) (ebp=405d4fb4) 9113 0x406a9ab1 (SendMessageTimeoutW+0xe1(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x405d5038) [message.c:1738] in user32.dll.so) (ebp=405d5014) 9114 0x406a9d37 (SendMessageW+0x37(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0) [message.c:1818] in user32.dll.so) (ebp=405d5048) 9115 0x40691780 (WINPOS_SetActiveWindow+0x230(hWnd=0x10021, fMouse=0x0, fChangeFocus=0x1) [winpos.c:1282] in user32.dll.so) (ebp=405d50a0) 9116 0x406909fa (SetForegroundWindow+0x7a(hwnd=0x10021) [winpos.c:762] in user32.dll.so) (ebp=405d50bc) 9117 0x0040535d (splash.exe..text+0x435d in H:\splash\splash.exe) (ebp=405d5310) 9118 0x406924dd (WINPROC_CallWndProc+0x8d(proc=0x404cc0, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:183] in user32.dll.so) (ebp=405d5340) 9119 0x40698989 (WINPROC_CallProc32WTo32A+0xc9(func=0x404cc0, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:2616] in user32.dll.so) (ebp=405d5368) 9120 0x40698fe2 (CallWindowProcW+0xb2(func=0x40ec0412, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:2831] in user32.dll.so) (ebp=405d539c) 9121 0x406a8e77 (call_window_proc+0xd7(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0, unicode=0x1) [message.c:1368] in user32.dll.so) (ebp=405d53f8) 9122 0x406a9ab1 (SendMessageTimeoutW+0xe1(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x405d547c) [message.c:1738] in user32.dll.so) (ebp=405d5458) 9123 0x406a9d37 (SendMessageW+0x37(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0) [message.c:1818] in user32.dll.so) (ebp=405d548c) 9124 0x40691780 (WINPOS_SetActiveWindow+0x230(hWnd=0x10021, fMouse=0x0, fChangeFocus=0x1) [winpos.c:1282] in user32.dll.so) (ebp=405d54e4) 9125 0x406909fa (SetForegroundWindow+0x7a(hwnd=0x10021) [winpos.c:762] in user32.dll.so) (ebp=405d5500) 9126 0x0040535d (splash.exe..text+0x435d in H:\splash\splash.exe) (ebp=405d5754) 9127 0x406924dd (WINPROC_CallWndProc+0x8d(proc=0x404cc0, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:183] in user32.dll.so) (ebp=405d5784) 9128 0x40698989 (WINPROC_CallProc32WTo32A+0xc9(func=0x404cc0, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:2616] in user32.dll.so) (ebp=405d57ac) 9129 0x40698fe2 (CallWindowProcW+0xb2(func=0x40ec0412, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:2831] in user32.dll.so) (ebp=405d57e0) 9130 0x406a8e77 (call_window_proc+0xd7(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0, unicode=0x1) [message.c:1368] in user32.dll.so) (ebp=405d583c) 9131 0x406a9ab1 (SendMessageTimeoutW+0xe1(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x405d58c0) [message.c:1738] in user32.dll.so) (ebp=405d589c) 9132 0x406a9d37 (SendMessageW+0x37(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0) [message.c:1818] in user32.dll.so) (ebp=405d58d0) 9133 0x40691780 (WINPOS_SetActiveWindow+0x230(hWnd=0x10021, fMouse=0x0, fChangeFocus=0x1) [winpos.c:1282] in user32.dll.so) (ebp=405d5928) 9134 0x406909fa (SetForegroundWindow+0x7a(hwnd=0x10021) [winpos.c:762] in user32.dll.so) (ebp=405d5944) 9135 0x0040535d (splash.exe..text+0x435d in H:\splash\splash.exe) (ebp=405d5b98) 9136 0x406924dd (WINPROC_CallWndProc+0x8d(proc=0x404cc0, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:183] in user32.dll.so) (ebp=405d5bc8) 9137 0x40698989 (WINPROC_CallProc32WTo32A+0xc9(func=0x404cc0, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:2616] in user32.dll.so) (ebp=405d5bf0) 9138 0x40698fe2 (CallWindowProcW+0xb2(func=0x40ec0412, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:2831] in user32.dll.so) (ebp=405d5c24) 9139 0x406a8e77 (call_window_proc+0xd7(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0, unicode=0x1) [message.c:1368] in user32.dll.so) (ebp=405d5c80) 9140 0x406a9ab1 (SendMessageTimeoutW+0xe1(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x405d5d04) [message.c:1738] in user32.dll.so) (ebp=405d5ce0) 9141 0x406a9d37 (SendMessageW+0x37(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0) [message.c:1818] in user32.dll.so) (ebp=405d5d14) 9142 0x40691780 (WINPOS_SetActiveWindow+0x230(hWnd=0x10021, fMouse=0x0, fChangeFocus=0x1) [winpos.c:1282] in user32.dll.so) (ebp=405d5d6c) 9143 0x406909fa (SetForegroundWindow+0x7a(hwnd=0x10021) [winpos.c:762] in user32.dll.so) (ebp=405d5d88) 9144 0x0040535d (splash.exe..text+0x435d in H:\splash\splash.exe) (ebp=405d5fdc) 9145 0x406924dd (WINPROC_CallWndProc+0x8d(proc=0x404cc0, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:183] in user32.dll.so) (ebp=405d600c) 9146 0x40698989 (WINPROC_CallProc32WTo32A+0xc9(func=0x404cc0, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:2616] in user32.dll.so) (ebp=405d6034) 9147 0x40698fe2 (CallWindowProcW+0xb2(func=0x40ec0412, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:2831] in user32.dll.so) (ebp=405d6068) 9148 0x406a8e77 (call_window_proc+0xd7(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0, unicode=0x1) [message.c:1368] in user32.dll.so) (ebp=405d60c4) 9149 0x406a9ab1 (SendMessageTimeoutW+0xe1(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x405d6148) [message.c:1738] in user32.dll.so) (ebp=405d6124) 9150 0x406a9d37 (SendMessageW+0x37(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0) [message.c:1818] in user32.dll.so) (ebp=405d6158) 9151 0x40691780 (WINPOS_SetActiveWindow+0x230(hWnd=0x10021, fMouse=0x0, fChangeFocus=0x1) [winpos.c:1282] in user32.dll.so) (ebp=405d61b0) 9152 0x406909fa (SetForegroundWindow+0x7a(hwnd=0x10021) [winpos.c:762] in user32.dll.so) (ebp=405d61cc) 9153 0x0040535d (splash.exe..text+0x435d in H:\splash\splash.exe) (ebp=405d6420) 9154 0x406924dd (WINPROC_CallWndProc+0x8d(proc=0x404cc0, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:183] in user32.dll.so) (ebp=405d6450) 9155 0x40698989 (WINPROC_CallProc32WTo32A+0xc9(func=0x404cc0, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:2616] in user32.dll.so) (ebp=405d6478) 9156 0x40698fe2 (CallWindowProcW+0xb2(func=0x40ec0412, hwnd=0x10021, msg=0x30f, wParam=0x0, lParam=0x0) [winproc.c:2831] in user32.dll.so) (ebp=405d64ac) 9157 0x406a8e77 (call_window_proc+0xd7(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0, unicode=0x1) [message.c:1368] in user32.dll.so) (ebp=405d6508) 9158 0x406a9ab1 (SendMessageTimeoutW+0xe1(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x405d658c) [message.c:1738] in user32.dll.so) (ebp=405d6568) 9159 0x406a9d37 (SendMessageW+0x37(hwnd=0x10021, msg=0x30f, wparam=0x0, lparam=0x0) [message.c:1818] in user32.dll.so) (ebp=405d659c) 9160 0x40691780 (WINPOS_SetActiveWindow+0x230(hWnd=0x10021, fMouse=0x0, fChangeFocus=0x1) [winpos.c:1282] in user32.dll.so) (ebp=405d65f4) 9161 0x406909fa (SetForegroundWindow+0x7a(hwnd=0x10021) [winpos.c:762] in user32.dll.so) (ebp=405d6610) 9162 0x00404b62 (splash.exe..text+0x3b62 in H:\splash\splash.exe) (ebp=405d697c) 9163 0x406924dd (WINPROC_CallWndProc+0x8d(proc=0x404cc0, hwnd=0x10021, msg=0x1, wParam=0x0, lParam=0x405d6d24) [winproc.c:183] in user32.dll.so) (ebp=405d69ac) 9164 0x40698ed2 (CallWindowProcA+0xb2(func=0x404cc0, hwnd=0x10021, msg=0x1, wParam=0x0, lParam=0x405d6d24) [winproc.c:2795] in user32.dll.so) (ebp=405d69e0) 9165 0x406a8ea3 (call_window_proc+0x103(hwnd=0x10021, msg=0x1, wparam=0x0, lparam=0x405d6d24, unicode=0x0) [message.c:1372] in user32.dll.so) (ebp=405d6a3c) 9166 0x406a9c0d (SendMessageTimeoutA+0xed(hwnd=0x10021, msg=0x1, wparam=0x0, lparam=0x405d6d24, flags=0x0, timeout=0xffffffff, res_ptr=0x405d6ac0) [message.c:1786] in user32.dll.so) (ebp=405d6a9c) 9167 0x406a9d87 (SendMessageA+0x37(hwnd=0x10021, msg=0x1, wparam=0x0, lparam=0x405d6d24) [message.c:1829] in user32.dll.so) (ebp=405d6ad0) 9168 0x409b7702 (X11DRV_CreateWindow+0x572(hwnd=0x10021, cs=0x405d6d24, unicode=0x0) [window.c:1005] in x11drv.dll.so) (ebp=405d6b44) 9169 0x4068bd20 (WIN_CreateWindowEx+0x590(cs=0x405d6d24, classAtom=0xc00d, type=0x2) [win.c:1154] in user32.dll.so) (ebp=405d6c0c) 9170 0x4068c17e (CreateWindowExA+0x14e(exStyle=0x0, className=0x411b3c, windowName=0x41c60d50, style=0x80880000, x=0x0, y=0x0, width=0x400, height=0x300, parent=0x0, menu=0x0, instance=0x400000, data=0x0) [win.c:1309] in user32.dll.so) (ebp=405d6d60) 9171 0x00405cd1 (splash.exe..text+0x4cd1 in H:\splash\splash.exe) (ebp=405d6e90) 9172 0x400ca01b (start_process+0x24b [process.c:526] in libntdll.dll.so) (ebp=405d6f38) 9173 0x400ce257 (call_on_thread_stack+0x27(func=0x400c9dd0) [sysdeps.c:105] in libntdll.dll.so) (ebp=405d6ff4) 9174 0x400ce410 (SYSDEPS_CallOnStack+0x14 in libntdll.dll.so) (ebp=00000000) Index: winpos.c =================================================================== RCS file: /home/wine/wine/windows/winpos.c,v retrieving revision 1.133 diff -u -r1.133 winpos.c --- winpos.c 25 May 2002 22:16:13 -0000 1.133 +++ winpos.c 29 May 2002 17:38:49 -0000 @@ -1278,8 +1278,10 @@ PERQDATA_SetActiveWnd( pOldActiveQueue->pQData, 0 ); /* send palette messages */ + /* if (hWnd && SendMessageW( hWnd, WM_QUERYNEWPALETTE, 0, 0L)) SendMessageW( HWND_BROADCAST, WM_PALETTEISCHANGING, (WPARAM)hWnd, 0 ); + */ /* if prev wnd is minimized redraw icon title */ if( IsIconic( hwndPrevActive ) ) WINPOS_RedrawIconTitle(hwndPrevActive);

2 2

RE: Stripping of whitespaces at the end of lines
by Patrik Stridvall 29 May '02

29 May '02

> Enforcing 'no space before the non-blank char on every line' is > orders of magniture more difficult than 'indentation is 4 space' Is it? find . -name \*.c | xargs perl -ne '/^\s*/ && $& =~ / / && do { print }' compared to find . -name \*.c | xargs perl -ne '!/^(?: )*/ && do { print }' Of course both will fail on Wine style function header comments but then you got what you asked for above. Anyway. I fully agree what you (Dimitrie) that the point of indentation is to make it human readable not easy for tools to verify. In fact I think I agree with almost everything you have said on the subject. So for once we agree. :-)

1 0

Quick question on the Cygwin/Mingw port
by Steven Edwards 29 May '02

29 May '02

Hola, I'm on the road traveling till Monday so I sent the question here rather then cygwin support because I figured someone here has to have a little cygwin and mingw experience. I'm using cygwin to host my mingw WINE devel with --target=mingw --host-mingw --build=mingw -mno-cygwin and -fnative-struct and it is still linking to cygwin1.dll. I don't really understand whats going on because it doesn't seem to be using any of the exports from cygwin1.dll but if I try to test the dlls/programs/tools on another box it bitches about missing the dll. If anyone has any insight please let me know or just send this to /dev/null Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

3 3

Use of wine RPC implementation for TAPI 2 client ?
by Yann Dirson 29 May '02

29 May '02

We're investigating the implementation of a TAPI 2 client lib on Linux. Wine looks like one of the projects with an implementation of DCE/MS-RPC. What's the status of this RPC implementation, in terms of specs coverage, and stability ? Do you have an MIDL compiler ? Regards, -- Yann Dirson <Yann.Dirson(a)fr.alcove.com> http://www.alcove.com/ Technical support manager Responsable de l'assistance technique Senior Free-Software Consultant Consultant senior en Logiciels Libres Debian developer (dirson(a)debian.org) Développeur Debian

2 1

More regression errors ...
by Paul Millar 29 May '02

29 May '02

Hi, I've noticed that amongst last night's slew of patches, Mehmet's regression tests were applied without his patches that correct wine's behaviour. Wine now fails regression tests on all platforms. If his patches are delayed for some reason, could/should we use todo_wine to acknowledge that these failures are known? If so, I've attached a trivial patch to do this for the tests that failed for me ... ChangeLog: Mark failing regression tests as todo Cheers, ---- Paul Millar

2 1

Re: [Bug 722] Changed - GDI.EXE
by Andriy Palamarchuk 29 May '02

29 May '02

--- Johan Gill <johane(a)lysator.liu.se> wrote: > On Tue, 28 May 2002 wine-bugs(a)winehq.com wrote: > > > Some rights wouldn't hurt btw. > > + > > + > > + ------- Additional Comments From > Speeddymon(a)yahoo.com 2002-05-28 15:14 ------- > > + Send an email to wine-bugs(a)winehq.com asking > someone to give you additional > > + BugZilla priveleges so that you may work on bug > 722 > > So here's an offical request for privileges. Done. Official congratulations with new privileges :-) Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

1 0

Main window size difference
by Guy L. Albertelli 29 May '02

29 May '02

Has anyone else noticed that the size of main windows under Windows is much different than under Wine. As an example, using the Tab control test program (from the ControlSpy series). Under Windows the overall size appears to be about 819x564. Under Wine it is about 505x268. (I may be off by 1 or 2 pixels, but not 30% to 40%.) And yes my screen resolution under both systems is 1024x768. This obviously makes doing pixel matching, or even item layout matching difficult. Guy Albertelli <<galberte(a)neo.lrun.com>>

2 1

Re: Idea for people with priveleges
by Andriy Palamarchuk 29 May '02

29 May '02

--- Dustin Navea <speeddymon(a)yahoo.com> wrote: > Anyone that can modify the layout of the BugZilla > site > should take this into consideration: > > People with priveleges as you know can pretty much > do > what they need to with a bug, i.e. if it is resolved > and the person working on it forgot to set it as > resolved, anyone with preveleges can do that. But, > what about if we havent heard from the reporter in a > while and we need to knock the bug out, our only > option is to ask the reporter if it has been > resolved, > tell them to try it with a recent wine build and to > try some of the things mentioned in the comments, > and > then mark it as resolved and them after that mark it > as closed, so it is shown as closed and not resolved > on the bug list... > > why not give people with priveleges the ability to > close it without resolving it, so that they only > have > to make 1 post instead of 2? Plus that way we have > bugs that are actually resolved marked so, and ones > that we are unsure of marked as closed but can > always > be reopened... Why do you want to close such bug in the first place? IMHO it is Ok to put the bug in the RESOLVED state and wait some time if the original reporter provides feedback or more information will become available. Keeping the bug in RESOLVED state will insure that somebody will look at the bug one more time. Is this too many steps? >From Bugzilla docs: "QA looks at resolved bugs and to make sure the appropriate action has been taken. If they agree, the bug is marked VERIFIED. Bugs remain in this state until the product ships, at which time the bug is marked CLOSED." Currently we do not have one more "verification layer" for bugs. Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

1 0

Something's wrong with hypermail
by Johan Gill 29 May '02

29 May '02

I've noticed that selecting 'Next message' in the web interface to the mailinglists sometimes skips messages. For example, take a look at my latest messages to wine-patches. Standing at the second 'PATCH: DirectSound', the next message is said to be 'Re: RESUBMIT: PATCH: DirectSound'. Hang on...this is the case for my mmioAdvance patch also! Ok, so my patches seem to confuse the interface :/ /Johan Gill, johane(a)lysator.liu.se

1 0

Re: some other playsound fixes
by Alexandre Julliard 29 May '02

29 May '02

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > typedef struct tagWINE_PLAYSOUND { > - HANDLE hThread; > - HANDLE hReadyEvent; > - BOOL bStop; > - LPCWSTR pszSound; > - HMODULE hMod; > - DWORD fdwSound; > - BOOL bLoop; > - BOOL bAlloc; > + volatile BOOL bLoop : 1, > + bAlloc : 1; > + LPCWSTR pszSound; > + HMODULE hMod; > + DWORD fdwSound; > + struct tagWINE_PLAYSOUND* lpNext; > } WINE_PLAYSOUND, *LPWINE_PLAYSOUND; If you need to make variables volatile, something is wrong with the synchronization, and volatile is the wrong fix (especially on a bit field where updates can't be atomic). What is this supposed to fix? -- Alexandre Julliard julliard(a)winehq.com

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel