dencorso

Congrats, Darth1701... you're now the thread starter! That also means you can, if you use the full edit mode, change the title to something more descriptive, if you find the one I gave the thread too terse. Let's see how this develops, but you certainly found out a quite intriguing issue, I hope we get to find a fix for.

Just to keep up to date, the situation here has remained about the same (or improved minimally, if one wants to be optmistic): What then were US$3126.50, now became US$3589.50... (about 15% real gain after two years, that's not bad you'll say!)... I'll check the new Gini Coefficient and the unemployment rate and add that info later. Also it's really worth it to give a look at the new, interactive, Big Mac Index page at The Economist's.

Moreover, 16-bit .exe, .dll, .cpl and .drv usually are NE executables, not PE executables. NE executables are totoally different animals. The best way to add resources to them is to use the MS Resource Compiler (rc.exe). To remove/edit a resource is another problem entirely. Sometimes MS VS 6.0 can do it right. Sometimes the (non-free) eXescope can do it. Sometimes nothing seems to work right. Go figure!

Sure. That's the point. The wholesale application of Wikipedia:No original research (to the point that merely calculating a median is taken to be "original research") and of Verifiability and Reliable Sources equally ferociously may doom Wikipedia in the end, but is already wreaking havok here and there, particularly in fast-moving fields like computer matters. Here is the bizarre full story of the Usage share of OSes (notice it's composed of 5 archival pages plus the current one! ) Yet, that said, the English Wikipedia seems to me to have more and better content than its counterparts in any other language I can read, perhaps because it's the one that has, by far, the most contributors, and this ensures the Darwinian survival of good content, no matter what (provided, of course, it's not nipped in the bud by Wikipedia:NOR, WP:V & WP:RS).

Well, I fear I cannot be of much help on MS' newest OSes, since my personal experience with 7 is *very* limited (read: used - here and there, mainly at work - but am not forced to use it, own one copy which I've never come around to install yet) and with 8 is actually nil. Yet the archive bit has been straightforwardly disregarded by everybody & their cousins almost since incept time (or, at least, from very early DOS times), so that it's just about obsolete, because of being unreliable, although it was a great idea, to begin with. You ARE aware that Wiki is a "user-contributed" information source (maybe NOT so trustworthy for ACCURATE information). That same Wiki does NOT state WHAT "backup software" does the "reset archive bit". I wouldn't trust that so much if I were you as there have been many a "technical article" there that have been erroneous.Yet, the same English Wikipedia, which I'm also fond of quoting, has (or, sometimes, has had) great entries on a variety op computer-related subjects, although not always, IMO, the best version is the extant (see, for instance, FAT, as opposed to the current version), due to the current predominance of a strictist view on the application of their own rules. Such a view also is conducting to the elimination a kind of entry that provided approximate facts for things about which truth cannot possibly be known (at least by scientific methods alone, afaics), as is the case of the usage share of OSes... in which a single set of numbers, generated by a rather difficult to justify median procedure, had the quality of being comparable to one another, and, with passing time, of thus providing a very welcome (even if somewhat distorted, but by non-partisan bias, afaics) view on what was happening. The current entry is much less useful, and is being considered for complete removal, which now perhaps may really be the case, unfortunately.

GetOpenFileName (ANSI version)... I wouldn't be surprised if they turn out to have done away with some ANSI functions. Try using the UNICODE version (I know it causes problems with 9xME) instead just for testing. If that turns out to work, we'll know how shallow runs backward compatibility nowadays...

So, now we actually know for sure there's an issue with VMWare 6.5 on AMD Athlon X2 (at least the "e" series Brisbanes).

