That's a bit steriotypical.
J/k :wink:
No, I'm not applying this to any program immediately, but I was just wondering, because this type of file copying takes ages. I remember copying a 10 MB file on a 100 MHZ machine, took
ages.
You're right, on a 100mhz machine it took forever. But, those old babies are pretty much gone forever. Try the same copy program on a new giga machine --- it'll take about 2 seconds or maybe less.
*****
Mmm-hmm, took about 1.5 seconds on my P4 with 2.4 ghz.
Just goes to show, doesn't it. Computers 8 years ago were a lot slower.
Quote:..... And don't say use the SHELL "copy..." alternative, because what if others are using a different language version of DOS, as someone pointed out.
Zack, I re-read your original post and the bit about not doing a SHELL. After thinking about it again:
1) If you're running QB on this machine, then it must have DOS.
2) If it has DOS then both the Shell and the Copy are available and compatible.
So then, what's the problem that "someone pointed out"?
Actually Shelling to a Copy command is much more reliable because you'll get an exact copy of the file, not one which is subject to the interpretation and handling by your program. For example, there are many ways that End-Of-File can be represented for a file. If your program can't handle all the possibilities, then the resultant file will not be an exact copy.
Another consideration is that when you do a copy the destination file retains the same date/time as the original, which will not be true if you copy via a program.
I've done this before and I generate a batchfile containing the copy command or several copy commands when I want to copy multiple files like an entire directory. Then I Shell to the batchfile.
I toyed with reading and writing the file with the program, but abandoned this after doing some testing.
BTW, as far as speed goes, you can't beat the copy command.
Don't re-invent the wheel. :wink:
*****
*Looks around, and says "huh?", and then puts down wheel he was inventing*
Didn't you or Nath point out recently that it is unsafe to use SHELL "" in order to take advantage of the msdos utilities, because COPY.EXE (or COPY.COM, not sure) might be, on a Spanish DOS machine, COPIA.EXE or COPIA.COM?
The problem would be if you want to overwrite the destination file (eg "COPY /Y"). As Nathan pointed out, in Spanish versions of DOS this would be "COPY /S" (si).
I don't see why you need to use SHELL. If you open the file in binary mode (as Zack was doing), you'll get an exact copy. There is only one EOF in binary mode, and that's the true EOF.
It's easy enough to set the file date and time with interrupts, if it's that important...
No, it's just that as Moneo pointed out, COPY.EXE (or .COM, not sure, again) is faster.
Quote:*Looks around, and says "huh?", and then puts down wheel he was inventing*
Didn't you or Nath point out recently that it is unsafe to use SHELL "" in order to take advantage of the msdos utilities, because COPY.EXE (or COPY.COM, not sure) might be, on a Spanish DOS machine, COPIA.EXE or COPIA.COM?
Zack,
1) What we were talking about is the problem of executing a PATH command from within a batchfile which is run inside a DOS Shell provoked by a program. This is entirely an isolated and very rare problem.
2) There is no COPY.EXE or COPY.COM program. The "DOS Command Interpreter", which is COMMAND.COM, sees one of its commands, like copy, del, dir, etc. on the command-line or in a batchfile, and executes them with internal logic.
3) There is no Spanish version of copy like copia, etc.,
otherwise they couldn't run Zack's copy program which he exported to Spain. :wink:
Spanish versions of DOS respect and use all the same DOS commands in English. They mainly differ in displaying Spanish prompts and messages and different date formats.
*****
Ah, didn't know about #2. And Plasma: exactly my point.
This is a multilingual and multnation forum, wouldn't want anybody to need to change a lot of code to get programs running.