dencorso

@tomasz86: As I said before, reliable [Hex] File Versions are obtained using FILEVER, findable inside this package. It runs OK on all Windows versions from 95 up. Petr was the first to report it, IIRR. @Coffee: Since you're at it, and use 7 x64, this is a good opportunity for you to test n7Epsilon's PEChecksum v. 1.4 and tell us how well does it work.

Precisely so. Win 98 will report up to about 1160 GiB max, no mater how much RAM you've got, unless you use the RAM Limitation Patch. But with 1 GiB RAM you really don't need it. the difference between what it sees and what you've got is too little. For some more info read this and this (notice that, at the high end, the memory amount reported was 2 GiB below what I actually allowed it to see, consistently). The latter seems to be the exact same finding as you've just reported, in somewhat different conditions. And it's probably due to memory set aside by the BIOS, as RLoew rightly pointed out.

Supertramp - Breakfast in America The live version from the wonderful Paris concert

@tomasz86: Just for the sake of clarity: I understand you did reproduce the problem I described in Win 2k, is that right? That means it probably has the bug throughout all the NT-family OSes, Vista and 7 included. @Coffee: OK. Point taken. So, if we stick to the simpler "Usage: WhateverProgName src dst" format, we can use a better algorithm: if PE get the PETimestamp; If hex version of src file is newer (and if PE, if PETimestamp(src) is >= PETimestamp(dst)) then copy src file to dst folder; else If hex version of src file is newer (and if PE, if PETimestamp(src) is < PETimestamp(dst)) then throw error and skip file; else If exist text version and text version of src file is newer (and if PE, if PETimestamp(src) is >= PETimestamp(dst)) then copy src file to dst folder; else If exist text version and text version of src file is newer (and if PE, if PETimestamp(src) is < PETimestamp(dst)) then throw error and skip file; else If both versions are the same and if PE, the PE timestamp of src file is newer then copy src file to dst folder; else else just skip file. This catches and points out the blorky cases that may happen as, for instance, the infamous oleaut32.dll v. 2.40.4522.0 (see post #14, above).

Queen - Somebody to Love

I think your algorithm will do fine. However I was thinking something a little more complex: Usage: WhateverProgName source1 source2 destination logplace Where: source1 and source2 are fully qualified directory names for the sources; destination is a fully qualified directory name for the resulting merge (might even be created if not existing already); logplace is a fully qualified filename for the log file (where success -- and which of the files was the one copied -- or error is logged, for each file copied). Advantage: both sources are kept intact. But this causes the following changes to your algorithm: If file is an orphan, then copy orphan to dst and log action else { If hex version of either src file is newer then copy that src file to dst folder and log action; else If text version of either src file is newer then copy that src file to dst folder and log action; else If both versions are the same and the PE timestamp of either src file is newer then copy that src file to dst folder and log action else since all tests are the same copy file from source1 and log action} with orphans being files that exist just in one of the src dirs. Now, the files may not have a text file version at all (very unusual) so an if exist test should be done for the text file version. Also the file may not be a PE, so an if PE test must be done for the PE Timestamp. As for the strange things that may happen in the text file version string, it always begins with a version number, that may be of the following formats: 1.20 4.10.1998 or the usual 7.61.3456.7654 so, by truncating and considering these 3 formats almost all problems are covered. The only one that remains can be solved by searching the already truncated string for commas and replacing them by dots, if they're found. The Adobe Flash executables are the most common example where commas are used instead of the standard dots. Also of interest: By looking at the Version object I see that now the version number may use four 32-bit words instead.

Way to go, jds!

@Coffee: FileVersionInfo.GetVersionInfo can be the begining of a solution... A quick glance at FileVersionInfo Class (System.Diagnostics) shows that: 1) The Hexadecimal File Version is FileVersionInfo.FileMajorPart & "." & FileVersionInfo.FileMinorPart & "." & FileVersionInfo.FileBuildPart & "." & FileVersionInfo.FilePrivatePart; 2) The Hexadecimal Product Version is FileVersionInfo.ProductMajorPart & "." & FileVersionInfo.ProductMinorPart & "." & FileVersionInfo.ProductBuildPart & "." & FileVersionInfo.ProductPrivatePart; 3) The Text File Version is FileVersionInfo.FileVersion; 4) The Text Product Version is FileVersionInfo.ProductVersion; 5) The Text Special Build is FileVersionInfo.SpecialBuild. The latter 3 values (the text strings) may not exist or be void. Post Win9x/ME files usually don't have a Special Build, for instance. So, the only thing not present in FileVersionInfo Class is the PE Timestamp, which can be read directly from the file, since it's at a fixed position in the PE header, when the file is a PE executable. However, using Hex and Text File Versions and PE Timestamps should be enough for most cases. If both File Versions and PE Timestamp are identical, the file accessed first could be copied, but either will do. If both File Versions are identical, the file with the highest PE Timestamp should be copied. If only one File Version differs, the highest of them should be copied. If both File Versions differ, but each file has a consistent pair of File Versions, the highest of them should be copied (this condition is tricky because it requires parsing the text File Version string). Else, throw an error and skip the pair of files: human intervention is needed to decide this pair, but others may be solved. This logic should work for most files, while letting humans tackle the most interesting ones. This is just my 5¢, of course. PS: This is what I get from my XP kernel32.dll (a PE exe): Hex File Version: 5.1.2600.5781 Text File Version: 5.1.2600.5781 (xpsp_sp3_gdr.090321-1317) and This is what I get from my XP shell.dll (a NE exe): Hex File Version: 3.10.0.103 Text File Version: 3.10 both are different, yet both are consistent.

