CharlotteTheHarlot

VirusTotal ( 42 scanners ) is a good site. There is also Jotti ( 20 scanners ) and VirScan.org ( 37 scanners ). There is some overlap between them but it never hurts to scan twice. Relevant news: not that it is a bad thing but within the last day, Google acquires VirusTotal. Also: Google acquires VirusTotal, but will continue independent operation. EDIT: added another link

FWIW, I have used ANSI.COM - http://www.robvanderwoude.com/ansi.php#AnsiCom - to restore the ability to utilize ANSI escape sequences even in Win7. -- (COMMAND.COM was not used) Cheers and Regards I could swear that I tried the all the ( PCMag ) ANSI.COM variations on WinXP and 7 ( btw, not x64? ). Your post greatly intrigues me. We should probably take this off topic thing elsewhere. Let me know if you have another thread in mind.

In addition to those mentioned by Foxbat, in the past I successfully tested these on Win9x ( with caveats ) ... DriveSitter by Oliver Marr *** ... Link Drive Health by Helexis *** ... Link Astra32 by Sysinfo Lab ... Link All three I believe are shareware. Trying the first two (***) I noticed added startup entries from the programs rather than it simply running and then exiting. As I prefer 'tamed' portable software myself, I consider that a black mark. What would be really great is if there was an old version of EFD HD-Tune that worked on Win9x but I never saw one. That is what I call a well behaved program.

Thanks for the info! And be aware that there is no need for the reboot if you don't mind getting your hands dirty. Yes, it uses the WININIT.INI 'rename' method. The new binary files ( the registry DATs ) are temporarily in C:\WINDOWS\TEMP with names like RC1154.TMP for example. They are scheduled to be moved under the [rename] section of WININIT.INI which is executed on bootup. These files can be intercepted quite simply. When RegCompact is complete and prompts for reboot, simply kill the task to close it. Then use the info found in the newly created WININIT.INI and move the two files to somewhere else, out of Windows\Temp and then rename them according to what WININIT.INI says ( or just name the biggest one SYSTEM.DAT and the other USER.DAT ). Then you can delete WININIT.INI and you're done. No need to go all the way through the reboot unless you want to. If you were to run RegCompact again immediately it would start over again as if it were never run before. This is the way I would get a new registry without actually having to use it. Looking at my old Win9x notes I just noticed an odd convention used by RegCompact ( well, odd to me, maybe normal for the time ). I didn't log which particular REGCOMPACT.EXE file I tested, but an actual entry found in WININIT.INI was entered by one of them like so ... [rename] C:\WINDOWS\SYSTEM\..\USER.DAT=C:\WINDOWS\TEMP\RC1154.TMP C:\WINDOWS\SYSTEM\..\SYSTEM.DAT=C:\WINDOWS\TEMP\RC1153.TMP C:\WINDOWS\SYSTEM\..\SYSTEM.DAT=C:\WINDOWS\TEMP\RC1153.TMP I made a note of the fact that there is one error there ( the repeated 2nd entry ) and one odd programming convention ( the parent folder '..' dereferencing ). That repeating error I don't really care for because the [rename] operations using '=' are a MOVE ( to the best of my knowledge ). That means that the repeated command must fail since the file no longer exists by the time it is executed. The parent folder dereferencing is fine but theoretically inefficient because it says look in C: then in WINDOWS then in SYSTEM then back up one level where we just were and use the file named xxx.DAT. Anyway, I noted all of the above and rewrote it like this without the repeat and with tighter code ... [rename] C:\WINDOWS\USER.DAT=C:\WINDOWS\TEMP\RC1154.TMP C:\WINDOWS\SYSTEM.DAT=C:\WINDOWS\TEMP\RC1153.TMP It is probably good advice for users of RegCompact to always check WININIT.INI before allowing the reboot. When I get a chance to, I will try all 6 of the RegCompact programs and try to determine if they all handle WININIT.INI this way. It is possible that this is a bug that he fixed and explains all the different builds, but I am just speculating. That is by design for registry defraggers. Theoretically it is just a long continuous write to disk of the currently loaded in memory or paged out registry, so you wind up with a 'compact' ( for lack of a better word ) registry minus any holes that exist from perhaps deleting a bunch of keys or values. This is contrasted with registry 'optimizers' ( 'cleaner' or 'repair' or 'fix' or other marketing speak ) which attempt to delete and correct registry structure and/or data. For the latter type of utility I prefer only the ones that will create an output log to save ( rather than simply presenting a list of choices to check or uncheck ) so that I can later do it myself. There is a lot of risk to those utilities.

