December 2001 - Wine-Devel - list.winehq.org

Re: We *really* need a development model change !

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Just looked at the tool. It only provides gateway from > Perl to wine API functions, right? Yes, though a lot of higher-level stuff could be added to it once people start using it. The C vs. Perl question has been debated already, please check the archive. The truth is that a lot of people are willing to setup a testing infrastructure, but nobody is willing to write the actual tests. So right now we have a minimal infrastructure in Perl, and I'm not going to setup another one until someone starts using the existing one seriously and demonstrates whether it works or not in practice. The theory has been discussed to death already. -- Alexandre Julliard julliard(a)winehq.com

Dec. 27, 2001

Re: We *really* need a development model change !

by Andreas Mohr

On Thu, Dec 27, 2001 at 07:38:24AM -0800, Andriy Palamarchuk wrote: > Because of the goals I'm more inclined to use C-based > test suite. IMHO it is better suited for existing Wine > developers audience and will provide us much bigger > code pool. I'm even ready to have tests in both - Perl > and C. Yes, IMHO we really need a C based test. After all in order to leverage the Windows developer group`s skills, we probably really shouldn't ask them to code it up in perl... The best way IMHO would be to try to make C and perl based test output compatible. That way people familiar with perl coding could code it in perl, and other people would have choice ;) Hmm, wait. Also creating perl based tests would mean that you need to have perl installed on Windows, too. Maybe that is too much of a disadvantage... > The big question is a tool to test GUI. I did not find > any OS Windows GUI testing frameworks :-( I don`t think we should even bother right now. Many windows functions are not GUI based, and those who are could at least get tested against their functional behaviour. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Dec. 27, 2001

Re: We *really* need a development model change !

by Andriy Palamarchuk

Alexandre Julliard wrote: > Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: >>Please comment on both my intended posting and the way I programmed the first >>version of the test suite (I'm not extremely happy with the current program; >>if you have any improvements, then get them here ASAP !). > > Look at programs/winetest, that's the tool we should use to write > tests IMO. Just looked at the tool. It only provides gateway from Perl to wine API functions, right? Advantages I see in using script-based tests: 1) tests can be used without recompilation 2) Perl is familiar to many developers 3) programming in scripting language is usually easier than in C 4) Perl is widely used for testing purposes and I expect to find many testing tools in Perl. Cons: 1) Many current Wine contributors don't know Perl 2) one more level of abstraction does not give significant advantages in this application. On the contrary, it is more difficult to locate cause of problems because developer has to go trough one more, often not familiar layer. Absense of strict typing in this layer will hurt a lot. Advantages of using C-based tests: 1) compilation has to be used to run the tests. In some cases this is an advantage. Before running the tests you'd better be sure it at least compiles in both environments. 2) C is the most familiar to developers language and the language itself is simpler than Perl 3) Documentation for Win32 API is C-oriented. Examples, given in documentation are in C or easy translated to C 4) Developers already have some testing code snippets in C Summary: Requirements to the unit testing tool: 1) should help to quickly create tests 2) easy to use, should help to involve as many developers as possible. 3) may be useful for developers, using Wine for there projects Because of the goals I'm more inclined to use C-based test suite. IMHO it is better suited for existing Wine developers audience and will provide us much bigger code pool. I'm even ready to have tests in both - Perl and C. The big question is a tool to test GUI. I did not find any OS Windows GUI testing frameworks :-( Comments, suggestions? Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

Dec. 27, 2001

Re: [Shrinker] Another landmine

by Robert Baruch

On 26 Dec 2001 12:46:33 -0800 Alexandre Julliard <julliard(a)winehq.com> wrote: > But unlike EXC_CallHandler there is no good reason to do that, except > to work around Shrinker stupidity. And for all we know there might be > 20 more similar tests (and if not, they may be added in the next > Shrinker version), which will lead to major code obfuscation. We will > also most likely have a lot of trouble supporting the various -winver > versions. That was my initial worry. Altering Wine in specific ways just to trick Shrinker will just make Wine that much less understandable. I can imagine that other vendors could write their tools in a similar way, so that their tools check for Genuine(R) Microsoft(TM) Parts(SM). Eventually Wine code would be Microsoft code! In addition, as you pointed out before, if there are other Shrinker versions, there could be more checks to make, and thus more changes to Wine. > At this point I think it would be a better strategy to write an > un-Shrinker tool that disables the most idiotic tests directly in the > shrinkered binary. Thanks to the DMCA, this should probably be done by > someone living outside the US... Well, there's still that SHRINKER.VXD thing under 95/98. If that VXD does not check for specific Microsoft code, then there could be success in emulating it and adding to Wine's "VXD toolbox". Of course, if that VXD contains the "copyright unprotection" code, then emulating it would also be a violation of the DMCA. But I'm up for a little civil disobediance :) OTOH, although IANAL, the interoperability clause of the DMCA (section 103f) could be an out. --Rob

Dec. 27, 2001

Re: err:heap:HEAP_CreateSystemHeap system heap base address 0x65430000 not available

by Rein Klazes

On 26 Dec 2001 12:54:49 -0800, you wrote: > Rein Klazes <rklazes(a)xs4all.nl> writes: > > > Both programs use native win98 commctrl,comctl32 dll's. One of them is > > CDmage, available at http://cdmage.cjb.net > > > > Any suggestions? > > Does this help? Thank you, that solves the problem. Rein. -- Rein Klazes rklazes(a)xs4all.nl

Dec. 26, 2001

Re: We *really* need a development model change !

by Francois Gouget

I wholeheartedly agree with you. I think that both approaches (application oriented, and API oriented) are necessary. * We need the application oriented approach because this makes Wine useful to people now. But maybe we should focus more on specific applications: getting a few applications working very well seems more interesting to me than getting a lot of applications kind of working. The reason is that people migrating from the Windows world don't want applications that kind of work, they want to see stuff that works just as well as on Windows, even if it is limited to a few applications. * We also need the test framework but not only for regression testing. All you need to write tests is a Windows computer so we could probably get the help of people who would otherwise not contribute to Wine (windows programmers who feel intimidated by contributing to Wine). And these tests look like a great way to find bugs in our current implementations: I am quite sure that with just a couple of hours of coding tests you could find quite a few bugs that may otherwise take you days to track down in a relay trace. But as Alexandre said, tact is needed when soliciting the help of windows programmers so that this is not seen as blatant spam. I also like your section about why Wine is worth contributing to. It may need some polishing but it would be nice to have it on WineHQ. After all, WineHQ may tell you what Wine is but there is not a single word about why it is important and why it is worth contributing to. We keep hearing about how Wine is bad for Linux, how we should all stop wasting our time and contribute to native Linux applications instead, how Linux has all the applications it needs anyway, etc., etc. No wonder! We don't even tell our side of the story! Also we need to have a framework in place so that we can handle the sudden downpour of help we are going to receive ;-) Well, even if it's not such a massive number of contributions. We need: * someone to organize things (and unfortunately no-one seems to have the time, please, someone, volunteer!) * a mechanism to track which APIs already have tests in place and which don't. Sure there are 12000 APIs so the risk of overlap seems small, but I am quite sure that the distribution of submissions will not be random. * something to do a 'make test' and report which tests suceeded and which failed * we also need to decide how to write these tests. You seem inclined to write them in C but there has been some work before to create a framework in perl. I consider that both have pros and cons and all I care about at this point is that we do finally get something in place. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

