Hi, so we should start working out this one, too. First let me sketch the present picture. I've got a directory structure like this: | + 20030829 + 95 | + 95_michael | + 98 | + 98_joel | + 98_kevin | + etc. | ` 2003s | + 20030916 (similar) ` 20031127 (similar) That is, one directory for each test collection and one subdirectory for each submission of it. For a new submission I create a directory, copy the results.txt into it, create a reporter.txt next to it, add it to archs in the Makefile, and make. For a new test collection I create missing.dll.txt's (presently dsound), Makefile and tests.zip in a new directory. Changes needed at least: 1. Windows version detected automatically. 2. Tester name and contact (?) included in the results. 3. Automatically generated tags, probably simple incremental numbers. 4. Which submission should be the principal one? The first? 5. Makefile at one level higher, archs variable autodetected. But before doing anything, we definitely need the opinion of the website maintainer. We need a very simple CGI to handle the file uploads. Presently it is <http://afavant.elte.hu/~wferi/wine/winetest.pl>. All of the present machinery is available in that directory: Makefile, dissect, gather and the other ingredients. I don't know much about web design or anything about WineHQ's inner workings. What sort of output should we produce? I think the above is enough for a start... Feri.
On December 4, 2003 08:10 pm, Ferenc Wagner wrote:
Changes needed at least: 1. Windows version detected automatically.
For sure. We have all this info into the results however, shouldn't be too difficult.
2. Tester name and contact (?) included in the results.
Would be nice to have, but I don't think we should depend on it in anyway. Which means that we should carry forward assuming we don't have it (at least for now).
3. Automatically generated tags, probably simple incremental numbers.
Agreed. You may want to have the OS prefix as now, something like this: 95_0 95_1 ....
4. Which submission should be the principal one? The first?
Why do we need a principal one in the first place? -- Dimi.
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
On December 4, 2003 08:10 pm, Ferenc Wagner wrote:
4. Which submission should be the principal one? The first?
Why do we need a principal one in the first place?
That would be the one we show in the first table, which contains one submission for each Windows version. We could also generate a test-by-test 'average', 'worst case' or 'best case' mixture out of the (hopefully) several submissions, of course. Maybe I could live with the 'worst case', it would lead to some confusion, I'am afraid. Feri.
On December 5, 2003 12:38 pm, Ferenc Wagner wrote:
We could also generate a test-by-test 'average', 'worst case' or 'best case' mixture out of the (hopefully) several submissions, of course.
This is what I was hopping we're gonna do. It doesn't seem right to pick the first one... We could try worst case, even though I'm afraid a test went bad for whatever reason will hide all the interesting results. I don't think it's that important. Let's pick the first one for now if that makes it simpler, and do the integration work (that's the hard part). Once that's done, we can tweak that table to our heart's content. -- Dimi.
I would like to have the call to the Win16 API LockResource16 removed from ole32.dll. I guess there is a reason for it being LockResource16 and not LockResource. What is the reason? How can the call be removed? Casper
"Casper Hornstrup" <chorns(a)users.sourceforge.net> wrote:
I would like to have the call to the Win16 API LockResource16 removed from ole32.dll. I guess there is a reason for it being LockResource16 and not LockResource. What is the reason?
Because LoadAcceleratorsA/W returns a value allocated by GlobalAlloc16.
How can the call be removed?
Only if you or someone else can prove that under real windows LoadAcceleratorsA/W behaves differently (taking into account Win9x weirdness). -- Dmitry.
-----Oprindelig meddelelse----- Fra: Dmitry Timoshkov [mailto:dmitry(a)baikal.ru] Sendt: 6. december 2003 14:00 Til: Casper Hornstrup Cc: wine-devel(a)winehq.com Emne: Re: LockResource16 in ole32.dll
"Casper Hornstrup" <chorns(a)users.sourceforge.net> wrote:
I would like to have the call to the Win16 API LockResource16 removed from ole32.dll. I guess there is a reason for it being LockResource16 and not LockResource. What is the reason?
Because LoadAcceleratorsA/W returns a value allocated by GlobalAlloc16.
How can the call be removed?
Only if you or someone else can prove that under real windows LoadAcceleratorsA/W behaves differently (taking into account Win9x weirdness).
Windows XP ole32.dll does not import LockResource16 (nor LockResource for that matter). Windows XP user32.dll does not import GlobalAlloc16, but it imports GlobalAlloc. I currently do not have access to a Win9X installation to check that. Casper
participants (4)
-
Casper Hornstrup -
Dimitrie O. Paun -
Dmitry Timoshkov -
Ferenc Wagner