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