UCyborg

Looks like someone expressed the same interest 4 years ago on SevenForums. It does actually work on 32-bit Windows 7 (and also 8.1), though access violation error pops up when logging off. Those binaries are 32-bit, but we'd need 64-bit ones for it to work on 64-bit systems. In best case scenario, code would just have to be recompiled. But since they're talking about porting it to 64-bit, it probably contains errors which would have to be corrected before it would work properly. If someone else won't do it, I may look into this again at some later point when I have more time.

By changing the number after the first decimal point in string value Version under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DirectX.

Can confirm, Aero Glass 1.5.9 does not work at all on Build 17134.441. Just crashes DWM and having manually downloaded symbols doesn't help neither. Despite the presence of appropriate debug symbols, the log file says that it's loading them from patterns instead of external files. minidump-12-01-16-29-04.7z (with debug.log) Experimental version for Build 17763 is not usable with 17134.441 neither.

Found the cause, Function Discovery Resource Publication service wasn't running.

I got version 1803 on my desktop. I found some under-the-hood changes beneficial in my every day usage. Didn't really think I'd be saying that after the experience from a year or two ago. I don't intend to switch to newer build at this time. I doubt anything that would interest me is coming, plus, the split personality between Settings app and Control Panel remains irritating.

I'm noticing on my main PC where I got Windows 10 (Build 17134 (1803)) working relatively well that it's significantly less aggressive in page file usage compared to Windows 8.1. Having a browser opened with a bunch of tabs for several hours and one virtual machine running, almost maxing out 4 GB of RAM; when I get around closing everything, there's much less disk activity and programs close several seconds faster. It was pretty common for my usage on Windows 8.1 that I had whole 2 GB of physical memory free and at the same time, a whole gigabyte of junk in the pagefile. Transitions from/to certain fullscreen applications to/from desktop, most notably those reliant on DXGI/D3D11 are smoother, particularly with multi-monitor setup. And so are the resolution switches; the screen on which the resolution is changed doesn't result in the screen temporary blanking (only goes blank if refresh rate is being changed). There are less occurrences of other screens blinking when resolution on one screen changes. It appears Windows 10 specific graphics drivers play a part in preventing blinking in certain scenarios, mostly noticeable when resolution is changed on behalf of some fullscreen application that is using some 3D graphics API. Some of these things related to graphics are probably result of how the compositor (Desktop Window Manager) is integrated, which is still shaky at places. Switching users will move windows on the secondary screens, this one dates back to Vista. Sure you can turn off composition on Vista/7 and live with the screen tearing on the desktop. And ever since Windows 7, when composition is enabled, flickering can be observed when things are drawn with GDI. https://stackoverflow.com/questions/17277622/dwm-in-win7-8-gdi https://www.youtube.com/watch?v=iU_zhKZKzNA The issue described can also be observed in 7-Zip when drawing selection rectangle with the mouse. One really good example with this bug in action is the old Pinball game, the version that comes with Windows XP. Ball just seems to vanish when it's moving at high speed. There's a workaround (compatibility shim/fix) that can be applied on per-application basis called NoGDIHWAcceleration. Compatibility Administrator is needed to apply it, it's part of Windows 8.x/10 ADK or Microsoft Application Compatibility Toolkit 5.6 for Windows 7 and older. Not sure about the effects on performance with this option. They also haven't completely tackled the issue with alt-tab/taskbar programs' preview thumbnails being "forgotten". Another thing handled by the compositor. On the positive note, they don't seem to be lost anymore (at least from my experience) when doing regular stuff on the desktop and using power saving functions (sleep/hibernation), though they're lost when certain 3D applications change resolution. Whether it happens or not seems to depend on the combination of used graphics API and settings in HKEY_CURRENT_USER\System\GameConfigStore, more specifically those with FSEBehavior in their name. I've only seen those FSEBehavior settings affect D3D9 applications. Doesn't seem to matter whether GameDVR_Enabled is 1 or 0.

