Jump to content
MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. ×


  • Posts

  • Joined

  • Last visited

  • Donations

  • Country


Everything posted by harkaz

  1. Windows XP SP4 thread (along with a few others) has been mostly archived, but some pages are missing: https://web.archive.org/web/20191105073426/https://ryanvm.net/forum/viewtopic.php?t=10321 We need a full snapshot of the site.
  2. Use the GH0stpak, as described in the RyanVM forum, in order to update your system. The May 2019 update pack is intended for new installations of WIndows XP from updated media.
  3. 1. In a Windows XP environment, extract/copy the contents of XP SP0/SP1/SP2/SP3 original media to an empty folder: C:\XPMEDIA. 2. Run this command from command line: WindowsXP-USP4-v3.1b-x86-ENU.exe /integrate:C:\XPMEDIA 3. As soon as 2 is complete, extract the update pack zip to a blank new folder named C:\updpack 4. Run C:\updpack\slipstream.bat. 5. Paste C:\XPMEDIA to the command line window that appears and press ENTER
  4. UPDATE: SP4 v3 October 2018 MUI Update ISO has been re-uploaded. UPDATE #2: Updated Windows XP Debugging Symbols for May 2019 post-SP4 update pack have been also uploaded. For more information, visit RyanVM.net.
  5. The "Windows XP SP4 MUI October 2018 Update" is the best way to use SP4 in languages other than English (ISO was flagged and no longer available, will re-upload sometime). However, several OS components will not be translated to another language.
  6. Extract zip anywhere you want, then run the .bat file.
  7. UPDATE [June 7, 2019]: Post-SP4 Update Pack released! This final update pack should be applied to Windows XP installation media immediately after slipstreaming SP4 v3.1b to a Windows XP RTM/SP1/SP2/SP3 source. This will update installation media to May 2019, including every single update released until the POSReady 2009 end-of-life in May 2019. Download available at RyanVM.net.
  8. @everyone FYI, new stuff has been released for XP SP4: 1. A SP4 v3.1b installer that does not install .NET Framework unless absolutely necessary (MCE, Tablet PC). 2. Windows XP SP4 Preinstallation Environment and OEM Preinstallation Kit (OPK) with SCSI drivers integrated 3. An updated MUI ISO with fixes and additions. Check my RyanVM thread for details.
  9. UPDATE - 15 OCT 2018: For novice users that do not want to wait for 20-30 minutes after installing XP SP4 AND rebooting For all .NET haters... A NEW RELEASE OF UNOFFICIAL SP4 3.1B WITHOUT .NET FRAMEWORK This release will not install .NET Framework in both live and slipstreamed install, unless: - Media Center Edition is used -> .NET Framework 1.1 SP1 is installed - Tablet PC Edition is used -> .NET Framework 1.0 SP3 is installed Users can still install .NET FWs of their choice from the Add/Remove Components wizard in Control Panel This alternative SP4 release is called: WindowsXP-USP4-v3.1b-NODOTNET-x86-ENU.exe In addition, XP SP4 OEM Preinstallation Kit ISOs with SCSI drivers, and an updated MUI ISO have been released!
  10. Registry settings to import as a .reg file after installing the latest cumulative IE8 update:
  11. You need to manually install the latest cumulative IE8 update and Office updates before scanning for updates. Updates can be downloaded from the Microsoft Update Catalog website (https://catalog.update.microsoft.com). Just search for posready and sort the updates shown in chronological order.
  12. MSI Error 1603: MSI (c) (30:60) [03:46:21:203]: Note: 1: 1708 MSI (c) (30:60) [03:46:21:203]: Product: Java 8 Update 161 -- Installation failed. MSI (c) (30:60) [03:46:21:203]: Windows Installer installed the product. Product Name: Java 8 Update 161. Product Version: 8.0.1610.12. Product Language: 1033. Installation success or error status: 1603. MSI (c) (30:60) [03:46:21:234]: Grabbed execution mutex. MSI (c) (30:60) [03:46:21:234]: Cleaning up uninstalled install packages, if any exist MSI (c) (30:60) [03:46:21:250]: MainEngineThread is returning 1603
  13. Try the offline installer at https://java.com/en/download/manual.jsp UPDATE: Tried that and it's not working. After some quick debugging it seems that there is an access violation exception related to C runtime implementation. ANTIDEBUGGING related stuff. The resource section includes an MSI file, which cannot install for some reason. Using Orca tto see more info.
  14. After applying the convenience rollup to a base SP1 image you will get the ability to run CheckSUR (System Update Readiness Tool) from inside DISM. The command can only be used online and it is the following one: dism /online /cleanup-image /scanhealth You cannot execute this command offline (on an install.wim image file), if that's what you're talking about.
  15. 1. The update.ses manifest file In a few big updates (like service packs) one may notice the presence of an update.ses file. The purpose of this file is to control package target installation state in different servicing stack conditions. For example, you could define a different behaviour when the servicing stack is of a different version, when the update is deployed online or offline. Ses stands for 'session'. This file controls the CBS session manager. Update.ses is digitally signed by the update.cat file. The same file is used to sign update.mum. Example from Windows 7 SP1: <?xml version="1.0" encoding="UTF-8"?> <Session version="1.0"> <Tasks operationMode="OnlineInstall"> ;Actions to take when installing online. <Phase servicingStack="6.1.7601.17514"> ;Prerequisite servicing stack version for update installation. ;Define target state for the specified package. See DISMAPI Documentation for supported installation states. <package id="Package_for_KB976902~31bf3856ad364e35~amd64~~" targetState="Installed"/> </Phase> <Phase exclusive="AllowPending"> <package id="Windows7SP1-KB976933~31bf3856ad364e35~amd64~~" targetState="Installed"/> </Phase> </Tasks> <Tasks operationMode="OnlineUninstall"> ;Actions to take when update is being uninstalled. <Phase exclusive="AllowPending"> <package id="Windows7SP1-KB976933~31bf3856ad364e35~amd64~~" targetState="Absent"/> </Phase> </Tasks> <Tasks operationMode="OfflineInstall"> <Phase> <package id="Windows7SP1-KB976933~31bf3856ad364e35~amd64~~" targetState="Absent"/> </Phase> </Tasks> <Tasks operationMode="OfflineUninstall"> <Phase> <package id="Windows7SP1-KB976933~31bf3856ad364e35~amd64~~" targetState="Absent"/> </Phase> </Tasks> </Session> 2. It is not essential to have a package container manifest (_manifest_.cix.xml) if there are no deltas in the update package. If there is no point in creating deltas (e.g. IE11 install package), because this will not save any disk space, then there is no need for adding such a manifest. The payload (files) each MANIFEST file copies to the system is stored in a FOLDER that has exactly the same name as its respective manifest: For example, all files copied by amd64_aagwrapper_31bf3856ad364e35_6.1.7601.17514_none_dd3e751b9f413882.manifest are stored in the directory amd64_aagwrapper_31bf3856ad364e35_6.1.7601.17514_none_dd3e751b9f413882 inside the update package root directory. In this case the sourceName in the MANIFEST file has to be defined explicitly: <file name="agilevpn.sys" destinationPath="$(runtime.drivers)\" sourceName="agilevpn.sys" sourcePath=".\" importPath="$(build.nttree)\"> <securityDescriptor name="WRP_FILE_DEFAULT_SDDL" /> <asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"><dsig:Transforms xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" /></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha256" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" /><dsig:DigestValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">YscNoSf0j3lviJe7+iOrbrCAzJI/Dwkd+jhKk/XJDKE=</dsig:DigestValue></asmv2:hash></file>
  16. More details about the MUM/ Manifest connection: Some MUM files in the MUM chain may contain references similar to these: ;Create an 'update': a top-level 'bundle' to connect MUM with MANIFEST. <update description="wvpchbus_inf" displayName="wvpchbus_inf" name="INF_wvpchbus"> <applicable disposition="detect"> <detectUpdate> <parent name="wvpchbus_inf"/> ;No prerequisites </detectUpdate> </applicable> <component> <assemblyIdentity buildType="release" language="sv-SE" name="wvpchbus.inf-LanguagePack" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" version="7.1.7600.16393" versionScope="nonSxS"/> </component> </update> This section is responsible for linking the component (MANIFEST) named amd64_wvpchbus.inf-languagepack_31bf3856ad364e35_7.1.7600.16393_sv-se_e01330253ba0e3cd.manifest with the specific MUM file. So, apart from the CAT connection, there is also a link inside the MUM itself. The specified MANIFEST file, in turn, is a trigger for another MANIFEST file, referenced as dependency: <?xml version="1.0" encoding="utf-8" standalone="yes"?> <?Copyright (c) Microsoft Corporation. All rights reserved.?> <assembly xmlns="urn:schemas-microsoft-com:asm.v3" copyright="Copyright (c) Microsoft Corporation. All Rights Reserved." manifestVersion="1.0"> <assemblyIdentity buildType="release" language="sv-SE" name="wvpchbus.inf-LanguagePack" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" version="7.1.7600.16393" versionScope="nonSxS"/> <deployment/> <dependency discoverable="no"> <dependentAssembly dependencyType="install"> <assemblyIdentity buildType="release" language="sv-SE" name="wvpchbus.inf.Resources" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" version="7.1.7600.16393" versionScope="nonSxS"/> </dependentAssembly> </dependency> <rescache xmlns="urn:schemas-microsoft-com:rescache.v1"/> </assembly> This dependency contains everything we've seen previously (file copying, driver install, etc.). Everything is triggered from a single MUM file. It seems it's rather complicated after all. I'll continue to search for patterns in Windows Update packages and report anything significant here.
  17. Windows Update package structure - Part 3: The MUM chaos As if the complexity of the manifest files was not enough, here comes the part that links the manifest files together: component-based servicing. Each manifest is named with the same name as its respective component-file folder in WinSxS. For example, a file named like aa.manifest means that all of its files are copied to winsxs\aa. The packages allow top-level interaction with servicing stack and Windows Update. The servicing stack creates a registry link between each package and components. The way it performs this link is not yet obvious to me. I suspect that the key to the connection is CAT files: (See post #5 below to learn how MUM and MANIFEST files are linked). There exists 1 CAT file for each MUM file. Each CAT must at least contain the hash of each respective mum and have the same file name with it. However, some CAT files include more than one hashes. These correspond to the copied files and the MANIFEST files. A manifest file is thus linked to a MUM file, via its unique catalog file. Update.mum should start like: <?xml version="1.0" encoding="UTF-8"?> ;General, top-level info about the update package (useful for DISM, etc.) <assembly manifestVersion="1.0" description="Windows Virtual PC" displayName="Windows Virtual PC (KB958559)" company="Microsoft Corporation" copyright="Microsoft Corporation" supportInformation="http://support.microsoft.com/kb/958559" xmlns="urn:schemas-microsoft-com:asm.v3"> ;Microsoft-Windows-VirtualPC-Package-TopLevel-MergedCab is the name of the package ;BuildType set to release in most packages ;Be careful of the publicKeyToken. ;DEFINITION of the update.mum package info. Be careful of the MergedCab designation in various update.mum packages. <assemblyIdentity buildType="release" language="neutral" name="Microsoft-Windows-VirtualPC-Package-TopLevel-MergedCab" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" version="7.1.7600.16393"/> ;Package identifier is the KB number. Applicability evaluation controls the Windows Update detection system. ;Sometimes the Permanence=Permanent designation is present, indicating that the update package will be marked as non-removable. ;This XML section means that servicing stack will start processing the update.mum package prerequisites and install other packages. <package identifier="KB958559" applicabilityEvaluation="deep" releaseType="Update" [Permanence="Permanent"]> <parent> ;Check for the presence of prerequisite parent packages. <assemblyIdentity name="Microsoft-Windows-UltimateEdition" version="6.1.7600.16385" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" buildType="release"></assemblyIdentity> ;....Add more prerequisites here </parent> ;Specify the MUM packages this MUM will install: <update name="Microsoft-Windows-VirtualPC-Package-TopLevel"> <package integrate="hidden"> ;Invisible to package manager (DISM) ;Specifies the MUM info (name, processor, publicKeyToken, version) of the package to install ; Now servicing stack will recursively process that MUM file, etc. <assemblyIdentity buildType="release" language="neutral" name="Microsoft-Windows-VirtualPC-Package-TopLevel" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" version="7.1.7600.16393"/> </package> </update> <update name="Microsoft-Windows-vpc-Package-SP1-Restore-Wrapper"> ;Usually a top level optional component package is followed by a respective 'wrapper' <package integrate="hidden"> <assemblyIdentity language="neutral" name="Microsoft-Windows-vpc-Package-SP1-Restore-Wrapper" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" version=""/> </package> </update> </package> </assembly> Sometimes MUM files do other stuff like driver installation: <update name="vpcuxd_inf" restart="required"> <applicable disposition="staged"> ; Indicates that servicing stack should stage the driver update and add it to the pending.xml tasks list. <updateDriver elevate="install"> ;In this example, the update that will be processed is not a MUM but a driver INF file (a driver package) ;PublicKeyToken is vital because it identifies the signer. ;Defines the driver update package info for the pending.xml <assemblyIdentity buildType="release" language="neutral" name="vpcuxd.inf" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" type="driverUpdate" version="7.1.7600.16393" versionScope="nonSxS"/> </updateDriver> </applicable> <driver inf="vpcuxd.inf" ranking="normal"> <assemblyIdentity buildType="release" language="neutral" name="vpcuxd.inf" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" type="driverUpdate" version="7.1.7600.16393" versionScope="nonSxS"/> </driver> </update> This completes my presentation of Windows Update packages, at least for now. It would be useful to start working on an update package creator, that will empower advanced users to install whatever they want, however they want.
  18. It's not just the ID of the first delta, it changes throughout the xml file. I will closely examine this. In most cases it is the ID of the previous delta in the XML. This is not the case with some language-specific resource files, however. MSU is an MsZIP archive containing 4 files: a txt, an xml, the wsusscan.cab and the main cab file. We use the term update referring to both the MSU and Main CAB file. The update package per se is the Main CAB file, while the MSU is its Windows Update bundle. Anyway, let's return to the package analysis. After specifiying everything, the package container manifest ends like: </Files></Container> Now, how are all the files copied and how are windows update registry entries added? The .mum and .manifest files do this. Instead of having a single update.inf it's now much more complicated. Example of a .manifest file (with comments): <?xml version="1.0" encoding="UTF-8"?> ;Introduction <assembly xmlns="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0" copyright="Copyright (c) Microsoft Corporation. All Rights Reserved."> ;Specify assembly identity as the name of its winsxs folder: Architecture_Name_PublicKeyToken_version_locale ;IMPORTANT: You cannot change the CAT signature vendor like I did in XP USP4! You must use MS-provided CAT files to install file with the same publickeytoken. <assemblyIdentity name="vpcusb.inf.Resources" version="7.1.7600.16393" processorArchitecture="amd64" language="da-DK" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" /> ;XML section for file copying: ;file name destinationPath sourcename and sourcepath importPath ;file name: target file name in winsxs ;destinationPath: directory to update with the file. We've lost the simplicity of the LDIDs in INF files. Special directories are designated by $(runtime.xxx) string. ;Examples: $(runtime.drivers), $(runtime.help), $(runtime.system32) More examples could be added here. ;sourcename and sourcepath: Undocumented, use only if there is a different file name definition in package container XML. ;importpath: Undocumented, reverse engineering required to properly understand this. Probably $(build.nttree) represents a temporary location where the delta files are extracted along with the other stuff. ;destinationPath <file name="vpcusb.inf_loc" destinationPath="$(runtime.system32)\DriverStore\da-DK\" sourceName="" sourcePath=".\" importPath="$(build.nttree)\loc\da-dk\mui_infs\vpc\"> ;Security desciptor for SFC. Some reverse engineering will be required for further options. <securityDescriptor name="WRP_FILE_DEFAULT_SDDL" /> ;Verification hashes - section start. <asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"> <dsig:Transforms xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"> <dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" /> </dsig:Transforms> ;Uses SHA256 for validation. ;Also must be CAT signed with MS certificate. <dsig:DigestMethod xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Algorithm="http://www.w3.org/2000/09/xmldsig#sha256" /> ;BASE64 digest value (SHA256 algorithm) <dsig:DigestValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">xVT51HPqzn0ICbhyK392n198mRihDDTh5yd3muBYZrA=</dsig:DigestValue> </asmv2:hash> </file> ;Specify file info for validation (copy of the previous line) <file name="vpcusb.sys.mui" destinationPath="$(runtime.drivers)\da-DK\" sourceName="" sourcePath=".\" importPath="$(build.nttree)\loc\da-dk\vpc\"> <securityDescriptor name="WRP_FILE_DEFAULT_SDDL" /> <asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"> <dsig:Transforms xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"> <dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" /> </dsig:Transforms> <dsig:DigestMethod xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Algorithm="http://www.w3.org/2000/09/xmldsig#sha256" /> <dsig:DigestValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">2cJBTne143cft9wMNmJ3b+AEwdV3Tk70cNB59wx71pM=</dsig:DigestValue> </asmv2:hash> </file> ;ACL codes for the winsxs assembly as a whole- Do not touch these ;Operationhint set to "replace" to replace any existing ACL. <trustInfo> ;Designates start of trust info specification section. <security> <accessControl> <securityDescriptorDefinitions> <securityDescriptorDefinition name="WRP_FILE_DEFAULT_SDDL" sddl="O:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464G:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464D:P(A;;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;;GRGX;;;BA)(A;;GRGX;;;SY)(A;;GRGX;;;BU)S:(AU;FASA;0x000D0116;;;WD)" operationHint="replace" /> </securityDescriptorDefinitions> </accessControl> </security> </trustInfo> <rescache xmlns="urn:schemas-microsoft-com:rescache.v1" /> </assembly> Other sections you could find in manifests: - Service creation (as you know drivers are services): <memberships> <categoryMembership> <id name="Microsoft.Windows.Categories.Services" version="6.1.7600.16393" publicKeyToken="31bf3856ad364e35" typeName="Service" /> <categoryInstance> ;Specify data for service creation (it's should be rather straightforward) <serviceData name="vpcvmm" displayName="@%SystemRoot%\system32\drivers\vpcvmm.sys,-100" errorControl="normal" imagePath="system32\drivers\vpcvmm.sys" start="system" type="kernelDriver" description="@%SystemRoot%\system32\drivers\vpcvmm.sys,-101" startAfterInstall="asynchronous" /> </categoryInstance> </categoryMembership> <categoryMembership> ;Store it as boot critical service. <id name="Microsoft.Windows.Categories" version="" publicKeyToken="365143bb27e7ac8b" typeName="BootCritical" /> </categoryMembership> </memberships> - Registry (it is straightforward) ;In INF language: HKLM, "SOFTWARE\Microsoft\Assistance\Client\1.0\Namespaces\Windows\en-US\Titles","virtualpc",0,"" ;(Yeah I love Windows XP) <registryKeys> <registryKey keyName="HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Assistance\Client\1.0\Namespaces\Windows\en-US\Titles" owner="false"> <registryValue name="virtualpc" valueType="REG_SZ" value="" operationHint="replace" owner="true" /> <securityDescriptor name="WRP_REGKEY_DEFAULT_SDDL" /> ;Undocumented; reversing required. </registryKey> </registryKeys> To be continued... P.S. For practice, try analyzing the manifests in Windows 7 SP1. Together we'll discover more stuff, more quickly.
  19. It will be rather difficult without some kind of automation. I'd recommend trying to create customized patches rather than a unofficial sp2; there is no point of doing such a thing in modern Windows actually. First of all, Windows 6.x and later updates are deployed in .cab format. Inside the cab file there must be a file named: _manifest_.cix.xml Take a look inside this file with IE preferably: It starts with something like: <?xml version="1.0" encoding="UTF-8"?> <Container name="windows6.1-kb958559-x64-refreshpkg.cab" type="CAB" length="19070059" version="1" xmlns="urn:ContainerIndex"><Description/> Container Name: The name of the CAB file. type="CAB" The type of the file that contains the updates (Set to CAB). length: Length of the update package in bytes Each file is then registered in another XML section called <Files>. Two primary examples: <File length="1872" name="x86_microsoft-windows-virtualpc-additions_31bf3856ad364e35_7.1.7600.16393_none_fa50c45d13592d39.manifest" attr="32" time="128981427337272897" id="1143"><Delta><Source type="RAW" name="x86_microsoft-windows-virtualpc-additions_31bf3856ad364e35_7.1.7600.16393_none_fa50c45d13592d39.manifest"/></Delta></File> <File length="5888" name="amd64_wvpchbus.inf_31bf3856ad364e35_7.1.7601.17514_none_435a07889c1e3a43\wvpchbus.inf" attr="32" time="129347010400000000" id="1116"><Delta><Source type="PA30" name="0"/></Delta></File> <File length="5888" name="amd64_wvpchbus.inf_31bf3856ad364e35_7.1.7600.16393_none_411c23409f399fec\wvpchbus.inf" attr="32" time="128981427800274961" id="1115"><Delta><Source type="PA30" name="1"/><Basis file="1116"/></Delta></File> File length: Target file size, in bytes name: Target file name + extension attr : Decimal code of the file attributes, as defined here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365535(v=vs.85).aspx Source type: RAW or PA30. RAW means that no delta-compression is implemented. PA30 means that the file in the cab file is a delta. Time: A 64-bit time stamp. Shows Win32 FILETIME values count 100-nanosecond intervals since January 1, 1600 UTC. More info: https://blogs.msdn.microsoft.com/oldnewthing/20030905-02/?p=42653 ID: A number identifying the source file in the update package (it is just an index number). name: An index value for the PA30. 0 means first delta, 1 second delta to process and so on. Respective deltas are named the same way in the cab file. <Basis file="1116"/> Not sure what this means, some more research required. To be continued.
  20. @jaclaz I see your point. I have some ethical concerns about current Rebase users, however. It wouldn't make me look good if I gave Rebase for free right now, when they've paid a few bucks for it just a few weeks ago. There are 3 and a half years till Windows 7 support ends. On the other hand, you're right that a few people might be really interested in Rebase if they discover it within the following months. For these few potential buyers, I am sure a private arrangement regarding pricing/support/intended use of the program could be reached.
  21. When I created Rebase in December, no free tool existed that could provide the same functionality. Usability of Rebase for the average user is, indeed, questionable. However, given there was no free tool that offered exactly the same quality of functionality I decided to distribute Rebase as shareware and measure its reception. I guess that most users don't grasp these subtle but substantial differences that exist between Rebase and other tools that offer similar functionality. Even those who may understand, they certainly do not trust an amateur, third-party developer. Winsxs management can be a tricky issue, even for Microsoft themselves. And of course, to put it in a more general sense, developing software may not be the best way to make money...
  22. Well, the interest for the program has been kinda limited. Probably the payment option was not appropriate but it was the best I could do at the moment. Given the low interest, it was not worth waiting for any 'late-comers' that might purchase a license to use the program just before the end of support. I always intended to stop availability just before end of support, it happended a bit earlier. For those who got a copy of the Rebase tool, I hope I've lived up to your expectations in terms of support and programming quality.
  23. IMPORTANT NOTICE: Rebase will not be available for purchase after June 30, 2016. Support for existing users will end as stated in the documentation.
  24. New payment option: Payment via Paypal to my e-mail address. Prior contact via e-mail is required.
  25. I have sent Dibya a PM with the update package. It will take much more work to be a full backport. For example, the dxgkrnl.sys, updated dxdiag, patched rpcrt4.dll, version.dll, cdd.dll, ntoskrnl/HAL files It requires advanced knowledge of the kernel structure. Recommend analysing the manifest files in Windows6.0-KB971512-x86 to get a first idea of the files needed. Then try understanding how this update brings DX11 functionality to Vista and try to combine this with DX10 in XP kernel. Remember: there is no way you can avoid changes in kernel, due to dxgkrnl.sys

  • Create New...