Re: Wine and serial port AGAIN
Vijay Kiran Kamuju writes: > Can anyone tell me how to get that into the mainline kernel ASAP. > Or Anyone can send it on my behalf to lkml list to get it into main line Why don't you send the patch to linux-...@vger.kernel.org? -- Cheers, Feri.
Re: WineHQ redesign
Jeremy Newman <[EMAIL PROTECTED]> writes: > http://wine.codeweavers.com/winehq_new/ Is it possible to add some preload magic for the impressed button images? Otherwise the buttons disappear for a moment when I hover above them the first time. -- Cheers, Feri.
Re: Fix for LoadStringW
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > "Christopher" <[EMAIL PROTECTED]> wrote: > >> Thanks for pointing that out! Am I suppose to attach a test case for all >> my patches to wine-patches? I had submitted a testcase under the bug >> report I filed, so I didn't attach it to the email. > > You have to add the test to the exiting tests in dlls/kernel32/tests Actually, there are LoadStringA tests in dlls/user32/tests/resource.c, maybe it's best to team up with those (and possibly extend for the same set of tests). -- Regards, Feri.
Re: [winetest] Use of HeapAlloc and friends
Paul Vriens <[EMAIL PROTECTED]> writes: > Ferenc Wagner wrote: >> Paul Vriens <[EMAIL PROTECTED]> writes: >> >>> Is there any particular reason we don't use HeapAlloc/HeapReAlloc in >>> winetest? The rest of our programs do, but winetest uses malloc and >>> realloc. >> >> I can't recall any. I'm more comfortable with the latter, since >> winetest is the only Win32 application I've ever written. > > So when I add functionality should I use malloc or can we use a mix? > Should winetest be changed to use HeapAlloc? That I can't tell. At least I haven't heard a single objection against my style in this respect. Mixing the two doesn't sound like a particularly compelling idea for me. -- Cheers, Feri.
Re: [winetest] Use of HeapAlloc and friends
Paul Vriens <[EMAIL PROTECTED]> writes: > Is there any particular reason we don't use HeapAlloc/HeapReAlloc in > winetest? The rest of our programs do, but winetest uses malloc and > realloc. I can't recall any. I'm more comfortable with the latter, since winetest is the only Win32 application I've ever written. -- Feri.
Re: [winetest] Show missing tests in single/group results
Paul Vriens <[EMAIL PROTECTED]> writes: > 'http://www.xs4all.nl/~pvriens/200708031000.new.single/' shows the new results > page for single tests. Instead of a single '.' there is a failure shown (red > box) and a skip border (as these tests have not run). There is still a '.' > which > could maybe better be a '?'. There is also a 'onMouseOver' hint when you go > over > the '.'. Hi Paul, Sorry for being so late. As a quick note, onMouseOver should contain JavaScript code, not a freeform string. Isn't the title attribute enough? -- Regards, Feri.
Re: Visualizing skip on test.winehq.org (and getting rid of visible desktop border)
Paul Vriens <[EMAIL PROTECTED]> writes: > My idea is to visualize the skipped tests by using the blue border > at the single test level to indicate tests are skipped. Hey, I like it! That blue border was already obsolete when I last touched the code, but I found it so neat that I couldn't kill it off. ;) -- Feri.
Re: [winetest] Make sure we can send larger files
Paul Vriens <[EMAIL PROTECTED]> writes: > On Thu, 2006-11-30 at 13:11 -0500, Dimi Paun wrote: > >> On Thu, November 30, 2006 1:01 pm, Paul Vriens wrote: >> >>> I'm hitting the 1MB limit already with my win98 tests. Most other tests >>> are about to reach that threshold as well. >> >> I'd make it 2MB, what's 1MB these days... :) > > the sending side is OK now. The receiving side has to be changed as well > I think. I get an error on my Win98 box. > > Any ideas? Yes, at the top of winetest.cgi you should find the following line: $CGI::POST_MAX = 1024 * 1025; (ie. receive a little more than 1M). Change that accordingly. This file can be found in :pserver:[EMAIL PROTECTED]:2401/home/wine/tools/winetest, but I didn't follow the GIT transition. -- Regards, Feri.
Re: comctl32: Fix loading string from resources
Alexandre Julliard <[EMAIL PROTECTED]> writes:
> Thomas Weidenmueller <[EMAIL PROTECTED]> writes:
>
>> LoadString() cannot be used to measure the length of a string resource.
>> It will not return the length of the string if no buffer is provided,
>> instead it will return 0! This patch fixes the broken property sheet code.
>
> Since you are going to the trouble of loading it all by hand, you
> should allocate and fill the buffer right away, instead of returning
> only the length and letting LoadString do the whole thing once again.
>
> Also a test case for LoadString demonstrating that the current
> behavior is wrong would be a good idea.
At first sight it's a simple matter of extending the
resource test (user dll) by adding {0, 0} to the test
variable. At second sight creation of a new test is needed,
as the current one tests LoadStringA only... Anyway, you
can use that as a template.
--
Feri.
[comp.emulators.ms-windows.wine] compile error with today's cvs
FYI: From: "Eike Lantzsch, ZP6CGE" <[EMAIL PROTECTED]> Date: Wed, 13 Jul 2005 11:59:36 -0400 Message-ID: <[EMAIL PROTECTED]> I get errors when compiling current cvs. .../wine# /wine/dlls/crypt32/tests/main.c:148: undefined reference to `CertFindAttribute' .../wine/dlls/crypt32/tests/encode.c:541: undefined reference to `CryptDecodeObjectEx' I'm trying on Debian Sid with stock 2.6.11 kernel. Am I missing some kernel headers? -- Feri.
Re: Hierarchical namespace for tests
Paul Millar <[EMAIL PROTECTED]> writes: > On Monday 25 April 2005 16:18, Alexandre Julliard wrote: > >> Paul Millar <[EMAIL PROTECTED]> writes: >> >>> Hopefully not a controversial one [...] >> >> The problem with this is that the result is not a valid path, which >> breaks tools that parse the output to let you jump to the error, >> like emacs compile mode. > > OK, I didn't realise people were automatically passing these strings. > > In principle, one can reconstruct the path from the test-name by > sticking "dlls" and "tests" in the right places. > > Presumably emacs (or whatever) can be taught these tricks, so one > could display the tests as "ole32%moniker.c:123" (just to avoid the > "/" character) and have emacs link to > "dlls/ole32/tests/moniker.c:123" > > Alternatively, we can store the full path and have the test name-space > coincident with the filesystem, which is the simplest but (slightly > wasteful) solution. > > What would people prefer? I'd prefer you don't break tools/winetest/dissect, which matches on the closing line. :) The change is trivial but essential for the winetest web summaries. -- Thanks, Feri.
Fwd: Wine install fails on Gentoo with `SYS_sigaction' undeclared
Hi, I think this message better fits here on the devel list. Cheers, Feri. Start of forwarded message From: "Jonathan Duncan" <[EMAIL PROTECTED]> Newsgroups: comp.emulators.ms-windows.wine Date: 25 Mar 2005 10:26:46 -0800 Message-ID: <[EMAIL PROTECTED]> I downloaded "Wine-20050310.tar.gz" Untar/zipped it. Entered the directory "wine-20050310" Typed "./configure" -> Success Typed "make depend" -> Success Typed "make" -> The following is the last of the make process: - gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o server.o server.c gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o signal_i386.o signal_i386.c signal_i386.c: In function `wine_sigaction': signal_i386.c:114: error: `SYS_sigaction' undeclared (first use in this function) signal_i386.c:114: error: (Each undeclared identifier is reported only once signal_i386.c:114: error: for each function it appears in.) make[2]: *** [signal_i386.o] Error 1 make[2]: Leaving directory `/home/jduncan/downloads/wine-20050310/dlls/ntdll' make[1]: *** [ntdll] Error 2 make[1]: Leaving directory `/home/jduncan/downloads/wine-20050310/dlls' make: *** [dlls] Error 2 - I have tried this as a regualar user and as root. I have tried "./tools/wineinstall". I have tried "make distclean" and then reinstalling. I have tried deleting and recreating the install directory. I am using Gentoo with a linux kernel of 2.6.10 on a dual-Xeon 3.2ghz 64-bit system. Any other ideas would be helpful. Thank you. End of forwarded message
Re: winetest: code reorder
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > "Ferenc Wagner" <[EMAIL PROTECTED]> wrote: > >> The -s option (submit file, do not run tests) makes sense >> anyway. But my main reason is that it drove me mad by not >> obeying the -c option (no GUI) in some test runs. And I >> don't think it hurts or contradicts your aims. > > I'd prefer to deprecate running winetest in any other mode > except of on a visible desktop in order to avoid > confusion. There are no two different modes. It's doing tests on a visible desktop only. > Again, there is no point in running it in 2 different > modes if all you just want to do is to send the test > results you've got by running winetest in interactive mode > 2 minutes ago. This feature was explicitly requested to get around proxies and such. The point is: the method of operation (GUI, console, quiet) should be taken into account already when displaying the error message about desktop visibility. It matters when you drive winetest from another program. I strongly believe that the intended functionality of the moved lines is totally preserved by this patch. If it's not the case, then I made a mistake and would be happy if you pointed it out. I just don't understand your concerns... -- Feri.
Re: winetest: code reorder
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > "Ferenc Wagner" <[EMAIL PROTECTED]> wrote: > >> ChangeLog: Check desktop visibility after processing command >>line arguments. > > Why do you need it? There is no point to proceed if the > tests can not run in an appropriate environment. The -s option (submit file, do not run tests) makes sense anyway. But my main reason is that it drove me mad by not obeying the -c option (no GUI) in some test runs. And I don't think it hurts or contradicts your aims. -- Feri.
Re: saving winrash
Ivan Leo Puoti <[EMAIL PROTECTED]> writes: > Recently winetest is leaving a testdir directory behind > it, so cleanup needs to be done better. This testdir comes from dlls/shell32/tests/shlfolder.c; RemoveDirectoryA in line 78 can fail somehow. Also, the return in line 147 doesn't do the necessary cleanup after CreateFileFolders() in line 144. Having no Windows is really a drag when fixing conformance tests... Btw I'm adding a tag entry dialog to winetest. But not sure if it can delete itself any way... -- Feri.
Re: [WINEALSA] multiple sound card support patch review needed
Paul van Schayck <[EMAIL PROTECTED]> writes: > On Tue, 22 Mar 2005 09:52:13 -0500, Robert Reif <[EMAIL PROTECTED]> wrote: > >> What happens when you have two or more identical cards. >> Should we also look for dmix in the device name? > > I think we should always look for hw:n I doubt it. First, ALSA have notion of the default device, which Wine should respect. On the other hand, using the hw:n device relies on a hardware mixer for sharing the sound card, which some widespread integrated cards don't have. So a lot of users would prefer using plughw:n (or another dmixed device) instead. The ALSA default can be set in ~/.asoundrc or by environmental variables, which is very convenient. Wine shouldn't behave differently unless explicitly configured so. > Doesn't ALSA have some kind of function to discover all devices? Probably not at the moment (except for /proc/asound/cards etc.) It was discussed on the ALSA devel list recently, but I don't remember the conclusions. -- Feri.
Re: winetest, winrash and new volunteers
Steven Edwards <[EMAIL PROTECTED]> writes:
> Like how to get winetest and the server to talk to each
> other and what is needed in the build and url files.
programs/winetest/README contains some relevant information.
> Is there some good documentation on how winrash and
> winetest work and communicate with the server? I am
> interested it in using it as part of the ReactOS build
> system.
Winetest sends back a single file to winetest.cgi, the one
which is linked from the summary page (report).
service.cgi is pretty much a mystery for me, too. Let me
offer these hunks containing some of my experiences. Be
careful with submitting requests to service.cgi, I strongly
suspect that it's easy to nuke the whole database with an
empty $publisher or $build...
Index: winetest/service.cgi
===
RCS file: /home/wine/tools/winetest/service.cgi,v
retrieving revision 1.24
diff -u -r1.24 service.cgi
--- winetest/service.cgi14 Jul 2004 18:33:47 - 1.24
+++ winetest/service.cgi16 Mar 2005 23:41:45 -
@@ -29,7 +29,7 @@
#
# We rely on the server to have directories available for every
# program that can be published. For example, we need a winetest directory:
-# winetest/
+# $data_root/$publisher/winetest/
#.urlcontains url to find latest winetests at, must
be
# writable
#url.mask contains a reg ex to match against, only needs to
@@ -112,6 +113,7 @@
# removes the current release from disk
sub releases_purge {
my ($project) = @_;
+# FIXME remove files of ALL publishers? Too easy to get here!
system("rm -f $data_root/*/$project/*.cookie");
system("rm -f $data_root/*/$project/*.url");
}
@@ -179,6 +182,7 @@
# FIXME: maybe we should check here that $build is sane
# test if this is a valid publisher
+# FIXME empty $publisher passes!
if (opendir(IMD, "$data_root/$publisher/")) {
closedir(IMD);
} else {
@@ -193,6 +198,7 @@
return "Build is old, current build is $current_build";
}
if ($build ne $current_build) {
+# FIXME this is VERY dangerous without $build sanitizing.
releases_purge is broken, too.
&releases_purge($program);
}
@@ -208,6 +214,7 @@
$cookie = &read_one_line("$lynx -source $url.sig |");
# all is good, store the cookie, and URL now, this activetes the release
+# FIXME isn't $cookie a binary fingerprint already?
&write_file(">$base_path/$name.cookie", &md5sum($cookie));
&write_file(">$base_path/$name.url", $url);
&write_file(">>$data_root/$program.builds", $build);
--
HTH,
Feri.
Re: Use IsWindowVisible instead of GetWindowLong(GWL_STYLE) & WS_VISIBLE as a test for desktop visibility
Dmitry Timoshkov <[EMAIL PROTECTED]> writes: > let's see if IsWindowVisible() better detects a not visible desktop. Ah, fine, this may put some momentum into the situation! -- Feri.
Re: vartest.c - major pain in the build process
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > "Ivan Leo Puoti" <[EMAIL PROTECTED]> wrote: > >>> In order to see what tests are affected by desktop visibility and which >>> don't >>> you have to run in both modes and compare the results. Why do it twice if it >>> can be avoided? Right now any failure in the tests can be attributed to the >>> desktop visibility, and until it's fixed nobody is going to fix the tests. >> >> You should email the guy who maintains winrash :-) > > First of all that should be a collective request, not just > a single voice in the dark. Yours may be a single voice, but definitely not in the dark, I hope. Even if I'm a little dense sometimes. > And I believe it should be a Wine test site maintainers > responsibility (it's WineHQ web space after all), winrash > has no direct relationship to Wine development since it's > not in the Wine CVS. Yes, it's a problem, I find it pretty hard to understand some corners of winrash. But it's mainly that installer thingie, not the core functionality... Back to the point, having no way to reliably determine desktop visibility there's not much I (or even winetest) can do to effect this. It's winrash we have to change, I'm afraid. -- Feri.
Re: invisible desktops - major pain in the testing process
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > "Ferenc Wagner" <[EMAIL PROTECTED]> 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.
Re: vartest.c - major pain in the build process
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
> I'd actually rise the question of sending the results of running winetest
> on an invisible desktop under Windows. For instance I'm interested to see
> how my recently added user32 tests behave on different Windows platforms,
> but the tests which currently present on http://test.winehq.org/data are
> completely unusable. I strongly ask to stop posing tests running on an
> invisible desktop and consider that tests broken, since almost all win32
> APIs are influenced by the fact of running in that environment. Moreover,
> Wine doesn't run in that mode at all, so we can't compare apples to apples
> in that case. And the apps most of the developers/users care about should be
> run on a visible desktop anyway.
I was under the impression that most of the tests are
independent of desktop visibility. And the winrash service
is the only way to get several reports quickly for a new
test. If it wasn't automatic, it would take a good while
until the tests are run. So I wanted to keep the best of
both ways by introducing a new flag according to your
recommendation:
static int running_on_visible_desktop ()
{
return (GetWindowLongA (GetDesktopWindow (), GWL_STYLE) & WS_VISIBLE) != 0;
}
Looks like it doesn't quite work, though: it returns 1 all
the time under Win9x and NT. Can you perhaps tell why?
--
Feri.
Re: winetest on wine and todo_wine
Paul Vriens <[EMAIL PROTECTED]> writes: > in shlwapi/tests/shreg.c I've put two todo_wine statements > for obvious reasons (they fail, so do not test). > > If I however look at > http://test.winehq.org/data/200502101000/wine_98/shlwapi:shreg.txt > > These tests are executed! Any ideas what could be wrong? Yep. Winetest resets all environmental variables influencing the tests unless the -e option is given. It is to provide a consistent environment for the tests, like tuning verbosity and going noninteractive. I'm not sure what happens if WINETEST_PLATFORM or the others are simply unset; you are welcome to persuade me or change the code. -- Feri.
Re: Broken cross-build, again.
>>> If I run winetest-200502091000-paul-mingw manually on my win98 box >>> I get several messages "Can't parse subtests output of" for the >>> following tests [...] >>> just before the tests actually start. In the first round winetest runs all the individual test executables to find out the names of subtests they contain. In case of a failure it obiously has no way to run those tests, so they are skipped. You have the freedom the run the problematic executables manually and find out more. Winetest could be massaged to include the unparsable output in the report, but it didn't seem worth it, as most of the time it means that the test doesn't apply for the given system (no such DLL installed). -- Feri.
Re: [WINETEST] How is a visible desktop detected
Paul Vriens <[EMAIL PROTECTED]> writes:
> I have a Win98/WNT/W2K (on VMWare) and a XP Home
> system. All are running the winrash service. All were
> started when I was logged in but only the W98 and WNT were
> considered running on a visible desktop.
Hmm, services use an invisible desktop by default AFAIK.
It shouldn't matter how you started winrash (the service),
but how you started winetest itself. If it's started by
winrash, it runs on an invisible desktop; if you start it,
it runs on a visible desktop.
It's either buggy or misnamed, reality suggests. It was
invented to account for metafile test failures, which
require a visible desktop, see eg.
http://test.winehq.org/data/200501271000/nt4_IvanLeo/gdi32:metafile.txt
Now it looks it depends on something else instead, and you
are in a pretty good position to find out what! I haven't
got a clue, including this flag was suggested by others.
> What's the criteria for 'running on a visible desktop'?
programs/winetest/main.c (as offered by Dmitry Timoshkov):
static int running_on_visible_desktop ()
{
return (GetWindowLongA (GetDesktopWindow (), GWL_STYLE) & WS_VISIBLE != 0);
}
--
Feri.
Re: gdi32 test failing
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > "Jakob Eriksson" <[EMAIL PROTECTED]> wrote: > >> http://test.winehq.org/data/200501151000/2000_JakobEriksson/gdi32:metafile.txt >> >> This fails. It shouldn't, because I ran winetest manually. >> >> http://test.winehq.org/data/200501151000/2000_JakobEriksson/version.txt >> >> >> what's up with that? > > The test still passes for me under win2k SP4. You have to investigate > what's going on. Although I'm compiling the metafile test separately > using my small test environment, that should not change anything for > the test itself. It passes under XP, too. (submitted) -- Feri.
Re: No new tests since 01/15/2005 ?
Paul Millar <[EMAIL PROTECTED]> writes: > I've been a bit busy lately so haven't gotten around to > fixing it, but should have some spare time tonight, > fingers crossed ;) Hey, you did it! Thanks very much! As a side note, the shell32:shlfolder test leaves an empty testdir directory around when run under XP. I tried to trace it, but suddenly it ceased to do so... Does anybody else experience this? -- Feri.
Re: tests
Ivan Leo Puoti <[EMAIL PROTECTED]> writes: >> Do you mean that the tagless report was generated by a >> manual run while the one with the IvanLeo tag was run by >> winrash? > > Yes, those reports were both generated from the same > winetest binary. I'm not sure of what you mean by > crosschecks, but I'll do whatever can help, just let me > know what I should do. Well, you could find out why the quoted code snippet doesn't work on NT, and possibly suggest a better test... It was recommended by Dimitry, btw. (cc'd) -- Feri.
Re: Exiting a tests on the first failure
Paul Vriens <[EMAIL PROTECTED]> writes:
> If the first CreateKey fails, there is no need to continue with the
> testing (because the rest of the tests will fail as well). What's the
> best way to stop there?, something like this?:
>
> START_TEST(shreg)
> {
> HKEY hkey = create_test_entries();
> +if (!hkey) return;
Looks fine for me, given that in wine/test.h we have
#define START_TEST(name) void func_##name(void)
--
Feri.
Re: more tests for tests.winehq.org
Stefan Leichter <[EMAIL PROTECTED]> writes: > now we have fixed mingw to build the new test. So perform them after > building ;-) > > ChangeLog > --- > Include new tests Thanks for your work and attention! -- Feri.
Re: WineHQ:winetest: produce valid HTML
Jakob Eriksson <[EMAIL PROTECTED]> writes: > Ferenc Wagner wrote: > >> What makes you think I've got one? It should be *you* >> who speak up and tell what information/presentation is >> need for the best and easiest use. > > I would prefer to have all failed tests at the top, so one > could see easily which ones need to be fixed. Not being an addition but a change, I'd like to hear others' opinion on this matter. My personal feeling is that losing alphabetical ordering on test names isn't worth it, as color monitors are fairly common nowadays. So vote for the change! > It would also be nice if the author of a test got an email > whenever a test failed. Finding out the author of a test isn't easy, it requires some digging into CVS. On the other hand, I'd choose an opt-in method instead. But it's a separate project anyway, the present machinery has pretty much nothing to facilitate this. The summary.txt files are easy to parse and available by HTTP, so one could use them to get the figures. -- Feri.
Re: tests
Ivan Leo Puoti <[EMAIL PROTECTED]> writes:
> I've run tests twice, once with winrash and once manually, on windows nt 4.0
> http://test.winehq.com/data/200501131000/#NT%204
> interestingly some tests that fail or timeout when run from winrash,
> work when
> run manually.
> Is there a way this could be fixed, or should we at least somehow mark tests
> that give different results when run with winrash or manually?
Do you mean that the tagless report was generated by a
manual run while the one with the IvanLeo tag was run by
winrash? That's strange, since the blue strip should only
be present when bRunningOnVisibleDesktop is true in the test
headers. And it's true in both cases. Here is the origin
of that flag (from winetest/main.c)
static int running_on_visible_desktop ()
{
return (GetWindowLongA (GetDesktopWindow (), GWL_STYLE) & WS_VISIBLE != 0);
}
Seems like it doesn't work properly. Can you perhaps do
some crosschecks? I'll also look into this later today.
--
Feri.
Fwd: Photoshop on amd64
Hi, I'm forwarding this messages from the users' newsgroup. Have you gurus got an idea? --- Begin Message --- Has anyone had any success running Photoshop 7 on an AMD 64bit system? I have a SuSE 9.1 64bit installation (amd64 3500+ and 2GB dual-channel RAM) and have sucessfully installed Photoshop 7 using both Wine and Crossover Office (idenitcal behaviour). However, when I start Photoshop, it goes through the intializing process and then says "Measuring memory". At this point it throws a "Could not intialize Photoshop because of a program error" message. Clicking on "OK" ends the program. Other apps such as MS Office 2k or Photoshop Image ready install and work fine. I have also installed the 32bit version of SuSE 9.1 on this machine and Photoshop runs fine in that case. Is there some difference in the way RAM is being reported? --- End Message ---
Re: WineHQ:winetest: produce valid HTML
Paul Millar <[EMAIL PROTECTED]> writes: > As a shot in the dark, have you got either ECN set, or a non-zero > default window-scaling? Which kernel are you running? > > cat /proc/sys/net/ipv4/tcp_ecn This gives 1 for me (and I can access your pages). > cat /proc/sys/net/ipv4/tcp_default_win_scale This is 0. One more thing to try is tcptraceroute: $ /usr/sbin/tcptraceroute www.astro.gla.ac.uk 80 Selected device eth0, address 157.181.170.74, port 41886 for outgoing packets Tracing the path to www.astro.gla.ac.uk (130.209.45.194) on TCP port 80, 30 hops max [...] 15 po3-0.warr-scr.ja.net (146.97.33.54) 45.120 ms 44.988 ms 45.036 ms 16 po2-0.glas-scr.ja.net (146.97.33.58) 49.367 ms 49.226 ms 49.186 ms 17 po0-0.glasgow-bar.ja.net (146.97.35.54) 49.115 ms 49.114 ms 49.057 ms 18 146.97.40.106 (146.97.40.106) 49.504 ms 50.188 ms 49.472 ms 19 130.209.2.117 (130.209.2.117) 49.783 ms 50.823 ms 49.629 ms 20 130.209.2.2 (130.209.2.2) 49.744 ms 49.599 ms 49.957 ms 21 terra.astro.gla.ac.uk (130.209.45.194) [open] 49.644 ms * * The interesting part may be filtered, but it was able to contact terra at port 80. -- Feri.
Re: WineHQ:winetest: produce valid HTML
Paul Millar <[EMAIL PROTECTED]> writes: > On Wednesday 12 January 2005 20:09, Stefan Leichter wrote: > >> Am Mittwoch, 12. Januar 2005 18:14 schrieb Dimitrie O. Paun: >> >>> Anyone knows what happened to the tests? >> >> [...] The attached patch fixes mingw for me. Hope i got the GUIDs >> right. > > Should be up tomorrow, all things being equal (and a following > wind ;^) Good work, guys! -- Thanks, Feri.
Re: WineHQ:winetest: produce valid HTML
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > For reasons I can not understand, I can not access Paul's > site at www.astro.gla.ac.uk Can't you even ping the server? If not, what does traceroute say? If yes, your IP number must be blacklisted at Glasgow... ;) -- Feri.
Re: WineHQ:winetest: produce valid HTML
Mike Hearn <[EMAIL PROTECTED]> writes: > On Wed, 12 Jan 2005 22:26:18 +0100, Ferenc Wagner wrote: > >> What makes you think I've got one? It should be *you* >> who speak up and tell what information/presentation is >> need for the best and easiest use. > > I basically did: some UI for test.winehq.com to let you > easily navigate the available builds. In the works (Jer?) What kind of navigation would you prefer? Is forward/backward and a directory list (like flashy PHP frontend) enough? Do you want such buttons scattered on the page? A directory button, perhaps? Web design is surely not my strength... > Also clicking on the info/name links gives a 404 right now > in many cases, so ... Yes, that's the effect of putting new skin on an old body: old submissions simply don't have that information available separately. Tests submitted and processed after the commit (not more than two so far, I think) don't have this problem. I didn't want to complicate the code with conditionaly emitting the links; those tests are old and of limited interest only. Hope we'll get new binaries soon. > just making it feel more like a full website and some > extra polish really :) D'oh, aesthetics... ;) -- Feri.
Re: WineHQ:winetest: produce valid HTML
Mike Hearn <[EMAIL PROTECTED]> writes: > On Wed, 12 Jan 2005 17:29:18 +0100, Ferenc Wagner wrote: > >> ChangeLog: * Generate valid HTML 4.01 Strict. >>* Underline vis_note class links, too. > > Groovy! Is there a todo list of what needs to be done for > winetest anywhere? I've got one myself, but keep it secret, of course. Still I can tell the only item of real interest is adding a Tag input field to the binary, which was brought forward by the apparent need of interactive and visible runs. > Going to http://test.winehq.com/ still yields an error, > you have to know the magic URL and then navigate the > builds manually. Ok, perhaps I can give out the classified URL: http://test.winehq.org/data/ Yes, you have to navigate manually (the links on the top don't work), but I've got Jeremy Newmann's word on knocking something up by yesterday. That something includes making those links work at least. > It'd be nice to get some pretty HTML frontend to that > going: a task for somebody who is keen but doesn't want to > hack Wine itself maybe? Yes, unless Jer has actually done it. Turning it into a template would also be possible, but I'm not too keen on it as that would steal real screen estate. But would be a nice touch, for sure. > Could you elaborate your plan for winetest Feri? What makes you think I've got one? It should be *you* who speak up and tell what information/presentation is need for the best and easiest use. -- Yours, Feri.
Re: WineHQ:winetest: produce valid HTML
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > On Wed, Jan 12, 2005 at 05:29:18PM +0100, Ferenc Wagner wrote: > >> ChangeLog: * Generate valid HTML 4.01 Strict. >>* Underline vis_note class links, too. > > Cool stuff Feri. Anyone knows what happened to the tests? > The last one at http://test.winehq.org/data/ is 2004-12-28. > Also, the last tests build at SF is winetest-200409111000 > which is a bit outdated :) Yes, looks like Kevin had to give up on cross building the binaries a couple of months ago; it was he who updated the SF downloads page. Paul Millar, however, kept up with the load until the new GUIDs broke MinGW again. We already talked about the issue and Hans Leidekker also confirmed the MinGW problem, but hasn't got around to provide a patch yet. If Paul can use Stefan's patch, then new builds can be expected real soon, I guess. -- Feri.
Re: RC file translation via winehq?
Mike McCormack <[EMAIL PROTECTED]> writes: > How hard to you think it would be to rig up a web page for > people to do translations for wine on? > > Have a web page (translate.winehq.org?) into which we feed > in all the .rc files and maybe even parts of WineHQ, and > show the translations for each language and bits that are > missing ... then accumulate all the bits of translation > somehow so they can be sumbitted back to wine-patches. Others have already solved similar problems: http://translate.sourceforge.net/doc/tools-online_editors.html These tools are usually .po centric, but may still be useful. -- Feri.
Re: another build problem on current cvs
Vincent Béron <[EMAIL PROTECTED]> writes: > Le mer 29/12/2004 à 05:38, Joris Huizer a écrit : > >> In debian the package is called libasound2-dev, version >> "0.9.0beta10.9.0beta1" which should be the 0.9 branch of alsa > > Either update to alsa 1.0, downgrade Wine to prior > 20040505, or switch to the wineoss driver. For Debian stable I've got some unofficial ALSA packages (among others) at http://afavant.elte.hu/~wferi/debian/ which may come handy. -- Feri.
Re: tests: add more listbox tests
Mike Hearn <[EMAIL PROTECTED]> writes:
> On Thu, 23 Dec 2004 17:01:09 +0200, Lauri Tulmin wrote:
>
>> Add tests for LBS_EXTENDEDSE and LBS_EXTENDEDSEL | LBS_MULTIPLESEL
>> listboxes. Some of these test don't pass on wine.
>
> Thanks for the tests! If they don't pass in Wine though you need to
> surround them in todo_wine {} blocks, or ideally fix them.
Actually (not ideally) you should just stick 1's into the
appropriate TODO fields.
--
Feri.
Re: Make winetest.exe detect if it is running on a visible desktop. Now without the linewrap.
Jakob Eriksson <[EMAIL PROTECTED]> writes: > Now without the linewrap. I hate to say this, but it's still wrapped... :( -- Feri.
Re: Wine test suite (or winrash, don't know which one) - possible way to improve for some persons (with some antivirus or firewall software running)
Tero Tamminen <[EMAIL PROTECTED]> writes: >> Yes. But will sticking to a fixed directory name (and >> possibly file name) help, or does ZoneAlarm check eg. MD5 >> sums to thwart any countermeasure from our side? Anyway, >> I have the feeling that this should be solved by >> configuring ZoneAlarm instead of throwing in kludges. >> Don't you know if it's possible to disable this warning >> for an application or a directory? > > Actually ZoneAlarm checks MD5 or some other checksum, but > it can also be configured so, that it doesn't care about > those. Fine, so far. This is absolutely needed, no way around. > There is option where I can specify that "Athenticate > program by full path name only"... name says all I see, thanks for the info. > Zonealarm only sees that, these programs are launcehd from > different directory, I will put in a "try this first" directory name, and fall back to "random" names if creating that fails. > they have different checksum, We can't help this, but it shouldn't pose a problem, right? > wine-test-whatever executable has different name (because > date is part of the name), We can change this, too. > At least to my knowledge ZoneAlarm can't be configured > with wildcards, so that it would check only part of the > executable name. What a shame. We'll have to go the "hard" way then. > But anyway, it is okay to me if you don't want to program > temp directories not to be random, I just have to disable > winrash and thus winetests from my win2k3 server. What would be a shame again, we aren't particularly overwhelmed with Win2k3 testers. Hope we can sort it out. In the meantime just disable winrash if it's too disturbing, I'll drop you a note once the necessary changes are in place. -- Regards, Feri.
Re: Wine test suite (or winrash, don't know which one) - possible way to improve for some persons (with some antivirus or firewall software running)
Vincent Béron <[EMAIL PROTECTED]> writes: > Le ven 10/12/2004 à 07:26, Francois Gouget a écrit : >> On Fri, 10 Dec 2004, Ferenc Wagner wrote: >> >> > Francois Gouget <[EMAIL PROTECTED]> writes: >> [...] >> >> I've had some dealings with ZoneAlarm and I thought it >> >> also saved an md5 checksum of the executable. >> > >> > Yes, please clear this issue up for me! After some >> > discussion on IRC I almost started changing the code :) >> > Also, can't ZoneAlarm use wildcards perhaps? I couldn't >> > find out from the webpage... >> >> Well... this is not on a machine I have access to. What you could do is >> take an old verion of one of Wine's conformance tests (wininet should >> do) that accesses the net, run it and configure ZoneAlarm to let it >> through, then download a newer version and put it in exactly the same >> place and try again. I strongly suspect that ZoneAlarm is going to ask >> you again. > > Newer ZoneAlarm don't only warn on accessing the network but also on > launching unknown applications. So merely launching winetests (which > launches the other .exe itself via CreateProcess) will get the question > to let it run or not asked, in part because the path to the test changes > with each release (the temp dir name is random). Yes. But will sticking to a fixed directory name (and possibly file name) help, or does ZoneAlarm check eg. MD5 sums to thwart any countermeasure from our side? Anyway, I have the feeling that this should be solved by configuring ZoneAlarm instead of throwing in kludges. Don't you know if it's possible to disable this warning for an application or a directory? -- Feri.
Re: Wine test suite (or winrash, don't know which one) - possible way to improve for some persons (with some antivirus or firewall software running)
Francois Gouget <[EMAIL PROTECTED]> writes: > On Thu, 9 Dec 2004, Tero Tamminen wrote: > [...] >> So would it be possible to start all the tests from same >> directory (I mean, every version of the tests would start >> in same directory). It would save me some time because I >> wouldn't have to click through all the messages. > > I've had some dealings with ZoneAlarm and I thought it > also saved an md5 checksum of the executable. Yes, please clear this issue up for me! After some discussion on IRC I almost started changing the code :) Also, can't ZoneAlarm use wildcards perhaps? I couldn't find out from the webpage... -- Feri.
Re: No more winrash?
Jakob Eriksson <[EMAIL PROTECTED]> writes: > Do you agree, should we stop using winrash? > > "Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote: > >> "Jakob Eriksson" <[EMAIL PROTECTED]> wrote: >> >>> Well, I tried now marking the service as interactive, >>> but that didn't make any difference. >>> >>> So, what follows, deprecate Winrash? >> >> If it really breaks the tests then definitely yes. I think it does provide much useful information which would be largely lost if we resorted to manual testing. What's more, winetest is not really up to that, as it doesn't ask for a tag but relies on a command line option which people would tend to forget. What I propose: make winetest detect whether it's running on an interactive desktop or not, and include this info in the header just like bRunningUnderWine. Meanwhile add the tag dialog to winetest and separate or mark the different reports on the webpage for easier reference. That would bring us the best of both worlds. Or possibly tweak the sensitive tests (how many are there?) to make clear in the output that they were not run for this reason... That would probably require a new field in the final report (ie. success-failure-todo-skipped or similar). This could also signal WINETEST_INTERACTIVE tests so that they aren't forgotten about... That said, I don't know much of this desktop business, so I'm not sure how to put the detection logic in. The rest should not be hard, I hope I'll find the time for them if we decide to go this way. -- Feri.
Re: automatic tests screwed up again
Paul Millar <[EMAIL PROTECTED]> writes: > All things being equal tomorrow's build (presuming they'll > be one) will include binaries that refer to themselves > correctly. Looks like you got it right. Thank you very much! -- Feri.
Re: automatic tests screwed up again
"Ivan Leo Puoti" <[EMAIL PROTECTED]> writes: > In the reports page the link to the tests points to > http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/winetest-200411251000.exe > and this is probably what the server tells winrash to > download, but it returns a 404. As things mostly work it's probably not the case. > The test actually is at > http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/winetest-200411251000-paul-mingw.exe > can someone please fix this? Paul, could you please fix your tests.url (or the script generating it)? -- Thanks, Feri.
Re: [test.winehq.org] summary broken
Stefan Leichter <[EMAIL PROTECTED]> writes: > The main summary shows that the tests winspool.drv:info > fails sometimes on the platform win2k, but in the summary > of win2k (2000 differences) the line winspool.drv:info is > not listed. Yep, the display logic is quite simple and broken, although this kind of brokennes is new for me. I'll look into this particular problem, since it's rather annoying. Until then you can type in the URLs by hand (they should be easy to guess) or scroll down in the full reports. Btw new ideas about the format as well as the content of those pages are welcome: the people using it should tell (and not necessarily do :) -- Feri.
Re: dlls/winmm/tests/capture.c - yes, we can open a device in 2MHz...
Robert Reif <[EMAIL PROTECTED]> writes: >> Winetest has a "runningunderwine" report option. Running >> it under Wine will be supported. > > winetest results from wine are not accepted by the website. Yes they are. Just make dist. > To be really useful as a developer tool, you would need wine > specific information like the os/distribution version, sound library > type and version and the wine version (with cvs patch info if > not a standard release). CVS revision numbers are available, but nothing else you ask for. If you send me some blobs of code to detect what you need, I'm willing to help integrate it, provided it also runs under Windows. -- Feri.
Re: Fix for metafile test
Jakob Eriksson <[EMAIL PROTECTED]> writes: > Dmitry Timoshkov wrote: > >> "Ferenc Wagner" <[EMAIL PROTECTED]> wrote: >> >>> Winrash, which invokes winetest in most of the cases, is a >>> service process running on an invisible desktop. Winetest >>> itself can happily run on the real visible desktop, it's >>> just people seldom run it that way (ie. directly). >> >> Then we need either instruct people to not run the tests from >> the service or completely remove that possibility altogether. > > Or check the option to "allow service to interact with desktop". Is that a service option or what? I don't really know anything about Windows services. If you can fix this issue in winrash please do so. > But I'd rather see that as many tests as possible can be > run from the service as is. There are many APIs out there > which do not use a desktop and if we loose the winrash > testers we lose maybe 90% of the test reports. I really wonder what share of the reports come from winrash instances, but I don't think you underestimate it. Removing this possibility would hardly buy anything for us, but a flag similar to bRunningUnderWine could be added indeed. Just patch it into winetest or send me some code and I will do the gruntwork. -- Feri.
Re: Fix for metafile test
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > The question is what makes the tests create invisible > windows? Does winetest run as a service on a not visible > desktop? Anything else? Winrash, which invokes winetest in most of the cases, is a service process running on an invisible desktop. Winetest itself can happily run on the real visible desktop, it's just people seldom run it that way (ie. directly). -- Feri.
Re: winetest results refused when run by wine
Robert Reif <[EMAIL PROTECTED]> writes: > I would like to see winetest used for more than windows > compatibility and wine regressions. I would like to see it > used as a diagnostic tool for specific hardware and os > combinations and specific system configurations. [...] > > Since most people probably don't use sound or don't care > about it, we are not getting as much feedback as we could. > [...] It might even be interesting to optionally run > winetest at installation time so we can tell them that > what features of wine will and will not work on their > system as they currently have it configured. Do you mean you'd like to wade through the installation reports of every people installing Wine? How would you tell which report belongs to whom? Anyway, your business, but I think we shouldn't mix those reports with those of the offical test suites that test writers use for reference. What default values do you think would serve for this purpose? OTOH if you'd like to see winetest reports from somebody who complains, the -o option may come to your help, as you could ask for the log file mailed to you. But then you could as well do without winetest, of course. I suggest you come up with a concrete proposal we can discuss. Winetest is free software (and still incomplete), you can change it or have it changed; I'm willing to help out. -- Feri.
Re: winetest results refused when run by wine
Robert Reif <[EMAIL PROTECTED]> writes: >>> For the built in wine, run with wine case, couldn't there be >>> reasonable default values rather than reading them from a file? >> >> That's exactly what we wanted to avoid. Submitted results >> should * not come from Wine but genuine Windows systems, and >>* be identifiable. >> So we decided to require some (small, one time) effort of >> people providing test suites. For what you are doing, make >> test seems worth consideration. If I guessed correctly. :) > > [...] Why should winetest be restricted to windows only? Well, it isn't. It's just we'd like to see some identification on the data published on the webpage. Moreover, the processing scripts are not prepared for reports coming from Wine, which would lead to confusion. It wouldn't be hard to fix, though, the report contains this information, but it's not presented to the reader. So, just read the README in the source directory, create (and keep up to date) those pesky files and give it a go. But we'd rather not drown in unusable reports coming from people running every executable in the Wine tree, and that's the reason for not having defaults. We used to, btw. If I still miss your point, and you don't find it hopeless, please try to explain the difficulty you experience once more. -- Cheers, Feri.
Re: winetest results refused when run by wine
Robert Reif <[EMAIL PROTECTED]> writes: > Ferenc Wagner wrote: > >> Robert Reif <[EMAIL PROTECTED]> writes: >> >>> Couldn't winetest fill in the proper test results fields >>> necessary for acceptance when compiled to an exe.so and >>> run in wine? >> >> Did you make dist in programs/winetest? >> winetest-dist.exe is the program meant for submission, but >> winetest-dist.exe.so should be able to submit as well. > > make dist > make: *** No rule to make target `build.id', needed by `dist.res'. Stop. > > For the built in wine, run with wine case, couldn't there be > reasonable default values rather than reading them from a file? That's exactly what we wanted to avoid. Submitted results should * not come from Wine but genuine Windows systems, and * be identifiable. So we decided to require some (small, one time) effort of people providing test suites. For what you are doing, make test seems worth consideration. If I guessed correctly. :) -- Feri.
Re: winetest results refused when run by wine
Robert Reif <[EMAIL PROTECTED]> writes: > Couldn't winetest fill in the proper test results fields > necessary for acceptance when compiled to an exe.so and > run in wine? Did you make dist in programs/winetest? winetest-dist.exe is the program meant for submission, but winetest-dist.exe.so should be able to submit as well. However, its use is discouraged, as it would run under Wine only. Unfortunately, cross-building seems broken ATM. Kevin, Paul, can you comment on this? I remember Paul sending a report to wine-devel about a week ago, do we still suffer from the same problem? -- Feri.
Re: winetest fails enumerating test files
Saulius Krasuckas <[EMAIL PROTECTED]> writes: > It shows some message-box telling: "Can't enumerate test > files: 1813" I couldn't reproduce it. Can you provide details (elf/pe run, ...)? -- Feri.
Re: some console fixes (for ctrl-c handling)
Eric Pouech <[EMAIL PROTECTED]> writes: > ChangeLog: > - ctrl-c enabling flag is now inherited > - fixed console-related fields in RTL_USER_PROCESS_PARAMETERS > - various clean-up in kernel32.SetConsoleCtrlHandler > - only send a console event once to a process and not to all the process' > threads > [...] > +ok(GenerateConsoleCtrlEvent(CTRL_C_EVENT, 0), "Couldn't send ctrl-c event\n"); > +todo_wine ok(mch_count == 1, "Event isn't synchronous\n"); > +ok(WaitForSingleObject(mch_event, 3000) == WAIT_OBJECT_0, "event sending didn't > work\n"); > +CloseHandle(mch_event); > +ok(SetConsoleCtrlHandler(NULL, TRUE), "Couldn't turn off ctrl-c handling\n"); > +mch_event = CreateEventA(NULL, TRUE, FALSE, NULL); > +mch_count = 0; > +ok(GenerateConsoleCtrlEvent(CTRL_C_EVENT, 0), "Couldn't send ctrl-c event\n"); Hi Eric, these Ctrl-C events kill off winetest under XP. You probably did your tests and found this OK, so I'm not sure what to do. Can you offer a solution? I commented those two lines out, which made it go through... -- Thanks, Feri.
Re: Winrash / Winetest
"Stephen Ogletree" <[EMAIL PROTECTED]> writes: > (I sent a version of this to wine-users originally and Ivan said to > send it over here to wine-devel) Yes, it's better sent here. Thanks for the report and sorry for the long delay. It's still summer... > 0. Small issue: The winrash installer (NSIS) concludes with a window > that has 3 lines that are in blue text to suggest a hyperlink [...] I think the winrash maintainer got the message. > Since installing winrash didn't do anything except put the service in > place and start it, I figured I'd go ahead and download the test > manually. Well, the service should download and run new tests as they got published. Unfortunately there is some error on server side so it doesn't work as expected. We will eventually fix it and you dormant service process will start working in the background. > This rest of this email pertains to > /winetest-200407091000-kevin-mingw.exe/ Running the winetest suite manually present the user some interaction which is hidden when invoked by the service. > 1. I received the "Can't parse subtests output of msvcrtd" message > during 'extraction'. I assume this is the same error Holly reported. In your case it probably means that msvcrtd.dll isn't installed on your system. > 2. I had a message indicating a timeout during the user32 tests > (before the network tests - this appears to be the same message Holly > reported). Also, I remember the timeout was occurring back when we > first tried out this testing program a month or two (or 3?) ago, so > its a bug thats been around a while. Yes, it's a bug in the user32 input tests, which I haven't tried to fix yet, but introduced the timeout instead. Wrong tests will also emerge in the future, it's better to handle them than hang with them... > 3. I am still seeing an error that I pointed out in the first round > (or a long time ago, at least..) of testing where the test crashes > Explorer That was a deliberate kill, not a crash. It's excluded now as far as I know. > FWIW: When I agreed to submit my test results, I did *not* receive any > warning about my log being too big. That warning was removed, we silently truncate now... :) -- Best wishes and thanks for you help, Feri.
Re: winetest can't parse subtest for msvcrt(d)
Saulius Krasuckas <[EMAIL PROTECTED]> writes: > On 27 Aug 2004, Vincent Béron wrote: > >> Just redirecting it to glibc would be trivial, but the problem is that's >> not the Right Thing To Do (tm) as both don't have exactly the same >> behavior, and that some apps rely on the msvcrt behavior (ie, break when >> using glibc's). > > This part if fine. Now please tell me: why printing result of msvcrt* > tests should depend on the difference of this behaviour? I mean, why do > we need msvcrt functions to print information about the behaviour of > another msvcrt functions? I always used to thought this is extremely > uncorrelated stuff: > > 1, testing function of the lib; > 2, printing results of the test. > > Are both thingies hardly tied? Forgive my ignorance, but I am afraid I > won't be able to undrestand this just by digging in the Wine src. Thanks. You are absolutely right, these two things should have nothing to do to each other. On my part it's simply that I've got no idea how to make that distinction. Wine's testing framework (test.h) uses fprintf() to do its output. It usually means glibc's fprintf(), but in the msvcrt* tests in means that of msvcrt, since those tests are linked with -lmsvcrt explicitly before the implicit -lc for the very purpose of the tests. So it's pure technicality at this end (at the other it's the matter of fixing msvcrt to take glibc redirection into account), which I didn't care enough to find a way to fix. It would be trivial if all the test used LoadLibrary() and GetProcAddress() to access the functions they test instead of linking them in, but it's not the case, especially not with such common and widely available functions as fprintf() for example. Hope I got the explanation right and that it makes sense for you. We are humans, that's to say... And finally a couple of winetest todos: 1. Implement the Stop button, like eg. first wait for the current test, then force termination. 2. Add an option the extract the tests and stop. 3. Ask for a Tag in the GUI (defaulting to the one given on the command line). 4. Add HTTP proxy support. 5. Remove mystrtok(), which isn't needed anymore. Out of these 3. and 4. would be the most useful additions, but the show seems to be stopped on the server side, so I will work there first. -- Feri.
Re: winetest can't parse subtest for msvcrt(d)
Saulius Krasuckas <[EMAIL PROTECTED]> writes: > On Wed, 18 Aug 2004, Ferenc Wagner wrote: >> Saulius Krasuckas <[EMAIL PROTECTED]> writes: >>> I think that's due to some additional \r\n-s in the output >>> of "msvcrt_test.exe.so". >> >> Actually, not quite. The problem is that msvcrt's output >> functions aren't redirected by libc's filehandle operations, >> so winetest doesn't get the output (it gets printed to the >> screen instead). > > Oh.. :-/ > >> Yeah, it's annoying, but doesn't hurt the meant functionality of >> winetest, which shouldn't be run under Wine for anything but testing >> purposes. The native (Windows) run doesn't show this problem, since >> there we use msvcrt functions exclusively. Still it would be nice to >> fix, but the proper way would be to fix Wine, and that's not entirely >> trivial as Alexandre commented. > > Can you provide a link to the post or maybe some keywords to find it using > google? Thanks. Try this for example: http://search.gmane.org/search.php?query=redirect+winetest&email=&group=gmane.comp.emulators.wine.devel&sort=date If you can't help feeling like hacking on winetest, I can send you my todo list, too... :) Or maybe I should put it into the source so that innocent bycomers can see it... -- Cheers, Feri.
Re: winetest can't parse subtest for msvcrt(d)
Saulius Krasuckas <[EMAIL PROTECTED]> writes: > I think that's due to some additional \r\n-s in the output > of "msvcrt_test.exe.so". Actually, not quite. The problem is that msvcrt's output functions aren't redirected by libc's filehandle operations, so winetest doesn't get the output (it gets printed to the screen instead). Yeah, it's annoying, but doesn't hurt the meant functionality of winetest, which shouldn't be run under Wine for anything but testing purposes. The native (Windows) run doesn't show this problem, since there we use msvcrt functions exclusively. Still it would be nice to fix, but the proper way would be to fix Wine, and that's not entirely trivial as Alexandre commented. -- Cheers, Feri.
Re: "winetest" throws an exception after the unsuccessful send operation
> Is it OK to try to free the modified "buffer" ptr? I
> thought we should preserve its value.
Yes, you are right, that code is illegal. The wonderful
thing is that it's more than half a year old, and went
unnoticed this far! Probably because the WineHQ server
never failed during that period. Amazing. I wonder what
have happened to it now.
> We can use the "str" instead of the "buffer". I've tried
> such mod and it worked fine in my case:
Yes, your patch is good. Still I recommend something more,
as I can't see why buffer should be dynamic at all. Please
check it in case I made another mistake:
Index: programs/winetest/send.c
===
RCS file: /home/wine/wine/programs/winetest/send.c,v
retrieving revision 1.12
diff -u -r1.12 send.c
--- programs/winetest/send.c6 Jul 2004 21:03:22 - 1.12
+++ programs/winetest/send.c18 Aug 2004 11:26:02 -
@@ -107,7 +107,7 @@
SOCKET s;
FILE *f;
#define BUFLEN 8192
-unsigned char *buffer;
+unsigned char buffer[BUFLEN+1];
size_t bytes_read, total, filesize;
char *str;
int ret;
@@ -127,7 +127,6 @@
"Upload File\r\n"
"--" SEP "--\r\n";
-buffer = xmalloc (BUFLEN + 1);
s = open_http ("test.winehq.org");
if (s == INVALID_SOCKET) return 1;
@@ -209,17 +208,15 @@
if (ret) {
buffer[total] = 0;
str = strstr (buffer, "\r\n\r\n");
-if (str) buffer = str + 4;
+str = str ? str+4 : buffer;
report (R_ERROR, "Can't submit logfile '%s'. "
-"Server response: %s", name, buffer);
+"Server response: %s", name, str);
}
-free (buffer);
return ret;
abort2:
fclose (f);
abort1:
close_http (s);
-free (buffer);
return 1;
}
Thanks for the good spotting,
Feri.
Re: don't kill the destktop
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > "Ferenc Wagner" <[EMAIL PROTECTED]> wrote: > >> ChangeLog: The desktop process is not automatically >>restarted under Win95, so stop killing it. > > This patch causes test_shell_window tests fail under win2k SP4. > Please either fix the failures or revert the patch. Sorry, I didn't notice it was adding to the errors, I only aimed at keeping the desktop usable. Whatever those tests do, it's voodoo magic for me, so my fix could only be removing the test_shell_window tests. Not very creative, so I'd rather shut up. -- Feri.
Re: Windows Default Button Observations
Mike Hearn <[EMAIL PROTECTED]> writes: > On Sun, 15 Aug 2004 11:23:07 +0200, Ferenc Wagner wrote: > >> Once you remembered the current (possibly inactive) default >> button in DIALOGINFO, this should come for free. I hope at >> most one button can be default in a dialog... > > http://weblogs.asp.net/oldnewthing/archive/2004/08/02/205624.aspx > > I'm afraid it's possible for dialogs to have more than one > default button. No, there is no hope. :( This fancy feature is definitely worth supporting in Wine. Thanks for the correction. -- Cheers, Feri.
Re: Windows Default Button Observations
"Zach Gorman" <[EMAIL PROTECTED]> writes: > My impression is that (1) could be handled by remembering > the default button (which, as Krishna Murthy has shown, is > not the same as the default button id) in the DIALOGINFO > structure. > > Number (2), however, is more difficult. When a button > receives the capture, it can send a BM_SETSTATE to itself > easily enough to make itself a DEFPUSHBUTTON, but how does > it determine which other buttons to query and make > non-default as necessary? Once you remembered the current (possibly inactive) default button in DIALOGINFO, this should come for free. I hope at most one button can be default in a dialog... -- Feri.
Re: for whoever maintinas winrash
Chris Morgan <[EMAIL PROTECTED]> writes: >>> Also, during the installation process, after I entered >>> my email address, the installer removed what it called >>> 'invalid characters' - i.e., underscores. All my main >>> email addresses contain underscores, so I was forced to >>> enter an old one that is not very reliable. > > We could support underscores but Feri tells me that they > aren't supported by winetest so I strip them out both > during the install and when the email address is being used. > > Feri, anyway we can add support for underscores in > winetest and remove this requirement? Hmm, I suspect some misunderstanding here. I told winetest didn't allow underscores in the Tag (which is given by the -t option). On the other hand, winetest doesn't even know about email addresses, therefore it doesn't require anything in this respect. I will add support for them, and only require that they don't contain newline characters, ok? ;) -- Feri.
Re: WineHQ:service.cgi: fix winrash option
<[EMAIL PROTECTED]> writes: >>> http://osdn.dl.sourceforge.net/sourceforge/wine/winetest-200407091000-kevin-mingw.zip > > I just tried that url and it worked. Many of the ones > I've tried in the past haven't and the cause seems to be > that the mirror chosen doesn't have the file. Hmm, Sourceforge's actually selling away what we want, see on http://sourceforge.net/subscription.php: * Direct Downloads Download any file released on SourceForge.net in a hurry. No need to use the website; download files directly from the command line. Need to add software to a remote server? This is the easier way to do it. Does it only mean connecting one to the right(?) mirror automatically? -- Feri.
Re: Fix crash in dsound test
Paul Millar <[EMAIL PROTECTED]> writes: > The build failed. It looks like there's a bug in CVS. Both > CLSID_DirectSoundPrivate and DSPROPSETID_DirectSoundDevice defined multiple > times (the wine-version of mingw libraries and in the source). Yes, there was a short discussion about this on 23-24 July on wine-devel. It reached no conclusion, though, and I didn't try the various MinGW libraries recommended there. The abundance of MinGW packages always confused me, and at the moment I don't even know where I got mine from. But it can't compile the dsound tests, that's for sure. Comments welcome. -- Feri.
Re: WineHQ:service.cgi: fix winrash option
Kevin Koltzau <[EMAIL PROTECTED]> writes: > On Wednesday 28 July 2004 04:36 pm, [EMAIL PROTECTED] > wrote: > >> Your help is much appreciated. This is a tricky issue it >> seems as SF isn't always reliable for downloads... > > Gentoo handles this situation fairly well, [...] Hi Kevin, since I included dsound into winetest you don't seem to publish any more winetest versions on Sourceforge. Have you got problems compiling the dsound tests? Can you cope? -- Thanks, Feri.
Re: WineHQ:service.cgi: fix winrash option
<[EMAIL PROTECTED]> writes: > Which errors are you referring to? The most frequent ones > lately are the ones where the winetest package isn't > available on the sourceforge osdn mirror. For example this: > Winrash version: winrash-0008-chris-msvc.exe > [...] > winetest = winetest-200407091000-kevin-mingw.zip > winetest_history = > Script: > 8 total commands, current command is 6 > 0: error_url http://test.winehq.org/error > 1: error_sleep 3600 > 2: download winetest-200407091000-kevin-mingw.zip > http://osdn.dl.sourceforge.net/sourceforge/wine/winetest-200407091000-kevin-mingw.zip > 3: cookie winetest winetest-200407091000-kevin-mingw.zip > 4: cookie winetest_history > 5: unzip winetest-200407091000-kevin-mingw.zip > --> 6: run winetest-200407091000-kevin-mingw.exe -c -t Cogman -u > http://osdn.dl.sourceforge.net/sourceforge/wine/winetest-200407091000-kevin-mingw.zip > 7: sleep 300 > Command in error: > 6 > Last error text: The system cannot find the file specified. Does the above mean that the download was unsuccessful? Equally for "Last error text: %1 is not a valid Win32 application."? Then we don't need these messages (which could be improved at least). Hmm, some still try to download winrash-0008 from the osdn mirror, which has been obsoleted for a long time. Why? And service.cgi shouldn't pass the -u option to winetest anymore, I patched it out. At least I think so. > We are still asking people to download the tests from this > location for particular test releases. I'd imagine the > fix is simply to point the downloads at valid mirror for > the file. By editing service.cgi's database? You could ask Jer, his is very helpful if you can catch him on IRC. I wish there was some logging feature in service.cgi... I'll go deeper in a couple of days. -- Feri.
Re: WineHQ:service.cgi: fix winrash option
<[EMAIL PROTECTED]> writes: > What is the service doing with winrash options btw? The > installer stops, installs and starts the winrash service. > > The installer uses /S for silent installs, otherwise it > will try to popup windows. Are you sure the service isn't > calling the installer with /S? You are right, I was wrong. This patch is rubbish. I can't really understand the errors on wine-test-results. Have you got an idea what may have gone wrong? Aren't any functional winrash instances running? Is something broken in the service script? The documentation is somewhat scarce so I'm doing a slow start... -- Feri.
Re: Fix crash in dsound test
Paul Millar <[EMAIL PROTECTED]> writes: > On Monday 19 July 2004 12:50, Ferenc Wagner wrote: > >> Can you (cross)build the directsound tests? > > FWIW, yes: > > http://www.astro.gla.ac.uk/users/paulm/wine/dsound_test-20040721.10-00.exe Fine, that works, even. :) What an interesting experience it is to hear variously-pitched 440 Hz sounds! The wonders of Doppler effect, I guess. Why not make the velocity such that the audible tones form a minor second for example? That way it really could be an interactive *test*... :] Back to the build: Paul, I can't see your winetest builds being used (allowing for the present outage). Do you know what the problem is? Those of Kevin are used for all the reports I checked, but he hasn't responded yet. I'll send a patch to include dsound in winetest, and we will see if he publishes anything... -- Thanks, Feri.
Re: tests: safe MAPI init
Jon Griffiths <[EMAIL PROTECTED]> writes: >> Windows XP Professional, in a network with roaming profiles >> served by Samba. I don't know what is relevant. > > Strange, I'd have assumed you'd have an extended mapi client > installed by deault. What is your default mail client? If it's Control Panel/Internet Options/Programs/E-mail, then Microsoft Outlook. I don't use this machine of Windows in particular, so only guessing. > Yes, it should probably bail at the first error; that should > be easy to change. I'm rather busy with work ATM but when > I get a day off I'll look at fixing these (and digging out > the rest of the mapi code I haven't submitted yet). Great! -- Cheers, Feri.
Re: tests: safe MAPI init
Jon Griffiths <[EMAIL PROTECTED]> writes: >> the mapi32 tests call scInitMapiUtil, which pops up an alert >> box saying something like (translating it) "Your default >> mailer application isn't capable of this operation, please >> ensure that Outlook is configured as the default mailer." > > This probably means that you don't have a mapi client installed, I > guess that the default win32 stub mapi implementation just falls back > into 'advertise ms software' mode when this happens. Is this an early > Windows version by any chance? Windows XP Professional, in a network with roaming profiles served by Samba. I don't know what is relevant. > if you can, please run 'winedump spec mapi32.dll' and 'winedump spec > mapistub.dll' (if the latter exists) and send me the resulting .spec > file, It should be possible to skip the tests unless there is a mapi > client installed. OK, sending you off-list. >> As a side note, most of the mapi tests are very careful >> about calling every function through a pointer acquired by >> GetProcAddr(), > > Thats just precautionary, I could only test on xp and some > entrypoints are sure to not be present in earlier native versions. Well, test_PropCopyMore() has four direct references IIRC. You may or may not want to "fix" it (like the IMPORTS). The long for loop in test_ScCountProps(void) is probably an overkill, too: if it happens to produce output in every iteration, it gets too big. Currently there is a 1 MB limit on the report submission to test.winehq.org. -- Best wishes, Feri.
tests: safe MAPI init
Hi (and sorry for the broken post), the mapi32 tests call scInitMapiUtil, which pops up an alert box saying something like (translating it) "Your default mailer application isn't capable of this operation, please ensure that Outlook is configured as the default mailer." This brings the tests to a halt, and even after clicking OK one gets 65536 failures bumping the logs above 5 MB. As a side note, most of the mapi tests are very careful about calling every function through a pointer acquired by GetProcAddr(), still the test executable is linked with -lmapi32. Does it make any sense? From winetest's perspective it isn't worth much, if a test can't run it's skipped altogether. Does it take care about different mapi versions? There are no recent reports on test.winehq.org/data, so something is obviously wrong. I'd be interested in hearing about people running Chris' winrash service. What happens if you run winetest directly? Don't forget to supply you tag with the -t option! Basically, winetest's own message boxes are OK, system message boxes are a problem. Thanks, Feri.
tests: safe MAPI init
Hi, the mapi32 tests call scInitMapiUtil, which pops up an alert box
Re: winetest timeout question
Robert Reif <[EMAIL PROTECTED]> writes: > Has anyone considered changing the timeout logic to be reset > every time something is printed? This would allow long tests > that periodically output something to run more than 2 minutes. > Timeout would only occur 2 minutes after the last output. Yes, that was the original idea. However, output redirection problems forced me to implement it the simple way. Basically, I couldn't make the same code work on WineLib and Windows. You can look at the related threads in the archive to get more precise information. I think the most sensible option would be to fix Wine so that redirecting Windows HANDLES has an effect on the libc filehandles, or change the testing framework so that it outputs through the Win32 API, not through the printf family in libc. That would also fix the present msvcrt inconsistency (the msvcrt tests' output doesn't get redirected under WineLib). But don't take my word on it, I'm talking from faint memory. Unfortunately I can't tell when I will have the time to do serious work on this. -- Feri.
Re: Fix crash in dsound test
Francois Gouget <[EMAIL PROTECTED]> writes: > On Mon, 19 Jul 2004, Ferenc Wagner wrote: > >> maybe winetest should explicitly reset >> WINETEST_INTERACTIVE and the other variables... > > It should probably do so. But maybe it could also have an > option to explicitly let you run a specific test in > interactive mode? Yeah, but that would be a not-so-smallish extension. Winetest's GUI is rather crude as it's mostly used from the winrash service in console mode. But of course it would be possible without major changes to present code. I'm tacking it to the end of my TODO. Due in the following months. :( -- Feri.
Re: Fix crash in dsound test
Robert Reif <[EMAIL PROTECTED]> writes: > How did this fail in windows. Since it doesn't crash with > wine, wine is doing something wrong. Lets try to figure > out what is wrong and correct wine to have the same > behavior as windows or at least notify someone that > something is wrong. > > Is anyone working on getting direct sound into the windows > port of our regression tests? > > Francois Gouget wrote: > >> Changelog: >> >> * dlls/dsound/tests/dsound.c >> >>Francois Gouget <[EMAIL PROTECTED]> >>Call IDirectSound::Initialize() as per MSDN before using the >>DirectSound object. Fixes a crash on Windows. Hi Kevin, hi Paul, Can you (cross)build the directsound tests? My toolchain is far too old, but yours could cope. If it/they can, we should include them into winetest, although interactive testing would remain unavoidable. Hmm, maybe winetest should explicitly reset WINETEST_INTERACTIVE and the other variables... -- Feri.
Re: [Mono-winforms-list] Fw: [Mono-list] System.Windows.Forms plans.
Hi, I'm largely incompetent in this field, so please forgive my fallacies in the comment below, but I felt sad reading Steven Edwards <[EMAIL PROTECTED]> write: > --- Paul Davis <[EMAIL PROTECTED]> wrote: > >> PDB might not be able to fuss, but I will. I recently >> asked about a way to figure out which version of Wine is >> in use at run-time because of the recent changes to >> wine_init()'s prototype. Alexandre appeared quite adamant >> that he was against introducing any such mechanism. > > You are asking for stable interfaces and those can only > come once there is a Wine 1.0. [...] All you are doing is > pointing out that its not stable which is well known. Well, not in my reading. Paul's asking for a way to *know* about (and act accordingly to) interface changes. He asked for an exported WINE_VERSION symbol for example. Alexandre didn't want to encourage that kind of version checks. Right, one shouldn't check for API versions but for features, and that's what people want in the first place anyway (if I understand correctly). >> [Wine] now is being used by (at least) 2 projects as a >> *library*, and it can either accept that role - which >> implies providing (at least) runtime version info - or >> reject it, which would be a great shame. It's not causing me warm fuzzies to see great projects duplicating each others' efforts for the lack of open negotiation. Knowledgeable people, please propose something to let these guys use and help Wine! -- Feri.
Re: psapi.dll tests
Uwe Bonnes <[EMAIL PROTECTED]> writes:
> Ferenc Wagner <[EMAIL PROTECTED]> writes:
>
>> Hi, please somebody enlighten me! How does this test
>> work once psapi_test.exe is linked with -lpsapi? How can
>> a program start at all without one of its hard
>> dependencies?
>
>> START_TEST(module)
>> {
>> dll = LoadLibrary("psapi.dll");
>> if (!dll) {
>> trace("LoadLibraryA(psapi.dll) failed: skipping tests with target
>> module\n");
>> return;
>> }
>
>> The above seems to be a common idiom which I don't
>> understand as opposed to using GetProcAddress and
>> invoking functions through pointers. What am I missing
>> here?
>
> If the library is already loaded, LoadLibrary returns the
> HModule of the already loaded module, to my knowledge...
Fine, but what for? Once this code is given control we can
be sure that run-time linking is done, ie. psapi.dll was
found and loaded. What do we test then?
--
Feri.
psapi.dll tests
Hi,
please somebody enlighten me! How does this test work once
psapi_test.exe is linked with -lpsapi? How can a program
start at all without one of its hard dependencies?
START_TEST(module)
{
dll = LoadLibrary("psapi.dll");
if (!dll) {
trace("LoadLibraryA(psapi.dll) failed: skipping tests with target module\n");
return;
}
The above seems to be a common idiom which I don't
understand as opposed to using GetProcAddress and invoking
functions through pointers. What am I missing here?
--
Feri.
[comp.emulators.ms-windows.wine] winetest observations
Hi, let me simply forward this message here. I can't take care for these during the weekend, but would be happy to receive comments on the harder parts when I'm back. Bye, Feri. From: Andrew Ziem <[EMAIL PROTECTED]> Newsgroups: comp.emulators.ms-windows.wine Subject: winetest observations Message-ID: <[EMAIL PROTECTED]> Date: Fri, 18 Jun 2004 09:56:12 -0600 It looks like winetest developers are busy. I don't know whether these are all bugs, but some of them are annoying. - winetest creates 3 popups complaining msvcdtd.dll could not be found - mapi32: creates popup: "Microsoft Outlook: either there is no default email client or the current mail client cannot fulfill the mesage request" - mapi32: util: another Outlook popup - user32_input always times out - Some test (maybe in user32) kills the system bar. On W2K it just pops up. On Win95 stays dead. This makes automated winrash testing difficult on 95. - winetest tells me my results are too big to upload. It tells me to upload the manually, but it would be nice if it would give me a URL or instructions to do that. - During winetest results upload, I cannot use DNS, SSH, IMAP, or HTTP. However, I can use Windows File Sharing. Andrew
Re: [test.winehq.org] missing tests
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: >>> 3. We are running multiple test _per_ build, but only >>> one is curretly reported. Currently, it says: >>> Main summary for build 200406171000 >>> where '200406171000' is a link to the test. But since >>> we have multiple downloads, it should be: >>> Main summary for build 200406171000: [0] [1] [2] [3] >>> (or somesuch), where [x] is a link to the download. > > Just append the above index to the Tag, separated by ':'. I think separate columns would serve us better by not repeating the overly long tags several times. The problem is rather: where to get these numbers (or anything) from? In principle it would be possible to mine them out of the archive URL, but Kevin and Paul have different naming conventions and the URL should be kept flexible. That's why I think we need a new piece of information stored in the reports. [See also at the end!] > For now each submit two: one .zip, one compressed with as > a self-extractable. I'm not sure I understand this. The above two should always produce the exact same results, shouldn't they? They contain the same executable after all... > We hope to also have a MSVC build in the future. That would be a nice addition, really. > Not if we separate them as I suggested above. I don't think > we currently allow ':' and '.' in the Tag. Currently it's [-.a-zA-Z0-9]*. >> It would be possible to subdivide the columns under the tags >> by builds. We would need a short build id for this at a >> well-defined place, like in a new field in the report or >> maybe in the first line of the Build info: block. > > We can just assign numbers for that as I suggested above. > As long as we list in the begginning what each number > is (that is, the URL for it) we should be fine. Since they > all should come from the same BUILD-ID, there should be > no difference between then anyway (usually :). Ah, finally I understand you. I think. So do you suggest that [1] and [2] may mean different things on different pages? That would be possible with what we have now, you are right. I can give it a shot, but only after having some sleep and maybe soccer, even. -- Feri.
Re: [test.winehq.org] missing tests
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > Speaking of the test results, I've noticed the following problems: > 1. Some errors reported in the summary > don't get reported in the differences. Good catch, fixed (*) > 2. The differences tables are inconsistent. How can you say that?! Do you think WineHQ can't reliably run my program? :) You may find my logic wrong, though. The differences show, well, the differences. Lines are pruned iff - all the reports are the same (char by char) AND - no run failed AND - there were no errors (* from now). It doesn't work as well as I expected because lots of successful tests produce variable output. I thought about fixing them, but I could as well change the pruning policy with much less work. Shall I simply drop the first condition? > we also shouldn't make the '0' in the summary a link, > since it has nowhere to take us. Those links don't target specific lines, so they could as well stay, but I've got no objection against nuking them. > 3. We are running multiple test _per_ build, but only > one is curretly reported. Currently, it says: > Main summary for build 200406171000 > where '200406171000' is a link to the test. But since > we have multiple downloads, it should be: > Main summary for build 200406171000: [0] [1] [2] [3] > (or somesuch), where [x] is a link to the download. This is a more complicated issue which I haven't dared to touch yet. I planned to handle this as different builds, so there is no machinery in place for this variability. Neither for the download link, nor for the results. The Tag could be overloaded for this purpose, and the download links should go into the differences header for easy access, where they could also serve as a quick indication of the build type. Then we need short names or icons for the builds. > 4. Each of the testers run and submit 4 sets of tests for > a build, but only one is reflected in the results. > This is related to the above point, and needs fixing. 4? I though it was 2: Kevin's and Paul's. Or do they both plan to build with MinGW and MSVC? Anyway, the reports should be present with the same tag, successively numbered. The annoying thing is that people started to number their tags, which leads to strange-looking headers. Oh well. It would be possible to subdivide the columns under the tags by builds. We would need a short build id for this at a well-defined place, like in a new field in the report or maybe in the first line of the Build info: block. -- Feri.
Re: [test.winehq.org] missing tests
Stefan Leichter <[EMAIL PROTECTED]> writes: > i noticed that not all dlls with unittests are listed > inside the Main summary of test.winehq.org. Missing dlls > are: iphlpapi, mapi32, msvcrtd, psapi, version > > Is there any reason for this? Not that I know of. Submitting a patch, thanks for pointing it out. -- Feri.
Re: Request for winetesting volunteers
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > the email would be good, but not as the ID, the reports > will be much uglified (the names are already a bit long > right now). We could easily chop those long tags to 6-7 chars. Shall we? > we should have a -M switch that just appends metadata to > the one already bundled with winetest, this would allow us > to include dynamic stuff, like this email address). Do you mean something like -M key:file or -M key=value? I agree that something like this should probably be added. -- Feri.
Re: Request for winetesting volunteers
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > On Sat, May 29, 2004 at 09:22:02AM +0200, Ferenc Wagner wrote: > >> What's missing, what should be easier? > > Now that you're asking: in the reports, I don't quite like > that a single report for Win95 is listed as OSR2 in the > main summary [...] I tend to agree, this idea didn't really work out. Somehow different Win9x subversions have well recognised names like OSR2, SP1, SE but other Windows flavours do not while still having service packs of course. We could probably drop this distinction altogether and empty this layer of abstraction. It would simplify things a bit. Deal? -- Feri.
Re: Request for winetesting volunteers
Chris Morgan <[EMAIL PROTECTED]> writes: > the winetest results are sent back to winehq and can be > accessed via http://test.winehq.org/data/ Pretty > formatting of the results is coming soon ;-) Do you mean somebody's already working on it or that I should do it eventually? I'm back from the summer school but the examination period started here, so I can do some work again. It would even make more sense now that the dust settled. Have you perhaps got concrete ideas? It would be interesting to hear the experience of people using/working from the reports. What's missing, what should be easier? Anyway, thanks for the good work, guys! -- Feri.
Re: Alsa compilation error
Francois Gouget <[EMAIL PROTECTED]> writes: > On Thu, 13 May 2004, James Courtier-Dutton wrote: > >> You have to use a version of alsa that came out after >> 19th June 2002 I.E. 0.9.0rc2 or above. The version of >> alsa you are using came out in 26th Feb 2002 >> >> Just upgrade your alsa version to a NON-BETA version. > > Debian stable does not have anything more recent you > insensitive clod! (I hope you read the Slashdot polls, > otherzise ignore the last 3 words) What polls? Btw. you can get my alsa packages for Woody: http://afavant.elte.hu/~wferi/debian Not the latest, but I haven't got there yet and they work. -- Feri.
Re: winetest: move to resources
Alexandre Julliard <[EMAIL PROTECTED]> writes: > Ferenc Wagner <[EMAIL PROTECTED]> writes: > >> Back to the topic: my main point is that the situation is >> best expressed by a Makefile and solved by make. Best as >> opposed to verbosity and complexity. I suppose this is also >> a fairly workable scheme for those who build the winetest >> packages while being transparent for others. And still a >> very straightforward application of make. I can't really >> see sane way to do all of this in maketest without >> triggering superfluous relinks all the time; maybe I miss >> something obvious. > > Again, please explain what you are trying to do from a > high-level point of view; it may well be that this needs > makefile changes, but if so they need to be done cleanly, > which isn't the case with your patch I'm afraid. Now I got it, hopefully. So: the winetest executable must contain some information about its build process which it can write into the reports. These are: an identification string (usually the checkout date and time but possible something else), a URL where the executable can be downloaded from and a free-format block of other build info like toolchain versions. Some of these are presistent, some more subject to change. -- Feri.
Re: winetest: move to resources
Alexandre Julliard <[EMAIL PROTECTED]> writes: > Ferenc Wagner <[EMAIL PROTECTED]> writes: > >> My first implementation did exactly that. However, these >> pieces of information have their places in the depencency >> tree and I managed to screw up my build more often than not >> without the help of make. Beyond that, moving this little >> complexity out of the Makefile leads to much more complexity >> in a couple of other places. I did my best not to bother >> uninterested parties by these small files; I think they >> would go unnoticed. Are you still holding your position? >> >> Btw the real solution to the ugliness would be the use of >> the .DELETE_ON_ERROR special target, isn't that portable? > > No, it's not, and frankly I don't see why you would need that. > Could you please explain a bit more what you are trying to do? Oh, that was a real 'btw' side note; I meant the usual ... || ( $(RM) $@ && exit 1 ) stanzas, which we have to keep repeating all to often. I skimmed through the compatibility section in the make manual but found no portability issues with respect to this special target. An overlook, probably. Back to the topic: my main point is that the situation is best expressed by a Makefile and solved by make. Best as opposed to verbosity and complexity. I suppose this is also a fairly workable scheme for those who build the winetest packages while being transparent for others. And still a very straightforward application of make. I can't really see sane way to do all of this in maketest without triggering superfluous relinks all the time; maybe I miss something obvious. -- Feri.
Re: winetest: move to resources
Alexandre Julliard <[EMAIL PROTECTED]> writes: > Ferenc Wagner <[EMAIL PROTECTED]> writes: > >> It's almost a resend of my previous patch which seems MIA. >> The only difference is that I removed the possible sequence >> point screwups in the hope they were the reason for the drop. >> >> New files: programs/winetest/README >>programs/winetest/resource.h >> >> ChangeLog: >> - Build info et al. is given by files instead of env. vars. >> - Store that information in resources. > > I think it would be much cleaner to have maketest take care of > including the files, so that it doesn't require everybody to have > dummy files around and avoids that ugliness in the makefile. My first implementation did exactly that. However, these pieces of information have their places in the depencency tree and I managed to screw up my build more often than not without the help of make. Beyond that, moving this little complexity out of the Makefile leads to much more complexity in a couple of other places. I did my best not to bother uninterested parties by these small files; I think they would go unnoticed. Are you still holding your position? Btw the real solution to the ugliness would be the use of the .DELETE_ON_ERROR special target, isn't that portable? -- Feri.
Re: [RFC] add msacm32 to winetest
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > On Tue, 4 May 2004, Ferenc Wagner wrote: > >> The msvcrt subtest parse error is a known redirection >> issue: the msvcrt test is linked against msvcrt (wow) and >> thus ignores the redirected libc filehandles. Tough. > > Can e special case this guy somehow? More generally, can > we special case test case linked against msvcrt? Sorry for being so terse. This problem arises in the ELF build only, therefore has very little relevance in our case. Special casing would be possible but not worth in my opinion. Still, I can do it if you beat me to it. -- Feri.
Re: [RFC] add msacm32 to winetest
Robert Reif <[EMAIL PROTECTED]> writes: > This patch adds msacm32 to the tests. > > I'm not sure this is correct because I got a subtest parse > error on the test following the one I added (msvcrt). I > also only tested it with wine. Could someone knowledgeable > in this program please check and correct this patch if necessary? The msvcrt subtest parse error is a known redirection issue: the msvcrt test is linked against msvcrt (wow) and thus ignores the redirected libc filehandles. Tough. -- Feri.
Re: winelib application taking 100% of the CPU
Scott W Gifford <[EMAIL PROTECTED]> writes: > I ported to Winelib because I had a hard time capturing > stdout from the Windows console program properly just > running the .exe under Wine. Try wineconsole instead of wine, that may work better. -- Feri.
Re: dlls/kernel/tests/file.c
Jakob Eriksson <[EMAIL PROTECTED]> writes:
> +lockfileex_capable = dll_capable("kernel32", "LockFileEx");
> +if (lockfileex_capable)
> +{
> +/* Test for broken LockFileEx a la Windows 95 OSR2. */
> +if (LockFileEx( handle, 0, 0, 100, 0, &overlapped ))
Can I ask somebody to explain me how this works? Shouldn't
the LockFileEx call be satisfied on program startup even if
we won't call it?
--
Thanks,
Feri.
Re: Rename builds.txt to winetest.builds
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > Looking at them I see that in winetest/winetest.conf, > $root = "/home/laxdragon/wine/tools/winetest"; > $builds = "$root/winetest.builds"; > but on the other hand in service.cgi we have > $path_to_builds_txt="/home/winehq/opt/winetest/builds.txt"; > What gives? $root in winetest.conf is a placeholder I provided for a value I had no idea of. Seems like Jer isn't useing this file from CVS but a separate copy instead, which has $root set up correctly. -- Feri.
Re: RFH: winetest testing
Eric Pouech <[EMAIL PROTECTED]> writes: >> The output redirection didn't work from a GUI app: the libc >> streams weren't initialized and thus the output disappeared. >> Wouldn't DETACHED_PROCESS result the same? It's not crucial >> for winetest itself, but making it a console app helped >> debugging tremendously. > > I think the stream (handle) point of view worked, but > somehow msvcrt doesn't initialize stdin/err/out when the > app is in GUI mode. Pretty much so. The output simply didn't appear, even if the GUI app was started from a console. No errors here. > It may work if the app would close 0,1,2 and reopen them > on standard handles Do you mean StdHandles a la Windows? I'm not sure a GUI app has them. Even if it had, there's no way to convert them into libc handles or streams AFAIK. >> In short, I've got the impression that things are working >> out now (by using some black magic -- ie. winetest being a >> CUI -- which I don't understand), so maybe we could simply >> leave it for now. Or do I miss serious issues? > > the only point is that we don't have a consistent basis > across platforms were we start the tests from: > - all tests programs are CUI exec > - but, we don't know if it's attached to a console or not A CLI program is attached to a console unless created with fancy flags, isn't it? Presently I only ask for the window to be hidden, nothing else. > - if attached to a console, we don't know whether other > processes are outputting to the same console (which could > impact the tests...) I never thought of this. If this really can be a problem, we must solve it, thanks for bringing it up. However I seem to recall that the console test pops up a separate console, so maybe isn't affected after all. Other test shouldn't care... But I will soon look into this (may take a couple of days, though). -- Feri.