Maybe a screenshot ( that's not too small! ) would help?

I did some recent searching for working download links. These links will take you to the MSFN threads were the info is. RegDat for Win9x ( and NT/2K/XP/Vista/7 ) is here. RegCompact for Win9x is here. They are getting much harder to find these days so grab the files while you can!

Thanks. Frustratingly I learned this independently and much to my chagrin that we have the Hobson's choice or more accurately, the Morton's fork of CMD.EXE working nicely but in 2-color, or else using COMMAND.COM with all it's bugs in glorious 16-color BBS beauty. ~sigh~ ( oops, there's those tildes again). Why Microsoft just didn't port the Win9x COMMAND.COM back to WinXP+ is a mystery to me, they broke a huge amount of batch files when the Win9x fork was shut down. I never researched it but I wonder if with enough patching the Win9x version would run in NT. At least LFN would be returned along with ANSI, not to mention being able to launch Windows apps. Of course if you can just find a link to the official source code to CMD.EXE and COMMAND.COM ( both NT and Win9x ) we can fix it and then recompile the sucker ourselves.

While this is obviously just heresay (for now), it does corroborate what Microsoft has already announced about their intention to radically shorten their development cycle of the Windows OS; and some of the information in the provided links does imply a big 'update' to Windows 8. Whether this is something trivial, or something that actually reconciles the profound issues like those UI presents some Enterprise Customers -- or just cements the foreseeable future of the Windows OS in it's current dissonant state. Regardless it seems we might find out sooner, rather then later of the negative reaction to Windows 8 has had any effect on Microsoft's intentions for the OS... What I think is twofold ... Start backing up updates and everything for XP/Vista/7 from the servers. Sell MSFT.

It would be interesting to hear what he has to say. I added it to the above. It is indeed a 6th unique compile. EDIT: typo

