UCyborg

Do you still get those random notifications with the updated version? BTW, I did a test; I compiled modified 32-bit version and tried invoking the code for displaying notifications. Guess what, those yellowish glitches we've discussed showed up! As long as it runs on 64-bit OS, they show up.

Not strange at all after you realize that the program's code for handling messages passed to notification area is flawed. Depending on how programs are coded, GlassToasts could even prevent them from showing an icon in notification area...

The actual rendering code is likely located in either dwmcore.dll or uDWM.dll. Probably. Doesn't look like simple hex editing would be able to accomplish it.

Right, I didn't consider you can throw exception with arbitrary exception code. I guess other exception information isn't recorded if crash dump fails to get generated. Out of curiosity, are you able to use any other debugging techniques except printf debugging when developing Aero Glass?

Compatibility engine is present regardless. And so is the default compatibility database. Judging from the strings in apphelp.dll, there's a flag in compatibility database that says it shouldn't be loaded on that version of the OS. Consequently, you may have a buggy Win9x era application that works out-of-the-box on full XP, but crashes and burns on FLP. Nevertheless, it's still possible to apply compatibility fixes with Compatibility Administrator v5.0 that comes with Microsoft Application Compatibility Toolkit v5.5. It's also possible to install newer, also easier to find 5.6 version of the toolkit, but its Compatibility Administrator can't read application entries from system database on XP, which might be useful for reference.

Then all is well as far as Aero Glass is concerned. But one big question remains, what does the exception code 0xe0464645 actually stand for? Is it even documented anywhere? I don't have Win10 SDK installed, but neither OllyDbg nor x64dbg recognize it. Maybe it's internal, perhaps even specific to DWM process. Win8.x are the same. I've actually seen DWM get messed up more often during fast startup sequence on Win8.1. I mentioned some oddities a long time ago in Win8.1 thread, the problem with AG unable to read its settings and screen glitches. Been lucky with Win10 in that regard, hasn't happened once so far. There also wasn't any recognizable pattern. Makes you wonder what MS was trying to do in their fast startup code. Since you can log off and then put PC in hibernation and the end result is almost the same.

I know about some of these issues, it was late and had some other things on my mind. Was going to write about them here anyway. That's actually a "bug" in the Readme which I haven't updated (yet), the correct parameter is -silence Yes, this one is the most bizarre and only happens in x64 version and only with default skin for unknown reason. Strange, can't reproduce this one.

The version from 12th January still doesn't work quite as it should on my end. After hybrid shutdown, DWM's state becomes corrupted; transparency doesn't work on top windows' frames and the secondary screen doesn't black out during log off. I've captured a dump of dwm.exe when it's in that state, if it helps. https://drive.google.com/open?id=1vfrN9Esr6hTggp1ABDOme4iCaMnY2Dkl Also got a crash 2 days ago after PC came out of sleep; dwm.exe crashed with exception code 0xe0464645, somewhere in kernel32.dll. BTW, this bug is still a thing.

Here we go!

Yes! If it doesn't work right away, just log off and back on.

I'm experiencing the strange issue with the latest debug version. When I login and dwm.exe has been running from when the previous session was closed due to initiating hybrid shutdown, the transparency on the top frame doesn't work. Oddly, it works on other sides (left, right and bottom). Also when this happens, when I log off, the second screen doesn't black out, the last frame of the desktop stays on it until the user is completely logged off. I guess this is when that instance of dwm.exe terminates.

Open firefox.exe with Resource Hacker: Copy-paste the entire content minus the highlighted line.

I think so. I haven't actually got around trying whether this registry setting still works (it's Windows 10, so you never know). I'll try it later today and edit this post to let you know. Edit: It works! If it doesn't work right away, log off and back on.

Try this.

ReactOS is an interesting project, but it would need a serious backing for it to move anywhere at a faster pace. Its devs also have to be careful to not violate Microsoft's license terms when implementing functionality. See this. ReactOS CONTRIBUTING.md file in the source code repo: Legal notice: If you have seen Microsoft Windows source code, your contribution won't be accepted because of potential copyright violation. Before contributing, you must affirm that the following is true: I hereby swear that I have not used nor seen the source code to any version of the Windows operating system nor any Microsoft product that may be related to the proposed project that is under a license incompatible with contribution to ReactOS, including but not limited to the leaked Windows 2000 source code and the Windows Research Kernel.

