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