Jump to content

UCyborg

Platinum Sponsor
  • Posts

    2,631
  • Joined

  • Last visited

  • Days Won

    28
  • Donations

    100.00 USD 
  • Country

    Slovenia

Posts posted by UCyborg

  1. Does anyone else get this bug: plug in USB flash drive or similar type of storage device, then try deleting a file from its root. The dialog asking if you want to delete a file should report its size as 0 bytes regardless of the actual size.

  2. It might be possible if one knows some tricks, which would apparently be required to implement this correctly. OldNewExplorer is good at reverting certain behaviors in Explorer, this might be one of the things you could add to Fix-Newer-Windows-File-Explorer-Oddities list.

    I went back to Windows 8.1 on my main machine after recent incident. Stlll, this information might be useful to someone else. I wonder how Windows 10 will be in general after 2 years from now, particularly when it comes to regressions like this.

  3. This turned out to be a bit longer than intended, but someone may find my recent experience interesting, otherwise, feel free to skip the following 3 paragraphs.

    My decision whether to stay with Windows 10 or go back to 8.1 on my old trusty desktop was made easier by a recent BSOD I got during troubleshooting the update problem (UNEXPECTED_STORE_EXCEPTION), which left some serious corruption in the file system. The system was half-broken after a reboot, couldn't even open Computer Management. Running chkdsk afterwards from Recovery fixed a lot of errors, but also purged a lot of OS related data, which rendered it unbootable. Suddenly there was approximately 20 GB of extra free space on the OS partition.

    It could be that at one point in time, possibly after Anniversary Update, some sort of incompatibility arose with the customized driver for my motherboard's SATA controller. It was occasionally reporting some generic error for all my disks in event log. The motherboard is from 2008 and the last time drivers for its chipset were updated was back in 2010 when Windows 7 was the latest version. Despite the error, nothing appeared out of the ordinary for the long time, which makes this case even stranger. Been running Windows 10 since build 10586.

    Testing hardware doesn't indicate any failures, RAM is OK, S.M.A.R.T. parameters are normal, not a single sector had to be reallocated in the past, no read or write errors etc. Windows 10 still functions on my own and family members' laptop, all of which have newer hardware. The only problem encountered few weeks ago was the Intel graphics driver failing to update properly on one machine via Windows Update, surprisingly, I got the newer driver to work without much hassle; rolling back to the old one from Device Manager, running uninstaller from Program and features, rebooting, then it could be magically updated via Device Manager without a problem, which installed the same version from Windows Update. Still, it shows how unreliable Windows Update can be, even when it offers the driver that does actually work fine, but somehow fails installing it properly so the user is stuck with low-resolution mode.

    The first thing I've noticed when installing Windows 10 is how much longer it can take to boot, especially on cold startup where fast startup aka. resume from hibernation isn't involved. If Windows 8.1 and 7 could be ready in 30 seconds or less, Windows 10 can take whole minute. While SSD disks are the norm these days, there's no reason for a PC with a decent classic HDD to not feel reasonably snappy. Although the type of hard drive isn't the only contributing factor, the difference can be really astonishing. This reminds me of the most silly argument I've ever heard from Microsoft from the time Windows 8 was released: We've made startup process so fast that we don't let you press F8 anymore to let you access the boot menu. Faster boot times being popular argument in favor of Windows 10, yet I'm seeing the exact opposite results. Fast startup is compensating for bad startup performance more than ever in Windows 10, and it's still faster in 8.1.

    Windows 8.1 with fast startup enabled and without disabling anything manages to get me to the desktop so fast that Welcome screen doesn't even have the time to appear! My main monitor needs 3 seconds to display the image after receiving initial signal when the display driver takes over (it's not plugged in the first DVI port). Then just add 2-3 seconds for the Windows boot screen. Windows 10 always took its time before it was ready. Can also observe the slowness when comparing with virtual machines. Perhaps this script could turn things around in such scenario? Will definitely give it a go next time I'm messing with Windows 10.

    Someone reported the tweaker script cut memory usage from 70% to 30% on a machine with 1 GB of memory. That's very impressive! Seems like Microsoft is updating OS but not the minimum hardware requirements for optimal experience. On Windows 8.1 with Classic Shell after taking care of few checkboxes, Metro stuff can be easily ignored. NTLite may be worth checking out, though you don't get all of its functionality for free.

    I still don't get the decision for removal of things like MIDI Mapper and GUI allowing full control over wireless connections since Windows 8. On the other hand, you still find policy settings applicable for older systems dating as far back as Windows XP in Group Policy Editor. But additions in Windows 10 still make the OS heavier than it should be, regardless of whether the user utilizes them or not.

  4. There is this annoyance in Windows 10's Explorer, if the user enables desktop slideshow and Automatically pick an accent color from my background, the scrollbar will jump up on each desktop background change, which triggers accent color change which is actually indirectly responsible for current Explorer behavior. It seems unlikely, from various responses over the internet, including Reddit, that Microsoft will ever address this, so probably the only hope would be coding some hack to remedy this. I came up with a very simple prototype DLL that can get rid of this annoyance.

    #include <Windows.h>
    #include <easyhook.h>
    
    HOOK_TRACE_INFO H_WindowProc_info;
    LRESULT (CALLBACK *O_WindowProc)(HWND, UINT, WPARAM, LPARAM);
    
    LRESULT CALLBACK H_WindowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
    {
    	if (uMsg == WM_SETTINGCHANGE && !wParam)
    	{
    		return 0;
    	}
    	return O_WindowProc(hWnd, uMsg, wParam, lParam);
    }
    
    BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
    {
    	if (fdwReason == DLL_PROCESS_ATTACH)
    	{
    		DisableThreadLibraryCalls(hinstDLL);
    
    		HWND hWnd = FindWindow(TEXT("CabinetWClass"), NULL);
    		LONG_PTR WndProc = GetWindowLongPtr(hWnd, GWLP_WNDPROC);
    
    		LhInstallHook(WndProc, H_WindowProc, NULL, &H_WindowProc_info);
    		ULONG ACLEntries[1] = { 0 };
    		LhSetExclusiveACL(ACLEntries, 1, &H_WindowProc_info);
    		LhGetHookBypassAddress(&H_WindowProc_info, &O_WindowProc);
    	}
    	else if (fdwReason == DLL_PROCESS_DETACH)
    	{
    		LhUninstallHook(&H_WindowProc_info);
    		LhWaitForPendingRemovals();
    	}
    	return TRUE;
    }

    This is just proof of concept. It seems intercepting certain WM_SETTINGCHANGE messages so they never make it to Explorer and therefore prevent it from refreshing whatever things it refreshes gets rid of the annoying behavior. I use EasyHook library for function hooking. There could be downsides, can't say for certain if there are cases where certain important system setting changes that would make the Explorer receive WM_SETTINGCHANGE with zero wParam and it would be a good thing to reload whatever settings it reloads.

    The problem I'm facing, I have to somehow intercept window creation process and then hook its window procedure. The above code will only work for one already existent window, need to make this thing dynamic. I must be missing something obvious because if I hook the RegisterClassW function to get the address of window procedure to hook it (obviously I interfere only when the class name is CabinetWClass), the hook isn't called at all then, but LhInstallHook function doesn't return a failure. I think I'll try hooking one of CreateWindow functions next then use GetWindowLongPtr to get its window procedure address and hope that works.

    Edit: It seems each window uses its own dynamically allocated window procedure, but I don't know how it's set, SetWindowLongPtr apparently isn't involved. Must be set when window is ready somehow. Thought this'd be easier.

  5. 6 hours ago, NoelC said:

    Microsoft hangs it on, I trim it off.  It remains to be seen whether a system so-tweaked is any better than its predecessors.

    Probably not, at least not significantly. My excuse for running latest Windows version is that it usually runs the widest collection of software/games. Unless you're fan of UWP apps, I don't see any advantage. Sure, there are some small nice things there and there, but are they really worth it?

    My main Windows 10 installation decided to crap itself, update KB4014329 just refuses to install with ERROR_SXS_TRANSACTION_CLOSURE_INCOMPLETE. Usual remedies don't help, neither sfc /scannow nor Dism /Online /Cleanup-Image /ScanHealth find any corruption, tried with /RestoreHealth anyway and specified good install.wim from fresh ISO image, still no go, Windows Update troubleshooter supposedly found and fix some corruption in Windows Update database, nope, still won't install, manually cleaned Windows\SoftwareDistribution after stopping Windows Update, no, that's not it neither. Needless to say, I did reboot between each troubleshooting step and ruled out hardware failures.

    At this point, who knows if it would even upgrade to 1703 without some fail in the middle of the process. Might just disable Windows Update completely and stay with the current build. Or I could go back to Windows 8.1, that option would also work well for me, it just takes time to set everything back to the way I like it.

    Either way, the OS should be transparent and not stay in the user's way. Windows 10 seems to be exceptionally good at doing the exact opposite. Now, you're excepted to fight the OS every few months. Not in Microsoft's opinion, you're supposed to take it as it is.

  6. Would be nice if people bothered to read the whole thread, it hasn't grown into a super long thread. There was a hint on the first page that the Creators Update compatible version is in the works, it'll just take a while.

    4 hours ago, daveo76 said:

    Build date is 1703

    So it'll turn to 1704 when it releases.

  7. You could try and see if it works in safe mode. There is a trick to get Aero Glass working in safe mode, first, install it as the service just to get rid of dependency on Task Scheduler (see http://www.msfn.org/board/topic/170945-uxtheme-signature-bypass/?do=findComment&comment=1136296), maybe you could just enable Task Scheduler in safe mode instead (I haven't tried), but this way, you keep things to a minimum, then, you have to add both Aero Glass and Themes services to the list of safe-mode enabled services (see the attachment).

    AeroGlassSafeMode.zip

  8. 56 minutes ago, raiden89 said:

    BigMuscle needs to know its an issue so it can be fixed. Right now its just being passed over.

    Agreed. This feature for restoring modern app frames to have theme defined appearance has been considered experimental for quite a while and it seems it's not quite there yet. I think that detail about tablet mode is important to know for testing purposes, otherwise one could suggest just running Edge, since it's one of the apps that don't require Microsoft account, but guess what, it doesn't have full-screen toggle AFAIK. Don't forget you can just turn that particular Aero Glass feature off (http://www.msfn.org/board/topic/176569-aero-glass-for-win81-153/?do=reportComment&comment=1136963), so at least the functionality isn't effected in negative way.

    There is also a minor bug with caption centering feature, when application resizes its own window and TextGlowMode is set to 0 or 3, the caption isn't always centered right afterwards. The easiest way to reproduce the bug is with Command Prompt window. Right-click on its frame, go to Properties->Layout then change Width under Window Size to something smaller than default eg. 80 and confirm the new setting. Then return to Properties dialog and set it back to 120.

    AGCmdResize.png.d88590d715c4685b3427844564947b8c.png

  9. 2 hours ago, raiden89 said:

    Does this build fix the bug I reported earlier in this thread with modern apps that have full-screen like Xbox? If you start streaming in that app, it goes to full-screen automatically. Aero Glass removes the caption buttons so you cant close, minimize, or exit full-screen.

    No. Here's a hint for everyone, this isn't app-specific issue. It can be reproduced in any modern app, simply activate Tablet mode.

    A note about SeDebugPrivilege, it seems it's enabled by default when running under SYSTEM account.

  10. 8 hours ago, bigmuscle said:

    I'm not aware of any change, so maybe it happened accidentaly. When setting TextGlowMode to 0x00000000, it simply means "Do not apply any glow effect on the text". When low-word is set to 3, the high-word is just passed to iGlowSize variable in DrawThemeTextEx function.

    Yes, 0x00000000 is okay, my point was, 0x00000003 no longer produces glow effect, have to set it explicitly to 0x000c0003. I played with DrawThemeTextEx a bit and from what I've observed, if you don't enable DTT_GLOWSIZE flag in struct member DTTOPTS.dwFlags, then the function will use TEXTGLOWSIZE value from .msstyles, otherwise, it takes DTTOPS.iGlowSize. Just so that we're on the same page, I tested with modified aero 2.msstyles from Aero 7 Clear theme. Your guide also says for TextGlowMode: 0x3=Composited glow effect using your theme settings. HIWORD of the value specifies glow size (0 = theme default).

    That's why I think something strange must have happened from 1.5.1 -> 1.5.2. I was also curious about the possibility of Aero Glass controling GLOWINTENSITY property, but it looks like DrawThemeTextEx doesn't offer any control over it, bummer.

    8 hours ago, bigmuscle said:

    Unfortunately, this is unfixable. When TextGlowMode is set to 3, glow effect is completely controlled by DrawThemeTextEx function.

    So subtracting a little from RECT.left is not a solution in this case?

  11. 4 hours ago, bigmuscle said:

    - if glow effect is enabled and caption is set to be centered, the glow effect will be drawn over whole frame width - do NOT report it as the bug!

    Which can look pretty ugly, but the composited glow effect looks nice:

    AGCenteredCaption.png.83a5b15d35cc0887364b57d67e28d27a.png

    It seems you have changed the behavior when registry setting TextGlowMode is set to 3. In 1.5.1 and earlier, the size WORD set to 0 meant use the value from .msstyles, in 1.5.2 and 1.5.3 zero means no glow. Old behavior seems to make more sense.

    For this setting to have any effect at all, GLOWINTENSITY property in .msstyles must be non-zero in .msstyles (http://i.imgur.com/McXdF28.png) so if the person doesn't use custom .msstyles, he doesn't have access to this kind of glow. Is intensity something Aero Glass could control if the user desires? As long as people understand there is no clean way to control these parameters for applications that draw captions on their own, as those questions have arised in the past and you don't really get an answer unless you dig into the whole theme hacking and related matters.

    If you use TextGlowMode set to 3 and leave caption text left-aligned, there remains the bug with text being shifted slightly to the right, the same problem you've fixed in 1.5.2 for glow effect from atlas image. It only shows when both size setting in UI and GLOWINTENSITY property from .msstyles are non-zero.

    A note about things to come, it seems changes in current Creators Update builds are extensive enough that will once again require modifications to Aero Glass internals when it releases. If I remember the build number correctly, there were symbols available for 15055, and it crashed with an error saying it couldn't find symbol CGeometry::GetShapeDataNoRef.

    It's great to see a new update! I noticed the bug with debug.log being created in the root drive is gone as well. I wonder about the practical effects of SeDebugPrivilege addition, supposedly being mandatory to inject code in critical system processes, one would assume it was there before.

  12. Regarding registry settings, it was never stated they're supposed to be there, you have to create them yourself or use GUI. And no need to create new topic, these things have been discussed before. You can't do much but wait and hope for a new bug-fixed version to come out. Aero Glass on Windows 8.1 is a better experience, though that fact doesn't help us much on Windows 10.

  13. I think we're lucky if we get fixes for existing issues. It's so close to perfect. This auto-update idea reminded me of another possibility, would it be possible for DWMGlass.dll to clean-up after itself on unload? That'd be neat. It crashes if you unload the DLL. I wonder why in recent Windows versions Unload option in Process Hacker works for dwm.exe while in regular processes it throws "Unable to find the module to unload."

  14. 11 hours ago, CKyHC said:

    With UxStyle didn't work glow on headers ribboned windows. Returning to UxTSB.dll through AppInit_DLL.

    Because that's not the job of theme signature bypass tool. By original design, applications that draw controls on window frame, must then also draw window caption using DrawThemeText API. UxTSB.dll just hooks that function and if random application uses it for something else, you get unexpected results like these:

    The cleanest solution for the most consistent experience accross applications is modifying theme to enable text glow like it was on Windows 7, take note of TEXTGLOWSIZE and GLOWINTENSITY properties:

    McXdF28.png

    Then set "Caption glow effect mode" in Aero Glass GUI to "Use theme settings". At least that is supposed to get you default Windows 7 behavior, the problem is the long-present bug in Aero Glass with text not being rendered at correct position. For now, I use the option that takes glow from atlas image, so I have one type of glow for regular windows and the other for ribboned windows. Though it's not connected to ribbons, it's the customized frame.

    The other type you get is composited glow controlled by those two properties I mentioned. Aero Glass only overrides TEXTGLOWSIZE, so no glow if GLOWINTENSITY is 0. I think the glow from atlas image is exclusive to captions of regular windows. And so is custom colored caption text without UxTSB.dll in every process (AppInit_DLLs method).

    53 minutes ago, CKyHC said:

    Dblake1, this shortcut exists in Modern Settings - Personalization - Themes.

    Not in Creators Update.

  15. 19 hours ago, drfsite said:

    I tried that per the suggestion of someone here, it worked for about a day or two and went right back to the same problem.

    However, the actual effect was interesting - the Explorer windows I had open prior to the customization breaking would continue to look fine, but any NEW windows I opened after that point were broken.  Task-killing the new ones didn't help, I had to kill ALL explorer processes to fix it.  So it was easier to just switch it back to non-separate processes so there's only one instance to kill and reopen.

    I see, it seems we all have a little different experience. I figured that since I'm on Windows 10, "Launch folder windows in a separate process" is a must for me, I've been getting frequent Explorer crashes before, almost every other day. Are you saying "Launch folder windows in a separate process" gives you separate process for every explorer window? I only have one extra process, regardless of how many windows I open. I usually use tabs given by QTTabBar extension.

    One constant thing on my end is that Explorer process' memory usage rises with time. The one that hosts its windows is now at 157 MB and it's been running for more than 9 hours, even though I haven't had any window opened for a while.

  16. I just realized why you can't use unsigned theme on Creators Update without editing registry, the theme selection settings have been moved to Settings app. Manually injecting UxTSB.dll in SystemSettings.exe with Process Hacker 2 makes it work!

×
×
  • Create New...