EvilAlex

Super-cool! Big thank you, since I use this theme too

I think it has: For the sake of full recreation of the glass effect.

Cool! Thanks. Global ThemeResource is really a nice addition.

Hmmm, strange then... Restarting DWM proccess had no effect. Maybe I should've restarted the entire system. UPD.: Yep, it worked.

bigmuscle, forgive me if that was asked already, but does RoundRectRadius not supposed to work with CustomThemeResource? It's buggy, but seems to work with the default theme. However, when a CustomThemeResource is used, it has no effect on window borders.

I do. MSi Gx60 (AMD-A10-4600M wh Radeon HD 7970M). (B.t.w. donated as promised.)

Important for you, me, and a cetain number of other "geeks". Doesn't make any sense for generic user: They just want "nice windows"©. Both apps do that (from their point of view), doesn't matter how we, being programmers, see them (from inside) as different. The only real difference for them: They can install and use WB on their own, and they can't "DWMGlass". Or have to use 3rd party installers, which as we all know, can create problems. So, for simple people, S.D. is your competition whether you like to see them as such or not: That's harsh reality. (If it wasn't nobody, for ex, would've mention it on that thread, but it was mentioned long before me a multitude of times.) So what's really important here, with what simple users can actually have a problem with WB's approach: Compatibility. But I'll humor you: Both my father (who doesn't even know, what a DLL is (besides it being "some important system file"©), and my grandmother (who knows not even that) had PCs with XP and Stardock's WB5 for about 5-7 years. My granny only uses simple stuff like Office and Outlook, my father uses some exotic apps for mathematical statistics, so he could've had problems... But... No! Not a single one with any relation to WB5 for, again about 7 years. Me? I'd like to stick to your solution. I'm not average user, and for me it IS important that the entire stuff is just a single DLL without(!) installer. YES, I DO SEE IT (no installer) AS A PLUS. It's free, it's lightweight, it solves the problems and NOTHING else. Activation breaks that "nothing else" sense. It creates hassle in installation and usage.I don't mind paying at all, and was going to donate upon public release (like many other people here). But activation stuff really kills the "nice" your utility has, exactly because it was gonna be "just a single non-bothering dll" I was dreaming about.

