Re: [4/6] kernel32: Make serial tests self-contained.
* On Thu, 15 Aug 2013, Dmitry Timoshkov wrote: dlls/kernel32/tests/comm.c | 284 ++--- 1 file changed, 167 insertions(+), 117 deletions(-) ... --- a/dlls/kernel32/tests/comm.c +++ b/dlls/kernel32/tests/comm.c @@ -1486,7 +1588,7 @@ static void test_WaitRing(HANDLE hcom) success, err, evtmask, after-before, after1-before); ok(evtmask EV_RING, Failed to detect EV_RING: 0x%08x, expected 0x%08x\n, - evtmask, EV_RING); + evtmask, EV_CTS); Is everything OK with the constants here? S.
Re: [0/13] Patch series description
* On Sat, 23 Feb 2013, André Hentschel wrote: Am 22.02.2013 15:09, schrieb Saulius Krasuckas: * On Thu, 21 Feb 2013, André Hentschel wrote: So where do we go from here? Right to the binary translation (or even dynamic recompilation), I guess. I won't do that, and i guess there's not much interest out there for someone else to do it, so have fun :) OK, I understand this. And by main part it probably belongs to different project (qemu-user, I guess). S.
Re: [0/13] Patch series description
* On Thu, 21 Feb 2013, André Hentschel wrote: Am 21.02.2013 21:31, schrieb Saulius Krasuckas: because I've got new(er) Sparc machine. You know that you most likely won't ever be able to run x86 apps on that machine, only winelib. Do you need that for something? Yes, I am aware of endianess issue found by Darwine people when integrating it with Qemu to run x86/PE binaries on PowerPC: http://wiki.winehq.org/MacOSX It is said byteswapping isn't worth trouble but if Rosetta did it (only in reverse direction) isn't this issue only about developers work time and not about performance? Then it seems Sparc V9 can switch to little endian to access data. So where do we go from here? Right to the binary translation (or even dynamic recompilation), I guess. S.
Re: [0/13] Patch series description
* On Thu, 21 Feb 2013, André Hentschel wrote: Really? :) I mean this was 2004, and it doesn't look like you took action on this. Did you read e.g. http://wiki.winehq.org/SPARC or http://bugs.winehq.org/show_bug.cgi?id=24142 in the meantime? Well, I didn't took actions but such intention is still present. Just because I've got new(er) Sparc machine. I've been reading this wiki page from time to time but haven't been into the bugreport. Thanks for it:) S.
Re: [0/13] Patch series description
* On Wed, 20 Feb 2013, André Hentschel wrote: this patch series removes the broken SPARC support. Reasons: * It's broken, i wasted enough time already trying to fix that It's sad to hear. Can you be more verbose on brokenness, please? Eg. namely what Sparc platform were you using for development? * Nobody cares - I sent an e-mail to everyone ever related to Wine/SPARC based on addresses from our mailing lists - no answer in a week (and cw also has no customers for it) You didn't catch this then: http://www.winehq.org/pipermail/wine-devel/2004-October/030355.html I care :) * If someone _would_ care the right thing to do would be a clean SPARC 64-bit port So, the old port was 32-bit or mixed or what? * It really can confuse people (more than a ARM/ARM64 port xD) You mean random readers about host platforms Wine runs on;)? * SPARC is dead on the Desktop :( And last but not least: I had a bad experience with the Solaris community regarding Wine/SPARC Oh. Is there any related public messages on the net? It would interesting to read and know those stories. S.
Re: Compiling Wine on Mac OS X 10.8.2?
* On Sun, 3 Feb 2013, Jeremiah Flerchinger wrote: Is anyone compiling Wine from the git repository for OS X version 10.8.2? Not me... At first I thought I broke my toolchain and could no longer compile Wine at all, but this is not the case. I can still compile old releases, but can no longer compile from git. ... but I would try running a regression test (git bisect) in your case. S.
Re: [PATCH] netapi32/tests: Fix workstation test failures on XP
* On Tue, 13 Nov 2012, Detlef Riekenberg wrote:
The workstation service might not running
http://test.winehq.org/data/b5d96da32f955357b7d9341ee9fca68108078dce/xp_s2-sp2-nosnd/netapi32:wksta.html
Indeed it isn't. I've disabled serveral services on this box.
--- a/dlls/netapi32/tests/wksta.c
+++ b/dlls/netapi32/tests/wksta.c
@@ -79,12 +79,17 @@ static void run_wkstausergetinfo_tests(void)
LPWKSTA_USER_INFO_1 ui1 = NULL;
LPWKSTA_USER_INFO_1101 ui1101 = NULL;
DWORD dwSize;
+NET_API_STATUS rc;
/* Level 0 */
-ok(pNetWkstaUserGetInfo(NULL, 0, (LPBYTE *)ui0) == NERR_Success,
- NetWkstaUserGetInfo is unsuccessful\n);
+rc = pNetWkstaUserGetInfo(NULL, 0, (LPBYTE *)ui0);
+if (rc == NERR_WkstaNotStarted)
+{
+skip(Workstation service not running\n);
+return;
+}
+ok(!rc ui0, got %d and %p (expected NERR_Success and != NULL\n, rc,
ui0);
No to blame you, this is just generic inquiry for developers.
Won't it be better to check service status directly in such case?
S.
on UTF-8, other Unicode encodings and WinAPI
Proposal with probably several insights: http://www.utf8everywhere.org/ Lyrical, older version: http://www.joelonsoftware.com/articles/Unicode.html S.
Survey about gaming on linux
The post: http://www.linuxforums.org/forum/coffee-lounge/192526-survey-about-gaming-linux.html The results containing one item about using Wine: https://docs.google.com/spreadsheet/viewanalytics?formkey=dEI5dEx1SGw5TEJMWi1RUnBUX09LSGc6MQ S.
Windows audio architecture
One link catched my eye here: The evolution of a data structure – the WAVEFORMAT https://www.assembla.com/spaces/portaudio/wiki/Win32AudioBackgroundInfo Maybe it is of some use for Wine developers too:) Some URLs need adjustment, though. Eg. Creative Labs description of Vista audio architecture changed to: http://forums.creative.com/showthread.php?t=302341 S.
Re: [PATCH 2/3] ntoskrnl.exe: Improve IoGetCurrentProcess stub.
* On Fri, 5 Oct 2012, Christian Costa wrote: 2012/10/5 Dmitry Timoshkov dmi...@baikal.ru What matters is what drivers need. I can add some typical fields if needed but that could be done in other patches when needed as well. There are basic things like the header and object list management, besides things like ActiveProcessors, Affinity, BasePriority is not hard to fill from the start. Probably you need to duscuss how this should be done, something tells me that without server support this is not going to work very well. What do you mean by object list management ?There is only one element for now : nothing before nothing after. Unless lists are circular. I'm open for discussion but it's hard without an idea of what drivers do and what we want to support since wine is not intended to run all driver types. So at the beginning, maybe we can do something simple and improve the infrastructure as needs appear. This is nth time the discussion drives to the question: How do you test ntoskrnl co functionality, folks? I suppose Christian debugs some application which loads own, custom sys-drivers. Wine has no tests which would build / load some simple sys-driver; and that needs to change in future, I'd say. Well, this topic already was brought in once by Damjan Jovanovic. [1] Plus, there are guys compiling kernel mode drivers with MinGW(-64) already: [2][3][4] Or am I misunderstanding the right way to go? S. [1] http://www.winehq.org/pipermail/wine-devel/2010-March/082460.html [2] http://strdup.livejournal.com/34596.html [3] http://sourceforge.net/projects/mingw-w64/forums/forum/723797/topic/3163052 [4] http://www.fccps.cz/download/adv/frr/win32_ddk_mingw/win32_ddk_mingw.html
Re: Wine bot results
* On Tue, 28 Aug 2012, Alistair Leslie-Hughes wrote: Target: i686-w64-mingw32 ... Target: i586-mingw32msvc There was the same topic brought up two years ago: http://www.winehq.org/pipermail/wine-devel/2010-September/086643.html IIRC, MSVC and i586-mingw32msvc compilers initialize every declared variable while *-mingw32* one does not. S.
Re: Wine bot results
* On Tue, 28 Aug 2012, Saulius Krasuckas wrote: * On Tue, 28 Aug 2012, Alistair Leslie-Hughes wrote: Target: i686-w64-mingw32 ... Target: i586-mingw32msvc There was the same topic brought up two years ago: http://www.winehq.org/pipermail/wine-devel/2010-September/086643.html IIRC, MSVC and i586-mingw32msvc compilers initialize every declared variable while *-mingw32* one does not. I mean *-mingw32-gcc (the one not using MSVCRT.DLL) with the latter;) S.
Re: Wine automated testing update
* On Thu, 21 Jun 2012, Francois Gouget wrote: --- Host / VM communication One piece that's missing is the ability to copy files from/to a VM and to run specific commands in a VM. ... * There's Cygwin's OpenSSH server which would give us what we need through scp and ssh. Cygwin does not install on NT4 and I'm not convinced it's really free of side-effects. In particular copying the cygwin directory to another computer does not seem to work. http://cygwin.com/install.html Seems like some guy Darren Tucker [1] is in the same boat: I have an old windows VM with an oldish cygwin that I use for the regression tests. Investigating one of the test failures, I see that it's for UsePrivilegeSeparation=sandbox, and it seems to be because setrlimit(RLIMIT_FSIZE, ...) is not supported. IMO, this isn't a big loss, since the most useful thing in the rlimit sandbox is the descriptor limits. Can anyone see a reason not to just omit RLIMIT_FSIZE on cygwin? It's a no-op unless you've explicitly set UsePrivilegeSeparation sandbox in sshd_config. Maybe you could ask him about his experience on side-effects? OTOH, to measure the difference between modern Win and NT4 one could probably compile whole env from the scratch and run Cygwin regression tests. Some guys are doing make -s test. [2] * There's more limited OpenSSH installations derived from Cygwin but I'm not sure they're much better on the side-effects side. http://sshwindows.sourceforge.net/download/ I've found tutorial about installing rsync on old Windows. [3] Maybe rsync could look like having fewer side-effects (or no at all) with this port now that it has been resurrected by some degree -- support for Win7 x64 was added this year. [4] S. [1] http://marc.info/?l=openssh-unix-devm=134127510031310w=2 [2] http://sourceforge.net/tracker/index.php?func=detailaid=2993522group_id=12694atid=112694 [3] http://optics.ph.unimelb.edu.au/help/rsync/rsync_pc1.html [4] http://sshwindows.webheat.co.uk/display/sshwindows/OpenSSH+for+Windows
Re: kernel32: Make CreateFile called with creation == 0 work when opening a vxd in win9x mode.
* On Sun, 11 Mar 2012, Dmitry Timoshkov wrote: A widely used approach to open/load device drivers under win9x is /* Check if already loaded in system.ini */ hvxd = CreateFile(.\\mydevice, 0, 0, 0, 0, 0, 0); if (hvxd == INVALID_HANDLE_VALUE) /* Load dynamically from PATH */ hvxd = CreateFile(.\\path\\to\\mydevice.vxd, 0, 0, 0, CREATE_NEW, FILE_FLAG_DELETE_ON_CLOSE, 0); First call never succeeds under Wine, and some device drivers refuse to load more than once. Are there any proof one can see? What application does behave like this? Where has this source excerpt come from? S.
Re: [docs] winedev: Update gcov section (try 2)
* On Mon, 5 Mar 2012, André Hentschel wrote: en/winedev-otherdebug.sgml | 170 1 files changed, 62 insertions(+), 108 deletions(-) ... para For a further in depth description of gcov, the official gcc compiler suite page for gcov is ulink -url=http://gcc.gnu.org/onlinedocs/gcc-3.2.3/gcc/Gcov.html; -http://gcc.gnu.org/onlinedocs/gcc-3.2.3/gcc/Gcov.html/ulink. -There is also an excellent article written by Steve Best for -Linux Magazine which describes and illustrates this process -very well at -ulink url=http://www.linux-mag.com/2003-07/compile_01.html; -http://www.linux-mag.com/2003-07/compile_01.html/ulink. +url=http://gcc.gnu.org/onlinedocs/gcc/Gcov.html; +http://gcc.gnu.org/onlinedocs/gcc/Gcov.html/ulink. /para I am not sure whether it's OK to exclude link to the article on Linux Mag., which only has changed it's URL over time: http://www.linux-mag.com/id/1409/ S.
Re: Sound keyword on bugzilla
* On Fri, 20 Jan 2012, Vitaliy Margolen wrote: While keywords components overlap, more generic components will not overlap with specific ones. And if we name all of them unknown-something that will help user / bugzilla triage people to pick closer area for SMEs to do more detailed investigation. To begin with I propose to create following components: unknown-browser unknown-core unknown-d3d unknown-gui unknown-input unknown-printing unknown-sound Yes, I support the idea very much. S.
Re: [PATCH 3/5] ddraw/tests: Add a IDirect3DDevice2 GetCaps test (try 2)
* On Sat, 14 Jan 2012, Stefan Dösinger wrote: Am Samstag, 14. Januar 2012, 11:21:15 schrieb Saulius Krasuckas: http://test.winehq.org/data/1fa1ab54376bace57f78d27ac13b7229caa56a2e/xp_wtb -wxpx64-32/ddraw:d3d.html d3d.c:5075: Test failed: CreateDevice failed: 88760091. This is DDERR_INVALIDPIXELFORMAT. The code doesn't provide a pixelformat for the offscreen surface, which means the screen's format should be used. What color depth is this machine runnning at? I know nothing about this machine as it belongs to Wine Test Bot. Maybe we do need additional trace() for it (like it is done in d3d9:visual, opengl32:opengl, dsound:propset or winmm:wave to find out model/name of an appropriate hardware specifics). Stefan, would GetDeviceCaps( GetDC(NULL), BITSPIXEL ) do the trick? My generic guess is that adding a broken(hr == DDERR_INVALIDPIXELFORMAT) is the best thing we can do here. I am all for broken() as it seems to be no other guy able to investigate this in more depth. Even more -- I am against testing 3D related things inside virtual machines at all:) S.
Re: Wine 1.3.37 Gecko engine fails on Arch Linux x86
* On Sun, 15 Jan 2012, Luca Bennati wrote: err:module:import_dll Loading library ssl3.dll (which is needed by LC:\\windows\\system32\\gecko\\1.4\\wine_gecko\\xul.dll) failed (error c020). Cannot reproduce: I'm on ArchLinux 32 bit. Did you install 'wine' and 'wine_gecko' from repositories? Problem solved. Luca, only wine has come from repository. I always install Gecko during wineprefix setup, but thanks for the tip. Well, my bad -- free space on the filesystem was too short (~70 megs). Thank you all for taking care:) S.
Re: [PATCH 3/3] d3d9/tests: More D3DTSS_TEXTURETRANSFORMFLAGS projection tests.
* On Tue, 27 Dec 2011, Matteo Bruni wrote: --- dlls/d3d9/tests/visual.c | 388 -- 1 files changed, 269 insertions(+), 119 deletions(-) Hello Matteo, this is http://source.winehq.org/git/wine.git/commitdiff/8dee7989f242b8ea624abc3b1fe929494d1fd329 The patch removed 6 failures on XP on real hardware (nVidia FX5200): http://test.winehq.org/data/18c20964e1e22f9aa974cc774bf77da6fc013716/xp_s2-sp2-nosound/d3d9:visual.html visual.c:4057: Test failed: proj: Pixel 162/122 has color 0x, expected 0x00FF visual.c:4062: Test failed: proj: Pixel 158/178 has color 0x, expected 0x00FF visual.c:4069: Test failed: proj: Pixel 318/118 has color 0x00ff, expected 0x visual.c:4071: Test failed: proj: Pixel 322/118 has color 0x00ff, expected 0x visual.c:4075: Test failed: proj: Pixel 322/122 has color 0x00ff, expected 0x visual.c:4078: Test failed: proj: Pixel 318/178 has color 0x, expected 0x00FF and introduced 14 new ones: http://test.winehq.org/data/277361d7be206e1ff7634998f0d750f7c6d66498/xp_s2-sp2-nosound/d3d9:visual.html visual.c:3729: Test failed: D3DTTFF_COUNT3 | D3DTTFF_PROJECTED - bottom right: Pixel (401, 361) has color , expected 00ff visual.c:3729: Test failed: D3DTTFF_COUNT3 | D3DTTFF_PROJECTED - bottom right: Pixel (401, 419) has color , expected 00ff visual.c:3729: Test failed: D3DTTFF_COUNT3 | D3DTTFF_PROJECTED - bottom right: Pixel (481, 359) has color 00ff, expected visual.c:3729: Test failed: D3DTTFF_COUNT3 | D3DTTFF_PROJECTED - bottom right: Pixel (481, 361) has color 00ff, expected visual.c:3729: Test failed: D3DTTFF_COUNT3 | D3DTTFF_PROJECTED - bottom right: Pixel (479, 359) has color 00ff, expected visual.c:3729: Test failed: D3DTTFF_COUNT3 | D3DTTFF_PROJECTED - bottom right: Pixel (479, 419) has color , expected 00ff visual.c:3729: Test failed: D3DTTFF_PROJECTED (like COUNT3 | PROJECTED, texcoord has only 3 components) - bottom right: Pixel (401, 361) has color , expected 00ff visual.c:3729: Test failed: D3DTTFF_PROJECTED (like COUNT3 | PROJECTED, texcoord has only 3 components) - bottom right: Pixel (401, 419) has color , expected 00ff visual.c:3729: Test failed: D3DTTFF_PROJECTED (like COUNT3 | PROJECTED, texcoord has only 3 components) - bottom right: Pixel (479, 361) has color , expected 00ff visual.c:3729: Test failed: D3DTTFF_PROJECTED (like COUNT3 | PROJECTED, texcoord has only 3 components) - bottom right: Pixel (479, 419) has color , expected 00ff visual.c:3729: Test failed: 0x (like COUNT3 | PROJECTED, texcoord has only 3 components) - top left: Pixel (81, 121) has color , expected 00ff visual.c:3729: Test failed: 0x (like COUNT3 | PROJECTED, texcoord has only 3 components) - top left: Pixel (81, 179) has color , expected 00ff visual.c:3729: Test failed: 0x (like COUNT3 | PROJECTED, texcoord has only 3 components) - top left: Pixel (159, 121) has color , expected 00ff visual.c:3729: Test failed: 0x (like COUNT3 | PROJECTED, texcoord has only 3 components) - top left: Pixel (159, 179) has color , expected 00ff The same machine running Win7 didn't exhibit any changes: http://test.winehq.org/data/18c20964e1e22f9aa974cc774bf77da6fc013716/win7_s2-enterprise-32-VAS/d3d9:visual.html http://test.winehq.org/data/277361d7be206e1ff7634998f0d750f7c6d66498/win7_s2-enterprise-32-VAS/d3d9:visual.html This probably has something to do with older nVidia driver version being used on Win7 - v96.85 - than the version used on XP - v163.75 . But on Win7 somewhat similar change is seen on virtual machine from Francois, only the failure count increases by 28 here: http://test.winehq.org/data/18c20964e1e22f9aa974cc774bf77da6fc013716/win7_fg-win7u64-1spie9-ja/d3d9:visual.html http://test.winehq.org/data/277361d7be206e1ff7634998f0d750f7c6d66498/win7_fg-win7u64-1spie9-ja/d3d9:visual.html Would you mind fixing this please:)? S.
Re: [PATCH 3/5] ddraw/tests: Add a IDirect3DDevice2 GetCaps test (try 2)
* On Tue, 6 Dec 2011, Stefan Dösinger wrote: try 2: Add infrastructure to rerun every test with new d3d objects. --- dlls/ddraw/tests/d3d.c | 211 1 files changed, 211 insertions(+), 0 deletions(-) Hi Stefan, this is http://source.winehq.org/git/wine.git/commitdiff/7ae81ba378c1633e574f130461bbc7fee16f5592 The patch introduced one failure on 64-bit XP running on virtual machine with VMware SVGA II driver v11.6.0.35: http://test.winehq.org/data/95f81d10c9c852b72c6513eca0a2d0e066457f9e/xp_wtb-wxpx64-32/ddraw:d3d.html http://test.winehq.org/data/1fa1ab54376bace57f78d27ac13b7229caa56a2e/xp_wtb-wxpx64-32/ddraw:d3d.html d3d.c:5075: Test failed: CreateDevice failed: 88760091. Platform is i386 WOW64 -- probably 64-bit XP running 32-bit Winetest: http://test.winehq.org/data/1fa1ab54376bace57f78d27ac13b7229caa56a2e/xp_wtb-wxpx64-32/version.html Would mind having a look and fixing the failure:)? S.
Wine 1.3.37 Gecko engine fails on Arch Linux x86
I decided to run latest Winetest on my linux box and chose to install Gecko package during prefix setup: $ rm -rf ~/.wine $ wine start wine: created the configuration directory '/home/s2/.wine' fixme:urlmon:DownloadBSC_OnProgress Unsupported status 3 fixme:wininet:InternetLockRequestFile STUB fixme:storage:create_storagefile Storage share mode not implemented. err:mscoree:LoadLibraryShim error reading registry key for installroot err:mscoree:LoadLibraryShim error reading registry key for installroot err:mscoree:LoadLibraryShim error reading registry key for installroot err:mscoree:LoadLibraryShim error reading registry key for installroot err:mscoree:LoadLibraryShim error reading registry key for installroot err:mscoree:LoadLibraryShim error reading registry key for installroot err:module:import_dll Loading library ssl3.dll (which is needed by LC:\\windows\\system32\\gecko\\1.4\\wine_gecko\\xul.dll) failed (error c020). Could not load wine-gecko. HTML rendering will be disabled. wine: configuration in '/home/s2/.wine' has been updated. Another try produced a crash: $ rm -rf ~/.wine $ wine start wine: created the configuration directory '/home/s2/.wine' fixme:urlmon:DownloadBSC_OnProgress Unsupported status 3 fixme:wininet:InternetLockRequestFile STUB wine: Unhandled page fault on read access to 0x149cb074 at address 0x7def0a3a (thread 0018), starting debugger... err:seh:raise_exception Unhandled exception code c005 flags 0 addr 0x7bc49a59 Could not load wine-gecko. HTML rendering will be disabled. wine: configuration in '/home/s2/.wine' has been updated. Should I report a bug? S.
Re: Wine 1.3.37 Gecko engine fails on Arch Linux x86
* On Sat, 14 Jan 2012, Jerome Leclanche wrote: Do you have a backtrace of the crash? Could be http://bugs.winehq.org/show_bug.cgi?id=27090 The backtrace doesn't get generated (printed). Thank you, I will investigate it. S.
Re: [PATCH 1/5] ddraw/tests: Add some clipper tests.
* On Wed, 11 Jan 2012, Henri Verbeet wrote: On 7 January 2012 10:47, Saulius Krasuckas sauli...@ar.fi.lt wrote: These tests fail on real machines (running XP and w7) with nVidia cards (FX5200 and GF 310M): http://test.winehq.org/data/b00e7039c5fcaa613b9776a38fe60bb697146b42/index_XP.html#ddraw:ddraw1 http://test.winehq.org/data/a86b765a50cdf76e66c8993977f892d825f52ec0/index_Win7.html#ddraw:ddraw1 On XP + FX5200 the first three tests (dd1, dd2, dd4) generates crash with failing hr = 0x8876021c. The other cases just fail by some color matches. Does the attached patch make it any better? I have no working dev-environment set up ATM, sadly. Was the patch submitted to WTB by a chance? S.
Re: [PATCH 1/5] ddraw/tests: Add some clipper tests.
* On Wed, 4 Jan 2012, Henri Verbeet wrote: --- dlls/ddraw/tests/ddraw1.c | 217 + dlls/ddraw/tests/ddraw2.c | 217 + dlls/ddraw/tests/ddraw4.c | 216 dlls/ddraw/tests/ddraw7.c | 216 4 files changed, 866 insertions(+), 0 deletions(-) It's http://source.winehq.org/git/wine.git/commitdiff/3997457574a0e3f1c2fa095e230ab6d71211e892 These tests fail on real machines (running XP and w7) with nVidia cards (FX5200 and GF 310M): http://test.winehq.org/data/b00e7039c5fcaa613b9776a38fe60bb697146b42/index_XP.html#ddraw:ddraw1 http://test.winehq.org/data/a86b765a50cdf76e66c8993977f892d825f52ec0/index_Win7.html#ddraw:ddraw1 On XP + FX5200 the first three tests (dd1, dd2, dd4) generates crash with failing hr = 0x8876021c. The other cases just fail by some color matches. Plus, tests fail on one WTB machine running XP with russian localisation + VMware SVGA II v11.6.0.35 in yet different way: http://test.winehq.org/data/b00e7039c5fcaa613b9776a38fe60bb697146b42/xp_wtb-wxpprorusp3/ddraw:ddraw7.html Other virtual XP machines do OK with similar setup. My humble guess -- that's just one broken setup out of many virtual machines. Henri, would you be as kind as to fix the tests:)? S.
Re: new d3d9/device.ok test always fails here, but not a regression?
* On Mon, 2 Jan 2012, Dan Kegel wrote: If an app stops working because some missing feature is added to an existing DLL, it should not be tagged as a regression even though it is from the app's point of view, right? (Thinking of the installers for Photoshop CS3 and Visual Studio 2005.) I wonder if we need a separate keyword for that, like 'appregression'. I would call it 'newfeature' or even 'weaknewfeature' to avoid similarity between sound of 'regression' and 'appregression'. S.
Re: [3/4] ddraw: Set correct HEL and HAL color models
Stefan, it looks like your patch http://source.winehq.org/git/wine.git/commitdiff/9e0baa55cec232656048c972e94a9dc2a15ec30b has introduced 2 failures on one virtual w2k3-vmware machine: http://test.winehq.org/data/e7bbb4ef1e95396b72a58f813b4346d9abccb699/2003_wtb-w2k3r2sex64-32/ddraw:d3d.html See earlier results: http://test.winehq.org/data/tests/ddraw:d3d.html Would you mind fixing this, please:)? S.
Re: ntdll: Revert 33b0f0edffa0c8a06b4ee8831c92fdc373f83ece.
On Thu, 17 Nov 2011, Alexandre Julliard wrote: The test requires a PE binary because obviously we can't test PE protections on Unix binaries. That doesn't mean it doesn't exist. Just build a crosstest: $ wine ntdll_crosstest.exe info.c info.c:1296: Test failed: mbi.Protect is 0x8, expected 0x4 IIRC, some of tests already craft minimal PE binaries in manual way. So it would be nice to have some tool inside the tree to generate PEs independetly, no? Several years ago I've tried testing GetStdHandle() from within two PE binaries with different header flags set (IMAGE_SUBSYSTEM_WINDOWS_[GC]UI). For a start I have copied some code of manual PE crafting to build PE header. Then there came .text section's order. I realized it's sufficient to write small assembler file, run it through the gas crosscompiler, disasm it and parse the results to have _not only_ binary data for rebuilding PE, but also symbolic one. I wrote some awk-script then to convert .S file into C-function this way. With it it was easy to adjust options for crosscompiling gas/ld tools to get PE with needed structure. But maybe there is point in creating some universal in-tree tool? Or integrate the functionality into winegcc (or else) so as not to depend on a crosscompiling suite but still have readable and easy changeable source. Guys, what do you think? S.
Re: MS XInput*.dll implementation
* On Wed, 2 Nov 2011, Alexey Loukianov wrote: 01.11.2011 18:54, Jerome Leclanche wrote: I'm no expert in any *input* API, but it sounds like it would be better to reimplement dinput under the xinput api; similarly to how audio has been handled. Despite being more recent API XInput actually is less capable than DI8. Most correct way to compare these API's would be to think about DI8 as a general and pretty complicated API for handling input devices while XInput is more likely API for handling some Xbox360 game input controllers. You may wish to read Wiki page titled something like XInput vs. DirectInput for more detailed analysis. I am just another bystander as well, but a year ago (as was brought in by Austin E. a few msgs ago) Roderick Colenbrander wrote about a possibility (and arising problems) doing this just a way round: http://www.winehq.org/pipermail/wine-devel/2010-June/084395.html Some other guys (more or less related to input, eg. Vitaliy Margolen, Alexandre Julliard, Marcus Meissner) on the same thread have said XInput can work only when done directly (via X11). S.
Re: ddraw: Keep track of interface attached by AddAttachedSurface and detach correct interface when parent is released. (try 3)
Hello, Octavian. * On Tue, 11 Oct 2011, Octavian Voicu wrote: try 3: - fix test failure by moving error check from *_DeleteAttachedSurface to ddraw_surface_delete_attached_surface, after another check (thanks Henri). try 2: - use IUnknown_Release(attached_iface) instead of manual dispatch, as suggested by Henri; - change type of attached_iface from void* to IUnknown* to reflect fact that it's a pointer to an interface; - add test to show that attaching a surface only attaches a specific interface and return error if DeleteAttachedSurface is called with another interface than the attached one (instead of detaching the surface anyway). Fixes a bug that causes a stencil buffer leak in the game The Longest Journey. Problem can be seen in the console output log attached to bug #11819. This patch doesn't fix the original bug, but now game exits cleanly. The root of the problem is that when releasing a surface, its attached surfaces are detached using IDirectDraw7_DeleteAttachedSurface, regardless of what interface was originally attached. I am troubled by seeing (via test.winehq.org) your ddraw:refcount tests to account only results for VMware SVGA 3D adapter/driver (and only those with 3D acceleration disabled), I guess. But if this driver is 3D-enabled or just present real physical adapter (with no 3d acceleration) then ddraw:refcount contains 6 static failures such as: refcount.c:214: Test failed: AddAttachedSurface returned 8876000a refcount.c:235: Test failed: AddAttachedSurface returned 8876000a refcount.c:237: Test failed: Got refcount 1, expected 2 refcount.c:262: Test failed: AddAttachedSurface returned 8876000a refcount.c:275: Test failed: AddAttachedSurface returned 8876000a refcount.c:277: Test failed: Got refcount 1, expected 2 refcount: 112 tests executed (0 marked as todo, 6 failures), 0 skipped This relation can be easily tracked by looking at d3d9:visual or (if they aren't present) at opengl32:opgenl tests. Eg. failures occuring here: * Intel(R) 82865G Graphics Controller http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/xp_af-xpsp3/d3d9:visual.html http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/xp_af-xpsp3/ddraw:refcount.html * NVIDIA GeForce FX 5200 http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_s2-enterprise-VAS/d3d9:visual.html http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_s2-enterprise-VAS/ddraw:refcount.html http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/xp_s2-sp2-VAS/d3d9:visual.html http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/xp_s2-sp2-VAS/ddraw:refcount.html * ATI Radeon HD 4800 Series (telling it has no IDirect3D[7] support for DDraw) http://test.winehq.org/data/a843acef5567bc30901612ce5013da543259b21b/win7_win7-x64/d3d9:visual.html http://test.winehq.org/data/a843acef5567bc30901612ce5013da543259b21b/win7_win7-x64/ddraw:refcount.html * VMware SVGA II http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/2000_fg-win2000-uplast/d3d9:visual.html http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/2000_fg-win2000-uplast/ddraw:refcount.html http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/2000_fg-win2000-4sp/opengl32:opengl.html http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/2000_fg-win2000-4sp/ddraw:refcount.html * VMware SVGA 3D (telling it has not IDirect3D[7] support for DDraw) http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_fg-win7u64fr-t64/d3d9:visual.html http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_fg-win7u64fr-t64/ddraw:refcount.html All other cases succeed. AFAICS all of them represent the only driver (with 3D support turned off): * VMware SVGA 3D http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_wtb-w7pro/d3d9:visual.html visual.c:194: Driver string: vm3dum.dll visual.c:195: Description string: VMware SVGA 3D (Microsoft Corporation - WDDM) visual.c:197: Device name string: \\.\DISPLAY1 visual.c:199: Driver version 7.14.1.40 visual.c:12627: Tests skipped: Creating the device failed visual: 5 tests executed (0 marked as todo, 0 failures), 1 skipped. with following results: http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_wtb-w7pro/ddraw:refcount.html refcount: 121 tests executed (0 marked as todo, 0 failures), 0 skipped. IMHO, it would be nice to conform to real world configuration. Wish you best luck with fixing your tests:) S.
New API functions for loading external dlls
It seems MS announced three new functions yesterday: SetDefaultDllDirectories AddDllDirectory RemoveDllDirectory These are to help developers correctly and securely load external libraries. [1] I remember some talk about SetDllDirectory() in the past [2], so now it's interesting how these two ways would coexist. Plus, could the new way help to simplify loading Gecko / XPCOM [3] by a chance? Probably not:) S. [1] http://support.microsoft.com/KB/2533623 [2] http://www.winehq.org/pipermail/wine-patches/2005-August/019625.html [3] http://source.winehq.org/source/dlls/mshtml/nsembed.c?v=wine-1.1.8#L144
Re: Raw Input Patch Update 16
* On Tue, 12 Jul 2011, Vincas Miliūnas wrote: Also I need to note the lack of applications that make extensive use of the raw input API. There are just a few games and they are convenient with just the mouse movement data. FWIW, I get a bit more applications by quering Bugzilla for RawInput string in comments. [1] It is Joost, AutoCAD 2004, WinUAE, Presentation whose logs mention RawInput. Also, it looks like the Sonic Fan Remix Demo also uses raw keyboard input. [2] S. [1] http://bugs.winehq.org/buglist.cgi?query_format=advancedorder=Importancelongdesc=RawInputproduct=Winelongdesc_type=allwordssubstr [2] http://bugs.winehq.org/show_bug.cgi?id=24883
Re: Glitch-free iTunes?
Perhaps such response is due to my language barrier, but... * On Mon, 4 Jul 2011, Keith Curtis wrote: I bring up Linus because he can focus efforts. You don't need Linus. You just need the same result -- focused efforts. There is another name for this concept -- teams. Maybe WINE needs sub-teams? Keith, maybe you should contact Codeweavers to persuade the right persons? :) However, you have accomplished so much already. Year after year, you accomplish more, and yet you just think that it is hopeless or something. What makes you say the last part (mentioning hopelessness)? And one worthy goal is iTunes runs better than on Windows. If you had that as a goal 5 years ago, you would have succeeded by now. Then 64-bit Wine port, DIB engine/rewrite wouldn't be started; XI2, XRender, Xcursor support, IO completion ports wouldn't have been born; Winsock, OpenGL in child windows, Systray would work in much buggier way; and APC would fail in addition to 16-32 bit thunking issues. I've forgot to mention countless fixes for window handling subsystem (in managend and unmanaged mode), COM mechanisms such as proxy delegations, marshaling, stubless proxies, RPC, Widl, X11 CopyPaste support, Inetcomm, Winhttp, implementations. Plus ton of Unicode fixes. All that would stay broken / unfixed / unimplemented. But iTunes would probably work (in possibly wrongly architectured way). Would such tradeoff be OK for the community? No offense, but I doubt it. I understand that WINE has many apps that you want to work. You are doing well. It is just missing some features that are not being caught by your random work. I know you'll get there, in the next 10 years. Perhaps by the time Apple no longer matters you'll have it working. BTW, Keith, could you please estimate how much people / work hrs were used to make XP a final product + produce security fixes? (And that's counting 25 years!) I guess a lot more people / hrs than it is used for Wine. My rough guess is 10 times. In the case of Linux kernel, it is very different game, IMHO. (less restrictions and INSANE compatibility issues:) But you could always contact our dictator-in-chief Alexandre to hear the last decision on project managament:) My two cents, S.
Re: kernel32/toolhelp: PROCESSENTRY32::szExeFile is the full path in Win9x.
* On Wed, 25 May 2011, Adam Martinson wrote:
Dragon NaturallySpeaking 7 expects this in Win98 mode.
---
dlls/kernel32/tests/toolhelp.c | 19 +++-
dlls/kernel32/toolhelp.c | 48 +--
2 files changed, 53 insertions(+), 14 deletions(-)
I am not sure you do it right (now that new testing strategy is taken):
* On Tue, 30 Nov 2010, Alexandre Julliard wrote:
The value of running tests on Win9x these days is certainly
questionable. We don't try to emulate the Win9x behavior anyway, except
in a very few cases (which most likely don't have tests...) so it only
serves to document historical behavior that nobody cares about any
longer.
WRT doesn't test win9x any longer, so what's the point of putting such
check in the test?
--- a/dlls/kernel32/tests/toolhelp.c
+++ b/dlls/kernel32/tests/toolhelp.c
...
@@ -106,6 +108,10 @@ static void test_process(DWORD curr_pid, DWORD
sub_pcs_pid)
unsignedfound = 0;
int num = 0;
int childpos = -1;
+OSVERSIONINFO osver;
+
+osver.dwOSVersionInfoSize = sizeof(osver);
+pGetVersionEx(osver);
hSnapshot = pCreateToolhelp32Snapshot( TH32CS_SNAPPROCESS, 0 );
ok(hSnapshot != NULL, Cannot create snapshot\n);
@@ -116,10 +122,15 @@ static void test_process(DWORD curr_pid, DWORD
sub_pcs_pid)
{
do
{
+TCHAR* bslash = strchr(pe.szExeFile, '\\');
if (pe.th32ProcessID == curr_pid) found++;
if (pe.th32ProcessID == sub_pcs_pid) { childpos = num; found++; }
trace(PID=%x %s\n, pe.th32ProcessID, pe.szExeFile);
num++;
+if (osver.dwMajorVersion 5)
+ok(bslash != NULL, szExeFile is not a full path: %s\n,
pe.szExeFile);
+else
+ok(bslash == NULL, szExeFile is a full path: %s\n,
pe.szExeFile);
} while (pProcess32Next( hSnapshot, pe ));
}
ok(found == 2, couldn't find self and/or sub-process in process
list\n);
Now such check is pointless, IMHO.
Here goes question to Alexandre:
what about (testing in) such cases?
S.
massively skipped tests being shown
Hello, there is something wrong with WRT result page/parser [1] (or with TestBot too) since yesterday. All tests' results from TestBot are shown as skipped by user request, eg. for XP [2]. Results from physical machines are present, currently only one (af-xpsp3-nv) which shows 12 failures. But in the daily summary we see 28 failures for XP. [3] Sounds like a bug or two:) S. [1] http://test.winehq.org/data/ [2] http://test.winehq.org/data/e5c3883c923d345848315a39a090607bdddac936/index_XP.html [3] http://test.winehq.org/data/e5c3883c923d345848315a39a090607bdddac936/
Re: clusapi: add stub for GetClusterInformation
* On Fri, 18 Mar 2011, Nikolay Sivov wrote: On 3/18/2011 11:04, Dmitry Timoshkov wrote: Konrad Rzepeckihanni...@astral.lodz.pl wrote: +DWORD WINAPI GetClusterInformation(HCLUSTER hCluster, LPWSTR lpszClusterName, LPDWORD lpcchClusterName, LPCLUSTERVERSIONINFO lpClusterInfo) It looks like your mailer has wrapped all your patches. Strange, looks fine for me, maybe mine unwrapped it. Yes, I guess it did. Mine did too. The message was in flowed format: Content-Type: text/plain; charset=us-ascii; Format=flowed I am out of ideas if this is acceptable for wine-patches@, though:) S.
Re: Make sure This-bsc.doc will be initialized while opening a zero byte html file, fix bug 25999 . modified: dlls/mshtml/navigate.c
* On Tue, 8 Mar 2011, Jacek Caban wrote: What's the exact problem you're trying to fix? AFAIK, builtin IE crashes on loading empty file: http://bugs.winehq.org/show_bug.cgi?id=25999 S.
Re: kernel32/tests: remove win9x hacks (try 2)
* On Thu, 24 Feb 2011, Alexandre Julliard wrote: Saulius Krasuckas sauli...@ar.fi.lt writes: I have at least one Win16 app which behaves differently on Win16, on XP and on Wine [*]. What's the right way to get it running OK on Wine then (without appropriate Win16API tests) ? Fix the bug without a test, or work on adding a 16-bit test suite. Thanks. Do you mean something like integrating OpenWatcom C compiler optionally into dlls/*/tests? And then running 16-bit part of winetest on Win3.1? WinXP seems to be broken in my case. While Win98 seems OK. This has nothing whatsoever to do with running 32-bit tests on Win95. Yes, that's two separate topics in one msg. What is best in your opinion to do for those still interested in win9x's 32-bit behaviour? The only alternative coming to my mind is forking winetest. S.
Re: kernel32/tests: remove win9x hacks (try 2)
* On Thu, 24 Feb 2011, Alexandre Julliard wrote: The win9x support makes the tests less strict, by allowing additional behaviors, and that only when running on Windows. Is that a problem? Running them on Wine is pointless since these code paths are never executed. I may be missing the point, but Wine uses broken() function already. Similar function, eg. dead_9x(), could be easily created to check for such cases. And does this mean that Windows 3.1 (and DOS?) tests aren't welcome now? As part of the winetest infrastructure, they are not welcome, and never have been. I have at least one Win16 app which behaves differently on Win16, on XP and on Wine [*]. What's the right way to get it running OK on Wine then (without appropriate Win16API tests) ? S. [*] http://bugs.winehq.org/show_bug.cgi?id=5278#c27
vblank timestamps and page flipping in DRI2
There are some news on the $Subject: [1]. (have a look at the chapter Fine tuned) I thought it could help Wine fixing such bugs as 6086, 13085, 17260, 22362 [2]. I'll paste the text in just for archiving purposes: --- quote --- Fine tuned The kernel hackers have extended the DRM infrastructure to include precision vblank timestamps, which are explained in detail in the commit comment and are relevant to OpenML (Open Media Library) conformity. This feature enables the kernel to provide timestamps with an accuracy of a few microseconds, allowing applications to detect when the rendering of a new image has started (double-buffer swap). This can, for instance, be relevant for applications where it is important to precisely co-ordinate the audio output, or the control of other devices, with the rendering of the image. The technology was first implemented for experimental psychology and neuroscience applications, but it can also be applied to provide (more) jerk-free video playback, animations or desktop effects. Such timestamps can also be utilised by the new page flipping feature available via DRI2. This feature improves the way the kernel synchronises the release of an updated image with the moment the graphics hardware starts rendering the new image (Vsync). Synchronising the release avoids such distortions as flickering, tearing or incomplete rendering, as it prevents situations where one half of a displayed image is part of the old image while the other half is part of the new image . for instance with individual movie frames. In kernel version 38, the graphics driver support required for both features will be available via the AMD drivers (1, 2) and the Intel drivers (1, 2). The NVIDIA drivers currently only support page flipping (1, 2). --- quote --- S. [1] http://www.h-online.com/open/features/Kernel-Log-Coming-in-2-6-38-Part-1-Graphics-1176900.html?artikelseite=1;page=2 [2] http://bugs.winehq.org/show_bug.cgi?id=6086 http://bugs.winehq.org/show_bug.cgi?id=13085 http://bugs.winehq.org/show_bug.cgi?id=17260 http://bugs.winehq.org/show_bug.cgi?id=22362
Re: .chm files for builtin programs?
* On Sat, 12 Feb 2011, Jacek Caban wrote: * On 2/11/11 5:06 AM, Dan Kegel wrote: I think there's an open source .chm compiler at http://sourceforge.net/projects/chmc/ Haven't tried it yet. If that doesn't work, we can use Microsoft's hhc. The right way to add chm file is implementing .chm compiler as a plain UNIX application chmc is such already. and use it in build time to product .chm files. BTW, can't it be integrated into the make process so the .chm files get compiled right after the programs/ folder have been built? S.
Re: Another milestone
* On Thu, 27 Jan 2011, Greg Geldorp wrote: Today we had a clean winetest.exe run on all 31 TestBot VMs for the first time. Although there are still failures on other test machines and some tests fail occasionally on TestBot, I still think this is a significant milestone. Congrats to all! And thanks :) Hopefully the Wine column on http://test.winehq.org/data/ will soon start to show some yellow spots too! I'm waiting years for this (since probably 2004:) My thanks go to all the developers and testers. S.
Re: [ActiveX]crash while open https://mybank.icbc.com.cn/icbc/perbank/index.jsp use wine buitin IE
* On Thu, 27 Jan 2011, Juan Lang wrote: By the way, will wine builtin IE support vbscript in the future? ICBC online bank required vbscript. That's a pretty open-ended question. I haven't seen anyone volunteer to work on this in some time, so I'd say the odds are not so good. ABBYY FormFiller software (used to fill data for electronic tax declaration system at the state level in our country) also requires vbscript.dll to parse data validation rules. There is workaround, though. You just run winetricks wsh56vb. S.
Re: Fail to use USB-Key/USB-Shield with wine USB patch :cannot start service 'SCardSvr':win error code:0x00000424
* On Mon, 17 Jan 2011, Qian Hong wrote: Dear all, after replacing winscard.dll by native windows dll and setting the native winscard.dll by default with winecfg, I got a new result,Screenshot here: http://goo.gl/7gWbt , this is the same as that the regist is modified in Windows XP: http://goo.gl/VNn2N Thanks for investigation:) You should open new bug for this, I guess. wine tokenadmin.exe fixme:wtsapi:WTSRegisterSessionNotification Stub 0x50086 0x fixme:wtsapi:WTSQuerySessionInformationA Stub (nil) 0x 8 0x32f2c4 0x32f2c0 fixme:wtsapi:WTSRegisterSessionNotification Stub 0x50086 0x fixme:win:RegisterDeviceNotificationA (hwnd=0x20072, filter=0xe8e9c4,flags=0x) returns a fake device notification handle! fixme:wtsapi:WTSRegisterSessionNotification Stub 0x50086 0x fixme:wtsapi:WTSRegisterSessionNotification Stub 0x50086 0x fixme:wtsapi:WTSRegisterSessionNotification Stub 0x50086 0x fixme:win:UnregisterDeviceNotification (handle=0xcafecafe), STUB! ... After using native wtsapi32.dll and winsta.dll, there is no fixme:wtsapi message. It seems these fixmes are harmless, so none of these two overrides should be needed. This should be verified only after fixing previous stuff, IMHO. $ wine tokenadmin.exe fixme:win:RegisterDeviceNotificationA (hwnd=0x10090, filter=0xe8e9c4,flags=0x) returns a fake device notification handle! fixme:win:UnregisterDeviceNotification (handle=0xcafecafe), STUB! I know that the native user32.dll is not compatible with wine. I'm afraid that I have no idea now. What's not working now with this configuration for you? Probably could be reported with via separate bugreport:) But if possible, I'll be gladly to help to test everything about wine usb supporting. Well, IIRC the USB patch you mentioned isn't officially supported by Wine (for now), so you could ask it's author Alexander Morozov and then Wine headquarters (here or on IRC) on how to integrate it public way (if possible in short run at all). This would probably lead to several or even more additional bug reports. S.
Re: Death to win9x?
* On Wed, 22 Dec 2010, Jacek Caban wrote: dropping win9x tests has nothing to do with dropping win9x support. It has, but in a small degree -- if win9x support regresses now, these existing few cases of testing win9x specifics won't do their job. These test results weren't helpful nor useful anyways. And how is the project going to get rid of win9x specifics in the winetest? Some of them were being skip()ed, some broken() and some of them were left just as valid (eg. ERROR_NOT_LOGGED_ON). You will you let them rot? But I see the pluses too. Now if I stuck upon some win9x-specifics, I can change WinAPI function without even needing a test case. Because it won't be tested anyway, right? :) I guess more patches are going to go through sinceg. S.
Re: Death to win9x?
* On Fri, 3 Dec 2010, André Hentschel wrote: As the VMs in Testbot are now retired we might want to delete the old win9x testdata from test.winehq.org(we need a name for this, testviewer?) manually? Wait, please. Was there some voting been held to make such sentence official? I think no. * On Tue, 30 Nov 2010, Alexandre Julliard wrote: The value of running tests on Win9x these days is certainly questionable. We don't try to emulate the Win9x behavior anyway, except in a very few cases (which most likely don't have tests...) So would someone try doing this (testing these rare cases, as Jerome Leclanche wrote), one wouldn't have a chance then (except for running Winetest on Win9x manually) ? I disagree. * On Thu, 2 Dec 2010, Alexandre Julliard wrote: That's not useful. The whole point is that we don't want to spend the effort required to keep the tests error-free on platforms that we don't care about. That makes it easier to write tests for platforms that actually matter, which is a more productive use of everybody's time. I believe most of devs writing test cases don't care about Win9x branch already. Here reds count about 5x more than reds from WinNT branch. * On Fri, 3 Dec 2010, Dmitry Timoshkov wrote: Right now all the test results that differ for win9x versions are marked as broken(), Dmitry, you are mistaken. I put the ERROR_NOT_LOGGED_ON case for Win98 in 2005[*], and it's still not broken(). How were you checking that? [*] http://source.winehq.org/git/wine.git/?a=commitdiff;h=5cd099290c5333206e25fd3a27e1344b70105881 In the worst case I would agree with alternative ways around: 1, to hide Win9x data by moving it to some other page (/data_all); 2, to separate tests into winetest-HASH.exe and winetest9x-HASH.EXE. This would require separate page for the (9x or total) data also. Thanks all for reading this long, S.
Re: Does testbot's MingW miscompile winmm:midi tests?
* On Fri, 10 Sep 2010, joerg-cyril.hoe...@t-systems.com wrote: Now what to do next? - uninitialised memory issue? - bad MingW or includes on test.winehq? How do MingW on test.winehq and testbot.winehq differ? Difference of primary interest would be in the compiler versions and then in configure options, I guess. Reports on test.wineh.org says the details [1]: | Build version | | Using built-in specs. | Target: i586-mingw32msvc | Configured with: /home/ron/devel/debian/mingw32/mingw32-4.2.1.dfsg/build_dir/src/gcc-4.2.1-2-dfsg/configure |-v --prefix=/usr --target=i586-mingw32msvc --enable-languages=c,c++ |--enable-threads --enable-sjlj-exceptions --disable-multilib |--enable-version-specific-runtime-libs | Thread model: win32 | gcc version 4.2.1-sjlj (mingw32-2) But testbot.winehq.org seems to provide such full info [2]. The only stuff I can find is the name of the cross-compiler binary used: | i686-pc-mingw32-gcc Lets compare it to the first one: | i586-mingw32msvc So at least it's clear both compilers were built using different build environments and different targets (msvc vs gcc; i586 vs i686). Seems like testbot.winehq.org should be enhanced to be a bit verbose. Is it's code available? I haven't found one in Wine's git repo [3]. S. [1] http://test.winehq.org/data/2c4b08176bf43c1a7a3dd922432e6efae33168cb/me_s2/version.html [2] https://testbot.winehq.org/JobDetails.pl?Key=5184log_101=1#k101 [3] http://source.winehq.org/git/
Re: Please report mcicda (CDROM audio) test results
* On Fri, 3 Sep 2010, joerg-cyril.hoe...@t-systems.com wrote: Saulius Krasuckas wrote: Then we would know for sure :) As far as MCICDA is concerned, it doesn't look like it knows about multi-sessions. All it offers is to play music. Therefore the mcicda tests is not the right place to look for a disc utility that'll show you information about your drive and disc. OK, I understand the reason in a case of disc, but couldn't differences between drives influence the operation result? To add more to my question I'm quoting your yesterday letter: * On Thu, 2 Sep 2010, joerg-cyril.hoe...@t-systems.com wrote: Your paranoid android. mci.c:714: Test failed: Expect message 0001 from play to 250 wait notify mci.c:721: Test failed: got 0004 instead of MCI_NOTIFY_xyz from command after close mci.c:782: Test failed: not enough time elapsed 58ms mci.c:838: Test failed: mci status position: 58 Sadly, that's the well-known transient flakyness that I blame on vmware's timers (or perhaps native bugs?). Did anybody with a real machine ever get any similar failures? That would be more revealing to analyse. And didn't investigate, but what is your (and anyone other's) opinion about testing CD emulators (like Daemon-Tools or WinCDEmu) on real machines? Could they be reliable tool for testing MCICDA, etc. ? me_s2-clean-updated/winmm:mcicda.html Ah, that's you, good to know. You can help me debug the ME-only errors in winmm:midi midioutXyz returns rc=MMSYSERR_INVALPARAM OK, switching to private mode :) S.
Re: Console issues in recent git
* On Thu, 2 Sep 2010, Reece Dunn wrote: On 2 September 2010 02:29, Jerome Leclanche adys...@gmail.com wrote: Anyone else's terminal emulators really acting up since the last git batch? On konsole (2.5//4.5.00), I'm unable to see what I'm writing if there is a wine process running, until it's killed. This is probably a konsole bug, but still... On gnome-terminal, running an application (StarCraft 2) via a bash script, using the arrow keys does not cycle through the history and pressing enter does not output a newline so the u...@computer: bit gets outputted next to the other one. This is after the second run. Similar things happens here with xterm. Killing wine processes and wineserver doesn't help me and xterm should be killed afterwards. S.
Re: AW: Please report mcicda (CDROM audio) test results
* On Thu, 2 Sep 2010, joerg-cyril.hoe...@t-systems.com wrote: According to http://de.wikipedia.org/wiki/Compact_Disc CD-Extra is a multi-session disc. So it would be like Jeff Zaroyko's disc. Yes, both K3B and Nero Info Tool v2 reports two sessions on my disk. I don't know whether he retried that one with the mcicda tests now in git. It would be nice to indicate disks containing tracks of different types (sessions) in the log and to extract some info from the data track. Then we would know for sure :) Drive info would be also interesting to see in the log. Wikipedia says that the Mixed Mode CDs have been largely replaced with multi-session ones. Given Jeff's output it looks like mcicda only sees the audio section of multi session discs. Care to confirm? Already done, it says: no mixed data+audio CD: http://test.winehq.org/data/cc945706a4933cda0d204ba07a13e93fccb66d18/me_s2-clean-updated/winmm:mcicda.html I haven't looked at the code and don't know MCI. Is there nothing more to be done with CD-Extra? S.
Re: Please report mcicda (CDROM audio) test results
Hello, * On Wed, 4 Aug 2010, joerg-cyril.hoe...@t-systems.com wrote: Jeff Zaroyko wrote: mcicda: 98 tests executed (0 marked as todo, 2 failures), 0 skipped. With a dual mode cd which has a data and audio tracks: mcicda: 90 tests executed (0 marked as todo, 14 failures), 0 skipped. Tried a different cd with audio tracks only: mcicda: 90 tests executed (0 marked as todo, 15 failures), 0 skipped. Strange, a mixed CD should have executed more tests, like my sample result. I'll add a skip when only audio tracks are found. The only way to have 0 skips flagged would then to use a mixed data + audio CD like you initially did. However those are rare. would CD Extra disk (with different types of tracks on the same disk) also be interesting to test? In this case single data track goes last. (I found one such CD today and realised it isn't a Mixed Mode CD which the test needs for the sake of completeness) S.
Re: dlls/ntdll/file.c: Use FIXME_ONCE for quieter reports.
* On Thu, 15 Jul 2010, Michael Stefaniuc wrote: Saulius Krasuckas wrote: TRACE_ONCE probably could help in some cases too. There I see another I fail to see how TRACE_ONCE could make any sense. TRACE is used to trace the important parts of the code flow. Just printing a TRACE once is less than helpful; it is waay better to not print the TRACE at all. I was in a hurry a bit and I am persuaded now :), thanks. Of course TRACE_ONCE should be defined for symmetry and preventing somebody wasting time to send a patch with an implementation for it. Too bad that Alexandre is too nice else that would be something like: #define TRACE_ONCE TRACE_ONCE_Misguided_developer_detected I am away from development now, but you will never know :). Such define sounds OK. Or has it already been decided on IRC to not exist? S. PS: Congrats to all the folks for Wine-1.2!
Re: dlls/ntdll/file.c: Use FIXME_ONCE for quieter reports.
* On Wed, 14 Jul 2010, Chris Robinson wrote: * On Wednesday, July 14, 2010 5:02:59 pm Max TenEyck Woodbury wrote: 'FIXME's that contain no variable information are completely redundant after their first report. After the first reminder, the additional reports are just noise. They add no additional information in terms of action required. I wouldn't say that. Sometimes the simple knowledge that a FIXME is called a whole lot says enough on its own (eg, in WineD3D, you get a fixme when an sRGB reload occurs, because it's a performance drain; if this happens a lot, it can be taken as a source for performance issues). Sometimes knowing particular a fixme is triggered near to a crash or other behavioral anomaly can say a bit, too. Although I stand for *_ONCE implementation, I agree with Chris. And there might be some alternative: lets then implement it like a FIXME_ONCE_PER(N)(a_debug_string); Which could print something like a fixme:channel:a_debug_string [repeated N times] This would not oly still tell you approximate frequency of a FIXME, but it also would require developer to know reasonable occurence quanta value (N) or to tune it later. This (for me) sounds like a way to know the code's stochastic behaviour better! Which would be a plus. If such fixmes were only printed once, it would be impossible to see this information without more in-depth testing that most users won't bother with. If the fixme is only printed once and the rest are TRACEs, it would still cause more work and a whole lot more noise (ie. all the other traces) in trying to spot it. TRACE_ONCE probably could help in some cases too. There I see another constraint of *_ONCE functionality. Once could be per block (eg. for-loop), per wrapping function call, per process or even once per thread's life. Implementing all onces might be difficult, IMHO. Though not all of them could be necessary, probably. * On Thu, 15 Jul 2010, Dmitry Timoshkov wrote: The patches which silense some FIXME's have been accepted as an exception. That covers the code which is unlikely to be fixed in near future, or the code nobody is working on. Then at least replacement of these (ugly by their size, IMHO) silence-blocks with a simple FIXME_ONCE seems rational. S.
Re: software built and worked under wine but not in vista?
* On Fri, 21 May 2010, Hin-Tak Leung wrote: To check this, it would be nice to run winetricks vcrun6, recomple the app in Wine and see if the resulting exe run OK on Vista. Tried that - the binary differs by 6 bytes - just timestamp and checksum. So using native msvcrt in vcrun6 has no effect. To kindly process this situation you should enter a new bugreport, I guess. This list isn't for analysing particular bugs :) There are a few differences I spotted between the two executables: 1) setupgs-wine.exe has wrong image size, changing it from 0x2b200 to 0x2b000 makes the executable working under win7. But that has to be a bug in wine - that it doesn't check the image size and loads PE with an invalid image size? (how that end up being invalid is a different issue). It looks like that. It would be nice to minimize resulting PE-image and to make some loader test from it. To end it up into this file, eg.: dlls/kernel32/tests/loader.c Good luck with your future bug report :) S.
Re: software built and worked under wine but not in vista?
* On Thu, 20 May 2010, Matijn Woudt wrote: On Thu, May 20, 2010 at 3:54 AM, Hin-Tak Leung hintak_le...@yahoo.co.uk wrote: I have gone ahead and done exactly that - the correct behavior should be a msg box saying filelist.txt is missing, rather than setupgs.exe not a valid win32 application. http://www.ghostscript.com/~hintak/setupgs-vista.exe http://www.ghostscript.com/~hintak/setupgs-wine.exe There are a few differences I spotted between the two executables: 1) setupgs-wine.exe has wrong image size, changing it from 0x2b200 to 0x2b000 makes the executable working under win7. 2) setupgs-wine.exe has wrong resource size, probably related to 1), because the size of both executables are the same. 3) The assembly in setupgs-wine.exe has only LF line endings, vista has CRLF. This explains 2). I don't know the reason for 3), I assume it's a bug somewhere in wine. Thus it could be a fault in Wine's msvcrt.dll (or the like: msvcr?0.dll). To check this, it would be nice to run winetricks vcrun6, recomple the app in Wine and see if the resulting exe run OK on Vista. S.
Re: software built and worked under wine but not in vista?
I sorry for stepping into Alexandre's or Dmitry's shoes, but.. * On Tue, 18 May 2010, Hin-Tak Leung wrote: So it seems that setupgs.exe is mis-compiled under wine with win7 sdk but just happened to also work under wine. Any idea how it might happen? ... there could be a pair of bugs: one in PE image manipulation functions plus another in Wine PE loading mechanism(s). I could imagine the first easily inside a IMAGEHLP, eg. functions ImageAddCertificate() or CheckSumMappedFile(). If you find the first one, then it should be possible to write a test to reveal the second one. I have checked things like end-of-line, but it is curious why the setupgs program works under wine but not in vista, the reverse situation compared to most. Could you build the same project under real Windows? Then I would run winedump dump -f or even -x on both files to compare the outputs (probably line by line) and to find the essential difference. S.
Re: Working on DOS VGA.
* On Mon, 5 Apr 2010, k4king wrote: While they focus mostly on games, they aren't against general fixes. From memory they don't support lpt ports (for similar reasons) wheras you can multi play games with serial ports so they do support those. There exists some branch of DOSBox called MegaBuild. [3] It implements LPT port emulation and enhances serial port emulation (at least for DirectSerial mode -- now MegaBuild5 switches DSR-DTR/DCD signal pair (and CTS-RTS one also) correctly with appropriate hardware loopback used. LPT hardware loopback works also with DOS application. Official DOSBox doesn't do that, so I believe you could use MegaBuild for games also. S. [3] http://home.arcor.de/h-a-l-9000/index.html
Re: Working on DOS VGA.
* On Tue, 6 Apr 2010, Saulius Krasuckas wrote: There exists some branch of DOSBox called MegaBuild. [3] It implements LPT port emulation and enhances serial port emulation (at least for DirectSerial mode -- now MegaBuild5 switches DSR-DTR/DCD signal pair (and CTS-RTS one also) correctly with appropriate hardware loopback used. I meant sending and querying status line operations at UART I/O port level (not via BIOS or DOS ints). S.
Re: Working on DOS VGA.
* On Fri, 2 Apr 2010, Damjan Jovanovic wrote: On Thu, Apr 1, 2010 at 8:20 PM, Saulius Krasuckas sauli...@ar.fi.lt wrote: * On Thu, 1 Apr 2010, Stefan Dösinger wrote: There's protected mode 32 bit, protected mode 16 bit, but no vm86 16 bit. So no real mode apps in Wine. We'd need to integrate a CPU emulator or JIT compiler into Wine to get this working. DOSBox does something like this already. I lack ideas about to what extent DOSBox could be integrated, but at least its CPU emulator could do. Or maybe DOSBox could even be bridged/integrated and do all the DOS stuff here? Then IIRC there were discussions in the past about integrating Qemu into Wine. Some folks at Darwine have achieved this to some degree: [1] AFAIK we can't integrate with DOSBox, Dosemu or FreeDOS for the same reason we can't integrate with Samba: their GPL licence. I am profane at licensing, but does GPL restrict even usage of binary (linking, execution), or only a compilation of source code? in my experience QEMU is very slow when it does full emulation. Should not be slower that eg. BOCHS. S.
Re: Working on DOS VGA.
* On Thu, 1 Apr 2010, Stefan Dösinger wrote: Am 01.04.2010 um 11:24 schrieb Roderick Colenbrander: Myself I'm a bit worried about whether we should improve our DOS support even further. The problem is that more and more people are moving over to 64-bit Linux. While you can run 32-bit programs on a 64-bit system, there is no protected mode support (vm86; there is emulation in some cases using a kernel module). There's protected mode 32 bit, protected mode 16 bit, but no vm86 16 bit. So no real mode apps in Wine. We'd need to integrate a CPU emulator or JIT compiler into Wine to get this working. DOSBox does something like this already. I lack ideas about to what extent DOSBox could be integrated, but at least its CPU emulator could do. Or maybe DOSBox could even be bridged/integrated and do all the DOS stuff here? Then IIRC there were discussions in the past about integrating Qemu into Wine. Some folks at Darwine have achieved this to some degree: [1] That probably won't fly directly [2] but some aspects of the design of an emulator integration can be investigated already, IMHO. S. [1] http://darwine.sourceforge.net/docs/dev-doc.xml [2] http://wiki.winehq.org/FAQ#head-5804ec2bb090feaf81f572993444efd8ec2a8569
Re: on most hated OS in the history of computing
Hello * On Sun, 28 Mar 2010, Damjan Jovanovic wrote: Out of interest, why were you visiting openwatcom.org? Are you also looking into Win16 tests for Wine? Kind of. I was looking into licensing problems preventing its inclusion in Debian. Seems like I should try starting negotiation between OWC folks and Debian-legal experts on slight license changes. S.
on most hated OS in the history of computing
Hello, This article is about Windows 3.x history and architecture: http://www.openwatcom.org/index.php/Exploring_Windows_3.x It was nice sunday reading :) for me. S.
Re: on most hated OS in the history of computing
* On Sun, 28 Mar 2010, James Mckenzie wrote: Saulius Krasuckas sauli...@ar.fi.lt wrote: Hello, This article is about Windows 3.x history and architecture: http://www.openwatcom.org/index.php/Exploring_Windows_3.x It was nice sunday reading :) for me. Interesting that ANYONE would consider any version of Windows 3.x as an operating system. That's why it is embraced with inverted commas :) Now, computing environment is a different answer. Definitely! S.
Re: Kernel mode tests?
* On Fri, 19 Mar 2010, Damjan Jovanovic wrote: We've already got ntoskrnl.exe, hal.dll, mountmgr.sys and usbd.sys, The problem, of course, is that on Windows these all run in kernel mode. So what would be a good way to structure these regression tests? We could cross-compile each test to a .sys file, Is it possible already using MinGW? install and load that, call it from user-space to run the tests, then unload and uninstall. Couldn't each test stay primarily as .exe with an accompanied .sys file? This would cover Kernel-User inter mode communication as well. This would work, but has the problem that a lot of complexity is necessary to set up the tests (driver signing, administrator access, UAC, etc.), Some of WinAPI tests also requires Administrator access and UAC, AFAIK. and any bugs that would crash a user-space application would now crash Windows instead (we all know how easy that is :-). For me it isn't a problem, because a Win-box under the risk isn't required to do somehing else. Besides, test drivers could probably use exception handling to prevent some crashes. Ah, SEH is only particularly used in usual Wine's test executables, so this statement is of no use, probably. Another possibility might be to use a custom program loader to load the Windows .sys file being tested into user-space, the way we do now on Wine, and test it like that. This seems to preclude us from testing ntoskrnl.exe and hal.dll though. Plus it sounds like porting Wine core into Win32 and writing additional code to test the portage :( Thus I vote for the first way. S.
recent winmm/midimap tests
Hi folks is it only me getting short midi-like sounds during non-interactive run of Winetest, or is this known new bug already? S.
DirectMusic emulation (Was: DirectX Emulation Question)
* On Thu, 15 Oct 2009, Paul Janoski wrote:
Can anybody please tell me how complete the DirectMusic wine emulation
is on Linux.
The main contributor seems to be Rok Mandeljc (judging from the filtered
output of git-blame):
$ time (for fn in dlls/dm*/*.c dlls/dswave/*.c; do \
git-blame $fn; \
done | \
awk '{match($0, /\([^0-9]+/); print substr($0, RSTART+1, RLENGTH-1) }' | \
sort | uniq -c | sort -rn | head -n 12)
17937 Rok Mandeljc
4848 Raphael Junqueira
1417 Alexandre Julliard
1232 James Hawkins
948 Rok Mandeljc
738 Michael Stefaniuc
643 Mike McCormack
482 Rok Mandeljc
475 Raphael Junqueira
447 John K. Hohm
396 Not Committed Yet
390 Andrew Talbot
real4m31.957s
user4m26.097s
sys 0m4.184s
And he is probably the one [1] who could answer you most correctly.
I could add that once I stuck upon TiMidity++ [2] and FluidSynth [3]
software. IMHO it could help implementing such class objects as
IDirectMusicSegment8, IDirectMusicSegmentState8, IDirectMusicStyle8 and
probably IDirectMusicPerformance8 or even IDirectMusicAudioPath8.
[1] http://www.winehq.org/pipermail/wine-devel/2009-June/076568.html
[2] http://timidity.sourceforge.net/
[3] http://fluidsynth.resonance.org/trac
Re: PowerPC MacOSX work...
* On Tue, 26 May 2009, mghug...@embarqmail.com wrote: Download link did not work... Would have been good to look at/try/experiment with, but not what I am looking/aiming for. You could probably want to google for Programmer's File Editor v0.07.001 (file pfe0701p.zip), for example this link: [1]. Quoting [2]: | This is the 0.07.001 release of Programmer's File Editor, a | large-capacity multi-file programming oriented editor for Windows 95, | Windows NT 3.51 and 4.0 on Intel and PowerPC platforms, and Windows 3.1x [1] http://128.40.77.181/ccp/web-mirrors/pfe/people/cpaap/pfe/pfe0701p.zip [2] http://www-personal.engin.umd.umich.edu/~nnarasim/courses/ece373/hc11/pfe32/readme.txt
Winprinfo tool
I just have struck one tool related to Windows printer drivers [*]: | In the process of developing a Windows printer driver, we created this | winprinfo tool to allow us to query the printer system from the point of | view of an application: there are several APIs that permit a wide range | of query. This tool exercises them all and proved to be indispensible in | our development. ... | Once a printer has been opened, there are several Win32 API calls that | can be used to query the device. These are DeviceCapabilities(), | GetDeviceCaps, and EnumForms() (there may be more, but we'll add them as | we discover them. | | Driver Info / GetPrinterDriver() | By fetching a DRIVER_INFO_4 object for this printer, we're able to | show the version (kernel or user), as well as the paths used for all the | support files (driver and UI DLLs, plus the dependent files). | | DEVMODE / DeviceCapabilities() | A central data structure involved in printing is the DEVMODE, which | is a collection of settings that apply to a printjob. Each printer has a | group of default settings that are used in the absense of any user input | on the subject, and they are managed with the printer's setup GUI. | Using the DeviceCapabilities() API function, we are able to extract | a number of individual parameters from the DEVMODE and report them. | | GetDeviceCaps() | Since a printer is a graphics device, there are some kinds of | parameters that are in common with other devices such as video displays. | The GetDeviceCaps() call returns a small set of numeric parameters, many | of which have no real interest to printer developers. | | EnumForms() | The NT print spooler supports the notion of forms, which is simply | a way of attaching a name to a specifically-sized piece of output media. | There are built-in sizes such as Letter and Legal, but there are at | least a hundreds defined for oddball paper sizes all over the world. A | print driver can define additional forms as well, though the interaction | between the central forms database and the driver is still a little | unclear. My guess, it could usefull for guys like Detlef working on Winspool and Co. also. Then it can query printers over SMB. One more (probably) interesting note (with regard to running the tool on Wine): | We built this to run strictly on NT/Win2000/XP platforms: if it works at | all on Win95/98/ME, we'd be very surprised. [*] http://unixwiz.net/tools/winprinfo.html
Winprinfo tool
(Excuse me for the flowed format in my previous msg) I just have struck one tool related to Windows printer drivers [*]: | In the process of developing a Windows printer driver, we created this | winprinfo tool to allow us to query the printer system from the point of | view of an application: there are several APIs that permit a wide range | of query. This tool exercises them all and proved to be indispensible in | our development. ... | Once a printer has been opened, there are several Win32 API calls that | can be used to query the device. These are DeviceCapabilities(), | GetDeviceCaps, and EnumForms() (there may be more, but we'll add them as | we discover them. | | Driver Info / GetPrinterDriver() | By fetching a DRIVER_INFO_4 object for this printer, we're able to | show the version (kernel or user), as well as the paths used for all the | support files (driver and UI DLLs, plus the dependent files). | | DEVMODE / DeviceCapabilities() | A central data structure involved in printing is the DEVMODE, which | is a collection of settings that apply to a printjob. Each printer has a | group of default settings that are used in the absense of any user input | on the subject, and they are managed with the printer's setup GUI. | Using the DeviceCapabilities() API function, we are able to extract | a number of individual parameters from the DEVMODE and report them. | | GetDeviceCaps() | Since a printer is a graphics device, there are some kinds of | parameters that are in common with other devices such as video displays. | The GetDeviceCaps() call returns a small set of numeric parameters, many | of which have no real interest to printer developers. | | EnumForms() | The NT print spooler supports the notion of forms, which is simply | a way of attaching a name to a specifically-sized piece of output media. | There are built-in sizes such as Letter and Legal, but there are at | least a hundreds defined for oddball paper sizes all over the world. A | print driver can define additional forms as well, though the interaction | between the central forms database and the driver is still a little | unclear. My guess, it could be usefull for guys like Detlef working on Winspool (and Co.) also. Then it can query printers over SMB. One more (probably) interesting note (with regard to running the tool on Wine): | We built this to run strictly on NT/Win2000/XP platforms: if it works at | all on Win95/98/ME, we'd be very surprised. [*] http://unixwiz.net/tools/winprinfo.html
Re: Serial port conformance tests
* On Mon, 23 Mar 2009, Chris Teague wrote: very useful tool would be a serial port loopback device. Rather than require conformance testers to attach a hardware loopback device (NULL modem) to a physical port, could we create some virtual ports in wine and connect them together? Maybe com98 and com99 for example? Anything written to one of the ports would be sent to the other one. Chris, none of my very business, but do you need to test only Tx/Rx lines, o some more? (like DTR, RTS and the rest) * On Tue, 24 Mar 2009, Alexandre Julliard wrote: Serial data and ioctls are forwarded straight to the kernel, so you'd need to put the loopback driver in the kernel, not in Wine. Basic tests could probably cover Tx/Rx signals only, so IMHO none kernel module would be necessary -- some user space app can suffice (remserial, socat, nullmodem). But that would tie such test to a specific configuration of a particular linux box... Alexandre, for the core operation your proposal sounds very reasonable, but in the case of winetest, how it would work on Windows? For tests, I suppose Wine really needs some stubby serial driver (eg one comming from the mentioned com0com), which would then communicate with ntdll/wineserver, where the missing functionality could probably be redirected to the linux kernel, when it's implemented there. No? With regard to Chris: personally I would start hacking at making com0com to work on Wine.
Re: Running 16 bit builtin exes fails?
As many developers (Dan, Steven) already have mentioned this feature since 2005..: * On Sun, 8 Mar 2009, Alexandre Julliard wrote: * Dan Kegel d...@kegel.com writes: Also, I was hoping we really had a solution for building 16 bit executables, but objdump reports that it's all 32 bit code. Should it still be possible to write win16 tests with this infrastructure (lightly extended, if needed)? No, it's not possible. We don't have any way of building 16-bit code with gcc. All 16-bit stuff in Wine is actually 32-bit code, with functions explicitly suffixed with '16' etc. You can't possibly build real 16-bit apps this way. Would it be acceptable to use Open Watcom C compiler to crosscompile the 16-bit part? (v1.8 released two weaks ago)
IE, mshtml.dll, oledb32.dll and vulnerability in XML parsing / data binding
Hello, I noticed article about some IE issue: [1] And couldn't stop smiling at the amount and spectre of the workarounds needed to prevent attacks ;) And maybe Jacek (or some other mshtml guy) could test Wine's html engine against the external test case [2] to see whether we are better at handling [3] such XMLs. [1] http://www.pcmag.com/article2/0,2817,2336831,00.asp [2] http://www.milw0rm.com/exploits/7410 [3] http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4844
GLee library (Was: Re: [5/6] WineD3D: Remove some #ifdefs)
* On Mon, 21 Jul 2008, H. Verbeet wrote: Right now it's simply broken of course. The extension being defined in the header is no guarantee the driver actually supports it. Just in a case: today I stuck upon some lib called GLee: | GLee provides a simple interface for using extensions and core OpenGL | functionality beyond OpenGL version 1.1, and automates the otherwise | tedious process of linking function pointers. GLee works with both C and | C++ compilers. | | Because the code is automatically generated, the latest extensions can | be included rapidly in new versions. Currently there is support for | OpenGL up to 3.0 and almost all registered extensions. For a complete | list of extensions, please see the accompanying extensionList.txt file. I am not sure if it's code helps (or hurts) wined3d development, but the description looked attractive to me. For those interested in it: http://elf-stone.com/glee.php http://elf-stone.com/downloads/GLee/readme.txt
Re: winequartz.drv Mac OS X UI discontinued?
Sorry for the lag, * On Thu, 10 Jul 2008, Adam Strzelecki wrote: Is it really technically impossible to access the Quartz APIs or write Mac applications using C? Well it is possible, for example iTunes is non Objective-C Carbon (API) app AFAIK. Problem is that Carbon (pure C interface) is considered as deprecated by Apple and may disappear from future releases of OSXes at all, most 98% of applications are Objective-C Cocoa anyway. Moreover most of the functionality introduced in 10.5 or 10.4 went just into Cocoa, and never was backported to Carbon. So it isn't matter that it isn't possible, but it is IMHO more reasonable to do it in Objective-C. Then what about some thunking from carbonic source code to binary Objective-C code? Well, I have found some text [1] on the web about bridging D (not C) [2] with ObjectiveC: | So basically, since the whole Objective-C runtime is accessible from C | calls, it’s pretty easy to do whatever we want with it. If that's true, then some MacOSy hacker should give it a try. The bigger task here probably would be implementation of some callback stuff in C with the right calling convention / ABI (as ObjC seems to send some kind of messages back). Somewhat scary part may be bridging of exception handling, but if Wine did this for WinAPI, with gobjc/libFoundation present and with Apple docs given [3] it should be doable also. I googled a bit more. There are at least two ways of achieving this mentioned in the docs of libFoundation: by using XML-RPC call and by wrapping classes in ANSI-C APIs. [4] And the last -- I found libffi for Unix-like systems which seems to be used on the MacOS X [5]: | On Mac OS X libffi is commonly used with BridgeSupport, which provides | programming language neutral descriptions of framework interfaces, and | Nu which binds direct Objective-C access from Lisp. HTH. [1] http://michelf.com/weblog/2007/d-objc-bridge/ [2] http://en.wikipedia.org/wiki/D_(programming_language) [3] http://www.google.lt/search?q=+objectivec+abi+site:developer.apple.com [4] http://www.opengroupware.org/en/devs/languages/ansic/index.html [5] http://en.wikipedia.org/wiki/Libffi
Re: Lots of input messages lingering in server slowing down wine tremendously?
* On Mon, 14 Apr 2008, Alexander Dorofeyev wrote:
I was able to isolate it in a very small and simplistic testcase, which
shows this same problem. It will be included as attachment. Holding a
key and moving mouse over the window steadily increases main loop
latency from 10 to 50 (and even 100) in a short time, especially so if
quickly clicking both mouse buttons as well. In a game this means going
from 100 fps to 20 or 10 just because of input messages.
...
Now, I do realize that what the testcase is doing is bad practice, it's
basically refusing to process certain types of messages, and PeekMessage
just once during a loop is probably bad as well, but that's what the
game was originally doing in its main game loop. They do plan to fix it
in the game. Still, there are several concerns about it:
1) No slowdown happens of Windows as far as I can tell. No matter how
much I move the mouse holding key and clicking madly, it shows same
stable 15-16 ticks latency in the testcase. I don't know what it does,
but somehow it handles this situation better than Wine.
I am not minded in this area, Alexander (an am a bit away in time), but is
it algorithmically possible to convert this code to somewhat reliable test
case which wouln't depend on CPU perfomance(s) (by any chance)?
#include windows.h
HWND window;
int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int nCmdShow)
{
WNDCLASS wc = {0};
MSG msg;
DWORD ticks, ticks2;
HHOOK kbd_hook, mouse_hook;
wc.lpfnWndProc = DefWindowProc;
wc.lpszClassName = testwc;
RegisterClass(wc);
window = CreateWindow(testwc, test, WS_OVERLAPPED | WS_VISIBLE |
WS_CAPTION , 0, 0, 640, 480, 0, 0, 0, 0);
ticks = GetTickCount();
for (;;) {
if (PeekMessage(msg, NULL, WM_NULL, WM_KEYFIRST, PM_REMOVE)) {
if (msg.message == WM_QUIT) {
DestroyWindow(window);
break;
}
TranslateMessage(msg);
DispatchMessage(msg);
}
//simulated work
ticks2 = GetTickCount();
for (;;) {
UINT i;
volatile int dummy = 1;
for (; i 1 dummy; i++) ;
if (GetTickCount() - ticks2 = 10) break;
}
printf(main loop %u tick latency\n, GetTickCount() - ticks);
ticks = GetTickCount();
}
}
Re: What to do about filenames legal in Linux but illegal in Windows?
* On Mon, 21 Apr 2008, Dan Kegel wrote: (I believe that in both Windows and Wine, directory listings will show these illegal chars, but attempts to open the files will fail.) ... I looked around a bit today for a way to open such files in Windows, and failed miserably ... Anyone know of a way on real Windows to do this? For a files that were at least undeletable I remember I have been using a feature of Total Commander to switch format of files displayed to a Short/Long form. Not all files give up for me this way, but half of them did, though.
Re: LoadStringW [1/2]
* On Mon, 7 Apr 2008, Dmitry Timoshkov wrote: * Saulius Krasuckas [EMAIL PROTECTED] wrote: If the regression can be identified by someone able to read the code and not by a regression test that doesn't matter. Could you show me appropriate code lines of LoadStringA and a logic to follow, please? I am schocked. Dmitry, for me your statement is true only in the case of reading original code of appropriate DLL from MS :( I suspect that you will be shocked even more if someone would say that something is really wrong out there if there is a need to explain what this list is about, And I am not asking for this. Plus, You still have not answered my question: how regression in question can be identified only by reading Wine code (at least in case of LoadStringA). how the patch review process is going, and which code is reviewed in the process. So do you say Wine HQs aren't willing to attract more casual contributors to Wine code via wine-devel@ anymore? :(
Re: LoadStringW [1/2]
* On Wed, 9 Apr 2008, Dmitry Timoshkov wrote: * Saulius Krasuckas [EMAIL PROTECTED] wrote: You still have not answered my question: how regression in question can be identified only by reading Wine code (at least in case of LoadStringA). I have no idea how the word 'only' has appeared in the sentence above, I am sorry for my hurry, it's really unnecessary here. and why it's not clear to you that reading Wine code is one of possible ways to understand what the patchs does, and see possible improvements or regressions caused by a patch. Or you know development methods which don't require reading and understanding the code you are going to modify? Well, what I meant was if you haven't tested LoadStringA in Windows, then reading code won't help you to see a bug in it. Excuse me my English, if earlier msgs of mine didn't sound like that. Such is specifity (peculiarity) of any API translator, no? I don't follow your logic here. Well, switching to private comm.
Re: LoadStringW [1/2]
* On Fri, 4 Apr 2008, Dmitry Timoshkov wrote: If the regression can be identified by someone able to read the code and not by a regression test that doesn't matter. Could you show me appropriate code lines of LoadStringA and a logic to follow, please? I am schocked. Dmitry, for me your statement is true only in the case of reading original code of appropriate DLL from MS :(
Re: LoadStringW [1/2]
* James Hawkins wrote: * On Jan 21, 2008 2:14 PM, Christopher wrote: * Dmitry Timoshkov wrote: Also, you need to test LoadStringA, to see if it behaves similarly. It would be also interesting to test LoadStringA/W with both buffer and buffer length set to 0. I tested LoadStringA under Windows XP, and calling it with buflen == 0 does not return a pointer to the resource. In fact LoadStringA seems to behave fairly differently from LoadStringW: in that calling with buffer == NULL causes an access violation instead of just returning 0. That's why you need to add tests for LoadStringA to Wine's test suite. No, he did not. The word need wasn't appropriate here. Christopher wasn't going to change LoadStringA. If changes of LoadStringW breaks LoadStringA then tests would show regression. If tests are too weak, then only patch commiter or previous patchers of the LoadStringA are to blame, not the casual contributor who enhances B. And if this is some new official rule for code, then I don't find it on the site:www.winehq.org . Of course, I don't protest at the idea (as I would do the same as Dmitry wrote), but I protest against usage of this particular word -- it's too strong here. Please, be more accurate with it. P.S.: James, you probably should start learning to cut unnecessary blocks of quoted text (esp. empty lines) and doing some block justifying in your replies using your MUA some day. Otherwise it gets too hard to read a discussion.
Re: user32: Test destroying the cursor of a parent process.
* On Tue, 8 Jan 2008, Eric Pouech wrote:
* Andrew Riedi a écrit :
dlls/user32/tests/cursoricon.c | 201
...
+static void do_child(void)
+{
+WNDCLASS class;
+MSG msg;
+BOOL ret;
+
+/* Register a new class. */
+class.style = CS_GLOBALCLASS;
+class.lpfnWndProc = callback_child;
+class.cbClsExtra = 0;
+class.cbWndExtra = 0;
+class.hInstance = GetModuleHandle(NULL);
+class.hIcon = NULL;
+class.hCursor = NULL;
+class.hbrBackground = NULL;
+class.lpszMenuName = NULL;
+class.lpszClassName = cursor_child;
+
+SetLastError(0xdeadbeef);
+ret = RegisterClass(class);
+ok(ret, Failed to register window class. Error: %d\n,
GetLastError());
...
IMO, the ok() tests in the child process are a bad idea (they won't be
counted, nor returned as errors, by the parent process)
Was Wine test framework architecture done such way on a purpose? Why
would it be a bad idea to take into account a child output also?
Re: [PATCH 04/14] inetcomm: Add self-registration code.
* On Fri, 2 Nov 2007, Robert Shearman wrote: I just thought I'd note that while the From: header said these patches came from me, Huw actually sent them, which I think is a deficiency in some of the git tools. I suspect the time is also the same issue. I may be writing this too late, but my MUA (pine) shows all the interesting info right there in the message view: Date: Fri, 2 Nov 2007 11:35:34 + From: Robert Shearman [EMAIL PROTECTED] Reply-To: wine-devel@winehq.org To: wine-patches [EMAIL PROTECTED] Subject: [PATCH 01/18] inetcomm: Add stub implementation of inetcomm.dll. Resent-Date: Fri, 2 Nov 2007 12:21:28 + Resent-From: [EMAIL PROTECTED] Resent-To: [EMAIL PROTECTED] So I already did know which it was sent (and then resent) by. :) Well, maybe only time stamp was reset, I am not sure.
Re: COM/DCOM of WINE
* On Thu, 25 Oct 2007, L. Rahyen wrote: * On Thursday October 25 2007 08:08, Fong, Man To wrote: The communication protocol, pre-defined by TCS manufacturing, is DCOM. Since the communication protocol is not opened by the manufacturer. We must install the API provided by the manufacturer on our workstation running on Linux. Does WINE support the DCOM function? ... If something will not work for you please fill a bug report at http://bugs.winehq.org . In case if builtin DCOM support doesn't work as expected you can run winetricks dcom98 to use native DCOM instead (you can download winetricks at http://kegel.com/wine/winetricks ). If this workaround helps you should mention this in your bug report as well. IANAL, but for being legal this way requires a user to have valid Windows Licence (or so). One of at least Win98, AFAIK.
Re: bug 9986
* On Fri, 26 Oct 2007, Damjan Jovanovic wrote: * On 10/26/07, Reece Dunn wrote: * On 25/10/2007, Juan Lang wrote: Tests would also be useful here as well, so that there is not a regression. That's good general advice, but hard to implement without a serial device to test against, which our test systems won't have. You could always skip the tests when a serial connection is not present. That way, you get coverage on systems that do have them. It should be possible to configure Virtual Machines that have serial ports suitable for use in these tests. ... You can emulate a serial port, but that requires kernel-mode drivers in at least Windows, and emulating hardware that plugs into the emulated port isn't much easier. Yes, but this is possible. I believe, the ideal state would be when MinGW support for compiling device drivers + Wine support for running KMD is good enough. It probably should be a separate software project, though, as it will require very specific driver coding and testing-on-Windows manpower. No?
Re: icmp states I need to be running wine as root
* On Sun, 21 Oct 2007, Juan Lang wrote: Isn't there another way to do this than with SOCK_RAW, or having to run wine as root? In answer to your second question: yes, modify the Linux kernel not to have such restrictions. Well, there are already patches which modifies it in one way or another. I refer to man 7 capabilities or web resources [1]-[3]. Some of approaches may be abandoned already, but I see recent discussion [4] on this and by [5] I judge SELinux already can handle this task. Plus, I have found some recently updated tool called Filesystem capabilities for linux which also is not POSIX compatible (and so were old capabilities implementation for linux kernel): | With this patch, you will be able to grant selective privileges to | executables on a needed basis. This means for some executables, there is | no need anymore to run as root or as a suid root binary. | | For example, you may drop the SUID bit from ping and grant the | CAP_NET_RAW capability: | | # chmod u-s /bin/ping | # chcap cap_net_raw=ep /bin/ping If this is acceptable solution, then it probably would be nice for Wine to have separate binary for every needed capability. CAP_NET_RAW (for ICMP), CAP_SYS_RAWIO (for IO ports) and CAP_SYS_NICE (for threads priority) comes to mind. This plan is to don't force users to give the bunch of capabilities to the main Wine binary (or even several of them) at once (so the security risk should be increased in a minimal way). But well, that could be a minor nuance for such users. [1] http://www.securityfocus.com/infocus/1400 [2] http://lwn.net/Articles/79185/ [3] http://lwn.net/Articles/199004/ [4] http://lkml.org/lkml/2006/9/18/100 [5] http://lwn.net/Articles/79208/ [6] http://www.olafdietsche.de/linux/capability/
Re: Patch: ntoskrnl.exe - Added PsCreateSystemThread
* On Fri, 21 Sep 2007, Stefan [iso-8859-1] D�singer wrote: * Am Donnerstag, 20. September 2007 03:49:40 schrieb Carroll Vance: I have tested this with a driver I made and it seemed to work fine. I don't know much about ntoskrnl.exe, but if you have a test driver, you may want to include it in the patch. Doesn't that need to be product' licence compatible? Other libraries have a set of regression tests in dlls/lib/tests . ntoskrnl.exe doesn't have any yet, but I don't know if that is a policy or just because no one started it yet. Cool idea, of course, but my old question is: Does MinGW have any support for compiling KMD/WDM binaries today?
Using [GS]etWindowLong{Ptr} in tests
Hello. I see some tests call [GS]etWindowLongPtr(..., GWLP_WNDPROC, ...).
I think this is somewhat confusing. API offers both A- an W- versions of
this function, while at my first glance I cannot firmly decide, what used
name does refer to.
Shouldn't occurences be renamed to ...WindowLongPtrA() here (or even all
occurrences {by not requiring second parameter == GWLP_WNDPROC}) ?
Same question stands for [GS]etWindowLong().
Re: Using [GS]etWindowLong{Ptr} in tests
* On Sat, 9 Jun 2007, Dmitry Timoshkov wrote: * Saulius Krasuckas [EMAIL PROTECTED] wrote: API offers both A- an W- versions of this function, while at my first glance I cannot firmly decide, what used name does refer to. ... The code is correct as it is now, I talk about corectness of the naming, not of a code. there is no need to change anything. Then could you answer me, please, why there is used both SetWindowLongPtrA() and SetWindowLongPtr() in the same file (dlls/user32/tests/win.c) ? Didn't you find that confusing?
Re: Using [GS]etWindowLong{Ptr} in tests
* On Sat, 9 Jun 2007, Dmitry Timoshkov wrote: Since I have written a large part of that code, I can answer it: some parts have been written under Windows, therefore no A/W suffix, since that's how it's usually done in the Windows world, some code has been copied from Wine parts, and they obviously have it. Did that restrict us from using single naming scheme? Didn't you find that confusing? No. The project needs some voting mechanism, I'd say. Well, Alexandre's vote would get an additional queue then, of course. ;)
Re: Using [GS]etWindowLong{Ptr} in tests
* On Sat, 9 Jun 2007, Dmitry Timoshkov wrote: * Saulius Krasuckas [EMAIL PROTECTED] wrote: The project needs some voting mechanism, I'd say. It's already in place. Namely how can I enter a new voting for renaming * to *A, then?
Re: Using [GS]etWindowLong{Ptr} in tests
* On Fri, 8 Jun 2007, James Hawkins wrote: * On 6/8/07, Saulius Krasuckas [EMAIL PROTECTED] wrote: * On Sat, 9 Jun 2007, Dmitry Timoshkov wrote: * Saulius Krasuckas [EMAIL PROTECTED] wrote: The project needs some voting mechanism, I'd say. It's already in place. Namely how can I enter a new voting for renaming * to *A, then? You send in a patch to wine-patches, and it either gets accepted or rejected by the community, and ultimately, by Alexandre. Didn't I just say that Alexandre's vote is a different thing from what I want to see? :)
Re: Using [GS]etWindowLong{Ptr} in tests
* On Fri, 8 Jun 2007, James Hawkins wrote: * On 6/8/07, Saulius Krasuckas [EMAIL PROTECTED] wrote: * On Fri, 8 Jun 2007, James Hawkins wrote: * On 6/8/07, Saulius Krasuckas [EMAIL PROTECTED] wrote: * On Sat, 9 Jun 2007, Dmitry Timoshkov wrote: * Saulius Krasuckas [EMAIL PROTECTED] wrote: The project needs some voting mechanism, I'd say. It's already in place. Namely how can I enter a new voting for renaming * to *A, then? You send in a patch to wine-patches, and it either gets accepted or rejected by the community, and ultimately, by Alexandre. Didn't I just say that Alexandre's vote is a different thing from what I want to see? :) Then you missed the first part of the sentence, about the community. I don't think so. Accepted or rejected by the community isn't numerical result of voting (which Dmitry wants to ensure me is present), while for example list from the page [1] is. The problem is, most of the community is on or near Alexandre's level, so we tend to agree on most things, I am fine with it, and this isn't a problem, IMHO. [1] http://appdb.winehq.org/votestats.php
Re: Using [GS]etWindowLong{Ptr} in tests
* On Fri, 8 Jun 2007, Alexandre Julliard wrote: Things don't get decided by popularity, but by technical merit. If you can make a good technical argument for a change it will go in; if you can't, gathering votes for it won't help. Ok, so what would you say about a benefit of renaming of SetWindowLongPtr to SetWindowLongPtrA ?
Re: Using [GS]etWindowLong{Ptr} in tests
* On Fri, 8 Jun 2007, Alexandre Julliard wrote: * Saulius Krasuckas [EMAIL PROTECTED] writes: Ok, so what would you say about a benefit of renaming of SetWindowLongPtr to SetWindowLongPtrA ? I wouldn't say anything at this point. It's up to you to explain what the benefits are, Well, I already said: there are two names used in one file, both for a single function. What if I add new test for it? I just don't know which name to use. What if I use SetWindowLongPtr and SetWindowLongPtrA interchangibly in my patch? I don't believe it's OK. why SetWindowLongPtr and not others, I am sorry, I didn't stuck upon other fns. I would ask about them too. why Dmitry is wrong in his objections, etc. He isn't wrong neither right. His arguments just didn't persuade me.
Re: wintrust: implement WintrustGetRegPolicyFlags and WintrustSetRegPolicyFlags
* On Sun, 3 Jun 2007, Juan Lang wrote: This function tries to open Software_Publishing key. ... So this key should be registered during wineprefix run at some point, right? No, it's simpler than that, the order of the tests is merely wrong. WintrustGetRegPolicyFlags calls WintrustSetRegPolicyFlags with the default value if the registry value doesn't exist. The call to WintrustGetRegPolicyFlags (line 333) should precede the RegOpenKeyExW call (line 325-326.) Well, I didn't dig into this yet, but on Windows tests aren't failing. So I guess this key arrives during Windows setup process. Can't be so?
Re: webpage: Update Fedora download information
* On Sat, 2 Jun 2007, Andreas Bierfert wrote: here is an upgrade for the fedora download information as I requested on w-d-l. Hi, your patch isn't in unified fromat. Probably add -u option.
Re: webpage: Update Fedora download information
I am sorry, this was meant to be private msg.
Re: wintrust: implement WintrustGetRegPolicyFlags and WintrustSetRegPolicyFlags
* On Mon, 14 May 2007, Juan Lang wrote:
+static const WCHAR Software_Publishing[] = {
+ 'S','o','f','t','w','a','r','e','\\',
+ 'M','i','c','r','o','s','o','f','t','\\',
+ 'W','i','n','d','o','w','s','\\',
+ 'C','u','r','r','e','n','t','V','e','r','s','i','o','n','\\',
+ 'W','i','n','t','r','u','s','t','\\',
+ 'T','r','u','s','t',' ','P','r','o','v','i','d','e','r','s','\\',
+ 'S','o','f','t','w','a','r','e',' ',
+ 'P','u','b','l','i','s','h','i','n','g',0 };
+static const WCHAR State[] = { 'S','t','a','t','e',0 };
+
/***
* WintrustGetRegPolicyFlags (WINTRUST.@)
*/
void WINAPI WintrustGetRegPolicyFlags( DWORD* pdwPolicyFlags )
{
-FIXME(%p\n, pdwPolicyFlags);
+HKEY key;
+LONG r;
+
+TRACE(%p\n, pdwPolicyFlags);
+
*pdwPolicyFlags = 0;
+r = RegCreateKeyExW(HKEY_CURRENT_USER, Software_Publishing, 0, NULL, 0,
+ KEY_READ, NULL, key, NULL);
+if (!r)
+{
+DWORD size = sizeof(DWORD);
+
+r = RegQueryValueExW(key, State, NULL, NULL, (LPBYTE)pdwPolicyFlags,
+ size);
+RegCloseKey(key);
This function tries to open Software_Publishing key. And creates it, if
the key didn't exist, I suppose. It is absent in a clean $WINEPREFIX.
Hence 4 test failures:
$ wine dlls/wintrust/tests/wintrust_test.exe.so register
register.c:327: Test failed: RegOpenKeyEx failed: 2
register.c:331: Test failed: RegQueryValueEx failed: 6
register.c:334: Test failed: Didn't get expected flags
register.c:341: Test failed: Didn't get expected flags
register: 43 tests executed (0 marked as todo, 4 failures), 0 skipped.
During next run failures are gone, and I get this difference between two
registry dumps:
+[HKEY_USERS\S-1-5-4\Software\Microsoft\Windows\CurrentVersion\Wintrust]
+
+[HKEY_USERS\S-1-5-4\Software\Microsoft\Windows\CurrentVersion\Wintrust\Trust
Providers]
+
+[HKEY_USERS\S-1-5-4\Software\Microsoft\Windows\CurrentVersion\Wintrust\Trust
Providers\Software Publishing]
+State=dword:00023c00
So this key should be registered during wineprefix run at some point,
right?
Re: problems regression testing/compiling wine
* On Sun, 13 May 2007, Louis Lenders wrote: * EA Durbin ead1234 at hotmail.com writes: No, that doesn't help, i've tried distclean, git clean -x, the usual make clean, and nothing works. Regression testing seems borked passed two bisects. I know I had the same problem, and somehow i got around it, but i forgot how ;( maybe rm -rf */*/*.def from wine's source tree. I tend to agree on this guess. But once regression interval starts occupying Wine versions delta = 1, usually I do: $ rm -rf dlls/; git checkout -f after every $ git bisect [bad|good] and before running ./configure .
Re: Winscard support (for smart cards)
* On Wed, 25 Apr 2007 [EMAIL PROTECTED] wrote: For the need of one of our projects, we are currently developing this dll for wine under Linux based on the pcsc-lite library. Cool. Once done, we'll share it with the community. Nice, but IMHO it would be best for the community if you will start doing this immediatelly, not once done. Otherwise you would probably step in a shoes of Transgaming' or Codeweavers' guys, patches from which src trees will have a somwhat hard way into Wine tree. However, we would like to known the reason behind the lack of winscard support. Is it simply because no one needed it before or maybe there is an issue with the pcsc-lite license? Thanks in advance for your information. IANAL, but if it's of BSD license, then that isn't an issue, AFAIK.
