Re: buildbot status
On Mon, Aug 29, 2011 at 05:53, Dan Kegel d...@kegel.com wrote: The buildbot now uses ccache, which sped up builds tremendously. Cycle time of build slaves with ccache using is 10-11 minutes; Told you ;) From 14 mins to 10-11 mins, nice 25% speed up Although it may make things a bit slower in general for perfectly working patches at first try (extra IO to fill in the cache). However, if/once it's integrated with testbot, it should help even more (especially on slow CPUs) Frédéric
Re: Cmd tests timeout and splitting tests
On Sun, Aug 28, 2011 at 01:24, Octavian Voicu octavian.vo...@gmail.com wrote: Hello, I've noticed a lot of timeouts for cmd tests lately, which is not so surprising with all the new incoming tests. OK found them I think test_builtins.cmd should be split in a few files, which would then be run separately. An added benefit is that it would permit putting tests that affect other tests in separate files. In order to fix the timeout problem it's not enough to split the tests in different files. Each file has to be run on its own from winetest. I see following solutions: 1) Hack winetest and increase timeout just for cmd.exe batch tests. 2) Allow individual tests to receive a parameter. ... 3) Add a new source file for each .cmd file. ... I would go for number 3, I think it's the cleanest solution (although it would add a few more source files). Any comments on that? 1) would probably need to be done temporarily until a proper solution is implemented Frédéric
Re: buildbot status
011/8/29 Frédéric Delanoy frederic.dela...@gmail.com: On Mon, Aug 29, 2011 at 05:53, Dan Kegel d...@kegel.com wrote: The buildbot now uses ccache, which sped up builds tremendously. Cycle time of build slaves with ccache using is 10-11 minutes; Told you ;) From 14 mins to 10-11 mins, nice 25% speed up Although it may make things a bit slower in general for perfectly working patches at first try (extra IO to fill in the cache). However, if/once it's integrated with testbot, it should help even more (especially on slow CPUs) Yes, first build is about a minute slower with ccache, but there are so many cache hits on later runs that it's well worth it. And slower CPUs totally love ccache; for the e8400, cycle time went from 17 minutes to 11 minutes. (I'm looking forward to seeing how much it helps the celeron.) I've made two more changes that bring the cycle time down by 3 minutes, to 7-8 minutes on e8400/e9300/i7 slaves: 1) blacklist the slowest test, wininet/ftp, which took 1 minute all on its own 2) run the headless subset of tests in the background, in their own wineprefix, with DISPLAY unset. These tests don't need DISPLAY. This saves another 2 minutes. I'd say 7-8 minutes is fast enough for now. Being able to pump out a full build-and-test every 2-3 minutes from my little three-node cluster, with only 8 minutes latency, is pretty cool. - Dan
Re: Cmd tests timeout and splitting tests
Frédéric Delanoy frederic.dela...@gmail.com writes: On Sun, Aug 28, 2011 at 01:24, Octavian Voicu octavian.vo...@gmail.com wrote: Hello, I've noticed a lot of timeouts for cmd tests lately, which is not so surprising with all the new incoming tests. Which timeouts are you talking about? On windows machines? Never experienced a timeout It only times out on Wine, because cmd is too slow (reading the input char by char and other silliness). That's what should be fixed. -- Alexandre Julliard julli...@winehq.org
Re: buildbot status
2011/8/29 Dan Kegel d...@kegel.com: 011/8/29 Frédéric Delanoy frederic.dela...@gmail.com: On Mon, Aug 29, 2011 at 05:53, Dan Kegel d...@kegel.com wrote: The buildbot now uses ccache, which sped up builds tremendously. Cycle time of build slaves with ccache using is 10-11 minutes; Told you ;) From 14 mins to 10-11 mins, nice 25% speed up Although it may make things a bit slower in general for perfectly working patches at first try (extra IO to fill in the cache). However, if/once it's integrated with testbot, it should help even more (especially on slow CPUs) Yes, first build is about a minute slower with ccache, but there are so many cache hits on later runs that it's well worth it. And slower CPUs totally love ccache; for the e8400, cycle time went from 17 minutes to 11 minutes. (I'm looking forward to seeing how much it helps the celeron.) I've made two more changes that bring the cycle time down by 3 minutes, to 7-8 minutes on e8400/e9300/i7 slaves: 1) blacklist the slowest test, wininet/ftp, which took 1 minute all on its own 2) run the headless subset of tests in the background, in their own wineprefix, with DISPLAY unset. These tests don't need DISPLAY. This saves another 2 minutes. I'd say 7-8 minutes is fast enough for now. Being able to pump out a full build-and-test every 2-3 minutes from my little three-node cluster, with only 8 minutes latency, is pretty cool. - Dan Also are you doing ./configure -C? That could save you a few more minutes. Damjan
Re: kernel32: Add UDF support Based on Steven Wallace work. Should fix the wine side of bug #26273
On 08/29/2011 04:33 AM, Dan Kegel wrote:
Fails tests here?
../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p
kernel32_test.exe.so volume.c touch volume.ok
fixme:volume:DefineDosDeviceW
(0x,La:,LZ:\\home\\dank\\wineslave.dir\\sandbox\\slave\\runtests\\build\\dlls\\kernel32\\tests)
DDD_RAW_TARGET_PATH flag not set, not supported yet
volume.c:105: Tests skipped: can't test removing fake drive
fixme:volume:GetVolumeNameForVolumeMountPointW Mounted Folders are not
yet supported
volume.c:359: Test failed: GetVolumeInformationA root failed, last error 66
volume.c:401: Test failed: GetVolumeInformationA with \ failed, last error 66
volume.c:423: Test failed: GetVolumeInformationA failed, last error 66
volume.c:434: Test failed: GetVolumeInformationA failed, last error 66
volume.c:445: Test failed: GetVolumeInformationA failed, root=C:\, last error=66
volume.c:451: Test failed: GetVolumeInformationA did fail,
root=\\?\C:\, last error=66
volume.c:458: Test failed: GetVolumeInformationA did fail,
root=\\.\C:\, last error=66
volume.c:486: Test failed: GetVolumeInformationA failed,
root=\\?\Volume{----0043}\, last error=66
fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for
IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS
Command exited with non-zero status 8
0.02user 0.04system 0:00.09elapsed 80%CPU (0avgtext+0avgdata 22992maxresident)k
0inputs+0outputs (0major+5625minor)pagefaults 0swaps
make[1]: *** [volume.ok] Error 8
I tested wine-1.3.27 which have the same errors but I'm aware
GetVolumeInformation needs a bit of refactoring.
Anyway, I would like to see this one merged first.
Re: kernel32: Improve GetVolumeInformation filesystem flags I set flags value according to my tests which may differ from a windows version to another.
On 08/29/2011 04:46 AM, Dan Kegel wrote: Fails to build here, since it depends on the patch include/winnet.h: Add more GetVolumeInformation system flags, but you didn't mark them as being part of a series. See Subject Line in http://wiki.winehq.org/SubmittingPatches volume.c: In function ‘GetVolumeInformationW’: volume.c:672: error: ‘FILE_SUPPORTS_REPARSE_POINTS’ undeclared (first use in this function) volume.c:672: error: (Each undeclared identifier is reported only once volume.c:672: error: for each function it appears in.) volume.c:672: error: ‘FILE_SUPPORTS_SPARSE_FILES’ undeclared (first use in this function) volume.c:672: error: ‘FILE_VOLUME_QUOTAS’ undeclared (first use in this function) make[1]: *** [volume.o] Error 1 You probably also want to use shorter subject lines, and move more of the patch description into the body of your message. When I wrote the description of the patch using git commit, I wrote kernel32: Improve GetVolumeInformation filesystem flags as the title and the remaining part on a new line (to make it a comment). If I look at my commit with GitWeb locally, the title is short and my comment is on a separate line. I'm probably missing something. Do you know how to move [...] description into the body (except manual editing before sending them) ? And concerning your first remark, I forgot the -n parameter to git format-patch. But before resending my patches, I would fix this long-subject-line issue.
Re: kernel32: Improve GetVolumeInformation filesystem flags I set flags value according to my tests which may differ from a windows version to another.
On Mon, Aug 29, 2011 at 14:41, GOUJON Alexandre ale.gou...@gmail.com wrote: When I wrote the description of the patch using git commit, I wrote kernel32: Improve GetVolumeInformation filesystem flags as the title and the remaining part on a new line (to make it a comment). If I look at my commit with GitWeb locally, the title is short and my comment is on a separate line. I'm probably missing something. There should be a blank line between the commit title and potential subsequent comments. That's probably the explanation.
The state of IDirectSoundBuffer
Hello guys, my tests: - http://source.winehq.org/patches/data/78080 - http://winetestbot.winehq.org/JobDetails.pl?Key=13790 - http://winetestbot.winehq.org/JobDetails.pl?Key=13791 - http://winetestbot.winehq.org/JobDetails.pl?Key=13792 - http://winetestbot.winehq.org/JobDetails.pl?Key=13793 show that native dsound has only one IDirectSoundBuffer implementation. That shouldn't matter as per the COM rules that is an implementation detail but there are broken apps out there (http://bugs.winehq.org/show_bug.cgi?id=28207) that rely on that fact. Not sure how many of the crashes due to dsound http://bugs.winehq.org/buglist.cgi?cmdtype=runnamednamedcmd=dsound can be traced to that as PrimaryBufferImpl and IDirectSoundBufferImpl had (before my dsound changes) only the first three fields in common. Well PrimaryBufferImpl has only three fields as it stores its info in its parent object aka the device (this is a very common design in our dsound). Keeping the two objects/implementations in sync is brittle and will litter the code. Thus my goal is to merge PrimaryBufferImpl into IDirectSoundBufferImpl. My plan of battle is (to keep the patches small and limit the scope of the regressions I'll introduce during this): - Make the primary buffer use struct IDirectSoundBufferImpl. - Move fields that belong to the primary buffer out of struct DirectSoundDevice. The structs DirectSoundDevice and IDirectSoundBufferImpl share quite a few fields. - For methods that have the same implementation I'll use the IDirectSoundBufferImpl_Method - Methods that differ considerably between primary and secondary buffer I'll make IDirectSoundBufferImpl_Method just a wrapper that calls out into the respective implementation, something along the lines of: if(is_primary) return primarybuffer_method(...); else return secondarybuffer_method(...); - Once all methods are converted I'll switch the primary buffer to use the same vtbl. - Profit! Comments? bye michael
Re: crytpui/tests: Add tests for CryptUIDlgSelectCertificateA.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=13801 Your paranoid android. === W7PROX64 (64 bit cryptui) === cryptui.c:806: Test failed: expected ERROR_SUCCESS, got 80070057 cryptui.c:840: Test failed: expected ERROR_SUCCESS, got 80070057 cryptui.c:846: Test failed: CryptUIDlgSelectCertificate failed: 80070057 cryptui.c:857: Test failed: CryptUIDlgSelectCertificate failed: 80070057 cryptui.c:869: Test failed: CryptUIDlgSelectCertificate failed: 80070057 cryptui.c:871: Test failed: display callback was not called cryptui.c:873: Test failed: the dialog box did not display certificate cryptui.c:879: Test failed: CryptUIDlgSelectCertificate failed: 80070057 cryptui.c:881: Test failed: display callback was not called cryptui.c:891: Test failed: CryptUIDlgSelectCertificate failed: 80070057 cryptui.c:899: Test failed: CryptUIDlgSelectCertificate failed: 80070057 cryptui.c:901: Test failed: TabCtrl_SetCurSel returned -559038737
Re: kernel32: Improve GetVolumeInformation filesystem flags I set flags value according to my tests which may differ from a windows version to another.
On 08/29/2011 02:49 PM, Frédéric Delanoy wrote: On Mon, Aug 29, 2011 at 14:41, GOUJON Alexandreale.gou...@gmail.com wrote: When I wrote the description of the patch using git commit, I wrote kernel32: Improve GetVolumeInformation filesystem flags as the title and the remaining part on a new line (to make it a comment). If I look at my commit with GitWeb locally, the title is short and my comment is on a separate line. I'm probably missing something. There should be a blank line between the commit title and potential subsequent comments. That's probably the explanation. I just tested and you're right ! Darn emty line...
Re: The state of IDirectSoundBuffer
On Mon, Aug 29, 2011 at 02:53:51PM +0200, Michael Stefaniuc wrote: Comments? Makes sense to me. Good luck ;) I'm sure you'll keep us posted. Andrew
Re: Documenting WineTest best practices
On Wed, 24 Aug 2011, Francois Gouget wrote: [...] * Similarly on Vista and Windows 7 UAC comes into play. I believe it mostly causes some tests to be skipped. So again, are there recommandations around this? * Are we interested in tests being run as an administrator or a regular user? Both? On my Windows 7 VM WineTest is not running with elevated privileges. This is what causes the advpack:install test to time out: http://test.winehq.org/data/6a6aab27633405aeb5e464943110960f0099dffe/index_Win7.html#advpack:install The reason is that the calls listed below cause Windows 7 to bring up a dialog telling me I need administrator privileges: You do not have administrator privileges on this machine. This installation cannot be completed correctly unless it is run by an administrator. Furthermore I get this issue even if I set UAC to 'Never notify'. I think the tests should work in both elevated and non-elevated privilege accounts. So this probably means detecting the non-elevated case and skipping some tests. Or finding a way to tell Windows not to bring up that dialog and just fail. hr = pRunSetupCommand(NULL, path, DefaultInstall, dir, Title, NULL, RSC_FLAG_INF | RSC_FLAG_QUIET, NULL); hr = pRunSetupCommand(NULL, path, DefaultInstall, , Title, NULL, RSC_FLAG_INF | RSC_FLAG_QUIET, NULL); hr = pRunSetupCommand(NULL, one\\test.inf, DefaultInstall, dir, Title, NULL, RSC_FLAG_INF | RSC_FLAG_QUIET, NULL); hr = pRunSetupCommand(NULL, one\\test.inf, DefaultInstall, dir, Title, NULL, RSC_FLAG_INF | RSC_FLAG_QUIET, NULL); hr = pRunSetupCommand(NULL, one\\test.inf, DefaultInstall, , Title, NULL, RSC_FLAG_INF | RSC_FLAG_QUIET, NULL); hr = pLaunchINFSection(NULL, NULL, cmdline, 0); hr = pLaunchINFSection(NULL, NULL, file, 0); hr = pLaunchINFSectionEx(NULL, NULL, cmdline, 0); -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ E-Voting: It's not the people who vote that count. It's the people who count the votes.
Re: cmd: Don't parse colons as stream separators when splitting paths.
On Sun, Aug 28, 2011 at 00:39, Octavian Voicu octavian.vo...@gmail.com wrote: Fixes an infinite recursion when running a command such as del file.txt /S in a directory that has some subdirectory with a colon in its name. The filename:stream syntax can be used on native to access alternate data streams on NTFS partitions. Such support would obviously need to be implemented by the underlying filesystem, so there is no point in parsing this is Wine. --- programs/cmd/batch.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/programs/cmd/batch.c b/programs/cmd/batch.c index 03c92ee..bbefcfb 100644 --- a/programs/cmd/batch.c +++ b/programs/cmd/batch.c @@ -222,8 +222,8 @@ void WCMD_splitpath(const WCHAR* path, WCHAR* drv, WCHAR* dir, WCHAR* name, WCHA } else if (drv) *drv = '\0'; - /* search for end of string or stream separator */ - for(end=path; *end *end!=':'; ) + /* search for end of string */ + for(end=path; *end; ) end++; /* search for begin of file extension */ -- Might be a good idea to add a simple testcase
Re: kernel32: Improve GetVolumeInformation filesystem flags I set flags value according to my tests which may differ from a windows version to another.
On Mon, Aug 29, 2011 at 5:41 AM, GOUJON Alexandre ale.gou...@gmail.com wrote: You probably also want to use shorter subject lines, and move more of the patch description into the body of your message. When I wrote the description of the patch using git commit, I wrote kernel32: Improve GetVolumeInformation filesystem flags as the title and the remaining part on a new line (to make it a comment). If I look at my commit with GitWeb locally, the title is short and my comment is on a separate line. I'm probably missing something. I think you need a blank line. The text before the blank line becomes the subject; the text after the blank line becomes the body. - Dan
re: [3/3] (resend) usp10: draw selected glyphs in ScriptStringOut
Hi Aric, did you forget to include Makefile.in changes with your patch? It failed to build here: http://buildbot.kegel.com/builders/runtests/builds/70 ccache gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_USER32_ -D_WINABLE_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O0 -o spy.o spy.c usp10.o: In function `SS_ItemOut': /home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/usp10/usp10.c:1061: undefined reference to `GetSysColor' /home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/usp10/usp10.c:1065: undefined reference to `GetSysColor' /usr/bin/ld: usp10.dll.so: hidden symbol `GetSysColor' isn't defined /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status winegcc: ccache failed make[1]: Leaving directory `/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/usp10' make[1]: *** [usp10.dll.so] Error 2
Re: Hebrew: update
On Sun, 28 Aug 2011, Shachar Shemesh wrote: [...] Yes. It's called type. Take a Hebrew text stored in a Windows 1255 encoded file, and type file, see what happens. The order, if I understand this correctly, will be logical. The Windows 7 console does not even support displaying the Hebrew characters. My understanding is that this is because the only fonts it lets you pick are lacking the required characters. I tested this by creating a Unicode file with notepad (which displayed everything fine, in Windows 7), containing: --- Hello שלום --- The first line was ok but the second one was either question marks or squares. The only fonts Windows will let me pick are 'Consolas', 'Lucida Console' and 'Raster Fonts'. -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ E-Voting: Those who cast the votes decide nothing. Those who count the votes decide everything.
Re: cmd: Don't parse colons as stream separators when splitting paths.
2011/8/29 Frédéric Delanoy frederic.dela...@gmail.com Might be a good idea to add a simple testcase Not sure yet how native is going to handle this, because windows doesn't allow colons in filenames. I submitted a job to the testbot to check this [1]. Alexandre already committed the patch, so if native passes the test I can send a test for the next iteration. On the other hand, if native chokes on the colon, then we shouldn't add any testcases. If it works, might also throw a @pwd@ in there. Octavian [1] https://testbot.winehq.org/JobDetails.pl?Key=13807
Re: [1/5] ddraw: Introduce a function to convert a DDSURFACEDESC to a DDSURFACEDESC2
On 29 August 2011 19:20, Stefan Dösinger ste...@codeweavers.com wrote: +/* Note that this function writes the full sizeof(DDSURFACEDESC2) size, don't use it So no need to clear it first.
Re: Hebrew: update
On 08/29/2011 07:57 PM, Francois Gouget wrote: On Sun, 28 Aug 2011, Shachar Shemesh wrote: [...] Yes. It's called "type". Take a Hebrew text stored in a Windows 1255 encoded file, and "type file", see what happens. The order, if I understand this correctly, will be logical. The Windows 7 console does not even support displaying the Hebrew characters. My understanding is that this is because the only fonts it lets you pick are lacking the required characters. I tested this by creating a Unicode file with notepad (which displayed everything fine, in Windows 7), containing: Yes, it does not support Unicode. That's why I said "1255", as in "Windows 1255", the ANSI encoding for Hebrew. The first line was ok but the second one was either question marks or squares. The only fonts Windows will let me pick are 'Consolas', 'Lucida Console' and 'Raster Fonts'. It should let you pick any monospace font. At least one of those should contain a Hebrew encoding. If not, you might need to set the default locale to Hebrew in order to test this (which will only be possible after clicking "add support for complex text layout languages", or something to similar effect, in Regional Settings). This will also install the Hebrew fonts. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Re: [2/2] net: Add support for enumerating the running services with 'net start'.
On Fri, Aug 26, 2011 at 17:41, Francois Gouget fgou...@codeweavers.com wrote: --- Quite useful to see what services are actually running. programs/net/net.c | 55 - programs/net/net.rc | 4 ++- programs/net/resources.h | 2 + 3 files changed, 58 insertions(+), 3 deletions(-) diff --git a/programs/net/net.c b/programs/net/net.c index 249c14d..ed26b43 100644 + STRING_RUNNING, %s\n This one is not particularly translatable.
Re: Hebrew: update
On Mon, 29 Aug 2011, Shachar Shemesh wrote: [...] Yes, it does not support Unicode. That's why I said 1255, as in Windows 1255, the ANSI encoding for Hebrew. It does support Unicode (UTF-16) otherwise 'Hello' would have not been displayed correctly. Furthermore I also tested with a Windows 1255 encoded and did not have any luck with it either. The first line was ok but the second one was either question marks or squares. The only fonts Windows will let me pick are 'Consolas', 'Lucida Console' and 'Raster Fonts'. It should let you pick any monospace font. At least one of those should contain a Hebrew encoding. If not, you might need to set the default locale to Hebrew in order to test this (which will only be possible after clicking add support for complex text layout languages, or something to similar effect, in Regional Settings). This will also install the Hebrew fonts. I am only given the three font choices I listed. Also I did test this in a Hebrew locale. I did not have to check an 'add support for complex text layout languages' option however. All I did was go to the Windows Update site and select the Hebrew support option. -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ Linux: the choice of a GNU generation
Re: [2/2] net: Add support for enumerating the running services with 'net start'.
On Mon, 29 Aug 2011, Frédéric Delanoy wrote: [...] diff --git a/programs/net/net.c b/programs/net/net.c index 249c14d..ed26b43 100644 + STRING_RUNNING, %s\n This one is not particularly translatable. That's quite true. I'll send a patch to remove it. -- Francois Gouget fgou...@codeweavers.com
Re: [1/5] ddraw: Introduce a function to convert a DDSURFACEDESC to a DDSURFACEDESC2
On Monday 29 August 2011 19:40:13 Henri Verbeet wrote: On 29 August 2011 19:20, Stefan Dösinger ste...@codeweavers.com wrote: +/* Note that this function writes the full sizeof(DDSURFACEDESC2) size, don't use it So no need to clear it first. Well, the clear is part of the code that writes to the structure. The rest of the code only writes members that are set in the source DDSURFACEDESC. signature.asc Description: This is a digitally signed message part.
Re: [3/5] ddraw: Convert dwZBufferBitDepth into a DDPIXELFORMAT
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=13809 Your paranoid android. === W2KPROSP4 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === WXPPROSP3 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W2K3R2SESP2 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === WVISTAADM (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W2K8SE (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W7PRO (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W7PROX64 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W7PROX64 (64 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091.
Re: [wine-devel] Re: Severe regression in wine startup latencies
On 2011-08-29 07:56+1000 Ben Peddell wrote: On 29/08/2011 2:37 AM, Alan W. Irwin wrote: bash.exe-3.1$ time /z/home/wine/newstart1/MinGW/msys/1.0/bin/echo.exe hello hello real0m0.503s user0m0.080s sys 0m0.020s Also, I tried time (x; x; x; x; x; x; x; x; x; x), where x represents the complete echo command above, and the result was real0m5.281s user0m0.800s sys 0m0.200s [snip] While I am doing those additional investigations, please consider the question of why there is a huge difference between built-in and executable latency for MSYS bash commands under wine. To start that investigation it would be good to compare the wine results for those two cases with the Windows results for those two cases. (I assume the two time results for built-in versus executable will be fairly similar in the Windows case, but that assumption needs to be checked.) I don't have access to Windows myself. Anybody up for doing that simple test and reporting the results back here? The automatic MinGW/MSYS installer at http://sourceforge.net/projects/mingw/files/Automated MinGW Installer/mingw-get-inst/ makes it easy to install the relevant MinGW/MSYS software on both wine and Windows. Under MSYS 1.0.17 running on Windows 7 x64 SP1: bash.exe-3.1$ /bin/bash --version GNU bash, version 3.1.17(1)-release (i686-pc-msys) Copyright (C) 2005 Free Software Foundation, Inc. bash.exe-3.1$ alias x='/bin/echo.exe -n .' bash.exe-3.1$ time x . real0m0.031s user0m0.000s sys 0m0.015s bash.exe-3.1$ time (x;x;x;x;x;x;x;x;x;x) .. real0m0.296s user0m0.075s sys 0m0.136s This shows a latency of approximately 2 jiffies for each command - 1 jiffy in Windows is 15.6ms. -- Ben Peddell IT Support Bowen, Collinsville, Proserpine and Home Hill Catholic schools http://klightspeed.killerwolves.net/ Thanks, Ben, for doing the requested test for the executable echo test. That shows the Windows startup latency is measureable but acceptable for that executable. Just out of curiosity, what happens for the corresponding bash executable built-in echo functionality? Is it essentially instantaneous (i.e., elapsed time less than 0.001 seconds) like in the wine case? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __
Re: [4/5] ddraw: Set dwZBufferBitDepth in old z buffers
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=13810 Your paranoid android. === W2KPROSP4 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === WXPPROSP3 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W2K3R2SESP2 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === WVISTAADM (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W2K8SE (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W7PRO (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W7PROX64 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W7PROX64 (64 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091.
Re: [5/5] ddraw: Add a test for DDSD_ZBUFFERBITDEPTH and DDSD_PIXELFORMAT
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=13811 Your paranoid android. === W2KPROSP4 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === WXPPROSP3 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W2K3R2SESP2 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === WVISTAADM (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W2K8SE (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W7PRO (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W7PROX64 (32 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091. === W7PROX64 (64 bit dsurface) === dsurface.c:3878: Test failed: IDirectDraw_CreateSurface failed, hr 0x88760091.
Re: [1/5] ddraw: Introduce a function to convert a DDSURFACEDESC to a DDSURFACEDESC2
On 29 August 2011 20:53, Stefan Dösinger ste...@codeweavers.com wrote: On Monday 29 August 2011 19:40:13 Henri Verbeet wrote: On 29 August 2011 19:20, Stefan Dösinger ste...@codeweavers.com wrote: +/* Note that this function writes the full sizeof(DDSURFACEDESC2) size, don't use it So no need to clear it first. Well, the clear is part of the code that writes to the structure. The rest of the code only writes members that are set in the source DDSURFACEDESC. If they aren't set in the source structure we should never read them anyway.
Re: winspool.drv/tests: Fix tracing a NULL string
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=13819 Your paranoid android. === WINEBUILD (build) === Can't determine base name
Re: [1/5] ddraw: Introduce a function to convert a DDSURFACEDESC to a DDSURFACEDESC2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 29.08.2011 um 21:38 schrieb Henri Verbeet: On 29 August 2011 20:53, Stefan Dösinger ste...@codeweavers.com wrote: On Monday 29 August 2011 19:40:13 Henri Verbeet wrote: On 29 August 2011 19:20, Stefan Dösinger ste...@codeweavers.com wrote: +/* Note that this function writes the full sizeof(DDSURFACEDESC2) size, don't use it So no need to clear it first. Well, the clear is part of the code that writes to the structure. The rest of the code only writes members that are set in the source DDSURFACEDESC. If they aren't set in the source structure we should never read them anyway. Technically that's true for this specific function since the result is only used by our code and never the application. Yet I prefer to keep the memset for consistency with other code that handles DDSURFACEDESC(2) structures. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJOW+6PAAoJEN0/YqbEcdMw9Q4QAIzL0rJ/RQ+pz2eS2Bm6Ojf2 aiOLyWe5Bwuc+qBL3uvt+l+L/PiUQSHXCViDyjvOlZL9IK/fdVfcEDLiWd8/884N FV9NtnR0MB5nUwOHpZYk70zXocY+Fyi47b7yuC0SC9DU8Pf1y+MvvTyu30GC8T5t J/vG6LLUlkuSDSsmomg5GAAEEGEst25D21m9nVlt8IiaaqP1oNdsshSwh3FWjP7w PmVR1Pzi2gNIyhRrXuTasbHFtgME4HwUrjgglRe4R/dacMopfLAHM+swxHQykgmw HGLYsRhKFMoegsAsiAkIARyF4Oc73uJaVdhcBP/mRXPcGBT93cICV69XbNgGJ7AN xdEfxFWVujCF0x94KTC1XLEt+sM1bkjlIoITcPsqEjbrm16jU3jtuSLL58KAOtsh QVlksMQ8b3Fo0zY/tKzucBQoAZpDgMJY4EvkfcB5HLqIRlHHK/ZzMhe6vjEzZfZn 0ELwEl2+QRaAITLEnmK8DxL/PtI9unemLAeOOZkigi8ooeo6KVOM5g5VqCqhEhMp XNi1yQdkINthCZpPqDWnx9SnYJS3bqlUqXHi+SoZnuwBc41AFctsYjPVeRnIF6Sm zf6Ae7MD2piA/elrHlCyQfS5CQWUmkY0xNZDGHD0sBEsh5SYFFbPoM4kJAKJZrTq OJR39TbofSSvpESIua2n =Mzq4 -END PGP SIGNATURE-
Re: [PATCH] explorer: Try ShellExecute if the parameter isn't a directory (try 2)
On 08/29/2011 04:08 AM, Jay Yang wrote: Changes from last time: Fixed a build issue. --- programs/explorer/Makefile.in |2 +- programs/explorer/explorer.c |4 2 files changed, 5 insertions(+), 1 deletions(-) sorry, thunderbird seems to have sent to old file
winelib an fpc
best regards
I would like to know
if it is possible to use the wine libraries with freepascal compiler.
kylix had a modified version of the wine libraries and I believe that it was
possible to invoke them from pascal.
I've tried several ways but all I get is segment fault.
sorry for my English.
Thanks.
program test01;
{$MODE Delphi}
uses types;
Type
BOOL = LongBool;
function GetCursorPos(var lpPoint: TPoint): BOOL; stdcall; external
'libuser32.so' name 'GetCursorPos';
var
a:Tpoint;
begin
WriteLn('Calling wine function');
GetCursorPos(a);
WriteLn('End Calling wine function');
WriteLn(a.x);
end.
program test02;
{$Mode Delphi}
uses sysutils,types;
Type
BOOL = LongBool;
TGetCursorPos=Function(var lpPoint: TPoint): BOOL;cdecl;
Function dlopen(name: pchar;mode: longint):pointer;cdecl;external 'dl';
Function dlsym(lib: pointer; name: pchar):pointer;cdecl;external 'dl';
Function dlclose(lib: pointer):longint;cdecl;external 'dl';
var
lib : pointer;
GetCursorPos:TGetCursorPos;
a:Tpoint;
begin
lib:=dlopen('/usr/lib/wine/user32.dll.so',1);
if lib nil then
@GetCursorPos:=dlsym(lib,'GetCursorPos')
else begin
WriteLn('library not loaded');
exit;
end;
if Assigned(GetCursorPos) then begin
WriteLn('Calling GetCursorPos');
Try
GetCursorPos(a);
Except
on E : Exception do WriteLn(E.Message);
end;
WriteLn('X:',a.x,' Y:',a.Y);
end
else begin
WriteLn('function not loaded');
exit;
end;
dlclose(lib);
end.
--
*
En la tierra hace falta personas que trabajen más y critiquen menos,
que construyan más y destruyan menos, que prometan menos y
resuelvan más que esperen recibir menos y dar más que digan mejor
ahora que mañana.
Che
*
--
*
En la tierra hace falta personas que trabajen más y critiquen menos,
que construyan más y destruyan menos, que prometan menos y
resuelvan más que esperen recibir menos y dar más que digan mejor
ahora que mañana.
Che
*
Re: buildbot status
On Sun, Aug 28, 2011 at 8:53 PM, Dan Kegel d...@kegel.com wrote: I hope to turn on email notifications sometime this week. Buildbot is now sending email on failure. There are two caveats: - it's emailing directly from a cable modem, not using an smtp relay, so some mail systems may think it's spam - buildbot currently explodes while attaching patches to status emails if the patch contains a non-ascii character, http://trac.buildbot.net/ticket/2091 (I'll probably work around this by disabling the attachment.) Future status updates will go to http://wiki.winehq.org/BuildBot - Dan
Re: winelib an fpc
On Mon, Aug 29, 2011 at 2:05 PM, Reinier Napoles Martinez
rnapo...@hlg.uci.cu wrote:
lib:=dlopen('/usr/lib/wine/user32.dll.so',1);
This won't work. Simply doing a dlopen on the wine libraries won't get
your environment setup properly.
--
Steven Edwards
There is one thing stronger than all the armies in the world, and
that is an idea whose time has come. - Victor Hugo
Re: winelib an fpc
This won't work. Simply doing a dlopen on the wine libraries won't get your environment setup properly. what can i do then to setup the wine environment correctly and use the wine libraries from fpc. thanks -- * En la tierra hace falta personas que trabajen más y critiquen menos, que construyan más y destruyan menos, que prometan menos y resuelvan más que esperen recibir menos y dar más que digan mejor ahora que mañana. Che *
Re: buildbot status
On Mon, Aug 29, 2011 at 23:41, Dan Kegel d...@kegel.com wrote: On Sun, Aug 28, 2011 at 8:53 PM, Dan Kegel d...@kegel.com wrote: I hope to turn on email notifications sometime this week. Buildbot is now sending email on failure. There are two caveats: - it's emailing directly from a cable modem, not using an smtp relay, so some mail systems may think it's spam - buildbot currently explodes while attaching patches to status emails if the patch contains a non-ascii character, http://trac.buildbot.net/ticket/2091 (I'll probably work around this by disabling the attachment.) Alternatively, avoid attaching patches containing .po or .rc files
Re: buildbot status
2011/8/29 Frédéric Delanoy frederic.dela...@gmail.com: - buildbot currently explodes while attaching patches to status emails if the patch contains a non-ascii character, http://trac.buildbot.net/ticket/2091 (I'll probably work around this by disabling the attachment.) Alternatively, avoid attaching patches containing .po or .rc files The patch that caused the problem choked on the first line, From: name-with-accent So it's not just .po files that cause the problem. I've disabled the attachment code, and am tweaking the message formatting now. Apologies for spamming patch authors with buildbot status results... the current buildbot crashes if you don't send results to the author, or I'd disable the messages. - Dan
Re: cmd: Don't parse colons as stream separators when splitting paths.
2011/8/29 Octavian Voicu octavian.vo...@gmail.com Alexandre already committed the patch, so if native passes the test I can send a test for the next iteration. On the other hand, if native chokes on the colon, then we shouldn't add any testcases. If it works, might also throw a @pwd@ in there. I've got the results, see [2]. I tried doing cd to a foo:bar directory, but it fails on Windows. Not sure what's with all the extra failures, but except tests on NT (where %cd% is broken) the second %cd% shows that either the directory was not created, or cd failed to that directory. I guess we could throw in the test without the echo %cd% part, but I'm not sure if it wouldn't affect subsequent tests -- if cd fails, then cd .. will go one level upper. Not sure if the test is worth the trouble... Octavian [2] https://testbot.winehq.org/JobDetails.pl?Key=13828
Where is the best place to report a fscanf bug found under wine-1.3.27?
Today I discovered while debugging a fairly complex application that I
built under MinGW/MSYS/wine that the scanf family of functions was
introducing float (32-bit floating-point) noise into double (64-bit
floating-point) results.
I implemented a simple test code to make it extremely easy to
replicate this issue:
cat test_fscanf.c
#include stdlib.h
#include stdio.h
void
main(void)
{
double x;
while(fscanf(stdin, %le , x) == 1)
{
printf(%25.17e\n, x);
}
}
On Linux you can build it and run it with these expected results with
some numerical noise in the last place:
gcc test_fscanf.c
echo 1.1e+01
1.1e+00
1.1e-01
1.1e-02
1.1e-03
1.1e-04 | ./a.out
1.1e+01
1.10009e+00
1.10001e-01
1.09994e-02
1.10007e-03
1.10004e-04
But if you do the same build on wine you get these noisy results for
all the values with negative exponents (but positive exponents are
fine for some reason).
echo 1.1e+01
1.1e+00
1.1e-01
1.1e-02
1.1e-03
1.1e-04 | ./a.exe
1.1e+001
1.10009e+000
1.1001639127737e-001
1.1003278255491e-002
1.1004917383261e-003
1.1006556511075e-004
The level of noise is consistent with some float (as opposed to
double) logic incorrectly being used in the fscanf library function
for negative exponents, and I had similar bad numerical noise results
from sscanf with my complex application.
My hardware is 64-bit. My wine is 32-bit wine-1.3.27
built on a Debian Squeeze box
with the standard 32-bit Debian build dependencies for wine. The wine
gcc is from the MinGW version you get with the automatic
MinGW/MSYS installer from a few days ago. It's version
number is
bash.exe-3.1$ gcc --version
gcc.exe (GCC) 4.5.2
...
The above wine test was run in a wineconsole running
the MSYS version of bash.
So for my wine installation (which has no access to Microsoft
libraries), how can I find out which library is providing the fscanf
functionality that is introducing float noise into double results
for the above test programme? I need that information so that
I can properly report the above bug.
If someone here knows exactly where to make the fix and is inspired to
do so, I would be happy to test the result with my more complex
ephcom2 application (reading and interpolating JPL ephemerides, see
http://sourceforge.net/news/?group_id=567377id=302987 for the latest
release announcement). That release was POSIX only, but I hope to
make the next version work properly on Windows as well. The current
status is that ephcom2 builds and mostly tests well under wine except
for the above numerical noise in sscanf results which I would like to
get rid of to see if there are any other remaining generic Windows
issues in the software.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__
Linux-powered Science
__
Re: Severe regression in wine startup latencies
On 29/08/2011 2:37 AM, Alan W. Irwin wrote:
While I am doing those additional investigations, please consider
the question of why there is a huge difference between built-in and
executable latency for MSYS bash commands under wine. To start
that investigation it would be good to compare the wine results
for those two cases with the Windows results for those two cases.
(I assume the two time results for built-in versus executable will
be fairly similar in the Windows case, but that assumption needs to
be checked.) I don't have access to Windows myself. Anybody up for
doing that simple test and reporting the results back here? The
automatic MinGW/MSYS installer at
http://sourceforge.net/projects/mingw/files/Automated MinGW
Installer/mingw-get-inst/ makes it easy to install the relevant
MinGW/MSYS software on both wine and Windows.
Some things I have seen while investigating:
I created a program which had a startup that immediately called
ExitProcess to attempt to eliminate most of the initialization of the
process being forked.
On Windows 7 x64 SP1 on an AMD 5050e:
* bash.exe takes about 22.2ms to execute a program.
* make.exe takes about 8.8ms to execute a program.
* cmd.exe takes about 5.9ms to execute a program.
Under wine 1.2.1 on linux 2.6.38 on an AMD 5050e:
* bash.exe takes about 236ms to execute a program.
* bash.exe takes about 182ms to execute ${MINGW}/bin/true.
* make.exe takes about 77ms to execute a program.
* make.exe takes about 25ms to execute ${MINGW}/bin/true.
* wine-cmd takes about 9ms to execute a program.
Under wine-git on linux 2.6.38 on an AMD 5050e:
* bash.exe takes about 190ms to execute a program.
* bash.exe takes about 147ms to execute ${MINGW}/bin/true.
* make.exe takes about 71ms to execute a program.
* make.exe takes about 20ms to execute ${MINGW}/bin/true.
* wine-cmd takes about 9ms to execute a program.
Even the native bash takes twice as long to fork as make - 1.1ms vs
0.5ms.
It looks to me like the fork emulation in MSYS is encountering a
bottleneck, and not actual process creation. Times have actually
improved between 1.2 and current.
-- Ben Peddell IT Support Bowen, Collinsville, Proserpine and Home
Hill Catholic schools http://klightspeed.killerwolves.net/
