"Packed file is corrupt" need to provide user assistance with this problem and possible workarounds about dosbox-x HOT 19 OPEN

Run LOADFIX, then the program.

DOSBox-X allocates memory differently than DOSBox that also opens up more free memory (counting up from the base). Some programs have problems when loaded too low in memory, typically when a lot of free conventional memory is open.

from dosbox-x.

Just for reference, MS-DOS 5.0 and higher are said to contain code that on EXE load autodetects the buggy EXEPACK code and patch it.

DOS +5 got an on-the-fly exepack unpacker in its exe loading code - already found while reverse engineering the loader code, and the leaked DOS 6 source also contains that code

from dosbox-x.

You can tell if this is the case if running LOADFIX then running the game resolves the issue.

from dosbox-x.

loadfix does fix the problem on the one game I've tested, but is there any disadvantage to using loadfix? Why is the original dosbox unaffected by this dosbox-x problem?

from dosbox-x.

It is affected, it just doesn't happen as often because the original DOSBox project allocates enough padding to low memory to prevent most games from failing this way (but it still happens).

from dosbox-x.

http://www.os2museum.com/wp/exepack-and-the-a20-gate/

from dosbox-x.

Seemed it's not only EXEPACKed programs not working when loaded too low.
#628

from dosbox-x.

Ninja is the first experience I had with LOADFIX IIRC.
https://www.mobygames.com/game/dos/ninja_
A test case if you need one.

from dosbox-x.

The original MSDN article is available here:
https://web.archive.org/web/20140831054604/http://support.microsoft.com/kb/72360

from dosbox-x.

Is there a specific dosbox configuration required to prevent this - in other words make it work as it did in original Dosbox? I've never encountered such error in original one.

from dosbox-x.

The error is caused by a bug in Microsoft's EXEPACK stub when it's loaded too low in memory, not by DOSBox-X.

This issue is a reminder to see if it is possible to autodetect the buggy EXEPACK and do something.

In the meantime, run LOADFIX to occupy the lowest 64KB before running the program, and it should work.

from dosbox-x.

Just for reference, MS-DOS 5.0 and higher are said to contain code that on EXE load autodetects the buggy EXEPACK code and patch it. Perhaps DOSBox-X might be able to do the same someday.

from dosbox-x.

Sorry, these instructions make no sense to me, I have no idea what you're referring to even though I don't consider myself an average user, yet I am no developer with insights of MS-DOS either.

What makes sense to me is comparing a single run of original Dosbox - no error in any game and reproducing the very same steps with Dosbox-x - errors with many games and setups. This basic troubleshooting makes me believe Dosbox-x does something differently which possibly could be avoided and I hoped it had something to do with how mainline compatible mapping; adapter rom is ram; private area size or any mem is set up in config...

from dosbox-x.

Thank you Jon, I was not aware what loadfix is - that it is an internal executable mapped on Z drive.
I ran it and then the first tested game worked. I thought I'd put loadfix in [autoexec] but upon further restarts of Dosbox even without running loadfix everything which didn't work previously worked now - even executables I did not test while loadfix was loaded. Odd? Would I ever need to re-run loadfix or was it somewhat one-time permanent fix of the whole environment?

from dosbox-x.

@joncampbell123 I have now implemented the algorithm to automatically re-run the program with LOADFIX if the "Packed file is corrupted" error message is detected in my latest pull request. Tested with some programs and they seemed to work so far.

from dosbox-x.

just remove the EXEPACKER Stub from the executable

using UNP: http://unp.bencastricum.nl/
or exepack: https://www.bamsoftware.com/software/exepack/

from: https://www.bamsoftware.com/software/exepack/

A20 bug?
"yes" means the stub relies on 8086-style 20-bit address wraparound; i.e., it requires the address fff0:0123 to map to the linear address 0x23, not 0x100000023. Stubs with this bug may falsely error out with "Packed file is corrupt" when run at a low address in memory.

from dosbox-x.

As I mentioned in issue #1525, LoadFix should not be blindly allocating 64K of memory when it's automatically triggered. Doing so breaks CIV 1 under default settings.

Instead, it should allocate until the first 64K is filled up, and 576K is available. After conventional ram is down to 576K available, it can allocate 64K each use.

The alternative workarounds also sound like good ideas, but changing Loadfix should be done first.

from dosbox-x.

@Dwedit LOADFIX was updated with an -a option that does just that: Allocate the low 64KB of memory if not already filled.

@LowLevelMahn DOS 5 does the unpack on it's own? I was under the impression that it patched the faulty EXEPACK code, rather than doing the full unpack on it's own.

from dosbox-x.

@LowLevelMahn DOS 5 does the unpack on it's own? I was under the impression that it patched the faulty EXEPACK code, rather than doing the full unpack on it's own.

thats correct

my statement should have been "DOS gets it fixed without user interaction"

btw: the rust based exepack: https://www.bamsoftware.com/software/exepack/ is getting better and better (im collecting many different versions of the linker for testing)
and i think i've also found my first bug with UNP (by Ben Castricum) which bamsoftwares exepack unpacker does not have (im testing multiple version of microsoft linker exepack with multi segment nasm test and comparing the unpack results of UNP and the rust based unpacker, some of my example do not get correctly unpacked by UNP)
and all the other exepack unpackers also seem not to be that prooved :)

from dosbox-x.