I sent my Machine code for my VM and a physical machine and got activation codes for both, I also PM'd BM and asked if it would be OK to use the final version on my sisters new Windows 8 PC but had no reply but I don't think he minds how many of our own machines or friends we install it on, I also expect this method of activation will not be final for the finished product as each machine code needs to be checked by BM before he sends you a activation code. Something tells me the entire "activation" thing won't last longer than the final release. I think it's a "safety mechanism" just like that damned message box, to keep it from leaking out to general public until BM decides it's good to go. Making this software permanently "paid-for" kinda kills the point for it's sheer existence: Not a lot of people (general public, and not PC geeks, that is) are going to want to pay for a potentially unstable software without installer, especially when there's a "neet & sweet" Stardock's solution already available for a lot of time now. Yes, those guys don't have "true glass", but they do have transparency combined with theming "in one easy solution", not to mention the whole "easy of use" thing, which this software doesn't (and isn't going to, from what we heard so far). But by being free of charge (and activation), BM's solution can escape being Stardock's competition, and be it's own thing. That's just my opinion, nothing else. This isn't meant to criticize anything, or "tell anybody how to act".

[offtopic] True. But before blaming them, there's a bigger and much more sinister picture at play. Some even call it "the death of PC". I think such loud words are way far fetched, but the tendency is here indeed, and it is very disturbing. Some wise guy wrote, "yes, you can do LESS, NOT MORE with tablets, and that's precisly why they're winning the market over". As paradoxal as it may sound, that's, unfortunaletly exactly what the average user wants: Simplicity. That's a big, nasty, depressing topic which can be discussed endlessly. Point is: Redmond f***ed up not because they caught the wind, but because they're too late for it, their solution is bloated and cumbersome, and their pushing of it into the "n.1 DESKTOP system", given it used to be their own system, is now more like a deliberate move to saw the branch on which they're seated (Or poison their own water... Doesn't matter, you've got the metaphor.), since they obviously won't win the tablet market over at they did PC all that time ago. Being late to the table, instead of making up by sticking to thier plate and filling it with such a delicios food that no one will look at the plates of others, they try to steal, silently, from the plates of others and compose something resembling a dish from these pieces. A completely losing strategy if you ask me... And of course, no one will. [/offtopic] So, cheers to the people like BigMuscle for trying to fix what can still be fixed. And yes, can't wait for the final release Glad it'll happen soon.

Okay, it makes perfect sense. Sad to hear that. About everything else: While many things seem to make sense, security context is already violated severely. An app launching DWM outside Winlogon (if it can, actually, be done) may be a nasty hole in it, yet an opened global injection key, famous to be used by malware, and a disabled BIOS setting blocking it and bootsector misuse, seems to be a much bigger evil. But anyway, you're the boss.

It is unpredictable in a general sense, yes. So I will totally agree that this method isn't realiable, and we can't count on it, even if it can be improved. But statistically, since I'm trying it in the same fashion on the same system with almost the same current load, it can be seen rather clearly that, for some specific unknown reasons, certain versions of DLL manage to load better than the others: You can try to load one, and it fails\succeeds at it's "usual ratio", then, try another, without rebooting, and again you gain expected results. Doesn't seem to be "total" random. Unfortunately, though, you are correct about the nature of these "expected results". Unreliable and unpredictable. A question about WinLogon hooking: Why do we need, theoretically, to load into it before it creates it's own resources? We don't need to reuse them, like DWM, just need to hook maybe a single function. I must be missing something. I haven't yet reverse engineered how it launches DWM, maybe this process can be repeated outside WinLogon at all, and then we don't need to bother. If we suspend WinLogon and then resume it, it won't relaunch DWM if it's already running. So basically, the idea is: Suspend WLogon, kill DWMs, launch DWM on our own in suspended mode (Launching a process in this state is doable, the root of the problem is exactly in the fact that the process needs to be launched by our app, and not by WLogon), inject it while it's "not even running" (started suspended), resume it, resume WLogon. Caveats are numerous, like I don't know if WinLogon stores it's DWM process Id's somewhere, this can be a problem, then how excatly it launches it, it's done under "funny users" like "DWM-1" or "DWM-2", for example, what the command line params are, e.t.c. Still needs research, I'm aware it can be a yet another dead end. I had the driver approach crossing my mind too, but discarded it immediately for exactly the same reasons you stated. Will Win8.1 version be "backwards compatible" with Win8? (Sounds like it can, at least theoretically, be.) If it will, then, yes, it's all a work for nothing. But if it won't, then it still has reason to continue. Yes, the Win 8.1 update is free for Win 8 users, e.t.c, but no guarantee everyone who wants DWMGlass will update. The release will go to the public at large, and thats "totally unpredictable"

I don't know what you did in RC4, but my "crazy injector" now loads it correctly in almost 90% cases (Can symbols download attempt slow the process down just enough to be the reason for success? Or is there something else new?). Tested on "vanilla" Win 8 x64, Build 9200, not activated, on VMWare Player, not connected to internet. Even in the other 10(bad)% it still works(!), but ALSO opens a console window showing some "DBGHelp" about, yep, attempt to download symbols Anyway, applause to you!!! So, it can be injected into "suspended-on-startup" (or, ALMOST at startup, I'm still figuring out how to detect it's startup reliably and, more importantly, FAST enough) DWM, rather successfully now. Suffice it to say, WMI didn't help detecting DWM startup at all, it's a sluggish as hell a method, so process polling done in a very specific way works MUCH better. This is done by suspending WinLogon (so it won't "unlogon" you, or re-launch DWM when not expected), killing "old DWM instances", and then activating "DWM waiter" (based upon the special process-polling), and then, resuming WinLogon. The DWM Waiter then catches DWM on startup and suspends it, then DWMGlass.dll is injected and DWM is resumed. Problem is, the "waiter" part is still far from perfect, as mentioned above. I actually gave a thought to what Tihiy once mentioned - hooking WinLogon itself and altering DWM launch sequence, but haven't gone that far yet.

