oleaut32: SafeArrayDestroyData

[Walt Ogburn]

Hi,

I am working on getting a scientific / engineering application called
SRIM (www.srim.org), specifically the batch-mode component SRModule of
SRIM 2003.  This is a Visual Basic program, so there's lots of reliance on
oleaut32.dll.

In addition to freeing the data memory of the SafeArray, Wine's
implementation of SafeArrayDestroyData sets the pointer pvData to
NULL.  The native Windows version apparently does not do this, and SRIM
depends on pvData still pointing to the same place afterwards.  Wine's
code also uses this nulling to keep track of the memory, so that it won't
get freed again.  I can't say why a program would still want pvData after
a call to SafeArrayDestroyData, but there it is.

Could the flag FADF_DATADELETED be used to keep track of this instead?
That seems to be the case only for vector SafeArrays now.  The following
patch seems to make SRIM work:

===================================================================
Index: dlls/oleaut32/safearray.c
===================================================================
RCS file: /home/wine/wine/dlls/oleaut32/safearray.c,v
retrieving revision 1.40
diff -u -r1.40 safearray.c
--- dlls/oleaut32/safearray.c   20 Sep 2004 19:11:48 -0000      1.40
+++ dlls/oleaut32/safearray.c   18 Oct 2004 17:03:51 -0000
@@ -1254,7 +1254,7 @@
   if (psa->cLocks)
     return DISP_E_ARRAYISLOCKED; /* Can't delete a locked array */

-  if (psa->pvData)
+  if (psa->pvData && !(psa->fFeatures & FADF_DATADELETED))
   {
     /* Delete the actual item data */
     if (FAILED(SAFEARRAY_DestroyData(psa, 0)))
@@ -1265,7 +1265,8 @@
     {
       if (!SAFEARRAY_Free(psa->pvData))
         return E_UNEXPECTED;
-      psa->pvData = NULL;
+      /* psa->pvData = NULL; */
+      psa->fFeatures |= FADF_DATADELETED;
     }
     else
       psa->fFeatures |= FADF_DATADELETED; /* Mark the data deleted */
===================================================================

Also, is there a way to make the tests in oleaut32/tests/ run on the
native dlls?  If so, I could more clearly show that the Windows version
doesn't null pvData.

Thanks,
Walter

[Hans Leidekker]

On Monday 18 October 2004 19:19, Walt Ogburn wrote:
> Also, is there a way to make the tests in oleaut32/tests/ run on the
> native dlls?  If so, I could more clearly show that the Windows version
> doesn't null pvData.

Wine's build system has support for cross compiling tests into PE
executables with MinGW. You can then run these on Windows of course,
or on Wine with:

WINEDDLOVERRIDES="oleaut32=n" wine oleaut32_crosstest.exe <yourtest>

after you've put a native oleaut32.dll in ~/.wine/drive_c/windows/system
Cross compiling tests is documented here:

http://winehq.org/site/docs/wine-devel/cross-compiling-tests

Alternatively you could carry over the source for the tests to a
Visual C installation and it should build there as well. This
is also documented on the site.

-Hans

[Walt Ogburn]

Hi hans,

Thanks, I hadn't thought of doing it that way.  That was very useful.

The result is that SafeArrayDestroyData shouldn't do anything if
FADF_STATIC is set for that array.  I'll submit a test and a fix for that.

- Walter

On Mon, 18 Oct 2004, Hans Leidekker wrote:
> On Monday 18 October 2004 19:19, Walt Ogburn wrote:
> > Also, is there a way to make the tests in oleaut32/tests/ run on the
> > native dlls?  If so, I could more clearly show that the Windows version
> > doesn't null pvData.
>
> Wine's build system has support for cross compiling tests into PE
> executables with MinGW. You can then run these on Windows of course,
> or on Wine with:
>
> WINEDDLOVERRIDES="oleaut32=n" wine oleaut32_crosstest.exe <yourtest>
>
> after you've put a native oleaut32.dll in ~/.wine/drive_c/windows/system
> Cross compiling tests is documented here:
>
> http://winehq.org/site/docs/wine-devel/cross-compiling-tests
>
> Alternatively you could carry over the source for the tests to a
> Visual C installation and it should build there as well. This
> is also documented on the site.
>
> -Hans