UCyborg

No. Blocking in this case is just some extra metadata attached to the file entry in the file system using NTFS Alternate Data Streams. I've yet to encounter a program that would make a fuss about it. Windows gives a warning if you try to run executable program blocked this way. Using some kind of download manager tends to prevent the file being blocked on download, at least the following two. I use DownThemAll! - XUL extension for older Firefox and derivatives that kept support for these types of extensions. My main reason for using such download manager is ability to preserve file last modification timestamp. More universal download manager when it comes to browser support is Internet Download Manager.

https://www.virtualbox.org/browser/vbox/trunk/src/VBox/HostDrivers/Support/SUPR3HardenedMain.cpp?rev=85127#L29

If the stable driver that would run this game doesn't exist or Win7 bundled games are the only applications utilizing 3D hardware acceleration that are of concern, I suggest downloading dgVoodoo2 (look under Latest stable version). Alternatively, download it from GitHub, author's own site has been often tagged by Google Safe Browsing due to anti-virus software considering his software malicious. In the downloaded ZIP file, run extract and run dgVoodooCpl.exe. Make sure Config folder is set to something like C:\Users\YourName\AppData\Roaming\dgVoodoo and minimize it. Then, in the ZIP file, navigate to MS->x64 and extract D3D9.dll to C:\Program Files\Microsoft Games\Solitaire. Try the game, it should launch normally and you'll see dgVoodoo watermark in the lower-right corner, which may be disabled with the dgVoodoo Control Panel on the DirectX tab (apply settings after change). If it doesn't work, try changing Output API on General tab to Direct3D 11 MS WARP (software), though I guess that in your case, nothing but WARP option and Best available would be available, in which case Best available translates to WARP anyway. At least in the past, dgVoodoo2 didn't work in VMware virtual machine without explicitly selecting WARP, because while some D3D10 support existed in its graphics driver, a certain needed feature didn't. The control panel may be closed when you're happy with the configuration.

Not just banks. I always thought of smartphones as complementary pocket computers. It seems cultural shift started to occur at some point that they became center of everything. Slovenian government was going to make an app that warns you if you've been in proximity of someone infected with SARS-CoV-2 mandatory to use, though realization failed. PS: old way to access my bank's site still works, it was supposed to stop working with November. I imagine getting people to switch from the old trusted way isn't a smooth process.

Old Edge doesn't seem to have it, but in Chromium Edge, right-click anywhere on the page->Save as. The longer route: click the 3-dot button (...)->More tools->Save page as.

VirtualBox checks if loaded system files have been tampered with. Your uxtheme.dll doesn't pass the check. 1490.d9c: supR3HardenedScreenImage/LdrLoadDll: rc=Unknown Status -22900 (0xffffa68c) fImage=1 fProtect=0x0 fAccess=0x0 \Device\HarddiskVolume3\Windows\System32\uxtheme.dll: Not signed. '\Device\HarddiskVolume3\Windows\System32\uxtheme.dll' is most likely modified.

I'm interested in the technical explanation of the crappy performance in a VM. Is it any better in Hyper-V compared to VMware/VirtualBox? Hyper-V tends to slow down the host somewhat due to the way it works.

One change I refuse to accept is Explorer with the new UWP search bar. It just looks out of place with its height IMHO and doesn't support search parameters. It's possible to revert it in Win10 1903/1909, but not in 2004+ AFAIK. They didn't care about all the complaints on their own discussion channels when Windows 7 was released when Explorer stopped indicating shared files with an icon overlay, with Windows 8.1, they changed it so it doesn't logically group storage devices anymore and it's significantly slower at counting files since then (open properties of some big folder with files of various sizes and compare). That's some of the problems that accumulated over time, some can be fixed by 3rd party software. Not related to Explorer, but what's the deal with the lag that occurs when you open the window for editing a task's trigger in Task Scheduler? That problem is at least 11 years old by now.

There's no issue adding it directly, eg.: reg.exe ADD "HKCU\Control Panel\Desktop" /v SCRNSAVE.EXE /d "whatever.scr" Putting this as the run entry works fine.

