February 2005 - Wine-Devel - list.winehq.org

Re: vartest.c - major pain in the build process

by Dimitrie O. Paun

On Mon, Feb 28, 2005 at 01:10:25PM +0100, Ivan Leo Puoti wrote: > OK, then we can have winrash only run them in interactive mode, end of > story. Don't need to do that, there are plenty of tests that run fine with an invisible desktop, there's enough value in having some automated tests. Maybe we need to separate the results... -- Dimi.

Feb. 28, 2005

Tools for identifying what a DLL provides?

by David D. Hagood

I have a DLL from a manufacturer that I don't have the source for, nor do I have the header or the import library for. Since Wine developers frequently have to reverse engineer what a given DLL provides, does anybody have a good recommendation for a tool that can scan the DLL and report what functions it exports, and their arg types and return types?

Feb. 28, 2005

Re: vartest.c - major pain in the build process

by Ivan Leo Puoti

Dmitry Timoshkov wrote: >"Ivan Leo Puoti" <ivanleo(a)gmail.com> wrote: > > > >>We can just have winrash run in interactive mode. Once tests are ready to run, a message pops up >>saying "new tests available" or something of the sort, the user then chooses to run them now or >>later, like the windows automatic updates. Like this we could test both visible and invisible >>desktops, and could have a fair amount of results for both environments. >> >> > >I have to repeat again: Winword, Photoshop, Internet Explorer or any other >application I and most (if not all) developers and users are care about do not >run on an invisible desktop, therefore I don't care about tests running in that >mode at all. It's not simply an optional mode, that's a mode completely useless >for vast majority of Wine users/developers. > > OK, then we can have winrash only run them in interactive mode, end of story. Ivan.

Feb. 28, 2005

Re: vartest.c - major pain in the build process

by Dmitry Timoshkov

"Ivan Leo Puoti" <ivanleo(a)gmail.com> wrote: > We can just have winrash run in interactive mode. Once tests are ready to run, a message pops up > saying "new tests available" or something of the sort, the user then chooses to run them now or > later, like the windows automatic updates. Like this we could test both visible and invisible > desktops, and could have a fair amount of results for both environments. I have to repeat again: Winword, Photoshop, Internet Explorer or any other application I and most (if not all) developers and users are care about do not run on an invisible desktop, therefore I don't care about tests running in that mode at all. It's not simply an optional mode, that's a mode completely useless for vast majority of Wine users/developers. -- Dmitry.

Feb. 28, 2005

Re: invisible desktops - major pain in the testing process

by Ferenc Wagner

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > "Ferenc Wagner" <wferi(a)afavant.elte.hu> wrote: > >> I was under the impression that most of the tests are >> independent of desktop visibility. > > Not really. Any API which directly or indirectly creates > windows or uses GDI is affected by the desktop visibility. Roughly checking the latest results shows that the following tests are affected seriously by desktop visibility: ddraw:ddrawmodes gdi32:metafile ntdll:reg user32:input user32:msg user32:sysparams Some pretty important ones, I agree, but hardly a majority. > Also, as I already pointed out, Wine doesn't run in that > mode at all, so we can't compare apples to apples in that > case. You are absolutely right in the cases where it makes any difference (more than the above list) > And the apps most of the developers/users care about > should be run on a visible desktop anyway. Yes. I don't argue that testing on a visible desktop is a must. Some people are actually doing that, it seems. Or maybe that's just you alone... :) Anyway, I tried to make such results visually distinctive so that we shouldn't drop all the rest. Too bad it doesn't work. > figuring out why it doesn't work is completely useless > IMO, since the results of the tests running on an > invisible desktop can't be used for a reasonable > comparison. I see your point, even if find it a bit strong. Ivan's suggestion is nice, but that requires a probably not so trivial change in winrash. I wonder if Chris will do it. >> And the winrash service is the only way to get several >> reports quickly for a new test. > > Why? What prevents someone to run the tests manually in > interactive mode once a day? Nothing. Somebody is actually doing it for NT4, 2000 and XP. I did it now and then for Win98, but this one can't really be told apart from the invisible ones (not considering error counts). From http://winehq.org/site/janitorial: Volunteers who will run the tests their Windows platform of choice on a regular basis so that we quickly fix incorrect tests * Win95: Michael Stefaniuc, Fabian Cenedese * Win98: Tony Lambregts, Jeff Smith (SE) * WinNT: Luke Stras * WinME: James K Whiting * Win2k: Tom Wickline, Kye Lewis * WinXP: David Miller, Kye Lewis > If that someone can't or won't do it, then we have to find > another someone. I'm pretty sure that there are enough not > lazy people wishing to help we could to choose from. OK. -- Feri.

Feb. 28, 2005

Use of Favourite instead a Favorite in our regedit

by Paul Vriens

