Re: ddeml: More calling convention fixes
Tristan Schmelcher tristan_schmelc...@alumni.uwaterloo.ca wrote:
+if (cbData != (DWORD)-1)
+{
+/* pData is not a pointer if cbData is -1, so we linearize the
address
+ * here rather than in the calling code. */
+pData = MapSL((SEGPTR)pData);
+}
-1 here should be replaced by CBR_BLOCK, and this piece of the patch
should be sent separately from .spec file fixes.
--
Dmitry.
Re: poor Wine performance creating fat dialogs
On Wed, Dec 01, 2010 at 11:42:44PM +0100, Andreas Pflug wrote: Am 26.11.2010 13:39, schrieb Marcus Meissner: On Fri, Nov 26, 2010 at 01:06:32PM +0100, Andreas Pflug wrote: I'm investigating running a commercial ERP system under Wine (only binary available). It mostly works, but creating the main dialogs for item, customer and such will need around 25 seconds, while running on Wxx it takes 2-3 seconds. After that, there's no serious performance impact working on these dialogs. The dialogs contain a lot of controls, like 500 or so each, so I suspect that's what makes things slow. I'm willing to investigate this in the wine sources, if it makes sense. So before I start I'd like to know if there are known or suspected inefficient code regions that might cause the problem? Maybe some win-x11 translation tables that degrade with 1000+ windows? Or has this been observed before, and the problem is outside of wine's scope? In 1.2.0 there was such a bug which was fixed in 1.2.1. What version do you use? If not, have you tried the current development version? Maybe some regression in the git HEAD I'm using? If it would be a regression, do you know a good version which performs better? If you can pinpoint a good and a bad version, you can also try running a git bisect. See http://wiki.winehq.org/RegressionTesting Given the number of controls there probably are some scaling issues, not just one :/ ciao, Marcus
Re: [2/2] msi: Clear last error on success in MsiQueryFeatureState and MsiQueryProductState.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7392 Your paranoid android. === W2KPROSP4 (32 bit msi) === msi.c:618: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:633: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:646: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:666: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:677: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:695: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:705: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:716: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:727: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:736: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:972: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:979: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:994: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1004: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1028: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1037: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1046: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1055: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1064: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1086: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1095: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1104: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1114: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1124: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1134: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1144: Test failed: expected ERROR_SUCCESS, got 1008 msi.c:1154: Test failed: expected ERROR_SUCCESS, got 1008
Re: [4/4] shdocvw: In PersistFile_Save, output the Icon Path and Icon Index properties
On Thu, Dec 2, 2010 at 5:39 AM, Andrew Bogott and...@codeweavers.com wrote: This gets Icon Path and Icon Index written out to .url files if they've been set previously. I think you leak a reference to pPropStgRead here. Nice patch set otherwise :-) Damjan
Re: [PATCH 5/7] npmshtml: Added Mozilla plugin for mshtml ActiveX controls.
Jacek Caban ja...@codeweavers.com writes: I know that this patch is the most questionable. Gecko expects us to give it a DLL named np*.dll, so we can't do it in mshtml. Also, this plugin will be visible to other NPAPI-based browsers running in Wine (that's a matter of change in the next Gecko release), so it's good that it's a tiny wrapper that fails to load if mshtml is not loaded (meaning that we're not running in Wine Gecko). This prevents the dll registration code from running, since mshtml is not loaded at that point. -- Alexandre Julliard julli...@winehq.org
Death to win9x?
Dan Kegel wrote:
Like you, I'm afraid that dropping the win9x tests will lead
to regressions old older apps.
Greg Geldorp wrote:
However, they [Win9x VMs] would be available for selection
if you click Show all VMs button when submitting a job.
This sounds very desirable.
However, this only allows to run one test at a time, i.e. the big picture is
missing.
Therefore I'd suggest running winetest.exe on all testbot machines once a week
or some such, e.g. only for releases.
Later a student may write a thesis about the degradation of SW over time ;-)
An independent idea is to run a special winetest.exe compiled with
int broken(int condition) { return 0; }
once a week on (some of?) the regular machines.
However this is best performed *not* on release days, based on the
assumption that more people submit test data for release versions than
the day to day ones, and we don't want to pollute these with stricter tests.
Regards,
Jörg Höhle
Re: [PATCH 5/7] npmshtml: Added Mozilla plugin for mshtml ActiveX controls.
On 12/2/10 12:49 PM, Alexandre Julliard wrote: Jacek Cabanja...@codeweavers.com writes: I know that this patch is the most questionable. Gecko expects us to give it a DLL named np*.dll, so we can't do it in mshtml. Also, this plugin will be visible to other NPAPI-based browsers running in Wine (that's a matter of change in the next Gecko release), so it's good that it's a tiny wrapper that fails to load if mshtml is not loaded (meaning that we're not running in Wine Gecko). This prevents the dll registration code from running, since mshtml is not loaded at that point. Um, that was stupid from me. I've previously made NP_* function failing, but it didn't work well, so I've changed it to DllMain. I don't see a clean way to fix registration. We could set these registries from mshtml.dll, but then we lose the ability to easily unregister npmshtml.dll. I've sent a patch that checks if it's running from rundll32 or regsvr32 and allows the DLL to load them. I hope it's not too hackish. Jacek
Re: [PATCH 5/7] npmshtml: Added Mozilla plugin for mshtml ActiveX controls.
Jacek Caban ja...@codeweavers.com writes: Um, that was stupid from me. I've previously made NP_* function failing, but it didn't work well, so I've changed it to DllMain. I don't see a clean way to fix registration. We could set these registries from mshtml.dll, but then we lose the ability to easily unregister npmshtml.dll. I've sent a patch that checks if it's running from rundll32 or regsvr32 and allows the DLL to load them. I hope it's not too hackish. I don't think it's a good idea to try to magically fail on DLL load. It would prevent registering from other tools, loading to check version resources, etc. It's preferable to always allow it to load. Of course an even better way would be to change Gecko to make it possible to not have a separate dll at all... -- Alexandre Julliard julli...@winehq.org
Re: Death to win9x?
joerg-cyril.hoe...@t-systems.com writes: However, this only allows to run one test at a time, i.e. the big picture is missing. Therefore I'd suggest running winetest.exe on all testbot machines once a week or some such, e.g. only for releases. 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. -- Alexandre Julliard julli...@winehq.org
Re: Death to win9x?
My very tentative $.02: If there are tests we care about on Win9x (for old apps), wouldn't it be easier to move them to their own file/folder, and only run those and only those on 9x? If the regular tests are going to lose all their broken() calls and become meaningless on 9x, we still will want to test specific features on old versions of Windows (for old apps as Dan mentioned). That way, tests are still easier to write, but we don't lose that ability. JL On Thu, Dec 2, 2010 at 1:30 PM, Alexandre Julliard julli...@winehq.org wrote: joerg-cyril.hoe...@t-systems.com writes: However, this only allows to run one test at a time, i.e. the big picture is missing. Therefore I'd suggest running winetest.exe on all testbot machines once a week or some such, e.g. only for releases. 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. -- Alexandre Julliard julli...@winehq.org
Re: Death to win9x?
Alexandre Julliard julli...@winehq.org wrote: Sent: Dec 2, 2010 6:30 AM To: joerg-cyril.hoe...@t-systems.com Cc: wine-devel@winehq.org Subject: Re: Death to win9x? joerg-cyril.hoe...@t-systems.com writes: However, this only allows to run one test at a time, i.e. the big picture is missing. Therefore I'd suggest running winetest.exe on all testbot machines once a week or some such, e.g. only for releases. 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. YOU might not care about them AJ, but we have Wine users that are still using Windows95 programs with Wine on Linux and there are NO suitable replacements for them. Several recent user reports have asked how do I get program X (released for Windows95) to work on Wine. One of my test programs is dOOmII, released in 1996 and I use Wine to run it. Should I just go out and find a copy of Windows98SE and VirtualBox to run this on? Your reply makes it sound like the Wine program just does not care if Windows9x functionality does not matter, it does. I do agree that not much effort should be expended to incorporate more 'A' functionality, but breaking what does work is not reflect well on this project. Remember the original purpose and I think it is still the purpose is to build out the ENTIRE Windows64/32 API, not just a portion of it. If I'm wrong, feel free to chastise me. James McKenzie
Re: Death to win9x?
Am 02.12.2010 13:46, schrieb joerg-cyril.hoe...@t-systems.com:
An independent idea is to run a special winetest.exe compiled with
int broken(int condition) { return 0; }
I recently sent a patch to have a new debuglevel 2, but AJ wisely pointed out
we can simply set WINETEST_PLATFORM=wine on Windows which has the same effect.
So no need for such hacks :D
--
Best Regards, André Hentschel
Re: Death to win9x?
Am 02.12.2010 16:11, schrieb James Mckenzie: Should I just go out and find a copy of Windows98SE and VirtualBox to run this on? Your reply makes it sound like the Wine program just does not care if Windows9x functionality does not matter, it does. Shutting down the test does not necessary meens wine will break the 9x stuff over time. actually we just always need to do something like skip() or broken() and that's nothing else as ignoring the test results of 9x and as you still play that game i guess wine still works here. -- Best Regards, André Hentschel
Re: wineps.drv: return error if unable to select a builtin font
Aric Stewart a...@codeweavers.com writes:
@@ -191,6 +191,12 @@ BOOL PSDRV_SelectBuiltinFont(PSDRV_PDEVICE *physDev,
HFONT hfont,
if(!family)
family = physDev-pi-Fonts;
+if (!family)
+{
+ERR(Unable to get any font for printer\n);
+return FALSE;
+}
If this is something that can legitimately happen it should be handled
correctly.
--
Alexandre Julliard
julli...@winehq.org
Re: [1/2] wininet: Use proper error code define instead of its value
Nikolay Sivov nsi...@codeweavers.com writes: @@ -270,7 +270,7 @@ static DWORD netconn_verify_cert(PCCERT_CONTEXT cert, HCERTSTORE store, else if (chain-TrustStatus.dwErrorStatus ~supportedErrors) err = ERROR_INTERNET_SEC_INVALID_CERT; } -if (!err) +if (err == ERROR_SUCCESS) There's no reason to change this. 0 meaning success is a common convention, and at least as clear as using an error code for no error. -- Alexandre Julliard julli...@winehq.org
Death to win9x?
André Hentschel wrote: I recently sent a patch to have a new debuglevel 2, but AJ wisely pointed out we can simply set WINETEST_PLATFORM=wine on Windows which has the same effect. So no need for such hacks :D I once submitted a similar command line patch: runtest --strict :-) AJ is right. The only problem is that testbot does not allow me to set an environment variable. All testbot knows are command line arguments. One idea would be to be able to run winetest.exe inside testbot with enough command line arguments that it runs all tests and submits results on its own. Regards, Jörg Höhle
Re: [PATCH 5/7] npmshtml: Added Mozilla plugin for mshtml ActiveX controls.
On 12/2/10 2:23 PM, Alexandre Julliard wrote: Jacek Cabanja...@codeweavers.com writes: Um, that was stupid from me. I've previously made NP_* function failing, but it didn't work well, so I've changed it to DllMain. I don't see a clean way to fix registration. We could set these registries from mshtml.dll, but then we lose the ability to easily unregister npmshtml.dll. I've sent a patch that checks if it's running from rundll32 or regsvr32 and allows the DLL to load them. I hope it's not too hackish. I don't think it's a good idea to try to magically fail on DLL load. It would prevent registering from other tools, loading to check version resources, etc. It's preferable to always allow it to load. Agreed, but everything we can do will be some kind of hack. I've found the solution that seems much better. Although Gecko standard plugin directory service doesn't work well for us (the API is in place, it's just used by a high embedding layer in the way that prevents us from using it properly), but there is an environment variable that we can use to specify a custom plugin directory. The only drawback of it is that we need a special directory, but on the other side not having Wine-specific DLL in system directory is a good thing. Of course an even better way would be to change Gecko to make it possible to not have a separate dll at all... That's true and it was my initial intention. There was even partial support for such solution in Gecko (called XPCOM plugins), but it was removed from the tree. The only supported way for plugins is NPAPI. Its requirement for DLLs in rooted deep in the code. It means that if we decided to have a Wine-specific changes, we'd have to maintain more changes that I'd like. Integrating it with mainstream may be tricky. Partial solution that would require less Gecko changes is also possible, but it would still be a hack, just living in a different place. Jacek
Re: ddeml: More calling convention fixes
I think CBR_BLOCK is only for values of type HDDEDATA. The cbData
value here is a DWORD (specifying a length). (DWORD)-1 seems to be the
preferred way of checking this condition in the existing code, e.g.
see dlls/user32/dde_client.c lines 637, 648, etc.
I will re-send the patch in two parts.
On Thu, Dec 2, 2010 at 12:19 AM, Dmitry Timoshkov
dmi...@codeweavers.com wrote:
Tristan Schmelcher tristan_schmelc...@alumni.uwaterloo.ca wrote:
+ if (cbData != (DWORD)-1)
+ {
+ /* pData is not a pointer if cbData is -1, so we linearize the
address
+ * here rather than in the calling code. */
+ pData = MapSL((SEGPTR)pData);
+ }
-1 here should be replaced by CBR_BLOCK, and this piece of the patch
should be sent separately from .spec file fixes.
--
Dmitry.
Re: Death to win9x?
Am 02.12.2010 19:17, schrieb joerg-cyril.hoe...@t-systems.com: André Hentschel wrote: I recently sent a patch to have a new debuglevel 2, but AJ wisely pointed out we can simply set WINETEST_PLATFORM=wine on Windows which has the same effect. So no need for such hacks :D I once submitted a similar command line patch: runtest --strict :-) AJ is right. The only problem is that testbot does not allow me to set an environment variable. All testbot knows are command line arguments. you are free to send a patch for testbot to handle that (yes, testbot is open source) :) -- Best Regards, André Hentschel
Re: Death to win9x?
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. You may not care, but I know a number of people who do. For some running the older software is more important, of interest, or use.
Re: Death to win9x?
On Thu, Dec 2, 2010 at 8:00 PM, K.King k.king...@ntlworld.com 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. You may not care, but I know a number of people who do. For some running the older software is more important, of interest, or use. A majority of that effort is rewriting tests to make win9x happy, not rewriting behavior to fix win9x applications. Few people (if any) want to intentionally break win9x applications, but spending a large amount of developer effort to maintain the tests there isn't really the best investment, when it could instead be spent fixing real bugs. -- -Austin
Re: Death to win9x?
Austin English austinengl...@gmail.com wrote: On Thu, Dec 2, 2010 at 8:00 PM, K.King k.king...@ntlworld.com 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. You may not care, but I know a number of people who do. For some running the older software is more important, of interest, or use. A majority of that effort is rewriting tests to make win9x happy, not rewriting behavior to fix win9x applications. Few people (if any) want to intentionally break win9x applications, but spending a large amount of developer effort to maintain the tests there isn't really the best investment, when it could instead be spent fixing real bugs. This I do agree with. I'm working on tests for richedit and the expected reaction of the Win9x version is much different than the reaction of the WindowsXP version. I could drop the Win9x tests and concentrate on Windows 2000 and higher. Would this be a good course of action? James McKenzie
Re: Death to win9x?
The only problem is that testbot does not allow me to set an environment variable. All testbot knows are command line arguments. Well, you can use 7zip and its SFX-capabilities to do a lot more with testbot. I used this to invoke winhlp showing a specific helpfile :) For your case, you might embed a shell script or similar? Regards, Wolfram
Re: wineqtdecoder: initial commit of the video decoder using Mac OS/X QuickTime Framework
The main problem when using the QuickTime C APIs is that the majority, if not all of it, is deprecated and not available on 64-bit code. I would suggest using the Objective-C QTKit, but apparently Objective-C code is a no-no in Wine. On Nov 29, 2010, at 10:31 AM, Aric Stewart wrote: --- configure |8 +- configure.ac |5 + dlls/wineqtdecoder/Makefile.in| 11 + dlls/wineqtdecoder/main.c | 135 + dlls/wineqtdecoder/qtvdecoder.c | 536 + dlls/wineqtdecoder/version.rc | 26 ++ dlls/wineqtdecoder/wineqtdecoder.spec |4 + 7 files changed, 724 insertions(+), 1 deletions(-) create mode 100644 dlls/wineqtdecoder/Makefile.in create mode 100644 dlls/wineqtdecoder/main.c create mode 100644 dlls/wineqtdecoder/qtvdecoder.c create mode 100644 dlls/wineqtdecoder/version.rc create mode 100644 dlls/wineqtdecoder/wineqtdecoder.spec 89fa3b1cdaca45ec01cde9e2350010b82c985666.diff
Re: d3d8/d3d9: fix compiler warnings on non x86/x86_64
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7410 Your paranoid android. === W2K8SE (32 bit device) === device.c:1671: Test failed: Expected foreground window 00010126, got 0001011A. === W7PROX64 (32 bit device) === device.c:1671: Test failed: Expected foreground window 00030186, got 00010068. device.c:1810: Test failed: Expected foreground window 00040186, got 00010068.
Re: d3d8/d3d9: fix compiler warnings on non x86/x86_64
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7411 Your paranoid android. === WVISTAADM (32 bit device) === device.c:2512: Test failed: Expected foreground window 000101D6, got 000101D2. === W7PRO (32 bit device) === device.c:2512: Test failed: Expected foreground window 00020158, got 00020058. device.c:2651: Test failed: Expected foreground window 00030158, got 00020058. === W7PROX64 (64 bit device) === device.c:2512: Test failed: Expected foreground window 000F0176, got 00010068. device.c:2651: Test failed: Expected foreground window 00100176, got 00010068.
Re: user32/tests: skip more input tests on 98 and ME
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7412 Your paranoid android. === WVISTAADM (32 bit input) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation
Re: wineqtdecoder: initial commit of the video decoder using Mac OS/X QuickTime Framework
That was true of the first set of APIs i used. But I believe the ICMDecompressionSession APIs are available on 64-bit and not deprecated. -aric On 12/2/10 3:46 PM, C.W. Betts wrote: The main problem when using the QuickTime C APIs is that the majority, if not all of it, is deprecated and not available on 64-bit code. I would suggest using the Objective-C QTKit, but apparently Objective-C code is a no-no in Wine. On Nov 29, 2010, at 10:31 AM, Aric Stewart wrote: --- configure |8 +- configure.ac |5 + dlls/wineqtdecoder/Makefile.in| 11 + dlls/wineqtdecoder/main.c | 135 + dlls/wineqtdecoder/qtvdecoder.c | 536 + dlls/wineqtdecoder/version.rc | 26 ++ dlls/wineqtdecoder/wineqtdecoder.spec |4 + 7 files changed, 724 insertions(+), 1 deletions(-) create mode 100644 dlls/wineqtdecoder/Makefile.in create mode 100644 dlls/wineqtdecoder/main.c create mode 100644 dlls/wineqtdecoder/qtvdecoder.c create mode 100644 dlls/wineqtdecoder/version.rc create mode 100644 dlls/wineqtdecoder/wineqtdecoder.spec 89fa3b1cdaca45ec01cde9e2350010b82c985666.diff
Re: wineqtdecoder: initial commit of the video decoder using Mac OS/X QuickTime Framework
On 12/2/10 7:06 PM, Aric Stewart wrote: That was true of the first set of APIs i used. But I believe the ICMDecompressionSession APIs are available on 64-bit and not deprecated. chips-computer:/System/Library/Frameworks/QuickTime.framework chip$ nm -arch x86_64 QuickTime nm: file: QuickTime does not contain architecture: x86_64 chips-computer:/System/Library/Frameworks/QuickTime.framework chip$ Chip
Re: wineqtdecoder: initial commit of the video decoder using Mac OS/X QuickTime Framework
Humm, Yup you are right. I was chatting with Ken Thomases earlier today and he was talking about QTKit and how it is only Objective-C and the next step beyond QuickTime. I had not realized that there where no 64 bit versions of the Quicktime framework. I think we are stuck. Since we are using the Carbon framework not Cocoa we don't really have access to QTKit. We may as well use Quicktime since it is still available. -aric On 12/2/10 8:10 PM, Charles Davis wrote: On 12/2/10 7:06 PM, Aric Stewart wrote: That was true of the first set of APIs i used. But I believe the ICMDecompressionSession APIs are available on 64-bit and not deprecated. chips-computer:/System/Library/Frameworks/QuickTime.framework chip$ nm -arch x86_64 QuickTime nm: file: QuickTime does not contain architecture: x86_64 chips-computer:/System/Library/Frameworks/QuickTime.framework chip$ Chip
Re: Death to win9x?
On 12/2/10 10:43 AM, André Hentschel wrote: Am 02.12.2010 16:11, schrieb James Mckenzie: Should I just go out and find a copy of Windows98SE and VirtualBox to run this on? Your reply makes it sound like the Wine program just does not care if Windows9x functionality does not matter, it does. Shutting down the test does not necessary meens wine will break the 9x stuff over time. actually we just always need to do something like skip() or broken() and that's nothing else as ignoring the test results of 9x and as you still play that game i guess wine still works here. True, but what happens IF the game stops working? Will a bug report with regression test be accepted or will it be rejected? You can see there is a little fear if we stop testing Windows9x completely. However, if we move the Windows9x VMs out of the way so we can concentrate on current versions, that is a good idea as some functionality of the current Windows versions does not exist or is vastly different. James McKenzie
Re: [3/7] urlmon: Implemented PARSE_PATH_FROM_URL for CoInternetParseIUri
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7419 Your paranoid android. === WVISTAADM (32 bit uri) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation
Re: msvcrt: Implement wcsnicoll
Hi Mike, --- a/dlls/msvcr70/msvcr70.spec +++ b/dlls/msvcr70/msvcr70.spec @@ -601,7 +601,7 @@ @ cdecl _wcslwr(wstr) msvcrt._wcslwr @ stub _wcsncoll @ cdecl _wcsnicmp(wstr wstr long) msvcrt._wcsnicmp -@ stub _wcsnicoll +@ cdecl _wcsnicoll(wstr wstr long) msvcrt._wcsnicmp Typo?
Re: ddeml: More calling convention fixes
Tristan Schmelcher tristan_schmelc...@alumni.uwaterloo.ca wrote: I think CBR_BLOCK is only for values of type HDDEDATA. The cbData value here is a DWORD (specifying a length). (DWORD)-1 seems to be the preferred way of checking this condition in the existing code, e.g. see dlls/user32/dde_client.c lines 637, 648, etc. You are right. -- Dmitry.
Re: Death to win9x?
James McKenzie jjmckenzi...@earthlink.net wrote: True, but what happens IF the game stops working? Will a bug report with regression test be accepted or will it be rejected? Are you kidding? Something tells me that you have no idea what you are talking about. You can see there is a little fear if we stop testing Windows9x completely. However, if we move the Windows9x VMs out of the way so we can concentrate on current versions, that is a good idea as some functionality of the current Windows versions does not exist or is vastly different. Right now all the test results that differ for win9x versions are marked as broken(), i.e. Wine intentionally makes an effort to NOT replicate it. So removing checks for (broken) results will change nothing. People complaining that Wine no more cares about applications written for Win9x should calm down, support for win9x apps and removing broken() statements from tests has no any connection. -- Dmitry.
