jaclaz

Ideally the good MS guys could adopt the acronym (paying a fee to me for its use of course ) changing the meaning of it from the original Nameless Crappy Interface to (say): New Custom Interface <- two lies as it is not new nor custom oriented or customizable or Naturally Confusing Interface <- more correct, but maybe counterproductive or possibly Neoteric Cloud-oriented Ideal[1] and get rid of the senseless naming or misnaming.... jaclaz [1] Ideal in the perverted minds of the MS executives that pushed and push for it, Nadella's Clear Inadequacy would also come to mind...

You are welcome . The good MS guys have a long tradition of keeping previous OS specific settings without documenting them and use deceiving error messages, and on the other hand the good guys that write programs often use some settings without really knowing all the consequences (mainly because the good MS guys never documented them properly), since this behaviour appears to be a not-so-common one my bet is on some third party tool setting those keys, possibly in order to increase the security of the PC. jaclaz

Hmmm I am not so sure that this can be correlated to "efficiency", in the sense that a given hardware and OS may be more efficient through being able to do more (or more complex) operations in a given time which would lead to increased produced heat. All in all the proposed test is IMHO a nice one but maybe linking it's results to "efficiency" directly is not entirely accurate. jaclaz

@bhplt Yep, you perfectly explicited the point. Everyone of us has his/her own experience and has seen different things, you wouldn't believe what I have seen (nor what I have done ) on some machines/installs, or what some (badly coded but "necessary") programs may do to a poor, innocent, Registry hive. A machine that has been maintained by an experienced user, that has rarely installed "experimental" or alpha or beta software if not his/her own coded ones, cleverly avoided the sh*tload of crappy apps/tools, particularly adware and trialware available in the wild, has resoloved an issue as soon as possible and correctly will not obviously benefit by a defragmentation of a hive, basically because the hive is already not fragmented or not fragmented much, but I have seen - like Bizzibody reported - Hives grown out of control that would be reduced in size by 20% or more, as well but this is another thing, if you check n systems you will likely find n-1 Registries with just ControlSet001 and ControlSet002 and 1 with also ControSet003 but I have seen machine with up to ControlSet025 and more, AFAICR the record is ControlSet052, but maybe there were worst cases . Anyway the point at hand is that cleaning a Registry is different from defragmenting it, the first removes data, the second simply re-arranges them, the first, if the "wrong" program is used or it is used by the "wrong" operator, can represent a risk, often even a substantial one, the second does not, and specifically the defragmentation is carried essentially through making a backup of the hive and then replacing the backup at next boot, and processing errors (if any) will happen before the replacement takes place, so that one has always a "way back" (as long as there is an alternate boot OS). jaclaz

Well, basically that was what post #4 was about: http://www.msfn.org/board/topic/173822-what-to-use-instead-of-ntregopt/?p=1098823 maybe I should have written it more explicitly? jaclaz

JFYI, you posted a picture of the good ol' model of wagon, the new one is more like this one: (which has BTW been recalled because it was potentially dangerous for kids) http://www.davescooltoys.com/davesblog/?p=936 jaclaz

Also check the good ol' https://technet.microsoft.com/en-us/library/bb457006.aspx HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\ As often happens the setting remained through later releases, at least up to 7/Server 2008/R2 so it is entirely possible that they are in Windows 8/8.1 as well, see also: http://jon-heidenreich.blogspot.it/2013/09/malwarebytes-this-program-is-blocked-by.html 25 minutes to wipe 50 Gb seems reasonable for a 00 write, besides making cipher or sdelete working, you may also want to try fsutil, you can create a file the size of the free space, then fill it with zeroes with setzerodata: http://ss64.com/nt/fsutil.html or try powershell: http://blog.whatsupduck.net/2012/03/powershell-alternative-to-sdelete.html jaclaz

Well, the whole point about Open Source is that you can check and see for yourself. As a side note, the developing teams between Clam AV and ClamWin are as international and as cross-country as possible. jaclaz

...or maybe, just maybe, it has a setting that allows it to download the emails in background and when you actually open it the result is instantaneous because the e-mails have been already downloaded? Something similar to the setting to auto send/receive maybe? http://www.howtogeek.com/howto/17890/schedule-auto-send-receive-in-microsoft-outlook/ jaclaz

Well, where the source resides it shouldn't make difference, the increase in heat due to the friction of the 1's and 0's in the cables is a localized effect, only affecting the cables (IDE, SATA or CAT5/6) and not spreading to the CPU. My guess would be that the CPU heat is correlated to CPU usage, i.e. the more usage of the CPU you have, the more heat builds up, on modern systems with efficient cooling systems and variable speed fans (or similar technologies) there will probably be an almost exact correlation also to CPU fan speed, probably near 0.99, like (say) US spending on science, space, and technology correlates with Suicides by hanging, strangulation and suffocation http://tylervigen.com/view_correlation?id=1597 jaclaz

