Dave-H

Thank you harkaz!

OK, back again! I've got the scripting working again. I had to move all the related files out of the \system folder into the \windows folder, and edit all the registry entries to reflect this. It then worked fine! Incidentally it's the Unofficial Windows Script 5.7.0.20550 update installer that puts wscript.exe and cscript.exe in the \system folder, which is not where the original Windows 98 installer puts them. I think whoever compiled the INF file got things confused with the NT install, which puts both those files in the \system32 folder. Anyway, after moving them to the \windows folder, along with their associated dlls, it all came good. I am going to keep your version of the script @jumper, as it looks neater!

If it's any help, some ATI graphics cards have a "VIVO" (video in, video out) hardware system built into them which will capture from a composite video or s-video input with the appropriate software. I have a Radeon X600 series card which I use with Windows 98SE, which was the first series to have PCI-E versions available. The Radeon X700 series and Radeon X800 series have the same facility, but it isn't physically there on all models so you would need to check carefully when buying one that it is a VIVO card. Hope this helps. Good luck! Cheers, Dave.

Thanks again @jumper. I'll check all that out and get back to you. I am just wondering, presumably the files that have a problem with 2015.11 are some system files in the \system folder. Is it really necessary to do a blanket disable of KernelEx on all the files in the folder to fix this? The problem with that is that the registry entry over-rides everything else, and you can't re-enable KernelEx on individual files. This is awkward if disabling KernelEx causes problems with some applications, as people have already found with VLC and my problems, which must be caused by this. Is there no hope of finding out exactly what system files have the problem and stop the desktop loading, and just disabling KernelEx on those?

@jumper I've been experimenting trying to get my script to work when KEx 2015.11 is installed, but no luck as yet. QuickMirror runs fine with the default KernelEx setting, both directly and by using shortcuts, included saved mirror configuration files that are associated with it. My script simply calls one of those mirror files, once you've answered "yes" to a yes/no prompt. If you answer "no" the script just terminates. The script is as follows - On error resume nextcompstr = wscript.arguments(0)verify = MsgBox("Run QuickMirror System Backup to Drive F:?",vbYesNo, "Confirm")If verify = vbNo Then wscript.quitEnd IfSet objShell = WScript.CreateObject( "WScript.Shell" )objShell.Run("""C:\Utilities\QuickMirror\System Backup to Drive F.mir""")Set objShell = NothingIs there anything wrong there, anyone that knows about scripting? This script works fine when run from a shortcut with KEx 2015.10 installed, but with 2015.11 installed with the registry fix I just get the message about mirror.exe needing a later version of Windows. If I play with the KEx settings on mirror.exe, and/or on wscript.exe I either get the same result, or the mirror just immediately runs without showing the yes/no prompt message box! The fact that it's not showing the prompt message box would indicate to me that it's wscript.exe that's the problem, not mirror.exe. It should show the message box before even attempting to run QuickMirror of course. I've tried moving wscript.exe out of the \system folder to the \windows folder, which made no difference, but I assume the wscript dlls are still in the system folder, which may be the problem. I'm using the Unofficial Windows Script 5.7.0.20550 update BTW, if that makes any difference.

Thanks @jumper! Strange what you say about QuickMirror as I've been using it for many years on 98SE, I would have thought even before i had KernelEx installed, but it may have been an earlier version back then of course. When the recent problem was there, it still ran fine when run directly, but didn't when run through the vbs shortcut, which is why I assumed that the problem was actually with wscript, not with QuickMirror. Wscript.exe has always been in my windows\system folder AFAIK. Interesting that you say it should be in the \windows folder, but as I said, moving it made the Windows version error go away, but the shortcut still didn't work properly, bypassing the "are you sure" prompt part of the script. I will try your suggestions and report back. Cheers, Dave.