Super! Can this still be disabled via reg-key?

Okay, I've managed to successfully replicate your DWM2DLLInjector in .NET. Restarting, or rather, waiting for the system to restart the DWM was the tricky part. You were 100% correct about that "race" metaphor, the time frame for correct injection is as short as can be. However, now I have a working code to mess with. Will see what can be done.

So, that's on their "un-feature" list too now, isn't it? Huh... Can't say I blame 'em for trying to clean their stuff out, what I think shouldn't have been done is the removal of Glass in the first place. And since they seem to be carrying plans to return the Start Button (but heard a rumor, that not the menu itself, so where will it direct you to? A Start Screen?) in 8.1, why clean-up on Glass now, and not return it too? If they say returning Start Button is due to Customer Demand, it would've been a logical move. (Yeah, right...) Thing is: A lot of people got burned by their upgrade to 8, so I think many will stick with just 8 or 7 for awhile (I'm still largely use 7), so this work may not be in vain. That is, if 8.1 won't just be forced upon like an update or a Service Pack, because MS's plans on that are kinda shady as far as I heard. People are debating whether "codename Blue" is an update, an SP, or an actual new OS. Anyway, if their plan is not to restore but to completely remove Glass, then both your project and SD's WB8 are going to have A LOT more customers, so brace yourself

Yep, my code just happened to be an almost exact replication of that example, the only major difference is that mine is written in .NET (C++\CLI) with DllImport used to invoke native functions. But, apparently, the SE_DEBUG_NAME really is required, although it does successfully obtain a DWM process handle. May also be due to CreateRemoteThread being called way too late after DWM execution. > and it is already in use by Theme service Oh, how nice of MS to use their own "nails". Not that it's something new or unexpected... Thanks a lot!!! I'll try this out and see what works.

Thanks! It actually lightens up a lot of important points. Can you specifically post a CreateRemoteThread call here? I'm not asking for a source at all, just this specific line Thing is - I actually tried this approach yesterday, because I've become actually interested in solving this issue, but that exact command failed. Does it (CRT that is) have to be called at a specific time interval, or the entire injection process (Including Alloc) should happen before it? Because everything going before CreateRemoteThread worked fine, surprisingly. If you don't mind, and if I'll have enough time, I'll try my luck with the service approach (a Service won't need Admin priv. once installed). What I think can be done is a partial emulation of "AppInit_DLLs", without actually using it. Don't know if it's possible yet - but I just have to try. If I'll have any luck I'll post my results and source. Again, that is if you don't mind. I do not intend to do anything that goes against author's wishes.

How did your "DLL2DWMInjector.exe" from v.0.6 work? It did just the thing. It DID work with Secure Boot ON. Both that AND it did NOT alert the Antivirus software. Sounds strange given what it did, but it did work. I re-read your OP here, seems like there are some problems with that approach regarding DWM creating "internal objects" of some sort, but with 0.6 it seemed to work fine. It seems I might be missing something crucial: some kind of changes made between v.0.6 and v.0.94 which render whichever code was used in "DLL2DWMInjector.exe" unusable for stated purpose anymore. But there may be a solution: A system service process can be made, which can do what the aforementioned injector did, but at the stage, when DWM hasn't finished loading it's "internal objects". Say, capture process starts at system startup and hook to DWM immediately after it is launched. I did a similar thing when I needed to run a certain script before "Terminal Services" process executed - worked perfectly. Pardon if this already had been suggested.

