But, when I run my executable console app it does not extract the entire input file to the output file when executing the -o param any reasons why it is not from this code?
It never dumps a output file even when it says it is doing it?
Here is my console app screenshot-> https://ibb.co/7jC8pwj
Then if -o is the parameter for the input file
Then, what is the parameter for the output file?
There, has to be a reason in code why it is not dumping the output file?
some compression tools just rename the input file for the output file.
eg if you bzip2 a file, it just makes filename.bz2 and you don't specify the output name at all. It may be doing this? Or not, it seems to follow the pattern below.
All I can tell you is that code detects which parameter has the -o in it (this becomes 'mode') and then passes everything else to the decompress (the -o parameter is completely ignored, as far as I saw!). It appears that you have 3 args, one of them has a -o in it, and the other two are input and output, in that order, but the -o could be anywhere in the mix, including a screwy infile, -o, outfile ordering.
My 2 cents is this is the most messed up noobily arg parsing I have seen since college.
I agree jonnin it is very messy arg parsing lol
I see so it just takes the input file makes a file with the same name and .ext.
Which expains a lot but if that is so then the date of the input file never changes.
So it either is dumping the file somewhere else besides where the rnc decompressor.exe is located or not doing renaming or dumping the file at all?
Very, weird program indeed.
Is there an alternative way to decompressing a file archive with a start offset file signature of RNC? Without using this messy code?
That's an start I can do in the mean time if one person was to make a small decompressor based on this code where would one start without needing all the code specified?
Since the file is part of a package called "The libAdikted dynamic library contains all you need to load, edit and write Dungeon Keeper 1 maps", my guess is that some enterprising soul did a bit of reverse engineering and what you see in the code is the result of that.
Yeah, your right on that, also after doing some error checking and what not the program passes no issues at all it is doing what it is suppose to be doing but no output file or rename file after decompressing the file is generated so this code seems to be an unfinished reverse engineering process which is bad for me trying to decompress a file with RNC-001 signature.
Thanks for the help guys, if anyone has any suggestions or tips or leads on this concept I am all open to read and check it out.
the tool has pretty good docs for what it is, and a set of example programs as well.
Have you tried to compile and run the examples? Or opened them up to study how they are used?
The code is a bit rough, but the work put into it suggests it probably functions.
the only rnc i found was for audio, and it looks ancient to boot. Dungeonkeeper sounds ancient too.
Well, I tested the other examples they compile but the one I am interested in was the "dernc.c" example for decompression of a file archive with a RNC-001 signature.
So, for the most part the "dernc.c" example works but is not complete it never dumps or even rename's the file archive you are using with the tool to decompress.
How, the tool works is it detects the RNC signature and if it is valid it will begin to unpack the archive file and if success it begins to decompress chunks of data and if success it starts to extract the decompressed archive data to an output file once succcess it will dump the file in the directory where the generated exe resides but it never makes it to that final step so determining this from error checking and really studying the "dernc.c" code I made my conception based on my finding's. So, not sure if all the examples are complete or not?