[Mono-bugs] [Bug 324335] [Vista] Win32 Interop Issue

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=324335

User andyhume32 at yahoo.co.uk added comment
https://bugzilla.novell.com/show_bug.cgi?id=324335#c3


Andy Hume <andyhume32 at yahoo.co.uk> changed:

           What    |Removed                                         |Added
----------------------------------------------------------------------------
                 CC|                                                |andyhume32 at yahoo.co.uk




--- Comment #3 from Andy Hume <andyhume32 at yahoo.co.uk>  2008-12-23 07:01:57 MST ---
Does anyone know whether the original fault as seen in MWF itself is still
present?  Was it that the setting clipboard data failed on Vista?  As this
seems to be the same issue as fixed by bug 414446.  The SetClipboardData
argument is a memory __handle__ and not a pointer.  The sample shows the wrong
usage (AllocHGlobal returns a pointer!), which is as was fixed in MWF.



IIUC the sample output shows that the different behaviours is a fluke(?) of the
memory allocation in StringToHGlobalUni!  Windows no longer has a memory handle
table, so the handle/pointer value actually encodes which type it is [1].  In
the test results above showing the pointers in hex is illuminating, see the
last nibble.

Fails:
"hmem: 19459576" = 0x0128EDF8

Works:
"hmem:  2142512" = 0x0020B130

So in the first case Windows tries to dereference a handle, but in the second
just uses it directly as a pointer.

[1] See the blogs posts around the following.  The commenter here describes the
internals:
<http://blogs.msdn.com/oldnewthing/archive/2004/11/09/254441.aspx#254644>


-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.