Sure, but I'm actually more concerned about having to disable "Secure Boot" in BIOS\UEFI (since it happened to be the real cause of the problem). No problem for me, but I'll understand if a lot of people will be scared away by this. Anything regarding "bios" and "safety" in the context of "disable" is a spooky lot for many, can't blame 'em.

BTW this also helped me. Never expected anything like this to be a reason. Disabled "secure boot" - everything works. It still requires an exception in AnitVirus soft to be made in order to successfully add registry values, but then it works. What the?... There are, of course. But thing is, AV Suites AND, as it turned out, even the UEFI (bios) itself, tend to block this key (like in my case) without regards to "worse ways". Malware being what is... Just in case, have you considered adding an exe-file launcher (akin to the one you had back in v.0.6) to the final release, for people like myself, with a little paranoid AV suites and UEFI bios-es? (Those are becoming more and more standard this days.) I must admit (although I understand why this happens), it's "a little bit strange" having to change bios settings just to be able to run a small app. It's OK while it's in "beta"\"testing" stage, but will be a major issue for release users who don't expect having to do anything like this. Thanks again for this amazing tool!

It's not paranoid, because your program intercepts keyboard data, which is very suspicious activity. It's fine if you wrote it, but if someone else wrote a program like that and put it on your computer, then they have access to everything you type, including every single password and username to go with it. If you ever buy something online, you enter your bank info, and it could intercept that. That's why government sites offer an on-screen keyboard in the website that you can optionally use if you feel that there might be a keylogger, because then it would be very easy for someone to get your SSN. So you might want to figure out a different way to get your program to work besides keylogging :-) That's way offtopic, but since you seem inclined to state the obvious (no offense intended ), I can also tell you, that for each decision, there are reasons: if I needed to write something, that didn't really require system-wide low-level access, like a game, I'd use Windows Messaging or DirectInput, obviously. No one wants their soft to be regarded "suspicious". But, here's the same deal going back to the topic at hand: DWMGlass we're discussing here uses not one, but AT LEAST two things extremely often used by Malware: DLL Injection (also called hooking), AND that aforementioned AppInit_DLLs reg value, which is actually the way a lot of "WinLock" type trojans work. They set themselves up in that value, load themselves at system start-up and hold an unsuspecting user for ransom: "Give a hacker a lot of money, or all your data is lost". And, apparently, this last quality is what (probably) causes my AV to react badly to this Win8-bad-looks-solution. So to speak about "dangerous coding decisions". But, like in the case with "returning Aero after it has been cut by Microsoft", there are situations, where "non-dangerous" approach is either impossible by design, or is way to complex, or isn't really solving the problem (like the aforementioned Stardock's WindowBlinds 8 (WB) \probably\ not having hardware acceleration). So, there are situations, where you either just trust the software author (you do trust driver vendors, don't you?) not to abuse your privacy, or don't use the software, or have to stick with less satisfying approaches. This was a case with my soft: I either had to write a full-fledged driver along with all the hassle and trouble (not to mention having user to install it), or just use a global hook, which I did. Obviously, mr. bigmuscle had to do something similar for similar reasons.

Hi, bigmuscle! First, thank you for your hard work, this thing is really amazing! Everything one needs to make Win8 look pretty without the sizes and hassle of WB. But here's a question: SOLVED. Problems were: - An Antivirus exception had to be added, because AppInit_DLLs reg key is frequently used by MalWare and anything modifying it is seen as "Trojan" or "Suspicious software" by Antivirus suites. - "Secure Boot" had to be disabled in UEFI/BIOS, because it disables AppInit_DLLs processing in Windows somehow. (My opinion is that having to do this may scare away potential release users, and this is a major psychological concern to be addressed (maybe, by including a launcher that doesn't have to use "AppInit_DLLs" key, akin to the one that was included in v.0.6.)).