Zorba the Geek

Deleted

After some experimentation I have concluded that this problem is caused by data corruption at one of the stages before Windows is installed in a virtual machine. Repeating all these stages for my addon resolved the problem. Here are the stages that need to be repeated: copy contents of INF and INI files in addon/update pack to Notepad and save them from there Build new 7z or CAB archive Copy Windows source from from ISO Use Poweriso or similar to build the ISO rather than the built in ISO maker in the integrator.

I am one of three people that I know of who are still creating update packs and addons for Windows XP, and the framedyn.dll/srclient.dll not found error is a recurring problem during the development of my addons that I have never been able to get to the bottom of. When I do make changes that fix the problem I cannot remember what I did to make it go away. According to setuperr.log srclient.dll could not be registered because a specified module could not be found. This means that there is a missing dependency, which in this case is framedyn.dll. In fact framedyn.dll has not been copied to System32 for some reason In txtsetup.sif framedyn has not been assigned a destination directory which means that it's destination is defined in an INF file, but I have searched all the XP INF files using Notepad++ and it is not there, so what controls it's copying to System32 is a real mystery. Also msjava.dll is missing in the dependency tree, but it is not included in I386 or a standard XP installation. The same issues apply to dgnet.dll not being registered. eventcls.dll and swprv.dll were not registered and the only missing dependency is the non existent msjava.dll. According to setuperr.log mofcomp.exe could not be registered and investigation shows that it is not present in the wbem folder. I have received exactly the same setuperr.log entries multiple times during the development of various addons with the same missing shortcuts and missing wbem modules, which suggests that there is a single cause each time.

All I can see in your screenshot is a switch for automatic definitions updates, but there ought to be a switch for automatic program components updates. I opened a ticket with Adlice and this is the latest reply I have received

I strongly urge everyone not to buy Rogue Killer because it is complete rubbish. I could see no information about system requirements on their websites so I went ahead and downloaded the latest version 16.0.1.0 but it would not install under XP. A Google search soon located version 15.17.4 whose installation triggered DEP notices even though it has been set for essential Windows and Services. I selected open the program after installation but nothing happened, and when I opened it from the start menu it triggered another DEP notice. Buying a one year license and activating it went without problem. I then made the mistake of upgrading to the latest version of Rogue Killer which has been rebranded as Adlice Protect. This resulted in my license being deactivated, so I had uninstall the application. I then tried to install the last version of Rogue Killer before rebranding which is version 15.19.2.0, but as soon as installation finished it started to update program components to version 16.0.1.0 and I was back to where I was before with an invalid license. After uninstalling Adlice Protect I tried installing version 15.19.2.0 with my internet connection disabled, but I was unable to find a setting to disable program updates. I reconnected my internet connection.but with the license correctly activated I was still in trial mode. I uninstalled the application again and went back to version 15.17.4.0 but even with the license properly activated real-time protection and ransomware protection were disabled and there was a notice in the account section of the application saying these protections are not available in portable mode. Also I was unable to log off or shutdown Windows with Rogue Killer installed. At this point I gave up and uninstalled Rogue Killer for the last time. I must have wasted two hours on this rubbish, but at least it only cost me 14 euros. A message has been sent to Adlice.

I see that you have used the POSUpdates.ini from my XPSP3_QFE_POSReady_Addon in the OnePiece_WinXP_Embedded_Post-SP3_True_AddOn_ENU which, for some strange reason, includes an entries_EOL.ini file with only the General section. I cannot remember why I included the line drvindex.inf|hsf_fs|hsf_fsks.sys|1 because hsf_fsks.sys is not updated with the POSReady update and the line is garbled and does not do anything.

I don't know the answer to this question for certain, but problems have been reported when nLite has been used first on a Windows source before using the RyanVM Integrator, possibly caused by the extensive changes and deletions to Windows INF files along with the addition of new files that change the setup routine. Therefore you are less likely to have problems if you use the RyanVM Integrator first on a Windows source before using nLite. Here is a list of the directives in the Integrator that are not supported by nLite: obsolete_files old_sysoc removable_cats WinntSif FileCopy FileMove DirCopy DirMove FileDelete DirDelete RunFile HexEdit

I have examined an XP installation that has the WPDMTP driver included with WMP 11 and it includes two INF files - wpdmtp.inf and wpdmtphw.inf. wpdmtp.inf only contains a generic MTP device descriptor of the form MTP, USB\MS_COMP_MTP but wpdmtphw.inf is a supplement to wpdmtp.inf which includes a number of device descriptors for cameras/camera phones available in 2008 which are MTP compliant but do not present to Windows the generic MTP device descriptor shown above, A typical example would be ;iRiver PMC %GenericMTP.DeviceDesc%=MTP, USB\VID_1006&PID_4003 Windows 7 may have a similar INF file with more up to date entries for device descriptors, including one for your Samsung A55. You could obtain the Device Instance ID for your for your Samsung A55 and use it to insert the device descriptor into wpdmtphw.inf, but this would probably not work because the "needs" and "include" directives do not seem to work under XP. Instead include these entries in wpdmtp.inf [Manufacturer] %MfgNameVendorModel%=VendorModel.NTx86 [VendorModel.NTx86] %MTP.DeviceDesc%=MTP, USB\VID_xxxx&PID_xxxx [Strings] MfgNameVenderModel = "Standard MTP Compliant Device" MTP.DeviceDesc = "MTP Device"