I can answer for several of them ( NT versions ) from this computer I am on. Windows 2000 SP4 has COMMAND.COM of size 50,620 bytes and the patch works OK. Windows XP Sp0-Sp1-Sp2-Sp3 ( all have identical COMMAND.COM, but not identical to Win2k ) is also 50,620 bytes and the patch works OK. The fact that the patcher works only means that the byte string was successfully located and that two bytes were changed from 10 to 16. However this does not mean it was necessary. To determine this an experiment needs to be run. I just did a quick test with a hidden folder on WinXP SP3 and sure enough, the bug is both reproduceable and is corrected by the patch. Follow these steps ... - go to C:\Temp - create a subfolder called "Test", make this the current directory. - copy original COMMAND.COM to "Original.com" - copy patched COMMAND.COM to "Patched.com" - create a subfolder called "Visible", copy a file into it. - copy the subfolder called "Visible" to "Invisible" - Enable the Hidden attribute for the folder called "Invisible" The test structure looks like this ... C: = Temp === Test ----- Original.com ----- Patched.com ===== Visible ------- Readme.txt ===== Invisible <- Hidden Attribute set ------- Readme.txt Now from within the folder called "Test" open CMD.EXE prompt (rather than pipe the output to file I captured the CMD window to preserve the executed command string. - execute: DIR /A /S - execute: ORIGINAL.COM /c DIR /A /S - execute: PATCHED.COM /c DIR /A /S Here are the results seen using CMD.EXE ... Here are the results seen using COMMAND.COM unpatched ... Here are the results seen using COMMAND.COM patched ... NOTE-1: The unpatched COMMAND.COM does indeed fail to traverse the HIDDEN subfolder, so patching of COMMAND.COM on NT is necessary ( if you intend to ever use it ). This can be seen in the directory output capture. NOTE-2: Several quirks of COMMAND.COM are also visible. Obviously the ~tilde~ laden short file and folder names denote the 8.3 DOS file system convention. We also see that the free space on that HDD as shown by CMD.EXE is over 94 GB but it is shown by COMMAND.COM as 1023932928 bytes free which is 1,023,932,928 bytes or 1 GB. NOTE-3: It is important to remember that DOS-FIX.EXE changes the COMMAND.COM file date/time to current when patching. If you care about preserving the original date/time you will need to 'TOUCH' the file with a utility that can read it from one file and apply it to another. I did do this when I patched COMMAND.COM and this is why in those directory listings you see identical date/time for both files. To answer Jaclaz's final question, well, that disk size bug and the non-LFN awareness is a huge reason why most people like myself rarely use COMMAND.COM. I was working on some experiments to utilize a parallel batch file interpretor by assigning COMMAND.COM to .BAT and CMD.EXE to .CMD. The idea was to allow perfect reproduction of the way batch files worked on Win9x ( I thought perhaps this was a route to restore ANSI.SYS or ANSI.COM markup as used in our old BAT files ) but it was not fruitful and remains on the back burner. So my answer to "Raise you hand who has EVER used COMMAND.COM under *any* NT based system, and if yes explain how and why." is yes I have, but I have been happier without it. EDIT: wording

Another Headline from an Alternate Universe ... Microsoft Redefines ''PC'' to be ''Personalized Computing'' ( Tom's Hardware 2012-09-06 ) The comments are a hoot. They just need a bit of touch-up to fit in the forum rules here Some examples ... I totally agree with this sentiment since 'personalized computing' is exactly the opposite that they have in mind. The direction they seem to have chosen is a real gamble because almost by definition if you are a discerning computer user who wants control over everything on your system you will be choosing a Windows PC. In other words, they don't really have the stable of obedient sheep ( minus the fanboys ) that they think they have. While they sit up there in Redmond planning their grand strategy of a Microbranded walled garden of kiosks they have really failed to understand most of the user base. Backlashes can really hurt you, just ask several of the game companies and many businesses outside the strictly computer universe.

RegCompact for Win9x ... 2012 Updated Links ... Well I started looking for file links and found a reference pointing back to a post here by me in a 2008 MSFN thread of which I had forgotten about, almost exactly 4 years ago to the day. At that point I already had located 4 different compiles of RegCompact v1.0. And after today, there are now 6. Rather than bump that 4 year old thread I'll post the findings here. Recall that previously there were 4 files named REGCOMPACT.EXE all v1.0 and now I find a 5th one ( and Jaclaz a 6th one ). The newest one is dated even more recently 2001-05-28 and is still v1.0. I also found working direct links to 2 of the 4 files I had previously. Get the files while you still can ( don't ask me how they manage to scrub all these files from the internet, but somehow they manage ). Complete inventory ... -- Filename ------- Size -- Version --- MODIFIED DateTime ------------------ MD5 -------------------- CRC32 ---- Working Links? RegCompact.exe ... 73,728 ... 1.0 ... 2000-10-15 - 05:36:10 ... d6c48ea6219abd82c127cf38994e0ed7 ... 98738fc3 ... (none found ) RegCompact.exe ... 73,728 ... 1.0 ... 2000-10-18 - 01:39:30 ... 328012d5badf9833ad645d7ca9b08b37 ... 2e4d7e33 ... Regcmp1a.zip RegCompact.exe ... 73,728 ... 1.0 ... 2000-10-28 - 18:16:16 ... f5e3fbb6209a0ed15e82be0f2b1847f7 ... 00b40b76 ... Regcmp1b.zip RegCompact.exe ... 73,728 ... 1.0 ... 2000-11-18 - 19:59:26 ... 3610d8baac81a9a7f44a2a8e02c8eca1 ... 29ff541c ... RegCompact1.0.exe RegCompact.exe ... 73,728 ... 1.0 ... 2000-12-01 - 21:33:08 ... 5749eb12f8c4f4fa3f2489e62a0c1531 ... 036ee115 ... (none found) RegCompact.exe ... 73,728 ... 1.0 ... 2001-05-28 - 20:48:52 ... fa3f9649f5f5f74b7036a48bcf205d42 ... bef289d7 ... Regcompact_1.0.zip Here are all the hashes as determined by NirSoft HashMyFiles ... -- Filename ------- Size -- Version --- MODIFIED DateTime ------------------ MD5 ------------------------------------- SHA1 ---------------------- CRC32 ------------------------------- SHA-256 -------------------------------------------------------------------------------------------- SHA-512 -------------------------------------------------------------------------------------------------------------- SHA-384 -------------------------------------------- RegCompact.exe ... 73,728 ... 1.0 ... 2000-10-15 - 05:36:10 ... d6c48ea6219abd82c127cf38994e0ed7 ... eabef0b84fc357694daa2f528488f8ac1f615394 ... 98738fc3 ... 3a7860ff36209d68e6763afc500e9c62bdca2237998607fc16c03a0cd1b80169 ... 26262f1271f7ca40c8384a2397b9a2859e66978a965ea5a361d53ac33b80b788a1bfecb59dacdf866b2b41bbb6f7544f7c594bf51af48d7897373b1353a0f34a ... b82d19e5f46d4d761555f54ab4c049bb95679f8fe56ebb4be0efef2320db0495ab00292679315621629a767e49cf1327 RegCompact.exe ... 73,728 ... 1.0 ... 2000-10-18 - 01:39:30 ... 328012d5badf9833ad645d7ca9b08b37 ... ab84d5248a8795470e7c7afcaf0994d18d28c01c ... 2e4d7e33 ... acbc0fc18df3256b13d8fef7b2df2a39565c5dd065fa5d3d68db8e6480c5ca8f ... 62ce76bfca289b92ba075a5388e59f464a011194e54ab05b043a6a79f7293f2a046c8ab9a8fb0960efd4714d03613480b5636fb5c2bc892c08ffb6ccba3741b2 ... 7705722e7c527741fca51a06fd905c37c07f3ebced4e0902ba19459acb2bc773d751a0cce307c5de86b8dfc48c0c8ca4 RegCompact.exe ... 73,728 ... 1.0 ... 2000-10-28 - 18:16:16 ... f5e3fbb6209a0ed15e82be0f2b1847f7 ... 52ab8b8d344c8935e8ff13b6f05a226992008e88 ... 00b40b76 ... 650e939a133da9573ea09b800bd220fb1fe58a00aabd31a3515997aba04097e8 ... 3bdb9a9a4f143aa56334fd2bbd6deb3691f1972bc3ace1070913868e5873957d5f70c827fd111d4a3e80889f65303e5c5814f6f85d3de4a83fc2fceb2df20b4b ... eb8ff46128b2cb57d4897e73b4f14a816d5cbfdb3d142ddec02c1c813901e7ca867b08ce49e6266d0cb6f9e5334060d4 RegCompact.exe ... 73,728 ... 1.0 ... 2000-11-18 - 19:59:26 ... 3610d8baac81a9a7f44a2a8e02c8eca1 ... 592fe9a6e9ea80a7e61cbe1089fffb315c2b2b6b ... 29ff541c ... fbfe55fa3da0490aa5e0bb038fe340973e5358c5161cc815656eb221e59c3bc9 ... 12ed5445d9652bd5ed74d3515bc0152388e366e48f51ec849040ce65554c97f01f8bb74533a65a4f56f13e7d319fc0389d05f848462bea5a016cd592b00f6f39 ... 03dfe7f89e136a7513dcefe0adb39d7b1abcab7942cd577b9de4ba8d45255aa619412f4d815cc5d8c9d4e78c97495652 RegCompact.exe ... 73,728 ... 1.0 ... 2000-12-01 - 21:33:08 ... 5749eb12f8c4f4fa3f2489e62a0c1531 ... a983554b5b05650ae9e56281181d1ed6f3c281f6 ... 036ee115 ... 246d78e5b9964b7d4593076da69ced1a1cb44b0016e9272922f0a7aa80bb45ba ... 5cc9de44ed8cd847941b7e4943748ea15dd53d2af56ab7e38dad37bfbc5280e01c0ddf6f985c41cbde5b81bd1a95b3391bb607d54b08b75da7fb352cafb19611 ... fe66a3fac84b429513ceb7321d6a4a540746f595ca1cc23f2b62271b0348ca949f0793cea9f337c8317125e4021ed12a RegCompact.exe ... 73,728 ... 1.0 ... 2001-05-28 - 20:48:52 ... fa3f9649f5f5f74b7036a48bcf205d42 ... df965ebc291afe6556f423420703511b2db7574d ... bef289d7 ... ea350d5ea624ce0b7985e7db6d85eb700bf25ff1f3d90ad46ba3bd23f4e7164b ... b801b29768cad3dab3ec6e4ebe28df8d15e9e2cda6d318f71bf6ba50feef1ecef45f8ffb78aa9c0ff0f218336ce1ccdb9edab19f11673e071ba622fc5754d968 ... c2b713c9c77865bef601b602ee8f649de0521053541fd3ad926cf5af2f6fe11b3208ea36295c250de8a4f01f9ccc85a2 DETAILS: In the file resources the languages of all 6 are listed as English (Australia), all with v1.0 and a Copyright © 2000 Daniel Werner. NOTE-1: That newest 2001 distribution is UPX packed to 37,376 bytes. The results shown above are *after* unpacking naturally. NOTE-2: I forgot to mention that both regcmp1a.zip and regcmp1a.zip have an installer EXE inside them named RegCompact1.0.exe. This can be simply extracted with WinRar. The 3rd download from 2001 has no installer in it, just the UPX packed exe and doc. The RegCompact1.0.exe ( 2000-11-18 ) download is itself an SFX installer easily extracted with WinRar and inside it is the normal EXE. NOTE-3: The readme for the 2001 version is in Italian ( "Leggimi.txt" ). My Italian is rusty but it appears to be the same information as found in the README.TXT that I have from the 2000-12-01 version. Perhaps Jaclaz or someone else can verify ... ... 2000-12-01 executable with README.TXT dated 2000-11-30 ... ... 2001-05-28 executable with LEGGIMI.TXT dated 2002-08-16 ... IMPORTANT ... I HAVE NOT TESTED the last two dated 2001-05-28 and 2000-11-18 since I just got them now and have no Win9x computer available right at this moment. If anyone can test them out PLEASE report the results. I did submit the unpacked 2001 file to both Jotti and VirusTotal which is 62 scanners. All came up clean except for ClamWin which suggests: PUA.Win32.Packer.PrivateExeProte-15. I highly doubt that ClamWin results is something I would bet the farm on. I just submitted the 2000-11-18 file and it was already scanned as 'clean' by someone else earlier ( Jotti and VirusTotal ). EDIT: Added file sizes. Added a 6th file that Jaclaz found.

I am looking around for RegCompact at this time, I can see that it will take a while :-( He seems to have moved to NT editions with version 2. There is/was a .NET version and now a 'final' edition v2.6.7 here ( also only for NT ). I found his official website called Experimental Scene but it has been scrubbed of mention of the program. Wayback has an archive. I will check the SimTel mirrors and track down the Win9x versions. Notice in my previous post that they are all identical sized, so I will have to diff them to see if he only changed version strings. After doing a Win9x full install is a great time to make backups, I know I always did. It's easy to grab the DATs at every opportunity and fortunately Win9x does not lock the files from being copied at any point like NT versions do. So copying them and archiving them with a batch file is ridiculously simple and would be crazy not to. I also prefer a corresponding ASCII export to be saved simultaneously ( although RegDat or RegExport will let you do this later naturally ). Windiff'ing the exports is the best way to detect changes and create a manual rollback to fix something gone awry. "export everything with the protected mode 'regedit', then swap the 'system.dat' and 'user.dat' files with the "minimal" set. Reboot, then import all that you exported earlier using the protected mode 'regedit'. Should work, I think." ... of course keeping in mind that within Windows you can kill the registry by adding massive quantities/complexities and won't be aware until the very next reboot. One other thing about registry importing/exporting is the fact that almost the entire blueprint for a given Win9x system exists in the registry ( aside from a few stragglers in SYSTEM.INI and a few other exceptions ) which means that a complete import is almost never a good idea unless the hardware never changes in the slightest way ( even a mouse ). Many of the system keys require great care! From my personal research ... [HKEY_LOCAL_MACHINE\Config] [HKEY_LOCAL_MACHINE\Driver] [HKEY_LOCAL_MACHINE\Enum] [HKEY_LOCAL_MACHINE\Hardware] [HKEY_LOCAL_MACHINE\System] ... of which this very important one in particular ... [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd] ... is machine specific, vital and really the central nervous system and or DNA of a given Win9x computer. It's two important subkeys ... [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd\Prob\{9b4e7760-3196-11cf-97ea-00aa0034319d}] [[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Asd\Prob\{cf2524c0-29ae-11cf-97ea-00aa0034319d}] ... to the best of my knowledge are literally the closest comparison in Win9x to a DOS era CONFIG.SYS or Win3x era SYSTEM.INI sequential startup list. Entries in the first one are 'ENUMERATED' and the second one 'STARTED' in the order they literally appear in the exported registry ASCII text ( not the way they necessarily appear in the sorted REGEDIT GUI ). Remove an entry and it is gone, move them out of order ( especially things like Acpi\\*pnp0xxx entries ) and it can go FUBAR. There are many things that order dependent ( a HDD controller before a disk attached to it, any 'bus' before one of its attached devices, etc ) Consequently, these keys should never be imported unless the hardware has not changed at all. On a long running system you can export that key and glance through the sequential entries and learn the exact order everything was added to a system, right down to a mouse, or disk, USB included. For example if you added a new CD drive or USB flash drive ( or any hardware ), along with all the more generic entries elsewhere, there will be one one entry at the end of both of those keys ( sometimes only one of the keys ) which IMHO is the flag or trigger during a bootstrap to enumerate and/or start a device. Note, this information is completely from my own experimentation, I searched for authoritative sources over the years to no avail. One other note, hard drives each get an entry too, however they are so generic with many sharing the same IDE type 47 or 80 description that you cannot really determine one from the other historically in this key. Instead Win9x relies on controller and cable position ( PM PS SM SS ) to enumerate and start them. I know this is a bit off topic, I just want to repeat that dropping entire registry exports into REGEDIT is a very bad idea, even on Win9x ( which itself is very light on registry and overhead compared to WinXP ), that is of course, if you want everything working properly. You can often drop a HDD from one Win9x installation into an entirely different computer and even though every ENUM and other system key is completely different, it seems to boot and operate okay ( if by okay you mean compatibility mode! ). Point being, these keys are very important to a perfectly working system. They must be treated carefully. I have done piecemeal transplants working around these keys many times. Often I exported those specific keys, edited them against a master list of hardware, even re-arranging the enumeration and starting, and then deleted the branch, re-imported them, rebooted and continued. Such work is not for the faint of heart! But it somewhat corresponds to the DOS days of ultra-managed CONFIG.SYS and AUTOEXEC.BAT entries to get the perfect running system ( but of course the goal there was slightly different in that it was more about getting a driver to load before another to more efficiently fill up the memory space leaving maximum available RAM for applications ). Sorry about the digression, and I expect you already know of these issues, it is just for the later readers of this thread that I want to say: BE CAREFUL in here.

rloew ... Quick question. How large is the registry export for that registry with 18 MB system + ?? MB user ? Also could you mention which machine it is ( from the Day-to-day thread ) so we can know the hardware RAM, CPU, etc ?

Thanks, I am changing that sentence above in the original post ( and surname spelling, sorry ). Feel free to delete it from quoted my mistake.

Well, no, it does mention them clearly (IMHO): BUt cannot say if it delivers what it states... jaclaz I stand corrected. Happily! From what I can tell that feature ( binary DAT output ) is available in the free version, while the professional version adds networking functions. Yet another amzing find Jaclaz. EDIT: well there are several restrictions, particularly time Click the button here ...

Well, if I were a 3-year-old (or had the worldview of a 3-year-old ), there's no doubt that I would pick the phone with the garish yellow squares! --JorgeA Exactly! Okay, so Nokia was delivered the Redmond sales pitch and bought it hook, line, and sinker. You would think they would be careful at this point ( the Metro name fiasco should be worrying ). Instead, they are showing signs of being almost as clueless ... Nokia's new PureView ad is amazing, too bad it's faked ( The Verge 2012-09-05 ) Nokia apologizes for misleading Lumia PureView video ( NeoWin 2012-09-05 ) Nokia appears to have faked the Lumia 920 PureView stills, too ( NeoWin 2012-09-05 ) This was quite a feat, this discovery. It occurs to me that despite the existence of many pro-Microsoft media outlets and a fifth-column of fanboys, it really won't matter because there really *are* some journalists around That Verge article is interesting, especially if you watch the video and note how sharp eyed the person was that discovered the 'fake'. Anyway, I think it is a good thing what we're seeing now. It seems like a bit of a sea-change really. 'We're not just gonna take your word for it anymore." I hope and expect them to keep all their feet to the fire. Microsoft with the ginned up sales figures and other deceptions, the rotten Apple patent litigations, Google with censorship (China) and privacy, etc. No more free rides. We are watching you. Ballmer is very optimistic ... Ballmer predicts 400 million Windows 8/Phone 8 devices in a year ( NeoWin 2012-09-05 ) And talk about laughs ... Symantec: Norton software makes Windows 8 run faster ( NeoWin 2012-09-05 ) Normally I might call some of these Headlines from an Alternate Universe, but then I look around.

This program is just a reduced version of RegDat, a subset really, only consisting of the text export function to REG file, without the other bells and whistles, and the registration. Still, a definite must have! Most likely, 'exporting' ( the ASCII output of the registry on a successfully booted computer ) will always work okay. I probably wasn't clear but what I meant was binary output from a registry tool that saves to a Win9x DAT on disk ( or a no-extension NT hive ) that is perfectly usable at a later bootstrap. Export is done while in protected-mode so by definition the registry was successfully read and loaded. At this point REGEDIT only has to write out the database. If you were to overload the registry with REG files, you could also export it out to a file. It's that next reboot which is scary. My understanding is that there are two major but separate registry problems in the Win9x family ... CREATION ... This occurs in DOS when the real-mode part of REGEDIT using /c cannot create one of the DAT files It is trying to rebuild a new registry ( output binary ) from a previously successful export ( input ASCII ). I discovered this way back in Win95 before the OSR updates corrected it ( temporarily ), when certain software moved all of its settings from private files into the registry and doubled the size. It was cat and mouse for the next few years but eventually even for Win98se large exports couldn't be /c created. Before WinME, the patching and backporting of a later REGEDIT version ( e.g., from 95osr to 95 ) allowed successful creation, but we ran out of luck when WinME changed REGEDIT ( it separated CLASSES out of the SYSTEM hive as a last ditch effort to make it manageable ). The reasons for this CREATION bug seem to be registry size, complexity, available RAM, ( and possibly CPU model, speed and cache ) so it is a chaotic and unpredictable problem, and pretty much unsolvable. Remember, this is the 16-bit universe and even before WinME Microsoft was already breaking things and leaving them broken. Microsoft could have fixed this in the 32-bit portion instead, but I am guessing that they did not want to give REGEDIT an option to output binary DATs to an arbitrary selected folder which would be necessary since it cannot overwrite the current in-use registry files. A 32-bit registry tool that can do this ( output binary DATs to an arbitrary selected folder ) would be very desirable for Win9x, hence my previous comment. LOADING ... BSOD protection error preventing successful bootstrap because one of the DATs cannot be successfully read or loaded. I had long thought that this was for all the same reasons, registry size, complexity, available RAM, etc, but here on MSFN RLoew has also discovered a connection to networking in some way. Consequently, a surprised and unprepared Win9x user is screwed at this point. However a well-prepared user has saved many DAT backups and thankfully in Win9x it is simple to change registries in F8 DOS command line. It is very possible while in Windows to absolutely overload the registry with imports ( or just install every SDK ) and it will appear fine as it fits within the protected-mode available memory space, but then it BSOD's on reboot. With great perseverance a person could manage this situation with lots of REG files used when in Windows and have REG 'deleters' to remove them before restart, and/or have fallback DATs ready to be copied in F8 DOS. Interestingly enough, one program that I never saw choke on a large registry was RegCompact by Daniel Werner, a 32-bit protected mode app which near as I can tell reads the currently loaded registry in memory and writes it out sequentially, removes any fragmentation 'holes'. It uses WININIT.INI to do this by outputting the DATs as C:\WINDOWS\TEMP\RCxxxx.TMP that are swapped in on next reboot. In my experience it was always successful in this 'defragmentation, and, on the following reboot I don't recall any problems either. But if you stop and think about there shouldn't be any problems because what you are loading in these new' DATs is just a likely smaller, and purified version of the previous working registry. Theoretically it should become problematic when you start pumping in REG files just before you RegCompact. The way I managed things on Win98se after the WinME registry change forked it up ... Boot Win9x normally without BSOD Backup DATs ( 'A' ) Import the required REG data in REGEDIT Backup DATs ( 'B' ) Run RegCompact Copy the newly created DATs cited in WININIT.INI, rename to DATs ( 'C' ) Now I have three sets of registry DATs, A, B, C Then I would try booting C having A to fall back on. Note that B was saved just for informational purposes, because C is a purified and smaller version of B. If this concept is understandable and makes sense, then you should be able to do this successfully. Just remember that A, B, C represent three points along the timeline. I never did have a problem here but I never did push it for experimentation's sake. In other words I never imported huge amounts just to learn the limits of that specific computer ( once again assuming the BSOD is related to registry size, complexity, available RAM, Networking, CPU model/speed/cache, etc ). Last registry size that I used on Win98se ... SYSTEM.DAT ..... 12,873,760 USER.DAT ........ 3,665,952 ASCII Export ... 21,261,267 I just want to repeat - that registry was highly managed. I didn't just throw stuff into REG files to experiment and explore the outer limits! What I imported was highly error checked and optimized ( some might say obsessively ) , paths shortened, ~SFN~ removed, font and other paths, etc. And I had a habit of deleting large chunks of unnecessary information ( Shared DLLs, Windows setup info, etc ). If I had left that all in plus all the MSI installer garbage with the absolutely insane amounts of entries ( for every single file found in every SDK ), I bet that registry export might be be closer to 50 MB. The point is, those sizes shown DO NOT REPRESENT any kind of upper limits. Please, don't anyone assume those numbers should be used as guidelines! NOTE: for RegCompact, there are four different versions that I have seen ... 73,728 ... 10-15-00 ... 4:36a ... Regcompact.exe_(2000-10-15) 73,728 ... 10-18-00 .. 12:39a ... Regcompact.exe_(2000-10-18) 73,728 ... 10-28-00 ... 5:16p ... Regcompact.exe_(2000-10-28) 73,728 ... 12-01-00 ... 8:33p ... Regcompact.exe_(2000-12-01) ... using this Can't say I ever saw it before. The only problem is it doesn't clearly mention the output of binary hives. Will have to check it out ... Someday. EDIT: wording, spelling, mistakes

Yeah, this is an old problem with COMMAND.COM. I just downloaded the above linked file for DOS-FIX and can confirm this is identical to the last and only version that I have from this author, John Augustine, dated 1999-05-12, version 1.1. It is a smart patcher, that sniffs for the necessary byte string in COMMAND.COM and patches them as necessary, just two bytes in total. The two (non-consecutive) bytes each get changed from hex 10 to hex 16. I did some research on this sometime after WinXP SP2 came out to see if it was still needed. What I found out is that every version of COMMAND.COM from around DOS 5.0 ( Microsoft MS-DOS and IBM PC-DOS ) up until that very day ( Windows XP SP2 ) required this patch. ( NOTE: I just now checked Windows XP SP3 and found that the file wasn't updated from SP2.) I never did get around to checking the COMMAND.COM that comes with 32-bit versions of Vista/7 but I will bet they also require it. So I believe it is safe to say that every version of COMMAND.COM from around DOS 5.0 ( Microsoft MS-DOS and IBM PC-DOS ) up until the present day requires this patch. Here is the DOC file from the DOS-FIX v1.1 distribution ... EDIT: as Jaclaz rightly points out below, this DIR display bug that skips certain hidden directories is part of COMMAND.COM, the command interpretor for DOS. It has nothing to do with CMD.EXE which is the NT counterpart.

Two brand new WP8 announcements ... Nokia unveils the Lumia 820 ( NeoWin 2012-08-05 ) Nokia unveils the Lumia 920 ( NeoWin 2012-08-05 ) UPDATE: I added their photos to the previous smartphone comparison photos from upthread. The new WP8 photos were copied from the above two links, pasted into the originals very carefully ( I promise ) to make it as fair as possible. Here they all are ... Just asking, what does everybody think their chances are in this market? Is this gonna do it? Apple announcements are in the queue and I bet Samsung is going to revamp their 'droids as well.

Make sure everyone grabs the two versions from the link posted above before they disappear. The HLP files are an important read and are vital to understand its capabilities. ... Download Links The final known version is ( for NT ) is 4.3. I have just started looking at it myself and realized there is a lot to this program now. I have noticed it has several new functions, including the possibility of creating new hives. He also appears to have ironed out the security ACL's allowing direct editing AND saving. Unfortunately we will need to find the author, Henry Ulbrich, in order to get the thing registered to enable all the functions! Anyway, this little tidbit jumps out of the HLP for v4.3 for NT based ( WinNT4/W2Kx/XP/Vista/W7 ) registry files: The Win9x version does not have any binary output that I can see which is a shame because this would solve many of the problems mentioned in this thread.

I know we're both getting old brother. So we gotta find some way to stop aging because these young'ins are sure messin' things up! To be sure, I meant the average, fickle, commodity consuming public which is what, 90% of the phone market? ( I would say the number is far less for desktops and laptops but gradually increases inversely proportional to screen size ). As the cost and features of plans get more similar and other variables like signal coverage become ubiquitous ( well I don't know about your town but around these parts there are few dead zones left ) and cost of the phone ( subsidized ), and functions like an app store or notifications or pinching and everything else converges, all that's left for the average consumer to decide about is the final visual appearance. When they see them side by side I very much anticipate most of them to be unimpressed with the WP immediately, but perhaps they'll ask the salesman: 'can I change this to look like that?' ( pointing at the snazzy wallpaper on an Android or raindrops on an iPhone ) and they'll balk when he stutters: 'ummm, well, we *can* change that little bit of wallpaper you see behind those giant rectangles, but ...'. If I were a Microsoft board member I would be worried now. It seems as if they set their grand plan in motion without ever sitting down and comparing the final product visual appeal with the other two players like in those photos above. How could that happen! Well, somehow they did it with the Metro name thing so I guess it is no surprise. The thing I mentioned about a gathering of phones was triggered by an actual event I was at recently. There were at least 100 people and probably 75 phones ( no WP's that I noticed ). At times when most were sitting at tables you could see all the phones in operation and as I walked around I was imagining if 1/3 had been WP's that *they* would have been the most uniform and conservative and boring since almost everyone else's was already customized with fancy wallpaper or baby or wedding pictures. Many times people were checking out each others phones, usually drawn by the main picture, something unlikely for WP's I think. And few if any of them were computer geeks, trust me, as I got roped into a pile of stupid jobs ("I got this problem on my home computer, it says the FBI wants me to ..."). This reminds me of a seldom mentioned but one of the worst features of Metro, and that is the paradigm of the start screen announcing the presence every software you own and use right within easy eavesdropping ( eyesdropping ? ) range of view so that a 'spy' doesn't even have to squint to know your business. On a phone I imagine this to be more difficult than larger computers but they do get to see your inbox email count or facebook and twitter notifications and other things at a glance. However on laptops and desktops this is terrible. People will begin to really miss the 'soft security' provided by subfolders and sub-flyouts in the Start Menu where only you know how to find your 'stuff', and can do it so quickly and easily that someone standing right next to you still won't be able to figure out what you did. The Microsoft fanboys and the actual softies that discuss this in the forums always describe this as a benefit: 'no more digging for programs, they're all right there on the start screen', but as usual they have it bass ackwards. On a phone ( like using an ATM ) you will soon develop a spy-blocking hand-shielding skillset, but on larger screens this will be a completely new problem leaving us wishing for the older, inferior LCD's with narrow viewing angles that forced you to have your head placed squarely in front of it. Anyway back to what I was saying, people like us are obviously far more discerning, no doubt about it, and would go for substance over style. But once again, WP, or more specifically Windows offers nothing in this form factor. I'll probably wind up with a Windows 8 tablet or Surface eventually, and at that size it just might work out okay, but I guarantee that if it's at all possible I will have a real keyboard and mouse hooked up eventually ( just for some twisted satisfaction because I can ) after I get tired of cleaning the screen and making mistakes on the toy keyboard. I just don't see it getting past a few years ( the Surface ), like a fad. At the phone form factor I *can* see it surviving, and actually do hope it does because that would be great competition for the other two. But Microsoft will have to do better than Metro, honestly. I'm talking about major customization putting some real zing into it, the opposite that they seem to have as a plan. If they are so intent on branding lock-in I dare them to get the manufacturers to make the ringtone non-customizeable permanently set to whatever jingle their brilliant marketeers decide.. Of course they won't because they know full well there is a limit where the people will kiss them goodbye. However they certainly have advanced the limitations this time more than ever before. Here is where I once again offer to help Microsoft for free, waiving copyright and compensation! The Windows Phone should jump out in a visual comparison. If I was designing it, besides the obvious like ringtone, wallpaper and screensaver selection, every single parameter for the 'tiles' would be tweakable: size, shape, image, icon, spacing, color, textures, gradients, brightness, contrast, etc. Within the actual tiles themselves all parameters would be adjustable: layout, padding, margin, font, color, justification, etc. I would allow selection of scroll direction, speed, and introduce user selectable visual effects commonly found in every DV editing suite and transition effects found in every slideshow creator. *That* would have been groundbreaking for the current phone market and all it really involves are the traditional Windows features plus simple HTML and CSS styling. In other words, Microsoft could have accomplished this without even breaking a sweat. EDIT: had to snip your quote Jaclaz, we hit the smiley limit this time.

I thought Minority Report was pretty well done and the computer scenes will probably stand up longer than many other movies. Personally I've always had a soft spot for the Start Trek TNG interface called LCARS as they somehow nailed down the LCD look long before anyone actually had one ( it was 1987! ). Windows was still in its first version and Windows 2.0 came out a short while later. The many home-made LCARS Windows themes are pretty good too and there are a surprising amount of LCARS GUI applications around. Not everybody likes it to be sure but one thing is for certain, they were way more consistent throughout the show than Microsoft has been with Windows 8. More LCARS from ST:TNG ... EDIT: updated image URLS, and again

double height taskbar too.

There is no good reason to pick one exclusively and it makes sense to have all of them installed and available. Too many times you need more than one and very often one works while another will not ( often due to 'programmers' that insist on browser sniffing rather than writing neutral code ). They exist just fine together and can all work simultaneously. In order of personal preference I use them like they appear here left to right ... Although lately, MSIE is getting more use than Chrome since it is becoming less useful and more dumbed down IMHO ( and should maybe be renamed 'Chromeless' now ).