CharlotteTheHarlot

UPDATE: Success using the latest DATs v6845 with McAfee v6 on Win9x. See above Post #40 for the first time I tried this using DATs v6346 ( has detailed instructions ). See above Post #57 when I tried it again using DATs v6511. Note that the time/dates shown for these files reflects the download and extraction, which was today. The three downloads that I found ... - 2012-09-24 ... 16:29 ... 108,306,264 ... 6845xdat.exe - 2012-09-24 ... 16:31 ... 106,425,344 ... Avvdat-6845.tar - 2012-09-24 ... 16:31 ... 114,108,032 ... Sdat6845.exe All three packages contain the same three DAT definition files ... - 2012-09-24 ... 06:40 ....... 718,817 ... Avvclean.dat - 2012-09-24 ... 06:40 ....... 487,057 ... Avvnames.dat - 2012-09-24 ... 06:40 ... 105,206,916 ... Avvscan.dat As described previously, just strip the "AVV" prefix from the default filenames and replace CLEAN.DAT, NAMES.DAT and SCAN.DAT. Note that the SCAN.DAT actually is smaller by about 20 MB this time compared to last. The McAfee scan engines contained in the SDAT package still hasn't been changed ... - 2009-07-31 ... 06:40 ..... 3,182,712 ... Mcscan32.dll - 2009-07-31 ... 06:40 ..... 4,706,936 ... Mscan64a.dll ... so I updated no other files beyond the three DATs. As before, it took a long time for McAfee to initialize and load the DATs ( likewise when I changed directories to test scan some known infected files ). But all went well and McAfee scanned files and folders successfully once again. Pretty impressive because the main executable McAfee file is VSMAIN.EXE v6.01.2000.1 is dated: 2001-11-16. Almost 11 years old. P.S. Maybe the OP should change the title to: Windows 9x/Me Security Thread for 2011-2012

Thanks for checking it out. Yeah, I'm just manually setting that Date/Time since it seems to make the most sense. I wish Mark kept an archive of the older versions ( sigh ) The moral of the story: always use ZIPs or similar for uploading files

Oh man. My poor cat is stuck to the ceiling from when I LOL'd P.S. absolutely no offense Andrea. Enjoy life and the laughs because it is far too short!

Classic! And thank you for helping me to stay on a regular monitor cleaning schedule.

