January 2002 - Wine-Devel - list.winehq.org

Re: [Shrinker] Another landmine

by J.Brown (Ender/Amigo)

Of course, one could do a search on Google for something like ""Undocumented Windows NT" ebook" and look at the bottom of the page. Of course, that person better have already ordered a copy! :) - Ender > There's also a book called "Undocumented Windows NT". That would probably > be the best hope of understanding LdrAccessResource, but without being > able to flip through it, I don't know if they cover it. > > --Rob > >

Jan. 3, 2002

Re: Mixed-mode CD Labels

by Chris Green

On Wednesday 02 January 2002 17:00, Francois Gouget wrote: > > There are a number of bug reports concerning CD label problems in > Bugzilla... although currently I can find only one (I thought there were > more). I asked the submitter to try again with a recent Wine. > FYI, here is the bug: > http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=275 Thanks Francois - I've had a look at the bug report you mentioned, and (fingers crossed) it should be fixed with the patch. I can't see any reason why it wouldn't be, anyway! regards Chris Green

Jan. 2, 2002

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

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > 1) look at file test1.pl. It implements exactly the > functionality of existing test.pl module with using > Test::Simple framework. The only change I made are > descriptive error messages for the first few tests. > > Output of test1.pl: > ok 1 - Valid atom handle > ok 2 - No error code defined > ok 3 > ok 4 - Succeed code > ok 5 - Atom name > ok 6 > ok 7 > ok 8 > ok 9 > ok 10 > ok 11 > ok 12 > ok 13 > ok 14 > ok 15 > 1..15 > > The basic usage is not more difficult than one you > suggested, right? Yes, using ok() or assert() is pretty much the same. But it should not be printing all that stuff IMO, except if you explicitly ask it to when debugging a test for instance. The TODO/SKIP stuff is interesting, I agree we probably want something like that. > 3) Things become even more interesting when > Test::Simple is used with module Test::Harness. > Test::Harness allows to run many tests at once and > consolidate results of these tests. > test_all.pl uses the module to run all the tests > (currently test2.pl only). The output of the script: > > test2.p.............# Failed test (test2.pl at > line 8) > # Looks like you failed 1 tests of 4. > dubious > Test returned status 1 (wstat 256, 0x100) > DIED. FAILED tests 2-3 > Failed 2/4 tests, 50.00% okay > Failed Test Status Wstat Total Fail Failed List of > failed > ------------------------------------------------------------------------------- > test2.pl 1 256 4 2 50.00% 2-3 > Failed 1/1 test scripts, 0.00% okay. 2/4 subtests > failed, 50.00% okay. I really don't see a need for this kind of things. IMO we should enforce that tests always succeed, otherwise we can't do regression testing. And running the tests through the Makefile has the advantage that you can check dependencies and only run tests when something affecting them has changed. -- Alexandre Julliard julliard(a)winehq.com

Jan. 2, 2002

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

by Sylvain Petreolle

