kar1

Is the name of that feature Intel Storage Matrix or Intel iRST? iRST = Intel Rapid Storage Technology

For Palemoon/Newmoon maybe try the UnMHT extension (legacy extension): https://services.addons.thunderbird.net/en-gb/firefox/addon/unmht/versions/ Direct download for UnMHT: https://addons.thunderbird.net/firefox/downloads/file/662569/type:attachment/unmht-8.3.2-an+fx+sm+tb.xpi?src=version-history For Chromium/Chrome/Brave Browser/etc just save the webpage as MHTML. This option may have to be enabled inside the chrome://flags settings page. If you don't have the option to save a webpage as MHTML, then search for 'MHTML' in chrome://flags.

@JFX My apologies for even asking, but I would really like to know if you might be interested: Is it possible to allow installing Windows from a RAR file (WinRAR Archive)? Basically the RAR file format's story is that it's a full backup format that supports saving all NTFS attributes, timestamps and ACLs, etc. Using WinRAR's unrar program allows for very fast extraction of big archives (multi-GBs) while restoring all NTFS attributes & properties. So I could for example use ImageX to unpack a sample install.wim file from a Windows ISO to a scratch directory, then archive it as RAR5 with the best compression settings, BLAKE2 checksums, preserving timestamps and NTFS security permissions (ACLs). This would help to create a sample install.rar file that cans also easily be split into arbitrarily-sized parts (e.g. 700MB parts, 2GB parts, etc). So finally for installing Windows, what you would do is to properly select the desired install partitions and extract the RAR5 file to the Windows partition you want. Of course I understand that you have to run WinRAR (for archiving) and WinNTSetup (for install) as TrustedInstaller to do this, but we have many tools made specifically for running programs as TrustedInstaller (example: 'RunAsTI'). So, is this something that you might consider doing in the future? Or perhaps you might think that it's not necessary to work on such an idea right now, because .wim files are good enough? I would also like to add that RAR4 & RAR5 archives can also possess recovery records, which help automatically correct errors if part of the data is damaged (with configurable percentage of recovery record size). Of course I understand that if you do it, then it would only support RAR archives without a password. And I also understand that the usage of such install.rar files would be mostly useful for creating 'super-small' ISO files.

Hello, This might also be a Java runtime problem. Try to use Azul Zulu's Java runtimes instead of the official Oracle ones: https://www.azul.com/downloads/#zulu Azul Zulu's Java runtimes support Windows 7 & JavaFX too. Otherwise try using Adoptium's Java runtimes: https://adoptopenjdk.net/releases.html https://adoptium.net/temurin/releases?version=21&mode=filter&os=windows&arch=any For Minecraft itself, try using mods: https://github.com/WindClan/oldgl/issues/1 https://github.com/KabanFriends/ForceGL20 https://modrinth.com/mod/forcegl2.0-remapped https://github.com/coredex-source/ForceGL2.0-1.2x https://github.com/coredex-source/ForceGL3.0 https://modrinth.com/mod/forcegl4.0 https://github.com/coredex-source/ForceGL_ARS You will surely need: Azul Zulu Java runtime Unofficial Minecraft launcher (not the official one!) FabricMC ForceGL4.0 mod I hope that this will help!

I managed to finally create a .inf file for ACPIEx that makes it bind to a virtual ACPI device. I took Microsoft's loopback network adapter .inf file (msloop.inf) as example to write a new one. After boot the event log no longer shows that the driver couldn't load due to unavailable hardware. However it just silently fails to load, even if I bind it to a valid ACPI HWID (ACPI_HAL\PNP0C08). ACPI_HAL\PNP0C08 is the ACPI HWID that the normal 'Microsoft ACPI-Compliant System Device' is bound to. And acpiapic is the one that the computer itself uses, but acpiapic doesn't use need driver to work. I thought that adding a new legacy device with the Device Manager and giving it a new .inf that uses the same ACPI HWID could work. However the driver still not loading seems to hint at a bigger issue, which is that we will need to backport KMDF 1.13 to Windows 7. This has been done in the past with KMDF when Windows 7's KMDF 1.11 was backported to Windows XP. We have to essentially backport KMDF 1.13 to Windows 7, by finding out where all its files are on a Windows 8.1 OS. For registering the new KMDF 1.13 with Windows 7, we can make a clean Windows 7 SP1 install, then make a snapshot of before & after the official KMDF 1.11 update is installed. This will reveal in which places of the registry we need to register a new unofficial version, and which kind of data we need to write. For the current ACPIEx driver it's uploaded here, but it still doesn't work: https://www.udrop.com/KqcD/ACPIEx___SpbCx-Win7-testing.zip (md5: a9367f0922e9f95a5ae1b14aca75ec58) ACPIEx & SpbCx-Win7-testing.zip