Back again. I have tested Harkaz's syssetup.dll patch and I must say that it seems to be perfectly suitable for my XP addons that remove Windows applications like Outlook Express. I did reproduce the syssetup.dll patch created by nLite, and although it makes more extensive changes it does cause problems.like syssetup.dll and sfcfiles.dll sometimes being flagged as modified in setuperr.log and the installation being halted because the battery driver had not been copied to System32. Here is the nLite patch adapted for addons [HexEdit] I386\syssetup.dll|5.1.2600.5512|328|DC27|10A9 I386\syssetup.dll|5.1.2600.5512|211780|56565656|33C0EB29 I386\syssetup.dll|5.1.2600.5512|212461|8BFF558BEC|33C0C20400 I386\syssetup.dll|5.1.2600.5512|360769|7507|9090 If entries are removed from syssetup.inf and syssetup.dll is not patched the installation is halted due to a fatal error with these messages: The Harkaz patch without the checksum in the header being updated will result in the halting of the file copy stage with this message: The file syssetup.dll was not copied correctly. The file Setup placed on your hard drive is not a valid Windows XP system image. The patch has to be combined with the updated checksum at 0x0148 like so: [HexEdit] I386\syssetup.dll|5.1.2600.5512|329|27|9E I386\syssetup.dll|5.1.2600.5512|211835|74|EB The Harkaz patch did not produce errors in setuperr.log, but there were errors in setupapi.log about unsigned or incorrectly signed files. Perhaps the Mr Dusha patches were meant to remedy this. Also this patch did not cause the installation of the battery driver to fail.

Here is my interpretation of Mr dUSHA's patch for syssetup.dll as it would be implemented for the RVM integrator: [HexEdit] I386\syssetup.dll|5.1.2600.5512|211753|73|EB :????????? (33B29) I386\syssetup.dll|5.1.2600.5512|212480|39|85 ;Disable Syssetup.inf protect (33E00) I386\syssetup.dll|5.1.2600.5512|212481|5D|DB ;Disable Syssetup.inf protect (33E01) I386\syssetup.dll|5.1.2600.5512|212482|08|90 ;DefaultDrvSignPol = 0 (33E02) I386\syssetup.dll|5.1.2600.5512|357631|74|90 ;DefaultDrvSignPol = 0 (574FF) I386\syssetup.dll|5.1.2600.5512|357632|07|90 ;DefaultDrvSignPol = Disable (57500) I386\syssetup.dll|5.1.2600.5512|371506|46|0D :Disable SFC files scan in T-8 (5AB32) As the two entries for Disable Syssetup.inf Protect are adjacent to each other in offsets 212480, and 212481 they can be combined like so: I386\syssetup.dll|5.1.2600.5512|212480|395D|85DB ;Disable Syssetup.inf protect (33E00) More from Mr dUSHA can be found using a translation in 360 Chrome here.

Redacted

I am glad that you have raised this issue because I have been struggling to pipe DASH streams to MPC-HC using the latest youtube-dl and yt-dlp from the commandline. When I have time I will give your batch scripts a try. Do you realize that MPV 0.35 has been backported to XP by Maroc at MDL?

Surely the ssudmtp.inf file should contain a generic MTP device descriptor of the form MTP, USB\MS_COMP_MTP so there should be no need for the vendor's VID & PID. Also if the device is MTP compliant it should be automatically installed using the generic MTP device descriptor in wpdmtp.inf. When I have installed WPDMTP from a suitable MTP compliant device there was no need to install the device's drivers. Perhaps the Android device has to be switched into debug mode or developer mode before Windows can detect it.

I am currently developing addons for XP that remove Windows applications like Outlook Express and they all have the missing battery driver problem if I remove entries from syssetup.inf and patch syssetup.dll. Rather than identify the root cause of the problem I do a workaround that involves copying the batt.dll file from the i386 folder to System32. Here are the relevant entries OE_Rem.inf: [OErem] CopyFiles = Battery.File [SourceDisksNames.x86] 1="Setup Files","WIN51",,"i386" [SourceDisksFiles] batt.dll = 1 [DestinationDirs] DelINFs = 17 Battery.File = 11 Cleanup = 10 [Battery.File] batt.dll As far as I can tell these addons do not have a problem with multiple cat files for one updated file.