Hi, while looking through some registries (via regedit) on several windows versions and Wine, I saw that we use Favourites/Favourite etc.. instead of Favorites/Favorite in our regedit implementation. Is this deliberate or should I create a patch for this? The patch will also change ID_FAVOURITES_MENU, ID_FAVOURITES_ADDTOFAVOURITES,ID_FAVOURITES_REMOVEFAVOURITE. I know it's not a functional change, but hey, one has to be busy. Cheers, Paul

Feb. 28, 2005

Re: vartest.c - major pain in the build process

by Ivan Leo Puoti

Dmitry Timoshkov wrote: > Why? What prevents someone to run the tests manually in interactive mode > once a day? If that someone can't or won't do it, then we have to find > another someone. I'm pretty sure that there are enough not lazy people > wishing to help we could to choose from. We can just have winrash run in interactive mode. Once tests are ready to run, a message pops up saying "new tests available" or something of the sort, the user then chooses to run them now or later, like the windows automatic updates. Like this we could test both visible and invisible desktops, and could have a fair amount of results for both environments. Ivan.

Feb. 28, 2005

Re: WIDL - Sync to ReactOS 20050227

by Steven Edwards

--- Steven Edwards <steven_ed4153(a)yahoo.com> wrote: Maybe I should learn something about IDL and COM before messing with this stuff. This seems to fix it. Thanks Steven Index: dcom.idl =================================================================== RCS file: /home/wine/wine/dlls/ole32/dcom.idl,v retrieving revision 1.1 diff -u -r1.1 dcom.idl --- dcom.idl 22 May 2003 03:36:26 -0000 1.1 +++ dcom.idl 28 Feb 2005 06:25:24 -0000 @@ -217,6 +217,7 @@ cpp_quote("#if 0") [ + explicit_handle, uuid(99fcfec4-5260-101b-bbcb-00aa0021347a), pointer_default(unique) ] @@ -260,6 +261,7 @@ } [ + explicit_handle, uuid(4d9f4ab8-7d1c-11cf-861e-0020af6e7c57), pointer_default(unique) ] __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250

Feb. 28, 2005

Wine cabinet.dll FDI Conformace Test Patch

by Rizwan Kassim

Folks, Aleksandr Liber and I have put together a set of tests for cabinet.dll. Before we submit them to wine-patches, can anyone offer any critiques/input? We plan to submit in a day or two. We're 4th+ year undergraduate students at the UCLA Computer Science program. We're among a group of students doing conformance tests as part of a software engineering course - more info can be found at http://www.geekymedia.com/wine Any advice you can offer will be greatly appreciated! -- Thank you, Rizwan Kassim ***** Patch message follows ***** Wine cabinet.dll FDI Conformace Test Patch (gzipped) Raw files available at : http://www.geekymedia.com/viewcvs/cgi/viewcvs.cgi/group3/wine/ This patch adds tests for the cabinet dll, specifically testing the functions FDICreate, FDIDestroy, FDICopy and FDIIsCabinet. As the FCI functions are still marked TODO in wine, they haven't been tested. The package is self containing, allowing additional cabinet features to be tested by preparing other cabinets in the same manner that ours were. A patch of -p1 will be needed. Changelog:' * configure.ac added dlls/cabinet/tests/Makefile to be generated * dlls/cabinet/Makefile.in added subdirectory reference * dlls/cabinet/tests/Makefile.in standard Makefile.in for tests * dlls/cabinet/tests/cabinet_fdi.c actual test code for FDICreate, FDIDestroy, FDIIsCabinet, FDICopy * dlls/cabinet/tests/data.h contains hex representations of the two test cabinets * dlls/cabinet/tests/tvfs.h * dlls/cabinet/tests/tvfs.c Trivial Virtual File System emulating _read, _write, _open, _lseek and _close * dlls/cabinet/tests/genfiles.sh Cabinet/data.h creation script used for simple.cab and complex.cab- current tests * tools/chexify.pl converts input files to C style arrays Signed-off-by: Rizwan Kassim <rizwank(a)geekymedia.com> Signed-off-by: Dan Kegel <dank(a)kegel.com> Signed-off-by: Aleksandr Liber <aliber(a)ucla.edu>

Feb. 28, 2005

Re: WIDL - Sync to ReactOS 20050227

by Steven Edwards

--- Steven Edwards <steven_ed4153(a)yahoo.com> wrote: > Changelog: > Eric Kohl <eric.kohl(a)t-online.de> > > Server stubs are void functions. > Fix a warning in the server stub descriptor. > Support multiple interfaces per idl file. > Support explicit binding handles. > Support remaining basic types (float, double, small, wchar_t and handle_t). I forgot to rebuild my whole tree after this patch and am getting a error so hold off. steven(a)steven:/usr/src/wine/dlls/ole32# ../../tools/widl/widl -I. -I. -I../../include -I../../include -D__WINESRC__ -D_OLE32_ -DCOM_NO_WINDOWS_H -h -H dcom.h dcom.idl error: ResolveOxid() must not define a binding handle! Thanks Steven __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

Feb. 28, 2005