Me neither. And I have looked. Here is the current list I have archived ( not counting a few special 64-bit versions, and maybe a couple of the latest which I didn't archive yet ) ... 2001-07-27 ... 08:10 ..... 176,128 ... ProcExp.exe_0510 2002-01-17 ... 05:40 ..... 180,224 ... ProcExp.exe_0523 2002-08-02 ... 10:16 ..... 192,512 ... ProcExp.exe_0525 2003-06-01 ... 10:12 ..... 217,088 ... ProcExp.exe_0603_(2003-06-01) 2003-06-06 ... 08:42 ..... 229,376 ... ProcExp.exe_0603_(2003-06-06) 2003-09-18 ... 08:31 ..... 237,568 ... ProcExp.exe_0702 2003-10-25 ... 06:07 ..... 299,008 ... ProcExp.exe_0800 2003-11-08 ... 16:44 ..... 303,104 ... ProcExp.exe_0803 2003-11-21 ... 15:18 ..... 340,023 ... ProcExp.exe_0810 2004-01-12 ... 22:45 ..... 487,479 ... ProcExp.exe_0820 2004-03-02 ... 09:53 ..... 512,055 ... ProcExp.exe_0832 2004-03-10 ... 17:25 ..... 520,247 ... ProcExp.exe_0833 2004-03-19 ... 06:17 ..... 520,247 ... ProcExp.exe_0834 2004-04-06 ... 07:23 ..... 520,247 ... ProcExp.exe_0835 2004-05-24 ... 23:05 ..... 536,631 ... ProcExp.exe_0840 2004-06-28 ... 09:06 ..... 536,631 ... ProcExp.exe_0841 2004-09-27 ... 11:13 ..... 548,919 ... ProcExp.exe_0850 2004-10-02 ... 12:42 ..... 548,919 ... ProcExp.exe_0852 2004-12-03 ... 16:01 ..... 561,207 ... ProcExp.exe_0860 2004-12-21 ... 15:06 ..... 561,207 ... ProcExp.exe_0861 2005-02-09 ... 06:25 ..... 456,208 ... ProcExp.exe_0900 2005-04-05 ... 09:26 ..... 456,208 ... ProcExp.exe_0903 2005-05-27 ... 20:34 ... 1,242,640 ... ProcExp.exe_0911 2005-06-15 ... 12:41 ... 1,242,640 ... ProcExp.exe_0912 2005-08-22 ... 13:29 ... 1,238,544 ... ProcExp.exe_0925 2012-09-22 ... 18:22 ... 1,443,392 ... ProcExp.exe_1001_misdated!_(2006-02-08) 2006-02-09 ... 13:53 ... 1,443,392 ... ProcExp.exe_1004 2006-02-22 ... 15:31 ... 1,455,680 ... ProcExp.exe_1006 2006-05-10 ... 16:28 ... 3,266,112 ... ProcExp.exe_1010 2006-05-11 ... 10:38 ... 3,266,112 ... ProcExp.exe_1011 2006-07-12 ... 12:59 ... 3,278,400 ... ProcExp.exe_1020 2006-11-01 ... 14:07 ... 3,623,736 ... ProcExp.exe_1021 2007-09-01 ... 08:16 ... 3,585,408 ... ProcExp.exe_1100 2007-09-09 ... 12:11 ... 3,589,160 ... ProcExp.exe_1101 2007-09-14 ... 13:29 ... 3,589,160 ... ProcExp.exe_1102 2007-10-25 ... 16:12 ... 3,609,640 ... ProcExp.exe_1103 2007-11-05 ... 07:54 ... 3,564,584 ... ProcExp.exe_1104 2008-02-26 ... 10:49 ... 3,654,696 ... ProcExp.exe_1110 2008-02-27 ... 13:05 ... 3,654,696 ... ProcExp.exe_1111_(Last-Win9x) 2008-04-04 ... 14:55 ... 3,522,072 ... ProcExp.exe_1112 2008-04-15 ... 08:09 ... 3,523,624 ... ProcExp.exe_1113 2008-05-28 ... 09:52 ... 3,522,600 ... ProcExp.exe_1120 2008-08-06 ... 17:27 ... 3,520,552 ... ProcExp.exe_1121 2008-11-18 ... 13:15 ... 3,549,552 ... ProcExp.exe_1130 2008-12-10 ... 14:40 ... 3,549,552 ... ProcExp.exe_1131 2009-01-09 ... 09:12 ... 3,550,064 ... ProcExp.exe_1132 2009-02-03 ... 10:32 ... 3,550,592 ... ProcExp.exe_1133 2010-03-24 ... 14:00 ... 3,925,880 ... ProcExp.exe_1200 2010-04-01 ... 11:26 ... 3,939,704 ... ProcExp.exe_1201 2010-04-12 ... 17:46 ... 3,905,400 ... ProcExp.exe_1202 2010-04-15 ... 08:01 ... 3,879,288 ... ProcExp.exe_1203 2010-06-07 ... 16:16 ... 3,887,480 ... ProcExp.exe_1204 2010-11-15 ... 11:45 ... 4,155,256 ... ProcExp.exe_1400 2010-11-22 ... 10:59 ... 4,177,272 ... ProcExp.exe_1401 2011-03-14 ... 12:52 ... 3,404,136 ... ProcExp.exe_1410 2011-05-02 ... 12:40 ... 3,412,856 ... ProcExp.exe_1411 2011-05-17 ... 12:48 ... 3,412,856 ... ProcExp.exe_1412 2011-07-07 ... 13:28 ... 4,754,224 ... ProcExp.exe_1500 2011-07-25 ... 12:40 ... 4,766,000 ... ProcExp.exe_1501 2011-08-15 ... 13:23 ... 4,768,032 ... ProcExp.exe_1502 2011-08-17 ... 11:35 ... 4,768,032 ... ProcExp.exe_1503 2011-08-31 ... 15:16 ... 4,846,880 ... ProcExp.exe_1504 2011-09-19 ... 10:36 ... 4,845,856 ... ProcExp.exe_1505 2011-12-02 ... 12:15 ... 4,755,768 ... ProcExp.exe_1510 2011-12-13 ... 15:54 ... 4,757,312 ... ProcExp.exe_1511 2012-01-10 ... 14:36 ... 4,763,456 ... ProcExp.exe_1512 2012-02-14 ... 14:10 ... 4,777,280 ... ProcExp.exe_1513 2012-06-05 ... 17:39 ... 2,674,800 ... ProcExp.exe_1520 2012-06-26 ... 13:01 ... 2,691,184 ... ProcExp.exe_1521 2012-07-11 ... 17:38 ... 2,691,192 ... ProcExp.exe_1522

Multibooter, could you try downloading this file, Process Explorer v10.01 with FlashGet and let me know if the DateTime is preserved? I've tried with a bunch of tools ( don't have FlashGet yet ) and always get today's date, so I suspect that the server doesn't co-operate by sending the necessary info for the touch. I figure if you cannot get it, then there is no way. Thanks.

Okay thanks! Interesting because that version I cannot locate anywhere. It nearly matches my 10.04, same size, but dated one day earlier. So what is the skin you got there on Win9x? Looks like a cross between Royale Noir and Metallic Shades EDIT: typo

Image discovered of retail box for Microsoft Plus!, I mean Windows 8 Pro Pack ... More Windows 8 box art revealed, "Pro Pack" spotted too ( NeoWin 2012-09-22 ) What should be a bolt-on application is Metro itself. But I digress. What is it? Recall from the official Destroying Windows blog this carefully crafted excuse from Windows Destroyer-In-Chief Sinofsky blaming the users, the 'partners' and the decoders themselves for the removal of a ubiquitous compatibility feature from Windows 8 ( ummm, does it still support serial, parallel, floppy, PS/2 and IDE out of the box, just wondering? ) ... Who didn't see this coming though? They can be remarkably consistent when it comes to charging more money for the illusion of extras. Most of the Plus! packs could have been part of the RTM distribution, and I would say should have been. But this is the first time they remove a common compatibility feature and charged for it. Coming soon, the non-operating operating system, Windows nOS with feature charges à la carte, 'Please check off the features of your system that you would like to enable: PS/2 input, Serial Ports, IDE, Parallel ... Thank you for choosing Windows nOS!" EDIT: updated image URLs, and again