@Jakob99 The ACPIEx.sys driver when I tried it myself didn't run at boot because it has no HWID to bind itself to. I don't know which HWID it's supposed to be installed for on a real Windows 8.1 system (e.g. ACPI_HAL\PNP0C08). Can you boot your computer into a Windows 8.1 or newer WinPE and share screenshots of the Device Manager's ACPI x64-based PC device? It will also help to share more screenshots about a System Device named 'System board' from the Device Manager. It's for the 'Parent' property and potentially some other device properties. But in any case, I think the only remaining part to be modified for the ACPIEx driver is the ACPIEx.inf file. If it gets correctly rewritten with a real Windows 8.1 HWID for ACPi, then the SpbCx driver will be able to run. And since Intel Serial IO drivers require the SpbCx driver as a dependency, this will make them work too.

I managed to create a modified Intel Serial IO driver that installs without problem, although it required more drivers to be modified first: https://www.udrop.com/KoWZ/Intel_Serial_IO_A368___A369-Win7-testing.rar (md5: e1a87e992db972e867e8710d69c1bc4f) It needs to be tested since I don't have a real Intel Serial IO hardware to try, so one thing you can do is: Shutdown your main Windows 7 OS Boot from a WinPE and backup to USB all the registry hives of your Windows 7 OS in C:\Windows\System32\config This includes all .LOG, .LOG2, .BAK etc files (they're cached transaction logs that are waiting to be written for real). Boot your main Windows 7 OS again This way if you have any problem with the drivers, you can easily do a Registry-only restore with the backups. You can also do a full system partition backup prior to installing the drivers if you wish. The install order that needs to be followed is: Remove all previous versions of the iaLPSS2_I2C driver with DriverStore Explorer: https://github.com/lostindark/DriverStoreExplorer Select ACPIEx.inf and right-click it, then use the "Install" menu item Select SpbCx.inf and right-click it, then use the "Install" menu item Reboot Run dpinst64.exe in the 'Intel Serial IO' folder or it install manually with the Device Manager (devmgmt.msc) Reboot If needed, you can also install the included 'MS HID I2C' driver after Intel Serial IO. Optional: use Driver Signature Enforcement Overrider to self-sign the drivers: https://www.softpedia.com/get/Tweak/Video-Tweak/Driver-Signature-Enforcement-Overrider.shtml Sign only the .cat files if needed. Intel Serial IO A368 & A369-Win7-testing.rar

