>>>>If you have the option of installing Windows Scripting Host version 2.0 or later, the Wscript.Network COM object can alter the default printer setting programmatically, and it can be instanced from VFP. Unlike the assignment of printer output using SET PRINTER, it's visiable to the full Windows environment.
>>>
>>>What I need to include to my install program for using Windows Scripting Host feature? What the DLL or OCX?
>>
>>It's a bunch of them; you can download the self-installing distribution executable from the Microsoft scripting site in my signature block. This will install the current WSH components on just about any system with Win95 and the Y2K patches, WinNT SP3 or later, Win98 or Win2K (which already has WSH 2.0 on it.) Win95 retail and WinNT that have not been patched to correct the initial releases will not support the WSH without bringing the target system (reasonably) up-to-date.
>
>Hmmm.. Then.. If I develop commerce application I must to belive so microsoft not change anything in COM calls in the future.. and I can't install this component from my install application. I think it is not good :(

If you are using an installer, it can fire the self-installing executable after testing for a supportable version of the OS, which you ought to be doing IAC to make sure that things like the DCOM support files are in place, and monitor for any required reboot during the sequence. For a commercial install, this degree of control is pretty much necessary from my POV.

AFA reliance on the COM components, the WSH COM Objects are about as likely not to provide backwards compatibility as the underlying Win32 APIs they're built on; they're used by things like ASP, IE and many of the MS development platforms. I simply put the freely-redistributable executable into my install, test for the necessary OS compatibility, and run the executable if necesssary. YMMV.