No. Not by any means! That would be too easy... I mean that there are executables around with SAME "hex" version BUT different "text" version, *and* that also are executables around with SAME "text" version BUT different "hex" version. The different version, whichever of the two types it is, can be used to decide which is the actual newer version, but there are cases in which the actual higher version number is the older one. PE Timestamps may also be used to help sort this conundrum, in the case of Win32 executables (= PE executables). But no solution is reliable, if by that you mean works for 100% of the cases... If you follow the links here, you'll see some examples. This is a noteworthy excerpt: @tomasz86: getver is reliable under Win9x/ME but unreliable under XP (where it gives the version of the file that is in memory, when you try to find the version of any file that has the same name of a loaded dll or exe file). So take care. Filever, by contrary, never lies.

Attached is an image of a real unusual superfloppy I've created some time ago... It can be made bootable, of course. And when transferred to a physical Zip100, after running SYS.COM on it, it realy does boot OK (I did the test). Empty_FAT12_SFloppy_Zip100.7z

One caveat: both versions the hexadecimal and the text string File Version should be checked because they are not always the same... MS filever.exe v. 5.2.3754.0 returns the hex file version. But in the properties tab one has the hex displayed above, and the text one below, when one selects File Version. Among the Win XP files ole32.dll is a simple example of this fact, but ole2.dll is even better. The text File Version is part of VS_FIXEDFILEINFO, which is a member of VS_VERSION_INFO. Now, the hexadecimal File Info is itself another a member of VS_VERSION_INFO but it resides inside a VarFileInfo structure, IIRR.

You've given us almost nothing to go on. So: 1) What brand and model of mouse do you use? 2) How is it connected to the machine (USB, PS/2 or serial)? 3) What's the version of the mouse driver you're using, for each OS?

Happy birthday, cluberti! Lots of success and good health.

The IBM RAMAC...

Buy your SanDisk from a reputable seller, test it, and have it replaced if fake. Never happened to me, though. --------------------------------------------------------------- CrystalDiskMark 2.2 (C) 2007-2008 hiyohiyo Crystal Dew World : http://crystalmark.info/ --------------------------------------------------------------- 32 GB Sandisk Extreme SDHC Class 10 Card on a Transcend RDS5 CardReader (on A7V600-X with Athlon XP 3200+) Sequential Read : 20.107 MB/s Sequential Write : 19.277 MB/s Random Read 512KB : 19.806 MB/s Random Write 512KB : 1.800 MB/s Random Read 4KB : 4.030 MB/s Random Write 4KB : 0.016 MB/s Test Size : 100 MB Date : 2010/12/11 3:49:41 --------------------------------------------------------------- 16 GB Sandisk Extreme III SDHC Class 6 Card on a Transcend RDS5 CardReader (on A7V600-X with Athlon XP 3200+) Sequential Read * : 20.214 MB/s Sequential Write * : 17.303 MB/s Random Read 512KB : 20.081 MB/s Random Write 512KB : 7.995 MB/s Random Read 4KB : 4.665 MB/s Random Write 4KB : 0.102 MB/s *Test Size : 100 MB Date : 2009/08/09 11:42:43 --------------------------------------------------------------- Slow?

Great, Geej, thanks! NoReopenLastSession=1 did it all right!

Try using 67.228.40.30 to see whether it's a DNS problem.

To start dispelling your doubts, Read The Fantastic Manual: download link.

IMO, you've got yourself an intermittent hardware problem. That's not something one can troubleshoot fast... it'll take time and patience. Sorry.