On Win9x? Is there definitely a v10.01? Could you post or PM me a link because I must be missing it!

3 different interfaces, 3 clear choices. Which appeals to you? And which appeals to your child? ( Image source: Nokia ) Walking into a hypothetical store that stocks, sells and displays all three, and disregarding contracts with everything else being equal, I would have to say that I would be walking out with the Galaxy. The wife would be grabbing an iPhone no doubt, and the kids would be all over the playskool model. That pretty much sums it up as far as their highly polished appearances. And it probably reflects the gender-demographic divide as well. YMMV. Of course I would be grabbing the Android just so I could quickly change that horrific dandelion screen to something else ( where I am, they are considered weeds which are just slightly less despised than Poison Ivy ). I would rather poke my eyes out than watch another dandelion blow around. I think Apple might have missed the boat a little by not sufficiently distinguishing the appearance from their previous two models, both in iOS6 and the handset itself. Looks like they mailed it in this time. The Windows Phone is just terrible IMHO. If the yellow isn't bad enough, what were they thinking with the text color? That thing is just screaming for black text. Nokia dummies! That is the absolute epitome of horrible theme design. Does it ship with bifocals? I despise the icons also. What does everyone else think? EDIT: typo

Error 403 No hotlinking please Yep, looks like that one is broke. No matter, just download the whole RAR instead. It has everything. I just updated it with the rest of the files too. That file will stay in place unless I hear a complaint from the author.

IMHO, there are a ton of reasons to despise Windows 8 and Metro and only a couple to like it. But I do want to understand this alleged file copy dialog improvement. Considering the transfer speeds we have now, what on Earth is the reason for pausing a copy? For almost two decades we have been able to start copying something, and if it doesn't complete it's task instantly simply ALT-TAB to something else, letting it go it's merry way! As the HDD and controller and other mass storage and peripheral speeds have increased enormously, problems and complaints have all but vanished. At the very least it is a classic example of fixing something that wasn't broken in the first place, like changing a car's rims to spokes for the next model year and saying wow! what an improvement!. I'm guessing this a consequence of the retrograde ( as opposed to upgrade ) Windows 8 philosophy of reviving the thankfully long dead concept of single or dual-tasking, and the customers' are being be dragged down to same the level of revisionism, that of singing the praises of the state of the art in windows 3.x. Besides, I think the filename collision dialogs are terrible, all of them from Vista forward. They are pretty much a joke and illustrate a dialog designed by a committee of bureaucrats. All we really needed to fix the 'legacy' conflict resolution was an option for "NO TO ALL" and it would have been fine. Oh yeah, a file compare option as well. But 'pausing' a copy?!? Who ordered that? EDIT: just want to add that this alleged improvement should be quantitatively cited by those extolling it's virtues, how many times could one possibly need to pause a copy operation, if ever. This thing is exactly like the phony bootup speed improvement. After you subtract out hybrid sleep, and non-Windows hardware speed improvement from moving from BIOS to UEFI, what is the net gain? 20 seconds?

Yes, thank you! The executable in that installer in that zip is identical to 2000-12-01, of which I had no working links. Something wrong with your link, it doesn't work. It looks like an old link. This works: http://wayback.archive.org/web/*/http://xoomer.virgilio.it/gloriosus/software/programs/regcompact1.0.zip jaclaz That is a strange thing! If you click his link you get a parking page, if you copy the link ( the actual link, not the shown text ) and paste it into a new blank tab it directly downloads. They must have some script at that site that can discern between a clicked link and a pasted URL. The link from Jaclaz also works ( but also from an interim page ) and is identical to the file from I41Mar. I'll have to see if I can make it work as a direct URL in Post #2. EDIT: still getting the interim parking page even using the URL that Opera saves in the 'Downloads' tab. EDIT2: more strangely, Firefox returns: Server not found. Firefox can't find the server at xoom.virgilo.it.. Pasting the URL into a blank tab DOES work correctly, like Opera.

