Split version history --------------------- What is new in version 3.4.2 (dated April 3, 2005, build 22): Corrected amount of data that can really be copied onto a Iomega Zip 250 from 245 to 238 Mbytes. Added the web site URL in the status bar when "hovering" nowhere. As of April 6th, 2005, the Windows GUI version is compressed with UPX. What is new in CONSOLE version 2.2 (dated April 6th, 2005): Fixed the batch/shell script generator to end with deleting itself with the correct filename. Minor visual corrections in "usage text" and in the progress texts (taking into account the Linux/Unix shell script generation). What is new in version 3.4.1 (dated April 2, 2005, build 20): Minor display bugfix. When using the Quickselect the "What will be done" text was not correctly updated according to part types. What is new in version 3.4 (dated March 31, 2005, build 18): Now also creates a Linux/Unix shell script to put all the parts back together. It creates both batches all the time... Use the one you need, *.bat for DOS/Windows or *.sh for Unix/Linux. More presets than just a floppy! Now you can also choose CD 650/700 IomegaZip 100/250 DVD 4.7/8G. The Zip 100 and 250 set to 98MB and 245MB because of FAT overhead. No full 250MB file fits onto a Zip250 disk. The command line version only does Zip100 (most common), CD700 (who can still find 650MB CD's nowadays?), DVD4.7 (8G is not most used yet). Nonetheless the command line version is meant for scripters or performance addicts (it is way faster than the GUI version) so the presets do not really matter for the command line version... Anyone knows that one can specify 8000 MB size for an 8 Gig DVD, right? What is new in version 3.3 (dated March 31, 2005, build 10): Further improved the DOS batch script to take into account destination disks that are nearly full. I have plans to also generate a Linux/Unix shell script to put all the parts back together... Stay tuned! What is new in version 3.2 (dated March 27, 2005, build 3): Moved the functionality from the progress form onto the main form (only one window now). Fixed many repaint issues. Enhanced DOS batch to rebuild the stuff in order to support many parts and partnames with very long filenames. On the other hand you will not be informed when a part is missing during the reconstruction. The statusbar is back! What is new in version 3.0 (dated December 30, 2004, release 2, build 55): Same day second release :-) I adapted the way filesizes are reported in the GUI version. Digit grouping is done and the sourcefile size is also displayed as T, G, M or kbytes according to the total file size. I figured that with large numbers it would increase the userfriendlyness of the program. What is new in version 3.0 (dated December 30, 2004, release 1, build 50): Thanks to Ted Cooper that came with the demand for huge file support (i.e. files larger than 2 or 4 gigabytes) and thanks to him for the testing as well I made the following improvement: Now capable to handle files >2 gigabytes! The maximum filesize is now the largest signed integer that fits into 64 bits (something like 8 million terrabytes, we're fine for some years to come). This came with a price to pay... The functions used require more instructions and the calculus for the progress bar is also heavier. Overall there is a performance impact. The console version only does the large file support, I did not increase the read/write buffer but I added a spinner that indicates the splitter is not "stuck" (also brings a small performance hit). While I was at it I also improved the following: The registry read of the parts type and amount happens only once at program start as it is rather a nuiscance to see the settings flip back when opening a file (in case the user wants different part types during program use). The read/write buffer has been extended from 8k to 18k for performance reasons and more particluarly when saving the parts directly onto a floppy. I noticed during tests that each write operation came with a head move to and back from the FAT to reduce head seeks onto floppies (and other removable media) I increased the buffer size (18k is the size of one cylinder on a standard floppy). This will also increase performance overall as there will be less iterations in the read/write loop resulting in less calculus for the progress bar etc... The Win32 GUI version is now compiled for pentium class CPU's and is not compatible with 80386/80486 computers! What is new in version 2.6 (dated August 11, 2002, release 1, build 51): Still responding to Gair's feedback Split now saves its directories (source and destination) in the registry. It saves it when one confirms a file dialog and it loads it back just before opening the file dialog. Split now also saves the number of parts and part type in the registry when one confirms the splitting action (confirm the Save As... dialog from the "Start Splitting") and it loads that information back when clicking the "Browse files..." button. What is new in version 2.5 (dated August 8, 2002, release 1, build 40): Thanks to feedback of Gair Shields who discovered the bug I fixed the problem where splitting larger files than a destination media can handle would fail in detecting the disk being full. Now a warning message appears telling the user to insert a disk with at least the correct amount of free disk space to continue (or simply cancel). This means that you can now split directly onto iomega Zip drives or floppy disks. I also added the extension patterns for movie files to the list where one can browse for a file to split. What is new in version 2.4 (dated August 1, 2002, release 2, build 35): I discovered a bug with the progressbar. Fixed and changed it's functionality to progress 1 percent at a time instead of part per part. I also set the 8.3 compatible filenames as the default (if you split it's for e-mail anyway) and I changed the tooltip to be more clear. What is new in version 2.4 (dated March 19, 2002, release 1, build 30): I added a cool feature, it now tells you estimated times for the file to be transferred by modem, ISDN or DSL. These are just rought estimations as the quality of your connection may vary. The speeds I used for the calculations in kbytes per second are: Modem 3.5, ISDN 7, DSL 100. These speeds are based on my personal experience with internet download speeds and these may vary for you. The whole idea is to give you an idea ... right? Do not count on it to set your alarm clock. This is also why I do not calculate it up to the seconds, that would be nonsense. What is new in version 2.3 (release 1, build 24): Sneaky release without notice, no major changes, simple rebuild. What is new in version 2.2 (dated January 22, 2001, release 2 build 18): Release 2 is an urgent bugfix release (thanks to Rugal to detect this one). Added a progress window during the splitting (usefull for extremely large files) The user can select the "unsplit" batch path and filename The splitted parts will be created in the same directory as the "unsplit" batch The splitted parts will bear the same name (not extension) as the selected "unsplit" batch When requested by the user only (added checkbox in 2.2): The parts will be named "PART.###" (### = 001 up to number of parts) if the destination "unsplit" batch filename is a long filename (LFN) for destination platform compatibility reasons! Added tooltips to keep it self explanatory Added a check for spaces in filenames and use quotes around them if needed in the "unsplit" batch