Re: server: Set the unix file write mode bit also for FILE_APPEND_DATA access.
Dmitry Timoshkov wrote: > diff --git a/server/file.c b/server/file.c > index 2ecf97c..94d3060 100644 > --- a/server/file.c > +++ b/server/file.c > @@ -459,7 +459,7 @@ static mode_t file_access_to_mode( unsigned int access ) > > access = generic_file_map_access( access ); > if (access & FILE_READ_DATA) mode |= 4; > -if (access & FILE_WRITE_DATA) mode |= 2; > +if (access & (FILE_WRITE_DATA|FILE_APPEND_DATA)) mode |= 2; > if (access & FILE_EXECUTE)mode |= 1; > return mode; > } I don't think that this patch should be in 'superseded' state. -- Dmitry.
Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.
Dmitry Timoshkov writes: > The tests show that this is how fully up to date Windows versions starting > from XP behave, isn't that convincing enough? If not, what else do you need > to see? An application that breaks because of this. -- Alexandre Julliard julli...@winehq.org
Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.
Alexandre Julliard wrote: > > Do you propose to leave NtWriteFile/NtReadFile in the state when they > > return STATUS_SUCCESS for overlapped writes and reads? But that's clearly > > not how Windows implements this accordingto the tests, and that would > > require changing all the tests to accept both values so that they pass > > under Wine. > > Well, the tests fail mostly because you have decided that this behavior > is broken. I'm not convinced. The tests show that this is how fully up to date Windows versions starting from XP behave, isn't that convincing enough? If not, what else do you need to see? -- Dmitry.
Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.
Dmitry Timoshkov writes: > Do you propose to leave NtWriteFile/NtReadFile in the state when they > return STATUS_SUCCESS for overlapped writes and reads? But that's clearly > not how Windows implements this accordingto the tests, and that would > require changing all the tests to accept both values so that they pass > under Wine. Well, the tests fail mostly because you have decided that this behavior is broken. I'm not convinced. -- Alexandre Julliard julli...@winehq.org
Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.
Alexandre Julliard wrote: > >> I don't see the point. Do you actually have an app that depends on this? > > > > When I started to work on this I had an app that has one of the reasons to > > require running under Vista+ was the difference in overlapped IO behavior. > > On the other hand the tests clearly show that up-to-date Windows versions > > (including Windows XP) always return STATUS_PENDING for asynchronous read > > and write on disk files. Is there another way to remove all those todo_wine > > statements from the tests? > > The tests also show that returning success is allowed for other file > types, so I don't see a need to add complexity to treat files > differently, unless there's a demonstrated need. Do you propose to leave NtWriteFile/NtReadFile in the state when they return STATUS_SUCCESS for overlapped writes and reads? But that's clearly not how Windows implements this accordingto the tests, and that would require changing all the tests to accept both values so that they pass under Wine. -- Dmitry.
Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.
Dmitry Timoshkov writes: > Alexandre Julliard wrote: > >> I don't see the point. Do you actually have an app that depends on this? > > When I started to work on this I had an app that has one of the reasons to > require running under Vista+ was the difference in overlapped IO behavior. > On the other hand the tests clearly show that up-to-date Windows versions > (including Windows XP) always return STATUS_PENDING for asynchronous read > and write on disk files. Is there another way to remove all those todo_wine > statements from the tests? The tests also show that returning success is allowed for other file types, so I don't see a need to add complexity to treat files differently, unless there's a demonstrated need. -- Alexandre Julliard julli...@winehq.org
Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.
Alexandre Julliard wrote: > I don't see the point. Do you actually have an app that depends on this? When I started to work on this I had an app that has one of the reasons to require running under Vista+ was the difference in overlapped IO behavior. On the other hand the tests clearly show that up-to-date Windows versions (including Windows XP) always return STATUS_PENDING for asynchronous read and write on disk files. Is there another way to remove all those todo_wine statements from the tests? -- Dmitry.
Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.
Dmitry Timoshkov writes: > --- > dlls/ntdll/file.c | 3 ++- > dlls/ntdll/tests/file.c | 5 +++-- > 2 files changed, 5 insertions(+), 3 deletions(-) I don't see the point. Do you actually have an app that depends on this? -- Alexandre Julliard julli...@winehq.org
Re: kernel32/tests: Add DuplicateHandle test to the file access tests.
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 https://newtestbot.winehq.org/JobDetails.pl?Key=2345 Your paranoid android. === build (build) === Patch failed to apply
Re: [2/2] shlwapi: Write file access also assumes read access.
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 https://newtestbot.winehq.org/JobDetails.pl?Key=2215 Your paranoid android. === build (build) === Patch failed to apply
Re: [1/4] ntdll/tests: Add 0-length read tests for a disk file.
Nikolay Sivov wrote: > > --- a/dlls/ntdll/tests/file.c > > +++ b/dlls/ntdll/tests/file.c > > @@ -1985,6 +1985,22 @@ static void test_read_write(void) > > > > bytes = 0xdeadbeef; > > SetLastError(0xdeadbeef); > > +ret = ReadFile(INVALID_HANDLE_VALUE, buf, 0,&bytes, NULL); > > +todo_wine > > +ok(!ret, "ReadFile should fail\n"); > > +todo_wine > > +ok(GetLastError() == ERROR_INVALID_HANDLE, "expected > > ERROR_INVALID_HANDLE, got %d\n", GetLastError()); > > + ok(bytes == 0, "bytes %u\n", bytes); > > > That's again a test for kernel32 calls, placed in a wrong file. Please actually look at the tests before commenting. -- Dmitry.
Re: [1/4] ntdll/tests: Add 0-length read tests for a disk file.
On 09/18/2013 10:53 AM, Dmitry Timoshkov wrote: --- dlls/ntdll/tests/file.c | 41 + 1 file changed, 41 insertions(+) diff --git a/dlls/ntdll/tests/file.c b/dlls/ntdll/tests/file.c index 120fdac..5ae605b 100644 --- a/dlls/ntdll/tests/file.c +++ b/dlls/ntdll/tests/file.c @@ -1985,6 +1985,22 @@ static void test_read_write(void) bytes = 0xdeadbeef; SetLastError(0xdeadbeef); +ret = ReadFile(INVALID_HANDLE_VALUE, buf, 0,&bytes, NULL); +todo_wine +ok(!ret, "ReadFile should fail\n"); +todo_wine +ok(GetLastError() == ERROR_INVALID_HANDLE, "expected ERROR_INVALID_HANDLE, got %d\n", GetLastError()); +ok(bytes == 0, "bytes %u\n", bytes); That's again a test for kernel32 calls, placed in a wrong file.
Re: ntdll: Add a file access test.
Dmitry Timoshkov writes: > Nikolay Sivov wrote: > >> >> It looks like it belongs to kernel32/tests. >> > Since actual access checks are done by ntdll APIs I believe that >> > ntdll/tests >> > is appropriate place, kernel32 file APIs are just wrappers around the >> > tested >> > functionality. >> > >> It doesn't matter what it uses internally. You're testing kernel32 calls. > > What are you trying to prove? Half of the calls in that file are using > kernel32 APIs, that doesn't mean that they need to be moved to kernel32 > or that they are doing something wrong. Using kernel32 APIs in order to test the ntdll ones is fine. But a test that only calls kernel32 has no reason to be in ntdll. -- Alexandre Julliard julli...@winehq.org
Re: ntdll: Add a file access test.
Nikolay Sivov wrote: > >> It looks like it belongs to kernel32/tests. > > Since actual access checks are done by ntdll APIs I believe that ntdll/tests > > is appropriate place, kernel32 file APIs are just wrappers around the tested > > functionality. > > > It doesn't matter what it uses internally. You're testing kernel32 calls. What are you trying to prove? Half of the calls in that file are using kernel32 APIs, that doesn't mean that they need to be moved to kernel32 or that they are doing something wrong. -- Dmitry.
Re: ntdll: Add a file access test.
On 9/13/2013 12:16, Dmitry Timoshkov wrote: Nikolay Sivov wrote: It looks like it belongs to kernel32/tests. Since actual access checks are done by ntdll APIs I believe that ntdll/tests is appropriate place, kernel32 file APIs are just wrappers around the tested functionality. It doesn't matter what it uses internally. You're testing kernel32 calls.
Re: ntdll: Add a file access test.
Nikolay Sivov wrote: > It looks like it belongs to kernel32/tests. Since actual access checks are done by ntdll APIs I believe that ntdll/tests is appropriate place, kernel32 file APIs are just wrappers around the tested functionality. -- Dmitry.
Re: ntdll: Add a file access test.
On 9/13/2013 11:20, Dmitry Timoshkov wrote: This test passes under Wine and shows that ReadFile after CreateFile(GENERIC_WRITE) is really supposed to fail. --- dlls/ntdll/tests/file.c | 82 + 1 file changed, 82 insertions(+) It looks like it belongs to kernel32/tests.
Re: Sort the AUTHORS file by their last names.
Hentschel said: you would need to fix the generation and wanted to change the order of the AUTHORS file. The message you posted in Mon, Sep 2, 2013 at 3:24 PM has a text file (AUTHORS) containing all authors sorted alphabetically by their last names. -- Tae Wong
Re: Sort the AUTHORS file by their last names.
Am 02.09.2013 08:24, schrieb Tae Wong: > Add more authors from the GIT log. > > Commit this patch. > > > It seems you have some need to change the order of the AUTHORS file, but it's autogenerated, so you would need to fix the generation. And Michael already pointed out that this non-trivial problem can't be automated. If you simply want to get into wine development, you really should pick something else to start with. PS: It also seems it's not clear to you what a patch is, so you might want to read http://wiki.winehq.org/SubmittingPatches
Re: Sort the AUTHORS file by their last names.
Non-Dutch names like Van Buggenhaut can be placed under V instead. -- Tae Wong
Re: Sort the AUTHORS file by their last names.
Non-Dutch names starting with a last name of van can be placed under v and d can be placed under d. -- Tae Wong
Re: Sort the AUTHORS file by their last names.
This is clearly going nowhere.
Re: Sort the AUTHORS file by their last names.
Particles "van" and "de" can be parts of last name for non-Dutch persons. On 8/17/13, Michael Stefaniuc wrote: > On 08/16/2013 09:33 PM, Tae Wong wrote: >> You have to manually update it by adding all authors from the GIT log. >> >> The attachment is here at first message. > That one you did is not correct either: > - I see some Spanish "double" last names sorted by the 2nd one instead > of the first. > - In Dutch the "van" is not part of last name so you cannot sort those > under "V" > > I'm sure there is more of that in other languages. Like I said this is > not a trivial problem. And not a problem that can be automated thus not > sustainable long term. There's a reason git opts to sort the text lines. > > bye > michael > -- Tae Wong
Re: Sort the AUTHORS file by their last names.
On 08/16/2013 09:33 PM, Tae Wong wrote: > You have to manually update it by adding all authors from the GIT log. > > The attachment is here at first message. That one you did is not correct either: - I see some Spanish "double" last names sorted by the 2nd one instead of the first. - In Dutch the "van" is not part of last name so you cannot sort those under "V" I'm sure there is more of that in other languages. Like I said this is not a trivial problem. And not a problem that can be automated thus not sustainable long term. There's a reason git opts to sort the text lines. bye michael
Re: Sort the AUTHORS file by their last names.
You have to manually update it by adding all authors from the GIT log. The attachment is here at first message. -- Tae Wong
Re: Sort the AUTHORS file by their last names.
On Fri, Aug 16, 2013 at 6:51 PM, Tae Wong wrote: > Older revisions sort them by last name instead of text line. > > Your file contains all of the names sorted on last name. > > The current revision contains all names sorted in first name, not last name. The old revisions were updated manually. The current revision is updated automatically from git "committer information" (e.g. 'user.name' config variable , and most people happen to set it to "firstname family_name" -- Frédéric Delanoy
Re: Sort the AUTHORS file by their last names.
Older revisions sort them by last name instead of text line. Your file contains all of the names sorted on last name. The current revision contains all names sorted in first name, not last name. -- Tae Wong
Re: Sort the AUTHORS file by their last names.
On 08/16/2013 05:40 PM, Tae Wong wrote: > In the GIT tree, the AUTHORS file is sorted on first names. Wrong. It is sorted by the text line. The first word on the line can be the first or lastname, depending what the author used. bye michael
Re: Sort the AUTHORS file by their last names.
In the GIT tree, the AUTHORS file is sorted on first names. -- Tae Wong
Re: Sort the AUTHORS file by their last names.
On 08/16/2013 04:42 PM, Tae Wong wrote: > Julliard said that it should feel free to provide a script that sorts > by last name. > > You want to do this. Careful. It is a trap. He is fine with it if it is done *right*. Figuring out what the last name is is a hard problem. bye michael
Re: Sort the AUTHORS file by their last names.
Julliard said that it should feel free to provide a script that sorts by last name. You want to do this. -- Tae Wong
Re: Sort the AUTHORS file by their last names.
Tae Wong writes: > Wow! It is sorted on the first names, not on the last names... > > You want to apply the patch. When you sort developers in alphabetical > order, you must choose first names or last names. It's autogenerated, so it's simply sorted textually. Feel free to provide a script that sorts by last name. -- Alexandre Julliard julli...@winehq.org
Re: Sort the AUTHORS file by their last names.
Wow! It is sorted on the first names, not on the last names... You want to apply the patch. When you sort developers in alphabetical order, you must choose first names or last names. You want to sort it by last names. This patch contains several names with particles (de Saedeleer, Van Assche...) sorted in the last names by case-insensitive. -- Tae Wong
Re: Sort the AUTHORS file by their last names.
On 16/08/13 14:46, Tae Wong wrote:> The AUTHORS file have all developers from the GIT log which were > sorted on their first names. > > This patch will switch the sort order from first to last names. This isn't how the AUTHORS file is generated. http://source.winehq.org/git/wine.git/commit/5da31c8817293ff98b4defceb962f7d0fbc25829
Re: ntdll/tests: test FileDispositionInformation file class
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=26661 Your paranoid android. === WXPX64 (32 bit file) === file.c:1318: Test failed: Unexpected NtQueryInformationFile result (expected STATUS_INVALID_INFO_CLASS, got c002) === WVISTAX64 (32 bit file) === file.c:1318: Test failed: Unexpected NtQueryInformationFile result (expected STATUS_INVALID_INFO_CLASS, got c002) === W7PROX64 (32 bit file) === file.c:1318: Test failed: Unexpected NtQueryInformationFile result (expected STATUS_INVALID_INFO_CLASS, got c002) === TEST64_W7SP1 (32 bit file) === file.c:1318: Test failed: Unexpected NtQueryInformationFile result (expected STATUS_INVALID_INFO_CLASS, got c002)
Re: ntdll: NtAllocateVirtualMemory should fail to commit if an address range is already committed for a memory mapped file.
Alexandre Julliard wrote: > > This patch fixes the problem reported in the bug 2770, hopefully it's still > > acceptable during code freeze. > > Is there an application that's fixed by this? According to bug 2770, > that app only crashes a little further on (which is of course an > improvement, but not worth the risk during code freeze). Including the patch in 1.6 is certainly up to you, I don't have an actual application that depends on this. -- Dmitry.
Re: ntdll: NtAllocateVirtualMemory should fail to commit if an address range is already committed for a memory mapped file.
Dmitry Timoshkov writes: > This patch fixes the problem reported in the bug 2770, hopefully it's still > acceptable during code freeze. Is there an application that's fixed by this? According to bug 2770, that app only crashes a little further on (which is of course an improvement, but not worth the risk during code freeze). -- Alexandre Julliard julli...@winehq.org
Re: [PATCH] [cmd, try2] move filename . deletes file
On Thu, Jun 13, 2013 at 12:23 PM, Alexandre Julliard wrote: > > Jason Edmeades writes: > > > move is not tollerent of the source and destination being the same > > and happily removes the destination (after prompting) ready to > > move the file, only to appear shocked that the file is no longer > > there... > > > > This was sent originally where I compared filenames, and was given > > feedback to use a better system of equality. This now uses something > > the MSDN implies is the best way to tell for equivalent destinations > > This should be done in MoveFile, and cmd should use that instead of > duplicating the checks. Then I think bug 14901 may be related. http://bugs.winehq.org/show_bug.cgi?id=14901 > -- > Alexandre Julliard > julli...@winehq.org Best wishes, Bruno
Re: [PATCH] [cmd, try2] move filename . deletes file
Jason Edmeades writes: > move is not tollerent of the source and destination being the same > and happily removes the destination (after prompting) ready to > move the file, only to appear shocked that the file is no longer > there... > > This was sent originally where I compared filenames, and was given > feedback to use a better system of equality. This now uses something > the MSDN implies is the best way to tell for equivalent destinations This should be done in MoveFile, and cmd should use that instead of duplicating the checks. -- Alexandre Julliard julli...@winehq.org
Adding names to the authors file.
The only Croatian person is Marko Nikolić, but with no accented letter. Could you also add Joško Nikolić (the Croatian translator) and Volkan Gezer (the Turkish translator) to the authors file as well? The file name (in all capitals) is AUTHORS. It is very great so that you have to accentuate Marko's name at the message. But you use "straight quotes" or “smart quotes”. And Van Schaik's name is credited under the surname (and not on the particle). Here is the sort that you want for the section: va. South African and Namibian names in Dutch should have been sorted on the prefix (particle), but not in the surname. Vainer, Moshe Valoska, Hleb Valtonen, Hannu Vance, Carroll Vanek, Tomas van Schaik, Carl (Note that this is on a letter by letter sort.) Vaughn, Charles
Names with particles on South Africa and Namibia should be in the particle on the AUTHORS file.
You have posted a message to show how surnames with particles of South Africa and Namibia show in the credits, like van Schayck listed in S and not under V: For example, van Schayck is under S and not in V. Note that the name of the file is in all capitals. Here is a correction of the va section, with van Schyack placed on the letter by letter system. The file name is AUTHORS. It is a file in all capitals and the file content contains just the heading and some names of the developers. Note that the file is out of date. Vainer, Moshe Valoska, Hleb Valtonen, Hannu Vance, Carroll Vanek, Tomas van Schaik, Carl Vaughn, Charles
Re: [PATCH 1/3] d3dx9_36: Add support for DIB file in D3DXGetImageInfoFromFileInMemory. (try 2)
2013/4/23 Rico Schüller
> On 22.04.2013 23:08, Christian Costa wrote:
>
>> +typedef struct {
>> +DWORD bc2Size;
>> +DWORD bc2Width;
>> +DWORD bc2Height;
>> +WORD bc2Planes;
>> +WORD bc2BitCount;
>> +DWORD bc2Compression;
>> +DWORD bc2SizeImage;
>> +DWORD bc2XRes;
>> +DWORD bc2YRes;
>> +DWORD bc2ClrUsed;
>> +DWORD bc2ClrImportant;
>> +/* same as BITMAPINFOHEADER until this point */
>> +WORD bc2ResUnit;
>> +WORD bc2Reserved;
>> +WORD bc2Orientation;
>> +WORD bc2Halftoning;
>> +DWORD bc2HalftoneSize1;
>> +DWORD bc2HalftoneSize2;
>> +DWORD bc2ColorSpace;
>> +DWORD bc2AppData;
>> +} BITMAPCOREHEADER2;
>>
>
> Do we really need a typedef here? For only locally used structs, I think
> we shouldn't use a typedef. Also the struct is only used to determine the
> size and for nothing else? There may be a better way to do that... Maybe
> something like in dlls/windowscodecs/icoformat.c ?
>
> I think you got inspired by dlls/windowscodecs/bmpdecode.**c, there is
> the same issue. Why do we need a typedef, if we only use it in one file to
> calculate the size?
>
This is correct. Indeed using header_size == 64 /*
sizeof(BITMAPCOREHEADER2) */ would be better.
>
>
>> +BITMAPFILEHEADER *header;
>>
>>
>> +if ((header_size == sizeof(BITMAPINFOHEADER)) ||
>> +(header_size == sizeof(BITMAPV4HEADER)) ||
>> +(header_size == sizeof(BITMAPV5HEADER)) ||
>> +(header_size == sizeof(BITMAPCOREHEADER2)))
>> +{
>> +/* All structures have the same memory layout as
>> BITMAPINFOHEADER */
>> +BITMAPINFOHEADER*header = (BITMAPINFOHEADER*)*data;
>>
>> +ULONG count = header->biClrUsed;
>>
>> +else if (header_size == sizeof(BITMAPCOREHEADER))
>> +{
>> +BITMAPCOREHEADER*header = (BITMAPCOREHEADER*)*data;
>>
>
> I don't think it's a good idea to use variable names multiple times. While
> this works fine it may be a bit confusing...
>
>
I don't find it confusing but I don't mind changing it.
Re: [PATCH 1/3] d3dx9_36: Add support for DIB file in D3DXGetImageInfoFromFileInMemory. (try 2)
On 22.04.2013 23:08, Christian Costa wrote:
+typedef struct {
+DWORD bc2Size;
+DWORD bc2Width;
+DWORD bc2Height;
+WORD bc2Planes;
+WORD bc2BitCount;
+DWORD bc2Compression;
+DWORD bc2SizeImage;
+DWORD bc2XRes;
+DWORD bc2YRes;
+DWORD bc2ClrUsed;
+DWORD bc2ClrImportant;
+/* same as BITMAPINFOHEADER until this point */
+WORD bc2ResUnit;
+WORD bc2Reserved;
+WORD bc2Orientation;
+WORD bc2Halftoning;
+DWORD bc2HalftoneSize1;
+DWORD bc2HalftoneSize2;
+DWORD bc2ColorSpace;
+DWORD bc2AppData;
+} BITMAPCOREHEADER2;
Do we really need a typedef here? For only locally used structs, I think
we shouldn't use a typedef. Also the struct is only used to determine
the size and for nothing else? There may be a better way to do that...
Maybe something like in dlls/windowscodecs/icoformat.c ?
I think you got inspired by dlls/windowscodecs/bmpdecode.c, there is the
same issue. Why do we need a typedef, if we only use it in one file to
calculate the size?
+BITMAPFILEHEADER *header;
+if ((header_size == sizeof(BITMAPINFOHEADER)) ||
+(header_size == sizeof(BITMAPV4HEADER)) ||
+(header_size == sizeof(BITMAPV5HEADER)) ||
+(header_size == sizeof(BITMAPCOREHEADER2)))
+{
+/* All structures have the same memory layout as BITMAPINFOHEADER */
+BITMAPINFOHEADER*header = (BITMAPINFOHEADER*)*data;
+ULONG count = header->biClrUsed;
+else if (header_size == sizeof(BITMAPCOREHEADER))
+{
+BITMAPCOREHEADER*header = (BITMAPCOREHEADER*)*data;
I don't think it's a good idea to use variable names multiple times.
While this works fine it may be a bit confusing...
Cheers
Rico
Re: [PATCH 1/3] d3dx9_36: Add support for DIB file in D3DXGetImageInfoFromFileInMemory.
Wich DIB types ? Are you referring to BI_BITFIELDS compression ?
I just looked at windows codecs code and there this code to handle color
masks:
/* if this is a BITMAPINFOHEADER with BI_BITFIELDS compression, we need
to
read the extra fields */
if (This->bih.bV5Size == sizeof(BITMAPINFOHEADER) &&
This->bih.bV5Compression == BI_BITFIELDS)
{
This->palette_offset += 12;
}
For the rest it's the same thing:
/* In a packed DIB, the image follows the palette. */
ULONG palette_count, palette_size;
if (This->bih.bV5ClrUsed)
palette_count = This->bih.bV5ClrUsed;
else if (This->bih.bV5BitCount <= 8)
palette_count = 1 << This->bih.bV5BitCount;
else
palette_count = 0;
if (This->bih.bV5Size == sizeof(BITMAPCOREHEADER))
palette_size = sizeof(RGBTRIPLE) * palette_count;
else
palette_size = sizeof(RGBQUAD) * palette_count;
This->image_offset = This->palette_offset + palette_size;
Albeit windows codecs support also BITMAPCOREHEADER2, BITMAPV4HEADER,
BITMAPV5HEADER the same way as BITMAPINFOHEADER.
Is there still anything wrong ?
Christian
2013/4/22 Alexandre Julliard
> Christian Costa writes:
>
> > +if (header_size == sizeof(BITMAPINFOHEADER))
> > +{
> > +BITMAPINFOHEADER *header = (BITMAPINFOHEADER*)*data;
> > +ULONG count = header->biClrUsed;
> > +
> > +if (!count && header->biBitCount <= 8)
> > +count = 1 << header->biBitCount;
> > +
> > +offset = sizeof(BITMAPFILEHEADER) + header_size +
> sizeof(RGBQUAD) * count;
>
> This isn't correct for all DIB types.
>
> --
> Alexandre Julliard
> julli...@winehq.org
>
Re: [PATCH 1/3] d3dx9_36: Add support for DIB file in D3DXGetImageInfoFromFileInMemory.
Christian Costa writes:
> +if (header_size == sizeof(BITMAPINFOHEADER))
> +{
> +BITMAPINFOHEADER *header = (BITMAPINFOHEADER*)*data;
> +ULONG count = header->biClrUsed;
> +
> +if (!count && header->biBitCount <= 8)
> +count = 1 << header->biBitCount;
> +
> +offset = sizeof(BITMAPFILEHEADER) + header_size + sizeof(RGBQUAD) *
> count;
This isn't correct for all DIB types.
--
Alexandre Julliard
julli...@winehq.org
Re: spec file and -arch
Am 05.03.2013 22:57, schrieb Stefan Leichter: > Hi, > > when i look into msvcr100.spec file i find lots of different parameters for > the > switch (?) -arch . So fare i have seen: arm, i386, win32, win64 and x86_64 . > > To me it is not clear what is the difference between win64 and x86_64. The > same > for i386 and win32. What are is the criteria to choose the first or the > second? > If it makes a difference do i have to distinguish between arm and ... ? win32 includes all 32-bit platforms win64 includes all 64-bit platforms if is implemented in x86 assembler win32 would not be the best choice. i suggest you should use make_specfiles in tools/ > Does -i386 and -arch=i386 mean the same? yes -- Best Regards, André Hentschel
spec file and -arch
Hi, when i look into msvcr100.spec file i find lots of different parameters for the switch (?) -arch . So fare i have seen: arm, i386, win32, win64 and x86_64 . To me it is not clear what is the difference between win64 and x86_64. The same for i386 and win32. What are is the criteria to choose the first or the second? If it makes a difference do i have to distinguish between arm and ... ? Does -i386 and -arch=i386 mean the same? Thank you for enlightening me Stefan
Fix name order in the authors file.
You’ve found Kazuyuki Sato in inverted name order. Apostrophes on the O-section are not ignored. O'Callahan, Robert O'Neill, Damien O'Regan, Mike Oberhumer, Stefan Oberndorfer, Peter Ogburn, Walt Ognyanoff, Damyan Olsen, Henrik Olsen, Magnus Olson, Roger Olver, Neil Ortiz, Jose Manuel Ferrer Osmundsen, Knut St. It should be ignored so the section should be sorted as: Oberhumer, Stefan Oberndorfer, Peter O'Callahan, Robert Ogburn, Walt Ognyanoff, Damyan Olsen, Henrik Olsen, Magnus Olson, Roger Olver, Neil O'Neill, Damien O'Regan, Mike Ortiz, Jose Manuel Ferrer Osmundsen, Knut St.
Re: [PATCH] ieframe/tests: Don't convert to long path name until the file exists
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=24128 Your paranoid android. === WNT4WSSP6 (32 bit webbrowser) === Timeout === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2607: Test failed: expected GetOverridesKeyPath webbrowser.c:2612: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2613: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:3046: Test failed: doc_disp == NULL webbrowser: unhandled exception c005 at 00402F21
Re: [PATCH (try3)] ieframe: Strip 'file://' from file URLs in BEFORENAVIGATE2 callbacks
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=23822 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [1/2] windowscodecs: Add a test for loading a .bmp file with BITMAPINFOHEADER.
Series looks fine to me. And yes, testbot has been broken for a while now..
Re: [PATCH (try2)] ieframe: Strip 'file://' from file URLs in BEFORENAVIGATE2 callbacks
Hi Andrew,
On 01/09/13 16:56, Andrew Eikum wrote:
> ---
>
> This should fix the Office 2007 half of Bug 17271.
>
> try2: Fix test failures on XP by expanding the expected path name.
>
> dlls/ieframe/navigate.c | 7 +-
> dlls/ieframe/tests/webbrowser.c | 56
> ++---
> 2 files changed, 59 insertions(+), 4 deletions(-)
>
>
> 0001-ieframe-Strip-file-from-file-URLs-in-BEFORENAVIGATE2.patch
>
>
> diff --git a/dlls/ieframe/navigate.c b/dlls/ieframe/navigate.c
> index dd4a976..2601ba8 100644
> --- a/dlls/ieframe/navigate.c
> +++ b/dlls/ieframe/navigate.c
> @@ -566,6 +566,8 @@ static void on_before_navigate2(DocHost *This, LPCWSTR
> url, SAFEARRAY *post_data
> VARIANT var_url, var_flags, var_frame_name, var_post_data,
> var_post_data2, var_headers;
> DISPPARAMS dispparams;
> VARIANTARG params[7];
> +WCHAR file_path[MAX_PATH];
> +DWORD file_path_len = sizeof(file_path) / sizeof(*file_path);
>
> dispparams.cArgs = 7;
> dispparams.cNamedArgs = 0;
> @@ -607,7 +609,10 @@ static void on_before_navigate2(DocHost *This, LPCWSTR
> url, SAFEARRAY *post_data
> V_VT(params+5) = (VT_BYREF|VT_VARIANT);
> V_VARIANTREF(params+5) = &var_url;
> V_VT(&var_url) = VT_BSTR;
> -V_BSTR(&var_url) = SysAllocString(url);
> +if(PathCreateFromUrlW(url, file_path, &file_path_len, 0) == S_OK)
> +V_BSTR(&var_url) = SysAllocString(file_path);
> +else
> +V_BSTR(&var_url) = SysAllocString(url);
>
> V_VT(params+6) = (VT_DISPATCH);
> V_DISPATCH(params+6) = (IDispatch*)This->wb;
> diff --git a/dlls/ieframe/tests/webbrowser.c b/dlls/ieframe/tests/webbrowser.c
> index 25cce8a..70c785b 100644
> --- a/dlls/ieframe/tests/webbrowser.c
> +++ b/dlls/ieframe/tests/webbrowser.c
> @@ -151,7 +151,7 @@ static VARIANT_BOOL exvb;
> static IWebBrowser2 *wb;
>
> static HWND container_hwnd, shell_embedding_hwnd;
> -static BOOL is_downloading, is_first_load, use_container_olecmd, test_close,
> is_http, use_container_dochostui;
> +static BOOL is_downloading, is_first_load, use_container_olecmd, test_close,
> is_http, is_file, use_container_dochostui;
> static HRESULT hr_dochost_TranslateAccelerator = E_NOTIMPL;
> static HRESULT hr_site_TranslateAccelerator = E_NOTIMPL;
> static const char *current_url;
> @@ -690,8 +690,14 @@ static void test_OnBeforeNavigate(const VARIANT *disp,
> const VARIANT *url, const
> ok(V_VT(V_VARIANTREF(url)) == VT_BSTR, "V_VT(V_VARIANTREF(url))=%d,
> expected VT_BSTR\n",
> V_VT(V_VARIANTREF(url)));
> ok(V_BSTR(V_VARIANTREF(url)) != NULL, "V_BSTR(V_VARIANTREF(url)) ==
> NULL\n");
> -ok(!strcmp_wa(V_BSTR(V_VARIANTREF(url)), current_url), "unexpected
> url %s, expected %s\n",
> - wine_dbgstr_w(V_BSTR(V_VARIANTREF(url))), current_url);
> +if(is_file){
> +char full_path[MAX_PATH];
> +GetLongPathNameA(current_url, full_path, sizeof(full_path));
I think expanding the path would be better done while constructing the URL
instead of here.
+test_DoVerb(webbrowser);
+test_Navigate2(webbrowser, file_url);
+
+IWebBrowser2_Release(webbrowser);
This is not enough for proper clean up. You may verify that by checking ref
count here. At least setting client site to NULL is needed.
Cheers,
Jacek
Re: [PATCH (try2)] ieframe: Strip 'file://' from file URLs in BEFORENAVIGATE2 callbacks
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=23818 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [PATCH] ieframe: Strip 'file://' from file URLs in BEFORENAVIGATE2 callbacks
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=23816 Your paranoid android. === WNT4WSSP6 (32 bit webbrowser) === webbrowser.c:3320: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3320: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3320: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3461: Test failed: Creating WebBrowser object failed: 80040154 webbrowser: unhandled exception c005 at 0040816F === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2607: Test failed: expected GetOverridesKeyPath webbrowser.c:2612: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2613: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:3046: Test failed: doc_disp == NULL webbrowser: unhandled exception c005 at 00402F21 === WXPPROSP3 (32 bit webbrowser) === webbrowser.c:693: Test failed: unexpected url L"C:\\Documents and Settings\\winetest\\Local Settings\\Temp\\wine_test.html", expected C:\DOCUME~1\winetest\LOCALS~1\Temp\wine_test.html === W2K3R2SESP2 (32 bit webbrowser) === webbrowser.c:693: Test failed: unexpected url L"C:\\Documents and Settings\\winetest\\Local Settings\\Temp\\wine_test.html", expected C:\DOCUME~1\winetest\LOCALS~1\Temp\wine_test.html
Re: [1/2] windowscodecs: Add a test for loading a .bmp file with BITMAPINFOHEADER.
Marvin wrote: > === WINEBUILD (build) === > Patch failed to apply Looks like testbot is broken. -- Dmitry.
Re: [1/2] windowscodecs: Add a test for loading a .bmp file with BITMAPINFOHEADER.
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=23802 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [PATCH 4/6] server: Store and return security attributes with extended file attributes (try 5).
03.12.2012 23:13, Erich E. Hoover kirjoitti: > On Sun, Dec 2, 2012 at 5:28 PM, Anssi Hannula wrote: >> ... >> I don't see the need for an uppercase "WINEACL" in the attribute name, >> especially since all the examples in e.g. attr(5) are lowercase. >> Moreover, [1] recommends using application specific namespaces in the >> attribute name, so IMHO a better attribute name would be "user.wine.acl". >> ... > > I copied the form of "user.DOSATTRIB" that I saw from posts about > Samba. If you think it makes more sense to call it "user.wine.acl" > then I can certainly do that. I do, at least. (of course, I'm just a random non-wine dev) -- Anssi Hannula
Re: [PATCH 4/6] server: Store and return security attributes with extended file attributes (try 5).
On Sun, Dec 2, 2012 at 5:28 PM, Anssi Hannula wrote: > ... > I don't see the need for an uppercase "WINEACL" in the attribute name, > especially since all the examples in e.g. attr(5) are lowercase. > Moreover, [1] recommends using application specific namespaces in the > attribute name, so IMHO a better attribute name would be "user.wine.acl". > ... I copied the form of "user.DOSATTRIB" that I saw from posts about Samba. If you think it makes more sense to call it "user.wine.acl" then I can certainly do that. Erich
Re: [PATCH 4/6] server: Store and return security attributes with extended file attributes (try 5).
Hi, 27.11.2012 00:45, Erich E. Hoover kirjoitti: > This patch adds the ability to store and retrieve the security > attributes of a file by turning them into extended file attributes (if > available). These attributes are stored in the attribute > "user.WINEACL" in the form: > ;;...; > where each ACE takes the form: > ,,, > With this information it is possible to more accurately store the ACL > information files, and also allows patch 5 to tell whether it's > necessary for an ACL to be inherited by a contained file in a folder. I don't see the need for an uppercase "WINEACL" in the attribute name, especially since all the examples in e.g. attr(5) are lowercase. Moreover, [1] recommends using application specific namespaces in the attribute name, so IMHO a better attribute name would be "user.wine.acl". Thanks for your work on this :) [1] http://www.freedesktop.org/wiki/CommonExtendedAttributes -- Anssi Hannula
Re: [PATCH 2/2] winmm: Fix handling of mmio file buffers.
Akihiro Sagawa writes: > This fix bug 19566 and 32013. > --- > dlls/winmm/mmio.c | 31 +-- > dlls/winmm/tests/mmio.c | 16 > 2 files changed, 21 insertions(+), 26 deletions(-) It doesn't work on 64-bit: ../../../../wine/tools/runtest -q -P wine -M avifil32.dll -T ../../.. -p avifil32_test.exe.so ../../../../wine/dlls/avifil32/tests/api.c && touch api.ok wine: Unhandled page fault on read access to 0x0004 at address 0x2b088aa9b1cb (thread 0022), starting debugger... Unhandled exception: page fault on read access to 0x0004 in 64-bit code (0x2b088aa9b1cb). Register dump: rip:2b088aa9b1cb rsp:0022ef58 rbp: eflags:00010216 ( R- -- I -A-P- ) rax:00340270 rbx:0003c100 rcx:0d04 rdx:45455246 rsi:0004 rdi:00341a50 r8:45455246 r9: r10:00340030 r11:8000 r12:45455246 r13:457954b6 r14:45455246 r15:0003bfe0 Stack dump: 0x0022ef58: 2b088c7d1cfb 0x0022ef68: 0001 0005 0x0022ef78: 2b088c7d19bd 5b5b5b5b5b5b5b5b 0x0022ef88: 5b5b5b5b5b5b5b5b 2020202020202020 0x0022ef98: 2020202020202020 00202020 0x0022efa8: 0x0022efb8: 00202020 0x0022efc8: 2000 00ff 0x0022efd8: ff00ff00 0x0022efe8: 0x0022eff8: 0x0022f008: Backtrace: =>0 0x2b088aa9b1cb in libc.so.6 (+0x881cb) (0x) 1 0x2b088c7d1cfb mmioRead+0x11a(hmmio=0x1, pch="", cch=) [/home/julliard/wine/build/obj-elf64/dlls/winmm/../../../wine/dlls/winmm/mmio.c:779] in winmm (0x) 2 0x2b088c35d774 ReadChunkIntoExtra+0xf3(extra=, hmmio=0x1, lpck=0x22f1f0) [/home/julliard/wine/build/obj-elf64/dlls/avifil32/../../../wine/dlls/avifil32/extrachunk.c:134] in avifil32 (0x) 3 0x2b088c35d8ce FindChunkAndKeepExtras+0xcd(extra=0x3bfe0, hmmio=0x1, lpck=0x22f1f0, lpckParent=0x22f190, flags=0x10) [/home/julliard/wine/build/obj-elf64/dlls/avifil32/../../../wine/dlls/avifil32/extrachunk.c:197] in avifil32 (0x0001) 4 0x2b088c356037 IPersistFile_fnLoad+0xee6(iface=, pszFileName=, dwMode=) [/home/julliard/wine/build/obj-elf64/dlls/avifil32/../../../wine/dlls/avifil32/avifile.c:1871] in avifil32 (0x0003bfe0) 5 0x2b088c34a597 AVIFileOpenW+0x156(ppfile=0x22f6c8, szFile="C:\users\julliard\Temp\wine_avifil32_test.avi", uMode=0x20, lpHandler=) [/home/julliard/wine/build/obj-elf64/dlls/avifil32/../../include/objidl.h:5274] in avifil32 (0x0022f6c8) 6 0x2b088c34a942 AVIFileOpenA+0x131(ppfile=0x22f6c8, szFile="C:\users\julliard\Temp\wine_avifil32_test.avi", uMode=0x20, lpHandler=(nil)) [/home/julliard/wine/build/obj-elf64/dlls/avifil32/../../../wine/dlls/avifil32/api.c:218] in avifil32 (0x) 7 0x2b088c12ea01 test_default_data+0xd0() [/home/julliard/wine/build/obj-elf64/dlls/avifil32/tests/../../../../wine/dlls/avifil32/tests/api.c:374] in avifil32_test (0x) 8 0x2b088c12fd2e func_api+0x29d() [/home/julliard/wine/build/obj-elf64/dlls/avifil32/tests/../../../../wine/dlls/avifil32/tests/api.c:552] in avifil32_test (0x) 9 0x2b088c130055 run_test+0x114(name=) [/home/julliard/wine/build/obj-elf64/dlls/avifil32/tests/../../../../wine/include/wine/test.h:557] in avifil32_test (0x2b088c3320e0) 10 0x2b088c12d101 main+0x110(argc=, argv=) [/home/julliard/wine/build/obj-elf64/dlls/avifil32/tests/../../../../wine/include/wine/test.h:627] in avifil32_test (0x2b088ad94d90) 11 0x2b088c130ae2 __wine_spec_exe_entry+0xa1(peb=) [/home/julliard/wine/build/obj-elf64/dlls/winecrt0/../../../wine/dlls/winecrt0/exe_entry.c:36] in avifil32_test (0x2b088a7c78f0) 12 0x7b874171 start_process+0xb0(peb=0x7fbef000) [/home/julliard/wine/build/obj-elf64/dlls/kernel32/../../../wine/dlls/kernel32/process.c:1052] in kernel32 (0x2b088c130a40) 13 0x2b088b02d9ae call_thread_func+0x6d(entry=0x7b8740c0, arg=0x7fbef000, frame=) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/signal_x86_64.c:3230] in ntdll (0x7fff7d40bed0) 14 0x2b088b02709a call_thread_entry_point+0x29() in ntdll (0x7fff7d40bed0) 15 0x2b088aff8a66 start_process+0x15(kernel_start=) [/home/julliard/wine/build/obj-elf64/dlls/ntdll/../../../wine/dlls/ntdll/loader.c:2653] in ntdll (0x7fff7d40bed0) 16 0x2b088a4a1283 wine_call_on_stack+0x12() in libwine.so.1 (0x7fff7d40bed0) 17 0x2b088a4a12d9 wine_switch_to_stack+0x8(func=, arg=, stack=) [/home/julliard/wine/build
Re: [PATCH 5/7] server: Store and return security attributes with extended file attributes (try 2).
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=22726 Your paranoid android. === W2KPROSP4 (32 bit security) === security.c:4417: Test failed: Current User ACE has unexpected flags (0x1f01ff != 0x03) security.c:4428: Test failed: Administators Group ACE has unexpected flags (0x1000 != 0x03) === WXPPROSP3 (32 bit security) === security.c:4417: Test failed: Current User ACE has unexpected flags (0x1f01ff != 0x03) security.c:4428: Test failed: Administators Group ACE has unexpected flags (0x1f01ff != 0x03) === W2K3R2SESP2 (32 bit security) === security.c:4417: Test failed: Current User ACE has unexpected flags (0x1f01ff != 0x03) security.c:4428: Test failed: Administators Group ACE has unexpected flags (0x1f01ff != 0x03) === WVISTAADM (32 bit security) === security.c:4417: Test failed: Current User ACE has unexpected flags (0x1f01ff != 0x03) security.c:4428: Test failed: Administators Group ACE has unexpected flags (0x1f01ff != 0x03) === W2K8SE (32 bit security) === security.c:4417: Test failed: Current User ACE has unexpected flags (0x1f01ff != 0x03) security.c:4428: Test failed: Administators Group ACE has unexpected flags (0x1f01ff != 0x03) === W7PRO (32 bit security) === security.c:4417: Test failed: Current User ACE has unexpected flags (0x1f01ff != 0x03) security.c:4428: Test failed: Administators Group ACE has unexpected flags (0x1f01ff != 0x03) === W7PROX64 (32 bit security) === security.c:4417: Test failed: Current User ACE has unexpected flags (0x1f01ff != 0x03) security.c:4428: Test failed: Administators Group ACE has unexpected flags (0x1f01ff != 0x03) === TEST64_W7SP1 (32 bit security) === security.c:4417: Test failed: Current User ACE has unexpected flags (0x1f01ff != 0x03) security.c:4428: Test failed: Administators Group ACE has unexpected flags (0x1f01ff != 0x03) === W7PROX64 (64 bit security) === security.c:4417: Test failed: Current User ACE has unexpected flags (0x1f01ff != 0x03) security.c:4428: Test failed: Administators Group ACE has unexpected flags (0x1f01ff != 0x03) === TEST64_W7SP1 (64 bit security) === security.c:4417: Test failed: Current User ACE has unexpected flags (0x1f01ff != 0x03) security.c:4428: Test failed: Administators Group ACE has unexpected flags (0x1f01ff != 0x03)
Re: [PATCH 5/7] server: Store and return security attributes with extended file attributes.
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=22707 Your paranoid android. === WNT4WSSP6 (32 bit directory) === Timeout
Re: [PATCH 5/7] server: Store and return security attributes with extended file attributes.
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=22706 Your paranoid android. === WNT4WSSP6 (32 bit security) === Timeout === W2KPROSP4 (32 bit security) === security.c:4411: Test failed: GetAclInformation returned unexpected entry count (5 != 2). security.c:4429: Test failed: Administators Group ACE != Administators Group SID. security.c:4432: Test failed: Administators Group ACE has unexpected mask (0x1000 != 0x1f01ff) === WXPPROSP3 (32 bit security) === security.c:4411: Test failed: GetAclInformation returned unexpected entry count (6 != 2). === W2K3R2SESP2 (32 bit security) === security.c:4411: Test failed: GetAclInformation returned unexpected entry count (5 != 2). === WVISTAADM (32 bit security) === security.c:4411: Test failed: GetAclInformation returned unexpected entry count (6 != 2). === W2K8SE (32 bit security) === security.c:4411: Test failed: GetAclInformation returned unexpected entry count (5 != 2). === W7PRO (32 bit security) === security.c:4411: Test failed: GetAclInformation returned unexpected entry count (6 != 2). === W7PROX64 (32 bit security) === security.c:4411: Test failed: GetAclInformation returned unexpected entry count (6 != 2). === TEST64_W7SP1 (32 bit security) === security.c:4411: Test failed: GetAclInformation returned unexpected entry count (6 != 2). === W7PROX64 (64 bit security) === security.c:4411: Test failed: GetAclInformation returned unexpected entry count (6 != 2). === TEST64_W7SP1 (64 bit security) === security.c:4411: Test failed: GetAclInformation returned unexpected entry count (6 != 2).
Re: [PATCH 1/3] ntdll: Implement nanosecond precision file time storage (try 2).
"Erich E. Hoover" writes:
> @@ -2048,17 +2048,26 @@ NTSTATUS WINAPI NtSetInformationFile(HANDLE handle,
> PIO_STATUS_BLOCK io,
>
> if (info->LastAccessTime.QuadPart ||
> info->LastWriteTime.QuadPart)
> {
> +#ifdef HAVE_FUTIMENS
> +struct timespec tv[2];
> +#else
> struct timeval tv[2];
> +#endif
> +int ret;
>
> if (!info->LastAccessTime.QuadPart ||
> !info->LastWriteTime.QuadPart)
> {
> -
> -tv[0].tv_sec = tv[0].tv_usec = 0;
> -tv[1].tv_sec = tv[1].tv_usec = 0;
> +memset(&tv, 0x0, sizeof(tv));
> if (!fstat( fd, &st ))
> {
> tv[0].tv_sec = st.st_atime;
> tv[1].tv_sec = st.st_mtime;
> +#if defined(HAVE_FUTIMENS) && defined(HAVE_STRUCT_STAT_ST_ATIM)
> +tv[0].tv_nsec = st.st_atim.tv_nsec;
> +#endif
> +#if defined(HAVE_FUTIMENS) && defined(HAVE_STRUCT_STAT_ST_MTIM)
> +tv[1].tv_nsec = st.st_mtim.tv_nsec;
> +#endif
You want UTIME_OMIT. Also please try to cut down on the number of
#ifdefs.
--
Alexandre Julliard
julli...@winehq.org
Re: [PATCH 1/3] ntdll: Implement nanosecond precision file time storage.
"Erich E. Hoover" writes: > This series of patches provides a fix for Bug #31858 (Netflix Internet > Connection Problem). With this particular patch the POSIX.1-2008 > futimens() function is used to replace the BSD futimes() function, > allowing for nanosecond precision of recorded file times. This would need a configure check. -- Alexandre Julliard julli...@winehq.org
Re: testbot/lib: If we cannot open the log file, then log to stderr.
2012/10/16 Francois Gouget > On Mon, 15 Oct 2012, Christian Costa wrote: > [...] > > >> Why not if I can make it run the test after the extraction. > > >> That said why not improving test bot download extra files? Is there a > > >> specific reason for that? > > > I'm not against improving the testbot, it was just a suggestion. > > > > > It's a good one.I will file a bug in bugzilla for the test bot and try > > your suggestion. > > Do you know any simple tool that enables to do that? > > If the sfx approach can be made to work without changes to WineTestBot > then it may be worth documenting somewhere on the Wiki. > > Otherwise I'd rather modify WineestBot to accept .zip files in addition > to .exe ones. This would cause the zip file to be extracted in a > temporary directory, maybe not allowing subdirectories, and the one .exe > file it contains would be run. I think that process would be more > intuitive. > > If we need to allow more than one exe, letting the user specify the > command to run should resolve any ambiguities. > > > That would be perfect!
Re: testbot/lib: If we cannot open the log file, then log to stderr.
Christian Costa wrote: > >> Indeed that would be great to be able to download some files along with the > >> test. > >> Typically for me avi files and dlls (or .drv) would be great ! :D > > Just do what other tests do: embed all the required data into the test: > > be it a PE executable, TIFF/GIF/PNG/etc image, or even a RIFF/AVI file. > > That way the tests don't depend on any external files, or abilities in > > the tested environment to download them. > > > It seems a bit complicated for a test I will run only once and not > intended to be part of the test suite. Another approach is how gdi32/tests/font.c embeds wine_test.ttf font file using RCDATA resource. That just adds a simple extraction helper and is pretty trivial and universal for any kind of data file. -- Dmitry.
Re: testbot/lib: If we cannot open the log file, then log to stderr.
On Mon, 15 Oct 2012, Christian Costa wrote: [...] > >> Why not if I can make it run the test after the extraction. > >> That said why not improving test bot download extra files? Is there a > >> specific reason for that? > > I'm not against improving the testbot, it was just a suggestion. > > > It's a good one.I will file a bug in bugzilla for the test bot and try > your suggestion. > Do you know any simple tool that enables to do that? If the sfx approach can be made to work without changes to WineTestBot then it may be worth documenting somewhere on the Wiki. Otherwise I'd rather modify WineestBot to accept .zip files in addition to .exe ones. This would cause the zip file to be extracted in a temporary directory, maybe not allowing subdirectories, and the one .exe file it contains would be run. I think that process would be more intuitive. If we need to allow more than one exe, letting the user specify the command to run should resolve any ambiguities. -- Francois Gouget
Re: testbot/lib: If we cannot open the log file, then log to stderr.
On Mon, Oct 15, 2012 at 12:45 PM, Christian Costa wrote: > Le 15/10/2012 21:29, Austin English a écrit : > >> On Mon, Oct 15, 2012 at 12:28 PM, Christian Costa >> wrote: >>> >>> Le 15/10/2012 21:16, Austin English a écrit : >>> >>>> On Mon, Oct 15, 2012 at 12:14 PM, Christian Costa >>>> >>>> wrote: >>>>> >>>>> Le 15/10/2012 18:07, Dmitry Timoshkov a écrit : >>>>> >>>>>> Christian Costa wrote: >>>>>> >>>>>>> Indeed that would be great to be able to download some files along >>>>>>> with >>>>>>> the >>>>>>> test. >>>>>>> Typically for me avi files and dlls (or .drv) would be great ! :D >>>>>> >>>>>> Just do what other tests do: embed all the required data into the >>>>>> test: >>>>>> be it a PE executable, TIFF/GIF/PNG/etc image, or even a RIFF/AVI >>>>>> file. >>>>>> That way the tests don't depend on any external files, or abilities in >>>>>> the tested environment to download them. >>>>>> >>>>> It seems a bit complicated for a test I will run only once and not >>>>> intended >>>>> to be part of the test suite. >>>> >>>> You could use a self extracting exe. >>>> >>> Why not if I can make it run the test after the extraction. >>> That said why not improving test bot download extra files? Is there a >>> specific reason for that? >> >> I'm not against improving the testbot, it was just a suggestion. >> > It's a good one.I will file a bug in bugzilla for the test bot and try your > suggestion. > Do you know any simple tool that enables to do that? 7-zip, look into its -sfx option. -- -Austin
Re: testbot/lib: If we cannot open the log file, then log to stderr.
Le 15/10/2012 21:29, Austin English a écrit : On Mon, Oct 15, 2012 at 12:28 PM, Christian Costa wrote: Le 15/10/2012 21:16, Austin English a écrit : On Mon, Oct 15, 2012 at 12:14 PM, Christian Costa wrote: Le 15/10/2012 18:07, Dmitry Timoshkov a écrit : Christian Costa wrote: Indeed that would be great to be able to download some files along with the test. Typically for me avi files and dlls (or .drv) would be great ! :D Just do what other tests do: embed all the required data into the test: be it a PE executable, TIFF/GIF/PNG/etc image, or even a RIFF/AVI file. That way the tests don't depend on any external files, or abilities in the tested environment to download them. It seems a bit complicated for a test I will run only once and not intended to be part of the test suite. You could use a self extracting exe. Why not if I can make it run the test after the extraction. That said why not improving test bot download extra files? Is there a specific reason for that? I'm not against improving the testbot, it was just a suggestion. It's a good one.I will file a bug in bugzilla for the test bot and try your suggestion. Do you know any simple tool that enables to do that?
Re: testbot/lib: If we cannot open the log file, then log to stderr.
On Mon, Oct 15, 2012 at 12:28 PM, Christian Costa wrote: > Le 15/10/2012 21:16, Austin English a écrit : > >> On Mon, Oct 15, 2012 at 12:14 PM, Christian Costa >> wrote: >>> >>> Le 15/10/2012 18:07, Dmitry Timoshkov a écrit : >>> >>>> Christian Costa wrote: >>>> >>>>> Indeed that would be great to be able to download some files along with >>>>> the >>>>> test. >>>>> Typically for me avi files and dlls (or .drv) would be great ! :D >>>> >>>> Just do what other tests do: embed all the required data into the test: >>>> be it a PE executable, TIFF/GIF/PNG/etc image, or even a RIFF/AVI file. >>>> That way the tests don't depend on any external files, or abilities in >>>> the tested environment to download them. >>>> >>> It seems a bit complicated for a test I will run only once and not >>> intended >>> to be part of the test suite. >> >> You could use a self extracting exe. >> > Why not if I can make it run the test after the extraction. > That said why not improving test bot download extra files? Is there a > specific reason for that? I'm not against improving the testbot, it was just a suggestion. -- -Austin
Re: testbot/lib: If we cannot open the log file, then log to stderr.
Le 15/10/2012 21:16, Austin English a écrit : On Mon, Oct 15, 2012 at 12:14 PM, Christian Costa wrote: Le 15/10/2012 18:07, Dmitry Timoshkov a écrit : Christian Costa wrote: Indeed that would be great to be able to download some files along with the test. Typically for me avi files and dlls (or .drv) would be great ! :D Just do what other tests do: embed all the required data into the test: be it a PE executable, TIFF/GIF/PNG/etc image, or even a RIFF/AVI file. That way the tests don't depend on any external files, or abilities in the tested environment to download them. It seems a bit complicated for a test I will run only once and not intended to be part of the test suite. You could use a self extracting exe. Why not if I can make it run the test after the extraction. That said why not improving test bot download extra files? Is there a specific reason for that?
Re: testbot/lib: If we cannot open the log file, then log to stderr.
On Mon, Oct 15, 2012 at 12:14 PM, Christian Costa wrote: > Le 15/10/2012 18:07, Dmitry Timoshkov a écrit : > >> Christian Costa wrote: >> >>> Indeed that would be great to be able to download some files along with >>> the >>> test. >>> Typically for me avi files and dlls (or .drv) would be great ! :D >> >> Just do what other tests do: embed all the required data into the test: >> be it a PE executable, TIFF/GIF/PNG/etc image, or even a RIFF/AVI file. >> That way the tests don't depend on any external files, or abilities in >> the tested environment to download them. >> > It seems a bit complicated for a test I will run only once and not intended > to be part of the test suite. You could use a self extracting exe. -- -Austin
Re: testbot/lib: If we cannot open the log file, then log to stderr.
Le 15/10/2012 18:07, Dmitry Timoshkov a écrit : Christian Costa wrote: Indeed that would be great to be able to download some files along with the test. Typically for me avi files and dlls (or .drv) would be great ! :D Just do what other tests do: embed all the required data into the test: be it a PE executable, TIFF/GIF/PNG/etc image, or even a RIFF/AVI file. That way the tests don't depend on any external files, or abilities in the tested environment to download them. It seems a bit complicated for a test I will run only once and not intended to be part of the test suite.
Re: testbot/lib: If we cannot open the log file, then log to stderr.
Christian Costa wrote: > Indeed that would be great to be able to download some files along with the > test. > Typically for me avi files and dlls (or .drv) would be great ! :D Just do what other tests do: embed all the required data into the test: be it a PE executable, TIFF/GIF/PNG/etc image, or even a RIFF/AVI file. That way the tests don't depend on any external files, or abilities in the tested environment to download them. -- Dmitry.
Re: testbot/lib: If we cannot open the log file, then log to stderr.
Hi François,
While your are at it. I would like to do a suggestion.
Indeed that would be great to be able to download some files along with the
test.
Typically for me avi files and dlls (or .drv) would be great ! :D
Thanks
Christian,
2012/10/15 Francois Gouget
> ---
> testbot/lib/WineTestBot/Log.pm | 16 +++-
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/testbot/lib/WineTestBot/Log.pm
> b/testbot/lib/WineTestBot/Log.pm
> index 6883968..7de6dcb 100644
> --- a/testbot/lib/WineTestBot/Log.pm
> +++ b/testbot/lib/WineTestBot/Log.pm
> @@ -38,20 +38,18 @@ sub LogMsg(@)
>if (!defined $logfile)
>{
> my $oldumask = umask(002);
> -if (open($logfile, ">>", "$LogDir/log"))
> -{
> - # Flush after each print
> - my $tmp=select($logfile);
> - $| = 1;
> - select($tmp);
> -}
> -else
> +if (!open($logfile, ">>", "$LogDir/log"))
> {
>require File::Basename;
>print STDERR File::Basename::basename($0), ":warning: could not
> open '$LogDir/log' for writing: $!\n";
> - $logfile = undef;
> + open($logfile, ">>&=", 2);
> }
> umask($oldumask);
> +
> +# Flush after each print
> +my $tmp=select($logfile);
> +$| = 1;
> +select($tmp);
>}
>print $logfile scalar localtime, " ", @_ if ($logfile);
> }
> --
> 1.7.10.4
>
>
>
>
Re: [1/3] cmd/tests: Show name of current test file on standard output
Frédéric Delanoy writes: > When there are several test files, indicates which file error line numbers > relate to, making > "debugging" easier. That's what trace() is for. -- Alexandre Julliard julli...@winehq.org
Re: shell32: Fix ShellExecute()'s handling of file URLs.
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=22079 Your paranoid android. === WNT4WSSP6 (32 bit shlexec) === shlexec.c:1440: Test failed: ShellExecuteEx(mask="0x200", verb="Params23456", file="C:\TEMP\wt1.tmp\test file.shlexec", params="p2 "p3" "p4 is lost"): the cmdline is ' "p2" "p3" "p3" "" ""' instead of ' "p2" "p3" "" "" ""' === W2KPROSP4 (32 bit shlexec) === shlexec.c:1440: Test failed: ShellExecuteEx(mask="0x200", verb="Params23456", file="C:\DOCUME~1\winetest\LOCALS~1\Temp\wt1.tmp\test file.shlexec", params="p2 "p3" "p4 is lost"): the cmdline is ' "p2" "p3" "p3" "" ""' instead of ' "p2" "p3" "" "" ""'
Re: [2/4] winemaker: Generate def file from spec file with winebuild (try 2)
André Hentschel writes:
> @@ -2569,6 +2570,7 @@ sub generate_project_files($)
> print FILEO "\$(${canon}_MODULE).so: \$(${canon}_OBJS)
> \$(${canon}_MODULE:.dll=.def)\n";
>} elsif (@$target[$T_TYPE] == $TT_DLL) {
> print FILEO "\$(${canon}_MODULE).so: \$(${canon}_OBJS)
> \$(${canon}_MODULE:.dll=.spec)\n";
> +print FILEO "\t\$(WINEBUILD) --def -E \$(${canon}_MODULE:.dll=.spec)
> -o lib\$(${canon}_MODULE:.dll=.def)\n";
That's not much better. You should have a proper target for it, and a
dependency from the modules that import that dll.
--
Alexandre Julliard
julli...@winehq.org
Re: [3/3] winemaker: Generate def file from spec file with winebuild
André Hentschel writes:
> @@ -2576,7 +2577,9 @@ sub generate_project_files($)
>if (@$target[$T_TYPE] == $TT_DLL && (@$project_settings[$T_FLAGS] &
> $TF_HASDEF)) {
> print FILEO "\$(${canon}_MODULE).so: \$(${canon}_OBJS)
> \$(${canon}_MODULE:.dll=.def)\n";
>} elsif (@$target[$T_TYPE] == $TT_DLL) {
> -print FILEO "\$(${canon}_MODULE).so: \$(${canon}_OBJS)
> \$(${canon}_MODULE:.dll=.spec)\n";
> +print FILEO "lib\$(${canon}_MODULE:.dll=.def):
> \$(${canon}_MODULE:.dll=.spec)\n";
> +print FILEO "\t\$(WINEBUILD) --def -E \$(${canon}_MODULE:.dll=.spec)
> -o lib\$(${canon}_MODULE:.dll=.def)\n\n";
> +print FILEO "\$(${canon}_MODULE).so: \$(${canon}_OBJS)
> \$(${canon}_MODULE:.dll=.spec) lib\$(${canon}_MODULE:.dll=.def)\n";
The .so doesn't depend on the .def.
--
Alexandre Julliard
julli...@winehq.org
Re: [5/6] start: Support getting the file to open by AppleEvent. (resend)
On Tue, Sep 25, 2012 at 10:57 AM, Francois Gouget wrote: > On Tue, 25 Sep 2012, Per Johansson wrote: > > > Hi, > > > > I should probably add a note that when I wrote this I had some doubts it > it > > belongs in start.exe, and I still somewhat do. > > > > The alternative would be to write a new program. The advantage to that > is: > > Start.exe already has a /unix option so adding a /AppleEvent one may > make sense. > > I have two questions though (I apologize if careful reading the patch > would answer them). > > How would this new /AppleEvent option be used? > It will be used in file type association scripts created by winemenubuilder (patch 6/6). You won't invoke it manually since it only makes sense if there's an AppleEvent waiting to be delivered. The AppleEvent is sent to an application by OS X when you open a document. Is AppleEvent how they call DDE on Mac OS X? > Pretty much, details differ but it serves the same function. AppleEvents have existed since 1991 and are pretty much unchanged since then at the API level. Mac OS prefers a single instance of each application and the events are therefore sent by the OS instead of a new instance of the application. This patch only checks for an event at launch, but since it usually immediately exits it's then ready to relaunch and check for another event. Regards, -- Per Johansson
Re: [5/6] start: Support getting the file to open by AppleEvent. (resend)
On Tue, 25 Sep 2012, Per Johansson wrote: > Hi, > > I should probably add a note that when I wrote this I had some doubts it it > belongs in start.exe, and I still somewhat do. > > The alternative would be to write a new program. The advantage to that is: Start.exe already has a /unix option so adding a /AppleEvent one may make sense. I have two questions though (I apologize if careful reading the patch would answer them). How would this new /AppleEvent option be used? Is AppleEvent how they call DDE on Mac OS X? -- Francois Gouget http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.
Re: [5/6] start: Support getting the file to open by AppleEvent. (resend)
Hi, I should probably add a note that when I wrote this I had some doubts it it belongs in start.exe, and I still somewhat do. The alternative would be to write a new program. The advantage to that is: 1. start.exe is left more similar to it's windows counterpart. 2. This other program could handle multiple files sent in the same AppleEvent, which is possible. 3. The same program could also act as a proxy for a dock icon, handling clicks and activating windows (this is a later project). I'd imagine it'd be called winehostproxy or somesuch and handle several types of interaction with the host (is that what we call it btw?). If you think that's more appropriate I can work on that instead of adding this to start. Regards, -- Per Johansson 2012/9/23 Per Johansson > 0006-start-Support-getting-the-file-to-open-by-AppleEvent.patch Description: Binary data
Re: shell32: Add tests for ShellExecute()'s handling of file URLs. (try2)
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=21655 Your paranoid android. === WNT4WSSP6 (32 bit shlexec) === Timeout === W2KPROSP4 (32 bit shlexec) === shlexec.c:1380: Test failed: ShellExecute(null, "file:/C|/Documents and Settings/winetest/Local Settings/Temp/wt1.tmp/nonexistent.shlexec", null, null) failed: rc=2 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file:/C|/Documents and Settings/winetest/Local Settings/Temp/wt1.tmp/test file.shlexec", null, null) failed: rc=5 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file://localhost:80/C|/Documents and Settings/winetest/Local Settings/Temp/wt1.tmp/test file.shlexec", null, null) failed: rc=5 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file://127.0.0.1/C|/Documents and Settings/winetest/Local Settings/Temp/wt1.tmp/test file.shlexec", null, null) failed: rc=5 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file://::1/C|/Documents and Settings/winetest/Local Settings/Temp/wt1.tmp/test file.shlexec", null, null) failed: rc=5 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file://notahost/C|/Documents and Settings/winetest/Local Settings/Temp/wt1.tmp/test file.shlexec", null, null) failed: rc=5 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file://www.winehq.org/C|/Documents and Settings/winetest/Local Settings/Temp/wt1.tmp/test file.shlexec", null, null) failed: rc=5 err=2 === WVISTAADM (32 bit shlexec) === shlexec.c:1380: Test failed: ShellExecute(null, "file:/C|/Users/winetest/AppData/Local/Temp/wt9C72.tmp/nonexistent.shlexec", null, null) failed: rc=2 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file:/C|/Users/winetest/AppData/Local/Temp/wt9C72.tmp/test file.shlexec", null, null) failed: rc=2 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file://localhost:80/C|/Users/winetest/AppData/Local/Temp/wt9C72.tmp/test file.shlexec", null, null) failed: rc=2 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file://127.0.0.1/C|/Users/winetest/AppData/Local/Temp/wt9C72.tmp/test file.shlexec", null, null) failed: rc=2 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file://::1/C|/Users/winetest/AppData/Local/Temp/wt9C72.tmp/test file.shlexec", null, null) failed: rc=2 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file://notahost/C|/Users/winetest/AppData/Local/Temp/wt9C72.tmp/test file.shlexec", null, null) failed: rc=2 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file://www.winehq.org/C|/Users/winetest/AppData/Local/Temp/wt9C72.tmp/test file.shlexec", null, null) failed: rc=2 err=2 === W2K8SE (32 bit shlexec) === shlexec.c:1380: Test failed: ShellExecute(null, "file:/C|/Users/winetest/AppData/Local/Temp/wt370A.tmp/nonexistent.shlexec", null, null) failed: rc=2 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file:/C|/Users/winetest/AppData/Local/Temp/wt370A.tmp/test file.shlexec", null, null) failed: rc=2 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file://localhost:80/C|/Users/winetest/AppData/Local/Temp/wt370A.tmp/test file.shlexec", null, null) failed: rc=2 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file://127.0.0.1/C|/Users/winetest/AppData/Local/Temp/wt370A.tmp/test file.shlexec", null, null) failed: rc=2 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file://::1/C|/Users/winetest/AppData/Local/Temp/wt370A.tmp/test file.shlexec", null, null) failed: rc=2 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file://notahost/C|/Users/winetest/AppData/Local/Temp/wt370A.tmp/test file.shlexec", null, null) failed: rc=2 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file://www.winehq.org/C|/Users/winetest/AppData/Local/Temp/wt370A.tmp/test file.shlexec", null, null) failed: rc=2 err=2 === W7PRO (32 bit shlexec) === shlexec.c:1380: Test failed: ShellExecute(null, "file:/C|/Users/winetest/AppData/Local/Temp/wtE079.tmp/nonexistent.shlexec", null, null) failed: rc=2 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file:/C|/Users/winetest/AppData/Local/Temp/wtE079.tmp/test file.shlexec", null, null) failed: rc=2 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file://localhost:80/C|/Users/winetest/AppData/Local/Temp/wtE079.tmp/test file.shlexec", null, null) failed: rc=2 err=2 shlexec.c:1380: Test failed: ShellExecute(null, "file://127.0.0.1/C|/Users/winetest/AppData/Local/Temp/wtE079.tmp/test file.shlexec", null, null) failed: rc=2 err=2 shlexec.c:1380: Test failed: ShellExec
Re: [7/8] winemenubuilder: Use a dispatch table to access XDG specific parts, extracted to different file.
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=21662 Your paranoid android. === WINEBUILD (build) === Make failed
Re: shell32: Add tests for ShellExecute()'s handling of file URLs.
Hi Francois, pretty sure you didn't mean to leave this hunk in: @@ -2296,9 +2406,13 @@ START_TEST(shlexec) init_test(); +#if 0 test_argify(); test_lpFile_parsed(); test_filename(); +#endif +test_fileurl(); +#if 0 test_find_executable(); test_lnks(); test_exes(); @@ -2308,6 +2422,7 @@ START_TEST(shlexec) test_commandline(); test_directory(); test_trojans(); +#endif --Juan
Re: shell32: Add tests for ShellExecute()'s handling of file URLs.
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=21649 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: shell32: Make ShellExecute use native file association databases as fallback path (resend)
Erik van Pienbroek writes:
> +#if defined(HAVE_FORK) && defined(HAVE_WAITPID)
> +static UINT_PTR SHELL_try_native_execute ( const char *openCmd, const char
> *unixName )
> +{
> +UINT_PTR retval = SE_ERR_NOASSOC;
> +pid_t cpid;
> +struct stat st;
> +
> +if (stat(openCmd, &st) == -1)
> +{
> +TRACE("stat() %s failed: %s\n", openCmd, strerror(errno));
> +return retval;
> +}
> +
> +cpid = fork();
> +if (!cpid)
> +{
> +/* Prevent the situation where the native file association database
> + * tries to run wine to execute a program and we trigger this
> fallback
> + * path again and end up in a recursive loop */
> +if (getenv("WINE_INSIDE_SHELLEXECUTE"))
> +{
> +TRACE("recursive loop detected, not continuing with ShellExecute
> call\n");
> +exit(EXIT_SUCCESS);
> +}
> +setenv("WINE_INSIDE_SHELLEXECUTE", "1", 0);
> +
> +TRACE("running %s %s\n", openCmd, unixName);
> +execlp(openCmd, openCmd, unixName, (char*) NULL);
> +/* execlp replaces the current process image with a new process
> image,
> + * so no code below here should get executed by the forked child */
> +} else {
> +int status;
> +waitpid(cpid, &status, 0);
> +TRACE("status %x\n", status);
> +if(!WEXITSTATUS(status))
> +retval = 33;
> +}
> +
> +return retval;
> +}
You want spawnvp(), but that sort of thing should probably go in
winebrowser or something like that, and be configurable.
--
Alexandre Julliard
julli...@winehq.org
Re: mountmgr.sys: For loop-mounted devices, use the backing file
On Tue, Aug 21, 2012 at 4:25 PM, GOUJON Alexandre wrote: > I thought mounting the ISO should be the same thing than inserting the disc > in the drive. > But you seem to think that the current behaviour is the right one so in this > case, simply ignore my patch. > > Try using cdemu to load that ISO into a virtual CDROM drive. There's an Ubuntu PPA for it at https://launchpad.net/~cdemu/+archive/ppa Damjan
Re: mountmgr.sys: For loop-mounted devices, use the backing file
On 08/21/2012 11:49 AM, Alexandre Julliard wrote: Alexandre Goujon writes: As part of their copy protection, some games use some ioctl's to check some physical attributes. Unfortunately, when using the loop device, some ioctl fail (like IOCTL_SCSI_GET_ADDRESS). A simple fix is to use /path/to/the/file.ISO instead of /dev/loopX. Several places depend on this being a device. Besides, failing to get the SCSI address of a loop mount seems like correct behavior to me. I originally wanted this patch in because my game was failing when I mounted the ISO of the disc via the loop device. The game was calling GetVolumeInformation to check its serial and to do so, GetVolumeInformation has to look at some blocks at specific offsets. But seeking (SetFilePointer) and reading (ReadFile) is not the same with the handle of the loop device and the ISO file. So I had to manually change the dosdesices/X:: link to make it point from /dev/loop/X to /path/to/file.iso Moreover, even if it is understandable that IOCTL_SCSI_GET_ADDRESS fails, others like IOCTL_DVD_READ_STRUCTURE, should return valid values, not ERROR_NOT_SUPPORTED. I thought mounting the ISO should be the same thing than inserting the disc in the drive. But you seem to think that the current behaviour is the right one so in this case, simply ignore my patch.
Re: mountmgr.sys: For loop-mounted devices, use the backing file
Alexandre Goujon writes: > As part of their copy protection, some games use some ioctl's to check some > physical attributes. > Unfortunately, when using the loop device, some ioctl fail (like > IOCTL_SCSI_GET_ADDRESS). > A simple fix is to use /path/to/the/file.ISO instead of /dev/loopX. Several places depend on this being a device. Besides, failing to get the SCSI address of a loop mount seems like correct behavior to me. -- Alexandre Julliard julli...@winehq.org
Re: start: Support getting the file to open by AppleEvent.
24 jul 2012 kl. 17:49 skrev Per Johansson: > I've also managed to write a function which fetches the AppleEvent using > Objective-C, which can be seen here: > <https://github.com/morth/molae/blob/master/molae.m>. > > I suppose if there's no way to get this file into wine I could make it into a > library and check for it in configure. Would that be the most proper approach? Sorry, I googled some and brought myself up to date with the Obj-C discussions in 2009 and 2010. I knew Obj-C is not allowed but I hadn't realized it was such an heated debate. At the risk of bringing it up even more, I don't necessarily think a QuartDriver is necessary, or at least not a primary goal. I would like to see some better integration with the OS X desktop though. The good news is I think I might've found a path through the CoreServices (C API) code which will also fetch the initial AppleEvent. Still investigating... Regards, -- Per Johansson
Re: start: Support getting the file to open by AppleEvent.
19 jul 2012 kl. 20:00 skrev Per Johansson: > 19 jul 2012 kl. 18:11 skrev Alexandre Julliard : > >> You really don't want to do that. > > Alright, but like I said earlier there's really no other good way to support > associations without using Objective-C. I'll send a new version without > associations support in a few days. I've sent in a new series without associations support, so this one can be discarded (noticed it's still in new status). I've also managed to write a function which fetches the AppleEvent using Objective-C, which can be seen here: <https://github.com/morth/molae/blob/master/molae.m>. I suppose if there's no way to get this file into wine I could make it into a library and check for it in configure. Would that be the most proper approach? Regrads, -- Per Johansson
Re: start: Support getting the file to open by AppleEvent.
19 jul 2012 kl. 18:11 skrev Alexandre Julliard : > Per Johansson writes: > >> Uses a private API. > > You really don't want to do that. Alright, but like I said earlier there's really no other good way to support associations without using Objective-C. I'll send a new version without associations support in a few days.
Re: start: Support getting the file to open by AppleEvent.
Per Johansson writes: > Series goal: Implement app bundle start menu / file type associations on OS X. > > > From 681ea02fb9e3df819f812e359d3fe76c77423e32 Mon Sep 17 00:00:00 2001 > From: Per Johansson > Date: Tue, 17 Apr 2012 21:29:13 +0200 > Subject: start: Support getting the file to open by AppleEvent. > To: wine-patches > Reply-To: wine-devel > > Uses a private API. You really don't want to do that. -- Alexandre Julliard julli...@winehq.org
Re: Suppressing My Computer in File Open dialog box?
On Sat, Jul 14, 2012 at 2:03 AM, GOUJON Alexandre wrote: >> Does anyone know how to keep the Save File dialog box from >> listing My Computer in the LookIn pulldown? > > Have you read > http://msdn.microsoft.com/en-us/library/windows/desktop/ms646960%28v=vs.85%29.aspx#_win32_Open_and_Save_As_Dialog_Box_Customization > ? Yeah, hooking was on my list of things to try, maybe I can intercept the items as they're added to the listbox... Thanks, Dan
Re: Suppressing My Computer in File Open dialog box?
On 07/14/2012 01:28 AM, Dan Kegel wrote: I'm creating a page of tips at http://wiki.winehq.org/DisplayingUnixFilenames for vendors shipping Windows apps on Linux with Wine who want their apps to use Windows paths throughout internally, but display Linux paths in the GUI This is something I've been meaning to do ever since I helped port Picasa. Picasa was an easy case, since it didn't use any standard widgets. So now I'm wondering how to coax standard widgets into not leaking Windows paths or naming conventions visually. Does anyone know how to keep the Save File dialog box from listing My Computer in the LookIn pulldown? (I know how to keep it from showing /, but I'd like to do the opposite, and *only* show / and maybe the user's home directory, if possible.) Have you read http://msdn.microsoft.com/en-us/library/windows/desktop/ms646960%28v=vs.85%29.aspx#_win32_Open_and_Save_As_Dialog_Box_Customization ? I tried in the past to make the Open dialog box able to select folder (instead of opening them). I first thought it was as simple as using a special flag when calling GetOpenFileName but I ended customizing the dialog via hook procedures.
Suppressing My Computer in File Open dialog box?
I'm creating a page of tips at http://wiki.winehq.org/DisplayingUnixFilenames for vendors shipping Windows apps on Linux with Wine who want their apps to use Windows paths throughout internally, but display Linux paths in the GUI This is something I've been meaning to do ever since I helped port Picasa. Picasa was an easy case, since it didn't use any standard widgets. So now I'm wondering how to coax standard widgets into not leaking Windows paths or naming conventions visually. Does anyone know how to keep the Save File dialog box from listing My Computer in the LookIn pulldown? (I know how to keep it from showing /, but I'd like to do the opposite, and *only* show / and maybe the user's home directory, if possible.)
Re: kernel32: Add a test for deleting an opened for reading file. Take 2.
one tricky question... could it be that on windows this test behaves
differently on ntfs vs FAT filesystem ?
or what would give re-opening the file after the deletefile call ?
A+
2012/6/21, Dmitry Timoshkov :
> Previous version had a typo in file name.
> ---
> dlls/kernel32/tests/file.c | 26 ++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/dlls/kernel32/tests/file.c b/dlls/kernel32/tests/file.c
> index 8768b99..0a662d9 100644
> --- a/dlls/kernel32/tests/file.c
> +++ b/dlls/kernel32/tests/file.c
> @@ -3236,6 +3236,31 @@ static void test_CreatFile(void)
>
> DeleteFile(file_name);
> }
> +static void test_delete_file(void)
> +{
> +char temp_path[MAX_PATH], temp_file[MAX_PATH];
> +HANDLE hfile;
> +int ret;
> +
> +GetTempPathA(MAX_PATH, temp_path);
> +GetTempFileName(temp_path, "tst", 0, temp_file);
> +
> +SetLastError(0xdeadbeef);
> +hfile = CreateFile(temp_file, GENERIC_READ, FILE_SHARE_DELETE |
> FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0);
> +ok(hfile != INVALID_HANDLE_VALUE, "CreateFile error %d\n",
> GetLastError());
> +
> +SetLastError(0xdeadbeef);
> +ret = DeleteFile(temp_file);
> +todo_wine
> +ok(ret, "DeleteFile error %d\n", GetLastError());
> +
> +SetLastError(0xdeadbeef);
> +ret = CloseHandle(hfile);
> +ok(ret, "CloseHandle error %d\n", GetLastError());
> +ret = DeleteFile(temp_file);
> +todo_wine
> +ok(!ret, "DeleteFile should fail\n");
> +}
>
> START_TEST(file)
> {
> @@ -3257,6 +3282,7 @@ START_TEST(file)
> test_CreateFileW();
> test_DeleteFileA();
> test_DeleteFileW();
> +test_delete_file();
> test_MoveFileA();
> test_MoveFileW();
> test_FindFirstFileA();
> --
> 1.7.11
>
>
>
>
--
--
Eric Pouech
Re: kernel32: Add a test for deleting an opened for reading file.
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=19407 Your paranoid android. === WNT4WSSP6 (32 bit file) === file.c:3255: Test failed: DeleteFile error 2 === W2KPROSP4 (32 bit file) === file.c:3255: Test failed: DeleteFile error 2 === WXPPROSP3 (32 bit file) === file.c:3255: Test failed: DeleteFile error 2 === W2K3R2SESP2 (32 bit file) === file.c:3255: Test failed: DeleteFile error 2 === WVISTAADM (32 bit file) === file.c:3255: Test failed: DeleteFile error 2 === W2K8SE (32 bit file) === file.c:3255: Test failed: DeleteFile error 2 === W7PRO (32 bit file) === file.c:3255: Test failed: DeleteFile error 2 === W7PROX64 (32 bit file) === file.c:3255: Test failed: DeleteFile error 2 === TEST64_W7SP1 (32 bit file) === file.c:3255: Test failed: DeleteFile error 2 === W7PROX64 (64 bit file) === file.c:3255: Test failed: DeleteFile error 2 === TEST64_W7SP1 (64 bit file) === file.c:3255: Test failed: DeleteFile error 2