Over on the RegCompact for Win9x I have noted a possible bug in Process Explorer which I don't recall seeing before. Perhaps some others might try to reproduce it? You will need to also have IrfanView and RegCompact present with the former, or, the former *and* the latter already running to experience the bug. These were the result of my testing ... ; ProcExp version that never crashed ... 2005-08-22 - 13:29 ... 1,238,544 ... Procexp.exe v09.25 ; ProcExp versions that crashed at launch when both IrfanView and RegCompact were already open ... 2006-02-09 - 13:53 ... 1,443,392 ... Procexp.exe v10.04 2006-02-22 - 15:31 ... 1,455,680 ... Procexp.exe v10.06 2006-05-10 - 16:28 ... 3,266,112 ... Procexp.exe v10.10 2006-05-11 - 10:38 ... 3,266,112 ... Procexp.exe v10.11 2006-07-12 - 12:59 ... 3,278,400 ... Procexp.exe v10.20 2006-11-01 - 14:07 ... 3,623,736 ... Procexp.exe v10.21 ; ProcExp versions that crashed at launch when IrfanView was already open ... 2007-09-01 - 08:16 ... 3,585,408 ... Procexp.exe v11.00 2007-09-09 - 12:11 ... 3,589,160 ... Procexp.exe v11.01 2007-09-14 - 13:29 ... 3,589,160 ... Procexp.exe v11.02 2007-10-25 - 16:12 ... 3,609,640 ... Procexp.exe v11.03 2007-11-05 - 07:54 ... 3,564,584 ... Procexp.exe v11.04 2008-02-26 - 10:49 ... 3,654,696 ... Procexp.exe v11.10 2008-02-27 - 13:05 ... 3,654,696 ... Procexp.exe v11.11 So in other words, with just IrfanView running and then launching ProcExp v11.0 to 11.11 the bug occurs and ProcExp crashes. For ProcExp versions 10.04 to 10.21 both IrfanView and RegCompact needed to be open to cause the crash. There may be more complex combinations that cause this crash as well.

We should start calling it the Windows Tick Tock ... EDIT: updated image URL, and again

The question is about integrated video ( HD 3000 ). This is usually not user-configureable but maybe the latest drivers might have an option. Anyway, you must switch to 64-bit Windows first as MagicAndre1981 has said before you can even utilize that entire 4 GB. Then you should go and read through this Intel FAQ to find out what the Max and Min is according to the Intel driver. They show this as an example picture from the graphics driver properties ... The common belief is that the number used by HD 3000 is between 64 MB and 1.65 GB. Here is someone trying to make sense of it ... Sometimes the BIOS has a shared video RAM allocation but I believe all that does is set the maximum that the Intel graphics driver can use.

frf954, I see this question as a followup to this thread. So I know you already understand the complexities.. I am just repeating here several of the key points for others that may just be reading now. Please report back your progress! I always wanted to try this myself. ( btw, I did not yet extract and expand every WinXP cabinet. It is still on the drawing board ) There are times when COPY makes a lot more sense than MOVE. This would be one of those times And yes, as Tripredacus says, this is only easily done offline. The disk can be placed in another computer and the folder structure copied. Or the computer booted up with a CD/DVD which has its own operating system plus tools for accessing NTFS disks and do the copy from there ( a perfect job for DaRT / ERD if you have these tools ). After you are done copying you will want to keep an eye on the last accessed times of the files in the original location to see if they are used anymore. If they are, that MOVE operation would have proved destructive. If they are not, it means all is okay. You say you made a REG patch to change references to the original profile path. The normal strings in the registry are easy to locate and edit. Did you also check all the Expand_SZ strings? There also may be references inside files on disk ( INI, CFG, etc ) to the original path. ANOTHER POSSIBILITY: There may be a kludge method of duplicating uncopyable registry files. See this image I posted in this thread ... That is a snapshot of the temporary files ( copies of the registry ) on WinXP written to C:\Documents and Settings\(USER)\Local Settings\Temp by the program called RegCompact. It was just a fast experiment to see what would happen. The registry files would need to be renamed of course. But it does bring up the possibility of using something like this or maybe NTRegOpt or ERUNT to maybe be able to grab copies of those locked files while still in Windows on the computer in question. Obviously more experimentation would be required to know for sure. Also note that in that experiment I was simply using the Win9x version of RegCompact, but be aware there are versions designed for WinXP but I have never used them. Read that post for more information. But I believe the idea is sound, using a registry compaction tool which reads in and writes out this registry while in Windows and saves them temporarily before using them on the next reboot. Intercepting them before this step is the key, and it has worked successfully on Win9x.