Dec. 26, 2001

Re: We *really* need a development model change !

by Joerg Mayer

On Wed, Dec 26, 2001 at 10:26:27AM -0800, Andriy Palamarchuk wrote: > C Unit test frameworks I found after a quick search: > http://check.sourceforge.net/ > http://people.codefactory.se/~spotty/cunit/ > http://freshmeat.net/projects/autounit/ > > C++: > http://sourceforge.net/projects/cppunit/ Seen on /. two days ago: http://www.codesourcery.com/qm/qmtest Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Dec. 26, 2001

Re: err:heap:HEAP_CreateSystemHeap system heap base address 0x65430000 not available

by Alexandre Julliard

Rein Klazes <rklazes(a)xs4all.nl> writes: > Both programs use native win98 commctrl,comctl32 dll's. One of them is > CDmage, available at http://cdmage.cjb.net > > Any suggestions? Does this help? Index: memory/heap.c =================================================================== RCS file: /opt/cvs-commit/wine/memory/heap.c,v retrieving revision 1.53 diff -u -r1.53 heap.c --- memory/heap.c 2001/12/19 19:16:30 1.53 +++ memory/heap.c 2001/12/26 19:12:19 @@ -106,6 +106,7 @@ { /* wait for the heap to be initialized */ WaitForSingleObject( event, INFINITE ); + systemHeap = (HANDLE)base; } CloseHandle( map ); return systemHeap; -- Alexandre Julliard julliard(a)winehq.com

Dec. 26, 2001

Re: We *really* need a development model change !

by Alexandre Julliard

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > I attached a preview of the posting I intend to post on *tons* of Windows > devel newsgroups ("Call For Volunteers"). That way we might actually get > hold of hundreds of Windows developers helping us implement a complete > test suite (complete tests of up to 12000 Windows functions). > Not to mention the additional PR we might get out of this... Yeah, I'm sure spamming the Windows newsgroups is a great PR strategy. Please don't do that. > Please comment on both my intended posting and the way I programmed the first > version of the test suite (I'm not extremely happy with the current program; > if you have any improvements, then get them here ASAP !). Look at programs/winetest, that's the tool we should use to write tests IMO. -- Alexandre Julliard julliard(a)winehq.com

Dec. 26, 2001

Re: [Shrinker] Another landmine

by Alexandre Julliard

Robert Baruch <autophile(a)starband.net> writes: > So anyway, if we implemented this internal function (in C), then in theory > it wouldn't be much of a big deal to code LdrAccessResource in assembly. > Although it will raise a few eyebrows, we can always put in a comment > similar to the one that will go in the assembler-coded EXC_CallHandler, > that this code is required by Shrinker. But unlike EXC_CallHandler there is no good reason to do that, except to work around Shrinker stupidity. And for all we know there might be 20 more similar tests (and if not, they may be added in the next Shrinker version), which will lead to major code obfuscation. We will also most likely have a lot of trouble supporting the various -winver versions. At this point I think it would be a better strategy to write an un-Shrinker tool that disables the most idiotic tests directly in the shrinkered binary. Thanks to the DMCA, this should probably be done by someone living outside the US... -- Alexandre Julliard julliard(a)winehq.com

Dec. 26, 2001