Apparently all it has is a number of (educated) guesses, some hearsay and nothing more: The release date will be in any among: June July August September any other monthlet's say that "exact" has another meaning... jaclaz

I would suspect using VLC. jaclaz

See here: https://support.microsoft.com/en-us/kb/301990 In theory you can solve the issue by downloading and installing the msagent.exe but really cannot say if it may apply on Windows 8.1. Since the *same* issue happened for Windows 7 and there is instead a specific "hotfix" for it: https://support.microsoft.com/en-us/kb/969168 Maybe (just maybe) this latter will work/run on Windows 8.1, but YMMGV. jaclaz

Example (to disambiguate): jonfrederick, Tripredacus, jaclaz <- Member Name Newbie, K-Mart-ian Legend, The Finder <- Member Title Member, Super Moderator, Developer <- Member Group jaclaz

EXTREMELY small, but it is not a good example/unit of measure, because not only I recklessly defragmented it, but before that I even crazily pruned it of unneeded parts. Well, it was a reported example that a condition actually requiring a defrag of the Registry may actually happen and BTW it is not related to Server 2003, but to a later version, most probably Server 2008 for the simple reason that SQL 2012 (which was the actual culprit) doesn't run on Server 2003. Other examples (or anecdotal evidence, if you prefer): http://carlwebster.com/the-curious-case-of-the-bloated-default-profile/ http://techierambles.blogspot.it/2014/12/the-system-has-reached-maximum-size.html jaclaz

Cannot say if it can help you, but the Author of UEFI_Multi is Wimb, and support for UEFI_multi is also on 911CD Forum: http://www.911cd.net/forums/index.php?showtopic=25269 (maybe it will be easier for you to become member there, or if you PM me your basic data I can create an account on 911CD for you, no prob ) Wimb is also a member here on MSFN.org, so in case any of the above is not possible you can try to contact him via PM through the MSFN board: http://www.msfn.org/board/user/132150-wimb/ jaclaz

Hmmm. Are you really sure that what the good guys had users' interests at heart? As opposed to "not predatory" or "secretly predatory"? As far back as I can go they seemed to me like always trying to do whatever they saw best for their business, and IMHO the fact that they produced something that was very widely accepted (and sold) is not necessarily due to their having "users' interests at heart", but more to having done the "right" choices (for their business) at the "right" moment. jaclaz

Well you can do the same (defragment or compact the Registry) without using 3rd party software,as in the given recommendation by the actual guys that wrote and support the OS: https://support.microsoft.com/en-us/kb/2498915 Please note how the above (that may well be nonsense nonetheless) has been published by the good MS guys "in response to emerging issues", which should mean three things: someone, somewhere, actually had performance issues that were diagnosed as being related to the Registry being overly fragmented or "bloated"the amount of these issue reports was so large as to prompt the support people to publish a KBthe proposed solution does solve the specific problem In any case I repeatedly, over the years, did what you consider a substantial risk, on countless machines and installs, when/where I thought it was needed and NEVER had any problem, this is why I consider defragmenting a Registry (generically) and defragmenting a Registry using NTREGOPT (specifically) in my experience (having actually tried it) t as inexistent risk or no risk at all. So, while in your personal experience defragmenting the Registry has never been *necessary* or *needed* there are "other people results" showing how in some cases this is actually *necessary* or *needed* and in any case, even when the defragmenting is not really or actually *necessary* or *needed* (or - as originally stated - not likely to produce in most cases a noticeable difference in speed/performance of the OS) doing it does NOT represent a "substantial risk" or a "risk" at all. And here, JFYI, is an example of "other people results": http://blogs.msdn.com/b/sqljourney/archive/2012/10/25/why-the-registry-size-can-cause-problems-with-your-sql-2012-alwayson-setup.aspx jaclaz

But ... it is free! .... JFYI I have exactly the same doubt as you have: http://www.911cd.net/forums//index.php?s=&showtopic=25787&view=findpost&p=176220 jaclaz

It seems like Noel took back the note about the "substantial risk" involved in not following exactly and to the letter his recommendations, which is good and essentially the point on which there was not a general consensus, so once removed the two truisms: and the anecdotal evidence: which is good to know, but irrelevant, what remains should be the "final statement" which boils down to just: jaclaz

http://www.hwinfo.com/download.php jaclaz