There are also issues with older AMD cards on 1809. https://www.tomshardware.com/news/windows-10-1809-still-broken-trend-micro-amd,38078.html

Observed another usability degradation in Explorer, which must have been there for a while now. While you can still use Folder Options X or QTTabBar to restore the old view control that displays files and folders, custom file ordering is not remembered. The taskbar still loves to flash. MS is also trying to hide instabilities of their own and other people's software. UWP stuff always just closes on crash without any indication for the user what happened. Same behavior can be observed with Win32 applications, but that can be amended with editing registry settings for Windows Error Reporting. Consequently due to default settings, you don't even get the option to invoke debugger on application crash (the one defined in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug key).

Exactly the kind of thing that worries me. That's why I prefer more conservative approach to updating. If you don't run into serious issues, it works just fine.

This. And the fact that the update infrastructure is a fragile mess doesn't help. For example, why does WU offer both October 2018 and November 2018 Quality Rollup updates for .NET Frameworks. Why not just the latest? Take a look at KB3191564; Update for Windows Management Framework 5.1. The known issue: What I wonder, is this partially installed problem really applicable only if you've installed security-only KB4025333 update? What if you've updated with regular quality rollup updates, which contain security and other updates? Given they're newer than KB4025333, they'll definitely contain newer version of components that KB4025333 also contains. So if you're on December 2017 patch level, you've installed December 2017 quality rollup update plus the other updates offered by WU and you then choose to also install Update for Windows Management Framework 5.1, will that NOT overwrite some newer components with an older versions? Because apparently, it's possible to install an update that has an older version of some DLL file, and even if the newer version of DLL is already in the component store and hardlinked to the correct location where it's usually loaded from, eg. System32 folder, installing update that contains older DLL will install it alongside the newer DLL in component store AND hardlink it to System32 or whatever folder, so you'll have both DLLs on the system, but the older version will be the one that's actually used. At least that's what I've observed when I did some experimenting a while back. Unfortunately, I didn't note down the results so can't tell which updates I've been messing with. I know for a fact that it's easy to break something when messing with updates.

Given that newer versions are just incremental upgrades and downgrades in some ways from previous versions, there probably aren't any compelling reasons, except if there's some extreme requirement by a certain user. Can't think of any from my POV as a non-demanding user. I just made this thread to highlight the silliness of restricting Office 2019 to Windows 10. :)

