[<<]Message[>>]    [<<]Author[>>]    [<<]Subject[>>]    [<<]Thread[>>]

Number : 521 Date : 2001-08-04 Author : Kan Yabumoto Subject : Re: lite version?? Size(KB) : 5
Michael, Thank you for the pointer to UPX which is quite intriguing. I went there and read the material in the web page. It is very intersting. It is ideal when the XXCOPY16 program need to be moved over to a tight space medium such as the floppy. On the other hand, it incurs a performance penalty on every execution. What should be noted is that the Win32 PE file format (the 32-bit common execution program file format) was designed with an efficient virtual memory implementation in mind. That is, the executable program file itself acts as the swap file for the program while it is running. That is, when XXCOPY.EXE is being run, only the necessary chunks of the XXCOPY file are brought into the main memory (by the 4KB granularity) on an as-needed basis (using the demand- paging scheme). In a typical XXCOPY execution, the help text (either the alphabetic version /HELPA or the unsorted version /HELP) which occupies a substantial amount of memory (about 50 KB altogether) is never accessed and therefore will remain on the program file (disk) without ever even brought into the main memory. In a way, knowing this, we, the programmer can be somewhat lazy in adding extra code which is seldom executed and therefore, even though the overall program size would increase, it would not add any performance penalty being just a very large executable program. I'm afraid that these hidden benefits of the PE file format will be all lost when we compress the program into a self-extracting file on the fly. Moreover, the expanded program will probably remain in the virtual memory space which reduces the amount of available virtual memory space by that much. That is, I assume the UPX stub portion will probably uncompress the entire program file rather than to uncompress small portion at a time on demand and does not even try the portion which is not being utilized for a particular run. In other words, the superficial benefit of having a small file size will add substantial burden on the system resource in the Win32 environment. If that is the case, there is little advantage using the technique for the 32-bit version. On the other hand, for XXCOPY16, it has a totally different outlook. First of all, as a DOS program, the uncompressed file image will very likely remain in the regular memory area (the 640 KB regular DOS memory space) and little impact on the virtual memory related issues discussed above. And, this is where the original motivation for reducing the program size. So, if we were to seriously consider the use of the UPX technique, it will be limited to the XXCOPY16.EXE program. ------------------------------------------------------------ Currently, there is a minor inconvenience if we apply this technique now. That is, the current method of the built-in version-detector mechanism implemented by XXCOPY will stop working unless it is replaced by a different scheme --- when you install a new version of XXCOPY, it will scan the target directory for an older version of XXCOPY.EXE and XXCOPY16.EXE and locate a signature value in the file to determine the version number of earlier release. This allows XXCOPY to rename the older version using the version number. ----------------------------------------------------------- The easiest way for us is to show the technique for those who want to use the compression, in order to squeeze the program into the floppy, and let the willing parties to do their own work. The proper way is for us to remove fat and come up with the "lite" version (which you could further shrink using the UPX technique). To answer to Michael's question, yes, it is worth giving some thought on a limited basis on the XXCOPY16.EXE version. Incidentally, I was trying to see how efficient their compression algorithm was. By PKZIPping the XXCOPY.EXE (freeware v.2.60.0), the 262,144-byte file becomes 106,273 bytes. According to Michael, the UPXed file is 99,328 bytes (with the self-extracting stub portion). That is about 7% smaller than the ZIP stuff. That is quite impressive. I wonder if Michael is interested in converting all of the Windows .DLL and .EXE (found inside the C:\windows\System directory) --- or better yet, in Win2000's c:\winnt\system32 directory which is huge and apply the UPX technique in every file you find there. In theory, the entire windows directory size will become less than half. The question is, what is the overall impact to the system performance (especially to the virtual memory usage)? If my reasoning (explained above for the Win32 environment) is correct, the system would probably die due to the virtual memory exhaustion --- or just excessive thrashing). Anyway, this is my guess. And, it is worth investigating. Any volunteers? Kan Yabumoto =========================================================== At 2001-08-04 07:46, you wrote: >On this topic of compression, the UPX executable compressor reduced XXcopy >from 262,144 to 99,328 bytes - and it's still executable. > >It will work on most MSdos exe,com,sys as well as windows executables. >You may be able to create enough room on your boot floppy for the full XXcopy. > >Look here: > > The Ultimate Packer for eXecutables > Copyright (c) 1996-2001 Markus Oberhumer & Laszlo Molnar > http://wildsau.idv.uni-linz.ac.at/mfx/upx.html > http://upx.sourceforge.net > > >Kan, would you consider using for all xxcopy distributions? > >Michael > > >On Fri, 03 Aug 2001 16:41:55 -0400, rotaiv wrote: > > >At 08/03/2001 02:11 PM, F. Schmultzburger wrote: > > > >>I have a fairly complete boot floppy that my collegues and I to use > >>when dealing with clients computers when windows is screwed up. I > >>really like XXCOPY, but it's much bigger than MS's XCOPY, and the boot > >>disk has less than 10k to spare. > > > >Have you considered creating a CAB file and extracting the contents to a > >RAM disk like the Win98 startup disk? I just compressed xxcopy 2.70.2 into > >a CAB format and it is only 87KB (60% smaller).
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.