Sure . Well said. Wait a minute , are you telling me that since very few uninstallers actually remove 100% of the stupid info they wrote to the Registry, in some cases even a Registry "cleaner" or "optimizer" might be needed? You do understand how this is the opposite of not only what NoelC believes, but also of what dencorso recommends? http://www.msfn.org/board/topic/171889-is-ccleaner-safe-to-run-on-windows-7-81/ http://www.msfn.org/board/topic/171889-is-ccleaner-safe-to-run-on-windows-7-81/?p=1078866 jaclaz

OK. XP SETUP: First disk: C: Partition1 [NTFS] 61872 Mb D: Partition4 [NTFS] 40744 Mb E: Partition2 [NTFS] 323119 Mb Unpartitioned space 4294644177 Mb Unpartitioned space 323120 Mb F: Partition3 [NTFS] 51202 Mb Second disk: U: Partition1 [FAT32] 3856 Mb TESTDISK: \\.\PhysicalDrive0=500107862016 \\.\PhysicalDrive1=3965190144 \\.\C:=64877494272 \\.\D:=42723180544 \\.\E:=338814828544 \\.\F:=53689015296 \\.\G:=2564476928 \\.\H:=3960995840 Drive C: - 64 GB / 60 GiB - CHS 7887 255 63, sector size=512 Drive D: - 42 GB / 39 GiB - CHS 5194 255 63, sector size=512 Drive E: - 338 GB / 315 GiB - CHS 41191 255 63, sector size=512 Drive F: - 53 GB / 50 GiB - CHS 6527 255 63, sector size=512 Drive G: - 2564 MB / 2445 MiB - CHS 611 64 32, sector size=2048 <- this sounds like a DVD Drive H: - 3960 MB / 3777 MiB - CHS 481 255 63, sector size=512 1 * HPFS - NTFS 0 32 33 7887 178 35 126713856 2 E extended LBA 7887 178 36 13081 244 27 83445760 3 P HPFS - NTFS 13081 254 62 54273 226 57 661747712 4 P HPFS - NTFS 54274 0 1 60801 80 63 104861358 5 L HPFS - NTFS 7887 211 5 13081 244 27 83443712 Combining the info: First disk: 1 * HPFS - NTFS 0 32 33 7887 178 35 126713856x512/1024/1024=61872 Mb -> Drive C: 2 E extended LBA 7887 178 36 13081 244 27 83445760 5 L HPFS - NTFS 7887 211 5 13081 244 27 83443712x512/1024/1024=40744 Mb -> Drive D: 3 P HPFS - NTFS 13081 254 62 54273 226 57 661747712x512/1024/1024=323119 Mb -> Drive E: 4 P HPFS - NTFS 54274 0 1 60801 80 63 104861358x512/1024/1024= 51201,83 Mb -> Drive F: The partitioning has been done by "mixing liberally" two "standards", the good ol'one where partitions had to respect head/cylinder boundaries and the "new" one where values are rounded to Mb, more specifically: Volumes C:, D: and E: (including the Extended partition hosting volume D: ) have been created under VIsta or later (or with a tool respecting the "new" standard). Volume F: has been created under XP or earlier (or with a tool respecting the "old" standard). In these cases it is EXTREMELY risky to use the XP Disk Manager (or Diskpart from XP) on that disk, see here why: http://reboot.pro/topic/9897-vistawin7-versus-xp-partitioning-issue/ http://www.dcr.net/~w-clayton/Vista/DisappearingPartitions/DisappearingPartitions.htm so simply DON'T. The partitioning (crazy as it might be) is however confirmed to be "good enough" for Vista and later, XP (generically, but particularly the simplified routines included in setup) may well "choke" on it however, if - for any reason - you need to re-install XP on that disk, I personally wouldn't dare to select any partition but the C: drive, this can be due, as said, due to the area beyond the 48 bit LBA limit: https://support.microsoft.com/en-us/kb/303013 and you should make sure that your XP CD/DVD has the EnableBigLBA in SETUPREG.HIV, as to be available during setup also, but it is also possible that it is a "quirk" due to the partitioning scheme not being compliant with the "old" standard or due to a "combined effect" (new partitioning standard + areas beyond 128 Mb). jaclaz

And again they are not "fictitious" labels they are what the tool at hand "sees" the current situation. The specific XP setup may well have been not enabled for LargeLBA, if the question has now changed to: jaclaz [1] Only for the record, for this kind of checks both Disk Manager and Diskpart are not suitable tools.

Where are you going? To the movies. To see what? Quo Vadis. Which means? Where are you going? To the movies... jaclaz