When I first started doing the REGEDIT /c registry creation was back on Win95 or maybe the first service pack. These computers mostly had 8MB of RAM ( and when you think about it, what a miracle that was running many programs in virtual memory! ). So any reduction of the size was immediately beneficial and I think I remember noticing faster bootups when using a compacted registry. Once the computers improved massively after the switchover from SDRAM to DDR, with CPU's going over 2 GHz I seriously stopped noticing the improvements and really stopped worrying about the holes. Of course by then RegCompact came along and I eventually moved into doing it all in protected mode as described in Post #4. Depending on the speed and RAM on that laptop it is either going to be noticeable or, well never underestimate the power of the placebo effect!. Seriously, with a stopwatch marking the bootstrap on an older machine ( SDRAM and 1 GHz or less ) I would imagine the difference in booting with an old registry vs. a freshly compacted one could be measured. I think the only real interesting uses ( except for those older machines again, SDRAM, slow CPU ) are as described in Post #4, and that is obtaining a freshly compacted 'holeless' new registry in about 10 seconds flat. That is why I used all the pictures in that post, so anyone that wants to try this will know exactly how to do it. This is as opposed to simply copying the binaries ( see the BAT file ), which also only takes seconds, but duplicates them bitwise, holes and all. However, someone that may be stuck on a i486 or early Pentium could use RegCompact to their benefit since it is so simple. I have to assume that what ScanReg /OPT does is the same thing that RegCompact does ( or vice versa actually ), which I believe is simply call API functions to read in and write out the registry in one continuous operation. But the fact that it is done in DOS is the dealbreaker even with SmartDrv loaded. It is my opinion that ScanReg was a poor response to creeping registry problems on Win9x, primarily aimed at quietly restoring an archived version when the existing one could not load. That is not a fix. What was needed was a complete re-write of REGEDIT in Win98 ( or earlier ) that accommodated large registries like I suggested by doing the /C work in Windows not DOS, also maybe adding some error checking and other features. It is my belief that they found these problems insurmountable and had already planned on the fork to NT shutting down Win9x so they didn't bother which is why that last attempt ( CLASSES.DAT ) was too little too late. First off, I would doublecheck this work with WinDiff and also with FC /B both while in Windows. BTW, I also used ExamDiff ( with some tweaking to show all binary differences ). I found tens of thousands or hundreds of thousands of discrete differences between consecutively written binary DATs as shown above in Post #5 using RegCompact (but the exported data matches perfectly with just a few expected exceptions ) . I am working under the assumption that the holes in a registry ( including areas of reserved space such as @ "default value not set" ) are literally transparent placeholders, and when the registry is written out to disk, whatever was in place at that sector of the HDD remains in those 'gaps' in the registry binary. This accounts for those many 3 and 4 byte sequences that have different data in different consecutively written out registry binaries. However, there are other places I cannot account for where there is large-scale relocation of bytes. Now keep in mind I am talking about binaries saved by RegCompact, which I believe uses something like: "write 30 bytes, advance 3 bytes, write 45 bytes, advance 4 bytes ..." which we can think of as a vector operation, the gaps ( which are necessary placeholders not to be compacted ) are thus preserved. Contrast this with simply using that BAT file to copy the registry DATs a few times in a row and they will compare identically because these copies are a bitmap operation. The exported data from these very different binaries are identical, the binaries themselves can be thought of as a container containing exportable data, plus per-machine dynamic data, plus some undocumented bits. RegDat to the best of my knowledge is only comparing the exportable data in two registries ( which is exportable ), live or saved on disk. I believe he even describes this in the HLP by mentioning that the dynamic data and other such keys are ignored. Beyond that, the other undocumented areas in the registry would also be left uncompared. See my consecutive RegCompact outputs experiment which are compaction's saved only seconds apart from an unchanged registry ( and in one case changed by one byte ) as an experimental control to understand what to expect as the minimum threshold for changes between two binaries. I am quite certain that the number is quite variable from machine to machine ( from all those possible variables I mentioned ). This ties in to one issue that reared its ugly head in Win95 with PnP. Before those days, one could have a static computer with a steady state predictable environment at every single bootup because every resource was decided by the user via jumpers or shipped hard-coded and was never altered. Every session was a mirror of every other. With PnP and ESCD and later BIOS CMOS improvements that all went out the window and every session sees a non-identical environment than every other. The BIOS can reshuffle hardware resources and so can Windows, consequently there is almost never a predictable environment. This is manifested in BOOTLOGs where the order is somewhat similar but not identical. The net result is that a certain size registry might crash on this bootup, but may survive the next one particularly if one changes stuff in the BIOS ( flush ESCD was always a possible option to fix certain problems ). This could mean that 12 MB is okay on one bootup but fails another. Like I say, just make a BOOTLOG every restart, archive them all, and try to make sense of this situation by reading through them. Sometimes certain cards are enumerated and started, other times they appear to not be. Sometimes a list of fonts shows up, other times not. It could be that even the logging system is buggy and some events are simply thrown out. I am fairly certain though that that registry size number is very flexible. But heck, at least it is very simple to do these experiments on Win9x. You can easily bloat up the registry like I showed by duplicating large keys, then run RegCompact ( keep your file manager aimed at Windows\Temp ) watch the output size, if not big enough do it again. save yourself a set of SYSTEM.DATs ranging from 11MB to 11.5MB to 12MB to 12.5MB to 13MB and then manually replace them in DOS and try booting and you should be able to determine the limit of that machine. Then you could go in and try adding or removing RAM and see how much headroom is gained and really answer some important questions for the rest of the Win9x users ( but I still think the results are machine specific and not really comparable for other users ). As you can see above, when I went from SYSTEM.DAT of 12,738,592 to 15,347,744 from added bloat ( duplicated Microsoft keys ) I went from a perfectly bootable system to a BSOD with a bogus VFAT error. Nailing down the trigger size should be easily accomplished. EDIT: Foxbat, even though in this last question I know you were talking about ScanReg, by the time I started replying my mind had shifted to Windows generally and this last response is a bit off-topic. Sorry! It is a good question actually, whether ScanReg has a hard limit like 12 MB or whatever. I have no clue since I avoided the program once its purposes were known to me and easily substitutable by other methods ( I archived my own DATs, scanned my own registries, etc ).It certainly would be interesting to know why there is a hardcoded size limit to ScanReg, and if there is not, then what exactly are the conditions that causes it to fail and makes it appear to be a hard limit.

