Re: user32/tests: Test edit control to WM_GETTEXT processing after WM_DESTROY
Please don't commit this test. Instead use or comment next try: user32: Destroy EDITSTATE structure in the WM_NCDESTROY message processing -- Best regards, Ilya Shpigor.
Re: shell32/tests: Fix Program Manager DDE Conformance Test Failures
You really don't want to skip this one as the api is supposed to create the window, but you can't be absolutely sure it is a failure, hence the error message being what it is. If you are going to skip the timeout if it fails, why bother checking for the window creation at all? The real question is what is the real worst case expected time to wait before failing because the window was not created? I upped it to 45 seconds. I could have implemented a window message thread to detect the window creation, but it doesn't change the problem. Window creation is not given a deadline. 10 seconds was obviously too short. Several machines failed on the first longer load with 10 seconds and a couple failed most of the timeouts with 10 seconds. I'd be more than willing to up the timeout longer, but if you really do encounter a failure, it makes the failed test take that much longer. - Mikey --- On Sat, 11/14/09, Nicolas Le Cam niko.le...@gmail.com wrote: From: Nicolas Le Cam niko.le...@gmail.com Subject: Re: shell32/tests: Fix Program Manager DDE Conformance Test Failures To: wine-devel@winehq.org Cc: fireswor...@yahoo.com Date: Saturday, November 14, 2009, 9:09 AM 2009/11/14 Mikey Alexander fireswor...@yahoo.com: Fixes a memory leak, non connection to the progman dde on early windows, and timeout problems with the conformance tests. --- dlls/shell32/tests/progman_dde.c | 25 + 1 files changed, 17 insertions(+), 8 deletions(-) Hi Mikey, There's also a test failure on localized Windows (see http://test.winehq.org/data/8a17a028b73d1ccc5b7ebaa9e135a1bfbf159615/2000_w2k-sp4-fr/shell32:progman_dde.html for example) because the window doesn't have the expected title. I tried to skip the ShowGroupTest call at line 510 (before your patch) but then the next call fails. Is there a better solution than skipping those two calls ? If not I'll just send a skipping patch. -- Nicolas Le Cam
Re: avifile bugfixes
Detlef Riekenberg wrote: On Di, 2009-11-10 at 00:43 +0100, Julius Schwartzenberg wrote: I will add tests to show this and submit the patches then. I created a test for avifil32 in June 2008, but it was not comitted. ( http://www.winehq.org/pipermail/wine-patches/2008-June/056310.html ) Thanks for the pointer. I was already wondering why there were no tests in the avifil32 directory. I'll keep this in mind. There are some tests that use avifile in winmm though. Julius
Working on avifil32, sudden non enough memory error
Hi,
I'm working on fixing some things in avifil32. Several problems should
be gone when using the attached four patches and most AVI files play
back properly.
With one file however (GOODTIME.AVI from the win95 cd) I get this error
after about a second:
err:heap:HEAP_ValidateInUseArena Heap 0x11: in-use arena 0x184420
next block has PREV_FREE flag
non enough memory
I have no idea where this comes from and why it happens. (It appears to
be unrelated to the memcpy call in avifile.c around line 1114.) With
+heap I also get this before the error:
HIGHPERF/GOODTIME.AVI: heap.c:403: HEAP_GetPtr: Controletest '0' faalt.
(the assert fails)
The whole output is here:
http://haar.student.utwente.nl/~julius/avifile-heaperr.log.gz
What could I try to figure out the cause of this problem? I can provide
both the file and my test program if necessary. Note that on MS Windows
XP it all works without problems.
Thanks in advance,
Julius
From a5fdf2316923e9b4fd254e571b5f70cb5a5ee87f Mon Sep 17 00:00:00 2001
From: Julius Schwartzenberg julius.schwartzenb...@gmail.com
Date: Sun, 8 Nov 2009 15:18:26 +0100
Subject: avifile: Fix header for audio stream
---
dlls/avifil32/avifile.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c
index 49e141f..4ecc6f6 100644
--- a/dlls/avifil32/avifile.c
+++ b/dlls/avifil32/avifile.c
@@ -1816,7 +1816,15 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This)
if (FAILED(hr))
return hr;
};
-
+ if (pStream-lpFormat != NULL pStream-sInfo.fccType ==
streamtypeAUDIO)
+ {
+ WAVEFORMATEX *wfx = pStream-lpFormat;
+ wfx-nBlockAlign = wfx-nChannels * wfx-wBitsPerSample / 8;
+ pStream-sInfo.dwSampleSize = wfx-nBlockAlign;
+ TRACE(Block size reset to %u, chan=%u bpp=%u\n, wfx-nBlockAlign,
wfx-nChannels, wfx-wBitsPerSample);
+ pStream-sInfo.dwScale = 1;
+ pStream-sInfo.dwRate = wfx-nSamplesPerSec;
+ }
if (mmioAscend(This-hmmio, ck, 0) != S_OK)
return AVIERR_FILEREAD;
}
--
1.6.3.3
From 84a0ee0327569c91c74d99be3c124c09cfc45cb9 Mon Sep 17 00:00:00 2001
From: Julius Schwartzenberg julius.schwartzenb...@gmail.com
Date: Sun, 8 Nov 2009 15:28:19 +0100
Subject: avifile: Fix header suggested buffersize
---
dlls/avifil32/avifile.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c
index 4ecc6f6..c40cbd9 100644
--- a/dlls/avifil32/avifile.c
+++ b/dlls/avifil32/avifile.c
@@ -1652,7 +1652,7 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This)
This-fInfo.dwCaps= AVIFILECAPS_CANREAD|AVIFILECAPS_CANWRITE;
This-fInfo.dwLength = MainAVIHdr.dwTotalFrames;
This-fInfo.dwStreams = MainAVIHdr.dwStreams;
- This-fInfo.dwSuggestedBufferSize = MainAVIHdr.dwSuggestedBufferSize;
+ This-fInfo.dwSuggestedBufferSize = 0;
This-fInfo.dwWidth = MainAVIHdr.dwWidth;
This-fInfo.dwHeight = MainAVIHdr.dwHeight;
LoadStringW(AVIFILE_hModule, IDS_AVIFILETYPE, This-fInfo.szFileType,
@@ -1754,8 +1754,7 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This)
pStream-sInfo.dwRate= streamHdr.dwRate;
pStream-sInfo.dwStart = streamHdr.dwStart;
pStream-sInfo.dwLength = streamHdr.dwLength;
- pStream-sInfo.dwSuggestedBufferSize =
- streamHdr.dwSuggestedBufferSize;
+ pStream-sInfo.dwSuggestedBufferSize = 0;
pStream-sInfo.dwQuality = streamHdr.dwQuality;
pStream-sInfo.dwSampleSize = streamHdr.dwSampleSize;
pStream-sInfo.rcFrame.left = streamHdr.rcFrame.left;
@@ -1905,6 +1904,13 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This)
}
}
+ for (nStream = 0; nStream This-fInfo.dwStreams; nStream++)
+ {
+DWORD sugbuf = This-ppStreams[nStream]-sInfo.dwSuggestedBufferSize;
+if (This-fInfo.dwSuggestedBufferSize sugbuf)
+ This-fInfo.dwSuggestedBufferSize = sugbuf;
+ }
+
/* find other chunks */
FindChunkAndKeepExtras(This-fileextra, This-hmmio, ck, ckRIFF, 0);
--
1.6.3.3
From c6437174e6c2241b95b0d9b30ae6d2cac8218cdc Mon Sep 17 00:00:00 2001
From: Julius Schwartzenberg julius.schwartzenb...@gmail.com
Date: Sun, 8 Nov 2009 15:32:33 +0100
Subject: avifile: Fix playback of fixed sample size audio stream
---
dlls/avifil32/avifile.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c
index c40cbd9..5fa45ae 100644
--- a/dlls/avifil32/avifile.c
+++ b/dlls/avifil32/avifile.c
@@ -1093,6 +1093,9 @@ static HRESULT WINAPI IAVIStream_fnRead(IAVIStream
*iface, LONG start,
/* convert samples to bytes */
samples *= This-sInfo.dwSampleSize;
+if (!buffer)
+ buffersize =
Re: shell32/tests: Fix Program Manager DDE Conformance Test Failures
2009/11/15 Mikey Alexander fireswor...@yahoo.com: You really don't want to skip this one as the api is supposed to create the window, but you can't be absolutely sure it is a failure, hence the error message being what it is. If you are going to skip the timeout if it fails, why bother checking for the window creation at all? The real question is what is the real worst case expected time to wait before failing because the window was not created? I upped it to 45 seconds. I could have implemented a window message thread to detect the window creation, but it doesn't change the problem. Window creation is not given a deadline. 10 seconds was obviously too short. Several machines failed on the first longer load with 10 seconds and a couple failed most of the timeouts with 10 seconds. I'd be more than willing to up the timeout longer, but if you really do encounter a failure, it makes the failed test take that much longer. - Mikey I think you misunderstood me. The window is created but as you're searching for a Startup window's title it fails on localized systems. So the test is not completely correct and only work on English system. That's why I proposed to skip the two tests on (and only on) such systems. I'll try to use a window message thread to see if it helps. PS: Please bottom post on wine-devel -- Nicolas Le Cam
re: Working on avifil32, sudden non enough memory error
Julius wrote: With one file however (GOODTIME.AVI from the win95 cd) I get this error after about a second: err:heap:HEAP_ValidateInUseArena Heap 0x11: in-use arena 0x184420 next block has PREV_FREE flag non enough memory I have no idea where this comes from and why it happens. (It appears to be unrelated to the memcpy call in avifile.c around line 1114.) With +heap I also get this before the error: HIGHPERF/GOODTIME.AVI: heap.c:403: HEAP_GetPtr: Controletest '0' faalt. (the assert fails) Sounds like heap corruption. You might want to cut down the file to the shortest one that causes the crash, then go after it (possibly using valgrind or the like) to look for the error. Does your implementation of avifil32 and friends work properly on windows?
Re: shell32/tests: Fix Program Manager DDE Conformance Test Failues
I think you misunderstood me. The window is created but as you're searching for a Startup window's title it fails on localized systems. So the test is not completely correct and only work on English system. That's why I proposed to skip the two tests on (and only on) such systems. I haven't tested this, but perhaps it's possible to use SHGetSpecialFolderPath(..., CSIDL_STARTUP, ...) to obtain the (localized) file system location of the Startup folder, then use the last part of that path as the window title to search for. E.g. on English Windows the path retrieved by the call would be C:\Documents and Settings\username\Start Menu\Programs\Startup, taking the last component would result in Startup. On Dutch Windows the path would be C:\Documents and Settings\username\Menu Start\Programma's\Opstarten, resulting in a last component of Opstarten which most likely is also the window title. Greg. smime.p7s Description: S/MIME cryptographic signature
Re: winscard: add pcsc-lite helpers for upcoming(?) implementation
To my knowledge the integration of the patches by Mounir IDRASSI has been rejected due to missing automated tests. This is a problem since for a full test someone has to write/provide an IFD handler which emulates some stuff. So far I haven't found some kind of virtual card reader - maybe attached to a virtual USB hub. Regards Heiko Am Freitag, 13. November 2009 09:32:24 schrieb viny: joerg-cyril.hoe...@t-systems.com a écrit : Hi, looking for PCSC-card-reader support in Wine, I came across old mails from 2007. http://www.winehq.org/pipermail/wine-devel/2007-May/057052.html What's the current state of PCSC support in Wine? When I recently looked, winscard seemed full of stubs. OTOH, there's a company http://www.starmoney.de/index.php?id=243 that seems to use Wine (and Darwine?) with card readers to make its software available for Linux Mac. Also seems ~2007. I believe that a winscard-PCSC-PCSC-Lite bridge would be much easier to achieve than USB support in Wine. Thanks for your help, Jörg Höhle Hi, There is a working binary winscard.dll for wine here : http://www.idrix.fr/Root/SCard4Wine/winscard.tar.gz But I'm waiting for official wine winscard too !
Re: ddraw/tests: Add test for refcounts of surface objects.
Am 15.11.2009 um 20:55 schrieb Vincent Povirk: 0001-ddraw-tests-Add-test-for-refcounts-of-surface-object.txt I think we already have tests for that - see IFaceRefCount() in dsurface.c
Re: ddraw/tests: Add test for refcounts of surface objects.
Ah, I only checked refcount.c. On Sun, Nov 15, 2009 at 2:12 PM, Stefan Dösinger stefandoesin...@gmx.at wrote: Am 15.11.2009 um 20:55 schrieb Vincent Povirk: 0001-ddraw-tests-Add-test-for-refcounts-of-surface-object.txt I think we already have tests for that - see IFaceRefCount() in dsurface.c -- Vincent Povirk
Implementing a cooling-off list in the heap
Valgrind has a nice option --freelist_vol which is the total size of blocks to hold on the freed block queue. It does this to help detect double free errors. Where in Wine's heap would one want to keep a free list like that? My first idea is to just add another element to the freeList array; rather than putting freed blocks into the normal element by size, they'd all go into the purgatory element until it filled up, after which they would be transferred to the normal free list according to their size. (Now off to ride the new light rail. In Los Angeles, any time they open a new one, it's cause for celebration... you kinda have to go there and see if some of the improbability will rub off on you.)
Re: [PATCH] winex11.drv: check for org = NULL (Coverity)
Hi Marcus,
A couple of hours ago I submitted a patch rewrites the function. It
suffers from the same 'issue'. This and any other wgl function are
called from gdi32/opengl.c which perform magic to arrive here and in
case of wglsharelists it also performs the filtering.
Roderick
On Sun, Nov 15, 2009 at 7:28 PM, Marcus Meissner mar...@jet.franken.de wrote:
Hi,
Coverity spotted some inconsistencies in org NULL
checking.
org originates via Windows code (I think) so we better check it.
Ciao, Marcus
---
dlls/winex11.drv/opengl.c | 8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c
index 45da479..774b205 100644
--- a/dlls/winex11.drv/opengl.c
+++ b/dlls/winex11.drv/opengl.c
@@ -1918,11 +1918,15 @@ BOOL CDECL X11DRV_wglShareLists(HGLRC hglrc1, HGLRC
hglrc2) {
if (!has_opengl()) return FALSE;
+ if (NULL == org) {
+ ERR(Could not share display lists, original context required.\n);
+ return FALSE;
+ }
if (NULL != dest dest-ctx != NULL) {
- ERR(Could not share display lists, context already created !\n);
+ ERR(Could not share display lists, context already created!\n);
return FALSE;
} else {
- if(org dest (GetObjectType(org-hdc) == OBJ_MEMDC) ^
(GetObjectType(dest-hdc) == OBJ_MEMDC)) {
+ if(dest (GetObjectType(org-hdc) == OBJ_MEMDC) ^
(GetObjectType(dest-hdc) == OBJ_MEMDC)) {
WARN(Attempting to share a context between a direct and indirect
rendering context, expect issues!\n);
}
--
1.5.6
Re: wined3d: Fix some typos
Hi Anders,
Your patch changes to two different dlls in one patch. In general a
patch should only change one thing. It would be nice if you could
separate it because else I'm not sure if it will be added.
Roderick
On Sun, Nov 15, 2009 at 9:12 PM, Anders Jonsson
anders.jons...@norsjonet.se wrote:
Fixes some typos in comctl32 and wined3d.
From 0656be69a97b7aae11b760fc4a436eb30191d527 Mon Sep 17 00:00:00 2001
From: Anders Jonsson anders.jons...@norsjonet.se
Date: Sun, 15 Nov 2009 21:05:22 +0100
Subject: Fix some typos
---
dlls/comctl32/updown.c | 4 ++--
dlls/wined3d/state.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/dlls/comctl32/updown.c b/dlls/comctl32/updown.c
index a212073..773d359 100644
--- a/dlls/comctl32/updown.c
+++ b/dlls/comctl32/updown.c
@@ -550,7 +550,7 @@ UPDOWN_Buddy_SubclassProc(HWND hwnd, UINT uMsg, WPARAM
wParam, LPARAM lParam)
*
* Sets bud as a new Buddy.
* Then, it should subclass the buddy
- * If window has the UDS_ARROWKEYS, it subcalsses the buddy window to
+ * If window has the UDS_ARROWKEYS, it subclasses the buddy window to
* process the UP/DOWN arrow keys.
* If window has the UDS_ALIGNLEFT or UDS_ALIGNRIGHT style
* the size/pos of the buddy and the control are adjusted accordingly.
@@ -659,7 +659,7 @@ static HWND UPDOWN_SetBuddy (UPDOWN_INFO* infoPtr, HWND
bud)
* 'delta' amount according to the 'action' flag which can be a
* combination of FLAG_INCR and FLAG_DECR
* It notifies the parent as required.
- * It handles wraping and non-wraping correctly.
+ * It handles wrapping and non-wrapping correctly.
* It is assumed that delta0
*/
static void UPDOWN_DoAction (UPDOWN_INFO *infoPtr, int delta, int action)
diff --git a/dlls/wined3d/state.c b/dlls/wined3d/state.c
index 94fe19e..6df6e54 100644
--- a/dlls/wined3d/state.c
+++ b/dlls/wined3d/state.c
@@ -1636,7 +1636,7 @@ static void state_wrap(DWORD state,
IWineD3DStateBlockImpl *stateblock, struct w
stateblock-renderState[WINED3DRS_WRAP13] ||
stateblock-renderState[WINED3DRS_WRAP14] ||
stateblock-renderState[WINED3DRS_WRAP15] ) {
- FIXME((WINED3DRS_WRAP0) Texture wraping not yet supported\n);
+ FIXME((WINED3DRS_WRAP0) Texture wrapping not yet supported\n);
}
}
--
1.6.3.3
Interesting Problem Building Wine for Regression Test
All: I continue to work with Tony Rollo's code as presented in bug 6254. I've found a problem with Wordpad's Print Preview between wine-1.1.10 and wine-1.1.11 and I attempted to run a regression test and end up with errors in makedep.c as follows: makedep.c:21:20: error: config.h: No such file or directory makedep.c:23:23: error: wine/port.h: No such file or directory makedep.c:35:23: error: wine/list.h: No such file or directory makedep.c:42: error: field ‘entry’ has incomplete type makedep.c:53: error: variable ‘sources’ has initializer but incomplete type makedep.c:53: error: ‘sources’ has an incomplete type makedep.c:54: error: variable ‘includes’ has initializer but incomplete type the list of errors continues but they are all related to the first three lines. These files exist in the include directory. What makes troubleshooting these errors difficult is that wine-1.1.10 AND wine-1.1.11 from the same git repository will build without these errors. What I did was: git bisect start git bisect good wine-1.1.10 git bisect bad wine-1.1.11 and I received the bisect message that there were 240 more changes to check. I do have an idea what commit caused the problem and attempted to manually backout the change, but the build also failed. I diffed the configure line and found no major differences between the configure on the build that finishes and the one that errors. Any idea on what I am doing incorrect? James McKenzie
[RFC] Extended Attributes for Dos Attributes, Creation Time, etc.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What are your thoughts on using Extended Attributes for items such as:
* Dos Attributes (like samba's store dos attributes = yes)
* File Creation Times (like samba's proposed user.crtime)
* An option for alternate storage of NT ACLs (like samba's vfs object =
acl-xattr)
Are Extended Attributes acceptable?
Or should they never touch the wine source?
Where would the portability functions for Extended Attributes on Linux,
Mac OS X, FreeBSD and Solaris belong? I would think in libport.
Attached is a patch to add extended attribute portability functions for
fgetxattr, fsetxattr and fremovexattr to libport.
Please give me any comments on this patch, and the idea of using
extended attributes.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAksAm/4ACgkQTHDAI68NsumFzwCbBDcRbB8kFXroLeskA+hzgswu
i0UAn3NHbau8AjSgtoruggBH3py+orcZ
=tEvP
-END PGP SIGNATURE-
From 2ef84c7f8c849db18ce15366e72c6787fa83597d Mon Sep 17 00:00:00 2001
From: Benjamin Peddell klightsp...@netspace.net.au
Date: Mon, 16 Nov 2009 01:23:28 +1000
Subject: [PATCH] Add Extended Attribute support to libport
---
configure| 178 ++
configure.ac | 45
include/config.h.in | 39 ++
include/wine/port.h | 36 +
libs/port/Makefile.in|3 +
libs/port/fgetxattr.c| 96 +
libs/port/fremovexattr.c | 75 +++
libs/port/fsetxattr.c| 102 ++
8 files changed, 574 insertions(+), 0 deletions(-)
create mode 100644 libs/port/fgetxattr.c
create mode 100644 libs/port/fremovexattr.c
create mode 100644 libs/port/fsetxattr.c
diff --git a/configure b/configure
index 15652b4..c9322b3 100755
--- a/configure
+++ b/configure
@@ -5747,6 +5747,7 @@ for ac_header in \
sys/errno.h \
sys/event.h \
sys/exec_elf.h \
+ sys/extattr.h \
sys/filio.h \
sys/inotify.h \
sys/ioctl.h \
@@ -5782,6 +5783,7 @@ for ac_header in \
sys/utsname.h \
sys/vm86.h \
sys/wait.h \
+ sys/xattr.h \
syscall.h \
termios.h \
unistd.h \
@@ -12084,6 +12086,9 @@ for ac_func in \
chsize \
dlopen \
epoll_create \
+ extattr_delete_fd \
+ extattr_get_fd \
+ extattr_set_fd \
ffs \
finite \
fnmatch \
@@ -12105,6 +12110,7 @@ for ac_func in \
lstat \
memmove \
mmap \
+ openat \
pclose \
pipe2 \
poll \
@@ -12137,6 +12143,7 @@ for ac_func in \
tcgetattr \
thr_kill2 \
timegm \
+ unlinkat \
usleep \
vsnprintf \
wait4 \
@@ -12262,6 +12269,81 @@ fi
fi
+{ $as_echo $as_me:${as_lineno-$LINENO}: checking for library containing
fgetxattr 5
+$as_echo_n checking for library containing fgetxattr... 6; }
+if test ${ac_cv_search_fgetxattr+set} = set; then :
+ $as_echo_n (cached) 6
+else
+ ac_func_search_save_LIBS=$LIBS
+cat confdefs.h - _ACEOF conftest.$ac_ext
+/* end confdefs.h. */
+
+/* Override any GCC internal prototype to avoid an error.
+ Use char because int might match the return type of a GCC
+ builtin and then its argument prototype would still apply. */
+#ifdef __cplusplus
+extern C
+#endif
+char fgetxattr ();
+int
+main ()
+{
+return fgetxattr ();
+ ;
+ return 0;
+}
+_ACEOF
+for ac_lib in '' attr; do
+ if test -z $ac_lib; then
+ac_res=none required
+ else
+ac_res=-l$ac_lib
+LIBS=-l$ac_lib $ac_func_search_save_LIBS
+ fi
+ if ac_fn_c_try_link $LINENO; then :
+ ac_cv_search_fgetxattr=$ac_res
+fi
+rm -f core conftest.err conftest.$ac_objext \
+conftest$ac_exeext
+ if test ${ac_cv_search_fgetxattr+set} = set; then :
+ break
+fi
+done
+if test ${ac_cv_search_fgetxattr+set} = set; then :
+
+else
+ ac_cv_search_fgetxattr=no
+fi
+rm conftest.$ac_ext
+LIBS=$ac_func_search_save_LIBS
+fi
+{ $as_echo $as_me:${as_lineno-$LINENO}: result: $ac_cv_search_fgetxattr 5
+$as_echo $ac_cv_search_fgetxattr 6; }
+ac_res=$ac_cv_search_fgetxattr
+if test $ac_res != no; then :
+ test $ac_res = none required || LIBS=$ac_res $LIBS
+
+fi
+
+
+for ac_func in \
+ fgetxattr \
+ fremovexattr \
+ fsetxattr \
+
+do :
+ as_ac_var=`$as_echo ac_cv_func_$ac_func | $as_tr_sh`
+ac_fn_c_check_func $LINENO $ac_func $as_ac_var
+eval as_val=\$$as_ac_var
+ if test x$as_val = xyes; then :
+ cat confdefs.h _ACEOF
+#define `$as_echo HAVE_$ac_func | $as_tr_cpp` 1
+_ACEOF
+
+fi
+done
+
+
{ $as_echo $as_me:${as_lineno-$LINENO}: checking for library containing
gethostbyname 5
$as_echo_n checking for library containing gethostbyname... 6; }
if test ${ac_cv_search_gethostbyname+set} = set; then :
@@ -12616,6 +12698,102 @@ $as_echo #define HAVE_ONE_ARG_MKDIR 1 confdefs.h
fi
+{ $as_echo
Re: winscard: add pcsc-lite helpers for upcoming(?) implementation
To my knowledge the integration of the patches by Mounir IDRASSI has been rejected due to missing automated tests. This is a problem since for a full test someone has to write/provide an IFD handler which emulates some stuff. IIRC, there was also a problem with the way it integration was done. It assumed the types between the Windows scard API and the Linux one were compatible, but in fact they may not be. I don't recall that this was ever addressed. --Juan
[Fwd: Interesting Problem Building Wine for Regression Test]
All: I continue to work with Tony Rollo's code as presented in bug 6254. I've found a problem with Wordpad's Print Preview between wine-1.1.10 and wine-1.1.11 and I attempted to run a regression test and end up with errors in makedep.c as follows: makedep.c:21:20: error: config.h: No such file or directory makedep.c:23:23: error: wine/port.h: No such file or directory makedep.c:35:23: error: wine/list.h: No such file or directory makedep.c:42: error: field ‘entry’ has incomplete type makedep.c:53: error: variable ‘sources’ has initializer but incomplete type makedep.c:53: error: ‘sources’ has an incomplete type makedep.c:54: error: variable ‘includes’ has initializer but incomplete type the list of errors continues but they are all related to the first three lines. These files exist in the include directory. What makes troubleshooting these errors difficult is that wine-1.1.10 AND wine-1.1.11 from the same git repository will build without these errors. What I did was: git bisect start git bisect good wine-1.1.10 git bisect bad wine-1.1.11 and I received the bisect message that there were 240 more changes to check. I do have an idea what commit caused the problem and attempted to manually backout the change, but the build also failed. I diffed the configure line and found no major differences between the configure on the build that finishes and the one that errors. Any idea on what I am doing incorrect? Just as a followup, I rebased my local git and received error messages relating to tools/Makefile.in. Forced a regit in the branch I had been working in and the builds are working again. Funny thing is that I did nothing to this file. James McKenzie
re: [RFC] Extended Attributes for Dos Attributes, Creation Time, etc.
Hi Ben, did you see http://bugs.winehq.org/show_bug.cgi?id=15679 http://www.winehq.org/pipermail/wine-patches/2009-October/079842.html ? IMHO the way the Samba sources merged the fd and filename version of the calls makes for less duplication of code. (I tried to do it the other way first, and it seemed ugly.) - Dan
Re: [PATCH 1/3] user32: Free window text to prevent leak in case whenWM_NCDESTROY doesn't get to default procedure
Nikolay Sivov bungleh...@gmail.com wrote: This fixes a leak spotted by valgrind. Changelog: - free window text to prevent leak in case when WM_NCDESTROY doesn't get to default procedure Then WM_NCDESTROY handler should be removed from DefWindowProc to avoid a confusing duplication. -- Dmitry.
Re: user32: Destroy EDITSTATE structure in the WM_NCDESTROY messageprocessing
Ilya Shpigor shpi...@etersoft.ru wrote: +SendMessageA(hWnd, WM_SETTEXT, 0, (LPARAM)str); +SendMessageA(hWnd, WM_GETTEXT, MAXLEN, (LPARAM)buf); +ok(!lstrcmp(buf, str), Wrong contents of edit: %s\n, buf); +lstrcpy(buf, ); +SendMessageA(hWnd, WM_DESTROY, 0, 0); +SendMessageA(hWnd, WM_GETTEXT, MAXLEN, (LPARAM)buf); +ok(!lstrcmp(buf, str), Wrong contents of edit: %s\n, buf); +lstrcpy(buf, ); +SendMessageA(hWnd, WM_NCDESTROY, 0, 0); +SendMessageA(hWnd, WM_GETTEXT, MAXLEN, (LPARAM)buf); +ok(!lstrcmp(buf, ), Wrong contents of edit: %s\n, buf); You should check return values of each SendMessage above. -- Dmitry.
