Re: kde plugin
On Sun, 2005-03-20 at 01:39 +, Oliver Stieber wrote: --- Scott Ritchie [EMAIL PROTECTED] wrote: On Sat, 2005-03-19 at 22:05 +, Oliver Stieber wrote: Hi, I've got a plugin for KDE that displays icons and thumbnails for windows applications and dlls in Konqueror. I was intending to extend it to meta info and maybe a full kioslave for browsing windows PE files, but never got that far. At the moment it's a bit of a licensing nightmare, but I can package it up in a format that's ok for QT and Wine if anyone's interested. Oliver. Send instant messages to your online friends http://uk.messenger.yahoo.com Well, there's nothing to stop you from releasing it as public domain or a BSD-type license that should be compatible with anything. I'm sure people would appreciate your code. I'm using a wine header that's lgpl but QT is GPL only, I'd just re-write the parts of the header I'm using. That's no problem: you can release your stuff as GPL. Section 3 of the LGPL explicitly grants you this right: http://www.gnu.org/licenses/lgpl.html 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. In effect, all LGPL software is effectively dual-licensed as GPL. -Scott Ritchie
Re: Correct calling conventions
On Sat, Mar 19, 2005 at 08:30:44PM -0500, Vincent Béron wrote: Changelog: Use the correct calling convention in various places. The problem here is too, that these functions do not have prototypes in the correct headers, otherwise gcc would have already warned about them. Ciao, Marcus
winmm problems
I am having some problems with the latest wine under Solaris and a small test game I use, (Little Fighter 2) , if I enable audio support the application seems to deadlock but without audio it runs OK. It doesn't matter what audio driver I select (libaudioio or arts). Since February, what changes have been made to the audio framework that might cause this behaviour? Bob
Re: Correct calling conventions
Le dim 20/03/2005 à 04:39, Marcus Meissner a écrit : On Sat, Mar 19, 2005 at 08:30:44PM -0500, Vincent Béron wrote: Changelog: Use the correct calling convention in various places. The problem here is too, that these functions do not have prototypes in the correct headers, otherwise gcc would have already warned about them. I don't have a current PSDK here, and I'm not sure I trust MSDN enough for that information. Vincent
Re: winmm patch
On Sat, Mar 19, 2005 at 07:46:01PM -0600, Royce Mitchell III wrote: Royce Mitchell III [EMAIL PROTECTED] - fix warning that is really a bug - from looking at the code, wDevID should be a UINT, not a UINT_16 ( perhaps these should be renamed? ) Please: 1. Send a diff -u (http://winehq.org/site/sending_patches) 2. Don't compress your submissions. -- Dimi.
ntdll / kernel32: #53
This patch starts looking at providing full overlapped I/O support to named
pipes. We're not here yet.
It basically starts making the wineserver side of the named pipe code:
- use NT values instead of kernel32
- make use of asynchronous I/O
The rest of the patch is mainly cleanup. It should be a no op change.
A+
--
Eric Pouech
Name: ntkrnl_53
ChangeLog:
- moved named pipe creation to ntdll
- server now handles the named pipe flags as the NTDLL values (not the KERNEL32 ones)
- named pipes in server now use the async IO mechanism for connect/wait ops
- tiddy up async IO functions in server to match named pipes' needs
- removed the no longer user APC_ASYNC kind of APC
License: X11
GenDate: 2005/03/20 14:17:12 UTC
ModifiedFiles: dlls/kernel/sync.c dlls/ntdll/file.c dlls/ntdll/sync.c include/winternl.h
server/fd.c server/file.c server/file.h server/named_pipe.c server/protocol.def server/serial.c server/sock.c
AddedFiles:
RemovedFiles:
===
RCS file: /home/cvs/cvsroot/wine/wine/dlls/kernel/sync.c,v
retrieving revision 1.71
diff -u -u -r1.71 sync.c
--- dlls/kernel/sync.c 4 Mar 2005 12:38:37 - 1.71
+++ dlls/kernel/sync.c 20 Mar 2005 08:28:28 -
@@ -56,6 +56,9 @@
#include wine/debug.h
+#define NONAMELESSUNION
+#define NONAMELESSSTRUCT
+
WINE_DEFAULT_DEBUG_CHANNEL(sync);
/* check if current version is NT or Win95 */
@@ -1051,15 +1054,20 @@
HANDLE WINAPI CreateNamedPipeW( LPCWSTR name, DWORD dwOpenMode,
DWORD dwPipeMode, DWORD nMaxInstances,
DWORD nOutBufferSize, DWORD nInBufferSize,
-DWORD nDefaultTimeOut, LPSECURITY_ATTRIBUTES attr )
+DWORD nDefaultTimeOut, LPSECURITY_ATTRIBUTES sa )
{
-HANDLE ret;
+HANDLE handle;
UNICODE_STRING nt_name;
-static const WCHAR leadin[] = {'\\','?','?','\\','P','I','P','E','\\'};
+OBJECT_ATTRIBUTES attr;
+DWORD options;
+BOOLEAN pipe_type, read_mode, non_block;
+NTSTATUS status;
+IO_STATUS_BLOCK iosb;
+LARGE_INTEGER timeout;
TRACE((%s, %#08lx, %#08lx, %ld, %ld, %ld, %ld, %p)\n,
debugstr_w(name), dwOpenMode, dwPipeMode, nMaxInstances,
- nOutBufferSize, nInBufferSize, nDefaultTimeOut, attr );
+ nOutBufferSize, nInBufferSize, nDefaultTimeOut, sa );
if (!RtlDosPathNameToNtPathName_U( name, nt_name, NULL, NULL ))
{
@@ -1072,30 +1080,42 @@
RtlFreeUnicodeString( nt_name );
return INVALID_HANDLE_VALUE;
}
-if (nt_name.Length sizeof(leadin) ||
-strncmpiW( nt_name.Buffer, leadin, sizeof(leadin)/sizeof(leadin[0])))
-{
-SetLastError( ERROR_INVALID_NAME );
-RtlFreeUnicodeString( nt_name );
-return INVALID_HANDLE_VALUE;
-}
-SERVER_START_REQ( create_named_pipe )
+
+attr.Length = sizeof(attr);
+attr.RootDirectory= 0;
+attr.ObjectName = nt_name;
+attr.Attributes = (sa sa-bInheritHandle) ? OBJ_INHERIT : 0;
+attr.SecurityDescriptor = sa ? sa-lpSecurityDescriptor : NULL;
+attr.SecurityQualityOfService = NULL;
+
+options = 0;
+if (dwOpenMode FILE_FLAG_WRITE_THROUGH) options |= FILE_WRITE_THROUGH;
+if (!(dwOpenMode FILE_FLAG_OVERLAPPED)) options |= FILE_SYNCHRONOUS_IO_ALERT;
+if ((dwOpenMode PIPE_ACCESS_DUPLEX) == PIPE_ACCESS_DUPLEX)
+options |= FILE_PIPE_FULL_DUPLEX;
+else if (dwOpenMode PIPE_ACCESS_INBOUND) options |= FILE_PIPE_INBOUND;
+else if (dwOpenMode PIPE_ACCESS_OUTBOUND) options |= FILE_PIPE_OUTBOUND;
+pipe_type = (dwPipeMode PIPE_TYPE_MESSAGE) ? TRUE : FALSE;
+read_mode = (dwPipeMode PIPE_READMODE_MESSAGE) ? TRUE : FALSE;
+non_block = (dwPipeMode PIPE_NOWAIT) ? TRUE : FALSE;
+if (nMaxInstances = PIPE_UNLIMITED_INSTANCES) nMaxInstances = ULONG_MAX;
+
+timeout.QuadPart = (ULONGLONG)nDefaultTimeOut * -1;
+
+SetLastError(0);
+
+status = NtCreateNamedPipeFile(handle, 0, attr, iosb, 0, FILE_OVERWRITE_IF,
+ options, pipe_type, read_mode, non_block,
+ nMaxInstances, nInBufferSize, nOutBufferSize,
+ timeout);
+
+RtlFreeUnicodeString( nt_name );
+if (status)
{
-req-openmode = dwOpenMode;
-req-pipemode = dwPipeMode;
-req-maxinstances = nMaxInstances;
-req-outsize = nOutBufferSize;
-req-insize = nInBufferSize;
-req-timeout = nDefaultTimeOut;
-req-inherit = (attr (attr-nLength=sizeof(*attr)) attr-bInheritHandle);
-wine_server_add_data( req, nt_name.Buffer + 4, nt_name.Length - 4*sizeof(WCHAR) );
-SetLastError(0);
-if (!wine_server_call_err( req )) ret = reply-handle;
-else ret = INVALID_HANDLE_VALUE;
+handle =
Re: Four questions to dll/iphlpapi/* wrt lstrcpyA.
Hi Peter, there's nothing magical in here, your understanding is correct. I'll answer each question individually though. 1) I am wondering, why sizeof(ptr-Adaptername) is used instead of MAX_ADAPTER_NAME_LENGTH+1? That's just a style thing. I prefer sizeof(thing being copied) to MAGIC_CONSTANT in case the structure being used changes. That's unlikely in this case since the structure is defined in a public header. Since it's a style thing there's no code-behavior reason to keep it this way. 2) Is 2a supposed to be saying 15 Yes, that's just a stupid bug apparently. Why I didn't use sizeof is beyond me. 3) Why suddenly the change to use memcpy? and not some strcpy function as the code above it? I wrote this on a different day :) --Juan __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
Re: ddraw correctness fixes patch
Christian Costa wrote: I think the problem Matthew was talking is how to remap surface pointers. I sent something to Mattew but I forgot to cc wine-devel, sorry. Basically it was : depth = surface_desc.u4.ddpfPixelFormat.u1.dwRGBBitCount; ddesc.lpSurface -= (lock_dst.left - lock_union.left)*(depth+7)/8 + ddesc.lPictch * (lock_dst.top - lock_union.top); sdesc.lpSurface -= (lock_src.left - lock_union.left)*(depth+7)/8) + sdesc.lPictch * (lock_src.top - lock_union.top); I implemented the surface pointer remapping in my lastest patch, but chose to adjust the surface pointers from the raw surface pointer instead of the pre-adjusted value returned from the Lock() call. It's the same logic, but easier to verify as correct to the eye. If you could take a look at the latest patch, I'd appreciate it. Matt.
Re: DDRAW: Surface locking patch, take 2
Hi Matthew,
This seems fine.
There are some comments though, see below.
Index: dlls/ddraw/dsurface/dib.c
===
RCS file: /home/wine/wine/dlls/ddraw/dsurface/dib.c,v
retrieving revision 1.46
diff -u -r1.46 dib.c
--- dlls/ddraw/dsurface/dib.c 10 Mar 2005 11:13:11 - 1.46
+++ dlls/ddraw/dsurface/dib.c 20 Mar 2005 16:49:40 -
@@ -528,9 +528,15 @@
DD_STRUCT_INIT(sdesc);
sdesc.dwSize = sizeof(sdesc);
-if (src) IDirectDrawSurface7_Lock(src, NULL, sdesc, DDLOCK_READONLY, 0);
ddesc.dwSize = sizeof(ddesc);
-IDirectDrawSurface7_Lock(iface,NULL,ddesc,DDLOCK_WRITEONLY,0);
+
+if (src == iface) {
+IDirectDrawSurface7_Lock(iface, NULL, ddesc, 0, 0);
+DD_STRUCT_COPY_BYSIZE(sdesc, ddesc);
+} else {
+if (src) IDirectDrawSurface7_Lock(src, NULL, sdesc, DDLOCK_READONLY,
0);
+IDirectDrawSurface7_Lock(iface,NULL,ddesc,DDLOCK_WRITEONLY,0);
+}
if ((sdesc.u4.ddpfPixelFormat.dwFlags DDPF_FOURCC)
(ddesc.u4.ddpfPixelFormat.dwFlags DDPF_FOURCC)) {
@@ -581,7 +587,8 @@
(xsrc.right sdesc.dwWidth) || (xsrc.right 0) ||
(xsrc.right xsrc.left) || (xsrc.bottom xsrc.top))) {
WARN(Application gave us bad source rectangle for Blt.\n);
- return DDERR_INVALIDRECT;
+ ret = DDERR_INVALIDRECT;
+ goto release;
}
/* For the Destination rect, it can be out of bounds on the condition that a clipper
is set for the given surface.
@@ -593,7 +600,8 @@
(xdst.right ddesc.dwWidth) || (xdst.right 0) ||
(xdst.right xdst.left) || (xdst.bottom xdst.top))) {
WARN(Application gave us bad destination rectangle for Blt without a clipper set.\n);
- return DDERR_INVALIDRECT;
+ ret = DDERR_INVALIDRECT;
+ goto release;
}
/* Now handle negative values in the rectangles. Warning: only supported for now
@@ -958,7 +966,7 @@
release:
IDirectDrawSurface7_Unlock(iface,NULL);
-if (src) IDirectDrawSurface7_Unlock(src,NULL);
+if (src src != iface) IDirectDrawSurface7_Unlock(src,NULL);
return DD_OK;
}
@@ -975,7 +983,7 @@
HRESULT ret = DD_OK;
LPBYTE sbuf, dbuf;
RECTrsrc2;
-RECTlock_src, lock_dst;
+RECTlock_src, lock_dst, lock_union;
if (TRACE_ON(ddraw)) {
TRACE((%p)-(%ld,%ld,%p,%p,%08lx)\n,
@@ -1043,11 +1051,28 @@
lock_dst.right = dstx + w;
lock_dst.bottom = dsty + h;
+bpp = GET_BPP(This-surface_desc);
+
/* We need to lock the surfaces, or we won't get refreshes when done. */
-sdesc.dwSize = sizeof(sdesc);
-IDirectDrawSurface7_Lock(src, lock_src, sdesc, DDLOCK_READONLY, 0);
-ddesc.dwSize = sizeof(ddesc);
-IDirectDrawSurface7_Lock(iface, lock_dst, ddesc, DDLOCK_WRITEONLY, 0);
+if (src == iface) {
+int pitch;
+
+UnionRect(lock_union, lock_src, lock_dst);
+
+/* Lock the union of the two rectangles */
+IDirectDrawSurface7_Lock(iface, lock_union, ddesc, 0, 0);
+
+pitch = This-surface_desc.u1.lPitch;
+
ddesc has not been properly initialized.
you should also copy sdesc from ddesc.
+/* Since sdesc was originally copied from this surface's description, we can just reuse it */
+sdesc.lpSurface = (BYTE *)This-surface_desc.lpSurface + lock_src.top * pitch + lock_src.left * bpp;
+ddesc.lpSurface = (BYTE *)This-surface_desc.lpSurface + lock_dst.top * pitch + lock_dst.left * bpp;
+} else {
+sdesc.dwSize = sizeof(sdesc);
+IDirectDrawSurface7_Lock(src, lock_src, sdesc, DDLOCK_READONLY, 0);
+ddesc.dwSize = sizeof(ddesc);
+IDirectDrawSurface7_Lock(iface, lock_dst, ddesc, DDLOCK_WRITEONLY, 0);
+}
/* Handle first the FOURCC surfaces... */
if ((sdesc.u4.ddpfPixelFormat.dwFlags DDPF_FOURCC) (ddesc.u4.ddpfPixelFormat.dwFlags DDPF_FOURCC)) {
@@ -1069,7 +1094,6 @@
goto error;
}
-bpp = GET_BPP(This-surface_desc);
sbuf = (BYTE *) sdesc.lpSurface;
dbuf = (BYTE *) ddesc.lpSurface;
@@ -1141,8 +1165,13 @@
}
error:
-IDirectDrawSurface7_Unlock(iface, lock_dst);
-IDirectDrawSurface7_Unlock(src, lock_src);
+if (src == iface) {
+IDirectDrawSurface7_Unlock(iface, lock_union);
+} else {
+IDirectDrawSurface7_Unlock(iface, lock_dst);
+IDirectDrawSurface7_Unlock(src, lock_src);
You should check if src != NULL before trying to unlocking it.
+}
+
return ret;
}
Re: [WINEALSA] fix direct sound capabilities to match HW
Robert Reif wrote:
Fix direct sound capabilities to match hardware.
Should fix problems related to trying to do 8 bit and mono on
16 bit stereo only hardware when using ALSA hw device and
direct sound hardware acceleration.
This one should work.
Index: dlls/winmm/winealsa/audio.c
===
RCS file: /home/wine/wine/dlls/winmm/winealsa/audio.c,v
retrieving revision 1.67
diff -u -p -r1.67 audio.c
--- dlls/winmm/winealsa/audio.c 19 Mar 2005 17:11:02 - 1.67
+++ dlls/winmm/winealsa/audio.c 20 Mar 2005 20:51:41 -
@@ -189,6 +189,7 @@ typedef struct {
/* DirectSound stuff */
DSDRIVERDESCds_desc;
+DSDRIVERCAPSds_caps;
} WINE_WAVEOUT;
typedef struct {
@@ -231,6 +232,7 @@ typedef struct {
/* DirectSound stuff */
DSDRIVERDESCds_desc;
+DSCDRIVERCAPS ds_caps;
} WINE_WAVEIN;
static WINE_WAVEOUTWOutDev [MAX_WAVEOUTDRV];
@@ -817,6 +819,38 @@ LONG ALSA_WaveInit(void)
wwo-caps.dwSupport |= WAVECAPS_LRVOLUME;
}
+if (wwo-caps.dwFormats (WAVE_FORMAT_1M08 | WAVE_FORMAT_2M08 |
+ WAVE_FORMAT_4M08 | WAVE_FORMAT_48M08 |
+ WAVE_FORMAT_96M08 | WAVE_FORMAT_1M16 |
+ WAVE_FORMAT_2M16 | WAVE_FORMAT_4M16 |
+ WAVE_FORMAT_48M16 | WAVE_FORMAT_96M16) )
+wwo-ds_caps.dwFlags |= DSCAPS_PRIMARYMONO;
+
+if (wwo-caps.dwFormats (WAVE_FORMAT_1S08 | WAVE_FORMAT_2S08 |
+ WAVE_FORMAT_4S08 | WAVE_FORMAT_48S08 |
+ WAVE_FORMAT_96S08 | WAVE_FORMAT_1S16 |
+ WAVE_FORMAT_2S16 | WAVE_FORMAT_4S16 |
+ WAVE_FORMAT_48S16 | WAVE_FORMAT_96S16) )
+wwo-ds_caps.dwFlags |= DSCAPS_PRIMARYSTEREO;
+
+if (wwo-caps.dwFormats (WAVE_FORMAT_1M08 | WAVE_FORMAT_2M08 |
+ WAVE_FORMAT_4M08 | WAVE_FORMAT_48M08 |
+ WAVE_FORMAT_96M08 | WAVE_FORMAT_1S08 |
+ WAVE_FORMAT_2S08 | WAVE_FORMAT_4S08 |
+ WAVE_FORMAT_48S08 | WAVE_FORMAT_96S08) )
+wwo-ds_caps.dwFlags |= DSCAPS_PRIMARY8BIT;
+
+if (wwo-caps.dwFormats (WAVE_FORMAT_1M16 | WAVE_FORMAT_2M16 |
+ WAVE_FORMAT_4M16 | WAVE_FORMAT_48M16 |
+ WAVE_FORMAT_96M16 | WAVE_FORMAT_1S16 |
+ WAVE_FORMAT_2S16 | WAVE_FORMAT_4S16 |
+ WAVE_FORMAT_48S16 | WAVE_FORMAT_96S16) )
+wwo-ds_caps.dwFlags |= DSCAPS_PRIMARY16BIT;
+
+wwo-ds_caps.dwMinSecondarySampleRate = DSBFREQUENCY_MIN;
+wwo-ds_caps.dwMaxSecondarySampleRate = DSBFREQUENCY_MAX;
+wwo-ds_caps.dwPrimaryBuffers = 1;
+
ALSA_WodNumDevs++;
}
@@ -933,7 +967,7 @@ LONG ALSA_WaveInit(void)
ALSA_WidNumDevs++;
}
-
+
return 0;
}
@@ -2013,7 +2047,7 @@ static DWORD wodGetVolume(WORD wDevID, L
if (!wwo-ctl)
return MMSYSERR_NOTSUPPORTED;
-
+
count = snd_ctl_elem_info_get_count(wwo-playback_einfo);
min = snd_ctl_elem_info_get_min(wwo-playback_einfo);
max = snd_ctl_elem_info_get_max(wwo-playback_einfo);
@@ -2612,25 +2646,7 @@ static HRESULT WINAPI IDsDriverImpl_GetC
{
IDsDriverImpl *This = (IDsDriverImpl *)iface;
TRACE((%p,%p)\n,iface,pCaps);
-memset(pCaps, 0, sizeof(*pCaps));
-
-pCaps-dwFlags = DSCAPS_PRIMARYMONO;
-if ( WOutDev[This-wDevID].caps.wChannels == 2 )
-pCaps-dwFlags |= DSCAPS_PRIMARYSTEREO;
-
-if ( WOutDev[This-wDevID].caps.dwFormats (WAVE_FORMAT_1S08 |
WAVE_FORMAT_2S08 | WAVE_FORMAT_4S08 ) )
- pCaps-dwFlags |= DSCAPS_PRIMARY8BIT;
-
-if ( WOutDev[This-wDevID].caps.dwFormats (WAVE_FORMAT_1S16 |
WAVE_FORMAT_2S16 | WAVE_FORMAT_4S16))
- pCaps-dwFlags |= DSCAPS_PRIMARY16BIT;
-
-pCaps-dwPrimaryBuffers = 1;
-TRACE(caps=0x%X\n,(unsigned int)pCaps-dwFlags);
-pCaps-dwMinSecondarySampleRate = DSBFREQUENCY_MIN;
-pCaps-dwMaxSecondarySampleRate = DSBFREQUENCY_MAX;
-
-/* the other fields only apply to secondary buffers, which we don't support
- * (unless we want to mess with wavetable synthesizers and MIDI) */
+memcpy(pCaps, (WOutDev[This-wDevID].ds_caps), sizeof(DSDRIVERCAPS));
return DS_OK;
}
Re: DDRAW: Surface locking patch, take 2
Matthew Mastracci wrote:
Christian Costa wrote:
Hi Matthew,
This seems fine.
There are some comments though, see below.
...
+if (src == iface) {
+int pitch;
+
+UnionRect(lock_union, lock_src, lock_dst);
+
+/* Lock the union of the two rectangles */
+IDirectDrawSurface7_Lock(iface, lock_union, ddesc, 0, 0);
+
+pitch = This-surface_desc.u1.lPitch;
+
ddesc has not been properly initialized.
you should also copy sdesc from ddesc.
It actually has. If you look higher up in the function, ddesc and
sdesc are copied from This-surface_desc:
/* Get the surface description without locking to first compute
the width / height */
ddesc = This-surface_desc;
sdesc = (ICOM_OBJECT(IDirectDrawSurfaceImpl, IDirectDrawSurface7,
src))-surface_desc;
AFAICT, ddesc and sdesc will always be valid after this initialization.
Sorry! I didn't see that in the diff. I should have looked at dib.c too.
+if (src == iface) {
+IDirectDrawSurface7_Unlock(iface, lock_union);
+} else {
+IDirectDrawSurface7_Unlock(iface, lock_dst);
+IDirectDrawSurface7_Unlock(src, lock_src);
You should check if src != NULL before trying to unlocking it.
BltFast() doesn't accept a NULL src, so this isn't necessary. The
function should probably check for NULL src before the surface lock
check. If I can figure out what the error return code should be (I
think it's DDERR_INVALIDPARAM), I can check for a NULL src at the
start of the function in a later patch.
Ok! Fine.
Thanks for the review,
Matt.
Re: DDRAW: Surface locking patch, take 2
Christian Costa wrote:
Hi Matthew,
This seems fine.
There are some comments though, see below.
...
+if (src == iface) {
+int pitch;
+
+UnionRect(lock_union, lock_src, lock_dst);
+
+/* Lock the union of the two rectangles */
+IDirectDrawSurface7_Lock(iface, lock_union, ddesc, 0, 0);
+
+pitch = This-surface_desc.u1.lPitch;
+
ddesc has not been properly initialized.
you should also copy sdesc from ddesc.
It actually has. If you look higher up in the function, ddesc and sdesc
are copied from This-surface_desc:
/* Get the surface description without locking to first compute the
width / height */
ddesc = This-surface_desc;
sdesc = (ICOM_OBJECT(IDirectDrawSurfaceImpl, IDirectDrawSurface7,
src))-surface_desc;
AFAICT, ddesc and sdesc will always be valid after this initialization.
+if (src == iface) {
+IDirectDrawSurface7_Unlock(iface, lock_union);
+} else {
+IDirectDrawSurface7_Unlock(iface, lock_dst);
+IDirectDrawSurface7_Unlock(src, lock_src);
You should check if src != NULL before trying to unlocking it.
BltFast() doesn't accept a NULL src, so this isn't necessary. The
function should probably check for NULL src before the surface lock
check. If I can figure out what the error return code should be (I
think it's DDERR_INVALIDPARAM), I can check for a NULL src at the start
of the function in a later patch.
Thanks for the review,
Matt.
Preview-window works in Virtualdub,Paltalk etc.
Hi, don't know if it's of much use for anyone, but i can now view the images from my webcam in the preview window in programs like Virtualdub, Paltalk and WebCamnow. Basically the attached patch reads a RGB-image from my video4linux device and turns this into a bitmap, which is then displayed. The device must be able to read RGB's. In case you would like to try, replace dlls/avicap32 with the attached one, and replace include/vfw.h with the attached vfw.h. I'm skilled enough to turn this into a real patch, maybe someone with more programming capabilities could give it try. Regards Luis Send instant messages to your online friends http://uk.messenger.yahoo.com avicap.tar.gz Description: avicap.tar.gz vfw.h.gz Description: vfw.h.gz
Re: Four questions to dll/iphlpapi/* wrt lstrcpyA.
On Sun, 20 Mar 2005, Juan Lang wrote: Hi Peter, there's nothing magical in here, your understanding is correct. I'll answer each question individually though. 1) I am wondering, why sizeof(ptr-Adaptername) is used instead of MAX_ADAPTER_NAME_LENGTH+1? That's just a style thing. I prefer sizeof(thing being copied) to MAGIC_CONSTANT in case the structure being used changes. That's unlikely in this case since the structure is defined in a public header. It's not that unlikely. Microsoft has extended some of their structures many times in the past. That's why some of them have have these cbSize fields. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.
Re: [ntdll] NtCreateFile update
Does anyone have any links to these documented only because Microsoft have to type functions (like NtCreateFile etc)?
