Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Problems with Post-Setup Executable DCom98.EXE in Setup
Message
From
11/12/1998 19:21:29
 
 
To
11/12/1998 17:28:34
Koos Veel
Gamma Research
Aruba
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00166630
Message ID:
00166821
Views:
23
>Hello Ed,
>
>>>How can we solve this problem with the post-setup executable?
>>
>>First, don't make DCOM a part of a Setup Wizard install; it is not appropriate for use with WinNT (installing SP3 or SP4 is the correct action to take with NT) and can cause a reboot to occur. If you want to incorporate DCOM into an install, write the install with another tool that can handle a split install by writing a RunOnce key to restart the install process after DCOM compeltes installing and rebooting.
>
>Well we use the setupwizard of VFP 6.0. Since InstallShield cost to much time to research we decided to keep to VFP 6.0. We decided to just include the DCOM98.EXE file in the setup filelist. So it get's copied to the executable directory of the application.

That's fine. What do you do when you discover NT running SP1 or SP2? And, more importantly, what if you have something to run post-setup besides DCOM?

>
>>
>>I'd recommend that your application simply check for the Reigstry Key HKEY_LOCAL_MACHINE\Software\Microsoft\OLE with a registry key value EnableDCOM to determine if DCOM is present; if not, use a Messagebox to display a warning to your user without activating a top-level form or the VFP main window, and then shut down. This will avoid the C0000005 error that most people associate with missing DCOM support; do this before any splash screen has been run.
>
>Hmm well we tried to use the registry class which was supplied with VFP to get the keyvalue but it always returns a code -105 (or something). We tried it like this:
>
>SET CLASSLIB TO registry ADDITIVE
>oRegist = CREATEOBJECT('registry')
>
>Test = oRegist.GetKeyValue("Software\Microsoft\OLE\EnableDCOM", "Y")
>WAIT WINDOW STR(Test)
>
>How do we call this routine so it DOES work? Because it has to give a return code 0. We checked in REGEDIT and the value of this key is set to "Y". So that shouldn't be a problem.

You have to open a registry key before reading a value - EnableDCOM is a registry value of the key "Software\Microsoft\OLE". Using the VFP reigstry class, you'd do something like:
IF oRegist.OpenKey("Software\Microsoft\OLE\EnableDCOM",HKEY_LOCAL_MACHINE, .F.)
   cKeyVal = ''
   IF oRegist.GetKeyValue("EnableDCOM",@cKeyVal) = 0
   IF Test = 0
      ? "Key value = " + cKeyVal
   ELSE
      ? "Key exists, no value exists"
   ENDIF
ELSE
   ? "Key doesn't exist"
ENDIF
>
>Because we want to execute the DCOM98.EXE file if the return code isnt't equal to 0. We use RUN /N SETUP\DCOM98.EXE /Q to execute it.

This is dangerous, since the DCOM98 may force a reboot during install, and you definitely will have some shred .DLLs loaded at the poiunt that DCOM is invoked.

>
>We want to do it as automaticly as possible. So that the user doesn't have to do anything. We make a application with about 100 (or more) customers and we don't want to tell them that they have to execute the DCOM98.EXE file.
>
>Do you have another elegant solution to our problem?

You don't have to write in InstallShield (I do, because I have it and know it pretty well, and it does a lot of setup-related things well); the Windows Scripting Host would be a good choice (it's free, has support for JSCRIPT and VBSCRIPT, and oiffers a whole lot of stuff that's useful to your VFP environment as well in terms of additional automation objects), or even something like WinBatch (available on Shareware.com).

>
>Thanks in advance!
>
>Christian
>Using the account of Koos Veel
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform