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

RE: usb support in ROS

by Steven Edwards

Hi, --- Ge van Geldorp <gvg(a)reactos.com> wrote: > No, not yet. Some work is being done on USB but it will take a while > before support is finished. Right now some very basic support accessing HID devices has been implemented but I am sure it does not work on ROS. I assume Thomas just developed it on Windows. I am sure he also would be willing to relicense it LGPL if someone needed it. http://cvs.reactos.com/cgi-bin/cvsweb.cgi/reactos/lib/hid/hid.c?rev=1.3&con… Thanks Steven __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail

Aug. 13, 2004

Re: [GDI] - More Leaks

by Dmitry Timoshkov

"Jon Griffiths" <jon_p_griffiths(a)yahoo.com> wrote: > Changelog: > +controls/button.c controls/combo.c controls/desktop.c > controls/edit.c controls/icontitle.c controls/listbox.c > controls/menu.c controls/scroll.c controls/static.c > dlls/gdi/gdi_main.c dlls/gdi/gdiobj.c dlls/gdi/gdi_private.h > dlls/user/cache.c dlls/user/controls.h dlls/user/user_main.c > dlls/user/winproc.h include/user.h windows/class.c > windows/cursoricon.c windows/dce.c windows/dialog.c > windows/mdi.c windows/syscolor.c windows/sysmetrics.c > Don't leak GDI objects on exit. Of course the patch is correct, but shouldn't that be a job for gdi32 on DLL_PROCESS_DETACH or even DLL_THREAD_DETACH? -- Dmitry.

Aug. 13, 2004

Re: dlls/kernel/heap.c breakage

by Gerald Pfeifer

On Fri, 13 Aug 2004, Robert Reif wrote: >> the following change to dlls/kernel/heap.c broke FreeBSD, both 4.10 >> and 5.2: > Here is the bsd fix. Thanks! Builds like a charm now. Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

Aug. 13, 2004

Re: Acknowledgment page

by Jeremy White

> Here's a question for you - should money contribution's credit expire? > If someone donated 100$ some five years ago, should we still list them? Another comment on this - - I have a list of names that have donated to Wine over the past 2 years - some folks quite generously - and yet I don't feel it's appropriate to publish their names without their permission. I try, when I thank them, to ask if they want it to be an anonymous donation, or if they want credit, but I don't always succeed. But I suspect if I dug around I could find a list of additional names to add there. Cheers, Jeremy

Aug. 13, 2004

Re: Fix compilation of the wininet generated tests

by Hans Leidekker

On Friday 13 August 2004 13:55, Francois Gouget wrote: > * compiling the test with the Windows headers may result in different > sizes/alignments if the Wine headers got the packign wrong. If that's > the case, the compiler will put in different values for sizeof(struct X) > which will result in something like ok(4==8,"..."); Changing the compiler but keeping the same set of headers may also result in different sizes/alignments. This was the case some time ago when MinGW appeared to align structures containing a double to 8 bytes whereas gcc would align those to 4 bytes. -Hans

Aug. 13, 2004

Re: dlls/kernel/heap.c breakage

by Robert Reif

Gerald Pfeifer wrote: > Robert, > > the following change to dlls/kernel/heap.c broke FreeBSD, both 4.10 > and 5.2: Here is the bsd fix. Index: dlls/kernel/heap.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/heap.c,v retrieving revision 1.10 diff -u -r1.10 heap.c --- dlls/kernel/heap.c 13 Aug 2004 00:41:34 -0000 1.10 +++ dlls/kernel/heap.c 13 Aug 2004 12:25:44 -0000 @@ -1124,13 +1124,13 @@ lpmemex->ullAvailPhys = *tmp; lpmemex->ullTotalPageFile = *tmp; lpmemex->ullAvailPageFile = *tmp; - lpmemex->ullMemoryLoad = lpmemex->ullTotalPhys - lpmemex->ullAvailPhys; + lpmemex->dwMemoryLoad = lpmemex->ullTotalPhys - lpmemex->ullAvailPhys; } else { lpmemex->ullAvailPhys = lpmemex->ullTotalPhys; lpmemex->ullTotalPageFile = lpmemex->ullTotalPhys; lpmemex->ullAvailPageFile = lpmemex->ullTotalPhys; - lpmemex->ullMemoryLoad = 0; + lpmemex->dwMemoryLoad = 0; } free(tmp);

Aug. 13, 2004

wine tests

by Ivan Leo Puoti

On our sf page we now have, under the winetest-200408071000 release, 6 copies of the same file, same name and same size, with the exemption of winetest-200408071000-kevin-mingw.zip that has 6 different sizes. Why is this? Ivan.

Aug. 13, 2004

Re: Development model/versioning stuff: Interesting essay on why decentralised versioning is a bad idea

by Mike McCormack

Mike Hearn wrote: > http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot > > What are peoples thoughts on this? It's not (despite appearances) an > argument against BitKeeper due to licensing concerns, but rather a short > paper on why the author believes the "pyramid" patch/development system > is a bad idea. From the article: "For Linux, the consequences of these limitations have been slow and unpredictable release schedules, poor stability of release branches, and a lack of important standards (for instance, no consistent kernel module ABI or even API within a release branch)." I think that the above is incorrect... IMO: * mainline linux kernels have not been unstable. Kernels released by distros, which are presumably done with multiple committers are far more unstable than that released by Linus. * the kernel->user space ABI is extremely stable. The internal kernel ABI is not stable, because supporting 3rd drivers is not a goal of Linux. The release schedule of the kernel is slightly irregular, but I don't think that it's holding back development. The advantage of having a single maintainer is that it reduces the level of politics in the project. We follow Alexandre's goals, which I think are pretty clear and consistent. Multiple maintainers would have multiple goals, and thus create conflict. There's always the option to fork the project if you think that you have a better way of doing things, but nobody has successfully done that so far. The current development model for Wine is achieving good results. I don't think there's any need to mess with it. CVS has it's problems (mostly for maintainers), but there's no better tool at the moment. Mike

Aug. 13, 2004

Re: ADVAPI32: implement SetThreadToken using NtSetInformationThread

by Dmitry Timoshkov

"Mike McCormack" <mike(a)codeweavers.com> wrote: > @@ -545,6 +545,12 @@ > case ThreadBasePriority: > case ThreadAffinityMask: > case ThreadImpersonationToken: > + { > + const HANDLE *phToken = data; > + if (length != sizeof(HANDLE)) return STATUS_INVALID_PARAMETER; > + FIXME("Set ThreadImpersonationToken handle to %p\n", *phToken ); > + return STATUS_SUCCESS; > + } Probably ThreadImpersonationToken handling should be isolated from other thread class identifiers otherwise FIXME will be printed for all them as well. -- Dmitry.

Aug. 13, 2004

dlls/kernel/heap.c breakage

by Gerald Pfeifer

Robert, the following change to dlls/kernel/heap.c broke FreeBSD, both 4.10 and 5.2: revision 1.10 date: 2004/08/13 00:41:34; author: julliard; state: Exp; lines: +115 -88 Robert Reif <reif(a)earthlink.net> Use GlobalMemoryStatusEx in GlobalMemoryStatus rather than the other way around. The failure mode is the following: /sw/gcc-3.3.2/bin/gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_KERNEL32_ -DETCDIR="\"/tmp/WINE/etc\"" -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o heap.o heap.c heap.c: In function `GlobalMemoryStatusEx': heap.c:1127: error: structure has no member named `ullMemoryLoad' heap.c:1133: error: structure has no member named `ullMemoryLoad' gmake: *** [heap.o] Error 1 Would you mind fixing this? Gerald

Aug. 13, 2004