The Windows 8 holy war continues in what is really becoming a funny episode over at Fanboy Central. Now there is a side thread going on over discussing the above-mentioned editorial ... Editorial news calls quite a lot of people Idiots ( NeoWin 2012-09-18 ) ... with some discussion on whether this author, Brad Sams did in fact say we "should be shot". Even one of their other moderators is incapable of figuring this out ( he cannot see an edit in the logs apparently ). But many of the readers have pointed it out that there was a change but with no mention of the change. ( which was my point above ). It isn't until Post #57 that the author comes out and says this vague non-apology apology ... ... not very clear Brad. Where is the mention of the update in the editorial? Another brazen fanboy staffer-moderator over there, Calum, chimes in at Post #63 unhelpfully attacking one of the commenters while completely ignoring the "should be shot" controvery. Yeah, that's professional. Still looking for words from forum owner Neobond ( Steven Parker ) ... hmmm, at Post #72 he offers an image but it makes no sense to me. Later he offers some off-topic throw-away comment. ~sigh~ Steven, you really need to get up to speed on things. For starters, where is the EDIT acknowledgement? You really don't think that stuff like this just goes away, do you? Only Paul Thurrott is as much in the tank as are so many of your staff and commenters.

Update to post #3. I re-ran the DOS registry 'CREATION' process 4 more times with both 512 MB and 1 GB of RAM, once with SmartDrv and once without. Click the button in that post to see the results showing the substantially improvement using a disk cache. After I resurrect a few more computers with extreme single-core speeds I will take that registry export and do the tests again to determine the sizable effect that CPU speed and L2 cache have on DOS operations like this.

Hehe. Funny thing happening at Fanboy Central ... EDITORIAL: Calling Windows 8 the next Vista makes you look like an id*** ( NeoWin 2012-09-18 ) Written by one of their mindless staffers, Brad Sams. Full of the usual juvenile defensiveness that young fanboys reflexively spout when their toys are threatened. But that is normal fare over there really. The forum owner, Neobond ( Steven Parker ) seems to enjoy the religious jihad as it must drum up site hits. However it appears that Brad Sams crossed a generally accepted line if you dissect several of the comments. You see, the top post editorial shows NO mention of any post-publishing editing ( such as: 'this post was modified' ) but some quotes exist that do not match it. NOTE: for reference sake, at this time the post is labeled: Brad Sams 5 hours ago 175 Comments. This exact quote is currently in the top article ... In the comments we see one reference to slightly different previous wording ... Hmmmm. Way to keep it classy Brad Sams. We'll have to check back to see if that remaining quote is scrubbed or other changes slip in. The point is, Journalism and Professionalism can only survive when integrity is present, and any signs that point to unacknowledged post-edits demolishes that integrity. When this happens in a forum it causes a few side-effects, not the least of which is leaving many comments looking out of place. Sometimes the coverup becomes as bad as the crime. Are we having fun yet Steven? This is what happens when your forum is overrun with unhinged fanboys. I have to dispute this "EDITORIAL" on other grounds though, and would correct it thusly: Calling Windows 8 the next Vista is an insult to Vista. Perhaps Windows ME would be more accurate. EDIT: please note that the asterisks *** are substituted by this forum software, not me. To be able to use that link which also has asterisks, you will need to substitue iot for ***

Yeah, don't bother. It won't make a difference changing careers to help this or any other flailing sector. Rembrandt, Da Vinci, Picasso, or Dali couldn't help them out. The comments praising this logo or Microsoft's logos are a symptom of a larger problem - declining standards. It's what happens when anything moves from specialized niche market status into the wider ' wouldn't-recognize-quality-if-it-smacked-them-in-the-head ' mainstream. This occurs in every field, not just computers, communications or tech in general. It is mass consumerist, quantity over quality, stock price over customer, spreadsheet economics. And it is a devilish problem as quantity will almost always win over quality. In this particular Windows 8 thread it is all about the retarded mobile device interface invading the personal computer desktop. Some of the other numerous examples were when LCD screens ( which were gradually improving 10-5 years ago but not yet ready for prime-time) replaced CRT's practically overnight. When anything goes mass market, R&D virtually stops and the focus becomes incremental improvements and only if they don't decrease profit margins. In the case of LCD's, it has taken forever just to move to LED backlights instead of fluorescents and will take far, far longer to get to where we should have been all along with discrete RGB LED's rather than LCD filtering cells. ~sigh~ The same case can be made for digital cameras which also came online too quickly, sacrificing important R&D into sensor tech and optics in trade for the megapixel marketing race. The music industry went through a similar metamorphosis in the 1980's to 1990's when the least talented but most marketable to the lowest-common-denominator with the highest profit margin became the focus. Whether it was Michael Jackson, Madonna, or any other number of pop or rap 'stars', the ratio of them against the truly talented ( insert whatever you personally enjoy ) will be 100:1 or more. The consequence is that the 'exceptional' is always the first victim to the consumerist business model. In Windows, once could sense this with the attitude displayed by Microsoft when they were trying to salvage Vista and routinely bad-mouthed their own hugely successful WinXP, something I don't recall them doing previously to Win2k or even Win9x when WinXP was promoted in 2001. To me it was the tip-off of their internal plans to move Windows into this mass-consumerist, McDonald's hamburger category and away from the traditional NT state-of-the-art and nobody-does-it-better bragging rights. Like in all the other examples ( LCDs, Cameras, and many more ), I believe that Microsoft is cashing out their R&D investment to succumb to quantity over quality. It's the easy way. The eBay logo, and both Microsoft's corporate and Windows logo fiascos are just a few signs of a stampede race to the bottom. Or a sign that, as Jaclaz has said, 'the human race is doomed'.

