Re: dlls/user32/combo.c: Fix an issue where pressing 's' in a combobox shows the dropdown isntead of finding an entry starting with 's'.
"David Quintana (gigaherz)" wrote: Issue was caused by VK_F4 having the same exact code as a lowercase 's'. So the code, which treated WM_CHAR and WM_KEYDOWN as the same, executed the wrong piece of code which was meant to be ONLY for WM_KEYDOWN. Thanks for spotting this bug. Anyway the fix is not correct. Virtual key codes should be tested only in the WM_KEYDOWN handler, WM_CHAR handler should test for character codes. Also, as Nikolay asked please don't use C++ comments in Wine code. -- Dmitry.
Re: Building and packaging Wine Gecko
On Mon, Dec 28, 2009 at 6:53 PM, Jacek Caban wrote: > On 12/29/09 1:44 AM, Ove Kaaven wrote: >> gcc 4.4.2 is already released, and >> Debian unstable is using it as the default compiler. And like I >> mentioned, they even have a mingw32 cross compiler of it. Would it then >> be a good idea to build wine-gecko git instead of wine-gecko 1.0.0? >> Should that work? >> > > That won't work, but I think it's better to spend time on working on the > next release. When is the next 'release' of wine-gecko planned? E.g., when will wine-gecko git become wine-gecko 1.1? -- -Austin
Re: avifile tests
Hi André André Hentschel wrote: > Julius Schwartzenberg schrieb: >> What do you think of the >> general idea of the tests? > > As i cant proof correctness here, i just can say that the general idea is great. > Until Bug 14085 is fixed you can todo_wine it out. Further i think you can leave the data in the c-file(we also have raw manifest data in c-files), but it should not be that hard to move it to a header. Thanks for your feedback! I don't think I can use todo_wine to work around this bug though or am I mistaken here? I kinda hope someone with a good J-rank is motivated by my patches to solve the problem ;) As by Dmitry's suggestion, I indeed moved all data to api.c now. Regards, Julius
Re: avifile tests
Hi Dmitry,
Thanks a lot for your feedback! I should've solved most issues you
pointed me at. I have attached a new version of the patch.
Dmitry Timoshkov wrote:
Indentation of above structure and all others below this one look strange.
4 spaces would be quite enough.
This was supposed to represent the RIFF tree with the headers being
tested taken out. The bottom part of the data is just needed to allow
both Windows' VFW and Wine's VFW to load the file.
Roderick also just found the indentation strange, so I got rid of it now.
Do you really need all that separate structures? Wouldn't it be simpler to
have a single buffer like in dlls/winmm/tests/mmio.c?
The reasons I chose to separate the structures:
To be able to separate the headers out that I specifically want to test.
I added an actual test to this version which shows how I imagine it to
be used. The values can be easily 'corrupted' now using the structures
as defined by the actual VFW headers.
To keep some structure. I only took a proper look at the audio stream,
but if someone has more knowledge on the video stream, they may now just
take the videopropheader array, move it up in the source, structure it
properly and write tests against it.
With the attached patch, all tests pass on MS Windows XP.
Regards,
Julius
>From 50ecf7728c68b60ebcff0c5e46e8332d124f1266 Mon Sep 17 00:00:00 2001
From: Julius Schwartzenberg
Date: Fri, 25 Dec 2009 20:29:43 +0100
Subject: initial version of avifile testing framework plus the first simple
tests
---
dlls/avifil32/tests/api.c | 320 +
1 files changed, 320 insertions(+), 0 deletions(-)
diff --git a/dlls/avifil32/tests/api.c b/dlls/avifil32/tests/api.c
index 55b194f..cfef4dc 100644
--- a/dlls/avifil32/tests/api.c
+++ b/dlls/avifil32/tests/api.c
@@ -35,6 +35,138 @@ static const CHAR winetest1[] = "winetest1";
/* ### */
+typedef struct common_avi_headers {
+MainAVIHeader mah;
+AVIStreamHeader ash0;
+AVIStreamHeader ash1;
+PCMWAVEFORMAT pcmwf;
+} COMMON_AVI_HEADERS;
+
+static const MainAVIHeader defmah =
+{
+0x8256, /* dwMicroSecPerFrame */
+0x80e8, /* dwMaxBytesPerSec */
+0x, /* dwPaddingGranularity */
+0x0910, /* dwFlags */
+1, /* dwTotalFrames*/
+0, /* dwInitialFrames */
+2, /* dwStreams*/
+0x0010, /* dwSuggestedBufferSize*/
+8, /* dwWidth */
+6, /* dwHeight */
+{ 0, 0, 0, 0 } /* dwReserved[4] */
+};
+
+static const AVIStreamHeader defash0 =
+{
+streamtypeVIDEO, /* fccType */
+0x30323449, /* fccHandler */
+0x, /* dwFlags */
+0, /* wPriority*/
+0, /* wLanguage*/
+0, /* dwInitialFrames */
+0x03e9, /* dwScale */
+0x7530, /* dwRate */
+0, /* dwStart */
+1, /* dwLength */
+0x0010, /* dwSuggestedBufferSize*/
+0x, /* dwQuality*/
+0, /* dwSampleSize */
+{ 0, 0, 0, 0 } /* short left right top bottom */
+};
+
+static const AVIStreamHeader defash1 =
+{
+/* AVIStreamHeader */
+streamtypeAUDIO, /* fccType */
+1, /* fccHandler */
+0, /* dwFlags */
+0, /* wPriority*/
+0, /* wLanguage*/
+0, /* dwInitialFrames */
+1, /* dwScale */
+0x2b11, /* dwRate */
+0, /* dwStart */
+0x0665, /* dwLength */
+0x3000, /* dwSuggestedBufferSize*/
+0x, /* dwQuality*/
+2, /* dwSampleSize */
+{ 0, 0, 0, 0 } /* short left right top bottom */
+};
+
+static const PCMWAVEFORMAT defpcmwf =
+{
+{
+1, /* wFormatTag */
+2, /* nChannels */
+11025, /* nSamplesPerSec */
+22050, /* nAvgBytesPerSec */
+2, /* nBlockAlign */
+},
+8, /* wBitsPerSample */
+};
+
+/* Extra data needed to get the VFW API to load the file */
+static DWORD file_header[] =
+{
+FOURCC_RIFF, 0x34c6 /* length */, formtypeAVI,
+FOURCC_LIST, 0x1ac /* length */,
+listtypeAVIHEADER, ckidAVIMAINHDR, sizeof(MainAVIHeader),
+};
+/* MainAVIHeader mah */
+static DWORD streamlist[] =
+{
+FOURCC_LIST, 0xd4 /* length */,
+listtypeSTREAMHEADER, ckidSTREAMHEADER, 0x38 /* length */,
+};
+/* AVIStreamHeader ash0 */
+static DWORD videostreamformat[] =
+{
+ckidSTREAMFORMAT, 0x28 /* length */,
+0x0028, 0x0008, 0x0006
Re: Difficulty fixing a regression in reading text files with MSVCRT
Hi Erich, thanks for that test case. I'm overloaded at the moment, but if you file a bug, I'll try to have a look... - Dan On Mon, Dec 28, 2009 at 5:03 PM, Erich Hoover wrote: > In a surprise last-minute request it became necessary for me to get > Athena Visual Studio running under Wine again > (http://appdb.winehq.org/objectManager.php?sClass=version&iId=15183). > A couple of commits to MSVCRT (that are needed for other reasons) > caused regressions in Wine's ability to run this application and I am > having a lot of difficulty getting Athena working again. The commits > that revealed the problem are: > ebe4a9e321800fbe6d2004a640cd276a28d15c38: Remove CRs earlier in ascii mode. > 7f3c70c52fe470d431a51b3363ed4f7336d5f7f5: Remove CRs earlier in ascii > mode in fseek, too. > > After tracing down a lot of rabbit holes, it appears that the problem > is somehow related to how the buffer boundary influences the file > position reported by ftell. I've attached a test case that appears > related to the issue. I can use a native MSVCRT for now, but I would > appreciate some assistance so that this issue can be properly resolved > at some point. > > Erich Hoover > ehoo...@mines.edu >
Difficulty fixing a regression in reading text files with MSVCRT
In a surprise last-minute request it became necessary for me to get
Athena Visual Studio running under Wine again
(http://appdb.winehq.org/objectManager.php?sClass=version&iId=15183).
A couple of commits to MSVCRT (that are needed for other reasons)
caused regressions in Wine's ability to run this application and I am
having a lot of difficulty getting Athena working again. The commits
that revealed the problem are:
ebe4a9e321800fbe6d2004a640cd276a28d15c38: Remove CRs earlier in ascii mode.
7f3c70c52fe470d431a51b3363ed4f7336d5f7f5: Remove CRs earlier in ascii
mode in fseek, too.
After tracing down a lot of rabbit holes, it appears that the problem
is somehow related to how the buffer boundary influences the file
position reported by ftell. I've attached a test case that appears
related to the issue. I can use a native MSVCRT for now, but I would
appreciate some assistance so that this issue can be properly resolved
at some point.
Erich Hoover
ehoo...@mines.edu
diff --git a/dlls/msvcrt/tests/file.c b/dlls/msvcrt/tests/file.c
index e164555..b4adad7 100644
--- a/dlls/msvcrt/tests/file.c
+++ b/dlls/msvcrt/tests/file.c
@@ -36,8 +36,11 @@
static HANDLE proc_handles[2];
+#define MSVCRT_BUFSIZ 512
+
static void test_filbuf( void )
{
+char test_buffer[MSVCRT_BUFSIZ*2];
FILE *fp;
int c;
fpos_t pos;
@@ -64,6 +67,21 @@ static void test_filbuf( void )
ok(fgetpos(fp, &pos) == 0, "fgetpos fail\n");
ok(pos == -2, "ftell does not match fgetpos\n");
fclose(fp);
+
+memset(test_buffer, ' ', sizeof(test_buffer));
+test_buffer[MSVCRT_BUFSIZ-1] = '\r';
+test_buffer[MSVCRT_BUFSIZ-2] = '\n';
+fp = fopen("filbuf.tst", "wb");
+fwrite(test_buffer, 1, sizeof(test_buffer), fp);
+fclose(fp);
+
+fp = fopen("filbuf.tst", "rt");
+c = _filbuf(fp);
+ok(c == ' ', "read wrong byte\n");
+ok(ftell(fp) == 0, "ascii crlf removal does not match native (pos = %d)\n", ftell(fp));
+ok(fgetpos(fp, &pos) == 0, "fgetpos fail\n");
+ok(pos == 0, "ftell does not match fgetpos (pos = %d)\n", pos);
+fclose(fp);
unlink("filbuf.tst");
}
Re: Building and packaging Wine Gecko
On 12/29/09 1:44 AM, Ove Kaaven wrote: Jacek Caban skrev: I'm not sure what to do about this. Any ideas about something I can do to make it build with gcc 4.2 or 4.4? The only compiler you can use for Wine Gecko 1.0.0 is GCC 3.4.5. Current Git version uses GCC 4.4 SVN version (waiting for the first official GCC release). First official GCC release of what? First official release of GCC from 4.4 branch with the fix included. gcc 4.4.2 is already released, and Debian unstable is using it as the default compiler. And like I mentioned, they even have a mingw32 cross compiler of it. Would it then be a good idea to build wine-gecko git instead of wine-gecko 1.0.0? Should that work? That won't work, but I think it's better to spend time on working on the next release. Jacek
Re: Building and packaging Wine Gecko
Jacek Caban skrev: > It does suffer from this bug, these tests are probably not enough to > show it. Hmm. I had hoped the debian version had patched it or something, especially considering how often stdcall is going to be used by a win32 compiler... >> I'm not sure what to do about this. Any ideas about something I can do >> to make it build with gcc 4.2 or 4.4? > > The only compiler you can use for Wine Gecko 1.0.0 is GCC 3.4.5. Current > Git version uses GCC 4.4 SVN version (waiting for the first official GCC > release). First official GCC release of what? gcc 4.4.2 is already released, and Debian unstable is using it as the default compiler. And like I mentioned, they even have a mingw32 cross compiler of it. Would it then be a good idea to build wine-gecko git instead of wine-gecko 1.0.0? Should that work?
Re: Guide for creating new AppInstall tests
On Mon, Dec 28, 2009 at 4:13 PM, Sam S. wrote: > Hello Wine team! > > After reading the introduction to AppInstall at > http://www.winehq.org/wwn/360, I decided to try and write some > additional application tests for it. > There are at least two freely downloadable win32 apps that I run with > Wine, that have in the past (in my experience) been quite sensitive to > small improvements/regressions in certain areas of wine (gecko engine > and opengl, namely), so having them automatically tested daily could > be useful... > > Unfortunately, however, the wiki page > (http://wiki.winehq.org/Appinstall) doesn't really provide a guide for > how to go about doing this... > It explains the text that will need to be put in the actual test > script (which I could have also figured out by looking at the > well-documented example scripts), but almost nothing about how you > need to set up your working environment, what files to put where, > which commands to call, etc, for the purpose of writing/testing a new > AppInstall script from scratch. I wrote Appinstall, as well as the documentation. While I agree it could be made more useful, it had the usual problem of the developer and users not communicating enough. I sent drafts of the documentation to wine-users and wine-devel, but received few comments on what to change/clarify/add. I'll work on the wiki in a bit, and the documentation on winezeug itself. It would be even better if you could e-mail me off list and point out what needs work. Or rewrite it to be clearer, from a user's perspective ;-). > In absence of such a guide, I just downloaded the whole > http://winezeug.googlecode.com/svn/trunk/appinstall directory, copied > it into a Windows XP environment (because according to the WWN > article, you're supposed to write the tests on Windows), and started > by duplicating one of the example files. > However, when I open a Command Prompt window and try to run one of the > .ahk files with AutoHotKey, nothing really happens - all I see is some > additional Command Prompt windows popping up for a split second and > disappearing again, and then the command returns - nothing downloaded, > no output, no error messages, nothing. (Btw, I don't even understand > where the dowloads specified in the scripts are supposed to end up...) Which script did you run? Most activity is logged to the log file (%APPINSTALL%\testname-result.txt=C:\appinstall\testname-result.txt), not stdout. Those command prompts opening and closing are most likely sha1sum's being calculated for installed files. > How am I supposed to do this? The downloads, as well as log files, go to C:\appinstall, by default. This is explained on the wiki. > More generally: Could someone who knows how to do this maybe put up a > step-by-step guide for users who want to contibute by writing new > AppInstall tests, with no prior knowledge? Possibly something along > the lines of: > > - what/how do download Not sure exactly what you mean here. The wiki explains you need the Appinstaller files, and your program's installer/executable. > - on Windows: what files to put where / how to set up the environment This should be clearer, but most of it is documented either on the wiki/by reading the examples. > - on Windows: how to create a new test-script / where to put it The test script can be anywhere, as long as the two include files are in the same directory. Should be clearer. > - on Windows: how to get all those checksums There's not an easy way on windows, without installing cygwin. This is explained in the wiki. > - on Windows: how to properly test-run/debug the new script By running it a few times and making sure nothing fails ;-). > - on Linux+Wine: what files to put where / how to set up the environment Same as windows. Doesn't matter, as long as yourtest.ahk, init_test and helper_functions are all in the same directory. > - on Linux+Wine: how to test-run the new script previously created on Windows To test it, use: $ wine /path/to/autohotkey.exe yourtest.ahk and examine the log in: $HOME/.wine/drive_c/appinstall/your_test-result.txt > - where to upload/send finished test-scripts to It's in the README on winezeug, but send them to me. If the repository is moved to winehq, the process may change... Most of this is covered/explained, but like I said, the problem is no one reviewed the material, and I wrote Appinstall so I needed little explanation. If someone would volunteer to help with the documentation (by proofing it, making sure I didn't leave steps out, etc.), it would help greatly. E-mail me off list if anyone wants to help with this. -- -Austin
Re: dlls/user32/combo.c: Fix an issue where pressing 's' in a combobox shows the dropdown isntead of finding an entry starting with 's'.
On 12/28/2009 22:18, David Quintana (gigaherz) wrote: Issue was caused by VK_F4 having the same exact code as a lowercase 's'. So the code, which treated WM_CHAR and WM_KEYDOWN as the same, executed the wrong piece of code which was meant to be ONLY for WM_KEYDOWN. Patch is attached. Please resubmit without cpp style comments.
Re: Removing WPARAM/LPARAM Casts
On 12/28/2009 03:06 AM, James Mckenzie wrote: I've noticed that Michael Stefuic (sp?) has removed quite a few WPARAM/LPARAM casts when calling SendMessage() and was wondering/inquiring if he was going do this to riched20/tests/editor.c since I noticed he put in a change for riched20. Michael are you going to do so, or are you going to leave this to others? All but one change in the riched20 patch where for riched20/tests/editor.c. bye michael
Guide for creating new AppInstall tests
Hello Wine team! After reading the introduction to AppInstall at http://www.winehq.org/wwn/360, I decided to try and write some additional application tests for it. There are at least two freely downloadable win32 apps that I run with Wine, that have in the past (in my experience) been quite sensitive to small improvements/regressions in certain areas of wine (gecko engine and opengl, namely), so having them automatically tested daily could be useful... Unfortunately, however, the wiki page (http://wiki.winehq.org/Appinstall) doesn't really provide a guide for how to go about doing this... It explains the text that will need to be put in the actual test script (which I could have also figured out by looking at the well-documented example scripts), but almost nothing about how you need to set up your working environment, what files to put where, which commands to call, etc, for the purpose of writing/testing a new AppInstall script from scratch. In absence of such a guide, I just downloaded the whole http://winezeug.googlecode.com/svn/trunk/appinstall directory, copied it into a Windows XP environment (because according to the WWN article, you're supposed to write the tests on Windows), and started by duplicating one of the example files. However, when I open a Command Prompt window and try to run one of the .ahk files with AutoHotKey, nothing really happens - all I see is some additional Command Prompt windows popping up for a split second and disappearing again, and then the command returns - nothing downloaded, no output, no error messages, nothing. (Btw, I don't even understand where the dowloads specified in the scripts are supposed to end up...) How am I supposed to do this? More generally: Could someone who knows how to do this maybe put up a step-by-step guide for users who want to contibute by writing new AppInstall tests, with no prior knowledge? Possibly something along the lines of: - what/how do download - on Windows: what files to put where / how to set up the environment - on Windows: how to create a new test-script / where to put it - on Windows: how to get all those checksums - on Windows: how to properly test-run/debug the new script - on Linux+Wine: what files to put where / how to set up the environment - on Linux+Wine: how to test-run the new script previously created on Windows - where to upload/send finished test-scripts to Thanks! Sam PS: When will there be a new WWN?
Re: Building and packaging Wine Gecko
On 12/28/09 4:51 PM, Steven Edwards wrote: On Mon, Dec 28, 2009 at 2:34 AM, Ove Kaaven wrote: OK, I've almost got a wine-gecko package built 100% from source, but there's a problem: the gcc version in Debian's mingw32, namely gcc 4.2.1-sjlj, apparently miscompiles the wine-gecko 1.0.0 sources, the resulting Gecko just crashes. (The mingw32 version in oldstable, 3.4.5 something, compiles it correctly, but I can't reasonably build-depend on it, as that version is not even in the current stable.) Would it be possible to build it as a winelib application? Not without a lot of work (it was discussed lately). Jacek
Re: Building and packaging Wine Gecko
On 12/28/09 8:34 AM, Ove Kaaven wrote: OK, I've almost got a wine-gecko package built 100% from source, but there's a problem: the gcc version in Debian's mingw32, namely gcc 4.2.1-sjlj, apparently miscompiles the wine-gecko 1.0.0 sources, the resulting Gecko just crashes. (The mingw32 version in oldstable, 3.4.5 something, compiles it correctly, but I can't reasonably build-depend on it, as that version is not even in the current stable.) (Note that this 4.2.1-sjlj might not suffer from that gcc bug 9381 mentioned on the wiki, as the testcases for it doesn't seem to crash. Or aren't they supposed to crash?) It does suffer from this bug, these tests are probably not enough to show it. I also seem to recall the gcc 4.4-based mingw32 compiler, available in unstable, also refusing to compile those sources at all, due to numerous problems with the headers, such as inconsistently declared calling conventions for methods and stuff. I'm not sure what to do about this. Any ideas about something I can do to make it build with gcc 4.2 or 4.4? The only compiler you can use for Wine Gecko 1.0.0 is GCC 3.4.5. Current Git version uses GCC 4.4 SVN version (waiting for the first official GCC release). All older compilers are not enough unless you'd patch them (but that doesn't sound reasonable). Jacek
Re: [PATCH 3/5] wined3d: Introduce "context_apply_state()" to setup a context for a specific usage.
Am 28.12.2009 um 11:32 schrieb Henri Verbeet: > 2009/12/28 Stefan Dösinger : >> The patch looks ok to me, but out of curiosity: Do you intend to make this >> function available to other wined3d code like context_acquire is, or is the >> main motivation of the patch to tidy up the context_acquire() function? >> > I'll probably kill the "usage" argument to context_acquire() at some > point, yeah. This might be useful in some places, although currently I can only think of the non-fbo-blit swapchain present blit(which could be dealt with in other ways maybe). Keep in mind though that context_apply_state only works properly if the context is current, and that might make it somewhat awkward to use because callers have to acquire the context first.
Re: Remove Macintosh platform
Macintosh is removed. -N Austin English wrote: Done. Sorry about that.
Re: Remove Macintosh platform
Done. Sorry about that. -- -Austin On Mon, Dec 28, 2009 at 9:46 AM, Jeremy Newman wrote: > http://bugs.winehq.org/buglist.cgi?rep_platform=Macintosh > > Still need to change the value on the closed bugs as well before it can be > deleted. > > -N > > Austin English wrote: >> >> I just moved the last macintosh platforms to ppc32/x86, so can someone >> with the appropriate permissions remove that option. >> >> Thanks! >> -Austin
Re: [PATCH 1/3] wininet: Test also InternetCrackUrlW in test_crack_url.
On 12/27/2009 01:27 AM, Jacek Caban wrote: --- dlls/wininet/tests/url.c | 77 ++ 1 files changed, 77 insertions(+), 0 deletions(-) Hi Jacek, Looks like these tests need at least IE7 to succeed. Could you have a look? -- Cheers, Paul.
Re: Acting as advisor for wcmd-uplift project?
On Mon, Dec 28, 2009 at 7:18 AM, Paul Vriens wrote: > I also guess that the error messages will be different on the different OS > versions out there. Yeah, and those pesky copyright laws might prevent us from copying error messages verbatim unless it's required for interoperability. I've updated http://kegel.com/wine/cmd/tests/ to use resources, write only to the windows temp dir, and ignore stderr.
Re: Building and packaging Wine Gecko
On Mon, Dec 28, 2009 at 2:34 AM, Ove Kaaven wrote: > OK, I've almost got a wine-gecko package built 100% from source, but > there's a problem: the gcc version in Debian's mingw32, namely gcc > 4.2.1-sjlj, apparently miscompiles the wine-gecko 1.0.0 sources, the > resulting Gecko just crashes. (The mingw32 version in oldstable, 3.4.5 > something, compiles it correctly, but I can't reasonably build-depend on > it, as that version is not even in the current stable.) Would it be possible to build it as a winelib application? -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Remove Macintosh platform
http://bugs.winehq.org/buglist.cgi?rep_platform=Macintosh Still need to change the value on the closed bugs as well before it can be deleted. -N Austin English wrote: I just moved the last macintosh platforms to ppc32/x86, so can someone with the appropriate permissions remove that option. Thanks! -Austin
Re: Defining missing DirectInput constants
Javier Kohen wrote: > Is it OK to copy constant definitions from Microsoft's SDK? If not, can > somebody help me or give some pointers on how to figure them out? Yes, as long as you type it yourself and don't copy&paste. Vitaliy.
Re: Acting as advisor for wcmd-uplift project?
On 12/28/2009 04:07 PM, Dan Kegel wrote: On Mon, Dec 28, 2009 at 6:57 AM, Alexandre Julliard wrote: You can't test error messages since in general they won't be identical between Wine and Windows. The Wine messages should be written in our own words, unless there is an app that explicitly depends on the exact Windows message. I can have the tests redirect their stderr to nul, and I'll figure out some way to filter out the embedded english in the output of some commands. But this purity is going to cost us. It's extra work. - Dan I also guess that the error messages will be different on the different OS versions out there. -- Cheers, Paul.
Re: Acting as advisor for wcmd-uplift project?
On Mon, Dec 28, 2009 at 6:57 AM, Alexandre Julliard wrote: > You can't test error messages since in general they won't be identical > between Wine and Windows. The Wine messages should be written in our own > words, unless there is an app that explicitly depends on the exact > Windows message. I can have the tests redirect their stderr to nul, and I'll figure out some way to filter out the embedded english in the output of some commands. But this purity is going to cost us. It's extra work. - Dan
Re: Acting as advisor for wcmd-uplift project?
Dan Kegel writes: >> Also, your tests are very risky in terms of non-English locales. I think we >> shouldn't test error messages strings. > > Can we force the locale to a particular value for the tests > with a registry key or something? It'd be pretty hard to write > tests without checking *any* error messages. You can't test error messages since in general they won't be identical between Wine and Windows. The Wine messages should be written in our own words, unless there is an app that explicitly depends on the exact Windows message. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 2/3] wininet: Always set lpszUrlPath in InternetCrackUrlW.
Jacek Caban writes: > --- > dlls/wininet/internet.c | 38 +- > 1 files changed, 13 insertions(+), 25 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so internet.c && touch internet.ok wine: Unhandled page fault on read access to 0x at address 0x68699521 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x in 32-bit code (0x68699521). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:68699521 ESP:0032d180 EBP:0032d1f8 EFLAGS:00010297( R- -- I S -A-P-C) EAX:cbcd24a4 EBX:686b1894 ECX:3432db62 EDX:6865b6c4 ESI: EDI: Stack dump: 0x0032d180: 0x0032d190: 0x0032d1a0: 000c 0x0032d1b0: 6865b6b8 0x0032d1c0: 0006 0x0032d1d0: Backtrace: =>0 0x68699521 InternetCrackUrlW+0x3c1(lpszUrl_orig=0x6865b6b8, dwUrlLength_orig=6, dwFlags=0, lpUC=0x32fb44) [/home/julliard/wine/wine/dlls/wininet/../../include/wine/unicode.h:311] in wininet (0x0032d1f8) 1 0x6869cd2c INTERNET_InternetOpenUrlW+0xec(hIC=0x148d18, lpszUrl=, lpszHeaders=(nil), dwHeadersLength=0, dwFlags=0, dwContext=0) [/home/julliard/wine/wine/dlls/wininet/internet.c:2846] in wininet (0x0032fb98) 2 0x6869d34e InternetOpenUrlW+0x10e(hInternet=0x1, lpszUrl=, lpszHeaders=(nil), dwHeadersLength=0, dwFlags=0, dwContext=0) [/home/julliard/wine/wine/dlls/wininet/internet.c:2990] in wininet (0x0032fbf8) 3 0x6864d4f3 test_null+0x3f3() [/home/julliard/wine/wine/dlls/wininet/tests/internet.c:400] in wininet_test (0x0032fca8) 4 0x6864f71b func_internet+0xbab() [/home/julliard/wine/wine/dlls/wininet/tests/internet.c:850] in wininet_test (0x0032fd98) 5 0x686560c0 run_test+0x130(name="internet.c") [/home/julliard/wine/wine/dlls/wininet/tests/../../../include/wine/test.h:537] in wininet_test (0x0032fdd8) 6 0x686562ae main+0x11e(argc=, argv=) [/home/julliard/wine/wine/dlls/wininet/tests/../../../include/wine/test.h:586] in wininet_test (0x0032fe88) 7 0x68656d34 __wine_spec_exe_entry+0x84(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in wininet_test (0x0032feb8) 8 0x7b8769d5 start_process+0x55(peb=) [/home/julliard/wine/wine/dlls/kernel32/process.c:1038] in kernel32 (0x0032fee8) 9 0x7bc6f9e4 call_thread_func+0xc() in ntdll (0x0032fef8) 10 0x7bc6fbc0 call_thread_entry_point+0x70(entry=0x7b876980, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2391] in ntdll (0x0032ffc8) 11 0x7bc4cd5a in ntdll (+0x3cd5a) (0x0032ffe8) 0x68699521 InternetCrackUrlW+0x3c1 [/home/julliard/wine/wine/dlls/wininet/../../include/wine/unicode.h:311] in wininet: cmpw$10,0x0(%edi) 311 for (end = ptr + n; ptr < end; ptr++) if (*ptr == ch) return (WCHAR *)(ULONG_PTR)ptr; -- Alexandre Julliard julli...@winehq.org
Re: [TRY 2] extrac32: Create directory tree before extraction
Hi, Why this patch don't have been commited? There are mistakes? I really want to make extrac32 better, but I don't know what to do if nobody answer me. -- Best regards, Ilya Shpigor.
Re: [PATCH 3/5] wined3d: Introduce "context_apply_state()" to setup a context for a specific usage.
2009/12/28 Stefan Dösinger : > The patch looks ok to me, but out of curiosity: Do you intend to make this > function available to other wined3d code like context_acquire is, or is the > main motivation of the patch to tidy up the context_acquire() function? > I'll probably kill the "usage" argument to context_acquire() at some point, yeah.
Re: Remove cpp_quote hackery from wined3d.idl
On Thu, 24 Dec 2009, Henri Verbeet wrote:
>> Done thusly. We just need to move WINEMAKEFOURCC to a local header,
>> the rest of the cpp_quote can go and we lose a couple of dozen warning
>> messages (rightfully) issued by GCC 4.5 snapshots.
> I already sent pretty much the same patch,
> http://source.winehq.org/git/wine.git/?a=commitdiff;h=3288911ae3e3cbd7124ed60d805ff3310f6a21c9
Ugh. My experience with Wine always has been that if an expert in some
area like you suggests an approach, I'd be the one expected to implement
that. Thanks for taking care of it this time, though getting a heads up
would have been nice (and would have avoided duplicate efforts).
That said, do you have an idea on how to best tackle the two remaining
cases?
In dlls/wined3d/directx.c we have the following where I wonder whether
you may want to add this to the enum as well?
case WINEMAKEFOURCC('I','N','S','T'):
TRACE("ATI Instancing check hack\n");
if (gl_info->supported[ARB_VERTEX_PROGRAM] ||
gl_info->supported[ARB_VERTEX_SHADER])
{
TRACE_(d3d_caps)("[OK]\n");
return TRUE;
}
TRACE_(d3d_caps)("[FAILED]\n");
return FALSE;
And in dlls/wined3d/utils.c we have TSTYPE_TO_STR(WINED3DTS_WORLDMATRIX(0))
in debug_d3dtstype which also triggers the warning.
Thanks,
Gerald
Re: Remove cpp_quote hackery from wined3d.idl
2009/12/28 Gerald Pfeifer :
> In dlls/wined3d/directx.c we have the following where I wonder whether
> you may want to add this to the enum as well?
>
> case WINEMAKEFOURCC('I','N','S','T'):
> TRACE("ATI Instancing check hack\n");
> if (gl_info->supported[ARB_VERTEX_PROGRAM] ||
> gl_info->supported[ARB_VERTEX_SHADER])
> {
> TRACE_(d3d_caps)("[OK]\n");
> return TRUE;
> }
> TRACE_(d3d_caps)("[FAILED]\n");
> return FALSE;
>
Yeah, just turn that into WINED3DFMT_INST.
> And in dlls/wined3d/utils.c we have TSTYPE_TO_STR(WINED3DTS_WORLDMATRIX(0))
> in debug_d3dtstype which also triggers the warning.
>
You can do something similar with WINED3DTRANSFORMSTATETYPE, and then
replace WINED3DTS_WORLDMATRIX(0) with WINED3DTS_WORLD.
Re: msvcrt: add some demangle features
André Hentschel a écrit : Eric Pouech schrieb: André Hentschel a écrit : - +if (*sym->current == 'A') sym->current++; I don't understand how this would be necessary? Are you sure it's needed ? A+ There is also the possibility "P" for "multidimensional arrays". The "A" actually seems to mean "nothing"(thats the same meaning it has as modifier), as it doesnt modify anything i can see. my point is either we need a modifier here, and your code isn't sufficient or we don't need anything... you should add more test cases (with B, C, D...) instead of A, test it on native msvcrt and see what gives A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
