>Thank very much Ajay Mishra,
>But there are something to make clear.
>
>
>1. On client PC, I must use Clireg32.exe to register class name and Server IP into Windows's registry. So, there is no need to use CreateObjectEx

Yes, if you register the COM and specify where it is located you may use just CREATEOBJECT() for that. Another purpose of registering COM on the client is to speed up the execution. If COM type library is registered on the client, there is no need for the round trip to the type library registered on the server just to check out the COM interface.

>2. VFPCOM1 & VFPCOM2 running on the same server (OS: Windows 2000 Professional, Service pack 1, and I also install Visual Foxpro 7 Professional on this server)
>
>
>3. On Server PC, I must use Racmgr32.exe to "Alow Remote Activation". Note that: I only "Alow Remote Activation" for (VFPCOM1.C1) , not for (VFPCOM2.C2). So , How can clients create objects of C2 from other PC? I think, there is no way for users to create objects of C2 directly from other PCs.

If you do not allow the remote activation, then you cannot run your COM directly from the client PC.
RACMGR32.EXE is the old utility. I would suggest to use DCOMCNFG.EXE instead.

>4. I use "Automation Manager" to handle RPC, not DCOM.

You don't need to run Autmgr32.exe under Windows 2000 at all.


>5. All of needed files (such as: Racmgr32.exe , Clireg32.exe , Autmgr32.exe , Autprx32.dll), I copy them from my client Pc (OS: Windows 98, installed Visual Studio 6 - Service Pack 5) to server. They can run on Windows 2000 smoothly but i am not sure THIS IS THE REASON or not.
>
>
>6. All things DO WORK fine if my server's OS is Windows98.
>
>
>I am still waiting for your helps , guy.
>Thank a lot