Running test1.pl returns to me : [syl(a)snoop winetest]$ cd /c/winetest [syl(a)snoop winetest]$ perl test1.pl Can't locate wine.pm in @INC (@INC contains: /usr/lib/perl5/5.6.0/i386-linux /usr/lib/perl5/5.6.0 /usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl .) at test1.pl line 8. BEGIN failed--compilation aborted at test1.pl line 8.--- Andriy Palamarchuk <apa3a(a)yahoo.com> a écrit : > The final attempt to solicit feedback for my > suggestion to use existing testing framework. > > > Want to bring to your attention testing framework > Test::Simple. I think you'll like this one the most > because it implements exactly the ideas you > suggested > earlier, plus some more. > > You can play with the examples unpacking file > winetest.tar.gz to the existing winetest application > directory. > > 1) look at file test1.pl. It implements exactly the > functionality of existing test.pl module with using > Test::Simple framework. The only change I made are > descriptive error messages for the first few tests. > > Output of test1.pl: > ok 1 - Valid atom handle > ok 2 - No error code defined > ok 3 > ok 4 - Succeed code > ok 5 - Atom name > ok 6 > ok 7 > ok 8 > ok 9 > ok 10 > ok 11 > ok 12 > ok 13 > ok 14 > ok 15 > 1..15 > > The basic usage is not more difficult than one you > suggested, right? > > 2) test2.pl - very simple test script. Demonstrates > TODO tests functionality. These are tests which are > known to fail - you are notified if any of these > succeeds by miracle. You'll see following output if > you run the test: > > 1..4 > ok 1 - Success > not ok 2 > # Failed test (test2.pl at line 8) > not ok 3 # TODO Example of using TODO tests > # Failed (TODO) test (test2.pl at line 12) > ok 4 - Example of successfull TODO test # TODO > Example > of using TODO tests > # Looks like you failed 1 tests of 4. > > 3) Things become even more interesting when > Test::Simple is used with module Test::Harness. > Test::Harness allows to run many tests at once and > consolidate results of these tests. > test_all.pl uses the module to run all the tests > (currently test2.pl only). The output of the script: > > test2.p.............# Failed test (test2.pl at > line 8) > # Looks like you failed 1 tests of 4. > dubious > Test returned status 1 (wstat 256, 0x100) > DIED. FAILED tests 2-3 > Failed 2/4 tests, 50.00% okay > Failed Test Status Wstat Total Fail Failed List > of > failed > ------------------------------------------------------------------------------- > test2.pl 1 256 4 2 50.00% 2-3 > Failed 1/1 test scripts, 0.00% okay. 2/4 subtests > failed, 50.00% okay. > > 4) the framework has other nice features, like > skipping tests. Useful in choosing platform-specific > tests, gui vs cli, etc. > > Is this functionality sufficient for winetest? > > However I found a few issues with winetest: > 1) For some reason running test_all.pl with winetest > gives compilation error. I saw the same compilation > error when I tried to use other Perl testing > framework > Test::Unit. > 2) Compilation failure when I try to run test1.pl > directly with Perl, like "perl test1.pl" > > Look forward for your answer. > Let me know if you need more information. > > Andriy Palamarchuk > > > > __________________________________________________ > Do You Yahoo!? > Send your FREE holiday greetings online! > http://greetings.yahoo.com > ATTACHMENT part 2 application/x-gzip name=winetest.tar.gz ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Courrier : http://courrier.yahoo.fr

Jan. 2, 2002

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

by Andreas Mohr

On Wed, Jan 02, 2002 at 02:46:50PM -0800, Francois Gouget wrote: > On Wed, 2 Jan 2002, Andreas Mohr wrote: > [...] > > > What is needed most is a two sample tests: > > > * one simple console based test > > > * another one involving some GUI stuff > > No ! > > We need Win32 GUI, Win32 console and Win16. > > Why is it necessary to separate Win16 from the rest? > On Windows it could make sense: obviously you cannot run the 32bit > tests on Windows 3.x. But in Wine if you are running the Win32 GUI > tests, why not run the Win16 GUI tests? Is a 'Win16 console' test > something that can exist? Would that be a DOS program? In any case > couldn't they be run with all the Win32 console tests? ?? :) We need to have a Win16 framework. Win16 is completely *different*, that's why. (thunking, different programming, ...) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Jan. 2, 2002

winelib, CRT_INIT

by Bill Medland

Does anyone know how _CRT_INIT should interact with winelib? I have a load of code which uses it in the DllMain but I presume that it is a Microsoft hack that the compiler/linker cleverly converts to something else Bill

Jan. 2, 2002

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

by Francois Gouget

On Wed, 2 Jan 2002, Andreas Mohr wrote: [...] > > What is needed most is a two sample tests: > > * one simple console based test > > * another one involving some GUI stuff > No ! > We need Win32 GUI, Win32 console and Win16. Why is it necessary to separate Win16 from the rest? On Windows it could make sense: obviously you cannot run the 32bit tests on Windows 3.x. But in Wine if you are running the Win32 GUI tests, why not run the Win16 GUI tests? Is a 'Win16 console' test something that can exist? Would that be a DOS program? In any case couldn't they be run with all the Win32 console tests? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

Jan. 2, 2002

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

by Andriy Palamarchuk

