Re: *** GMX Spamverdacht *** MSYS touch.exe timestamp resolution issue on Wine-1.6
Am 12.10.2013 23:28, schrieb Alan W. Irwin: Under MSYS bash.exe if I use the touch command I only get 1-second resolution when reading the results. bash.exe-3.1$ touch touch1.test touch2.test bash.exe-3.1$ ls --full-time touch*.test -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.0 -0700 touch1.test -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.0 -0700 touch2.test Would somebody be willing to make the above test for MSYS on the Microsoft version of Windows (which I don't have access to) to see if time stamps are being read with 1-second resolution as above. That test should help distinguish whether this is a Wine issue or else an MSYS issue. I have also done some tests with the MSYS find.exe and make.exe commands, and in all cases touch2.test is not newer than touch1.text. This can be an important issue for the make command where one-second time resolution can potentially screw up file dependencies. If I use the equivalent Linux ls (and find and make) commands to read the time stamps on the above files, then touch2.test is newer than touch1.text, e.g., wine@raven ls --full-time touch*.test -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.39100 -0700 touch1.test -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.40800 -0700 touch2.test So I think this implies the MSYS touch.exe command is writing high-resolution (i.e., millisecond) time stamps, and it is only reading that high-resolution time stamp that seems to be an issue for MSYS on Wine. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science _ Sure -- seems to be a MSYS issue though: root@me ~ $ touch touch1 touch2 root@me ~ $ ls --full-time touch* -rw-r--r-- 1 root Administratoren 0 2013-10-13 13:33:47.0 + touch1 -rw-r--r-- 1 root Administratoren 0 2013-10-13 13:33:47.0 + touch2 root@me ~ $ uname MINGW32_NT-6.1 root@me ~ $ Have a nice Day ! Thorsten
Mono Update
Hi, wine-mono hasn't been updated in nearly a year.Should it be time to consider a new release? Thoughts. Best Regards Alistair Leslie-Hughes
Re: [2/4] dnsapi/tests: Compile with -D__WINESRC__.
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=2733 Your paranoid android. === wxppro (32 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === wvista (32 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === w2008s64 (32 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === w7pro64 (32 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === w864 (32 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === w2008s64 (64 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === w7pro64 (64 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly === w864 (64 bit record) === record.c:46: Test failed: succeeded unexpectedly record.c:49: Test failed: succeeded unexpectedly
Re: [PATCH] d3drm: added some freeing of memory in error paths (Coverity)
On 13 October 2013 11:13, Marcus Meissner mar...@jet.franken.de wrote: 1104553 Resource leak Fixing the memory leak is fine of course, but I think it would be better to handle the array initialization in d3drm_visual_array_create() etc. instead, so that those functions actually return an object that's properly initialized.
Re: Mono Update
IMHO it is more than time. Mono has several release cycles of new features that we are not taking advantage of with wine-mono cheers 2013/10/14 Alistair Leslie-Hughes leslie_alist...@hotmail.com: Hi, wine-mono hasn't been updated in nearly a year.Should it be time to consider a new release? Thoughts. Best Regards Alistair Leslie-Hughes
Re: Help / Mentoring
Hello Hugh, I'd be more than happy to help you review your patches, although I am no wineconsole expert, I believe I could help you get your changes into wine. Contact me if no better offer comes around :) cheers 2013/10/11 Hugh McMaster hugh.mcmas...@masterindexing.com: Can anyone help me on this? I do realize that wineconsole is only a minor focus of development. Hugh - Hi everyone, I just wanted to know if anyone would mind helping/mentoring me with a few small patches. I am working primarily on wineconsole's screen buffer problems (to which I believe I have the solution), but am also looking at implementing some stub Win32 console functions found in dlls/kernel32. Obviously, my aim is to have these patches committed, as the changes will benefit the entire Wine community. I had initially thought of Eric Poeuch, a significant wineconsole developer, however he appears to be extremely busy. So I'm not sure who else to contact. If time is a consideration, please note that I won't be constantly contacting you to review patches or answer questions. Thank you, Hugh
RE: Help / Mentoring
On Monday, 14 October 2013 9:50 PM, Ricardo Filipe wrote: I'd be more than happy to help you review your patches, although I am no wineconsole expert, I believe I could help you get your changes into wine. Contact me if no better offer comes around :) cheers Hello Ricardo, Thank you for your kind offer. I'll contact you via email. Hugh
Re: wsock32: Add a fallback for inet_network.
Huw Davies h...@codeweavers.com writes: --- dlls/wsock32/protocol.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) This doesn't build on MingW: protocol.o: In function `WSOCK32_inet_network@4': /home/julliard/wine/build/obj-pe32/dlls/wsock32/../../../wine/dlls/wsock32/protocol.c:55: undefined reference to `_inet_addr' /home/julliard/wine/build/obj-pe32/dlls/wsock32/../../../wine/dlls/wsock32/protocol.c:55: undefined reference to `_ntohl' collect2: ld returned 1 exit status winegcc: i686-w64-mingw32-gcc failed -- Alexandre Julliard julli...@winehq.org
Re: dlls/explorerframe: build tests with -D__WINESRC__
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=2750 Your paranoid android. === wvista (32 bit nstc) === nstc.c:1934: Test failed: Got event 7, count 0 nstc.c:1936: Test failed: Got event 4, count 0 nstc.c:1949: Test failed: Got event 4, count 0
Clang Static analysis
I have been doing a Clang static analysis of Wine on OS X using the one provided at http://clang-analyzer.llvm.org and storing the results on my PogoPlug drive. If someone wants to see the results, please tell me and I'll set up your e-mail. You will need a free PogoPlug account to view them. While the contents are zipped, they expand to about 1.2 GB. They are displayed as basic HTML pages, so you don't need anything special other than a web browser to see the results. Or you could click on this link for the analysis of 1.7.4: http://ppl.ug/ND-7PZ3cSzM/
Re: MSYS touch.exe timestamp resolution issue on Wine-1.6
On 2013-10-12 23:28, Alan W. Irwin wrote: Under MSYS bash.exe if I use the touch command I only get 1-second resolution when reading the results. bash.exe-3.1$ touch touch1.test touch2.test bash.exe-3.1$ ls --full-time touch*.test -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.0 -0700 touch1.test -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.0 -0700 touch2.test Would somebody be willing to make the above test for MSYS on the Microsoft version of Windows (which I don't have access to) to see if time stamps are being read with 1-second resolution as above. That test should help distinguish whether this is a Wine issue or else an MSYS issue. I tested this on Windows 7, with MSYS 1.0.18, and I get the exact same experience. ls --full-time has a one second resolution (on NTFS, I expect a two second resolution on FAT, at least for some FAT variations). I have also done some tests with the MSYS find.exe and make.exe commands, and in all cases touch2.test is not newer than touch1.text. This can be an important issue for the make command where one-second time resolution can potentially screw up file dependencies. If I use the equivalent Linux ls (and find and make) commands to read the time stamps on the above files, then touch2.test is newer than touch1.text, e.g., Same here if I use an equivalent Cygwin ls, i.e. the actual time stamps are more fine grained than MSYS is capable of detecting. wine@raven ls --full-time touch*.test -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.39100 -0700 touch1.test -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.40800 -0700 touch2.test So I think this implies the MSYS touch.exe command is writing high-resolution (i.e., millisecond) time stamps, and it is only reading that high-resolution time stamp that seems to be an issue for MSYS on Wine. Indeed. Since Cygwin has a different view, the situation should improve with MSYS 2. Cheers, Peter
Re: ntdll: Support pinning module refcount with LdrAddRefDll()
Nikolay Sivov nsi...@codeweavers.com wrote: +FreeLibrary(mod); Please add the tests for FreeLibrary return value. -- Dmitry.
Re: ntdll: Support pinning module refcount with LdrAddRefDll()
On 10/14/2013 05:21, Dmitry Timoshkov wrote: Nikolay Sivov nsi...@codeweavers.com wrote: +FreeLibrary(mod); Please add the tests for FreeLibrary return value. Makes sense, thanks.
MSYS touch.exe timestamp resolution issue on Wine-1.6
Under MSYS bash.exe if I use the touch command I only get 1-second resolution when reading the results. bash.exe-3.1$ touch touch1.test touch2.test bash.exe-3.1$ ls --full-time touch*.test -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.0 -0700 touch1.test -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.0 -0700 touch2.test Would somebody be willing to make the above test for MSYS on the Microsoft version of Windows (which I don't have access to) to see if time stamps are being read with 1-second resolution as above. That test should help distinguish whether this is a Wine issue or else an MSYS issue. I have also done some tests with the MSYS find.exe and make.exe commands, and in all cases touch2.test is not newer than touch1.text. This can be an important issue for the make command where one-second time resolution can potentially screw up file dependencies. If I use the equivalent Linux ls (and find and make) commands to read the time stamps on the above files, then touch2.test is newer than touch1.text, e.g., wine@raven ls --full-time touch*.test -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.39100 -0700 touch1.test -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.40800 -0700 touch2.test So I think this implies the MSYS touch.exe command is writing high-resolution (i.e., millisecond) time stamps, and it is only reading that high-resolution time stamp that seems to be an issue for MSYS on Wine. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __
Re: d3d11 patch
On Fri, Oct 11, 2013 at 7:20 PM, Max . asnl...@hotmail.com wrote: Hi, I would like to know when the first patchs for d3d11 will be introduce into wine ? Beginning of 2014 ? middle 2014 ? End 2014 ? Thanks, WIR
Re: mscoree: Add support for ICLRMetaHostPolicy interface
Alistair Leslie-Hughes leslie_alist...@hotmail.com wrote:
+static HRESULT WINAPI metahostpolicy_QueryInterface(ICLRMetaHostPolicy
*iface, REFIID riid, void **ppvObject)
+{
+TRACE(%s %p\n, debugstr_guid(riid), ppvObject);
+
+if ( IsEqualGUID( riid, IID_ICLRMetaHostPolicy ) ||
+ IsEqualGUID( riid, IID_IUnknown ) )
+{
+*ppvObject = iface;
+}
+else
+{
+FIXME(Unsupported interface %s\n, debugstr_guid(riid));
+return E_NOINTERFACE;
+}
+
+ICLRMetaHostPolicy_AddRef( iface );
+
+return S_OK;
+}
I think that a common COM convention is to set the object pointer to NULL
in case of an unsupported interface.
Also you're doing pretty good job in avoiding hungarian notation except for
ppvObject.
Another nitpick is the choice for if/else construct (although I understand
that other places also use this sub-optimal one). A more elegant way of
implementing QueryInterface would be IMHO:
static HRESULT WINAPI xxx_QueryInterface(IFace *iface, REFIID riid, void
**object)
{
if (IsEqualGUID(riid, IID_IUnknown) ||
IsEqualGUID(riid, IID_IAnotherSupported)
{
xxx_AddRef(iface);
*object = iface;
return S_OK;
}
*object = NULL;
return E_NOINTERFACE;
}
--
Dmitry.
Re: Fix text rotation problem in GM_ADVANCED graphics mode caused by incorrect implementation of GetTextExtentPointW().
On 01.10.2013 12:12, Alexandre Julliard wrote: Ralf Habacker ralf.habac...@freenet.de writes: With other patches i have been told to implement such stuff in the dib driver. Unfortunally this do not works in this case, because in the top level function it looks like having driver specific stuff using display coordinates. It would still most likely have to be in the driver, though maybe the driver would not be calling that exact entry point. In any case, you can't change the DC transform like this. You are refering to the usage of setting hard coded values ? Instead I should decompose the rotation and reset only that part ? Ralf
RE: Help / Mentoring
Can anyone help me on this? I do realize that wineconsole is only a minor focus of development. Hugh - Hi everyone, I just wanted to know if anyone would mind helping/mentoring me with a few small patches. I am working primarily on wineconsole's screen buffer problems (to which I believe I have the solution), but am also looking at implementing some stub Win32 console functions found in dlls/kernel32. Obviously, my aim is to have these patches committed, as the changes will benefit the entire Wine community. I had initially thought of Eric Poeuch, a significant wineconsole developer, however he appears to be extremely busy. So I'm not sure who else to contact. If time is a consideration, please note that I won't be constantly contacting you to review patches or answer questions. Thank you, Hugh
Fwd: Re: kernel32/tests: Add tests for job objects (try 7)
(no idea why my client sent this to wine-patches) On 10/10/13 15:23, Andrew Cook wrote: --- dlls/kernel32/tests/process.c | 159 +- include/winbase.h | 1 + include/winnt.h | 90 3 files changed, 249 insertions(+), 1 deletion(-) there appears to be a window between the all processes leaving a job and the job actually being considered empty, and no apparent way to wait for this. I can't reproduce this locally either. Is there an accepted way to wait for some inaccessible kernel-side event? reordering some calls would likely hide the issue but i'd rather avoid that. https://newtestbot.winehq.org/JobDetails.pl?Key=2687 failure on w8 https://newtestbot.winehq.org/JobDetails.pl?Key=2709 failure on w864 https://newtestbot.winehq.org/JobDetails.pl?Key=2685 same patch, success on w864
Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.
Hmm... It still fails today. I have a better idea to fix it, will send a patch tomorrow. Sorry for introducing the failures :(
Re: wined3d: Use BOOL type where appropriate
On 11 October 2013 22:51, Frédéric Delanoy frederic.dela...@gmail.com wrote: -DWORD onesided_enable = FALSE; -DWORD twosided_enable = FALSE; +DWORD onesided_enable = 0; +DWORD twosided_enable = 0; Actually, all of those initializations are redundant.
Re: winmm/tests: Use BOOL type where appropriate
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=2721 Your paranoid android. === wxppro (32 bit wave) === wave.c:498: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 13211 bytes, should be 13230 wave.c:498: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 13229 bytes, should be 13230 wave.c:498: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 13075 bytes, should be 13230 wave.c:509: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 13091 samples (13091 bytes), should be 13230 (13230 bytes) wave.c:522: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 594 ms, (13108 bytes), should be 600 (13230 bytes) wave.c:498: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 13220 bytes, should be 13230 wave.c:498: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 17621 bytes, should be 17640 wave.c:509: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 17634 samples (17634 bytes), should be 17640 (17640 bytes) wave.c:498: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 22016 bytes, should be 22050 wave.c:509: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 22027 samples (22027 bytes), should be 22050 (22050 bytes) wave.c:522: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 999 ms, (22044 bytes), should be 1000 (22050 bytes)
Re: winspool: ERROR_INVALID_NAME in GetDefaultPrinter() ?
Dears, I faced the same problem, but, unfortunally, link to answer is invalid. Please, tell me, how did you resolve situation? Thanks. -- View this message in context: http://wine.1045685.n5.nabble.com/winspool-ERROR-INVALID-NAME-in-GetDefaultPrinter-tp1788463p5773073.html Sent from the Wine - Devel mailing list archive at Nabble.com.
Re: Fix text rotation problem in GM_ADVANCED graphics mode caused by incorrect implementation of GetTextExtentPointW().
On 01.10.2013 12:40, Alexandre Julliard wrote:
Ralf Habacker r...@habacker.de writes:
On 01.10.2013 12:12, Alexandre Julliard wrote:
Ralf Habacker ralf.habac...@freenet.de writes:
With other patches i have been told to implement such stuff in the dib
driver. Unfortunally this do not works in this case, because in the top
level function it looks like having driver specific stuff using display
coordinates.
It would still most likely have to be in the driver,
which is freetype_GetTextExtentExPoint() ?
though maybe the driver would not be calling that exact entry point.
not sure i understand right:
GetTextExtentExPointW() calls get_char_positions(), which runs
dev-funcs-pGetTextExtentExPoint(), which is mapped to
freetype_GetTextExtentExPoint(), which is in the driver. Which entry
point your are refering else ?
The various text rendering entry points in the graphics drivers.
You mean there are more affected places ?
In any case, you can't change the DC transform like this
then a real solution requires to move the transformation to logical
coordinates stuff in BOOL GetTextExtentExPointW() to
freetype_GetTextExtentExPoint() and to manipulate the related matrixes
in freetype_GetTextExtentExPoint() directly wen using GM_ADVANCED ?
No, I don't think so. The transform is only used to determine the font
scaling factor.
the recent implementation of get_glyph_outline() uses in GM_ADVANCED
mode a scale which depends somehow on the rotation angle.
I got better results with saving the use GM_ADVANCED case in
font-font_desc.advanced_graphics_mode and the following hunks for
freetype.c
@@ -6426,10 +6426,24 @@ static DWORD get_glyph_outline(GdiFont
*incoming_font, UINT glyph, UINT format,
worldMat.xy = -FTFixedFromFloat(font-font_desc.matrix.eM21);
worldMat.yx = -FTFixedFromFloat(font-font_desc.matrix.eM12);
worldMat.yy = FTFixedFromFloat(font-font_desc.matrix.eM22);
pFT_Matrix_Multiply(worldMat, transMat);
-pFT_Matrix_Multiply(worldMat, transMatUnrotated);
pFT_Matrix_Multiply(worldMat, transMatTategaki);
-needsTransform = TRUE;
+if (font-font_desc.advanced_graphics_mode) {
+worldMat.xx =
FTFixedFromFloat(1.0/font-font_desc.matrix.eM11);
+worldMat.xy = -FTFixedFromFloat(font-font_desc.matrix.eM21);
+worldMat.yx = -FTFixedFromFloat(font-font_desc.matrix.eM12);
+worldMat.yy =
FTFixedFromFloat(1.0/font-font_desc.matrix.eM22);
+}
+else {
+worldMat = identityMat;
+}
+
+pFT_Matrix_Multiply(worldMat, transMatUnrotated);
+ needsTransform = TRUE;
}
and
@@ -6571,35 +6590,50 @@ static DWORD get_glyph_outline(GdiFont
*incoming_font, UINT glyph, UINT format,
origin_y = top;
}
+if (font-font_desc.advanced_graphics_mode)
+pFT_Vector_Transform(vec, transMatUnrotated);
+else
+pFT_Vector_Transform(vec, transMat);
+
which works except for using 90° and 270° world transformations angles.
Transforming back the list of character width in the top level function
GetTextExtentExPointW(). The transformation is done with
static inline INT INTERNAL_XDSTOWS(DC *dc, INT width)
{
double floatWidth;
floatWidth = (double)width * dc-xformVport2World.eM11;
/* Round to integers */
return GDI_ROUND(floatWidth);
}
dc-xformVport2World.eM11 is zero in the mentioned angles, so it will
always return zero, which means at now the submitted patch is the only
working solution.
From what i can see an alternative would require to move the device to
logical back transformation into get_glyph_outline() and to refactor all
function get_glyph_outline() is called from.
Regards
Ralf
Re: winemac: Add registry settings to make Option keys send Alt rather than accessing additional characters from the keyboard layout.
Hello, On Thu, Oct 10, 2013 at 3:24 AM, Ken Thomases k...@codeweavers.com wrote: On Oct 9, 2013, at 4:49 PM, Phil Krylov wrote: Do you consider adding an option to stop interpreting Command as Alt? I have not considered it. What would be gained? Do you want the Command key interpreted as the Windows key? Do you want something else to happen when Command is pressed? Every time I press Cmd-Space to switch keyboard layouts, Wine activates menu as if I would have pressed Alt, so I have to press Command once again to exit it. It does not happen in Windows, though, when I use Alt-Shift to switch layouts, so the real problem is not related to Alt interpretation of Cmd, but to incorrect emulation of Windows behaviour when a keyboard layout switch hotkey is pressed. On the other hand, Option is labeled as Alt, and works this way with the X11 driver, so it seems logical to process Cmd as Win key. And it would hack around my actual problem ;) -- Ph.
Re: [PATCH 5/5] user32: Implement better stub of OpenInputDesktop.
Hi Vincent, Thanks a lot for the advice, I'll try that. On Thu, Oct 10, 2013 at 12:41 AM, Vincent Povirk madewokh...@gmail.com wrote: I don't think it's possible to properly implement SwitchDesktop in either the X11 or Mac driver. There's just nothing sensible for it to do. That's one reason that I didn't try to implement SwitchDesktop, I was not very sure about this, thanks for confirming. One possible strategy would be to implement SwitchDesktop in user32 and wineserver. Wineserver could logically track the input desktop, and OpenInputDesktop would return the correct desktop, but SwitchDesktop wouldn't really do anything. If in the future we decide there's something SwitchDesktop can do that makes sense, we can add a function for it to the user driver, and OpenInputDesktop probably won't need to change. I ever though about this, but gave up. After more thought, I agree that this is a better approach, thanks again! -- Regards, Qian Hong - http://www.codeweavers.com
Re: xmllite: Use BOOL type where appropriate
On 10/10/2013 00:36, Frédéric Delanoy wrote:
---
dlls/xmllite/reader.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/dlls/xmllite/reader.c b/dlls/xmllite/reader.c
index 0a4423c..a216951 100644
--- a/dlls/xmllite/reader.c
+++ b/dlls/xmllite/reader.c
@@ -726,7 +726,7 @@ static void readerinput_grow(xmlreaderinput *readerinput,
int length)
}
}
-static inline int readerinput_is_utf8(xmlreaderinput *readerinput)
+static inline BOOL readerinput_is_utf8(xmlreaderinput *readerinput)
{
static char startA[] = {'','?'};
static char commentA[] = {'','!'};
@@ -953,7 +953,7 @@ static void reader_skipn(xmlreader *reader, int n)
}
}
-static inline int is_wchar_space(WCHAR ch)
+static inline BOOL is_wchar_space(WCHAR ch)
{
return ch == ' ' || ch == '\t' || ch == '\r' || ch == '\n';
}
@@ -1055,7 +1055,7 @@ static HRESULT reader_parse_versioninfo(xmlreader *reader)
}
/* ([A-Za-z0-9._] | '-') */
-static inline int is_wchar_encname(WCHAR ch)
+static inline BOOL is_wchar_encname(WCHAR ch)
{
return ((ch = 'A' ch = 'Z') ||
(ch = 'a' ch = 'z') ||
@@ -1269,7 +1269,7 @@ static HRESULT reader_parse_comment(xmlreader *reader)
}
/* [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10] */
-static inline int is_char(WCHAR ch)
+static inline BOOL is_char(WCHAR ch)
{
return (ch == '\t') || (ch == '\r') || (ch == '\n') ||
(ch = 0x20 ch = 0xd7ff) ||
@@ -1279,7 +1279,7 @@ static inline int is_char(WCHAR ch)
}
/* [13] PubidChar ::= #x20 | #xD | #xA | [a-zA-Z0-9] | [-'()+,./:=?;!*#@$_%] */
-static inline int is_pubchar(WCHAR ch)
+static inline BOOL is_pubchar(WCHAR ch)
{
return (ch == ' ') ||
(ch = 'a' ch = 'z') ||
@@ -1292,7 +1292,7 @@ static inline int is_pubchar(WCHAR ch)
(ch == '_') || (ch == '\r') || (ch == '\n');
}
-static inline int is_namestartchar(WCHAR ch)
+static inline BOOL is_namestartchar(WCHAR ch)
{
return (ch == ':') || (ch = 'A' ch = 'Z') ||
(ch == '_') || (ch = 'a' ch = 'z') ||
@@ -1312,7 +1312,7 @@ static inline int is_namestartchar(WCHAR ch)
}
/* [4 NS] NCName ::= Name - (Char* ':' Char*) */
-static inline int is_ncnamechar(WCHAR ch)
+static inline BOOL is_ncnamechar(WCHAR ch)
{
return (ch = 'A' ch = 'Z') ||
(ch == '_') || (ch = 'a' ch = 'z') ||
@@ -1336,7 +1336,7 @@ static inline int is_ncnamechar(WCHAR ch)
(ch = 0xfdf0 ch = 0xfffd);
}
-static inline int is_namechar(WCHAR ch)
+static inline BOOL is_namechar(WCHAR ch)
{
return (ch == ':') || is_ncnamechar(ch);
}
I don't actually see what this will achieve, but I see such patches are
accepted. Is it a new style rule?
Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.
Qian Hong qh...@codeweavers.com writes: --- dlls/user32/tests/winstation.c | 57 1 file changed, 57 insertions(+) Can you please fix the test failures introduced by your previous changes first? cf. https://test.winehq.org/data/tests/user32:winstation.html -- Alexandre Julliard julli...@winehq.org
Re: wmvcore: Stub implementation of IWMMetadataEditor interface
On 10/10/2013 14:58, Jeff Latimer wrote:
---
dlls/wmvcore/Makefile.in| 2 +-
dlls/wmvcore/wmvcore_main.c | 100
+++-
include/wmsdkidl.idl| 11 ++---
3 files changed, 105 insertions(+), 8 deletions(-)
+typedef struct MetadataEditorImpl {
+IWMMetadataEditor MetadataEditor_iface;
+LONG ref;
+} MetadataEditorImpl;
+static inline MetadataEditorImpl *impl_from_MetadataEditor(IWMMetadataEditor
*iface)
Please follow naming convetions for interfaces.
+HRESULT WINAPI WMCreateEditor_close(IWMMetadataEditor *iface)
+{
+FIXME(iface=%p\n, iface);
+HeapFree(GetProcessHeap(), 0, iface);
+return S_OK;
+}
+HRESULT WINAPI WMCreateEditor_flush(IWMMetadataEditor *iface)
+{
+FIXME(iface=%p\n, iface);
+HeapFree(GetProcessHeap(), 0, iface);
+return S_OK;
+}
This looks totally wrong.
Also please keep implementation functions order and interface methods
order the same.
Re: ieframe: Compile tests with __WINESRC__ define.
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=2688 Your paranoid android. === wxppro (32 bit webbrowser) === webbrowser.c:792: Test failed: ReadyState = 1, expected 4
Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.
Hello, On Thu, Oct 10, 2013 at 6:48 PM, Alexandre Julliard julli...@winehq.org wrote: Can you please fix the test failures introduced by your previous changes first? cf. https://test.winehq.org/data/tests/user32:winstation.html Sorry for introduced the failures, I'd like to investigate, however I can't reproduce the failures on my own Win7. I try to run winetest-latest.exe on the testbot, but it ran timeout (as expect), is there any way I can increase the timeout value from 120 to something like 1800? Thanks! -- Regards, Qian Hong - http://www.codeweavers.com
Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.
On Thu, Oct 10, 2013 at 8:42 PM, Qian Hong qh...@codeweavers.com wrote: Sorry for introduced the failures, I'd like to investigate, however I can't reproduce the failures on my own Win7. I try to run winetest-latest.exe on the testbot, but it ran timeout (as expect), is there any way I can increase the timeout value from 120 to something like 1800? Oh, forgot to say: the test failures are most likely caused by side effects of other tests, I can't reproduce it on our testbots if only winstation tests are executed, that is why I asked for increasing the timeout so I can run a full test of winetest-latest.exe -- Regards, Qian Hong - http://www.codeweavers.com
Re: mshtml: Compile tests with __WINESRC__ define.
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=2689 Your paranoid android. === w864 (64 bit activex) === activex.c:1346: Test failed: unexpected call SetObjectRects === wxppro (32 bit htmldoc) === htmldoc.c:2898: Test failed: mon(0026BFD0) != exmon(00269670) htmldoc.c:7601: Test failed: mon(0026BFD0) != exmon(00269670) htmldoc.c:5978: Test failed: mon(0026BFD0) != exmon(00269670) htmldoc.c:2898: Test failed: mon(0029CA28) != exmon(00286FF8) htmldoc.c:7601: Test failed: mon(0029CA28) != exmon(00286FF8) htmldoc.c:5978: Test failed: mon(0029CA28) != exmon(00286FF8) === wvista (32 bit htmldoc) === No test summary line found === w7pro64 (32 bit htmldoc) === No test summary line found
Re: xmllite: Use BOOL type where appropriate
On Thu, Oct 10, 2013 at 12:40 PM, Nikolay Sivov bungleh...@gmail.com wrote: On 10/10/2013 00:36, Frédéric Delanoy wrote: --- dlls/xmllite/reader.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/dlls/xmllite/reader.c b/dlls/xmllite/reader.c index 0a4423c..a216951 100644 --- a/dlls/xmllite/reader.c +++ b/dlls/xmllite/reader.c @@ -726,7 +726,7 @@ static void readerinput_grow(xmlreaderinput *readerinput, int length) } } -static inline int readerinput_is_utf8(xmlreaderinput *readerinput) +static inline BOOL readerinput_is_utf8(xmlreaderinput *readerinput) I don't actually see what this will achieve, but I see such patches are accepted. Is it a new style rule? Basically cleanup/clarity. Using boolean values when expressing logical expressions results does make sense (and it makes the intent clearer) IMHO. The fact that it translates to integer values is just a C implementation/design detail. Why using an integer type when one only needs one of two truth values like TRUE/FALSE? -- Frédéric Delanoy
Re: xmllite: Use BOOL type where appropriate
On 10 October 2013 16:59, Frédéric Delanoy frederic.dela...@gmail.com wrote: Basically cleanup/clarity. Using boolean values when expressing logical expressions results does make sense (and it makes the intent clearer) IMHO. I just think it would have been nice if we could have used the C99 bool type, but clearly C99 is much too new for any real compilers to support.
Re: [PATCH] d3dx9: Move object initialization into a separate function.
On 09.10.2013 01:12, Matteo Bruni wrote: Hi Rico, 2013/10/8 Rico Schüller kgbric...@web.de: Hi, this moves the object initialization into a separate function, so it could be used for strings and resources. It also removes the STATE_TYPE as we could distinguish the types at the object level. 1. When an object has a destination, it points to another shader variable. This was state ST_PARAMETER. 2. If a variable has something in data, it is fxlc, shader (preshader) or a string. This was state ST_CONSTANT and ST_FXLC. 3. If it has both (destination and data), it points to an array of shader variables. The name is in the destination, the index could be calculated with the data. This will be added in a later patch. There's still the issue of distinguishing between ST_CONSTANT and ST_FXLC, checking object_id and type might cover that though. I think we could distinguish between them. I forgot to add, if both are 0, then it is a constant and the parameter data has already the correct value. Marking the shader as ST_CONSTANT was a little bit wrong, as we would need to set the shader/preshader variables. Also saving the destination parameter in the object gains some speed when we need to access the variable as we don't need to run get_parameter_by_name() each time we need the variable ... I'm not sure storing additional info into the objects is the right thing to do. Take a look at the D3DXFX_NOT_CLONEABLE flag from http://msdn.microsoft.com/en-us/library/windows/desktop/bb172855%28v=vs.85%29.aspx. Notice that GetPassDesc() doesn't return the shader data if the object was created with the flag. What I've been thinking is that it simply can't because the original shader data, stored in an object, were freed after parsing. Yeah, I'm aware of D3DXFX_NOT_CLONEABLE. But we need to hold the shader blob or something similar (a reflection of the used preshader variables) to set the correct values. We also need it in the case for when the parameter needs to be calculated (fxlc) and in for strings. So imho, we could only release the blob partially when we have a preshader, nowhere else (and in this case we still need the reflection somehow). So let me conclude: We need to store the destination and the reflection somewhere. We may release the full shader binary. While nothing forces us to do the same (except probably avoiding to use more memory than strictly necessary) I think it's better not to put additional stuff into the objects or generally assume that the objects are still available after parsing. That means creating the shaders and the strings at parse time or right after that and storing any additional required information (e.g. preshader) in the parameter. So, directly storing the referenced parameter is a good idea but I'd prefer that pointer to be in d3dx_parameter. I haven't put it in the parameter as there are much more parameters than objects. Each state, each array element and each structure member has a parameter while there are only some parameters that have objects. So we may use some more bytes when putting it in the parameter than putting it in the object. I'm fine with both ways, because each object is tight to a specific parameter, it's mostly a matter of taste where the data is stored. Cheers Rico
Re: [PATCH 4/5] d3drm: Compare with the correct IID in IDirect3DRMVisualArrayImpl_QueryInterface().
Henri Verbeet hverb...@codeweavers.com wrote:
+static HRESULT WINAPI
IDirect3DRMVisualArrayImpl_QueryInterface(IDirect3DRMVisualArray *iface,
REFIID riid, void **out)
{
-TRACE((%p)-(%s, %p)\n, iface, debugstr_guid(riid), ret_iface);
+TRACE(iface %p, riid %s, out %p.\n, iface, debugstr_guid(riid), out);
-if (IsEqualGUID(riid, IID_IUnknown) ||
-IsEqualGUID(riid, IID_IDirect3DRMFrameArray))
+if (IsEqualGUID(riid, IID_IDirect3DRMVisualArray)
+|| IsEqualGUID(riid, IID_IUnknown))
{
-*ret_iface = iface;
IDirect3DRMVisualArray_AddRef(iface);
+*out = iface;
return S_OK;
}
Although this is existing code the assignment '*out = iface' is wrong,
especially since next patch introduces impl_from_IDirect3DRMVisualArray()
helper. Looks like that file needs a bit of COM clean up.
--
Dmitry.
Re: [PATCH 4/5] d3drm: Compare with the correct IID in IDirect3DRMVisualArrayImpl_QueryInterface().
On 9 October 2013 11:26, Dmitry Timoshkov dmi...@baikal.ru wrote:
Henri Verbeet hverb...@codeweavers.com wrote:
+static HRESULT WINAPI
IDirect3DRMVisualArrayImpl_QueryInterface(IDirect3DRMVisualArray *iface,
REFIID riid, void **out)
{
-TRACE((%p)-(%s, %p)\n, iface, debugstr_guid(riid), ret_iface);
+TRACE(iface %p, riid %s, out %p.\n, iface, debugstr_guid(riid), out);
-if (IsEqualGUID(riid, IID_IUnknown) ||
-IsEqualGUID(riid, IID_IDirect3DRMFrameArray))
+if (IsEqualGUID(riid, IID_IDirect3DRMVisualArray)
+|| IsEqualGUID(riid, IID_IUnknown))
{
-*ret_iface = iface;
IDirect3DRMVisualArray_AddRef(iface);
+*out = iface;
return S_OK;
}
Although this is existing code the assignment '*out = iface' is wrong,
especially since next patch introduces impl_from_IDirect3DRMVisualArray()
helper. Looks like that file needs a bit of COM clean up.
The entire dll needs some cleanup in general, but that assignment is
correct, since it's querying for the same interface that gets passed
in.
Help / Mentoring
Hi everyone, I just wanted to know if anyone would mind helping/mentoring me with a few small patches. I am working primarily on wineconsole's screen buffer problems (to which I believe I have the solution), but am also looking at implementing some stub Win32 console functions found in dlls/kernel32. Obviously, my aim is to have these patches committed, as the changes will benefit the entire Wine community. I had initially thought of Eric Poeuch, a significant wineconsole developer, however he appears to be extremely busy. So I'm not sure who else to contact. If time is a consideration, please note that I won't be constantly contacting you to review patches or answer questions. Thank you, Hugh
Re: [PATCH] d3dx9: Move object initialization into a separate function.
2013/10/9 Rico Schüller kgbric...@web.de: On 09.10.2013 01:12, Matteo Bruni wrote: Hi Rico, 2013/10/8 Rico Schüller kgbric...@web.de: Hi, this moves the object initialization into a separate function, so it could be used for strings and resources. It also removes the STATE_TYPE as we could distinguish the types at the object level. 1. When an object has a destination, it points to another shader variable. This was state ST_PARAMETER. 2. If a variable has something in data, it is fxlc, shader (preshader) or a string. This was state ST_CONSTANT and ST_FXLC. 3. If it has both (destination and data), it points to an array of shader variables. The name is in the destination, the index could be calculated with the data. This will be added in a later patch. There's still the issue of distinguishing between ST_CONSTANT and ST_FXLC, checking object_id and type might cover that though. I think we could distinguish between them. I forgot to add, if both are 0, then it is a constant and the parameter data has already the correct value. Marking the shader as ST_CONSTANT was a little bit wrong, as we would need to set the shader/preshader variables. Also saving the destination parameter in the object gains some speed when we need to access the variable as we don't need to run get_parameter_by_name() each time we need the variable ... I'm not sure storing additional info into the objects is the right thing to do. Take a look at the D3DXFX_NOT_CLONEABLE flag from http://msdn.microsoft.com/en-us/library/windows/desktop/bb172855%28v=vs.85%29.aspx. Notice that GetPassDesc() doesn't return the shader data if the object was created with the flag. What I've been thinking is that it simply can't because the original shader data, stored in an object, were freed after parsing. Yeah, I'm aware of D3DXFX_NOT_CLONEABLE. But we need to hold the shader blob or something similar (a reflection of the used preshader variables) to set the correct values. We also need it in the case for when the parameter needs to be calculated (fxlc) and in for strings. So imho, we could only release the blob partially when we have a preshader, nowhere else (and in this case we still need the reflection somehow). So let me conclude: We need to store the destination and the reflection somewhere. We may release the full shader binary. Yeah, we need to store something for those cases, but not necessarily the original shader blob (we could store some derived information instead). So I essentially agree here. While nothing forces us to do the same (except probably avoiding to use more memory than strictly necessary) I think it's better not to put additional stuff into the objects or generally assume that the objects are still available after parsing. That means creating the shaders and the strings at parse time or right after that and storing any additional required information (e.g. preshader) in the parameter. So, directly storing the referenced parameter is a good idea but I'd prefer that pointer to be in d3dx_parameter. I haven't put it in the parameter as there are much more parameters than objects. Each state, each array element and each structure member has a parameter while there are only some parameters that have objects. So we may use some more bytes when putting it in the parameter than putting it in the object. True, my point is that the memory reclaimed by freeing the objects is probably more than the memory wasted by some additional pointers. I don't have any hard data though (and applications might forget to specify D3DXFX_NOT_CLONEABLE) so I might be wrong. I'm fine with both ways, because each object is tight to a specific parameter, it's mostly a matter of taste where the data is stored. Cheers Rico
Re: [PATCH 5/5] user32: Implement better stub of OpenInputDesktop.
I don't think it's possible to properly implement SwitchDesktop in either the X11 or Mac driver. There's just nothing sensible for it to do. One possible strategy would be to implement SwitchDesktop in user32 and wineserver. Wineserver could logically track the input desktop, and OpenInputDesktop would return the correct desktop, but SwitchDesktop wouldn't really do anything. If in the future we decide there's something SwitchDesktop can do that makes sense, we can add a function for it to the user driver, and OpenInputDesktop probably won't need to change.
Re: winemac: Add registry settings to make Option keys send Alt rather than accessing additional characters from the keyboard layout.
Thanks! Do you consider adding an option to stop interpreting Command as Alt? On Thu, Oct 10, 2013 at 1:30 AM, Ken Thomases k...@codeweavers.com wrote: --- dlls/winemac.drv/cocoa_window.m | 22 -- dlls/winemac.drv/macdrv_cocoa.h |2 ++ dlls/winemac.drv/macdrv_main.c |7 +++ 3 files changed, 29 insertions(+), 2 deletions(-) -- С уважением, Филипп Крылов.
Re: winemac: Add registry settings to make Option keys send Alt rather than accessing additional characters from the keyboard layout.
On Oct 9, 2013, at 4:49 PM, Phil Krylov wrote: Thanks! You're welcome. Do you consider adding an option to stop interpreting Command as Alt? I have not considered it. What would be gained? Do you want the Command key interpreted as the Windows key? Do you want something else to happen when Command is pressed? Cheers, Ken
Re: ddraw/tests: Use BOOL type where appropriate
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=2682 Your paranoid android. === wxppro (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === wvista (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w2008s64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w7pro64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag
Re: kernel32/tests: Add tests for job objects (try 7)
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=2683 Your paranoid android. === w864 (64 bit process) === process.c:2092: Test failed: Unexpected completion event: 6, 0158, 02F0
Re: msi/tests: Use BOOL type where appropriate (resend)
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=2667 Your paranoid android. === wvista (32 bit msi) === Timeout === w2008s64 (32 bit msi) === Timeout Failure running script in VM: network read timed out === w2008s64 (64 bit msi) === Timeout
Re: [1/3] xmllite: Use buffer offset instead of pointers
Nikolay Sivov nsi...@codeweavers.com writes: On 10/6/2013 19:06, Nikolay Sivov wrote: It's normal to grow destination buffer, in this case all stored pointers will be trashed. This patch uses offsets from start of a buffer instead. Hi, Alexandre. Patches list shows a build failure for this one, and I don't see any failures on testbot for it so assuming something it fails on your machine. So what's the exact failure you get? It's compiler warnings, you have several uninitialized or unused variables. Please review your changes carefully. -- Alexandre Julliard julli...@winehq.org
Re: winemac.drv: add fullscreen mode support for Mac OS X 10.7+
Hi, I finally got around to working on support for Cocoa full-screen mode in the Mac driver, based on the work of Kevin Eaves. I've attached a new patch. This patch can only be applied on top of the other Mac driver patches I just submitted to wine-patches. Some changes from Kevin's original, in no particular oder: * I have not used the user32 hack to increase the max tracking size and let windows grow so their non-frame area covers the screen. Instead, the call to SetWindowPos() that results from a WINDOW_FRAME_CHANGED event uses SWP_NOSENDCHANGING for Cocoa-full-screen windows. That prevents any immediate modification of the new window rect to be within the max tracking size. However, some programs (e.g. Guild Wars) end up moving the window again shortly afterward and then it gets constrained. This results in a window that doesn't quite fill the screen, showing a plain background around the edges. This isn't ideal. As previously discussed, this may require a new driver entry point to allow it to override the size limits. (Although I got slapped down for trying to add a similar entry point for some other work.) * Cocoa understandably refuses to minimize a window that's in full-screen mode. So, if Win32-land tries to programmatically minimize a full-screen window, Cocoa just immediately tells it that it's been unminimized. This shouldn't come up much. (One can access a window's system menu using the keyboard to test.) * We can't distinguish the program trying to make a window Win32 full-screen vs. it merely echoing back the frame set by Cocoa full-screen. So, we never consider a window to be in Win32 full-screen mode if it's in Cocoa full-screen mode. That means that the menu and Dock auto-unhide. Many (most?) apps will modify the window style in addition to just setting the frame such that it becomes incompatible with Cocoa full-screen mode. In that case, the window is first taken out of Cocoa full-screen and then put into Win32 full-screen mode. The menu and Dock are properly hidden, but the window went back to its original space, which may not be what the user wants. * I have added the standard menu item for controlling Cocoa full-screen, Enter Full Screen, to the Window menu. Cocoa automatically renames that to Exit Full Screen and back as the window enters and exits full-screen mode. As with other items in the Mac menus, I don't allow keyboard shortcuts that don't include Option among the modifiers. So, I've used Command-Option-Control-F instead of just Command-Control-F. * The menu item and the window widget are properly disabled when the window is disabled. * The maximum tracking size set by the app for the window is respected in full-screen mode. If the app leaves the default max tracking size alone, then the full-screen size is unconstrained (and so fills the screen) even though the Win32 default is slightly too small to allow that. * If the app programmatically changes the window rect while the window is in Cocoa full-screen mode, that change is honored. This may end up looking a bit odd, but is necessary for correctness. Furthermore, the changed rect is maintained as the window exits full-screen mode, which is not what Cocoa would normally do. (Cocoa restores the window to the size and position it had before entering full-screen.) This is necessary when, for example, a game switches from windowed (in Cocoa full-screen mode) to Win32 full-screen. It will often change the window style in such a way that forces it out of Cocoa full-screen and changes its size to fill the screen. We don't want Cocoa negating that size change as it transitions out of Cocoa full-screen mode. Programmatic changes of the window rect that occur during and shortly after the transition into full-screen are not interpreted as setting the frame that should be restored when exiting full-screen mode. Those are probably just responses from Wine and the app to the changes that Cocoa has initiated. * I set NSWindowCollectionBehaviorFullScreenAuxiliary on any windows which don't get NSWindowCollectionBehaviorFullScreenPrimary. I'm not certain that this is right. That flag is not as clearly documented as I would like. My intent is to allow other Wine windows to share the space with a full-screen-primary window. * WS_EX_TOOLWINDOW windows (utility windows, in Cocoa parlance) are not eligible for Cocoa full-screen. This means that they get NSWindowCollectionBehaviorFullScreenAuxiliary as per the previous point, so they can share a space with a full-screen primary window. * I have left out any attempt to reconcile Cocoa full-screen with changes to the display mode which result in the displays being captured. I don't know of an app which does that while leaving its window eligible for Cocoa full-screen, although I haven't tested many yet. I invite everybody who's interested to test and/or review. Cocoa full-screen was introduced
Re: [PATCH 3/5] wined3d: Handle sRGB_decode when reading the sampler state.
On 8 October 2013 00:27, Stefan Dösinger ste...@codeweavers.com wrote:
diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
index 52eac16..eb8ca7e 100644
--- a/dlls/wined3d/surface.c
+++ b/dlls/wined3d/surface.c
@@ -5608,8 +5608,6 @@ HRESULT surface_load_location(struct wined3d_surface
*surface, DWORD location, c
}
}
-if (location == SFLAG_INSRGBTEX
gl_info-supported[EXT_TEXTURE_SRGB_DECODE])
-location = SFLAG_INTEXTURE;
if (surface-flags location)
{
@@ -5671,12 +5669,6 @@ HRESULT surface_load_location(struct wined3d_surface
*surface, DWORD location, c
surface_evict_sysmem(surface);
}
-if (surface-flags (SFLAG_INTEXTURE | SFLAG_INSRGBTEX)
- gl_info-supported[EXT_TEXTURE_SRGB_DECODE])
-{
-surface-flags |= (SFLAG_INTEXTURE | SFLAG_INSRGBTEX);
-}
-
return WINED3D_OK;
}
This change seems good on its own, as far as I can tell all callers
already handle this correctly. I'm less sure about the other changes,
the texture code seems like the right place to handle
EXT_texture_sRGB_decode.
Re: riched20: Set control content in WM_CREATE message
On Sat, 05 Oct 2013 14:54:07 +0200, Piotr Caban wrote:
+ if (!(editor-styleFlags ES_MULTILINE))
+ {
+len = 0;
+while(textW[len] != '0' textW[len] != '\r' textW[len] != '\n')
+ len++;
+ }
Although this patch has been committed as
e660bf676c111ce20d9e868280094f1c5bb81c79,
I doubt that it works properly. Did you mean '\0' or 0?
Regards,
Akihiro Sagawa
Re: riched20: Set control content in WM_CREATE message
Hi Akihiro,
On 10/08/13 12:51, Akihiro Sagawa wrote:
On Sat, 05 Oct 2013 14:54:07 +0200, Piotr Caban wrote:
+ if (!(editor-styleFlags ES_MULTILINE))
+ {
+len = 0;
+while(textW[len] != '0' textW[len] != '\r' textW[len] != '\n')
+ len++;
+ }
Although this patch has been committed as
e660bf676c111ce20d9e868280094f1c5bb81c79,
I doubt that it works properly. Did you mean '\0' or 0?
I meant to check for terminating null-character. I'll fix it.
Thanks,
Piotr
Re: [1/3] xmllite: Use buffer offset instead of pointers
On 10/8/2013 10:56, Alexandre Julliard wrote: Nikolay Sivov nsi...@codeweavers.com writes: On 10/6/2013 19:06, Nikolay Sivov wrote: It's normal to grow destination buffer, in this case all stored pointers will be trashed. This patch uses offsets from start of a buffer instead. Hi, Alexandre. Patches list shows a build failure for this one, and I don't see any failures on testbot for it so assuming something it fails on your machine. So what's the exact failure you get? It's compiler warnings, you have several uninitialized or unused variables. Please review your changes carefully. Okay, will do. Strangely I see no warnings here, but that's probably a different gcc version.
Re: [PATCH 3/5] wined3d: Handle sRGB_decode when reading the sampler state.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-10-08 12:06, schrieb Henri Verbeet:
On 8 October 2013 00:27, Stefan Dösinger ste...@codeweavers.com
wrote:
diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
index 52eac16..eb8ca7e 100644 --- a/dlls/wined3d/surface.c +++
b/dlls/wined3d/surface.c @@ -5608,8 +5608,6 @@ HRESULT
surface_load_location(struct wined3d_surface *surface, DWORD
location, c } }
-if (location == SFLAG_INSRGBTEX
gl_info-supported[EXT_TEXTURE_SRGB_DECODE]) -location =
SFLAG_INTEXTURE;
if (surface-flags location) { @@ -5671,12 +5669,6 @@ HRESULT
surface_load_location(struct wined3d_surface *surface, DWORD
location, c surface_evict_sysmem(surface); }
-if (surface-flags (SFLAG_INTEXTURE | SFLAG_INSRGBTEX) -
gl_info-supported[EXT_TEXTURE_SRGB_DECODE]) -{ -
surface-flags |= (SFLAG_INTEXTURE | SFLAG_INSRGBTEX); -} -
return WINED3D_OK; }
This change seems good on its own, as far as I can tell all
callers already handle this correctly.
Are you sure? E.g. if a texture is used with srgb=true and sRGB_decode
is supported, wined3d_texture_bind sets WINED3D_TEXTURE_IS_SRGB. If
the application later calls PreLoad manually, texture2d_preload is
called with SRGB_ANY. Because of the set IS_SRGB flag it chooses to
load the srgb copy. It correctly uses the rgb texture structure and
binds the rgb GL texture, but still passes srgb=true to
surface_load(), which results in SFLAG_INSRGBTEX being passed to
surface_load_location, even though we want to load the RGB copy.
I'll see if I can simplify the sRGB_decode handling while still
keeping it in the texture.
Patches 4 and 5 should apply without this one by the way.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSU/AfAAoJEN0/YqbEcdMwIP8P/iJUb9d3dfTQgdDAYNSx0fFc
wp7tJZSZKDNlSLz8oTNx7k2Lmcv7ZSInce+R1oaGxS7QjkhxD7U25CdnvgaXV+Oy
IInOFuauZ7m6zO+FfBbHd9ujM1pC1Mi7BtsE59LNypJT9ym6iqe2MLocLUjDCfbL
koro3I3rzjkMb3XVUQapMevobYBr0jfl3G3q7zirrVuh1fYnL3a1Ge4ckIGsRneL
98ZjmcQyfT8lo9zxtwXPTOR23j1oLnJDNWhn63he1sX6Vg7XQvPZwszXwbN30Jof
CjbrTzBmaKq/yY4jXnffu84tDygvWFr0a9sklX7qtaGd4cNBaiSscR6gBAgvZQdI
1533llMChhOqIUBrS5i8d3t24DLdAzd6PiD4LBCjJXzqfTiqWp3JjChR9FUvq+P1
G5gEldxF+MHPXKhZgpq1MoAy13NDYAFNT/EZSgIH/yRGcm9qVTnI98A6gFZnvel4
DQ3p05mMN4dSvGsQJt/l42k8I5IT1nYqetE1ybZd/45LgHKyjYc80z8lt6f0fhrS
j9KtY3Pu6Ks8hIjsIrnVPX7SSbiaNzytEwTpECXsmnB6T2Co+d5YOYzKmWLIqOqL
ZSTBkStiBzfxi+2KWlnfUHzWmOthaPo98ZRsiwtaux9W+8xvIDMnWD5x51EPlcjt
ca93bMIW9i8aPNOOMeKb
=dp6t
-END PGP SIGNATURE-
Re: [PATCH 3/5] wined3d: Handle sRGB_decode when reading the sampler state.
On 8 October 2013 13:44, Stefan Dösinger stefandoesin...@gmail.com wrote: Are you sure? E.g. if a texture is used with srgb=true and sRGB_decode is supported, wined3d_texture_bind sets WINED3D_TEXTURE_IS_SRGB. If the application later calls PreLoad manually, texture2d_preload is called with SRGB_ANY. Because of the set IS_SRGB flag it chooses to load the srgb copy. It correctly uses the rgb texture structure and binds the rgb GL texture, but still passes srgb=true to surface_load(), which results in SFLAG_INSRGBTEX being passed to surface_load_location, even though we want to load the RGB copy. Right. It should be pretty easy to fix that by taking EXT_TEXTURE_SRGB_DECODE into account in texture_srgb_mode() though.
Re: (try 6)[3/5] imm32: use thread data from target HWND
Aric Stewart a...@codeweavers.com writes:
@@ -1597,7 +1612,9 @@ BOOL WINAPI ImmGetConversionStatus(
HWND WINAPI ImmGetDefaultIMEWnd(HWND hWnd)
{
HWND ret;
-IMMThreadData* thread_data = IMM_GetThreadData(0);
+IMMThreadData* thread_data = IMM_GetThreadDataForWindow(hWnd);
+if (!thread_data)
+return NULL;
if (thread_data-hwndDefault == NULL)
thread_data-hwndDefault = CreateWindowExW( WS_EX_TOOLWINDOW,
szwIME, NULL, WS_POPUP, 0, 0, 1, 1, 0, 0, 0, 0);
It doesn't seem right to create the default window from a different
thread.
--
Alexandre Julliard
julli...@winehq.org
Wrong status of gdi32
I found this page http://www.nirsoft.net/dll_information/windows8/gdi32_dll.html shows that gdi32 dll has more than 800 functions,but the spec file has only 500 .
Re: gdi32/tests: Skip linked font like SimSun-ExtB in fixed-pitch font selection.
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=2669 Your paranoid android. === wvista (32 bit font) === The test timed out === w2008s64 (32 bit font) === Timeout Failure running script in VM: network read timed out
RE: binfmt support
From: xantare...@hotmail.com To: hverb...@gmail.com Subject: RE: binfmt support Date: Mon, 7 Oct 2013 11:47:05 + Date: Mon, 7 Oct 2013 12:23:30 +0200 Subject: Re: binfmt support From: hverb...@gmail.com To: xantare...@hotmail.com CC: wine-devel@winehq.org On 7 October 2013 12:06, xantares 09 xantare...@hotmail.com wrote: ... I don't see a reason why to not include it at the wine level instead of every linux distros, see: https://github.com/xantares/wine/commit/76ebd5d29effaf4b6b39ceecb689f7008bf6b376 What do you think ? Ignoring the discussion if we want this or not for the moment, I'd guess this would break as soon as you pass something other than /usr for --prefix to configure. Yes, It'll only work when prefix=/usr, which is always what happens when building packaging. This is what we want ; we still want to honor the prefix var. x.
Re: Wrong status of gdi32
Some of those are probably Wine-specific, and/or are forwarded from other DLLs. On Oct 8, 2013, at 8:35 AM, Akira Nakagawa matyapir...@gmail.com wrote: I found this page shows that gdi32 dll has more than 800 functions,but the spec file has only 500 .
Re: Wrong status of gdi32
On Tue, Oct 8, 2013 at 11:54 AM, C.W. Betts computer...@hotmail.com wrote: Some of those are probably Wine-specific, and/or are forwarded from other DLLs. On Oct 8, 2013, at 8:35 AM, Akira Nakagawa matyapir...@gmail.com wrote: I found this page shows that gdi32 dll has more than 800 functions,but the spec file has only 500 . That info is from the windows 8 dll, not wine's. Wine doesn't implement the full win32 API, only what is needed to run applications. If you've got an application that doesn't run because of a missing gdi32 function, please report it to bugzilla: https://bugs.winehq.org -- -Austin
Re: [PATCH 5/5] user32: Implement better stub of OpenInputDesktop.
Hello, this patch is in pending status, is there any way I can improve it? IMO there is no way to 'correctly' implement OpenInputDesktop before implementing SwitchDesktop, as far as SwitchDesktop is a stub, it is safe to assume that OpenInputDesktop will always return either NULL or Winsta0/Default, that is what the patch does and what the tests in [PATCH 3/5] shows.. It is not trivial to implement SwitchDesktop, also I don't know any real world app needing SwitchDesktop except some virtual desktop manager, so I'm not sure it is worth to spend time on implementing SwitchDesktop. However, OpenInputDesktop is needed by multiple apps (TeamViewer, QQ International, Inspect tool from Windows Platform SDK as bug 12067), is it acceptable to submit such a 'better stub' to Wine and leaving SwitchDesktop as a stub? Any comment is great appreciated! On Tue, Oct 8, 2013 at 11:41 AM, Qian Hong qh...@codeweavers.com wrote: Fixed http://bugs.winehq.org/show_bug.cgi?id=12067 , let QQ users happy :) --- dlls/user32/tests/winstation.c | 22 -- dlls/user32/winstation.c | 22 +++--- 2 files changed, 19 insertions(+), 25 deletions(-) -- Regards, Qian Hong - http://www.codeweavers.com
Re: [PATCH] d3dx9: Move object initialization into a separate function.
Hi Rico, 2013/10/8 Rico Schüller kgbric...@web.de: Hi, this moves the object initialization into a separate function, so it could be used for strings and resources. It also removes the STATE_TYPE as we could distinguish the types at the object level. 1. When an object has a destination, it points to another shader variable. This was state ST_PARAMETER. 2. If a variable has something in data, it is fxlc, shader (preshader) or a string. This was state ST_CONSTANT and ST_FXLC. 3. If it has both (destination and data), it points to an array of shader variables. The name is in the destination, the index could be calculated with the data. This will be added in a later patch. There's still the issue of distinguishing between ST_CONSTANT and ST_FXLC, checking object_id and type might cover that though. Also saving the destination parameter in the object gains some speed when we need to access the variable as we don't need to run get_parameter_by_name() each time we need the variable ... I'm not sure storing additional info into the objects is the right thing to do. Take a look at the D3DXFX_NOT_CLONEABLE flag from http://msdn.microsoft.com/en-us/library/windows/desktop/bb172855%28v=vs.85%29.aspx. Notice that GetPassDesc() doesn't return the shader data if the object was created with the flag. What I've been thinking is that it simply can't because the original shader data, stored in an object, were freed after parsing. While nothing forces us to do the same (except probably avoiding to use more memory than strictly necessary) I think it's better not to put additional stuff into the objects or generally assume that the objects are still available after parsing. That means creating the shaders and the strings at parse time or right after that and storing any additional required information (e.g. preshader) in the parameter. So, directly storing the referenced parameter is a good idea but I'd prefer that pointer to be in d3dx_parameter. Cheers Rico --- dlls/d3dx9_36/effect.c | 98 ++ 1 Datei geändert, 34 Zeilen hinzugefügt(+), 64 Zeilen entfernt(-) Cheers, Matteo
Re: ws2_32/tests: Use BOOL type where appropriate
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=2674 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (bc): unexpectedly at the OOB mark: 0 sock: unhandled exception c005 at 71AB8D62 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (2c8): unexpectedly at the OOB mark: 0 === w7pro64 (32 bit sock) === sock.c:509: Test failed: oob_server (8a4): unexpectedly at the OOB mark: 0 sock.c:519: Test failed: oob_server (8a4): unexpectedly at the OOB mark: 0 === w864 (32 bit sock) === sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for telnet: 11004 sock.c:1740: Test failed: getservbyname could not retrieve information for domain:
binfmt support
Hello, I made a patch to add a configuration file to be picked up by binfmt to allow to associate windows executables to wine. As binfmt is now a part of systemd in most linux disttributions: http://www.freedesktop.org/software/systemd/man/systemd-binfmt.service.html ... I don't see a reason why to not include it at the wine level instead of every linux distros, see: https://github.com/xantares/wine/commit/76ebd5d29effaf4b6b39ceecb689f7008bf6b376 What do you think ? x.
Re: binfmt support
On 7 October 2013 12:06, xantares 09 xantare...@hotmail.com wrote: ... I don't see a reason why to not include it at the wine level instead of every linux distros, see: https://github.com/xantares/wine/commit/76ebd5d29effaf4b6b39ceecb689f7008bf6b376 What do you think ? Ignoring the discussion if we want this or not for the moment, I'd guess this would break as soon as you pass something other than /usr for --prefix to configure.
Re: msvcrt: add support for _chsize_s (try #2)
Hi,
On 10/06/13 00:45, morphiend wrote:
+ * _chsize_s (MSVCRT.@)
+ */
+int CDECL MSVCRT__chsize_s(int fd, __int64 size)
+{
+LARGE_INTEGER cur, pos;
+LARGE_INTEGER temp = { 0 };
This causes compilation warnings. There's also a trailing space in this
line.
+TRACE((fd=%d, size=%lld)\n, fd, size);
You can't print 64-bit numbers this way, it's not portable. You can use
wine_dbgstr_longlong function.
+handle = msvcrt_fdtoh(fd);
+if (!MSVCRT_CHECK_PMT_ERR(handle == INVALID_HANDLE_VALUE, MSVCRT_EBADF) ||
+!MSVCRT_CHECK_PMT_ERR(size 0, MSVCRT_EINVAL))
You're validating parameters incorrectly. Did you test this patch?
+{
+ret = SetEndOfFile(handle);
+if (!ret)
+{
+msvcrt_set_errno(GetLastError());
+ret = *MSVCRT__errno();
+}
This causes the _chsize_s function to return TRUE in case of success.
+ /* restore the file pointer */
+ MSVCRT__lseek(fd, cur.QuadPart, SEEK_SET);
MSVCRT__lseek takes LONG as second argument.
Cheers,
Piotr
Re: [PATCH 3/3] msvcrt: Add support for vtordispex demangling
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=2650
Your paranoid android.
=== wxppro (32 bit cpp) ===
cpp.c:1328: Test failed: 124: Got name [thunk]: __thiscall
CView::`vcall'{392,{flat}}'
cpp.c:1331: Test failed: 124: Expected [thunk]: __thiscall
CView::`vcall'{392,{flat}}' }'
cpp.c:1328: Test failed: 125: Got name
?_dispatch@_impl_Engine@SalomeApp@@$R4CE@BA@PPPM@7AE_NAAVomniCallHandle@@@Z
cpp.c:1331: Test failed: 125: Expected [thunk]:public: virtual bool __thiscall
SalomeApp::_impl_Engine::_dispatch`vtordispex{36,16,4294967292,8}' (class
omniCallHandle )
Re: [PATCH 2/3] msvcrt: Add support for vcall thunks demangling
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=2649
Your paranoid android.
=== wxppro (32 bit cpp) ===
cpp.c:1326: Test failed: 124: Got name [thunk]: __thiscall
CView::`vcall'{392,{flat}}'
cpp.c:1329: Test failed: 124: Expected [thunk]: __thiscall
CView::`vcall'{392,{flat}}' }'
Re: [PATCH 2/3] msvcrt: Add support for vcall thunks demangling (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
https://newtestbot.winehq.org/JobDetails.pl?Key=2651
Your paranoid android.
=== wxppro (32 bit cpp) ===
cpp.c:1329: Test failed: 125: Got name
?_dispatch@_impl_Engine@SalomeApp@@$R4CE@BA@PPPM@7AE_NAAVomniCallHandle@@@Z
cpp.c:1332: Test failed: 125: Expected [thunk]:public: virtual bool __thiscall
SalomeApp::_impl_Engine::_dispatch`vtordispex{36,16,4294967292,8}' (class
omniCallHandle )
Re: riched20: Set control content in WM_CREATE message
Piotr Caban pi...@codeweavers.com writes: --- dlls/riched20/editor.c | 21 + dlls/riched20/tests/editor.c | 38 ++ 2 files changed, 59 insertions(+) It doesn't work: ../../../tools/runtest -q -P wine -M riched20.dll -T ../../.. -p riched20_test.exe.so txtsrv.c touch txtsrv.ok wine: Unhandled page fault on read access to 0x0024 at address 0x7ac23e94 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x0024 in 32-bit code (0x7ac23e94). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7ac23e94 ESP:0032f290 EBP:0032fb98 EFLAGS:00010246( R- -- I Z- -P- ) EAX: EBX:7ac58c00 ECX:0032fc80 EDX:003338e8 ESI:003338e8 EDI:0001 Stack dump: 0x0032f290: 0032fc80 0x0032f2a0: 0001 00333428 0x0032f2b0: 4d430002 0008 0004 7bc3c8e3 0x0032f2c0: 00333558 00333550 7bc3c8e3 0x0032f2d0: 0780 04b0 0032f300 6890a34c 0x0032f2e0: 001f 0032f318 688bd210 Backtrace: =0 0x7ac23e94 ME_HandleMessage+0x32d4(editor=0x3338e8, msg=0x1, wParam=0, lParam=0, unicode=0x1, phresult=0x32fbdc) [/home/julliard/wine/wine/dlls/riched20/editor.c:4029] in riched20 (0x0032fb98) 1 0x7ac3d3ab CreateTextServices+0x11a(pUnkOuter=couldn't compute location, pITextHost=couldn't compute location, ppUnk=couldn't compute location) [/home/julliard/wine/wine/dlls/riched20/txtsrv.c:417] in riched20 (0x0032fbf8) 2 0x686569cb func_txtsrv+0x2fa() [/home/julliard/wine/wine/dlls/riched20/tests/txtsrv.c:864] in riched20_test (0x0032fd38) 3 0x6862a5a7 main+0x386(argc=is not available, argv=is not available) [/home/julliard/wine/wine/dlls/riched20/tests/../../../include/wine/test.h:570] in riched20_test (0x0032fe08) 4 0x68657e30 __wine_spec_exe_entry+0x7f(peb=couldn't compute location) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in riched20_test (0x0032fe58) 5 0x7b85f36c call_process_entry+0xb() in kernel32 (0x0032fe78) 6 0x7b86054b start_process+0x6a(peb=couldn't compute location) [/home/julliard/wine/wine/dlls/kernel32/process.c:1085] in kernel32 (0x0032feb8) 7 0x7bc7fe70 call_thread_func_wrapper+0xb() in ntdll (0x0032fed8) 8 0x7bc82d7d call_thread_func+0x7c(entry=0x7b8604e0, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2602] in ntdll (0x0032ffa8) 9 0x7bc7fe4e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 10 0x7bc54a1e start_process+0x1d(kernel_start=0x7b8604e0) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2694] in ntdll (0x0032ffe8) 11 0x6803128d wine_call_on_stack+0x1c() in libwine.so.1 (0x) 12 0x6803134b wine_switch_to_stack+0x2a(func=0x7bc54a00, arg=0x7b8604e0, stack=0x33) [/home/julliard/wine/wine/libs/wine/port.c:59] in libwine.so.1 (0xff8b7288) 13 0x7bc5a557 LdrInitializeThunk+0x3a6(kernel_start=couldn't compute location, unknown2=couldn't compute location, unknown3=couldn't compute location, unknown4=couldn't compute location) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2750] in ntdll (0xff8b72f8) 14 0x7b866ac0 __wine_kernel_init+0xbbf() [/home/julliard/wine/wine/dlls/kernel32/process.c:1257] in kernel32 (0xff8b8208) 15 0x7bc5ac23 __wine_process_init+0x182() [/home/julliard/wine/wine/dlls/ntdll/loader.c:2959] in ntdll (0xff8b8298) 16 0x6802eeda wine_init+0x2b9(argc=0x3, argv=0xff8b87d4, error=, error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:952] in libwine.so.1 (0xff8b82f8) 17 0x7bf00d3b main+0x7a(argc=is not available, argv=is not available) [/home/julliard/wine/wine/loader/main.c:237] in wine-loader (0xff8b8738) 18 0x682518c5 __libc_start_main+0xf4() in libc.so.6 (0x) 0x7ac23e94 ME_HandleMessage+0x32d4 [/home/julliard/wine/wine/dlls/riched20/editor.c:4029] in riched20: movl 0x24(%eax),%eax 4029: (void*)((CREATESTRUCTA*)lParam)-lpszName); -- Alexandre Julliard julli...@winehq.org
Re: mscoree: Partial implement ICLRMetaHost RequestRuntimeLoadedNotification (try 2)
HRESULT CLRMetaHost_CreateInstance(REFIID riid, void **ppobj)
{
+GlobalCLRMetaHost.callback = NULL;
return ICLRMetaHost_QueryInterface(GlobalCLRMetaHost.ICLRMetaHost_iface,
riid, ppobj);
}
I don't think we should be changing global state every time someone
creates an instance of this object. We can't assume it only happens
once.
Re: [1/3] xmllite: Use buffer offset instead of pointers
On 10/6/2013 19:06, Nikolay Sivov wrote: It's normal to grow destination buffer, in this case all stored pointers will be trashed. This patch uses offsets from start of a buffer instead. Hi, Alexandre. Patches list shows a build failure for this one, and I don't see any failures on testbot for it so assuming something it fails on your machine. So what's the exact failure you get?
Re: msi/tests: Use BOOL type where appropriate
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=2660 Your paranoid android. === wvista (32 bit msi) === The test timed out === w2008s64 (32 bit msi) === The test timed out === w7pro64 (32 bit msi) === No test summary line found Failure running script in VM: network read timed out === w2008s64 (64 bit msi) === Timeout === w7pro64 (64 bit msi) === Timeout
Re: msvcrt: add support for _chsize_s (try #2)
On Sun, Oct 6, 2013 at 12:45 AM, morphiend morphi...@gmail.com wrote: This patch adds the _chsize_s() to the mscvrt and corresponding mscvr*s. This was tested on Ubuntu 12.10 using IDA 6.4 as a test application. Without the implementation of _chsize_s(), certain binaries caused an internal crash of IDA. This patch fixed that crash. You need to use your real name when sending patches. -- Frédéric Delanoy
Re: msvcrt: add support for _chsize_s (try #2)
On 6 October 2013 20:32, Frédéric Delanoy frederic.dela...@gmail.com wrote: On Sun, Oct 6, 2013 at 12:45 AM, morphiend morphi...@gmail.com wrote: This patch adds the _chsize_s() to the mscvrt and corresponding mscvr*s. This was tested on Ubuntu 12.10 using IDA 6.4 as a test application. Without the implementation of _chsize_s(), certain binaries caused an internal crash of IDA. This patch fixed that crash. You need to use your real name when sending patches. Well, it is actually there in the patch.
Re: d3d9: update locked_rect only if wined3d_surface_map succeeded
Stefan Dösinger stefandoesin...@gmail.com writes: Am 2013-10-03 21:45, schrieb Henri Verbeet: On 3 October 2013 21:16, Lasse Rasinen lrasi...@iki.fi wrote: According to debugging output, Artemis Spaceship Bridge Simulator 2.0 calls LockRect twice on the same texture (for whatever reason) and crashes. http://bugs.winehq.org/show_bug.cgi?id=34271 This change prevents the locked_rect being overwritten with garbage in that case, and the game no longer crashes. I think this patch makes sense, but could you please add a test case as well? Ideally we'd also have similar tests for other resources (i.e., textures, volumes, vertex buffers, index buffers) and D3D versions (ddraw, d3d8), but that's not a strict requirement. I'd expect that the correct behavior is to set pBits to NULL. test_volume_locking() demonstrates this for volumes. That appears to work too, thanks. I'll have a look at the existing tests; let's see what I come up with. -- Lasse Rasinen lrasi...@iki.fi
Re: kernel32/tests: Fix compilation on systems that don't support nameless unions.
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=2634 Your paranoid android. === w7pro64 (64 bit comm) === comm.c:861: Test failed: WaitCommEvent failed with a timeout comm.c:872: recovering after WAIT_TIMEOUT... comm.c:883: Test failed: WaitCommEvent error 0 comm.c:885: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:889: WaitCommEvent for EV_TXEMPTY took 1014 ms (timeout 1000) comm.c:891: Test failed: WaitCommEvent used 1014 ms for waiting
Re: mshtml/tests: Fix compilation on systems that don't support nameless unions.
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=2637 Your paranoid android. === wxppro (32 bit htmldoc) === htmldoc.c:2898: Test failed: mon(0026BF78) != exmon(00269670) htmldoc.c:7601: Test failed: mon(0026BF78) != exmon(00269670) htmldoc.c:5978: Test failed: mon(0026BF78) != exmon(00269670) htmldoc.c:2898: Test failed: mon(002ADFE8) != exmon(00265FE8) htmldoc.c:7601: Test failed: mon(002ADFE8) != exmon(00265FE8) htmldoc.c:5978: Test failed: mon(002ADFE8) != exmon(00265FE8) === wvista (32 bit htmldoc) === No test summary line found === w7pro64 (32 bit htmldoc) === No test summary line found
Re: [PATCH 3/3] winemac: Tell Wine when Cocoa has brought a window to the front.
On Oct 4, 2013, at 12:17 AM, Ken Thomases wrote: --- dlls/winemac.drv/cocoa_app.m| 8 ++-- dlls/winemac.drv/cocoa_window.h | 1 + dlls/winemac.drv/cocoa_window.m | 16 +--- dlls/winemac.drv/event.c| 5 + dlls/winemac.drv/macdrv.h | 1 + dlls/winemac.drv/macdrv_cocoa.h | 1 + dlls/winemac.drv/window.c | 12 7 files changed, 39 insertions(+), 5 deletions(-) 0003-winemac-Tell-Wine-when-Cocoa-has-brought-a-window-to.patch Don't commit this one. It has caused some strange behavior on Mavericks. The other two in the series are OK and useful independently of this one. -Ken
Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.
On 4 October 2013 00:03, Stefan Dösinger ste...@codeweavers.com wrote:
@@ -2883,10 +2886,6 @@ HRESULT CDECL wined3d_surface_set_mem(struct
wined3d_surface *surface, void *mem
/* Now the surface memory is most up do date. Invalidate drawable
and texture. */
surface_validate_location(surface, SFLAG_INSYSMEM);
surface_invalidate_location(surface, ~SFLAG_INSYSMEM);
-
-/* For client textures OpenGL has to be notified. */
-if (surface-flags SFLAG_CLIENT)
-surface_release_client_storage(surface);
}
else if (surface-flags SFLAG_USERPTR)
{
@@ -2899,9 +2898,6 @@ HRESULT CDECL wined3d_surface_set_mem(struct
wined3d_surface *surface, void *mem
surface-resource.allocatedMemory = NULL;
surface-flags = ~(SFLAG_USERPTR | SFLAG_INSYSMEM);
-if (surface-flags SFLAG_CLIENT)
-surface_release_client_storage(surface);
-
surface_prepare_system_memory(surface);
}
What makes this safe, and why is it needed?
BiDi, Unicode 6.3 and Wine.
Hello, So Unicode 6.3 was just recently released. One of the things it features is an updated BIDI (Bidirectional) algorithm. This is revision 29 to the algorithm. (http://www.unicode.org/reports/tr9/tr9-29.html#Modifications) Looking at the code I moved from gdi32 to usp10, it looks like the existing code is based off of revision 17. This implementation was originally by Shachar and Maarten. I simply integrated it into uniscribe. I am tempted to update our code to match the revision 29 version of the algorithm. But this raises a question. Right now our code mostly correctly mimics Windows. It may be that I am not testing the correct edge cases that would reveal if windows is coded to a later version of the algorithm or not. But if we update to revision 29 then we will almost assuredly be using a later version of the algorithm. What is more important to us in this regard? Do we want to have the latest algorithm based on the unicode standard, or do we want to try to match the algorithm that Windows makes use of? Thanks! -aric
Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.
On 4 October 2013 15:02, Stefan Dösinger stefandoesin...@gmail.com wrote: Client storage only applies to GL textures, which won't be created for sysmem surfaces. I don't think that's necessarily true at the moment. In particular, ddraw blits can in principle cause a texture to be created for sysmem surfaces. There might be restrictions in the ddraw API that prevent this from happening in practice, but even if there are, we certainly don't enforce them.
Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.
Am 04.10.2013 um 15:28 schrieb Henri Verbeet hverb...@gmail.com: On 4 October 2013 15:02, Stefan Dösinger stefandoesin...@gmail.com wrote: Client storage only applies to GL textures, which won't be created for sysmem surfaces. I don't think that's necessarily true at the moment. In particular, ddraw blits can in principle cause a texture to be created for sysmem surfaces. There might be restrictions in the ddraw API that prevent this from happening in practice, but even if there are, we certainly don't enforce them. No codepath in wined3d_surface_blt will attempt to load a sysmem surface into a texture. fbo_blit_supported returns FALSE if src or destination are in sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills will go to a cpu side clear because of the INSYSMEM optimization. (This optimization is needed for a few other things to work correctly, but that's a different patch.)
Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.
Am 04.10.2013 um 15:51 schrieb Stefan Dösinger stefandoesin...@gmail.com: No codepath in wined3d_surface_blt will attempt to load a sysmem surface into a texture. fbo_blit_supported returns FALSE if src or destination are in sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills will go to a cpu side clear because of the INSYSMEM optimization. (This optimization is needed for a few other things to work correctly, but that's a different patch.) Fwiw, the other patches are independent of this patch.
Re: BiDi, Unicode 6.3 and Wine.
While I have no experience contributing code to wine itself so far, BiDi or not, I smell a high-level design choice here. If the new revision to the Unicode algorithm looks superior, my first idea would be to try rebasing the code on that and then explicitly overriding it for Windows quirks. I don't know enough about wine's code or performance issues to advocate when that redirection should take place. I suppose it could be done during compilation and linking, during runtime, or even by just hard-coding and commenting standards and quirks versions in the source. Mine's not the most informed opinion though so I would take it with a grain of salt. -Kyle On 10/04/2013 07:54 AM, Aric Stewart wrote: Hello, So Unicode 6.3 was just recently released. One of the things it features is an updated BIDI (Bidirectional) algorithm. This is revision 29 to the algorithm. (http://www.unicode.org/reports/tr9/tr9-29.html#Modifications) Looking at the code I moved from gdi32 to usp10, it looks like the existing code is based off of revision 17. This implementation was originally by Shachar and Maarten. I simply integrated it into uniscribe. I am tempted to update our code to match the revision 29 version of the algorithm. But this raises a question. Right now our code mostly correctly mimics Windows. It may be that I am not testing the correct edge cases that would reveal if windows is coded to a later version of the algorithm or not. But if we update to revision 29 then we will almost assuredly be using a later version of the algorithm. What is more important to us in this regard? Do we want to have the latest algorithm based on the unicode standard, or do we want to try to match the algorithm that Windows makes use of? Thanks! -aric
Re: [PATCH 2/2] advapi32: Don't cache HKCR if WOW64 redirection flags are set
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=2624 Your paranoid android. === wxppro (32 bit registry) === Timeout
Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.
On 4 October 2013 15:51, Stefan Dösinger stefandoesin...@gmail.com wrote: No codepath in wined3d_surface_blt will attempt to load a sysmem surface into a texture. fbo_blit_supported returns FALSE if src or destination are in sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills will go to a cpu side clear because of the INSYSMEM optimization. (This optimization is needed for a few other things to work correctly, but that's a different patch.) I guess that makes it ok in practice, but I'd still feel happier about this kind of patch if we actually enforced resource access flags first. (At which point you could also just check the access flags instead of the pool.)
Re: [PATCH 5/5] wininet: Added InternetLockRequestFile 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=2625 Your paranoid android. === w2008s64 (64 bit http) === http.c:3521: Test failed: HttpQueryInfo failed 0 === w7pro64 (64 bit http) === http.c:3521: Test failed: HttpQueryInfo failed 0
Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.
Am 04.10.2013 um 17:15 schrieb Henri Verbeet hverb...@gmail.com: I guess that makes it ok in practice, but I'd still feel happier about this kind of patch if we actually enforced resource access flags first. (At which point you could also just check the access flags instead of the pool.) My plan is to enforce this in resource_load_location similar to how it's currently done for volumes. That'd be at the end of my surface cleanup patchset though, and it'll need some additional work (downloading a texture to a bigger sysmem surface to handle get_front_buffer_data). I think my surface patches should work ok without the assumption that client storage and user memory are mutually exclusive, so feel free to skip this patch for now. The other 4 patches in this series should work ok. Some later patches in the big patchset need minor adjustments though.
Re: [3/3] ntdll: Add support for FILE_APPEND_DATA to NtWriteFile. Take 2.
Dmitry Timoshkov dmi...@baikal.ru writes:
@@ -979,6 +986,12 @@ NTSTATUS WINAPI NtWriteFile(HANDLE hFile, HANDLE hEvent,
goto done;
}
+if (append_write)
+{
+offset_eof.QuadPart = (LONGLONG)-1; /* FILE_WRITE_TO_END_OF_FILE
*/
+offset = offset_eof;
+}
+
Please add a test for the file position after the write, to show that
this is the correct behavior.
--
Alexandre Julliard
julli...@winehq.org
Re: BiDi, Unicode 6.3 and Wine.
Aric Stewart a...@codeweavers.com writes: Hello, So Unicode 6.3 was just recently released. One of the things it features is an updated BIDI (Bidirectional) algorithm. This is revision 29 to the algorithm. (http://www.unicode.org/reports/tr9/tr9-29.html#Modifications) Looking at the code I moved from gdi32 to usp10, it looks like the existing code is based off of revision 17. This implementation was originally by Shachar and Maarten. I simply integrated it into uniscribe. I am tempted to update our code to match the revision 29 version of the algorithm. But this raises a question. Right now our code mostly correctly mimics Windows. It may be that I am not testing the correct edge cases that would reveal if windows is coded to a later version of the algorithm or not. But if we update to revision 29 then we will almost assuredly be using a later version of the algorithm. What is more important to us in this regard? Do we want to have the latest algorithm based on the unicode standard, or do we want to try to match the algorithm that Windows makes use of? I'm not sure that there's any evidence that the existing version is identical to Windows. It's probably just what happened to be the current version when the code was written. As long as it passes reasonable tests, it shouldn't be an issue to use a more recent version. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 1/5] wined3d: Store valid locations in the resource.
On 3 October 2013 13:08, Stefan Dösinger ste...@codeweavers.com wrote: --- dlls/wined3d/volume.c | 46 +- dlls/wined3d/wined3d_private.h | 6 -- 2 files changed, 27 insertions(+), 25 deletions(-) What about surfaces and buffers?
Re: [PATCH 1/5] wined3d: Store valid locations in the resource.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-10-03 13:14, schrieb Henri Verbeet: On 3 October 2013 13:08, Stefan Dösinger ste...@codeweavers.com wrote: --- dlls/wined3d/volume.c | 46 +- dlls/wined3d/wined3d_private.h | 6 -- 2 files changed, 27 insertions(+), 25 deletions(-) What about surfaces and buffers? Will be updated as well. See http://www.winehq.org/pipermail/wine-devel/2013-October/101575.html for the surface part and more explanations. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSTVN9AAoJEN0/YqbEcdMw9hwP/insKmUabEOtn+87MOY8RSqw gEHY1dYyi8L+ECVcjJx/x7BzLGDDC8lfISWHQkVZ6RcF7X8TegVwxQwgJY1e1isM YD8ECNRW96mBgSumrvtLUJVvdOlOOW0HU9L4U7DvqXLTrc1n6toaCvALW2v+OyTz aZy2+5iRu6SL5zoTsdt5AAOVg/xqBaY1svnBvEAyDJ3w/ztPmLReMGaM95cLzStG 6NzPhg3nd4YCb2hHvpAXypM9PQLFgMAGqOIS/4PXIVa1N5sbnNABWs0tmqOeP8DJ Oul8vSsNysEViWdsRBvQFa9m3s5lvpY3RMXKdfWjQjjpDQv6Ii3f6D8xzEUnguI4 BrysvAkrz2dcQAdkLm2LmLIe9pCEbL+FHaFXjydgRWBLY7iK5Y68WMpVyyKA8SVv jYdd/e+hLu1IvYWRgSU9Z3tNBnIwTqZyrb6exwlsUztvkoMZvTKEGuDShnTvPLX5 FornFmxCYflneZO6fjFtI+y9OgAQLsdqCPKb6JzPlQS+d3baR1IZeY/j9/iS8U0I 0xknAEGZ63gVUWONJB55S6Kt7tSEjI7fTMZfKBPm+oDU36//2PxDtuA58K7aUnnG +dAOSz0Fndpnei7dZQSCSNyCwujWqetAdXK3n13uzHxL2QZIxWiHrEo8nqawVLWL wkzlLCqE9605fthCQYf6 =Q81u -END PGP SIGNATURE-
Re: [PATCH 1/5] wined3d: Store valid locations in the resource.
On 3 October 2013 13:22, Stefan Dösinger ste...@codeweavers.com wrote: Am 2013-10-03 13:14, schrieb Henri Verbeet: On 3 October 2013 13:08, Stefan Dösinger ste...@codeweavers.com wrote: --- dlls/wined3d/volume.c | 46 +- dlls/wined3d/wined3d_private.h | 6 -- 2 files changed, 27 insertions(+), 25 deletions(-) What about surfaces and buffers? Will be updated as well. See http://www.winehq.org/pipermail/wine-devel/2013-October/101575.html for the surface part and more explanations. It sounds like you have some ordering issues in that patch set.
Re: [PATCH 1/5] wined3d: Store valid locations in the resource.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-10-03 13:45, schrieb Henri Verbeet: On 3 October 2013 13:22, Stefan Dösinger ste...@codeweavers.com wrote: Will be updated as well. See http://www.winehq.org/pipermail/wine-devel/2013-October/101575.html for the surface part and more explanations. It sounds like you have some ordering issues in that patch set. Correct. Patches before patch 24 shouldn't be affected by that though. I didn't get around to splitting and recombining patch 24 and some later bugfixes yet due to other priorities. Unless you mean to imply that you disagree with the ordering of the first 23 patches, where the order is mostly a matter of opinion instead of technical constraints. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSTWsrAAoJEN0/YqbEcdMwXnMP/1mN/d6iy/pXtftkIEvLsDLb Av1zqQpPs92UU/H/TPlkQ0B2jMgBaefpuAsIWFc856lRjPUXUlbZ6cz17G502g7b cqn6idjqEqIpPfF5dQ+U3SY4mAznUI0mxWqGdiqKNyq1uuPA1PoUxS1zTIrK68sQ TXf4CgVsz0wObN7rEdpLUrGY+wPAG0PeNSCQaQsOMkvV5J0QpOHy++p9bOlV7W1K IiwpVdorT7G3ru0KMYVChdsPiFvEVE0uj+/6+b1oewaA3r2XIOKiMeCLhPGgOTnh jJxWfJA+MO3tI1RjUxXC1Pxl5fcuMTbr9saj01+WSfI/BMAnNnzdumo84yX8ME5l ypAu2UwXWSSU4cFPRx4ok/+iQ/JW533QoSZ50j4MevFl4OPAtFl+k8tfpdhfuaop tC/NuvB8SlPFLLsN1ELiBNWXyFdW5LGruTl9Fxb5in1XwQIxy/t4u1aS23cbU30K 3cYYCfk14nG6XWnAmjBq7I+gTWY55P34dIqf/q0bQPtHWUD31lP/Vdi++md8g+32 6FbMQm+/2NZfoX/fJQyRIaDQSnE0NIjpsRfEtKRPqZGehT3D2KbFJIaVJrh/X7w6 LShdXa4q7R+bQyHT6weg4nMcyoHfHDUokUctSgvAsUpVdT/0kMt/Z/kRlEvtcygi KTaXODUsfmXBin8sKlyt =3Dy9 -END PGP SIGNATURE-
Re: [PATCH 1/5] wined3d: Store valid locations in the resource.
On 3 October 2013 15:03, Stefan Dösinger ste...@codeweavers.com wrote: Am 2013-10-03 13:45, schrieb Henri Verbeet: It sounds like you have some ordering issues in that patch set. Correct. Patches before patch 24 shouldn't be affected by that though. I didn't get around to splitting and recombining patch 24 and some later bugfixes yet due to other priorities. Unless you mean to imply that you disagree with the ordering of the first 23 patches, where the order is mostly a matter of opinion instead of technical constraints. I don't think this patch makes sense before you actually unify the location management. In particular, after this patch you'd have location management in resources that really only does anything for volumes, while from the surface point of view you'd have duplicate location management.
Re: Looking for an icon for the Mac driver: generic program running under Wine
The window for that icon was made from a screenshot of a window from my desktop. The Wine glass was from a png on the WineHQ website. So there should be no copyright issues there, so long as Wine agrees to letting itself use it. I made it in icon composer which only supports up to 512x512 which is the max resolution supported in XCode's icon composer. A Mac-themed icon seems more appropriate in my opinion. I've cc'd Linda who might be willing to make one that's cleaned up and contains better reduced resolution versions, if that's the desired direction. Thanks, J On Wed, Oct 2, 2013 at 11:01 PM, Ken Thomases k...@codeweavers.com wrote: Hi, I have a need for a new icon in Wine and I'm hoping somebody with some graphics-design skills might be able to create it. The Mac driver attempts to extract an icon from the executable to use for the Dock icon of its process. This is also the icon that appears in the Command-Tab application switcher. This often works, but not always. When it doesn't, the Dock just uses the generic Unix executable icon from Mac OS X. You can see that here: http://i.imgur.com/b1JrMDJ.png. It's not very nice. I would prefer to have a Wine-specific generic program icon. Any graphic designer care to take on the task of creating such an icon? I'm told Wine has been using the Tango icons as the template for its. Tango provides application-x-executable.svg at http://cgit.freedesktop.org/tango/tango-icon-theme/tree/svg that might be suitable. That could be badged with the Wine glass logo to produce an icon for a program running under Wine. On the other hand, if this icon were to be used only by the Mac driver, it might be more appropriate to use a Mac-themed icon. Some time back, Jeremiah posted an archive of icons. http://www.winehq.org/pipermail/wine-devel/2013-February/098783.html That included one which had a miniature Mac window badged with the Wine glass logo. I'm not sure of the copyright/licensing situation with that icon. It's bitmap-only, not vector, but that might be fine for a Mac-only icon. It does have some issues with rough edges around the window, rather than a smooth alpha-blended edge. Although Mac app icons can go up to 1024x1024 pixels (512x512 points at 2x resolution for Retina displays), this icon would only appear in the Dock and the application switcher. So, it needn't be larger than 256x256 pixels (128x128@2x). Thanks, Ken
Re: kernel32: Add tests for job objects (try 4)
Andrew Cook aris...@gmail.com writes: +sprintf(buffer, \%s\ tests/process.c ignored \%s\, selfname, wait); + +IOPort = CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0, 1); +ok(IOPort != INVALID_HANDLE_VALUE, CreateIoCompletionPort (%d), GetLastError()); + +JobObject = pCreateJobObjectW(NULL, NULL); +ok(JobObject != INVALID_HANDLE_VALUE, CreateJobObject (%d)\n, GetLastError()); These functions don't return INVALID_HANDLE_VALUE. -- Alexandre Julliard julli...@winehq.org
Re: d3d9: update locked_rect only if wined3d_surface_map succeeded
On 3 October 2013 21:16, Lasse Rasinen lrasi...@iki.fi wrote:
According to debugging output, Artemis Spaceship Bridge Simulator 2.0
calls LockRect twice on the same texture (for whatever reason) and crashes.
http://bugs.winehq.org/show_bug.cgi?id=34271
This change prevents the locked_rect being overwritten with garbage in
that case, and the game no longer crashes.
I think this patch makes sense, but could you please add a test case
as well? Ideally we'd also have similar tests for other resources
(i.e., textures, volumes, vertex buffers, index buffers) and D3D
versions (ddraw, d3d8), but that's not a strict requirement.
+if (hr == WINED3D_OK) {
+locked_rect-Pitch = map_desc.row_pitch;
+locked_rect-pBits = map_desc.data;
+}
Minor style issue, this should be:
if (SUCCEEDED(hr))
{
...
}
Re: d3d9: update locked_rect only if wined3d_surface_map succeeded
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-10-03 21:45, schrieb Henri Verbeet: On 3 October 2013 21:16, Lasse Rasinen lrasi...@iki.fi wrote: According to debugging output, Artemis Spaceship Bridge Simulator 2.0 calls LockRect twice on the same texture (for whatever reason) and crashes. http://bugs.winehq.org/show_bug.cgi?id=34271 This change prevents the locked_rect being overwritten with garbage in that case, and the game no longer crashes. I think this patch makes sense, but could you please add a test case as well? Ideally we'd also have similar tests for other resources (i.e., textures, volumes, vertex buffers, index buffers) and D3D versions (ddraw, d3d8), but that's not a strict requirement. I'd expect that the correct behavior is to set pBits to NULL. test_volume_locking() demonstrates this for volumes. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSTdihAAoJEN0/YqbEcdMwFOoP/RJbSrIe02Zs+3kZ3orWZTW9 kYDUNQd1kBPE4FPn4XxRBN4n8imOylpNj5M8hrAVSUlXzHhYJ7r3MWCGL9p+Xgra ycYCN36u9eRMgo3LLzw3HH1z/D3qObwzHEgVZFa6UVgBfUqKxuWmbRLRm51uF9B+ YslkqGyX6d3+BqFO3Xw1h4AA+BxeEBmR/dCmMhEdzcRhgUPaCRjd0UiPnAD9SNLk 9hNbkmp6P5dfvz4fbYFmtbCiGwy0ma6BuyA9Oh925fQ7vcka6OHmIU78R5FU1zMF GEMQ9rNz/coWGWs+eFh0u09WXK3BlgN+cz8YTF/bH6iRazsyfuKNrmyVXXAyxG/c PuqTt4HhJ459KuFUGsa+he/VdqOKeoxj/h/0s/aNRnn/k6L5Coa0HUVT2BqOVi3e 4wLnHog5nwJzPMzCu89QZtJVtg9lCpfkRPPSMxt5YuM1SRoZFXCjSs9mms9TBhtt b41UK9Oy3bJVh16YdPxNj1AFpdXpngeK19jpjErH+nhXtjm6uOKinFsKYD/8L285 cRLvyND3SYK2JxyezAEEuUJlA95qKFZdcLqUPjj2ZAoXEeMCgVefIJIRPQ/znM8V vZHH1ejo0SvtcpidTa4LLCyccbUqTPl1BpSXPLbrRiTqwdIeDuWHNo/rTVRVLGBZ JmhUXEaVBE3Uuo+VzPbD =38ER -END PGP SIGNATURE-