Oops, I overlooked the Shcore.dll. Since it's a paid game, I can't obtain its .exe, otherwise, I could tell you what bytes to change with hex editor. Hex-editing SetProcessDpiAwarenessContext->SetProcessDpiAware (they're both in user32.dll) + plus NOPing out the code from the .exe that calls it should still do the trick, but a hex editor alone isn't enough in this case unless you have x64 assembly code parser in your brain. And assuming there isn't something in there that checks for modifications, but since it's an indie game, it probably doesn't. They'll look into the fix as I've read over Steam discussions, hope they come across the docs. Just to reflect the CURRENT state of the game I think.

Are there any other dependencies besides SetProcessDpiAwarenessContext (check with 64-bit Dependency Walker)? If not, hex-editing the .exe by changing SetProcessDpiAwarenessContext->SetProcessDpiAwareness should at least make it launch on Windows 8.1 (set bytes of "Context" part of the string to zero). A call to SetProcessDpiAwareness with parameters of SetProcessDpiAwarenessContext will probably make it behave as if the call wasn't made, error code would be returned and assuming the game doesn't check it, it should be fine (may need fiddling with compatibility settings on the .exe related to DPI in certain cases), though I'm not 100% on that since I can't tell the numeric constants of the possible parameters passed to SetProcessDpiAwarenessContext from the definitions and I don't have the right tools at hand to tell. If this is the only issue and devs refuse to fix it, I would change SetProcessDpiAwarenessContext string to any USER32 API that the oldest OS that satisfies all other dependencies supports and NOP out the problematic call in the code and declare DPI awareness via the manifest like MS recommends to cover the users using DPI higher than 100%, Resource Hacker would help with the latter, but a debugger like x64dbg would be required to modify the code.

There's little more behind dependentlibs.list than the mere check for listed DLLs. Arbitrary DLL may be dropped in the application directory and have its name added to dependentlibs.list before xul.dll and the listed DLL will be loaded at application startup. The reoccurring pattern is that said .list file lists non-system DLLs that xul.dll depends on, with xul.dll being the last on the list. I don't see a good reason for existence of dependentlibs.list and the logic behind it. When it comes to actual dependencies of xul.dll, they are resolved by the operating system when the library is loaded. Why the extra code to load them explicitly?

It's possible that an update would come and break Aero Glass in a way that just updating symbols wouldn't help and the utility would have to be updated to compensate. I noticed KB4571748 from August 2020 is still the last update for Win10 1809 that changes DWM files. Aero Glass was broken in Win10 1909 with an update that arrived several months earlier.

What's the reason for doing this exactly? In this case, it seems there's no guarantee that would be installed in the first place, so this could backfire by not working for many. Shouldn't be a problem if all VC++ redists from 2005 - 2019 are installed. I do it so i don't have duplicates and for such libraries, it doesn't make sense that each application has its own copies as they're supposed to be shared resource.

You need x86 variant in this case. This looks like an oversight though as runtime libraries are supposed to be bundled with the browser, so roytam1 should add the missing vcomp120.dll. I personally delete all such runtime DLLs from programs' folder and let them use the ones installed system-wide. Some, but not all Firefox browsers' dependentlibs.list file contains those DLLs' names, they should be deleted from it to avoid "Couldn't load XPCOM" error after deleting the DLLs.

I don't think THEY'll bat an eye. "Download more RAM"? What an immature response. So unless you want to build the entire browser from source yourself, roytam1's fork is probably going to be the most accessible option in the future. You also get some bells and whistles that the upstream dropped, like early WebExtension support. It might be a bit slower in places, at least theoretically, due to usage of critical sections instead of SRW locks. Maybe roytam1 could implement runtime check in the future, use SRW locks if available and critical sections otherwise. Some folks run Vista and they could benefit as well since Vista already supports SRW locks. When the time comes, I'll make a switch.

It's set to Metro skin, which might be the default setting to not look out place compared to the rest of the OS. Selecting Windows Aero on the Skin tab makes it more similar to Win7 menu.

They're extracted to temporary directory behind the scenes. Other programs wouldn't be able to work with them otherwise.

To answer the OP's question, in the .bat file, the one and only occurrence of "add-package" should be replaced with "remove-package", save it then run it administrator.

Maybe, though I'm not the one to ask.

https://github.com/mcmilk/7-Zip-zstd Found it a while back, it's basically 7-Zip on steroids. Perhaps someone finds it useful.

Turns out it's not so simple...it's linked to APIs that don't exist in Windows 7.

Assuming dependencies are satisfied, you have to modify the .exe so it doesn't specify minimum required OS version as 10.0 using a tool such as CFF Explorer. If I remember correctly, you're looking for MajorOSVersion/MinorOSVersion and MajorSubsystemVersion/MinorSubsystemVersion, they have to be modified to target 6.1 instead of 10.0. It'll probably also need MUI files carried over before it'll work, but I can't say more ATM as I'm not on computer. PS: that error message is misleading, you have to upgrade to Windows 95 to get more accurate error message.

Even though it's possible to install gpedit.msc with the batch file in the first post, does it even work properly under any circumstance? GitHub page of the alternative tool Policy Plus says that policies are applied on logoff/logon, but it doesn't seem to work, the registry setting that each applied policy modifies remain untouched (Win10 Home v1809).

AVG managed to revive itself after reboot, though it started crapping in that registry setting again. The most important thing, I wanted to make sure temp files from other installations were cleaned up. Ended up uninstalling AVG. Until I use that machine, viruses are the least of concerns.