Just to add my 2¢, since backups, cloning and images are mentioned in this thread. Now, you have and use Ghost. Ghost is not for free, but it's the best of its kind. So, with Ghost, and with XXCopy, you should be able to cover all your back-up needs pretty comprehensively. Great! When in doubt, this is the way to go! This kind of image (-z9 -ir) can be called a compressed "True Image" or "Dumb Image", or "Raw Image" (hence "ir" = image-mode: raw), because it makes no assumptions whasoever and, instead, just copies sector-by-sector. You can get it somewhat smaller, by zeroing-out the unused areas. And ghost can restore it to any HDD bigger or equal to the original one the image was acquired of. It's as near fool-proof as you can get and quite a good backup, but it's time-consuming. For saving and recovering the state of my system partitions, I usually do single partition images. Once you have the full true image backup optimized, do a partition backup of one of your system partitons, reformat that partition, sdelete -c that partition and restore that single partition image back to its place, and test to see whether everything is working OK. If so, that's the best way to create snapshots of a system being tuned or debugged. Repeat the test for your other system partitions and, all going well, start a library of backups for them. Before doing major experiments, always create a new image of the partition you're gonna mess with, so, no matter what you do, you remain less than 1h away from having it back as it was when you started (compared with full-disk operations, single partition operations are quite fast). It'll also most probably boot OK from a similar or bigger HDD of the same type, used to replace the physical HDD in case of hardware failure. The more similar the replacement HDD is to the one it is replacing, the more probable one gets a good result.

The only problem is that you'll find almost the same people here that are replying to you there. And, no, I'm not convinced it's a hardware problem, although you've just used one single stick, so one cannot be sure, anyway. In any case, welcome to MSFN and good luck with solving your problem.

Your thread at reboot.pro (formerly known as boot-land) has grown to 85 posts in 11 days and you're not satisfied? Haven't it occurred to you yet it's "by design" (i. e.: OSes generally don't like to boot from ro media and those which are made to boot from ro media don't expect your pendrive to be ro)? Is it possible to circunvert that limitation and succeed? Maybe. But it requires lots of experimentation and patience, on your part.

True. Then again, Win 95 fits that description, too, and VPC 2004 is free, reasonably easy to find and reputed to be 9x/ME friendly. But, in any case, the main aim here really is to test in a completely different VM. If it turn out to work well, you may decide to keep it in the AMD machines, you cannot know until you try it..

@Darth1701: What about installing VirtualPC 2004 on the AMD (or any other virtual machine provider, to have a second shot at it, without using VMWare)? I think you may have hit jackpot, when you guessed the problem lies on VMWare...

@Drugwash: May I suggest you zip and attach the flawed kexbases.dll, so that the others can test it in their environments?

All that this fix solves is the frequency issue. Your own results show it works perfectly at 3000 MHz, so the issue you're having with the AMD Athlon X2 4850e is *obviously* not related to the frequency it's running at.

To handle way much simpler tasks than calculating an MD5 hash (or even a simple PE Checksum). BTW, IMO, the only safe (& fast) way to do it is to use the Windows API directly (CreateFile then MapViewOfFile or some ImageHlp function), even from plain C or Delphi, to avoid defining a buffer (which will always end up getting overrun in real life use).

Why? MS's own FCIV (KB841290) isn't bona-fide enough?

With all due respect, of course it would: when the 8th character is a space, one patches 0x00 to 0x20. But if there are 8 characters, it's simply a question of using an incomplete 7 characters string at build time, and then patching the final 0x00, added by C++, with the right value for the 8th character.

Look and you'll find: this seems reasonable. And if you're in the US, there's also this. Of course, that's just my 2¢.

Since VxDs are not checksummed, you all could adopt a post-build patching procedure as a routine. It's not elegant, but does the job -- and can be automated (with hexalter, for instance)...

I don't think it's worth it. You probably can find an EISA IDE adapter and an old, smallish (but larger than the one that failed) working IDE HDD for almost no money at all. It might be a better solution, IMO.

Hoodoo Gurus - A Thousand Miles Away http://www.youtube.com/watch?v=Cz62Oxn8hZM

Men at Work - Down Under

Right! A post count limitation, set to at least 10 posts should solve it... way to go!

With all due respect to rainyd, if I may add my 2¢, when it's working, don't fix it! It's working already, the way you wanted it to, so...

Mcf71.dll Not Found