Folks, Can you please run this .exe on your Windows box: http://afavant.elte.hu/~wferi/wine/winetest.exe We are trying to test the winetest infrastructure. TIA! -- Dimi.
Just tried this on win98, XP and Win2k3 On win98 it totally locks my system up on user32:dialog On Tuesday 20 April 2004 01:01 pm, Dimitrie O. Paun wrote:
Folks,
Can you please run this .exe on your Windows box: http://afavant.elte.hu/~wferi/wine/winetest.exe
We are trying to test the winetest infrastructure.
TIA!
Test run on Win2K sp4 (French) 1. I have a error with comctrl32_test.exe (it's seems to occur during extraction). Translated from french : "Can't find PDA_Search entry point in COMCTL32.DLL" (I have version 5.81.4916.400) 2. With the GUI, a shell is created (it should display debug traces ??) but I see only some weird caracters like "abcdf g" and one line : "tests/process.c: 6 tests executed, 0 marked as todo, 0 failures.??" 3. Freezes on "oleaut32:vartest", I have a timeout error. 4. Programme stops on "user32:input" (the progressbar is at about 90%) 5. the icon of "winetest.exe" has a dark background, is it on purpose ? (my video card is configured to 16 bits/pixel) I like this little program ;-)
Mehmet YASAR <myasar(a)free.fr> writes:
1. I have a error with comctrl32_test.exe (it's seems to occur during extraction). Translated from french : "Can't find PDA_Search entry point in COMCTL32.DLL" (I have version 5.81.4916.400)
That's probably due to my old MinGW, newer versions hopefully won't produce this. Can anybody confirm this?
2. With the GUI, a shell is created (it should display debug traces ??) but I see only some weird caracters like "abcdf g" and one line : "tests/process.c: 6 tests executed, 0 marked as todo, 0 failures.??"
That's expected. Windows just can't do without this. :(
3. Freezes on "oleaut32:vartest", I have a timeout error.
4. Programme stops on "user32:input" (the progressbar is at about 90%)
Yes, these happen sometimes.
5. the icon of "winetest.exe" has a dark background, is it on purpose ? (my video card is configured to 16 bits/pixel)
No, it isn't. If anybody can tell me why, I'd like to hear!
I like this little program ;-)
So glad you like it! :) You probably won't see if often, though. -- Feri.
2. With the GUI, a shell is created (it should display debug traces ??) but I see only some weird caracters like "abcdf g" and one line : "tests/process.c: 6 tests executed, 0 marked as todo, 0 failures.??"
That's expected. Windows just can't do without this. :( I'd say it's part of kernel32 tests of console. a new console is created, and text printing is tested (especially line wrap around and the likes). We could perhaps print some information for unaware testers. A+
Eric Pouech <pouech-eric(a)wanadoo.fr> writes:
2. With the GUI, a shell is created (it should display debug traces ??) but I see only some weird caracters like "abcdf g" and one line : "tests/process.c: 6 tests executed, 0 marked as todo, 0 failures.??"
That's expected. Windows just can't do without this. :(
I'd say it's part of kernel32 tests of console. a new console is created, and text printing is tested (especially line wrap around and the likes).
The second part, yes. But winetest must have been made into a console app, so it pops up a console when it starts. The console test would pop up a console anyway (we should hide it), but if a console is already present it is used instead.
We could perhaps print some information for unaware testers.
Sure, but some tests would better be fixed anyway. Examples: kernel32:file leaves a temp file behind kernel32:pipe loops forever on Win9x/Me (not included in my version of winetest) oleaut32:vartest takes too long to complete user32:dialog tends to hose Win9x user32:input hangs Thanks everybody for helping us testing this thing! There is more to come: a program running as a Windows service in the background, downloading and running new versions of winetest as they come out: WinRash! Watch this place! :) -- Feri.
Ferenc Wagner wrote:
Thanks everybody for helping us testing this thing! There is more to come: a program running as a Windows service in the background, downloading and running new versions of winetest as they come out: WinRash! Watch this place! :)
And then winetest.exe can no longer pop up little dialogs everywhen there is a timeout, that would kind of defeat the purpose of having a service in the first place... regards, Jakob
Jakob Eriksson <jakov(a)vmlinux.org> writes:
Ferenc Wagner wrote:
Thanks everybody for helping us testing this thing! There is more to come: a program running as a Windows service in the background, downloading and running new versions of winetest as they come out: WinRash! Watch this place! :)
And then winetest.exe can no longer pop up little dialogs everywhen there is a timeout, that would kind of defeat the purpose of having a service in the first place...
Winetest's main purpose isn't harassing nice users with pressing OK buttons. The less intervention it needs the better. -- Feri.
Ferenc Wagner wrote:
Jakob Eriksson <jakov(a)vmlinux.org> writes:
And then winetest.exe can no longer pop up little dialogs everywhen there is a timeout, that would kind of defeat the purpose of having a service in the first place...
Winetest's main purpose isn't harassing nice users with pressing OK buttons. The less intervention it needs the better.
Yes, I'm sorry - stating the obvious, that's me. :-) Jakob
On April 20, 2004 5:32 pm, Ferenc Wagner wrote:
kernel32:file leaves a temp file behind kernel32:pipe loops forever on Win9x/Me (not included in my version of winetest) oleaut32:vartest takes too long to complete user32:dialog tends to hose Win9x user32:input hangs
Good list. We'll need to fix these soon I believe, can you keep track of them so we don't forget them? Or better, may we should open a Test meta-bug in bugzilla, and log separate bugs for each defect, as dependants of the metabug. Yeah, and we can link the metabug from the (future) index page, to keep it fresh in our memory :) -- Dimi.
The second part, yes. But winetest must have been made into a console app, so it pops up a console when it starts. why do you need a console ? either you don't care about the output to the console, or you do care but you've already redirected the output to a log file so, passing DETACHED_PROCESS in CreateProcess (winetest/main.c) would be a good thing IMO
A+
Eric Pouech <pouech-eric(a)wanadoo.fr> writes:
The second part, yes. But winetest must have been made into a console app, so it pops up a console when it starts.
why do you need a console?
Er, I don't know. Winetest itself doesn't really need it, but WinRash (the service) couldn't execute it otherwise. We don't understand this. Apart from this, winetest has console mode, when it doesn't display a gui but logs into its console. I couldn't find a way to presen gui or console mode based on a command line option (I asked on Win32 programmers' forum, the only solution was XP only.)
either you don't care about the output to the console, or you do care but you've already redirected the output to a log file so, passing DETACHED_PROCESS in CreateProcess (winetest/main.c) would be a good thing IMO
The individual tests started by winetest don't pop up additional consoles, and their output is redirected. When started from the service, winetest doesn't pop one up either (of course). If you can think of a better solution, I'm all ears. -- Feri.
On Wednesday 21 April 2004 06:07 pm, Ferenc Wagner wrote:
Er, I don't know. Winetest itself doesn't really need it, but WinRash (the service) couldn't execute it otherwise. We don't understand this. Apart from this, winetest has console mode, when it doesn't display a gui but logs into its console. I couldn't find a way to presen gui or console mode based on a command line option (I asked on Win32 programmers' forum, the only solution was XP only.)
Something along these lines can be used to have a console app "detach" from its console..not extremely elegant but it does seem to work void main(int argc, char *argv[]) { if(argc < 2) { char buff[1024]; STARTUPINFO si; PROCESS_INFORMATION pi; ZeroMemory(&si, sizeof(si)); si.cb = sizeof(si); sprintf(buff, "%s /stage2", argv[0]); CreateProcess(NULL, buff, NULL, NULL, FALSE, DETACHED_PROCESS, NULL, NULL, &si, &pi); CloseHandle(pi.hProcess); CloseHandle(pi.hThread); } else MessageBox(NULL, "Test", "test", MB_OK); }
Ferenc Wagner wrote:
Eric Pouech <pouech-eric(a)wanadoo.fr> writes:
The second part, yes. But winetest must have been made into a console app, so it pops up a console when it starts.
why do you need a console?
Er, I don't know. Winetest itself doesn't really need it, but WinRash (the service) couldn't execute it otherwise. We don't understand this. Apart from this, winetest has console mode, when it doesn't display a gui but logs into its console. I couldn't find a way to presen gui or console mode based on a command line option (I asked on Win32 programmers' forum, the only solution was XP only.)
Hmm... what about this: compile winetest.exe in two versions - one in console, one in gui mode. Let us call them winetestC.exe and winetestG.exe Add a third wrapper winetest.exe to contain both versions in the same way that all the regression test exes are contained. Let the wrapper read a command line option and start winetestC.exe and winetestG.exe respectively. This adds overhead, but only two times what the .obj - files in programs/winetest/ take up. regards, Jakob
Ferenc Wagner a écrit :
Eric Pouech <pouech-eric(a)wanadoo.fr> writes:
The second part, yes. But winetest must have been made into a console app, so it pops up a console when it starts.
why do you need a console?
Er, I don't know. Winetest itself doesn't really need it, but WinRash (the service) couldn't execute it otherwise. so you mean, that the service (winrash) couldn't start winetest if it isn't a cui application (from the PE image point of view) ?, or do you mean that winrash wouldn't start winetest if winetest isn't attached to a console ?
We don't understand this. Apart from this, winetest has console mode, when it doesn't display a gui but logs into its console. I couldn't find a way to presen gui or console mode based on a command line option (I asked on Win32 programmers' forum, the only solution was XP only.) why do you mean by that ?
either you don't care about the output to the console, or you do care but you've already redirected the output to a log file so, passing DETACHED_PROCESS in CreateProcess (winetest/main.c) would be a good thing IMO
The individual tests started by winetest don't pop up additional consoles, and their output is redirected. When started from the service, winetest doesn't pop one up either (of course). If you can think of a better solution, I'm all ears. as I said, we would be better of, if winetest would create the process for the tests with the DETACHED_PROCESS flag. As you redirect output from child to parent, you don't care about stdout/stderr going to the console itself, and tests actually requiring a console care about creating it, so you should be all set
A+
Eric Pouech <pouech-eric(a)wanadoo.fr> writes:
Ferenc Wagner a écrit :
Eric Pouech <pouech-eric(a)wanadoo.fr> writes:
The second part, yes. But winetest must have been made into a console app, so it pops up a console when it starts.
why do you need a console?
Er, I don't know. Winetest itself doesn't really need it, but WinRash (the service) couldn't execute it otherwise.
so you mean, that the service (winrash) couldn't start winetest if it isn't a cui application (from the PE image point of view) ?, or do you mean that winrash wouldn't start winetest if winetest isn't attached to a console ?
The first. Never tried the second, though. It doesn't really matter, since -- if I understand it right -- winetest can't popup its console (like any CUI app) when started by the service (Chris, is this really the case?), but the subtests it runs can! However, recently they are started with hidden windows and that seems to be enough.
We don't understand this. Apart from this, winetest has console mode, when it doesn't display a gui but logs into its console. I couldn't find a way to presen gui or console mode based on a command line option (I asked on Win32 programmers' forum, the only solution was XP only.)
why do you mean by that ?
Transforming a GUI app into CUI by AttachConsole(ATTACH_PARENT_PROCESS). Since then somebody suggested go the other way and restart the CUI process with the DETACHED_PROCESS flag to get rid of the console. Not clean, and we wouldn't gain much: putting up with a console window isn't the worst thing in life after all. And ppl running the service wouldn't even see this.
either you don't care about the output to the console, or you do care but you've already redirected the output to a log file so, passing DETACHED_PROCESS in CreateProcess (winetest/main.c) would be a good thing IMO
The individual tests started by winetest don't pop up additional consoles, and their output is redirected. When started from the service, winetest doesn't pop one up either (of course). If you can think of a better solution, I'm all ears.
as I said, we would be better of, if winetest would create the process for the tests with the DETACHED_PROCESS flag. As you redirect output from child to parent, you don't care about stdout/stderr going to the console itself, and tests actually requiring a console care about creating it, so you should be all set
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. 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? -- Feri.
On Monday 26 April 2004 7:11 pm, Ferenc Wagner wrote:
Eric Pouech <pouech-eric(a)wanadoo.fr> writes:
Ferenc Wagner a écrit :
Eric Pouech <pouech-eric(a)wanadoo.fr> writes:
The second part, yes. But winetest must have been made into a console app, so it pops up a console when it starts.
why do you need a console?
Er, I don't know. Winetest itself doesn't really need it, but WinRash (the service) couldn't execute it otherwise.
so you mean, that the service (winrash) couldn't start winetest if it isn't a cui application (from the PE image point of view) ?, or do you mean that winrash wouldn't start winetest if winetest isn't attached to a console ?
The first. Never tried the second, though. It doesn't really matter, since -- if I understand it right -- winetest can't popup its console (like any CUI app) when started by the service (Chris, is this really the case?), but the subtests it runs can! However, recently they are started with hidden windows and that seems to be enough.
When I was trying to run the winetests in gui mode they simply wouldn't run. Winetest would start but wouldn't spawn any of the subtests. Ferenc's winetest build with console windows worked much better. I don't have any idea why this might occur, maybe because child processes of services can't popup windows? Chris
On Tuesday 27 April 2004 08:57 pm, Chris Morgan wrote:
When I was trying to run the winetests in gui mode they simply wouldn't run. Winetest would start but wouldn't spawn any of the subtests. Ferenc's winetest build with console windows worked much better. I don't have any idea why this might occur, maybe because child processes of services can't popup windows?
Under NT, services run under a dedicated window station separate from the interactive window station. It is not possible for them to create windows, as there is no display or user input associated with this windows station, they can however have a console It may be possible for a GUI app to create a console manually to allow the tests to run, but I have not verified this It may also be possible to create the test processes with input redirected to a pipe, so that it does not require a true console however some of the tests requiring a console may fail in this case These pages may provide some insight into the problems you are having http://msdn.microsoft.com/library/en-us/dllproc/base/window_stations.asp http://msdn.microsoft.com/library/en-us/dllproc/base/interactive_services.as...
On Tue, 27 Apr 2004, Kevin Koltzau wrote: [...]
Under NT, services run under a dedicated window station separate from the interactive window station. It is not possible for them to create windows, as there is no display or user input associated with this windows station, they can however have a console
I don't think that it is correct to say that services cannot cerate windows. From what I remember from the time I wrote a service and how I read the information at the URLs you provided, what happens is that a service can create windows but the user won't see them, and the user won't be able to send input of click on them. But as long as the process does not expect the user to do anything with the windows it puts up we should be fine. Note that some tests need to be able to create windows. See for instance user32_test.exe. If services cannot create Windows at all (i.e. if CreateWindow fails for services), then many important tests are likely not to work at all, thus greatly reducing the usefulness of such a service process! (based on the trend I suspect we'll get more and more window related tests) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?
On Wed, Apr 28, 2004 at 12:25:31PM +0200, Francois Gouget wrote:
On Tue, 27 Apr 2004, Kevin Koltzau wrote: [...]
Under NT, services run under a dedicated window station separate from the interactive window station. It is not possible for them to create windows, as there is no display or user input associated with this windows station, they can however have a console
I don't think that it is correct to say that services cannot cerate windows. From what I remember from the time I wrote a service and how I read the information at the URLs you provided, what happens is that a service can create windows but the user won't see them, and the user won't be able to send input of click on them. But as long as the process does not expect the user to do anything with the windows it puts up we should be fine.
What about "Allow service to interact with desktop" I have seen somewhere in Windows? -- regards, Jakob It's is not, it isn't ain't, and it's it's, not its, if you mean it is. If you don't, it's its. Then too, it's hers. It isn't her's. It isn't our's either. It's ours, and likewise yours and theirs. -- Oxford University Press, Edpress News
Francois Gouget wrote:
On Tue, 27 Apr 2004, Kevin Koltzau wrote: [...]
Under NT, services run under a dedicated window station separate from the interactive window station. It is not possible for them to create windows, as there is no display or user input associated with this windows station, they can however have a console
First of all, we are talking about "non-interactive serivces" only.
I don't think that it is correct to say that services cannot cerate windows. From what I remember from the time I wrote a service and how I read the information at the URLs you provided, what happens is that a service can create windows but the user won't see them, and the user won't be able to send input of click on them.
Actually, I think the user WILL see them if she presses "ctrl-alt-del". The GINA login window is one such window opened by a service, as well as that thing that pops up only when you press ctrl+alt+del. I hope this helps. Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/
On Wednesday 28 April 2004 07:59 am, Shachar Shemesh wrote:
First of all, we are talking about "non-interactive serivces" only.
Yes
Actually, I think the user WILL see them if she presses "ctrl-alt-del". The GINA login window is one such window opened by a service, as well as that thing that pops up only when you press ctrl+alt+del.
GINA runs on a completely dedicated, secure windows station, there are 2 such window stations, the one displayed at login (which is also the one shown when you hit ctrl-alt-del), the other is used by the screen saver the only windows that can be displayed on these are generated by the Messenger service, which simply displays a popup window on the current window station that is attached to user input
Kevin Koltzau wrote:
GINA runs on a completely dedicated, secure windows station, there are 2 such window stations, the one displayed at login (which is also the one shown when you hit ctrl-alt-del), the other is used by the screen saver the only windows that can be displayed on these are generated by the Messenger service, which simply displays a popup window on the current window station that is attached to user input
At a demo in Black Hat Windows 2001, in Las Vegas, a guy from the rootkit project was demoing their stuff. Amazing stuff. One of the things he was demoing was fresh out of the oven. A kernel-mode rootkit launching a user-mode process. They were taking another process, and copying it's process information for their newly created process. He was running cmd, IIRC. The thing is, he was demoing how he was telneting (to a fake IP), and issued a command to run CMD, and nothing happened. And the guy says "oh well, I said it was experimental". Then, a couple of minutes later, the guy presses CTRL+ALT+DEL for an unrelated reason, and guess what? There is his CMD Window, functional and all. They were cloning the information of the wrong Win32 process. Not entirely relevant, and obviously once your'e in kernel mode, you can do anything. Still, that's where my info comes from. Sorry about the distraction. Just thought you may enjoy the story. Shachar p.s. http://www.rootkit.com, in case anyone is interested. -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/
On Wednesday 28 April 2004 06:25 am, Francois Gouget wrote:
I don't think that it is correct to say that services cannot cerate windows. From what I remember from the time I wrote a service and how I read the information at the URLs you provided, what happens is that a service can create windows but the user won't see them, and the user won't be able to send input of click on them. But as long as the process does not expect the user to do anything with the windows it puts up we should be fine.
Note that some tests need to be able to create windows. See for instance user32_test.exe. If services cannot create Windows at all (i.e. if CreateWindow fails for services), then many important tests are likely not to work at all, thus greatly reducing the usefulness of such a service process!
(based on the trend I suspect we'll get more and more window related tests)
Services can create windows, but when the service is not flagged as interactive its windows don't act completely normally, AFAIK.
From what I remember in my past work with services (which has been a while so I may be forgetting something here), windows created from a non-interactive service dont show up in the system window list (as seen by apps like spy++), and they cannot be visible (that is, the windows are created hidden, and a call to ShowWindow will always fail)
If the service is flagged as interactive, everything acts normally
Kevin Koltzau wrote:
If the service is flagged as interactive, everything acts normally
Except you can take control over the process, thus escalating priveleges. MS's reply? "It's an application bug. Don't use interactive services". With such a reply, you would really expect them not to ship any interactive services themselves, wouldn't you? Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/
> 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. It may work if the app would close 0,1,2 and reopen them on standard handles > 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 - if attached to a console, we don't know whether other processes are outputting to the same console (which could impact the tests...) - ... A+
Eric Pouech <pouech-eric(a)wanadoo.fr> 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.
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. a GUI app gets the std-handles its parent requires it to have. then msvcrt on startup will only initialize 0,1,2 to the std-handle if the app is a CUI app (from the PE flag) check out in msvcrt _open_osfhandle to open a msvcrt file descriptor from a kernel32 handle http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/...
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? it's attached to the parent console, if the parent has a console, and if you don't pass DETACH_CONSOLE as a flag in CreateProcess
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, no, they create a console if the process doesn't have one. don't forget that on unix, the test will output to stdout/stderr using the unix streams, even without a console is created, which is rather different from windows were normally the program will output its info on the same console it's run from
A+
On Tue, 20 Apr 2004, Ferenc Wagner wrote:
Mehmet YASAR <myasar(a)free.fr> writes:
1. I have a error with comctrl32_test.exe
That's probably due to my old MinGW, newer versions hopefully won't produce this. Can anybody confirm this?
You could try with the auto-built versions here: http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/winetest-latest.exe It was cross-built with pretty recent versions of everything: binutils-2.15.90-20040222 gcc-core-3.3.3-200402017 mingw-runtime-3.2 w32api-2.5 + lots of patches from Hans. .. then UPX compressed. If you have problems running the test (you shouldn't), try the binary inside winetest-latest.zip as it won't have been UPX compressed. HTH, Paul. ---- Paul Millar
On Tue, 20 Apr 2004, Mehmet YASAR wrote:
Test run on Win2K sp4 (French)
1. I have a error with comctrl32_test.exe (it's seems to occur during extraction). Translated from french : "Can't find PDA_Search entry point in COMCTL32.DLL" (I have version 5.81.4916.400)
Yes, expected.
2. With the GUI, a shell is created (it should display debug traces ??) but I see only some weird caracters like "abcdf g" and one line : "tests/process.c: 6 tests executed, 0 marked as todo, 0 failures.??"
Expected.
3. Freezes on "oleaut32:vartest", I have a timeout error.
Ditto.
4. Programme stops on "user32:input" (the progressbar is at about 90%)
Wait for timeout, expected.
5. the icon of "winetest.exe" has a dark background, is it on purpose ? (my video card is configured to 16 bits/pixel)
Hmmm. Feri? -- Dimi.
"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes:
On Tue, 20 Apr 2004, Mehmet YASAR wrote:
5. the icon of "winetest.exe" has a dark background, is it on purpose ? (my video card is configured to 16 bits/pixel)
Hmmm. Feri?
That icon behaves pretty strange: it has a transparent background until you click on it, then it becomes dark. I'd be glad to solve this if I knew how... -- Feri.
5. the icon of "winetest.exe" has a dark background, is it on purpose ? (my video card is configured to 16 bits/pixel)
It looks here like the background is the 'inverse' colour (invert the underlying colour) -- in the app's title bar it shows up as a pale yellow background, but on the taskbar as dark grey. Regards, Ben A L Jemmett. (http://web.ukonline.co.uk/ben.jemmett/, http://www.deltasoft.com/)
Dimitrie O. Paun wrote:
Can you please run this .exe on your Windows box: http://afavant.elte.hu/~wferi/wine/winetest.exe
We are trying to test the winetest infrastructure.
On my (dutch) Windows 98 SE Lite (see www.litepc.net) install it needed quite a lot of user interaction. In the sense of clicking [Ok] on error boxes. Is that intentional? Should I have written them down? Henk Poley <><
Henk Poley <hpoley(a)dds.nl> writes:
Dimitrie O. Paun wrote:
Can you please run this .exe on your Windows box: http://afavant.elte.hu/~wferi/wine/winetest.exe
We are trying to test the winetest infrastructure.
On my (dutch) Windows 98 SE Lite (see www.litepc.net) install it needed quite a lot of user interaction. In the sense of clicking [Ok] on error boxes. Is that intentional? Should I have written them down?
It's partly intentional, but as I can't see a single Win98 report on the summary page, I have to say that in your case at least one isn't. Could you please provide some details? -- Feri.
Ferenc Wagner wrote:
Henk Poley <hpoley(a)dds.nl> writes:
Dimitrie O. Paun wrote:
Can you please run this .exe on your Windows box: http://afavant.elte.hu/~wferi/wine/winetest.exe
We are trying to test the winetest infrastructure.
On my (dutch) Windows 98 SE Lite (see www.litepc.net) install it needed quite a lot of user interaction. In the sense of clicking [Ok] on error boxes. Is that intentional? Should I have written them down?
It's partly intentional, but as I can't see a single Win98 report on the summary page, I have to say that in your case at least one isn't. Could you please provide some details?
If you can tell me where the partial report is stored I can send it to you. The thing halted at the :input stuff (yes, I know, known bug), so the report was never sent. I waited 15 minutes or so, so the 2 minutes timout should have happened if it was just 'stuck' somewhere. Henk Poley <><
Henk Poley <hpoley(a)dds.nl> writes:
Ferenc Wagner wrote:
Henk Poley <hpoley(a)dds.nl> writes:
Dimitrie O. Paun wrote:
Can you please run this .exe on your Windows box: http://afavant.elte.hu/~wferi/wine/winetest.exe
We are trying to test the winetest infrastructure.
On my (dutch) Windows 98 SE Lite (see www.litepc.net) install it needed quite a lot of user interaction. In the sense of clicking [Ok] on error boxes. Is that intentional? Should I have written them down?
It's partly intentional, but as I can't see a single Win98 report on the summary page, I have to say that in your case at least one isn't. Could you please provide some details?
If you can tell me where the partial report is stored I can send it to you.
It should be in %TEMP% with a name like res<digit>. If you can't find it, start winetest again and examine the log file name in its window. The old log file should be in the same directory.
The thing halted at the :input stuff (yes, I know, known bug), so the report was never sent. I waited 15 minutes or so, so the 2 minutes timout should have happened if it was just 'stuck' somewhere.
Now that's strange. It may sound lame, but wasn't the timeout dialog simply obscured by something else? It happened with me a couple of times... -- Thanks for taking time, Feri.
Ferenc Wagner wrote:
Henk Poley <hpoley(a)dds.nl> writes:
Ferenc Wagner wrote:
Henk Poley <hpoley(a)dds.nl> writes:
Dimitrie O. Paun wrote:
Can you please run this .exe on your Windows box: http://afavant.elte.hu/~wferi/wine/winetest.exe
We are trying to test the winetest infrastructure.
On my (dutch) Windows 98 SE Lite (see www.litepc.net) install it needed quite a lot of user interaction. In the sense of clicking [Ok] on error boxes. Is that intentional? Should I have written them down?
It's partly intentional, but as I can't see a single Win98 report on the summary page, I have to say that in your case at least one isn't. Could you please provide some details?
If you can tell me where the partial report is stored I can send it to you.
It should be in %TEMP% with a name like res<digit>. If you can't find it, start winetest again and examine the log file name in its window. The old log file should be in the same directory.
Attached, thanks to the wonders of SMB shares.
The thing halted at the :input stuff (yes, I know, known bug), so the report was never sent. I waited 15 minutes or so, so the 2 minutes timout should have happened if it was just 'stuck' somewhere.
Now that's strange. It may sound lame, but wasn't the timeout dialog simply obscured by something else? It happened with me a couple of times...
I'm pretty shure it was more or less crashed (not shure if it was in the :input phase though). At least the three finger salute showed the process as non responding. Henk Poley <><
Ferenc Wagner wrote:
Henk Poley <hpoley(a)dds.nl> writes:
The thing halted at the :input stuff (yes, I know, known bug), so the report was never sent. I waited 15 minutes or so, so the 2 minutes timout should have happened if it was just 'stuck' somewhere.
Now that's strange. It may sound lame, but wasn't the timeout dialog simply obscured by something else? It happened with me a couple of times...
Tested it again, it was/is the user32:dialog test that halts (known bug). It is 'running' for 10 minutes now... Henk Poley <><
"Dimitrie O. Paun" <dimi(a)intelliware.ca> wrote:
Can you please run this .exe on your Windows box: http://afavant.elte.hu/~wferi/wine/winetest.exe
We are trying to test the winetest infrastructure.
There are some problem with running tests under winetest. For instance user/msg test fails when running under it, but has no failures if ran as a standalone app. kernel32/pipe test binary is broken. I've recompiled it under cygwin from Wine CVS and it works for me without any single failure. Also kernel32/generated test is broken due to miscompilation by recent cygwin/mingw compilers. Regarding winetest user interface: 1. it's better to make all progress bars have the same size 2. edit windows should be replaced by static controls 3. main window should be made not resizable, otherwize it's ugly -- Dmitry.
On Wed, 21 Apr 2004, Dmitry Timoshkov wrote:
There are some problem with running tests under winetest. For instance user/msg test fails when running under it, but has no failures if ran as a standalone app.
We know, it's weird. Help fixing them is much appreciated.
kernel32/pipe test binary is broken. I've recompiled it under cygwin from Wine CVS and it works for me without any single failure.
But that means that it will use cygwin.dll instead of msvcrt, which is no good for us I'm afraid.
Also kernel32/generated test is broken due to miscompilation by recent cygwin/mingw compilers.
Is it a compiler or header problem?
Regarding winetest user interface: 1. it's better to make all progress bars have the same size
I can't say that I mind it, really.
2. edit windows should be replaced by static controls
I disagree. A read-only edit control is always better for this type of info (as you can easily copy from it), and it's standard practice in Windows GUIs.
3. main window should be made not resizable, otherwize it's ugly
Agreed. -- Dimi.
"Dimitrie O. Paun" <dimi(a)intelliware.ca> wrote:
There are some problem with running tests under winetest. For instance user/msg test fails when running under it, but has no failures if ran as a standalone app.
We know, it's weird. Help fixing them is much appreciated.
I didn't really look how winetest works and I have some other things to do so I can't help at the moment, sorry.
kernel32/pipe test binary is broken. I've recompiled it under cygwin from Wine CVS and it works for me without any single failure.
But that means that it will use cygwin.dll instead of msvcrt, which is no good for us I'm afraid.
That means that a compiler used for producing the test is broken, because both MS' cl.exe and gcc --no-cygwin produce a working binary.
Also kernel32/generated test is broken due to miscompilation by recent cygwin/mingw compilers.
Is it a compiler or header problem?
======= From: Hans Leidekker <hans(a)it.vu.nl> To: wine-devel(a)winehq.com <wine-devel(a)winehq.com> On Saturday 27 March 2004 02:20, Dmitry Timoshkov wrote:
generated.c:542: Test failed: TYPE_ALIGNMENT(*(LPWIN32_STREAM_ID)0) == 8 (expected 4) generated: 842 tests executed, 0 marked as todo, 1 failure. * NOTE: the same test compiled by cl.exe (MS compiler) works as expected, * so that's most likely a gcc bug. (gcc version 3.3.1 (cygming special))
Same here (GCC 3.2.3 (mingw special 20030504-1)). It appears that this compiler defaults to --malign-double. When I specify --mno-align-double the test succeeds. =======
Regarding winetest user interface: 1. it's better to make all progress bars have the same size
I can't say that I mind it, really.
2. edit windows should be replaced by static controls
I disagree. A read-only edit control is always better for this type of info (as you can easily copy from it), and it's standard practice in Windows GUIs.
What kind of info do you want to copy from winetest edit boxes? -- Dmitry.
On Wed, 21 Apr 2004, Dmitry Timoshkov wrote:
I didn't really look how winetest works and I have some other things to do so I can't help at the moment, sorry.
No problem, I was half joking, but also you are very good with tests, and your expertise in the matter would certainly be appreciated. As for winetest, it's very simple: it simply unpacks out xxxx_test.exe, runs them, and collects their output for submission to WineHQ.
That means that a compiler used for producing the test is broken, because both MS' cl.exe and gcc --no-cygwin produce a working binary.
Right. It seems that Feri used an old version of MinGW.
======= From: Hans Leidekker <hans(a)it.vu.nl> To: wine-devel(a)winehq.com <wine-devel(a)winehq.com>
On Saturday 27 March 2004 02:20, Dmitry Timoshkov wrote:
generated.c:542: Test failed: TYPE_ALIGNMENT(*(LPWIN32_STREAM_ID)0) == 8 (expected 4) generated: 842 tests executed, 0 marked as todo, 1 failure. * NOTE: the same test compiled by cl.exe (MS compiler) works as expected, * so that's most likely a gcc bug. (gcc version 3.3.1 (cygming special))
Same here (GCC 3.2.3 (mingw special 20030504-1)). It appears that this compiler defaults to --malign-double. When I specify --mno-align-double the test succeeds.
Paul, Kevin, Feri: it looks like we need to specify this -mno-align-double when building the tests. Should this go into Wine's Makefiles?
I disagree. A read-only edit control is always better for this type of info (as you can easily copy from it), and it's standard practice in Windows GUIs.
What kind of info do you want to copy from winetest edit boxes?
Well, they are dir names, maybe I want to paste them into Explorer to see what I have there, etc. I don't want to write the ugly name down just so I can look in there. Besides, I like the way an edit box looks for that type on info... -- Dimi.
"Dimitrie O. Paun" <dimi(a)intelliware.ca> wrote:
Same here (GCC 3.2.3 (mingw special 20030504-1)). It appears that this compiler defaults to --malign-double. When I specify --mno-align-double the test succeeds.
Paul, Kevin, Feri: it looks like we need to specify this -mno-align-double when building the tests. Should this go into Wine's Makefiles?
I think it's better to report a bug to mingw/cygwin developers, since in the default configuration their compiler produces incompatible (broken) alignment. -- Dmitry.
On Thu, 22 Apr 2004, Dmitry Timoshkov wrote:
I think it's better to report a bug to mingw/cygwin developers, since in the default configuration their compiler produces incompatible (broken) alignment.
Of course, but for now there is no harm in forcing that option in our Makefiles, is it? -- Dimi.
"Dimitrie O. Paun" <dimi(a)intelliware.ca> wrote:
I think it's better to report a bug to mingw/cygwin developers, since in the default configuration their compiler produces incompatible (broken) alignment.
Of course, but for now there is no harm in forcing that option in our Makefiles, is it?
It wouldn't cause any harm if you could ensure that adding that option to fix that particular broken gcc build will not break all other gcc based compilers out there. -- Dmitry.
"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes:
Paul, Kevin, Feri: it looks like we need to specify this -mno-align-double when building the tests. Should this go into Wine's Makefiles?
Sounds good, but I'm surely not the one to take the word of. -- Feri.
"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes:
On Wed, 21 Apr 2004, Dmitry Timoshkov wrote:
There are some problem with running tests under winetest. For instance user/msg test fails when running under it, but has no failures if ran as a standalone app.
We know, it's weird. Help fixing them is much appreciated.
Well, I didn't know, and it's the strangest thing ever. I have no idea how this could happen. *Any* clues much appreciated!
kernel32/pipe test binary is broken. I've recompiled it under cygwin from Wine CVS and it works for me without any single failure.
That would explain a couple of things. I hope the official builds won't have this problem, I can't do much about it. -- Feri.
participants (15)
-
Ben A L Jemmett -
Chris Morgan -
Dimitrie O. Paun -
Dimitrie O. Paun -
Dmitry Timoshkov -
Eric Pouech -
Ferenc Wagner -
Francois Gouget -
Henk Poley -
Jakob Eriksson -
Jakob Eriksson -
Kevin Koltzau -
Mehmet YASAR -
Paul Millar -
Shachar Shemesh