Tackling gdiplus?

[Dan Kegel]

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

Re: comctl32: listview tests

[Lei Zhang]

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

Re: quartz: Use proper alloc/free functions for COM objects

[Chris Robinson]

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: Command and Conquer 3 Demo

[Matthew Clark]

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: Alexandre Julliard : advapi32: Fixed registry test that failed because of a buffer overflow.

[James Hawkins]

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

Fwd: kernel32: Implement ReplaceFileA/ReplaceFileW (revised)

[Erich Hoover]

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;
+ 

Fwd: wined3d: Update cursor position on ShowCursor

[Erich Hoover]

Request for comments, as per http://www.winehq.com/site/sending_patches.
For details on the need for this patch please see Bug
#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

-Wcast-qual result

[Mike Schaadt]

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

Re: modification to allow -Wcast-qual to find potential warnings without unicode.h causing them

[Andrew Talbot]

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.

Interesting Winelib report

[Jeremy White]

Hi Folks,

John Gilmore alerted me to an attempted use of Winelib by the Cairo folks:
  http://lists.freedesktop.org/archives/cairo/2007-February/009707.html

I've chatted privately with Behdad, who doesn't have a ton of time,
but would be willing to poke a bit further if he had some help.

I know that from time to time, people like to pick up this sort
of project as a fun one, and I thought I'd see if I could spark someone into
doing so with Cairo.

Cheers,

Jeremy

Re: modification to allow -Wcast-qual to find potential warnings without unicode.h causing them

[Andrew Talbot]

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.

modification to allow -Wcast-qual to find potential warnings without unicode.h causing them

[Andrew Talbot]

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: Don't compare file handles to NULL

[João Eiras]

Na , Alexandre Julliard <[EMAIL PROTECTED]> escreveu:


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.



Yes it does. INVALID_HANDLE_VALUE has value of -1. NULL is 0 in a x86  
architecture.

Serial port problem - again

[Aleš Rom]

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  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

Re: Work legalities

[NikNot]

If you signed any so called "intellectual property" contract with your employer,
go visit a lawyer, show him or her the contract and be prepared to pay for the
legal advice.

If not, it very much depends on the jurisdiction.

In a number countries that I know and operate in, if the only legal interaction
between the employer and employee is of generic employment nature,
anything that you create on your own time, with your own equipment and
without using any proprietory  technical knowledge that belongs to your
employer, you own and are free to do with as you please.

What Wine project might or might not require is up to them. (However, it is my
observation that most US entities (such as Wine) blindly assume that there is
only one jurisdiction in the world - US, and act accordingly :).

NikNot

Re: wine-devel Digest, Vol 20, Issue 30

[Alexandre Julliard]

Alessandro Pignotti <[EMAIL PROTECTED]> writes:

> It's not possible to write a conformance test because i'm using a flag 
> internal to wine's implementation of directplay, It's possible to safely 
> change "I think we should" with "we have to". I've used "i think" more as an 
> answer to the previous FIXME comment we have inherited from the author of the 
> code.

If you have fixed the FIXME then you should remove it. The source code
isn't the right place to start a discussion with the previous author ;-)

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: Work legalities

[Jeremy White]

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

Re: user32: avoid NULL pointer access in DefWindowProcA WM_NCCREATE

[Jan Zerebecki]

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: wine-devel Digest, Vol 20, Issue 30

[Alessandro Pignotti]