It's potentially normal behavior that the modified Skylake Intel Serial IO driver of Windows 7 didn't work because of the modded DSDT. I'm just making a guess about the DSDT & this Intel Serial IO error code 31, but it might very well really be because of this. On Windows 8.1 the driver might already behave correctly with a DSDT that returns the "Windows 2013" profile. In this case it's a matter of manually adding the missing HWIDs as you did, and it should work. But if the driver runs on Windows 7 and the DSDT returns a "Windows 2013" profile, the driver will still try to run as if it was "Windows 2009". It's best to use a Windows 8.1 Intel Serial IO driver, and it needs to initially be intended for Windows 8.1. If the Intel Serial IO driver doesn't care about Windows 7, then it will directly use the proper code for your DSDT's "Windows 2013" profile. Then it's just a matter of modifying the Windows 8.1 Serial IO driver to work on Windows 7 anyway. I found a Windows 10 driver that already supports PCI\VEN_8086&DEV_A368 & PCI\VEN_8086&DEV_A369 natively (very early version from 2017). There's also a Windows 8.1 driver that doesn't directly support these HWIDs but it comes with PDB files (debug symbols). I'm going to sort these out to select the best one for Windows 7 backporting, it shouldn't take very long. Another note is that MediaFire blocked your download link because of DMCA. MediaFire really seems to dislike the upload of Intel driver files (it's not the first time this happens). MEGA.nz also sometimes blocks Intel driver downloads. Next time you will need to password-protect driver uploads with any archiver of choice that supports .7z or .rar format. Use the 'encrypt filenames' option & put any password such as 'driver'. You can also name the file 'Outtel Serial IO 7th Gen+ Win 7' if needed, or any other 'Intel' wordplay of choice.

You can do this without extracting the setups because Dell also provides All-In-One CAB files for WinPE integration. However extracting the setups is somewhat difficult, because you have to carve the setup for its resources while driver_auth.exe is still running. Otherwise the setup unloads its resources and deletes everything after it 'fails', but this could be achieved with IFEO & nop-continue.exe from Github. Now, if you install the drivers manually with INF files you will have to also modify them to include important Dell services. For mobile broadband, the Dell mini_WMCore.exe (WMCoreService) file isn't part of the real INF driver files. There are many such programs included in the official Dell setups that aren't part of the INF-only distributions. These Dell services are the ones that actually make their hardware exist on Windows. Otherwise Windows wouldn't even know that the hardware is physically present. These services send a sort of hardware interrupt to the firmware that tells it start making Windows aware of the hardware's existence at the next scan for hardware for changes. Therefore if you own a laptop with such kind of hardware and yet it doesn't seem to exist at all after installing INF files, that's because of this.

I looked it up deeper and the driver fails to load likely because of the lack of a KB3125574 Windows update: - https://www.catalog.update.microsoft.com/Search.aspx?q=KB3125574 This update brings a WdfLdr.sys driver that the Intel HID Event Filter relies on. However it should work without the KB3125574 update by taking it from a Windows 8.1 system. I took your Intel HID Event Filter drivers and modified them, the list is as follows: Removed all invalid INF comment prefixes // and replaced them with ; instead Added my compiled ntoskrn8.sys & WdfLdr.sys from Windows 8.1 to the INF files section For HidEventFilter.sys & WdfLdr.sys I modified the EXE/SYS file headers to use MajorVersion 6 & MinorVersion 1 Because it was MajorVersion 10 & MinorVersion 0 (6.1 vs. 10.0 for Win10) Modified the import filename in both HidEventFilter.sys & WdfLdr.sys from ntoskrnl.exe to ntoskrn8.sys Modified the __security_cookie in both SYS files & bypassed the security cookie check in driver code as well Removed the Security Directory information from EXE/SYS headers for both HidEventFilter.sys & WdfLdr.sys Updated all the EXE/SYS file checksums in the headers for all files Created a new unsigned HidEventFilter.cat file with '6.1' OS attribute (verifies all .sys files & the .inf file) Included dpinst64.exe from Microsoft (version 2009 for Windows 7 64-bit) Prior to installing the modified drivers, you need to remove all the previous Intel HID Event Filter drivers with DriverStore Explorer: - https://github.com/lostindark/DriverStoreExplorer This allows for removing old drivers that otherwise get reinstalled again instead of the newest modified drivers. The modified Intel HID Event Filter drivers (version 3): - https://www.udrop.com/KopH/HidEventFilter-Win7-testing-3.zip (md5: 765c950f421cd7a9b7a353e8e980487c) For the 0x0000007E BSOD error code, it doesn't actually mean much other than 'Windows had a trouble while running this program/driver'. It's a generic Windows error code rather than one that actually gets sent by the Intel HID Event Filter itself. Try the modified version after having removed all previous ones with DriverStore Explorer, I think it should work. You can also enable testsigning & easily self-sign the drivers yourself with Driver Signature Enforcement Overrider: - https://www.softpedia.com/get/Tweak/Video-Tweak/Driver-Signature-Enforcement-Overrider.shtml Just sign the HidEventFilter.cat file only if needed. HidEventFilter-Win7-testing-3.zip

Purchasing a Microsoft Office 2010 Home / Student key from eBay is very much equal to using a third-party Activator (other than losing money). The story is that Microsoft sells discounted student keys for these editions at loss, and the eBay resellers use a batch of .edu email adresses to purchase these with great discounts. Then they proceed to resell the keys at a more expensive price, but still less than retail on such websites. Microsoft didn't gain anything from it, so my advice is not to feel concerned with purchasing Office 2010. There are many of ways to use Office 2010 Now for your Dell card reader problem: The install failed because the Setup deliberately aborted the install, it's not your OS's fault. Dell uses what they call 'driver authentication' when you run the Dell driver setups. It finds a sysID file (encrypted) and extracts a driver_auth.exe program to your %TMP% folder. Then it runs driver_auth.exe and gives it the encrypted sysID. If your HWID (cans be motherboard, BIOS, etc) doesn't match the very exact model the setup was for the install 'fails'. It's a fake error. We had online (customers) many such problems when trying to install mobile broadband drivers for Dell computers. You need to bypass the driver authentication. For this create a new IFEO registry key (Image File Execution Options) named 'driver_auth.exe' and a 'Debugger' STRING_SZ registry value. Then give the Debugger value a file path to a dummy program that just exits. Example: https://github.com/myfreeer/nop (don't use nop-continue.exe, it needs to simply exit directly, so choose nop.exe) The Dell driver authentication is nothing more than checking whether the exitCode of driver_auth.exe is 0. Redirect the driver_auth.exe filename to e.g. C:\Drivers\nop.exe and the install will succeed. This enables the install of many broadband drivers for Dell computers that were 'unsupported' just because they were a later upgraded model. Hope it helps.