What do you people make of this? Didn't think anyone would actually bother to comment, but the author of Rufus himself did. Is anyone here who uses Vista on a regular basis actually concerned of the potential security implications? At least for me, regardless of the OS I use, whether that mitigation is enabled or not, it doesn't make a difference to me, because nothing ever gets on my PC without my explicit permission. I haven't used anti-virus software in years. To me, that's snake oil that only serves to give gullible people a false sense of security and slow the computer down and being downright annoying by deleting software that I actually want to run. It even happened to me once that I was compiling a program from source and NOD32 deleted the freshly compiled .exe right away! I was compiling a freaking game engine at the time... Windows Defender is the very first thing that gets turned off after Windows install. So, since this is primarily for the few Vista fans on this forum and that I don't really like programming and only ever bother with it if something I'd like to use is horribly broken or otherwise find some inconvenience that I'm able to fix, what do you think? Would you rather have a version that's potentially more secure or is the current fine? Honestly, my Vista image dates back to 2013, so it's possible that the bug with controls losing Aero appearance doesn't even occur when on a later patch level, but knowing MS, when their product goes out of mainstream support, they don't usually do any interesting updates. I guess I could compile both versions. I personally prefer the one that looks right.

How far along it is? Very alpha, like it's always been since its early roots dating back to the nineties trying to mimick Windows 95.

I don't see Firefox 66 behaving any differently from the older versions. I'd just use modified firefox.exe with Windows 10 manifest patched out unless someone comes up with CSS hack that actually works properly.

I still get this crash with latest debug version of AG on Win10 1809. Doesn't happen when Aero Glass is not loaded. It's possible I've terminated aerohost.exe last time without also terminating dwm.exe, so DWMGlass.dll was still loaded, hence coming to conclusion that it happens regardless of AG. I get these results both in VMware and on a real PC. Crash dumps are not generated in this scenario. I don't see it crashing on 1803 virtual machine though...maybe I used the wrong snapshot when testing the last time.

I miss the x86 flavor. What's the actual reason for dropping x86 support? Just that everyone else does it? Last time I checked, x64 assembly was more complicated than x86.

Have you tried this? http://glass8.eu/out/rs5_17763_1564_x64dbg.7z It's a debug version, but supposedly fixes some crashing problems that were reported. The latest non-debug version also crashes for me occasionally, though I decided I'll just wait for the new non-debug version.

I noticed in version 1809 that they started using NDIS 6.x drivers by default (for portable devices with USB tethering feature), so no need to manually update them anymore to avoid connection stability issues due to bad backwards compatibility with NDIS 5.x specification. Also the old Windows 8 bug with DirectDraw and DWM_DX_FULLSCREEN_TRANSITION_EVENT that caused 3 second delay on transitions from/to fullscreen mode when the app's screen settings (resolution, refresh rate) matched the desktop's is gone. Didn't think this one would ever be addressed.

I've recently come across a very nasty bug in Windows 8.1, specifically in its NDIS kernel driver (ndis.sys). Basically, when using network adapters in bridged mode and copying files from a file share, non-paged pool usage keeps rising with more files copied (Task Manager->Performance tab->Memory). Reboot is the only way to reclaim that memory. I haven't seen anyone posting about this particular problem, the only known issue with similar symptoms occurs with outdated Ethernet Killer drivers. I did find this: https://answers.microsoft.com/en-us/windows/forum/all/windows-10-memory-leak/4bbdd7a6-d6e1-46ab-8ea1-c2ee60361088 And this: https://support.microsoft.com/en-us/help/4025339/windows-10-update-kb4025339 (Addressed issue with memory leaks in the nonpaged pool with the "NDnd" tag, which causes the OS to crash.) Windows Performance Toolkit confirmed that the leaks happen in ndis.sys and that the allocations have "NDnd" tag. The network adapter drivers can be ruled out since the only requirement is that the network adapters are part of the network bridge and the behavior can be consistently reproduced with different network adapters. While I can't say with 100% certainty, it's likely the Windows 10 update article I linked speaks of the resolution of the same bug. It must have appeared in Windows 8.1 and was only later fixed in Windows 10. Latest cumulative update for Windows 8.1 does not address it.

Windows 10: How to burn CDs and DVDs And if you install OpenShell, you get a replacement start menu, which presents "This PC" option right after you open it (well, actually, the very first time you try to open it, its Settings window opens). But still, the fastest way to open File Explorer is using the yellow folder icon in the taskbar (assuming it wasn't removed for any reason). Traditionally, File Explorer used to be called just Explorer in the old days. Then at one point it was renamed to File Explorer. The confusion stems from the fact that the most common way to open it is not through the shortcut that just points to the File Explorer program, but through the special shortcut (that's my own term for simplicity sake), that opens the specific location in the File Explorer. This special shortcut had different names throughout history, such as "My Computer", "Computer" and "This PC". But it always pointed to the same location where you can access all storage media connected to the computer. The only difference besides the name, they added some commonly used folders in newer Windows versions in the same place where you see all storage media. BTW, I don't know how good it is, but there's this book called Windows 10 for Dummies. Perhaps it has some useful answers.

Rufus can still be made to run on Vista without much effort. I've put the binary on GitHub.