Print

[Yuyu]

Awsome of you to provide this to other developers in the scene    You have been very generous towrds all developers UnleashX and I hope they have shown you the same respect, as I know as a late comer you were bashed upon for awhile for even daring to create another dash.. Let alone with some of the same features as the current dashes out... Keep up the great work and I hope to see that new version UnleashX out soon...

As I know all developers can use it in the scene from time to time, between all the bashing, I respect the work you do, and wish to thank you for devoting so much of your free time for my selfish entertainment needs  

[BenJeremy]

Thanks a lot.... wonderful to see contributions to the scene.

It's like waking up Easter Morning and finding a nice basket of goodies.... oh wait, it IS Easter, and this IS a basket of goodies!  

[BenJeremy]

Well, I've run into a few furstrating issues with this lib... primarily in regards to the incredible amount of data being allocated from the stack!

It's causing CHKSTK overflows all over the place. I've corrected for the initial listing - that seems to work great now, but I have to pour into the extraction stuff to fix that part of the code, which is littered with 1K strings declared as stack variables. Worse, they have returns peppered through the 600+ line function

The easy way would be to remove the stack checking, but then what... I caught the code trying to allocate over 40K from the stack. That's Bad news.

Ah well... it will get fixed, and I'll release the modified version. I'll probably just make some simple smart pointers to avoid too much code re-writing.

At least it's a good start.

EDIT: OK, almost there. kludging some simple smart pointer classes did the trick.

[BenJeremy]

QUOTE (unleashx @ Apr 12 2004, 11:20 PM)

CHKSTK overflows happpened to me too even before this code, and I'm quite stumped as to the reason why. Same thing happened to DVD2Xbox, I think. A lot of my string conversion routine was affected, specially those A2W, W2A macros and I'm not really sure why this happens. At any rate, the main code that does extraction was still the original UnRar source. I have just added the flags to exclude functions not available on the xbox library, usually those that deals with WinNT specifics and unicode functions. You can see the changes by finding the standard def _XBOX, aside from those, the source is still the same. The new code really is in the unrarx.hpp, and rar.cpp. I'd like to see that part where it tries to allocate 40k buffer, really, that's bad news I agree. If you can release your source afterwards, I'd like to start on that instead.

Yeah, I get that to you as soon as I get it fully working.

I have it unraring files, but for some reason (I didn't have time to debug it compltely last night), it wasn't unraring ALL of the files in my test. Specifically, files two folders deep - though it reported no problems.

It shouldn't be too hard to figure it out though - just that it's ugly code (I realize it's not yours or grebulon's fault on that count). It was one reason that kept me from porting it in the first place.

As it stands, I also need to go through my ZIP code as well, as my test file didn't completely unzip from that, either.  

Given a day or two, however, I'll have it sorted out.

I've tied my ZIP and RAR code into the same interface, but there are subtle differences in how the stuff is handled between the two of them. ActionScripters will still need to know the difference between archive formats, as I have separate (but syntactically similar) commands for ZIPs and RARs. The biggest difference for users between the two is that they can build new ZIP files, too.

[grebulon]

I tested with deep folder nesting and it worked fine. Perhaps the folder or file name is incompatible with the xbox file system?

[BenJeremy]

QUOTE (grebulon @ Apr 13 2004, 06:28 AM)

I tested with deep folder nesting and it worked fine. Perhaps the folder or file name is incompatible with the xbox file system?

The odd thing was that the folders were there - I enabled the "E" option for my purposes and my script built the folders as they appeared in the RAR file (and the ZIP, too).

I may fiddle around with that a bit tonight.

[BenJeremy]

OK... I figured out what was happening there. I was using the "E" option, which SHOULD strip the path from the filename, allowing the app to specifically control where the file goes. The routine they had only stripped out the first folder of a path - when in "char" mode. The "wchar" version of the routine would work fine, though.

I re-wrote the offending routine.

I'll post the code in the next day or two. It will be a VS.NET 2003 Project this time around.

Oh... and for some reasons, my UNZIP seems to be totally hosed. Don't know what's happening there at all. Maybe I'll figure it out as easily as the UNRAR issue. It's unzipping files, alright, but the sizes are incorrect, and I assume the data is corrupt.  One thought I had was that the compression methods in the test file are not supported in the ZIP routines I'm using.

[BenJeremy]

OK, the code is here:

MXM's version of UnRar Lib

One line might need to be commented out - the "E" option line in the unrar code. That's the one that lets me extract per file and ignore original pathing.

It's in VS.NET 2003 vproj format for the 5558 XDK.

[Striker2k2]

^bump^

all problems solved?

[BenJeremy]

QUOTE (Striker2k2 @ Apr 18 2004, 06:39 AM)

^bump^ all problems solved?

That's what I said.....