On Fri, Aug 20, 2021 at 4:48 PM Aitor Santamaría <aitor...@gmail.com> wrote: > > Hi, > > Thanks Jeremy. > > On Fri, 20 Aug 2021 at 13:03, <perditi...@gmail.com> wrote: >> >> > I was trying to figure out how KITTEN/KITTENC works. Seems to attach each >> > NLS file with the "KITTENC" signal by the end of the executable. I've read >> > about making UPX support easier, I guess you UPX before you ATTACH. >> >> It is written to support either, appending before or after UPX, it >> stores the original file size and then when ran uses the compressed >> file size computing the difference and adjusting the stored offsets >> with this difference. >> So if you don't compress or append the languages files after >> compressing the difference is 0, but if you do it before compressing >> then the difference is your compression savings more or less and >> offsets adjusted accordingly. > > > But if you append after compressing, wouldn't UPX mess the attached stuff? > (I mean if it tries to "expand" something that hasn't been compressed). > I suppose it is tested to work, but I am curious, I am not very familiar with > the technical details of how UPX works. >
I haven't looked into what exactly it does, but it matters whether you are compressing an exe or a com file. For exe files, it uses the header (I believe) and only compresses the actual executable portion, not anything appended to the file, but instead anything after the end of executable portion is copied asis to the end of the compressed portion. For com files, there is no header, so it can't determine the end of the executable portion and anything appended will be treated as part of the executable program and thus compressed. So kittenc and similar tools will not work if you append to a com file and then upx - though I suppose they could be modified in that case to search memory for the strings as upx should both compress and decompress the appended data. If you append after compressing, I'm not sure exactly what the upx stub does, whether the uncompression has a way to tell the end of the compressed data or it will try to uncompress data that wasn't compressed (I did a quick but not exhaustive check and a upx com file, appending junk, running the com file does not produce any errors suggesting upx stub has a way to stop at the end of compressed data). [Note: upx limits com files to about 65350 bytes per its documentation] >> > Why did you need to write an own function to convert string to UL? >> >> It was from the original kitten - not needed in kittenc since that >> part occurs during build, but also no need to change working code; I >> like the update from switch statement to strchr for the xlat portion >> of the escape conversion > > Well I see it used when processing the Esc chars, when a language file is > processed. > What I was wondering is if the function is smaller, or has some benefits over > using the standard strtoul. > > Aitor I don't recall (pretty sure it wasn't me who added it), but my guess it was either for smaller size like you suggest (it definitely can be smaller) and/or because some compilers lack strtoul (not sure how many, but at least one lacks it). However, it should be noted that mystrtoul does not match strtoul: int mystrtoul (char *src, int base, int size); vs unsigned long int strtoul (const char* str, char** endptr, int base); where src and base are the same for both, one returns a long the other an int, mystrtoul uses size to determine how many numerical characters to process whereas strtoul updates endptr to point next char after number (if not NULL) Jeremy _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
