if you check more carefully in some posts we have reports about success, cpu load is prob ok but.... ----> we have also reports from the makers of this tools with they statements: Its working... Anyway.... its like... safari...
you asked where to start and i said start at page 1 i did not say it is all in the first post what i mean is read all 26 pages carefully and you'll know what is what (but you are right, you still won't know what's actually working) but you don't have to read everything there is nothing working well for 64bit and that's why there is no mention of a 64bit solution in post 1 so if you just want a solution, don't read, don't write, just refresh 1st page if there is a solution i'll add it to the first post.
i can confirm that twinui for x64 bit was working great, i did not see the watermark for like 12 hours. thank you guys
x86 had the problem with CPU usage after 3 hours, I used Process Explorer to close the GetActivationFactory Thread and the usage went all the way down again, so the return from the calling function isn't happy, like I said before woot332's method goes through all the notions but sets the text to draw to a blank string (it draws nothing but does the job). I am still waiting for the x64 to do the same thing, but as it's the exact code patch as the x86 version I think it will happen the first time the overlay is called to be drawn. So back to the drawing board, find another nop jmp to place, before the GetActivationFactory is called from Explorer.exe to stop the execution loop, so the DllUnload is able to complete it's task and not use a heap of CPU forever. Ok x64 just started two, it took me an extra 4 minutes to get the patch executed on that VM, so at exactly 3 hours all hell breaks loose on the CPU with this current patch. Back to my original thoughts - woot332 save us!!!!
Houston, we have a problem. (x64). I have a cpu monitor on my taskbar and noticed one core was consistently in use, but forgot to follow up on it. This morning I did.
The patches work to stop the watermark but at a cost to high to use them, the 3 hour CPU bug will get it up to 100% cpu on one core. So it's not worth messing with any other hack than woot332's one in the first post for x86 x64 is not patched, it merely stops a thread in explorer.exe by making a call to the patched code in twinui.dll and never gets the results returned to it, so it re-requests or checks for a valid return (loops forever), so no watermark and no CPU power left in one core!!! The only fix (for another 3 hours) is to use Process Explorer to close the dll call I mention in my post above... The other is don't patch x64 at all, just close explorer when you get the water mark and it'll be gone for 3 more hours of uninterrupted usage (time enough for a movie )
^^ To this point, I've stopped hosting the hex-edited twinui files as they'll cause more harm than good. Best option for x64 users is be patient for a properly patched twinui as per woot332's method.
The patched files both for x86 and x64 are working fine (see my signature). Got it running on my host (11 hours running) a x64 vm (10 hours running) and a x86 vm (5 hours running) and a tablet (x64) (14 hours running) all different versions of windows (enterprise, professional) this is a screenshot taken from my x64 vm machine (bigger picture = i46.tinypic.com/54d55l.png)
@UnknownRE the cpu usage is normat as should? the screenshot is too small , but im seeing 3%. Interesting
Does anyone have a theory on why the inconsistent outcomes? Why does it work fine for some, work but gets replaced for others or work but with high cpu usage for still others?