This issue only happens with AVG 10 (aka AVG 2011), AFAIK, which, of course, doesn't run on Win 9x/ME. However, for those of us who multiboot, it's possible to scan the Win 9x/ME boot partition with AVG 2011 when we're running Win XP (or any other NT-family OS), and then AVG 2011 will pop the now familiar message: "D:\WINDOWS\SYSTEM\filename.ext"; "Corrupted executable file"; "Potentially dangerous object" and send the file packing to the Virus Vault. In my case, there were the 10 files it didn't like: BATMETER.DLL; CALC.EXE; HID.DLL; HIDSERV.EXE; POWRPROF.DLL; QCUT.DLL; REGEDIT.EXE; ROUTE.EXE; TWAIN_32.DLL; TWUNK_32.EXE. I was furious, at first, because there is no way to whitelist things AVG considers a "Corrupted executable file"; "Potentially dangerous object", as oposed to "Potentially Unwanted Programs (PUPs), for which AVG has a whitelist. Moreover, Jolaes is right, all those files are from 98SE2ME, but except for REGEDIT.EXE, they're plain vanilla Win ME files, straight from the Win ME installation CD, and signed by MS, so how come AVG 2011 insists they're corrupt? But the fact is AVG 2011 *is right*... well, sort of: it all depends on what one considers to be a corrupt file, and the NT-family OSes do have stricter requirements about PE headers than Win 9x/ME! For more details read this. Furthermore, if one tries to run that CALC.EXE in Win XP, it refuses to run and throws the "<Drive>:\<Path>\<File> is not a valid Win32 application." error message! So, here we have a set of files that really are corrupt when seen by Win XP, but which are OK in Win 9x/ME! Well, one solution to this issue is to downgrade these files back to their Win 98SE conterparts, which aren't detected as corrupt in any OS... But this is not an acceptable solution in my book. So I decided to find a way to keep the updated files... ... and here is it: download PE Explorer Free 30-Day Trial version from this page, install it (I did it on XP, but they say it also runs on 9x/ME...), load each one of the problem files, one at a time, and let PE Explorer create corrected versions of them. It'll fail to correct only one file, this being the special REGEDIT.EXE, modified by Tihiy (about which more later). Once you're satisfied that all other files are correct versions working as usual, you may uninstal PE Explorer, as it won't be needed anymore, and substitute the problem files by those files corrected by PE Explorer. Please notice that MDGx offers updated versions of TWAIN_32.DLL and TWUNK_32.EXE, so those two files might just be updated to their newer versions (which aren't detected as corrupt files). Now, the only remaining problem file is the special REGEDIT.EXE, which PE Explorer isn't able to correct. This one I've corrected by hand, and included here as a patch pattern. In order to use the enclosed patch pattern you need to grab the original REGEDIT.EXE v. 4.90.0.3000 from inside WIN_17.CAB from Win ME's original distribution CD, and rename it REGEDIT.ME. Then download the freeware command-line utils.zip, from KanastaCorp, grab inside it just PATCH.EXE and drop it into the \%windir%\command\ folder. Then download the attached file containing REGEDIT.PAT. Now create a temporary folder, say, C:\TEMP\PATCH and put REGEDIT.ME and REGEDIT.PAT in it. Then open a DOS box, go to C:\TEMP\PATCH and, from there run the following command: PATCH -p REGEDIT.ME REGEDIT.PAT REGEDIT.EXE A new REGEDIT.EXE will be created, and it will be v. 4.90.0.3001. This file is a modified version of Tihiy's hybrid REGEDIT.EXE, which isn't detected as a corrupt file. After you're satisfied it's working OK, it's time to substitute the version from 98SE2ME by this one PATCH.EXE has just created. HTH. BTW, the corrected CALC.EXE now runs OK under Win XP, in case you want to test it. regedit_patch_pattern.7z

Iggy Pop & Kate Pierson - Candy

Welcome, Lilian! I'm glad you joined.

Now that UHS-I is out (and being razor-edge technology are the most expensive thing possible), Class 10 cards are the way to go. Be sure you buy a Class 10 not a Class 6 or 4 (). Both Transcend and SanDisk are good enough.

Windows is no different. By contrary, it's much more complex and gives many more opportunities to filter/hide whatever one wants. That said, I don't have the faintest idea of how it's actually done, in your specific case, nor did you give enough specifics for me (or anyone, for that matter) to go on with. Then again, I bet jaclaz just gave you the software solution you were seeking. By rerouting either the sound card line or the audio from the modem to DTMF decoder you should get the number you're looking for, just the same as if you were using a BINA. Good luck!

Scorpions - Still loving you