wordproc@ucf-cs.UCF.EDU (wordproc) (11/28/89)
I got lots of great responses from you guys regarding my following message: >> I have a very large file on my MSDOS 4.01 machine that I need to copy onto >> 360K diskettes and transfer onto an MSDOS 3.3 machine. >> >> The file is a .EXE file of about a megabyte in length and is a >> self-extracting archive created with PAK. >> >> Naturally, I cannot use 4.01's BACKUP/RESTORE to copy the file over several >> disks because 4.01's RESTORE will give an "incorrect DOS version" error when >> I try to restore the file to the MSDOS 3.3 machine's hard disk. I presume >> that using MSDOS 3.3's BACKUP/RESTORE will fail for the same or similar >> reason. >> >> Upgrading the 3.3 machine to 4.01 is not an option, unfortunately. >> >> What other utility could I use that won't take the DOS version into account? The following are some of the responses: > Why not try downgrading the 4.01 machine to 3.3 for purposes of the > backup in copying your large file? That might work, but it would be nice if there was a utility that would do the same thing that BACKUP/RESTORE does and simply *not* check the dos version. Seems to me (whatever that's worth) that there should be a simple way around it than re-installing DOS. > Get a copy of a version of uuencode/uudecode that also splits/joins the > coded file. One was distributed not too long ago on comp/binaries/ibm/pc. > uuencode the file under 4.01, copy several sections of it to one floppy, > and repeat until it all fits, then under 3.3, copy them back to your hard > disk and uudecode the file. > > John Baird, Naval Ocean Systems Center, San Diego, CA USA > Kang Li, UCLA Computer Science Department > Roberto Gomez, Physics Department, University of Pittsburgh I'll look into this if I don't find a BACKUP-like utility that won't check the DOS version. > > Fastback + This may be the ticket, since I have a tape drive on the way and probably w be using Fastback + for that purpose. > Some people around, still have low density floppies, so I think your > best bet, is to extract the archive on your system, and then create > four separate archives to give to him. > Sean Coughlan I could kill the self-extracting archive and re-archive into smaller chunks, but that would be time-consuming and I still couldn't understand why a simple BACKUP-like program doesn't exist that would do the job without checking the DOS version. > PC-Magazine has the utility that you seek, but I am afraid that > I do not have nor remember the name. It should be available through > PC-MagNet. Sorry I could not be of more help than this. > Bryan Perhaps they do have one. I have their Utility disks volumes 1 and 2, and the only backup-type utilities they had could not handle a file larger than the target disk. The utility simply kept asking for another disk and would start over with that file on the new target, never finishing the copy. > Is it physically possible to connect the machines via > their serial ports with a null modem cable and use something > like Procomm to transfer the file? If they're not close > enough, perhaps the one computer could dialup the other > and still transfer the file over the phone line... > > Bruce W. Mohler > Ron Kline This sounds like a route I may end up taking. > Not having 4.01 I'll make the assumption that, like other versions, you can > still boot up from a floppy without having to go through a process of > configuration and instalation. What I've done in the past between 3.1 and > 3.3 is simply boot the target machine with a floppy disk that has the > original machine's DOS and a copy of the original's RESTORE program. I > then initiate the RESTORE from the floppy. Sounds like a very good possibility. As long as the BACKUP/RESTORE isn't reading the DOS version off the hard disk.... That's what I'll probably try first, since I don't yet have Fastback +. A final suggestion was to use a better file compression utility. Great idea, but the PAK utility created this self-extracting archive of about one megabyte from nearly four megabytes of program source, data and executable. I don't think much better compression than that would be obtained with another utility. In a few unscientific comparisons, it actually seemed to provide equal and even better compression than ARC or the PKARC/PKZIP utilities. THANKS, EVERYBODY, for the help! ___________________________________________________________________ _________ / Marcus Clenney ___ ___ /___ ___/ ________ / U. of Central Florida / | / | / / / ______/ / Dept. of Computer Science / /| | / /| | / / / / / Orlando, FL 32816 / / | |/ / | | / / / /_____ / wordproc@bithlo.ucf.edu /_/ |___/ |_| /_/ /_______/ / ____________________________________________________________/
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (12/01/89)
In article <1381@ucf-cs.UCF.EDU> wordproc@ucf-cs.UCF.EDU (wordproc) writes:
$Sounds like a very good possibility. As long as the BACKUP/RESTORE isn't
$reading the DOS version off the hard disk....
No, programs that check the DOS version use int 21h, function 30h to
check the version number. What they care about isn't what version of DOS
the disk was formatted under, but rather what version of DOS is currently
running. The rationale for this is that different versions of DOS have
slightly different sets of function calls, so it may depend on a function
call that's present in DOS 4.01 that isn't in DOS 3.30, for example.
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
They say the best in life is free // but if you don't pay then you don't eat