November 2004 - Wine-devel - list.winehq.org

[setupx_main.c] SETUPX_CreateStandardLDDs: question about a FIXME
by Fabrice Ménard 10 Nov '04

10 Nov '04

Hi, In setupapi/setupx_main.c, function SETUPX_CreateStandardLDDs: There is a FIXME("LDID_SRCPATH: what exactly do we have to do here ?\n"). It concerns the registry value: SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Setup\\SourcePath. AFAIK, this value defines the location where the setup of windows was done. As we don't have a real windows installation, this key is naturally not set. I'm wondering if it will hurt to set it to a fallback string (maybe the most common one: "D:\\") and get rid of this FIXME. I think if a windows application need this value and don't find what it wants, it justs throw a message box asking for the correct CD (in fact it is very common to have this value set to a wrong path when you have more than one CD device). I know it is not so important, but I really enjoy having one less FIXME :-)) If you're ok with that, I'll send a tiny patch Fabrice Ménard menard.fabrice(a)wanadoo.fr

1 0

Ekush
by Ge van Geldorp 10 Nov '04

10 Nov '04

> From: Ge van Geldorp > > Ekush (http://www.ekush.com) published some binaries. > Surprise, surprise, it looks like ReactOS very much (Check > e.g. the radio buttons on the "Accept License" screen during > 2nd stage setup). > Some string searching in their binaries reveals: > > $ strings -a ver.dll | grep ReactOS > OS2 Images not supported under ReactOS at this time. Shortly after I sent this email to ros-dev yesterday the Ekush website went down. Today they are back, with a slightly changed set of binaries. The strings I reported yesterday are gone now (well, except for the CcRosInitializeFileCache and CcRosReleaseFileCache exports from NTOSKRNL, maybe changing the name of an exported symbol was too difficult???). There's still plenty of other evidence of the ReactOS heritage though. I guess since I only reported about ReactOS they forgot to remove the references to Wine (except ofcourse the copyright notices, those are gone). This pisses me off bigtime. I can only explain it as a deliberate attempt to use the work of Qemu, FreeType, Wine and ReactOS without giving credit. Gé van Geldorp.

2 1

Latent memory corruption bug in widl, with workaround
by Dan Kegel 10 Nov '04

10 Nov '04

I ran into the error Oops, segment violation while running make to build wine from cvs. It failed on the command ../tools/widl/widl -I../../wine/include -I. -I../../wine/include -I../include -h -H ocidl.h ../../wine/include/ocidl.idl Turning on logging showed that it happened while processing an import statement. Running under valgrind yielded output like this: ==10699== Invalid read of size 1 ==10699== at 0x4002273E: strlen (mac_replace_strmem.c:164) ==10699== by 0x805E0D1: pp_xstrdup (../../../wine/libs/wpp/preproc.c:108) ==10699== by 0x805E7B2: pp_add_define (../../../wine/libs/wpp/preproc.c:231) ==10699== by 0x805FB21: add_cmdline_defines (../../../wine/libs/wpp/wpp.c:48) ==10699== Address 0x41233334 is 0 bytes inside a block of size 29 free'd ==10699== at 0x40029961: free (vg_replace_malloc.c:231) ==10699== by 0x805B9B6: yylex (../../../wine/tools/widl/parser.l:126) ==10699== by 0x80548B3: yyparse (/usr/share/bison/bison.simple:573) ==10699== by 0x8054295: main (../../../wine/tools/widl/widl.c:265) Commenting out the free on line 126 of widl/parser.l solved the problem. Uncommenting it and building again, I couldn't reproduce the original crash, but running under valgrind revealed the problem was still there, just hidden. I tried tracing through why the free on line 126 of widl/parser.l was bad, but it was too late, and I was too tired. Can somebody else have a look? It was quite annoying to be dead in the water, unable to build wine... Thanks, Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

Re: [lostwages] developer cheatsheet
by Jeremy Newman 10 Nov '04

10 Nov '04

Added this. The text in the <code> tag on line 78 is long. It needs a line break or something. And I fixed the url in documentation template. Otherwise it looks fine to me. On Fri, 2004-11-05 at 19:00 +0000, Mike Hearn wrote: > Add a developer getting started guide to the website. Hack to your > satisfaction, I probably did it totally wrong ;)

1 0

Thanks
by Frank v Waveren 09 Nov '04

09 Nov '04

I felt nostalgic for starcraft today, so for fun and kicks decided to see if wine was up to the task. Not only did it run, it worked perfectly, using RandR and everything. Very impressive, thanks for the wonderful work everyone! -- Frank v Waveren Fingerprint: 9106 FD0D fvw(a)[var.cx|stack.nl] ICQ#10074100 D6D9 3E7D FAF0 92D1 Public key: hkp://wwwkeys.pgp.net/8D54EB90 3931 90D6 8D54 EB90

1 0

Re: dlls/rsaenh/rsaenh.c
by Alexandre Julliard 09 Nov '04

09 Nov '04

Michael Jung <mjung(a)iss.tu-darmstadt.de> writes: > Changelog: > CPAcquireContext: Set last error to ERROR_SUCCESS in case of success. There are very few functions that set last error on success, do you have a test demonstrating that Windows does it in this case? -- Alexandre Julliard julliard(a)winehq.org

2 6

Re: drive detection and driveui rewrite
by Alexandre Julliard 09 Nov '04

09 Nov '04

Mike Hearn <mike(a)navi.cx> writes: > final part of winecfg work from september > > - Add drive detection and clean up the drive configuration code/UI It doesn't build, you probably forgot some files. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: implement dbghelp's C++ name undecoration on top of msvcrt's
by Eric Pouech 09 Nov '04

09 Nov '04

Eric Pouech a écrit : > see Changelog for the details > A+ with the patch this time. A+

2 1

Re: Convert the COLORREF to a real colour for ExtTextOut
by Alexandre Julliard 09 Nov '04

09 Nov '04

Glenn Wurster <gwurster(a)scs.carleton.ca> writes: > Index: dlls/x11drv/xrender.c > =================================================================== > RCS file: /home/wine/wine/dlls/x11drv/xrender.c,v > retrieving revision 1.48 > diff -u -r1.48 xrender.c > --- dlls/x11drv/xrender.c 27 Oct 2004 00:43:50 -0000 1.48 > +++ dlls/x11drv/xrender.c 8 Nov 2004 03:54:51 -0000 > @@ -1019,6 +1019,11 @@ > UINT align = GetTextAlign( hdc ); > COLORREF textColor = GetTextColor( hdc ); > > + textColor = X11DRV_PALETTE_ToPhysical( physDev, textColor ); > + textColor = ((textColor & 0xFF0000) >> 16) | > + (textColor & 0xFF00) | > + ((textColor & 0xFF) << 16); > + That color swapping looks very suspicious, you shouldn't need anything like that. And actually it seems to me you should simply be able to use physDev->textPixel instead, but maybe I'm missing something. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: fix delete_key in shlwapi/shreg test
by Bill Medland 09 Nov '04

09 Nov '04

On November 9, 2004 12:10 am, James Hawkins wrote: > oops one-letter typo. This is the correct version. > > On Tue, 9 Nov 2004 01:46:50 -0500, James Hawkins <truiken(a)gmail.com> wrote: > > the previous implementation of delete_key only deleted subkeys of a > > requested key to delete. this fixes that and also fixes test failures > > that crop up in advapi32/registry because of extraneous keys in > > Software\Wine\Test. > > > > Changelog > > * fix implementation of delete_key for shreg test Alternatively couldn't we just call SHDeleteKey, now it has been fixed. > > > > -- > > James Hawkins

3 4