More On VFP and Windows XP XP2 NX ... Samples and What-not (by John Koziol)

  • Article

For background information, please refer to my prior post on this topic.  Also, there's an excellent paper on advanced COM and VFP in particular, located at https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnfoxgen7/html/vfpandcom.asp 

As aforementioned, the problem with the NX switch is that it makes early binding a no-no for COM. Now, if you've created a COM DLL with VFP and it's being called from a client using early binding, then the client code has to be changed. The VFP code is fine.

“So what do I have to do differently in my VFP code to comply with the NX switch being on?“, you might reasonably ask. “Stay the bloody hell away from CREATEOBJECTEX()” would be my answer, that is, after a few drinks or particularly bad session feedbacks. Seriously, the following mantra applies:

“CREATEOBJECT, NEWOBJECT good!. CREATEOBJECTEX bad!“

Now there are cases where a COM object must be instantiated using CREATEOBJECTEX, fer instance, where a remote server computer has to be named or the COM server does not support an iDispatch interface. What to do then?

Well, the NX switch can be toggled per process, so a particular COM DLL that requires NX = OFF can be dealt with. Refer to the links I posted in my earlier post on this topic.

Here's some code. The first part of the code creates a simple DLL.  

*:*************************************
*:* Create a simple VFP DLL.
*:*
*:* Calvin Hsia and John Koziol
*:*
*:*************************************
*:* Create a simple VFP DLL
*:*************************************

IF FILE("testnx.dll")
DECLARE integer DllUnregisterServer IN testnx.dll
?DllUnregisterServer()
CLEAR DLLS
ENDIF

SET TEXTMERGE TO testnx.prg
SET TEXTMERGE ON NOSHOW
\DEFINE CLASS testnx AS Session OLEPUBLIC
\PROCEDURE MyEval(cExpr)
\RETURN &cExpr
\ENDPROC
\ENDDEFINE
SET TEXTMERGE TO

BUILD PROJECT testnx FROM testnx
BUILD DLL testnx FROM testnx
*************************************************

OK, now here's guaranteed success for instancing the and calling the COM DLL under NX.  

*:*************************************
*:* Here's a good way to create the COM object -
*:* no early binding. NX compatible.
*:*************************************

ox=NEWOBJECT("testnx.testnx")
?ox.myeval("_VFP.ServerName")
RELEASE ox,oy

Here's a guaranteed exception under NX

*:*************************************
*:* Here's early binding, NOT NX compatible
*:*************************************

ox=CREATEOBJECTEX("testnx.testnx","","")
?ox.myeval("_VFP.ServerName")
RELEASE ox,oy

See? The only difference was I used NEWOBJECT in the good and CREATEOBJECTEX in th bad.

If I come across any other issues, I will post yet again. Until then, be thou not afraid of XP SP 2. It's cool, it's stable, and the security enhancements are going to be better for all of us in the long term.