The final attempt to solicit feedback for my suggestion to use existing testing framework. Want to bring to your attention testing framework Test::Simple. I think you'll like this one the most because it implements exactly the ideas you suggested earlier, plus some more. You can play with the examples unpacking file winetest.tar.gz to the existing winetest application directory. 1) look at file test1.pl. It implements exactly the functionality of existing test.pl module with using Test::Simple framework. The only change I made are descriptive error messages for the first few tests. Output of test1.pl: ok 1 - Valid atom handle ok 2 - No error code defined ok 3 ok 4 - Succeed code ok 5 - Atom name ok 6 ok 7 ok 8 ok 9 ok 10 ok 11 ok 12 ok 13 ok 14 ok 15 1..15 The basic usage is not more difficult than one you suggested, right? 2) test2.pl - very simple test script. Demonstrates TODO tests functionality. These are tests which are known to fail - you are notified if any of these succeeds by miracle. You'll see following output if you run the test: 1..4 ok 1 - Success not ok 2 # Failed test (test2.pl at line 8) not ok 3 # TODO Example of using TODO tests # Failed (TODO) test (test2.pl at line 12) ok 4 - Example of successfull TODO test # TODO Example of using TODO tests # Looks like you failed 1 tests of 4. 3) Things become even more interesting when Test::Simple is used with module Test::Harness. Test::Harness allows to run many tests at once and consolidate results of these tests. test_all.pl uses the module to run all the tests (currently test2.pl only). The output of the script: test2.p.............# Failed test (test2.pl at line 8) # Looks like you failed 1 tests of 4. dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED tests 2-3 Failed 2/4 tests, 50.00% okay Failed Test Status Wstat Total Fail Failed List of failed ------------------------------------------------------------------------------- test2.pl 1 256 4 2 50.00% 2-3 Failed 1/1 test scripts, 0.00% okay. 2/4 subtests failed, 50.00% okay. 4) the framework has other nice features, like skipping tests. Useful in choosing platform-specific tests, gui vs cli, etc. Is this functionality sufficient for winetest? However I found a few issues with winetest: 1) For some reason running test_all.pl with winetest gives compilation error. I saw the same compilation error when I tried to use other Perl testing framework Test::Unit. 2) Compilation failure when I try to run test1.pl directly with Perl, like "perl test1.pl" Look forward for your answer. Let me know if you need more information. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

Jan. 2, 2002

Re: some other console fixes

by eric pouech

> - The Apply button in the Propertysheet never gets enabled. > It always stays grayed out. When I press [Ok], the changes do get active, > but are not saved into the registry. Somehow the property sheet does not > get noticed that values inside it have changed... I do not have a clue > how that works. yes. I didn't enable the apply button (shame on me) in fact, there are two sets of configuration options: - the current and the default - the current only applies to the current opened console, whereas the default eventually gets saved into the registry - the current configuration set is opened with the 'properties' item in the menu - the default configuration set is opened with the 'default' item in the menu - it's the way NT2000 console behaves... not very ergonomic I admit ;-) > - The default font is not fixed pitch. This is strange, since the font enum > appears correct. I hardcoded the default font to Console, but this is > not a good solution. > Testing now appears to provide only correct fonts. Strange. did you remove any entry from the registry before starting the testings ? > - IDA text display is slow, it does a lot of redraws all the time. > > I tried the following patch, which makes redraws async: I think there are two different issues: - wineconsole redraws itself by entire row, which is slow, especially when the program writes character by character. two optimizations could be made here 1/ implement partial row update 2/ the wineconsole could 'compress' incoming messages (especially updates), so that some operations could be factorized (like screen blitting) - painting operations. sometimes, it seems the input gets frozen, and paint events are not generated until the mouse moves for example... this goes down to internal message passing and I didn't have the guts to look into it yet > - Mouse presses should be sent as input events. If I get too annoyed I just > can just implement it ;) if you want to ;-) however, mouse events must be handled with care. they can either mean mouse click events to be generated, but also copy area selection Windows NT2000 console provides a switch (through the hereabove mentionned menu to enable one or the other more...). it's even more ergonomic than before ;-)) > - wineconsole without arguments crashes: thanx. that's fixed. A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Jan. 2, 2002

Re: [Shrinker] Another landmine

by Andreas Mohr

On Wed, Jan 02, 2002 at 03:28:22PM -0500, Robert Baruch wrote: > Hi Dan, > > > "Windows NT/2000 Native API Reference" by Gary Nebbett > > http://www.amazon.com/exec/obidos/ASIN/1578701996/ > > according to my friend who wrote one of the competitors > > to Shrinker. > > I don't know... I looked at its index on amazon.com, and it had no > reference to LdrAccessResource. So I suspect this book gives no > information about the undocumented aspects of Windows, and probably > regurgitates (like so many other API books) the online documentation. > > There's also a book called "Undocumented Windows NT". That would probably > be the best hope of understanding LdrAccessResource, but without being > able to flip through it, I don't know if they cover it. Actually I just ordered both books (and also "Inside COM+ Base Services"), so I'll have it in case anyone needs info. But it'll take some 4 to 8 weeks (ground shipping). And about Windows NT/2000 Native API Reference: AFAIK it is said to be very good and to contain lots of undocumented API things. www.google.com ""Windows NT/2000 Native API Reference" review" should help a lot :-) At least I know that review(s) are good, otherwise I wouldn't have bought it. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Jan. 2, 2002