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

Yes/No. They are not "fictitious labels" they are a representation of the situation your hard disk is at the moment. Depending on specifically which partitioning software you used and what exactly you did with it, it may be possible to: recover the previous partitioning and volumes/data in them as if nothing happenedrecover the data only (but all the data)recover the data only (and only partial data)recover nothing The reference tool to analyze your situation is TESTDISK, that you may get here: http://www.cgsecurity.org/wiki/TestDisk Do take some time on the basic instructions: http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step then run it , making sure to create the log, DO NOT change anything and post the log for review. Besides the above, the more you remember about the previous partitioning scheme and you provide, the better. jaclaz

Sure , and still people may exist with an even deeper experience than you have , but what I do (or not do) while it may well be useless[1], it is seemingly not particularly risky, let alone substantially, or at least never caused issues to me, and since still seemingly you never attempted doing it (because it's useless) you have exactly 0 experience about the level of risk it may represent (which was actually tested by me and ended up being coincidentally also exactly 0). However, and JFYI : https://support.microsoft.com/en-us/kb/2498915 jaclaz [1] better than useless I would prefer "of limited practical benefit, particularly on modern machines and recent MS OS's", but they are just lexical nuances.

Something like this one?: http://www.cnet.com/products/acer-aspire-one-d255e-13639-10-1-atom-n455-windows-7-starter-1-gb-ram-250-gb-hdd/specs/ Which processor? Which speed? How much RAM? The basic steps to install a Windows 9x on such a kind of PC is usually to install DOS to the internal disk, copying to it also the setup files and to run the setup from the internal disk itself, like in here: http://www.nickh.org/computer/instlwin9x.html and - more loosely - as in here: http://www.windowsreinstall.com/win98/laptopinstall98stepbystep1/indexfullpage.htm#.VUkJBL0Zk_g Just use the USB stick as if it was the CD-ROM in the above, but very likely the USB stick will be C: drive and the partition on the internal hard disk will be D:, so you will have to adapt to your actual drive letter assignment, and of course this assumes that you already partitioned the hard disk (using FDISK or similar) and formatted the target filesystem. Then there may be issues anyway with too fast processor or too much RAM. And it is very possible that you will need to run the setup with a given switch: https://support.microsoft.com/en-us/kb/186111 http://thpc.info/how/switches9x.html jaclaz