> Date: Thu, 8 Mar 2007 08:22:59 +0100
> From: Kai Blin <[EMAIL PROTECTED]>
>
> >/* FIXME: Should we be storing these dwFlags or the creation ones? */
> > -  lpPData = DP_CreatePlayer( This, lpidPlayer, lpPlayerName, dwFlags,
> > +  /* I think we should pass creation flags, so we can distinguish
> > sysplayers and not count them in the current + player total */
> > +  lpPData = DP_CreatePlayer( This, lpidPlayer, lpPlayerName,
> > dwCreateFlags, hEvent, bAnsi );
>
> Every time someone uses "I think" in the code, usually this calls for a
> test case. This one should be rather straightforward to test.
It's not possible to write a conformance test because i'm using a flag 
internal to wine's implementation of directplay, It's possible to safely 
change "I think we should" with "we have to". I've used "i think" more as an 
answer to the previous FIXME comment we have inherited from the author of the 
code.

Regards
Alessandro Pignotti
>
> Cheers,
> Kai
>
> --
> Kai Blin, 
> WorldForge developerhttp://www.worldforge.org/
> Wine developer  http://wiki.winehq.org/KaiBlin/
> --
> Will code for cotton.


-- 
Vi Veri Veniversum Vivus Vici
-Dr. Faustus -  Marlowe
Public GPG Key ID 0x650B3ED9 on subkeys.gpg.net
Key Fingerprint 6243 AAD3 E3EC 52D8 DFAA 2A2F 9FCD 0457 650B 3ED9
Encrypted mails are welcome


pgpCA3znxxTUK.pgp
Description: PGP signature

Re: quartz: Use proper alloc/free functions for COM objects

[Detlef Riekenberg]

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: Command and Conquer 3 Demo

[H. Verbeet]

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: user32: avoid NULL pointer access in DefWindowProcA WM_NCCREATE

[Felix Nawothnig]

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.

Felix

Re: Command and Conquer 3 Demo

[Alexander Nicolaysen Sørnes]

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: Writing a winelib plugin

[Dan Kegel]

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: [winealsa] Mind buffer loops when pausing

[Jan Zerebecki]

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: Don't compare file handles to NULL

[Francois Gouget]

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: Don't compare file handles to NULL

[Alexandre Julliard]

Francois Gouget <[EMAIL PROTECTED]> writes:

> 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.

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.

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: Don't compare file handles to NULL

[Francois Gouget]

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

[Michael Stefaniuc]

Alexandre Julliard wrote:
> 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.
Well, in one of the found cases (one of the RPCRT) the code was setting
the file handle manualy to NULL...

bye
michael
-- 
Michael Stefaniuc   Tel.: +49-711-96437-199
Sr. Network EngineerFax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart

Re: Don't compare file handles to NULL

[Alexandre Julliard]

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

[Francois Gouget]

On Wed, 7 Mar 2007, Michael Stefaniuc wrote:
[...]
> You mean something like
> http://people.redhat.com/mstefani/wine/smatch/scripts/file_handles.pl ?

Cool, thanks.


[...]
> Most are false positives (non NULL check before CloseHandle()).

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.


[...]
> dlls/rpcrt4/rpcss_np_client.c 92 RPCRT4_RpcssNPConnect(58) Comparision
> of the file handle 'the_pipe' with 0.
> programs/rpcss/np_server.c 393 RPCSS_NPConnect(57) Comparision of the
> file handle 'the_pipe' with 0.

These two combine with what looks like a very bad file handle leak 
(especially in rpcrt4).


Sending patches...


-- 
Francois Gouget <[EMAIL PROTECTED]>  http://fgouget.free.fr/
   Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

Re: Work legalities

[Shachar Shemesh]

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

Writing a winelib plugin

[Shachar Shemesh]

Hi all,

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?

Many thanks,
Shachar

Re: Alexandre Julliard : wine_common_ver: Set company name to Microsoft, some apps check for that.

[Alexandre Julliard]

Paul Chitescu <[EMAIL PROTECTED]> writes:

> Ummm, isn't this legally dangerous? Stamping a piece of code with
> Microsoft's name can be interpreted as counterfeiting.

Not really, it's just providing a string that apps require to behave
properly. The LegalCopyright field still says it's been written by the
Wine authors. It's similar to IE pretending to be Mozilla in its
user-agent string...

-- 
Alexandre Julliard
[EMAIL PROTECTED]