Hi Robert:
It has been made clear several times in this thread, that one must use the
FSX SDK from MS-FSX Deluxe and Acceleration DVDs with either MS-FSX or FSX: Steam Edition; alternatively the downloadable LM-P3D version
1.4x SDK (only) may be used with either version of FSX.
It has been quite some time (year 2006) since I tinkered with trying to get the SDK and other 3rd party DLL Modules to run through repeated re-installs / removals etc.
However, I do recall
another factor which may need to be addressed in addition to the thus far mentioned editing of entries made in the 'active' copy of
DLL.XML.
IIRC, each time one installs the SDK, that installer auto-configures the entry for OPT in
DLL.XML to be
disabled.
When one manually edits that entry for OPT in
DLL.XML to instead '
enable' OPT, on the next restart of FSX, a
prompt for permission to run that OPT Module should appear that requires a reply by the end user.
FYI: This "should" occur
regardless of how Windows UAC and/or any other security utility functions are configured.
Based on the reply by the end user at the above cited FSX startup security prompt, an additional entry with a [
key code string=0,1,2 etc.] suffix is written
not into DLL.XML, but rather into
FSX.Cfg under the
[Trusted] sub-section of that file.
BTW: Regardless of how many times I edited the entries in
DLL.XML, I could not get some Modules (especially SDK Modules, and/or Flight1's Instant Scenery and AFX) to run; this proved to be because of my interrupting the installers' intended work-flow by editing the DLL.XML immediately after the installer finished, and therefore via my interrupting the
intended next phase of Module configuration that 'should' have been allowed to occur during the very next startup of FSX.
In the case of those (earlier) version numbers of Instant Scenery and AFX, I found that I had to allow Modules to 'finish' being 'fully installed and activated' in a 'windowed' FSX task session, and I had to
refrain from editing the
DLL.XML entry for both modules ...so that the Module
launch from DLL.XML could 'auto-run' (without end user manual editing to re-enable the entry) ...
during the very next FSX startup after installation of the Module.
Intrigued, I utilized SysInternals' FileMon (predecessor to ProcMon) to scan for- and analyze- what among the (literally) millions of line entries appeared to taking place when those Modules attempted to run in FSX.
The logged permutations of what security coding protocols were running in the subsystem of both FSX-related files and Windows sub-systems were mind-numbing.
Incidentally, the default "phone home" methodology to utilized by certain add-on Modules to automatically check for updated versions online by finding / forcibly utilizing an 'available' internet connection to do so, raised potentially ominous questions as to where exactly certain connectivity coding techniques had their origin in the "Eastern Bloc", as such unique coding signatures and functionality could only be found in public discussions from the "dark side" of the 'InterWeb' at that time.
Now of course, we have available a coding mechanism for such connectivity which utilizes later versions of Windows'
.NET which may reduce risk for proprietary and/or otherwise 'misbegotten' connectivity methods being exploited by 3rd parties for nefarious purposes.
But, my point is, a Windows User Permissions security prompt 'should' appear the first time any such Module is run as a child process in the FSX Windows task session, and when permission is granted by the end user, an entry is written into
FSX.Cfg.
IMHO, to successfully re-install and activate a SDK or add-on Module, one must first remove its entry from
both DLL.XML and FSX.Cfg under the
[Trusted] sub-section before attempting re-installation of the Module.
NOTE: In some scenarios where one has attempted multiple times to re-install a Module,
there may be multiple entries for the same Module within
FSX.Cfg under the
[Trusted] sub-section.
IIUC,
all those Module line item entries should be manually removed from
FSX.Cfg, along with any such entry in
DLL.XML if attempting re-installation of a Module known to otherwise be compatible with a specific version of FS one is using / configuring.
Then, after re-installing the Module (
ex: OPT by re-installing the SDK),
do NOT immediately edit the DLL.XML, and run FSX in a 'windowed' task session.
When the Module 'first run' security prompt appears, be sure to allow the Module to run
automatically every session
without requiring end user permission each time; this allows 'some' Module installers to work properly.
After the security mechanism does its 'voodoo' in the sub-system of FSX and Windows during the very next FSX startup
after installation, and
after exiting FSX, one can
later edit the
DLL.XML to require end user permissions to run on subsequent FSX sessions ...if desired.
Hope this helps with getting OPT to work for you.
GaryGB