October 2006 - Wine-Devel - list.winehq.org

Tracking memory allocation
by Jeff L Nov. 3, 2006

Nov. 3, 2006

I am looking at how to track whether memory has been allocated or freed. The SCRIPT_STRING_ANALYSIS opaque point in usp10 can be freed in a number of places. It seems that Windows handles this by checking a list of allocated storage as the passed value of a SCRIPT_STRING_ANALYSIS could be invalid. An obvious problem is where SCRIPT_STRING_ANALYSIS pointer is passed or copied to another pointer. At best one pointer could be NULLed but not both. I have seen this behaviour. It seems that this would not be a unique problem in wine, is there a standard way to handle memory tracking so that if memory is freed, at a later time we can check to see if the pointer is still valid? Jeff Latimer

2 7

Bugs with new 'installer' keyword
by Dan Kegel Nov. 3, 2006

Nov. 3, 2006

I think the new 'installer' keyword is on every bug that needs it now. http://bugs.winehq.org/buglist.cgi?product=Wine&keywords_type=allwords&keyw… shows 94 downloadable apps with keyword 'installer'. Here's a breakdown by component: 24 wine-misc 17 wine-ole 15 wine-msi 7 wine-binary 6 wine-net 4 wine-x11 4 wine-msxml 3 wine-programs 3 wine-kernel 2 wine-user 2 wine-setupapi 2 wine-richedit 1 wine-shdocvw 1 Wine-Rebar 1 wine-msvcrt 1 wine-gdi-(printing) 1 wine-directx-d3d James is taking on the msi and setupapi ones, I think. Anyone else interested in plowing through these to see if we can resolve all the installer bugs before 1.0? - Dan

4 6

Re: winhlp32 implementation
by Kirill K. Smirnov Nov. 2, 2006

Nov. 2, 2006

Eric, there is a mess in winhelp and winhlp32 in "Context" and "Topic" concept: what winhelp calls "topic", winhlp32 calls "context", and what winhelp calls "Context" winhlp32 calls "Topic without CNT section". So, the buttons are messed too. I suspect there are other "features". We couldn't implement winhlp32 and winhelp in one box. I suggest to at least get rid of old winhelp interface in favor of winhlp32, and create symlink winhelp->winhlp32 in windows directory. Does it save the day? >IMO, we don't need two apps but we could make most apps believe both >winhelp & winhlp32 are present and put all effort into a single application >we should also reimplement winhelp based on richedit for the rendering >A+ richedit sound very good - select/copy very easy! (but riched32 is not complete yet) -- Kirill K. Smirnov

3 3

Re: [advpack] Fix typo's
by James Hawkins Nov. 1, 2006

Nov. 1, 2006

On 10/31/06, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > most likely lstrcat was intended. I haven't checked why this lead to errors on > Windows and not on Wine. > It works in XP, at least, because you don't have to specify a full pathname to the INF file. The test that shows that is just a couple lines up. Wine's implementation matches XP. -- James Hawkins

2 1

Executing wine over make segfaults.
by Jimmy W Nov. 1, 2006

Nov. 1, 2006

I got a simple problem, that got really hard to fix. I am trying to cross-compile stuff over a Makefile with ms compiler. Problem is that when make are executing wine as a command, wine segfaults. An example: # wine --version Works! But: Makefile --------- test: wine --version --------- Then run: #make test Wine will segfault! I have tried making a wrapper that will reset env and argv fith static values, and then exec wine with totally new variables, and still fails. Specifications: ubuntu edgy, wine 0.9.22 running as local user. Thankfull for all help. Jimmy Wennlund

3 3

Re: rpcrt4: Set the socket back to blocking in rpcrt4_conn_tcp_handoff as the read and write function for the protseq assume that syscalls will block.
by Juan Lang Oct. 31, 2006

Oct. 31, 2006

+ /* reset to non-blocking behaviour */ + fcntl(ret, F_SETFL, 0); Shouldn't that read "reset to blocking behaviour" then? --Juan ____________________________________________________________________________________ We have the perfect Group for you. Check out the handy changes to Yahoo! Groups (http://groups.yahoo.com)

1 0

Re: cmd: Check for argument in copy, mkdir, delete, goto, move, rmdir, rename, type.
by Alexandre Julliard Oct. 31, 2006

Oct. 31, 2006

Markus Amsler <markus.amsler(a)oribi.org> writes: > This fixes bug http://bugs.winehq.org/show_bug.cgi?id=6286 > --- > programs/cmd/builtins.c | 22 ++++++++++++++++++++++ > 1 files changed, 22 insertions(+), 0 deletions(-) > diff --git a/programs/cmd/builtins.c b/programs/cmd/builtins.c > index 3329a0b..0732170 100644 > --- a/programs/cmd/builtins.c > +++ b/programs/cmd/builtins.c > @@ -36,6 +36,12 @@ #define WIN32_LEAN_AND_MEAN > > #include "wcmd.h" > > +#define CHECK_FOR_ARGUMENT \ > + if (param1[0] == 0x00) { \ > + WCMD_output ("Argument missing\n"); \ > + return; \ > + } > + > void WCMD_execute (char *orig_command, char *parameter, char *substitution); > > struct env_stack > @@ -110,6 +116,8 @@ BOOL force, status; > static const char overwrite[] = "Overwrite file (Y/N)?"; > char string[8], outpath[MAX_PATH], inpath[MAX_PATH], *infile; > > + CHECK_FOR_ARGUMENT > + > if ((strchr(param1,'*') != NULL) && (strchr(param1,'%') != NULL)) { This is ugly, you should use a normal function instead of a macro and do the return explicitly instead of hiding it in the macro (or even put the code in as is, it's only a couple of lines). -- Alexandre Julliard julliard(a)winehq.org

1 0

rotated text in ExtTextOut
by Carl-Daniel Hailfinger Oct. 31, 2006

Oct. 31, 2006

Hi, I have a problem displaying rotated text in Wine where the rotation under Windows is counterclockwise, but the rotation in Wine is clockwise. The patch I came up with rotates the text in the right direction, but the individual characters are still rotated in the wrong direction. The attached WMF file shows the bug. Any help/criticism would be appreciated. diff --git a/dlls/gdi32/font.c b/dlls/gdi32/font.c index 24f16dd..24dac20 100644 --- a/dlls/gdi32/font.c +++ b/dlls/gdi32/font.c @@ -1820,6 +1820,11 @@ BOOL WINAPI ExtTextOutW( HDC hdc, INT x, { cosEsc = cos(lf.lfEscapement * M_PI / 1800); sinEsc = sin(lf.lfEscapement * M_PI / 1800); + if (lf.lfClipPrecision & CLIP_LH_ANGLES) + { + FIXME("rotated text flag with flag CLIP_LH_ANGLES unimplemented, trying to fix it up\n"); + sinEsc = - sinEsc; + } } else { diff --git a/dlls/winex11.drv/xrender.c b/dlls/winex11.drv/xrender.c index 1fe30f6..21eaad6 100644 --- a/dlls/winex11.drv/xrender.c +++ b/dlls/winex11.drv/xrender.c @@ -1135,6 +1135,11 @@ BOOL X11DRV_XRender_ExtTextOut( X11DRV_P if(lf.lfEscapement != 0) { cosEsc = cos(lf.lfEscapement * M_PI / 1800); sinEsc = sin(lf.lfEscapement * M_PI / 1800); + if (lf.lfClipPrecision & CLIP_LH_ANGLES) + { + FIXME("rotated text flag with flag CLIP_LH_ANGLES unimplemented, trying to fix it up\n"); + sinEsc = - sinEsc; + } } else { cosEsc = 1; sinEsc = 0; Regards, Carl-Daniel

1 0

Re: [PATCH 5/5] quartzdrv: Implement MsgWaitForMultipleObjectsEx and initial Carbon event handling.
by Alexandre Julliard Oct. 31, 2006

Oct. 31, 2006

Pierre d'Herbemont <pdherbemont(a)free.fr> writes: > + DWORD remaining_timeout = timeout; > + DWORD acceptable_timeout; > + > + /* We can't remain too long without a carbon call, > + or the application seems to hang for the user */ > + do { > + if(remaining_timeout > 50 || remaining_timeout == INFINITE) > + acceptable_timeout = 50; > + else > + acceptable_timeout = remaining_timeout; > + > + ret = WaitForMultipleObjectsEx( count, handles, flags & MWMO_WAITALL, > + acceptable_timeout, flags & MWMO_ALERTABLE ); I don't think polling is an acceptable way to wait for events. You really need to get a file descriptor or some other handle that you can wait on. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: gdi32: Cast-qual warnings fix (1 of 3)
by Alexandre Julliard Oct. 31, 2006

Oct. 31, 2006

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > @@ -1779,16 +1779,17 @@ > > if (!lprect) > flags &= ~ETO_CLIPPED; > - > + > + reordered_str = HeapAlloc(GetProcessHeap(), 0, count * sizeof(WCHAR)); > + lstrcpynW(reordered_str, str, count); The input string is not necessarily null-terminated, and in any case you shouldn't allocate a copy unless it's really necessary. -- Alexandre Julliard julliard(a)winehq.org

1 0