Latest cumulative update for Build 17134 (aka. April 2018 Update) also fixes the issue with broken ICopyHook interface (dragging and dropping files from programs like FileZilla to Explorer works again) and the issue with missing ellipsis in various places where the text is too long to fit (it occurred only when extra length didn't exceed 3 characters).

It's possible to download an ISO of the latest build that's deemed stable from... https://www.microsoft.com/en-us/software-download/windows10 ...by changing web browser's user agent to say you have non-Microsoft OS.

Aero Peek is broken since 1803. Somehow running Aero Glass on 1803 fixes it. I tried asking @bigmuscle about it in the other thread, but didn't get any response.

Here's another f***up in 1809. Using Explorer to handle ZIP files for some reason? Well, if you try to extract a file into a destination folder where the file with the same name exists, extraction will silently fail without presenting a dialog asking whether to overwrite the file.

The older builds also have/had issues, some are never addressed. Recently, I needed to transfer some files to another computer, used plain file shares. The Windows 10 computer never appeared in the Network folder, neither on the machine in question itself nor on the other computer from which I wanted to access the files. It could be accessed by manually typing its hostname. That bug with deleting user files is on the whole new level. It just never ends. We're not even talking about abusing the software with crazy combinations of user input.

You can disable the task without removing custom trigger first, its presence just prevents other task properties from being edited in the GUI, disabling works either way. Whatever that task's custom trigger is for, it's disabled by default. This is its description in the task's file (XML): <WnfStateChangeTrigger> <Enabled>false</Enabled> <StateName>7508BCA3380C960C</StateName> <Data>01</Data> <DataOffset>0</DataOffset> </WnfStateChangeTrigger> Whatever that means.

That's strange, I just re-enabled Windows Defender, updated its definitions and the task did stay disabled. At least on my end, the only other user with write access to the file is the administrators group, so nobody except me should be able to modify it. Though setting just Everyone to read-only access should be the most thorough action that can be accomplished by messing with permissions alone. The only Windows 8 installations I have for testing is Windows 8.0 with zero updates and Windows 8.1 with only security updates 'till December 2017. There should be something out there available to monitor file access. Process Monitor perhaps? Maybe it can help determine what changes the task. Edit: Forgot to mention, I noticed having Windows Defender enabled does cause Windows Update service to start at boot, that is, with both scheduled task disabled and that machine policy trigger removed.

I don't know what that machinepolicy trigger is supposed to be, just noticed it causes the service to start on cold boot. I didn't take Windows Defender into account, just assumed it would work after seeing it didn't reset on reboot. What about taking the ownership of the file, disabling inherited permissions and just set one entry - Everyone - to allow just read-only access? Scheduled Start task by itself doesn't do anything beyond starting the service. I also don't remember ever seeing the service updating Windows Update state if updates were disabled, always have to check manually. No idea what messes with those tasks; I noticed it gets enabled on reboot with Windows Defender service disabled, so some core component/service must be responsible.

Because Task Scheduler GUI doesn't understand custom triggers. If you delete it, it works. Windows Update service has a trigger defined that will start it under certain circumstances; remove it with: sc triggerinfo wuauserv delete start/machinepolicy For the task being recreated/overwritten problem, disable it in Task Scheduler first then take away write permission for the SYSTEM account on the file C:\Windows\System32\Tasks\Microsoft\Windows\WindowsUpdate\Scheduled Start.

I suspected this might be the case. At least when you run the installer on the official Office 2019 image, it runs successfully on both Windows 8 and 8.1 if you use the debugger to make RtlGetVersion function in ntdll.dll return Windows 10's major and minor version; 10.0.

It installs after fooling the installer into thinking it's running on Windows 10. Installed programs seem to function without issues at first glance without any workarounds. No luck running the installer on Windows 7. It wants SetCoalescableTimer function (Windows 8 and up), which I could redirect to SetTimer, but then the exception is thrown in msxml6.dll and I don't know how to proceed further.

I thought Configure Automatic Updates policy in gpedit.msc was completely ineffective these days. Turned out WU was already downloading updates in the background when I was testing its effectiveness a while back, making it seem like it doesn't do anything. Thanks for confirming. I see that it alters registry settings in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate key. I was aware of the settings there, just unsure about their long-term effectiveness. I see Windows Update Mini Tool and Windows Update Manager have similar interface, the latter also has some radical options to block the updates: capping the Update Orchestrator service and blocking access to update servers by utilizing policy settings for re-directing update service away from Microsoft's update servers.

How do you manage to keep updates disabled? Currently using registry value *NdisDeviceType set to 1 (type DWORD) under my network adapter key, these keys can be found in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}, refer to DriverDesc value of each numbered key to find the right one. This works, but also disables some of the networking functionality, so it's not the best approach. If I disable the update services (BITS, UsoSvc, wuauserv, WaaSMedicSvc) through conventional means (sc config <service name> start= disabled) and the tasks in UpdateOrchestrator, WaaSMedic, WindowsUpdate folders, all of these just re-enable themselves eventually. What prevents these services from even starting is removing them from the lists in registry in the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost Requires reboot to take effect and failures of service startup are logged. I've seen Windows Update MiniTool mentioned, which I haven't tried yet; does it have any magic options to keep updates disabled? I'd prefer something at least convenient as just disabling those services and re-enabling them when I want to update, so I'm open to suggestions.

Sorry, I don't have any suggestions. It's difficult to diagnose these things remotely. I guess it's something other than Visual C++ Redist, but can't say for certain.