Try using Dragon Unpacker instead.

Thanks, I know Dragon Unpacker but the latest version (v5.6.0) doesn't got the PCX format... weird. I attach a screen capture sorted by "Type" (PCX must be in Picture Type)

DOSBox wasn't designed to handle this kind of situation. I'm impressed it got as far as creating a few thousand new files before crashing. That said, I would guess the crash (exception) is related to DOSBox's directory cache. You could try an SVN build, as there have been some fixes/improvements to the cache, but this situation may be asking too much. Another thing you can do is create a hard disk image big enough to hold the source file and output files, and use that image with booted DOS in DOSBox; that way the cache is not a factor.

Thanks for your possible solution ripsaw8080! but sometimes, I don't understard why DosBox doesn't have the same functionalities as the original Dos... That program will not crash in a real Dos, ¿why not solve this in DosBox and make DosBox be compatible with more programs like in the past?

ripsaw8080, can you tell me how to create a hard disk image? A link to a "howto" of that or telling me the only the necessary program will be enough.

Multi Ripper 2.80 has a parameter /F that is "Deactivate Cache's Flush" but it crashes too:

/F: Deactivate Cache's Flush, which is done after every extraction.
This function was added to avoid disk slowdowns caused when cache
buffer become full after finding a pattern, especially on huge files.
Works with Microsoft SmartDrive and compatibles, that are Norton Cache,
Symantec SpeedCache+ and SpeedDrive...
According to informations from Ralf Brown's Interrupt List there
should not be incompatibilities with other types of caches; anyway
the cache flush is not applied with these.

/MHHHH: Size of internal memory buffer used for reading the file
Minimal size 4096, max 32768
/M1000 = 4096 byte
/M8000 = 32768 byte

but sometimes, I don't understard why DosBox doesn't have the same functionalities as the original Dos...

Yeah I wonder that as well. Those stupid guys should get their ass up.

...

DOSBox tries to emulate enough (but nothing more) for games.
We haven't run into a game that tries to create this many files.
It might be interesting to figure out what goes wrong for stability reasons, but it's not on the top of our lists.

I don't think there's anything the program can do that will have an affect on DOSBox's internal directory cache, except maybe indirectly. SmartDisk and similar are drive caches that would be running inside the emulation; not the same thing. As I said, you can try an SVN build; maybe it works better... but I'm not going to volunteer my system to test it, as even Windows gets rather grumpy when you try to cram many thousands of files into a single folder.

There is at least one hard drive image guide in the DOSBox Guides section. Might not be completely up-to-date; but if you run into a snag after following the guide(s), feel free to ask *specific* questions.

Thanks ripsaw8080. Yes, that's true, is better to do from cmd "del *.pcx" than select all the pcx files in a window and delete them, incredible, a modern OS slower than the same thing from console... Surely is because each time a file is deleted, Windows must refresh the window to "delete that line".

OK, I will investigate into that, I will try first to make a hard disk image and if this doesn't work, I will try with a DosBox SVN, any in particular? I will post my results here

I solved the problem. I have not created a hard disk image or try with a SVN DosBox, finally I downloaded Multi Ripper v3.00b, that now is win32 compiled code and not win16 like un v2.80, so you can execute it without DosBox and the program works well, it extracts all the files.

Sorry about knowing if your two solutions would work too