Cygwin for Windows (used by many Windows utilities in the background) will be dropping support for Windows 7: https://cygwin.com/install.html More info: http://www.crouchingtigerhiddenfruitbat.org/Cygwin/timemachine.html

Check this topic on win-raid, there's a link for the HD Graphics 620 driver (modded): https://winraid.level1techs.com/t/offer-7th-8th-gen-intel-gpu-drivers-for-win7-8-1/33096/8 Try installing these drivers with "dpinst.exe" from Microsoft or use the Device Manager with the "Choose a driver manually" option. Don't install these with the normal Intel installer, try installing it manually as detailed above.

There's a DSDT & SSDT editor (IDE) on Github for this purpose: https://github.com/ic005k/Xiasl (block it in the firewall to prevent its Internet check) Another older DSDT Editor: http://web.archive.org/web/20161108180259if_/http://olarila.com/dsdt/DSDTEditor_Linux_Windows.zip You should then be able to edit your SSDT/DSDT and load patched versions using a boot-time loader: https://github.com/jslegendre/ACPIPatcher Or you can also use Clover, OpenCore, or other loader of choice. Some quick tips: CondRefOf function is also used to verify the return of _OSI "Windows 2009" is Windows 7 & "Windows 2013" is Windows 8.1 Lookup "If (_OSI" or "If ((_OSI" to quickly locate the blocks that have a system check WIN7 is a constant that cans also be searched ACOS & ACSE variables seem to matter, they have to also be modified OSYS is the variable that gets checked the most in the OS installed locks Vista is named with the WLG constant There's a DRS3 variable but only set for Windows 10 RS3 & later I made a patched version of your DSDT that makes Windows 2006 & 2009 (Vista & 7) behave as if it was Windows 8.1 (2013). It also returns Windows 8.1's OSYS value for Vista & 7 which will be able to unlock more ACPI objects. https://www.udrop.com/Kn0y/dsdt-patched.zip (md5: 4d22eb9bedc63efb618aaeef84ffb9db) Try using the normal version and if any problem then the 'no-optimization' one. I also compiled GeorgeK1ng's version of NTOSKRNL_Emu incase you need to mod the Intel HID driver. https://www.udrop.com/Kn0H/NTOSKRNL_Emu-GeorgeK1ng-version.zip (md5: a054a8ba9d05e587f3ac0f409d9e25e5) dsdt-patched.zip NTOSKRNL_Emu-GeorgeK1ng-version.zip

Are you sure that MacType itself is buggy or is it just that its Mac-like antialiasing isn't good enough? If MacType just causes fonts to look bad, it will still be technically working. As long as there are no explicit error messages or crashes. If you're then able to see colored fonts where the emojis are otherwise black&white it will be a good start, even if the text rendering is visually botched. What I mean is that it's not too bad if MacType optimization looks wrong, it's more about verifying whether MacType is technically able to hook Windows font rendering to output colored characters where there was only black&white font support before it. If it actually brings colored fonts support, then MacType could be forked into a new project without the aliasing optimization part. Just the enhanced fonts support, and this would solve both the colored emoji support for Windows 7 & the MacType optimization problems.