no i havent all i ever used was 7zip or winzip or the windows xp zip program. what is that stuff and how does it work the stuff u mentioned

... These days, who the heck has ever heard or Seaware, seller of ARC tools? Almost no one. PKZip? For a long time, it was everywhere. I still have it and use it on occasion.

I corresponded with him many years later on Exec-PC, the monster BBS, where I led the PC-Hardware forum. I remember watching all the flak flying when Seaware sued him over PKArc and PKXArc. Their claim was ridiculous and had no technical merit, but Phil ran out of money and lawyers before they ran out of money and lawyers.

On Tue, 19 Aug 2014, Derrick Meury wrote: Do you also need some help repairing the <Shift> key? Yeah, many "Driver" websites are BOGUS. Even many of the legit ones will willingly host ads for "download managers", etc. that deliberately have links to click that fraudulently claim to be the link to click to begin your download. Hosting such ads make them equally culpable. As mentioned before, BACKUP/RESTORE in the forms shipped on early versions of PC/MS-DOS WILL split a file that is too big for a floppy! You could BACKUP the file onto disk(s), and then RESTORE onto the destination hard drive. There are other, including commercial products, that will also split/recombine files that would otherwise be too big for floppies. BUT, if you have the stones to do it, this weeks assignment is to write a file splitter. GOALS: useful utility, practice handling files larger than RAM, understanding working with files that contain characters tha might be misunderstood to be the EOF 1) Write a program that copies a file. Open two files, one for read and one for write. Read byte from the source file, write it to the destination file. GOTO20. Do NOT read the entire file into memory and then start writing [NO CREDIT WILL BE GIVEN FOR THAT], because that will interfere with later steps, such as copying files that are larger than your virtual memory. WARNING: be careful, that SOME language/OS combinations will default to an "ASCII" (or "cooked") mode (which disunirregardless of its inappropriately chosen name is COMPLETELY DISRELATED TO ASCII), and stop at certain characters; you may need to over-ride for "BINARY" ("raw") mode in OPEN or FOPEN. If written properly, this program will impose no limits on file size, other than the existing OS limits. 2) Add a counter, and stop the copy at a fixed length. Check the size of the resulting file! - did the language/OS append an extraneous "END OF FILE" character? Make the length an input variable. For now, the maximum number will be the OS file size limit and/or the maximum size of your counter variable type. (Note: using "float" will earn you a below-failing grade) Optional extra credit: modify the program so that the counter can be larger than the maximum for an unsigned long int. 3) Add an "offset" as another input variable, that controls where within the source file to START. Note: if your language/OS does not support an adequate seek/fseek capability, then use the "offset" as a counter, and read that number of bytes from the source file before beginning the read/write copying. Using your SPLIT program, run multiple times with different inputs, you can now take a source file, and produce a series of destination filescontining the pieces of the source file. Optional Extra Credit: Modify the program to not need the "offset" variable, and automatically generate multiple destination files. It should open the source file, write a destination file, close the destination file, open another destination file, copy it, open another, etc. until done. Be sure to close each destination file before opening the next, so that you don't run out of file handles. 4) Recombine the files. You can write a companion program, or get lazy and use MS-DOS COPY. COPY /B source1.ext + source2.ext + source3.ext destinat.ext will combine source1.ext, source2.ext, and source3.ext into a file named destin.ext. WARNING! The "/B" is critically important! For a single file copy, COPY defaults to "raw" or "BINARY" mode. BUT, when combining files, OR copying to a device (such as copying fonts into a printer!), COPY switches to "cooked" mode (erroneously called "ASCII MODE"), so that it can STOP when it encounters character number 26; that is so that when copying a CP/M file, it won't copy the rest of the setctor after it reaches "END OF FILE". You MUST over-ride! Split a file, recombine it, and then compare to confirm that the recombined file is an EXACT match for the original. Note: In most post-CP/M operating systems, there ain't no sech character as EOF! End Of File is NOT a special character in the file. Instead, keeping track of where the file ends is done by the OS. Calling EOF a character is a FICTION. It does not exist, and is a fictitious character (like Al Bundy, or Santa Claus). But, like Santa Claus, such a fictitious character is very handy for controlling file reads (or getting children to cooperate in December). "EOF" is merely a defined constant naming the ERROR CONDITION of fgetc(). It is NOT a character (and, in most c compilers is not even a valid value for a char variable type.) -- Grumpy Ol' Fred cisin at xenosoft.com

On Wed, 20 Aug 2014, Jonas Otter wrote: Yes. BUT, here we are not plagued with undefenestrated college administrators. I gave the SPLIT program as an exam question in some of my classes. Derrick wants us to give him a fish.