Re: Work legalities
Nathan Williams wrote: but I did sign a contract and think there may be an issue with one of the sections. If you want, post those sections here. There are some contracts that say anything you do is ours. A reasonable contract, however, will say everything you do using work equipment and on company time is ours. This may still be a problem if, for example, you code Wine on a company provided laptop. When I finally come to submitting code, does wine need a copy of the agreement, or do I just hold onto it incase of future cmplications? (which is very unlikely as I see it) No. Ultimately, it's your responsibility to make sure that the code you submit to Wine under LGPL is yours to submit. As far as I understand, all that will be required of Wine in case of a violation is to remove the code. You, on the other hand, might find yourself on the wrong end of a copyright violation suite from your employer. Just get permission. Oral is ok if you can later prove that it happened (which is another way of saying get it in writing). Shachar
Re: Don't compare file handles to NULL
Francois Gouget [EMAIL PROTECTED] writes: These are not false positives. Any file handle that is not INVALID_HANDLE_VALUE must be closed with CloseHandle(). So these checks should be against INVALID_HANDLE_VALUE, not NULL. In fact they may possibly be removed altogether. Note that a valid file handle will never be NULL, so while these checks are wrong in theory, in practice it makes no difference. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Don't compare file handles to NULL
On Thu, 8 Mar 2007, Alexandre Julliard wrote: [...] Note that a valid file handle will never be NULL, so while these checks are wrong in theory, in practice it makes no difference. Right. But the invalid check means that in some cases we will call CloseHandle(INVALID_HANDLE_VALUE) which the MSDN has this to say about: If the application is running under a debugger, the function will throw an exception if it receives either a handle value that is not valid or a pseudo-handle value. This can happen if you close a handle twice, or if you call CloseHandle on a handle returned by the FindFirstFile function. I did not check but I guess Wine does not do that... so far. It's still best avoided. -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean
Re: Don't compare file handles to NULL
On Thu, 8 Mar 2007, Alexandre Julliard wrote: [...] Sure, it's best to avoid closing an invalid handle. We don't throw an exception but we do set last error, and this could conceivably break something. But the NULL check is not going to cause us to forget to close a valid handle, which would be a much worse problem. Oh, sure. The exception being RPCRT4_RPCSSOnDemandCall() (and similar code in rpcss) which was so confused it did not call CloseHandle() at all (as far as I could see). -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.
Re: [winealsa] Mind buffer loops when pausing
On Wed, Mar 07, 2007 at 02:41:42AM -0500, Chris Bandy wrote: It looks correct on paper, but I don't seem to have any applications that even attempt to pause. Can anyone suggest an application to test this with? All feedback welcome. The winmm wave testcase does pause. Jan
re: Writing a winelib plugin
Shachar wrote: It used to not be possible to write a plugin, to be loaded from a standard Linux ELF program, that will be itself a winelib shared object. All sorts of issues regarding running wineserver and memory layout initializations were problematic. I'm wondering whether there is any news on that front. Is it still not practically possible to do this? Last time I asked about this, I got the impression that there was some hope but nobody was working on it. And I think it would require linking something statically into the program, too, so if you're trying to foist winelib shared objects onto an unsuspecting Big App, you're probably going to be out of luck even if this gets worked on. What application did you have in mind?
Re: Command and Conquer 3 Demo
Onsdag 07 mars 2007 09:40, skrev H. Verbeet: On 07/03/07, Matthew Clark [EMAIL PROTECTED] wrote: I just wanted to write to let all of the devs know how proud of the wine project I am. This Demo seems to work for the most part except for the movies in it don't seem to want to resize and when you are under attack the game crashes. Here is the console dump: Wrt the movies, are you running the game at a different resolution from the default by any chance? hope that helps. Again, greats that that is all that's wrong^_^ The graphics look great, it sounds great, and the videos are crystal clear(though small). Have you got a backtrace as well? Does running the game with OSS instead of ALSA make any difference? From the debug output you posted I can't really tell if that's a dsound problem, a d3d problem or something else. Not all users are experiencing the crashes, perhaps a SMP issue? Running with OSS gives you no sound (this already has a bug report). Regard,s Alexander N. Sørnes Also, please post a bug report on bugzilla, it's much better for keeping track of bugs.
Re: Command and Conquer 3 Demo
On 08/03/07, Alexander Nicolaysen Sørnes [EMAIL PROTECTED] wrote: Running with OSS gives you no sound (this already has a bug report). Well yeah, just looking if we can blame winealsa :-)
Re: quartz: Use proper alloc/free functions for COM objects
On Do, 2007-03-08 at 03:06 -0800, Chris Robinson wrote: Subject: [PATCH] quartz: Use proper alloc/free functions for COM objects +omr-messages = CoTaskMemAlloc(omr-ring_buffer_size * sizeof(Event)); +ZeroMemory(omr-messages, omr-ring_buffer_size * sizeof(Event)); +fimpl = CoTaskMemAlloc(sizeof(*fimpl)); fimpl-IGraphBuilder_vtbl = IGraphBuilder_VTable; +This-ppPins = CoTaskMemAlloc((This-cStreams + 2) * sizeof(IPin *)); memcpy(This-ppPins, ppOldPins, (This-cStreams + 1) * sizeof(IPin *)); +This-ppPins = CoTaskMemAlloc(sizeof(IPin *) * 1); memcpy(This-ppPins, ppOldPins, sizeof(IPin *) * 1); While reading your Patch, I see the above Places, where the result from the allocation is used without a NULL-check. The other allocations are checked for NULL before used. Is this correct? -- By by ... Detlef
Re: user32: avoid NULL pointer access in DefWindowProcA WM_NCCREATE
On Thu, Mar 08, 2007 at 05:08:46PM +0100, Felix Nawothnig wrote: Jan Zerebecki wrote: CREATESTRUCTA *cs = (CREATESTRUCTA *)lParam; /* check for string, as static icons, bitmaps (SS_ICON, SS_BITMAP) * may have child window IDs instead of window name */ -if (HIWORD(cs-lpszName)) +if (cs HIWORD(cs-lpszName)) cs is never NULL at that point. Where should it be checked for NULL, then? Or what does it prevent to be NULL? Jan PS: please respect Mail-Followup-To, see http://cr.yp.to/proto/replyto.html
Re: Work legalities
I asked James Vasile, of the Software Freedom Law Center, to comment on this. (For those who don't recall, the SFLC officially represents the Wine project on legal matters). This is essentially what he had to say (and James, correct me if I get anything wrong :-/): If you are employed to do programming (even at a university), or have made an agreement with your employer, school or anyone else saying it owns software you write, then you and we need a signed document from them disclaiming any rights they may have to the software. The disclaimer should be signed by a vice president, general manager, or anyone else who is authorized to assign software owned by them. Here is a sample wording: As a general rule, get everything in writing. The below will suffice. Email is fine, paper is better. The project needs a copy (or, better yet, the original) of the document. Here's some sample text: ACME Corporation (Company) hereby disclaims all copyright interest in the code written by Jane Doe for the program [insert name of program] (Program), including original Program code and documentation and support files, changes and enhancements to the Program and files, and any future modifications of the Program and files. We do not consider the code as work made for hire for us. Company affirms that it has no other intellectual property interest that would undermine this release, or the use of the Program, and will do nothing to undermine it in the future. [signature of John Smith], 30 March 2006 John Smith, Vice President, ACME Corp. Ideally, you would obtain this in writing and then get this on to James (vasille - at - softwarefreedom - dot - org, or use snail mail/fax from their web site). Cheers, Jeremy
Serial port problem - again
Hello. I'm new to this list. First I must say that I apologise for posting this mail again here. I hope you wine gurus can see what is going wrong here. If I run this app http://appdb.winehq.org/appview.php?iAppId=4165 with WINEDEBUG=+relay , I can transfer data from my device to PC, but not all of it. It stops somewhere in the middle of the transfer. Without +relay option, device is not even accesible. It just say: [EMAIL PROTECTED] ~]$ WINEDEBUG=+trace,+comm wine /home/romcek/.wine/drive_c/Program\ Files/SMA/Sunny\ Data\ Control/SDC.exe err:systray:delete_icon invalid tray icon ID specified: 0d fixme:tapi:lineInitialize (0x832f88, 0x11c, 0x11c2dfc, TAPICOMM, 0x832f8c): stub. fixme:tapi:lineGetDevCapsA ((nil), , 00010003, , 0xf7eaf8): stub. fixme:tapi:lineGetDevCapsA ((nil), , 00010003, , 0xf7eb2c): stub. fixme:ras:RasEnumEntriesA ((nil),(null),0xf7fc80,0x34f5d8,0xf7ec38),stub! fixme:ras:RasEnumDevicesA ((nil),0x34f60c,0x34f608),stub! fixme:ras:RasEnumDevicesA (0x777fe0,0x34f60c,0x34f608),stub! trace:comm:GetCommState handle 0x144, ptr 0x34f9b8 trace:comm:io_control 0x144 IOCTL_SERIAL_GET_BAUD_RATE (nil) 0 0x34f988 4 0x34f914 trace:comm:io_control 0x144 IOCTL_SERIAL_GET_LINE_CONTROL (nil) 0 0x34f98d 3 0x34f914 trace:comm:io_control 0x144 IOCTL_SERIAL_GET_HANDFLOW (nil) 0 0x34f970 16 0x34f914 trace:comm:io_control 0x144 IOCTL_SERIAL_GET_CHARS (nil) 0 0x34f982 6 0x34f914 trace:comm:GetCommState OK trace:comm:dump_dcb bytesize=8 baudrate=19200 fParity=0 Parity=0 stopbits=1 trace:comm:dump_dcb ~IXON ~IXOFF trace:comm:dump_dcb fOutxCtsFlow=0 fRtsControl=0 trace:comm:dump_dcb fOutxDsrFlow=0 fDtrControl=1 trace:comm:dump_dcb ~CRTSCTS trace:comm:dump_dcb bytesize=8 baudrate=19200 fParity=0 Parity=0 stopbits=1 trace:comm:dump_dcb ~IXON ~IXOFF trace:comm:dump_dcb fOutxCtsFlow=0 fRtsControl=1 trace:comm:dump_dcb fOutxDsrFlow=0 fDtrControl=1 trace:comm:dump_dcb ~CRTSCTS trace:comm:io_control 0x144 IOCTL_SERIAL_SET_BAUD_RATE 0x34f988 4 (nil) 0 0x34f914 trace:comm:io_control 0x144 IOCTL_SERIAL_SET_LINE_CONTROL 0x34f98d 3 (nil) 0 0x34f914 trace:comm:io_control 0x144 IOCTL_SERIAL_SET_HANDFLOW 0x34f970 16 (nil) 0 0x34f914 trace:comm:io_control 0x144 IOCTL_SERIAL_SET_CHARS 0x34f982 6 (nil) 0 0x34f914 trace:comm:io_control 0x144 IOCTL_SERIAL_SET_QUEUE_SIZE 0x34f98c 8 (nil) 0 0x34f930 fixme:comm:set_queue_size insize 1024 outsize 1024 unimplemented stub trace:comm:io_control 0x144 IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x61b196c8 20 0x61b19660 trace:comm:io_control 0x144 IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x61b196c8 20 0x61b19660 trace:comm:io_control 0x144 IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x61b196c8 20 0x61b19660 trace:comm:io_control 0x144 IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x61b196c8 20 0x61b19660 trace:comm:io_control 0x144 IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x61b196c8 20 0x61b19660 last line is repeating and then nothing hapens. It looks like delay issue to me, but I'm not a programmer. Can someone help, plese. Thanks, Ales
modification to allow -Wcast-qual to find potential warnings without unicode.h causing them
Assuming it is valid and does what is required, maybe the following pragma would be more precise. #pragma GCC diagnostic warning -Wwrite-strings -- Andy.
Re: modification to allow -Wcast-qual to find potential warnings without unicode.h causing them
Of course, what I should have written was: Assuming it is valid and does what is required, maybe the following pragma would be more precise. #pragma GCC diagnostic ignored -Wcast-qual Sorry. I did too much cutting and pasting, and not enough thinking. -- Andy.
Re: modification to allow -Wcast-qual to find potential warnings without unicode.h causing them
Mike Schaadt wrote: I attempted using the suggested '#pragma GCC diagnostic ignored -Wcast-qual' in replace of what I submited, however I received the warning 'ignoring #pragma GCC diagnostic' message, plus the normal warnings from unicode.h My guess is that I might be using an older version of gcc that doesn't support that feature. My version of gcc is 4.1.2, the version that comes with ubuntu. Should I upgrade my version of gcc, or should I leave the pragma instruction as it was? What is the wine standard version of gcc? Hi Mike, Yes, you are right: I tried it, too, and got the same result. GCC 4.1.2. is the latest version, so I'm not sure why this pragma is being ignored. I was hoping it might be a way of supressing the cast-qual warnings for this file, without suppressing other warnings, too. -- Andy.
-Wcast-qual result
I submited a patch today that modified unicode.h that disables warnings(which allows for -Wcast-qual to actually give relevant results) I don't know if it will be accepted or not(it has the potential of being problematic if modifying unicode.h that would normally result in a warning, but this patch would cause it to be suppresed), but I figured I would at least share the results I found. after configuring with cast-qual, I stored the warnings that resulted(which I've included as an attachment for those that are interested.). There were no warnings in the make depend, and make generated 545 warnings(all from .c files). The included file does not contain the sub directory for what file generates the warning. If anyone knows how to pull that data, let me know and I'll redo it and extract that information as well. I plan on start looking through these and working on fixing some here soon, but I thought I would share what I found with this group in general. cast-qual.result Description: Binary data
Fwd: wined3d: Update cursor position on ShowCursor
Request for comments, as per http://www.winehq.com/site/sending_patches.
For details on the need for this patch please see Bug
#7542http://bugs.winehq.org/show_bug.cgi?id=7542.
Thanks!
Erich Hoover
[EMAIL PROTECTED]
-- Forwarded message --
From: Erich Hoover [EMAIL PROTECTED]
Date: Mar 3, 2007 6:46 PM
Subject: wined3d: Update cursor position on ShowCursor
To: [EMAIL PROTECTED]
Real Name:
Erich Hoover
Description:
When ShowCursor is first called it should make the cursor appear at the
OS's last known cursor position. Because of this, some applications just
repetitively call ShowCursor in order to update the cursor's position. This
behavior is undocumented.
Changelog:
wined3d: Update cursor position on ShowCursor
From 0f41458d921e6fbcb0a6c4dec69589bc56898c93 Mon Sep 17 00:00:00 2001
From: Erich Hoover [EMAIL PROTECTED](none)
Date: Sat, 3 Mar 2007 18:43:11 -0700
Subject: wined3d: Update cursor position on ShowCursor
---
dlls/wined3d/device.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
index 0ad2c47..f536dd2 100644
--- a/dlls/wined3d/device.c
+++ b/dlls/wined3d/device.c
@@ -5246,10 +5246,20 @@ static void WINAPI IWineD3DDeviceIm
static BOOL WINAPI IWineD3DDeviceImpl_ShowCursor(IWineD3DDevice* iface,
BOOL bShow) {
IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *) iface;
BOOL oldVisible = This-bCursorVisible;
+POINT pt;
+
TRACE((%p) : visible(%d)\n, This, bShow);
if(This-cursorTexture)
This-bCursorVisible = bShow;
+/*
+ * When ShowCursor is first called it should make the cursor appear at the
OS's last
+ * known cursor position. Because of this, some applications just
repetitively call
+ * ShowCursor in order to update the cursor's position. This behavior is
undocumented.
+ */
+GetCursorPos(pt);
+This-xScreenSpace = pt.x;
+This-yScreenSpace = pt.y;
return oldVisible;
}
--
1.4.1
Fwd: kernel32: Implement ReplaceFileA/ReplaceFileW (revised)
Request for comments, as per http://www.winehq.com/site/sending_patches.
Thanks!
Erich Hoover
[EMAIL PROTECTED]
-- Forwarded message --
From: Erich Hoover [EMAIL PROTECTED]
Date: Mar 3, 2007 2:37 PM
Subject: kernel32: Implement ReplaceFileA/ReplaceFileW (revised)
To: [EMAIL PROTECTED]
Real Name:
Erich Hoover
Description:
Implements the functions ReplaceFileA and ReplaceFileW in kernel32 (Bug
#7544). This revision includes a lot of changes as a result of feedback
from Felix, see wine-devel for details. Also provides conformance test code
to ensure proper functionality.
Changelog:
kernel32: Implement ReplaceFileA/ReplaceFileW
From 9672111a9202dc9bd75d8af949678c270b4238bd Mon Sep 17 00:00:00 2001
From: Erich Hoover [EMAIL PROTECTED](none)
Date: Sat, 3 Mar 2007 14:18:48 -0700
Subject: kernel32: Implement ReplaceFileA/ReplaceFileW
---
dlls/kernel32/file.c | 200 ++--
dlls/kernel32/kernel_private.h |3
dlls/kernel32/path.c | 23
dlls/kernel32/tests/file.c | 252
4 files changed, 448 insertions(+), 30 deletions(-)
diff --git a/dlls/kernel32/file.c b/dlls/kernel32/file.c
index f92d37a..d6c5472 100644
--- a/dlls/kernel32/file.c
+++ b/dlls/kernel32/file.c
@@ -163,6 +163,46 @@ static BOOL check_dir_symlink( FIND_FIRS
}
+/**
+ * FILE_copy_contents (internal)
+ *
+ * Copy the contents of a file handle into another file handle.
+ */
+BOOL FILE_copy_contents(HANDLE source, HANDLE destination)
+{
+static const int buffer_size = 65536;
+BOOL ret = TRUE;
+char *buffer;
+DWORD count;
+
+/* Create a copying buffer */
+if (!(buffer = HeapAlloc( GetProcessHeap(), 0, buffer_size )))
+{
+SetLastError(ERROR_NOT_ENOUGH_MEMORY);
+return FALSE;
+}
+/* Perform actual copy operation */
+while (ReadFile( source, buffer, buffer_size, count, NULL ) count)
+{
+char *p = buffer;
+while (count != 0)
+{
+DWORD res;
+if (!WriteFile( destination, p, count, res, NULL ) || !res)
+{
+ret = FALSE;
+break;
+}
+p += res;
+count -= res;
+}
+}
+/* Free the copying buffer */
+HeapFree( GetProcessHeap(), 0, buffer );
+return ret;
+}
+
+
/***
* FILE_SetDosError
*
@@ -1531,10 +1571,124 @@ BOOL WINAPI ReplaceFileW(LPCWSTR lpRepla
LPCWSTR lpBackupFileName, DWORD dwReplaceFlags,
LPVOID lpExclude, LPVOID lpReserved)
{
-FIXME((%s,%s,%s,%08x,%p,%p)
stub\n,debugstr_w(lpReplacedFileName),debugstr_w(lpReplacementFileName),
-
debugstr_w(lpBackupFileName),dwReplaceFlags,lpExclude,lpReserved);
-SetLastError(ERROR_UNABLE_TO_MOVE_REPLACEMENT);
-return FALSE;
+BY_HANDLE_FILE_INFORMATION ifoReplaced, ifoReplacement;
+HANDLE hReplaced, hReplacement, hBackup;
+BOOL skipBackup = FALSE, ret = FALSE;
+
+if (dwReplaceFlags)
+FIXME(Ignoring flags %x\n, dwReplaceFlags);
+/* First two arguments are mandatory */
+if (!lpReplacedFileName || !lpReplacementFileName)
+{
+SetLastError( ERROR_INVALID_PARAMETER );
+return FALSE;
+}
+/*
+ * Open the replacement file for reading, writing, and deleting
+ * (writing and deleting are needed when finished)
+ */
+if ((hReplacement = CreateFileW(lpReplacementFileName,
+GENERIC_READ | GENERIC_WRITE,
+FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
+NULL, OPEN_EXISTING, 0, 0)) == INVALID_HANDLE_VALUE)
+{
+return FALSE;
+}
+/* Obtain the file attributes from the replacement file */
+if (!GetFileInformationByHandle( hReplacement, ifoReplacement ))
+{
+WARN(GetFileInformationByHandle returned error for %s\n,
debugstr_w(lpReplacementFileName));
+goto replace_fail_1;
+}
+/* Open the replaced file for reading and writing */
+if ((hReplaced = CreateFileW(lpReplacedFileName, GENERIC_READ |
GENERIC_WRITE,
+FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING,
+ifoReplacement.dwFileAttributes, hReplacement)) ==
INVALID_HANDLE_VALUE)
+{
+if ( GetLastError() == ERROR_FILE_NOT_FOUND )
+{
+/* If replaced does not exist then create it for the write, but
skip backup */
+if ((hReplaced = CreateFileW(lpReplacedFileName, GENERIC_READ |
GENERIC_WRITE,
+FILE_SHARE_WRITE, NULL, CREATE_ALWAYS,
ifoReplacement.dwFileAttributes,
+hReplacement)) == INVALID_HANDLE_VALUE)
+{
+goto replace_fail_1;
+}
+skipBackup = TRUE;
+}
+else
Re: Alexandre Julliard : advapi32: Fixed registry test that failed because of a buffer overflow.
On 3/8/07, Alexandre Julliard [EMAIL PROTECTED] wrote: Module: wine Branch: master Commit: 7e2228f15aa7a6fc0d63fe36c34906035422e95a URL: http://source.winehq.org/git/wine.git/?a=commit;h=7e2228f15aa7a6fc0d63fe36c34906035422e95a Author: Alexandre Julliard [EMAIL PROTECTED] Date: Thu Mar 8 21:06:31 2007 +0100 advapi32: Fixed registry test that failed because of a buffer overflow. The test passes in Windows, so isn't this hiding a bug in our implementation of RegSetValueW? -- James Hawkins
Re: Command and Conquer 3 Demo
Alexander Nicolaysen Sørnes wrote: Not all users are experiencing the crashes, perhaps a SMP issue? may be it I do have a dual-core system
Re: quartz: Use proper alloc/free functions for COM objects
On Thursday 08 March 2007 08:14:54 am you wrote: While reading your Patch, I see the above Places, where the result from the allocation is used without a NULL-check. The other allocations are checked for NULL before used. Is this correct? It should NULL check, but I was mainly concerned with just using/matching the right allocator functions (HeapAlloc is failable just like CoTaskMemAlloc, and if there wasn't a NULL check before, there isn't now). I can make in another patch to add missing NULL checks, though.
Re: comctl32: listview tests
On 3/8/07, George Gov [EMAIL PROTECTED] wrote: @@ -573,10 +699,242 @@ static void test_redraw(void) trace(invalidate update\n); InvalidateRect(hwnd, NULL, TRUE); UpdateWindow(hwnd); -ok_sequence(sequences, LISTVIEW_SEQ_INDEX, redraw_listview_seq, redraw listview, FALSE); +ok_sequence(sequences, LISTVIEW_SEQ_INDEX, redraw_listview_seq, redraw listview, TRUE); This test succeeds for me, so I'm not sure why you marked it as todo. - Lei
Tackling gdiplus?
An increasing number of apps need gdiplus.dll. Seems like it's time for Wine to include it. Since Mono has implemented much of gdiplus already ( http://www.mono-project.com/Libgdiplus ), we ought to be able to just slurp that into Wine and get quite a ways. Any objections? I'm thinking of asking a summer intern to try this. - Dan