Sorry @jumper, the 2015.11 update has caused me more problems I'm afraid. I have a shortcut which runs a .vbs file to prompt me as to whether or not I want to run a mirror program (QuickMirror) to backup my system drives under 98SE. If I click "yes" on the message box prompt it runs it, if I click "no" it doesn't. this is to prevent it being run accidentally. It has always worked fine until I applied the 2015.11 registry fix. Suddenly running the shortcut just produced a message saying that QuickMirror needs a later version of Windows (it doesn't). I assumed this was because wscript.exe was now having the wrong KernelEx settings applied to it as it's in the Windows\System folder. I tried changing the KernelEx settings on wscript.exe, but every setting I tried either made no difference, or caused the shortcut to immediately run the program without the prompt, which is useless. I then tried moving wscript.exe to the Windows folder and changing the folder options to reflect this, and the shortcut also then worked but again immediately just ran the QuickMirror program without prompting me as to whether I wanted to or not, so that was no good either. I could find no way of resolving this, so I'm back on 2015.10 I'm afraid. After reinstalling that and putting everything else back as it was, everything now works as it should. Any idea how I can resolve this problem? Cheers, Dave.

Yes, I got it working on Firefox 43 eventually too. Still no joy with Opera 12 though, the plugin substitution workaround no longer seems to work.

Confirmed here. Still fine in IE8, but nothing in Opera 12 or Firefox 43, even after substituting the plugin file. I was using update 66. Did it only stop working at Update 71, are Updates 67-70 OK? EDIT: Of course the research I should have done in the first place shows there were no released Updates 67-79!

I saved the text as a registry file, but I had to modify it as my Windows folder is not the default, (it's C:\WIN-98 instead of C:\Windows.) Also it wouldn't merge into the registry by double clicking it for some reason. It said it had, but the entry wasn't actually there when I checked. I had to import it using my registry editor.

Ah, silly me, of course it's a separate thing!

No problem @harkaz, your praise is much deserved! I agree with you that in the future XP will I'm sure be considered the pinnacle of Microsoft's achievement in operating systems, before over-emphasis on eye candy looks and over-obsession with security restrictions took over. I assume there'll be another update to fix the dates problem in the documentation?

Such a simple fix to implement, although I bet it wasn't at all simple to find out what was needed! Thanks @jumper, 2015.11 all seems to be working fine now. Cheers, Dave.

Thanks very much for this @harkaz. It must have been a lot of work, and it's much appreciated. I hope what I've got already is as up to date as it can be, but I'll certainly use your SP4 if I ever have to make a new installation of XP. Cheers, Dave.

Indeed so! I'm now running EMET 5.0 with the rules from 5.5, and it appears to be working fine, so I see no point in trying to use later versions that are probably not working properly under Windows XP, which is not something you want to risk with a security monitoring program of course!

Yes, that was exactly my experience with EMET 5.2, so I abandoned it. 5.5 is a complete no-no of course as it needs .NET 4.5.

Wow, thanks heinoganda, that all works perfectly! Even the downloaded file worked fine with my ancient copy of WinRAR this time, so I assume you compressed it differently. When I extracted the files from the 5.5 installer with Universal Extractor I couldn't see any CertTrustUpd.xml file in there. Did you make it yourself from the other xml files? Do you think there is any advantage in updating to EMET 5.0 over 4.1? I'm willing to give 5.0 another try if you think it is, although I found that the tray icon didn't work when I tried it before. Cheers and thanks again, Dave.

Should I just forget about KernelEx 4.5.2015.11 for the moment?

I've looked at the latest versions of EMET, 5.2 and 5.5 beta, and they seem to use a completely different system for their rules. In fact I believe that they download updates to them automatically from Microsoft (as you would expect!) There is no file in their installers that can be imported into earlier versions as far as I can see. EMET 5.0 and 5.1 are supposedly still supported (until July 12th this year), so quite how you're supposed to keep them up to date when the rules in the latest "Easy Fix" file seem to have already expired is a bit of a mystery! Anyway, fortunately i had saved my configuration, so I've restored that. The rules I've got (from EMET 5.2 which someone helpfully posted their export of) still expire on August 1st though, so what happens then?

Yes, you're absolutely right. I got heinoganda's files installed finally, and yes, the rules in the "Easy Fix" have actually all expired!

I did have some problems with versions later than 4.1, and the departed hmuellers did warn that versions later than 4.1 might have problems under XP. The main issues were the Trust button not working, which I've since fixed, and the tray icon not working, which is important as it provides error popups if the program detects a problem. Now I've fixed the former problem I might try version 5.0 again (later versions had other issues). Thanks, that probably explains it! I have an up-to-date version of 7-ZIP installed on Windows 8.1, so I'll try extracting the files with that, which I'm sure will work.

I just downloaded it again as I thought that maybe the download was corrupted. Same result. My version of WinRAR is old (3.60) but usually works OK. I've also tried with Universal Extractor to extract the files, and that fails as well, with a similar error report - 7-Zip 4.57 Copyright © 1999-2007 Igor Pavlov 2007-12-06 Processing archive: C:\Temp Folder\Trusted.7z Skipping Import.cmd Unsupported Method Skipping CertTrustUpd.xml Unsupported Method Sub items Errors: 2 The downloaded Trusted.7z file is 2.97 KB, does that sound right?

As I said, I'm glad you agree. It really is that simple!

@heinoganda That archive won't extract for me. WinRAR is reporting - ! C:\Temp Folder\Trusted.7z: Unknown method in Import.cmd ! C:\Temp Folder\Trusted.7z: Unknown method in CertTrustUpd.xml ! C:\Temp Folder\Trusted.7z: Error - operation failed

Thanks guys! I could see too why the Import.cmd file included with the patch won't work unless EMET is installed in its default location, as it contains absolute paths ("%ProgramFiles(x86)%\EMET 4.1\EMET_Conf.exe"). Rather stupid when the EMET installer actually does allow you to install it wherever you like! %ProgramFiles(x86)% doesn't exist in Windows XP either as far as I'm aware, unless you have the x64 version presumably! That probably explains why the patch wouldn't work for me even when EMET was in its default location! Unfortunately, heinoganda's version of import.cmd doesn't work for me either, although the registry entry quoted in it is present and correct. I just get "EMET 4.1 not aviable!" (sic) It does look as if the easiest way of doing it is to extract the CertTrustUpd.xml file from the patch, and just run <path>\EMET_Conf.exe --import <path>\CertTrustUpd.xml. It does look as if I was up to date anyway!