>>>>We have an application which uses custom dll's registered through Regfn and RegFn32 calls into foxtools.fll depending on whether the environment is 16 bit or 32 bit.
>>>>
>>>>Everything works fine in WFW3.11, and in NT. However, when we are closing down the app in Windows 95, the now familiar message "VFP has performed an illegal operation..." pops up. This happens at the end of the calling program, after all objects and dll's have been cleared. (I have checked it, they are cleared).
>>>>
>>>>The code at this point reads "SET LIBRARY TO". Even if we remove this line, (the next line being "CLEAR ALL"), the same thing happens. It seems that when VFP is releasing FOXTOOLS.FLL in W95, something weird happens. However, if the code is compiled as an .app it seems to be fine!
>>>>
>>>>We are using VFP3.0. Grateful for any clues.
>>>>
>>>>Thanks
>>>
>>>Sanjay,
>>>
>>>Unfortunately, I don't have any experience with Foxtools under VFP 3.0. The only thing that I could suggest would be to use conditional compilation to use the DECLARE syntax for the DLL calls under 32 bit Windows. For 16 bit, of course, you'd still have to use RegFN().
>>>
>>>BTW, RegFN32() always makes calls to 32 bit DLLs (according to the documentation). RegFN() is dependent on the OS (16 bit DLLs under Win 3.1x, 32 under NT 3.51, 4.0 and Win 95).
>>
>>Thanks George. I did forget to mention that the DECLARE syntax also does not work! I have tried to debug it with the debug versions of the custom DLL, which I thought may be causing a problem, in C++, and there are no problems with the DLL itself since the crash occurs when control is passed back to VFP.
>>
>>One thing I did note however. One particular function call's address space (in the DLL) seems to be violated as it returns the space occupied by the function, say 126 bytes, PLUS an additional 21 bytes. That means that it is reading rubbish from an additional 21 bytes. Its almost as if VFP realises it has screwed up memory somewhere, and it realises that rather late!
>>
>>If you can think of something meanwhile, please do let me know. I promise to keep you posted.
>
>About the only thing I can suggest is to rely on RegFN() only. Of course, you'll have to rely on conditional compilation a great deal, especially if you utilize functions in Win32 that aren't available in Win 3.

George, thanks for all your help. The problem was not in Foxtools.FLL! Since I promised to keep you posted, here it is. It's to do with OLE automation!!

The DLL which we use makes calls to start an OLE session with a 3270 emulator. It so transpires that because the calling application was a VFP .exe, the handle to the OLE session was being passed to VFP from the DLL on startup. On shutdown, all hell breaks loose!

VFP, being the 'good' memory handler it is, sees the OLE session's handle as its own creation and promptly shuts it down. Meanwhile, MFC code lurking in the background DLL, having incremented a count internally from OleInitialize() now wants to OleUninitialize() since it is being removed from memory.

You guessed it. Since the calling app was VFP, MFC passes the exception to VFP to handle, which, by now, really knows nothing about it! So it gives us the routine "VFP has performed an illegal ..." error.

The moral of the story is to 'Always initialise and uninitialse OLE sessions from the calling executable, never from within a DLL or anywhere else'!