beside that this should work under dosbox

why not the 32bit version:
https://keenwiki.shikadi.net/wiki/UNLZEXE
https://files.shikadi.net/keenwiki/tools/t.un … .2010-07-04.zip
source code of the above 32bit exe: https://github.com/gerstrong/Commander-Genius … exe/unlzexe.cpp

@llm:
A 32bit version? Thanks!

Try UNP instead, more compression methods than just LZEXE: https://bencastricum.nl/unp/

@ripsaw8080:

Thank you, I am aware of unp but didn't have it available at the time I wrote that post.

When I get home and have access to my own pc I am going try that loadfix suggestion. Could still be useful alternative.

Uhm, didn't someone suggest LoadFix? Where did that post go? Also it doesn't work. DOSBox doesn't freeze anymore but the unlzexe.exe still freezes.

my old unpacker will handle it too https://bloodycactus.com/files/amber.zip

(and lots of different things vs unp, see https://bloodycactus.com/files/amber.txt).

The zip archive for UNLZEXE 0.5 includes its C source code. I found that the program crashes in DOSBox due to a bug in its code. The isjapan() function was intended to call DOS function INT 21h/3800h (Get Country-specific Information), but erroneously calls a DOS function number that happens to be on the stack. In DOSBox the function called is 00h (Terminate), which causes a crash because the program is EXE format, not COM format. In real DOS the function called is 49h (Free Memory Block), which fails because there is no valid memory block at the specified address, but it does not cause a crash. The reason for the difference in functions called is stack behavior of DOS functions that DOSBox's internal DOS does not bother to emulate. It's certainly possible for DOSBox to emulate the DOS stack behavior, which would prevent the crash as it does in real DOS, but of course it would not fix the program's bug.

To fix the program code:

1 int isjapan() {
2     union REGS r;
3     struct SREGS rs;
4     BYTE buf[34];
5     
6     segread(&rs);
7     rs.ds=rs.ss;  r.x.dx=(WORD)buf;
8-    r.h.al=0x3800;
9+    r.x.ax=0x3800;
10     intdosx(&r,&r,&rs);
11     return(!strcmp(buf+2,"\\"));
12}

The function number (38h) should be in the AH register, not in AL. When the fixed source is compiled, the program should function as it appears to have been intended, and no crash in DOSBox.

In later versions of UNLZEXE the bug is mentioned in comments, and the offending code removed rather than fixed.

Everyone thank you for your feedback. I think there are enough work arounds for this. It's not too big a deal.

It might be a good idea for the DOSBox developers to see if they can prevent DOSBox from hijacking the desktop due to freezing. It's rare but doesn't just happen with unlzexe.exe.

The only solution is to either force a hard reboot (power on/off for the computer) or:
1. Press the Windows + L key to go to the lock screen.
2. For some reason I can't fathom Microsoft neglected to adjust the resolution before displaying the lock screen. Which means a 640x480 resolution lock screen in these cases.
3. Clicking "I forgot my Pin" forces Windows to set the proper resolution for the lock screen. Just click cancel and you have a proper lock screen.
4. However, when returning to the desktop by entering my pin, DOSBox is stuck in a corner of the desktop. Completely unresponsive. Usually the mouse pointer has disappeared too! (What's up with that?)
5. So you need to open task manager or log off using the keyboard or navigate and invisible mouse pointer. (while DOSBox hijacks a quarter of the screen.)
6. Usually I resort to rebooting from the lock screen.

Imho this should be investigated. I am using Windows 10, but I don't think that really matters. I think I've seen this happen on my previous system running Windows 7 as well.

EDIT:
I sometimes go overboard with words. This post has been cleaned.