IMPORTANT; Please note that I've some difficultly with my hands after working on systems all day, so I'll be using CAPS to emphasize some points that should be given extra attention to detail, not to be rude or shout, just type more easily and clearly. Thank
you in advance for your understanding.
Okay, covering this at large because I've found this issue with two classic Star Wars Games that I dug out (I've got the patches for updating saved in an archive) and used for testing because the arts department needs access to just about every API there
is going forwards and backwards.
That being said, using a few games for testing is the best option, and most perform quite well.
Here are the titles:
1 - Star Wars Battlefront II (Non-Steam, Non GoG - Worked fine on 7 64-bit)
2 - Star Wars Galactic Battlegrounds (Non-Steam, Non GoG - Worked fine on 7 64-bit)
Both have patches that update them to v1.1. and the patches have been installed.
Drivers, registry entries, etc. have been gone over with a fine toothed comb; including with SysInternals and manual edits of registry and file placements for related files as needed. In short, the aim is for a perfect corporate image and we've been testing
for three weeks.
Here's what we know will NOT, does NOT, and will NEVER work:
1 - Stop discussing the June 2010 libraries' web installer and limit the discussions to the parameters shared here in item " 4 - ". EPIC FAIL because:
A - DXDiag does not give the whole story of all of the DirectX files on any system, but rather ONLY reports whatever the highest version is that the OS has installed.
B - The libraries will at least install when using the offline installer (the one that unpacks DXSETUP.exe)
C - The DXWebSetup.exe (has to be run as Admin to ever start) will not move through the install procedure after clicking "next" and gives the following message:

2 - It's clear that many of the people here... (not all the people, just a lot of the people) ...have limited experience with hardware. My employer requires 10 years of hardware experience in a PC environment just to get into the software development or
the administration departments for the very reason that's likely caused a lot of the misinformation being tossed around on this post.
Please bear in mind this is just polite observation at work, so if this doesn't apply to you, then just dismiss it.
Here's what everyone needs to know about hardware:
A - Test it.
B - Our new workstation build's hardware was previously tested on Windows 7 64 bit, and the above games worked fine as did all DX9 and above apps.
C - Drivers are SOFTWARE and have NOTHING to do with HARDWARE.
D - The PURPOSE of DRIVERS is SOLELY to assist the operating system (ANY OS; All Windows Versions, Linux, Mac, etc.) in understanding what the HARDWARE's limits are. DRIVERS ARE SOLELY A SOFTWARE BRIDGE BETWEEN THE OS AND THE HARDWARE.
E - Just like iMovie or any Apple editing suite SOFTWARE products can't be run on Windows, some DRIVERS will have VERSIONS that are NOT COMPATIBLE WITH A NEWER VERSION OF WINDOWS.
F - If the HARDWARE FUNCTIONS in ONE SOFTWARE OS environment, it is CAPABLE of FUNCTIONING in ANY SOFTWARE OS ENVIRONMENT
IF ALL THE SOFTWARE FOR THE OS IS COMPATIBLE WITH BOTH THE OS AND EXPLOITING THE HARDWARE'S FEATURES ALL DONE AT THE SOFTWARE LEVEL through COMPATIBLE SOFTWARE DRIVERS.
IMPORTANT NOTE: "Software Drivers" and "Virtual Drivers" FOR "Virtual Devices" are NOT THE SAME. Apples and Oranges by comparison where the only thing they have in common is that they both have seeds (They both are PROGRAMMED SOFTWARE of DIFFERENT CLASSIFICATIONS
in that "Virtual Drivers" FOR "Virtual Devices" are essentially SOFTWARE TO SOFTWARE Drivers, and" "Software Drivers" are actually programmed for a piece of HARDWARE).
3 - Windows 10 is still an evolving platform, and many people and businesses will test the software (Windows 10) prior to fully migrating to it using upgrade options, but rather performing cold installs on blank or newly formatted hardware to learn what
their options are for the tasks they perform and what adaptations need to be made such as not using an older version of AutoDesk or some such adjustment to estimate costs for new software as well.
A - In November of 2015, Windows 10 changed drastically as was noted through various sources and articles we've found through our own testing process. Far too many to list, so don't ask.
B - One of the major changes was that Microsoft is trying to completely automate Windows Updates. As an Admin, I think this is a great idea; however it comes with several disadvantages for everyone including Microsoft;
1B - Microsoft has not kept up its drivers catalog since about 2004 as was able to be used in Internet Explorer in Windows 98 through XP. It's still present, and accessible if you know how to get IE to access it, but the drivers kept within it are very
old and outdated.
2B - Many software developers don't bother purchasing certificates that are Trusted so as to be able to sign drivers triggering many problems with both new OS'es (not just MS) and API's such as DirectX. At SLI (My Employer), we've an X.500 ID that allows
us to run an ANSI certified TLD that we keep largely internal, so we may perform this task. Since we own the rights, costs are low, and as a result developers have gotten fired for not E-Signing their work with applicable SLI credentials. If other companies
were as strict as SLI about this, DirectX would never have a problem verifying WHQL data, and Microsoft would likely not have abandoned their driver Catalog for so long, that is otherwise an excellent feature.
3B - Microsoft is not ready to take on the responsibility of system drivers because a PC marketplace has far too much software and hardware variety for such an undertaking short of starting a brand new MS Driver Catalog with a full time team that updates
it 24/7/365 to keep up with the PC industry while Apple is so inflexible with limited variety such a goal as is already in place is more realistic at the cost of having much choice in software and hardware configuration to the consumer and/or enterprise. MS
please stop trying to be something that you're not because the thing that you're not is actually why many of those in the PC marketplace choose Microsoft. :D
C - If anyone does a clean install of Windows 10 using the installation media that was setup before November of 2015, DirectX 9.0C libraries MAY work TEMPORARILY, but as soon as all November 2015 updates and after are installed, the same problem WILL OCCUR
AGAIN.
***SIGH***
4 - Now that hopefully everyone has learned something helpful that is beneficial to understanding the fundamental issues at hand with this problem I will note what has been observed so far in testing the apps I mentioned in this post first:
A - Unpacking the June 2010 libraries for DirectX 9.0C will be part of the solution.
B - Unpacking the CABS (Not sure which ones yet) AFTER the unpacking of the June 2010 libraries for DirectX 9.0C will be part of the solution.
C - Running the "DXSETUP.exe" of the June 2010 libraries is part of the solution since it will fully run, and it is always wise to make Windows perform its own maintenance whenever possible.
D - Running the "DXSETUP.exe" of the June 2010 libraries only results in a partial install of DirectX 9.0C because upon inspection of either the C:\Windows\System32 or C:\Windows\SysWOW64 folder it's very noticeable many essential DirectX 9.0C Dll files
are missing and further; do not have counterparts (FILES WITH THE SAME NAME) such as were included with DirectX 11 and below.
E - Depending on whether a system is running on 64-bit Windows 10 or 32-bit (x86) Windows 10 will have an impact on which DLL's need to be manually transferred to either C:\Windows\System32 , C:\Windows\SysWOW64 , or both.
We'll keep everyone here posted on the solution's specifics once we find it at SLI, or perhaps maybe even find, there isn't one. If there's a real solution though, we'll find it.
SLI - IT Deployments - Chief Analytics Officer