Quote Originally Posted by Dick Berg View Post
Bob,

I just wanted to comment on your thread above (http://forums.dc3.com/showthread.php...2119#post82119).

I installed the latest Windows version 2004 update a couple weeks ago. Yes, it installs the "new" broken JET .dlls, both labeled version 4.0.9801.24. But before installing the update, I had changed the Date Modified of each good working file (msjet40.dll and msrd3x40.dll) to the date of my planned update install. That didn't prevent the good .dlls from being overwritten with the newer bad ones.

So I replaced them once again with the good old files, only this time I changed their Product version/File version numberss to the current version number ...24. Now I'm waiting for another KB update to see whether a new update will replace those good files with the bad ones again. There has to be some cue that the update takes in order to know if it has to install new files - perhaps the version number is that cue.

In the meantime, other than this wrinkle, Windows 10 (2004) is working well for me.[/QUOTEQUOTE=Dick Berg;83653]Bob,

I just wanted to comment on your thread above (http://forums.dc3.com/showthread.php...2119#post82119).

I installed the latest Windows version 2004 update a couple weeks ago. Yes, it installs the "new" broken JET .dlls, both labeled version 4.0.9801.24. But before installing the update, I had changed the Date Modified of each good working file (msjet40.dll and msrd3x40.dll) to the date of my planned update install. That didn't prevent the good .dlls from being overwritten with the newer bad ones.

So I replaced them once again with the good old files, only this time I changed their Product version/File version numberss to the current version number ...24. Now I'm waiting for another KB update to see whether a new update will replace those good files with the bad ones again. There has to be some cue that the update takes in order to know if it has to install new files - perhaps the version number is that cue.

In the meantime, other than this wrinkle, Windows 10 (2004) is working well for me.

Hello Dick.

You don't have to wait until the next monthly update to test whether your changes to the DLL's identifiers are ignored, open an elevated Command Prompt window (type CMD in the lower search box and from the "Best Match" list right-mouse-click "Command Prompt" and select "Run as Administrator" from the context menu).

In the elevated Command Prompt window type the string "sfc /scannow" (without quotes) and this will run a Windows tool that will compare the core Windows DLL's that you see (and modify for example) in the Windows SysWOW64 folder, with a master backup DLL cache that is hidden away on the hard drive and will replace any that it thinks are corrupted, modified without a valid developer certificate or do not match the version specified by the last quality update.

Running sfc /scannow will replicate what happens when a quality update is installed so you can make many attempts to try fooling Windows to ignore those JET .dll files and then sfc /scannow will revert them back to the default (signed) versions from the backup cache. Trying to fool Windows is tough nut to crack as the files are identified by hidden as well as visible markers and certificates to prevent malicious hacking. Windows 10 is tied up pretty tight to prevent us users from making unauthorised modifications, still, provides plenty of 'play' time on a rainy afternoon!

Before Windows 10 it was easy to just slip in an Application Manifest file written in XML stating .dll dependencies (sample code below) together with copies of the good .dll's to your applications root folder and at run time of your app i.e, Scheduler.exe, Windows would read the Application Manifest and log that you wanted your versions of the specified .dll's to take precedence over the copies found in the SysWOW folder and load your specified dll's into memory but I spent a couple of weeks trying to make this work and it seems that in Windows 10 you can only do this with a dedicated side-by-side assembly and these need to be signed with a Microsoft developer certificate which are not free to obtain.

Pre Windows 10 if you did a wild card search of the C:\ drive for *.manifest you would have found hundreds of Application Manifest files that were used to state .dll dependencies and avoid this so called "DLL Hell" but if you do the same search with Windows 10 you will mostly find just Microsoft still using them and those are for dedicated side-by-side assemblies containing the required versions of the .dll's and are signed with developer certificates and secure SHA hashes.

I tried many variations of the application manifest and copies of the older .dll's in the Scheduler folder but none worked and it might be that 'scheduler.exe' does not call the JET database engine directly and so the Application Manifest is ignored or it might be that in Windows 10 the older Windows core .dll's have to be digitally signed with a developer certificate and stored in the Windows SxS folder, either way, with very little up-to-date information available regarding Application Manifest files specifically for Windows 10 on the Windows developer web pages I gave up after trying various scenarios for a couple of weeks.

Microsoft haven't exactly made it easy for developers re the future of the JET Database Engine as they announced a few years ago that JET, which has been around since the late 1980's was to be deprecated in 2018 and then changed their minds and released new versions of Access in 2019 that depend on JET so it seems that JET will be around for quite a while as Bob posted recently.

If Bob were to begin building Scheduler today I guess he would use SQL lite rather than JET since Microsoft have said that SQL is their preferred database going forward and MS could change their minds again in a few months and say sorry but we are going to deprecate JET in the next Windows build.

Makes me glad I chose medical engineering as a career and not software development....would drive me mad trying to second guess MS all the time..

William.

Code:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity type="win32" name="ACP.Expert Scheduler" version="8.3.2.0" processorArchitecture="x86"/>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity 
      type="win32" 
      name="msjet40.dll" 
      version="4.0.9801.20" 
      processorArchitecture="x86"/>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity 
      type="win32" 
      name="msrd3x40.dll" 
      version="4.0.9801.19" 
      processorArchitecture="x86"/>
    </dependentAssembly>
  </dependency>
</assembly>