I don't know about anyone else but I'm just thrilled that the world is awash in tiny mobile devices legitimizing childish l33t speak, formerly blamed on individual laziness but now rationalized as necessary thanks to tiny or nonexistent keyboards.

Doh! You're right! I completely forgot about SmartDrv, thanks for the memory jogging. I'll run that CREATION again soon. "... Just when I thought I was out, they pull me back in! ..." P.S. if you patch REGEDIT, and run it in Windows ( making it think it is in DOS ), how can it output the DAT files?

TEST RESULTS ... ( September 2012 ) Using all 7 known RegCompact binaries. Quick reminder: RegCompact processes the 'live' registry currently loaded and in-use by the system you are using. This is in contrast to 'opening' an arbitrary offline registry file from disk ( as RegDat does, recent links ). The consequence of this is that during experimentation there is no foolproof way to ensure that the 'live' registry is bitwise ( or datawise ) identical from one test to another. We can get as close to possible by scripting the various steps and by restoring a 'default' identical registry at each reboot in DOS. But there will always be several unavoidable differences between each test because of dynamic changes during the Win9x bootstrap. Fortunately there are very few of these in Win9x as it is a very tame operating system compared to everything since. METHODOLOGY: I made a default copy of SYSTEM.DAT and USER.DAT to re-use for each test iteration. This was achieved by RESTORE.BAT in DOS which re-installed the default SYSTEM.DAT and USER.DAT to C:\WINDOWS and deleted WININIT.INI if it existed. In Windows a shortcut in C:\WINDOWS\STARTM~1\PROGRAMS\STARTUP to a batch file used to launch RegCompact after waiting for a minute ( an effort to make sure all Windows PnP drivers completed to have a common starting point for all tests. This is a nearly uncontrollable variable. ) Once RegCompact prompted with it's dialog all the registry processing was done, I exported the registry, took screenshots if necessary ( already seen in above posts ), copied the new DATs, clicked 'COMPACT', copied WININIT.INI, terminated the task, rebooted and moved to the next version. For the 2nd pass I add one step to the procedure in which a REG script was imported just after rebooting. This script was designed to add a bunch of registry keys and values, then it deleted a preceding key to force creation of a registry hole. The effect of the script also has a net gain of registry size. RESULTS: As mentioned, the two new generated registry binaries were collected each time. RegDat was then used to convert them to ASCII REG files in order to do WinDiff comparisons between the default originals to each compacted registry. The primary purpose here was to make sure that the exact same data exists before and after running every version of RegCompact. Summary: What should be expected is that the binary DATs get reduced in size, while the ASCII exports remain exactly identical. And this is exactly what occurred ... ; Binaries -------- BEFORE -------- AFTER SYSTEM.DAT .... 12,738,592 ... 12,730,400 USER.DAT ....... 3,686,432 .... 3,629,088 ; ASCII ----------- BEFORE -------- AFTER SYSTEM.REG .... 15,485,408 ... 15,485,408 USER.REG ....... 5,589,653 .... 5,589,653 Here are all the sizes as saved in a spreadsheet. The RegCompact file size results were all perfectly identical. Click the button ... What ASCII differences are there? In a way this is also a test of experimental control methods ( how well did I control all the variables ). Well, The results were astonishingly similar. In fact there were a maximum of 14 bytes difference in a maximum of 8 keys for all comparisons, sometimes less. All of them are accounted for by the dynamic nature of certain Windows elements on each bootup and cannot be easily disabled ( save for one ). There were 4 bytes different found in 4 keys belonging to PnP Audio WDM drivers. There were 4 bytes different found in 1 key belonging to the Ethernet NIC ( which could have been turned off in the BIOS ). There were 4 bytes different found in 2 keys shared by both Windows and MSIE for BROWSEUI.DLL and SHDOCVW.DLL. There were 2 bytes different found in 1 keys belonging to the Explorer shell MRU. Anyone that is familiar with WinDiff'ing registries will recognize them as always different ( with possible variations on the audio drivers and the specific key numbers ). To see these always changing keys, click the button ... What about Binary differences? The above results are ASCII comparisons, however the small amount of differences seen there DO NOT represent all the changes between any two given DATs. The export of a DAT hive to ASCII only includes what REGEDIT ( or RegDat ) returns using public functions through the API. It does not export everything, even on the relatively tame Win9x ( where there are no security ACL's to worry about ). In fact, the number of differences between two successive registry DATs can be quite numerous while there is no difference at all in the exported data in ASCII text ( exceptions described above ). To illustrate this a few more tests need to be performed. Here are examples of the massive binary differences in registries that have absolutely identical data ( as seen in the ASCII text export ). Quick Test: 3 runs of RegCompact in rapid succession. Conceptually, this is a perfectly identical 'live' registry in memory processed by RegCompact mere seconds apart ( I copied the temp DATs and canceled and immediately relaunched RegCompact ) ... ;--- SYSTEM.DAT 2012-09-13 - 14:58 ... 12,730,400 Rca126.tmp 2012-09-13 - 14:58 ... 12,730,400 Rca245.tmp .... 93,592 differences! 2012-09-13 - 14:59 ... 12,730,400 Rca372.tmp ... 163,904 differences! ;--- USER.DAT 2012-09-13 - 14:58 .... 3,629,088 Rca127.tmp 2012-09-13 - 14:58 .... 3,629,088 Rca246.tmp .... 14,255 differences! 2012-09-13 - 14:59 .... 3,629,088 Rca373.tmp .... 12,768 differences! NOTE: ASCII text comparisons were identical Quick Test: 2 runs of RegCompact in rapid succession, changing 1 byte in REGEDIT in between. Conceptually, this is a nearly identical 'live' registry in memory ( 1 byte different ) processed by RegCompact mere seconds apart ( I copied the temp DATs and canceled and immediately relaunched RegCompact ) ... ;--- SYSTEM.DAT 2012-09-13 - 15:01 ... 12,730,400 Rc1015.tmp 2012-09-13 - 15:01 ... 12,730,400 Rc1176.tmp ... 164,035 differences! ;--- USER.DAT 2012-09-13 - 15:01 .... 3,629,088 Rc1016.tmp 2012-09-13 - 15:01 .... 3,629,088 Rc1177.tmp .... 12,028 differences! NOTE: ASCII text comparisons were identical EXCEPT for the 1 changed byte EXPLANATION? Well it is only my speculation but what I believe to be happening is that there are reserved empty 'cells' in the registry, and when the registry is written out as a file on disk, the pre-existing byte pattern in those HDD sectors remain undisturbed. I would guess that the function says "write out this data string of 69 bytes, now skip ahead 3 bytes, now write out 24 bytes, now skip ahead 3 bytes ...". So every time you write out the registry it is written to a new place on the HDD and the empty parts ( e.g., default value not set ) reserve their space with a placeholder showing the contents existing in that HDD sector at that moment in time it was written rather than zeroing them out. Here is a screenshot of some of the bytes, binary compared between two successive registry saves to disk ( mere seconds apart ). I believe the differences seen here are just the pre-existing bytes that existed at that location on the HDD. Click the button ... Anyway, this may explain some of the binary differences, but there are other vast changes as well, including large blocks of relocated bytes. Others probably can speculate further on this, but me, I am just chalking it up to the fact that the registry database file format remains largely undocumented. It is an interesting detail to be sure, but completely irrelevant for most purposes of Windows use. What about NT Versions of Windows? In fact there are versions of RegCompact specifically for NT in the form of '.NET' and 'Pro' releases, and they are not discussed here since I haven't tested any of them. There is also the well regarded NTRegOpt ( by Lars Hederer, the author of ERUNT ). However, these tested versions RegCompact v1.0 also support NT in the following manner as described in the README: "Any computer running Windows95, 98, Me, NT 4.0 or 2000 is supported.". So what happens if you execute it on WinXP? Well, I ran the program just to generate the temp files and then canceled it. The following screenshot shows the dialog processing the many hives of the registry and the already written temp hives in the %UserProfile%\Local Settings\Temp folder. Whether it would have successfully restarted and installed the files is anybody's guess. I'm not pursuing this question at this time. Click the button ... PECULIARITIES DEFINITE BUG :: I noticed this quirk many years ago. It is not a deal-breaker at all, the program works just fine, but it is the kind of thing that bothers perfectionists! I described it in another thread ... Since I just tested all the versions several times, I can report that this 'bug' exists in every one ( supplementing earlier testing by Foxbat ), which probably suggests that they are all post-compile edits of the same binary. Here are the WININIT.INI entries from every version. Click the button ... POSSIBLE BUG :: I just noticed this while doing all the above testing. The problem is the crashing of ProcExp upon launch when either IrfanView is already open alone or IrfanView and RegCompact are already open together ( depending upon which version of ProcExp is used ). In other words, open IrfanView and RegCompact, and now open ProcExp and it crashes. I have no time to run this one down but I can list the tested configurations that definitely crashed ProcExp. Click the button ... ORIGINALLY POSTED: 2012-09-14. Okay, that's all for now. If anyone can add anything to this please leave details in the comments. Also, if you spot any errors, typos or otherwise please let me know. Thanks! EDIT: typos