dencorso

Sorry, I had the impression you had downloaded the file directly to the pendrive. Then again, I might just have lost part of what you said as I've been doing too many things at the same time, these days. Now, I'd say a 300-400 MiB file should be enough (let's call it big file). Copy it to and from the pendrive in both machines, while timing it. Then I'd do a "small file bunch" test: the bunch is something like 300-400 MiB of small text or pic files, of 500 kiB or less each. It'd be best if the bunch contained some 100-200 1-2 kiB files as a part of it. To do it easily, create a folder called bunch and populate it with random files (they may contain anything). Then copy the whole folder to and from the pendrive as before, while timing it. The more significant results are obtained when the total bunch size (i.e., the sum of all file sizes in it) is within 10 kiB or less of the size of the big fiile. Then we can compare the results for the big file vs. those for the bunch at each machine, to see whether the pendrive and the machines are behaving as expected (viz.: slower for the bunch, regardless of the controller and OS).

Local files are those stored in a disk internal to the machine. So, I meant "copy some given file from the internal disk to the pendrive, while timing it, then copy it back from the pendrive, to (another folder in) the internal disk"... Do it for 3 or 4 files big enough for the transfer to be timed accurately, and you'll have a meaningful test. Downloading instead of copying is not a good idea for a benchmark, because internet traffic variations affect the resulting transfer time, perhaps more than the speed of the USB connection.

Welcome to MSFN! I'm sure you're going to enjoy your stay.

With all due respect, which help didn't you get? I do think we've all been plenty helpful along the way, and all respect you and your project a lot. MDGx hasn't got himself any 9x/ME machine anymore, and yet he keeps trying to keep things up to date. He's far from gone. Tihiy and Xeno86 also remain around, although both come here less than in the past. Most others remain here, too. In my reckoning, only Petr gave up on 9x/ME for good. And he's a great loss. That said, of course I cannot prevent you from going away, if you so wish. But let me ask you: away whither? Together we've got here, and remain strong... scattered, IMO, the community will wither.

Different pendrives behave differently. Ponder over this, and you'll see why more expensive pendrives are more expensive. Moreover, small files, and downloads that come in parts are the worst case for any pendrive. Do local file full copy tests, to have more meaningful results.

UltraIso should do the job nicely. It just works (when it works, YMMV).

Of course it has AHCI! Just set Extended IDE Mode to "None" in the BIOS config, and it'll be in AHCI mode. BTW, AHCI and ACPI are totally diferent animals... SSD? RunCore Rules!

So I *was* right, after all! The problem lies in pre-Word-97 .doc files! I'm really glad you've solved it, though!

Yasuo Fuzakawa - Opening theme from the National Kid series! (I think it wasn't shown in the US, how many of you ever heard of it?). http://www.youtube.com/watch?v=iUTODdFhpf0

For PC-DOS 1.00 and 1.10 (and, I presume, for all the OEM MS-DOS 1.xx versions) there is no BPB, nor the Magic Bytes, *and* DOS uses the first byte of the first FAT (on FAT-12, BTW, the only FAT they know about) to establish what's the floppy format. This causes WinImage to be unable to open dikette images of such OSes, because WinImage relies on the existence of a BPB. When a correct BPB is artificially added to either a PC-DOS 1.00 or 1.10 bootable diskette image (and there is free space for a BPB in them), then WinImage will read them with no complaints, regardless of the existence of the Magic Bytes. This tests were performed with v. 8.5.0.8500 and 8.0.0.8000 of WinImage, so I believe it may be true, at least, for all of v. 8.x.x.x, and probably to earlier versions as well.

But, as the OP just said, not helping at all. You're free to love 7, 8 or even Windows 9 and full cloud computing. However, this is the XP forum and comments like the above have no place here.

No. In 1970 we actually didn't even have microprocessors: the 4004 is from 1971. So DOS, in 1970 would be a real wonderful blessing! DOS is from 1981, there was CP/M before it. And no, by the 80s, DOS was far from being all we had: does UNIX ring any bells?

It has nothing whatsoever to do with the DOS boxes. XP WordPad and later versions cannot open Word 2.0 .doc files. That's by design, and has no solution. But it does have a workaround. Open them in Word and save as a Word 97 or latter .doc, and WordPad will open them all right. And you can install the Word 97 compatibility pack (or whatever it was called) to Word 2.0, so that Word 2.0 will still be able to open those .docs, besides gaining the ability to save in Word 97 .doc format directly. I think the converters you need are this and this... but I've installed them so long ago that I might as well be wrong, and some other files might be needed, too, along with those I just gave you links to. As for CMD, I agree with jaclaz: it's more able than that DOS's own COMMAND.COM, not less.

@Larry123456: San Francisco is great beyond measure! And those sure were good times... Roxette - Listen to your heart.

That sure doesn't apply to Win 9x/ME. And even on NT-Family OSes do beware those multi-fix applications, which, at best fix very little and at worst will hose your system.

Thanks!

Or IrfanView.

Yes: "Problem exists between Chair and Keyboard"...

From the Wikipedia link I gave and you didn't follow...

Run regedit and look ar HKLM\SYSTEM\Select The value Default stores which ControlSet should become the CurrentControlSet, at the next boot. More info here.

The OP is in Uruguay. I guess that, like here in Brazil, the tax on money orders and on Western Union wire is constant up to a relatively high threshold, and then grows slowly for bigger amounts, so that sending small amounts of money by money orders or wire is not feasible as the tax might easily be 5 to 10 times the amount sent.

Something is really wrong here, let's see: If you have NUSB insatalled, you don't need any other drivers for using a USB 3.0 pendrive in a USB 2.0 port/controller. The drivers are for the controller and ports, not for the device itself. The numbers for the A-DATA are good, but not particularly impressive (and confirm it's working in USB 2.0 compatibility mode). read speed : 20-25 MB[color="#FF0000"]/s[/color] or above write speed : 10-13 MB[color="#FF0000"]/s[/color] or above Now, a really fast USB 2.0 pendrive, like an OCZ ATV Turbo 8GB (SLC, out of production for at least one year already) can beat that easily: Sequential Read * : 32.6 MB/s Sequential Write * : 26.5 MB/s *Test Size : 100 MB These numbers are from one test I ran in 2009, when no USB 3.0 pendrive even existed, and using NUSB as the USB 2.0 stack. You'd need a USB 3.0 add-on controller and port, and with that you might reach 133 MB/s for both sequential read and write (if card is PCI) or more (if card is PCI-e). Of course that requires a real good USB 3.0 pendrive, like the RunCore Pro IV (aka Moon Drive, SLC) or the Patriot Supersonic Magnum. Either, if plugged to a USB 2.0 port/controller should reach 35-38 MB/s for both sequential read and write, BTW.

Are your HDD's SATA or PATA?

C.C. Anderson resells RLoew's products, and he does accept PayPal. If you'd be willing to pay for it, it's the best solution, hands down, so go for it! BTW, Anderson's prices are just a little higher, because of PayPal's charges and his comission, of course.

Would this help?