DOS ain't dead

This year's spring we had a lot of discussions about UPX-compressed files. Several month ago I started to write a small tool to display all UPX header data in a nice way. Now I "finished" that project and would like to hear your opinions.

Archive upxinfo-04-aug-2008.zip just holds a ready-to-run EXE file. Final release will contain short manual and source code for Turbo Pascal 5.5 (), of course.

Trivia: UPXINFO.EXE has been compressed using aPACK, not UPX.

---
Forum admin

> This year's spring we had a lot of discussions about UPX-compressed files.
> Several month ago I started to write a small tool to display all UPX
> header data in a nice way. Now I "finished" that project and would
> like to hear your opinions.

Looks useful. However, some suggestions:

- Don't call the first value "UPX version". Yes, it's the header data called "version", but it doesn't contain the version of the UPX program that compressed the file. I would rather call it the UPX file format version.

- UPX lists a compressed size of 148 byte more than UPXINFO. I suppose that's the size of the header and decompression stub. (My binary is compressed as DOS .COM...) Although I agree the compressed size of the real program is also useful, UPXINFO should additionally list the stub/header size.

---
l

> Several month ago I started to write a small tool to display all UPX
> header data in a nice way. Now I "finished" that project and would
> like to hear your opinions.

Looks good, but two comments ...

1). Shouldn't the help screen contain either a URL (e.g. http://www.bttr-software.de/) or at least your e-mail address?

2). What, no LFN support? Aren't there Pascal units around that can handle that? (At worst just use int 21h,7160h to convert LFN to SFN.)

Otherwise, good job, seems to handle all the various DOS/Win32 formats correctly (as far as I can tell, at least the ones I tested, not exhaustive by any means). Of course, if UPX itself can't handle it (D3X-stubbed, BinUtils, compressed Causeway stub + compressed Watcom/LE), then neither can yours.

> Trivia: UPXINFO.EXE has been compressed using aPACK, not UPX.

Outrageous!

> 1). Shouldn't the help screen contain either a URL (e.g.
> http://www.bttr-software.de/) or at least your e-mail
> address?

No. That's left to the manual. I think search results for "bttr software" are sufficient: http://www.google.com/search?q=bttr+software

> 2). What, no LFN support? Aren't there Pascal units around that can handle
> that? (At worst just use int 21h,7160h to convert LFN to SFN.)

LF-what? Do you really need this? It will "blow" the binary by probably 100 bytes.

> Otherwise, good job, seems to handle all the various DOS/Win32 formats

Thanks!

> correctly (as far as I can tell, at least the ones I tested, not
> exhaustive by any means). Of course, if UPX itself can't handle it
> (D3X-stubbed, BinUtils, compressed Causeway stub + compressed Watcom/LE),
> then neither can yours.

That's right.

---
Forum admin

> - Don't call the first value "UPX version". Yes, it's the header data
> called "version", but it doesn't contain the version of the UPX program
> that compressed the file. I would rather call it the UPX file format
> version.

Firstly I called it "UPX header version". I'll have to look into my e-mails from László Molnár.

> - UPX lists a compressed size of 148 byte more than UPXINFO. I suppose

Compressed length means real data. Of course, this doesn't include any headers or stubs.

> that's the size of the header and decompression stub. (My binary is
> compressed as DOS .COM...) Although I agree the compressed size of the
> real program is also useful, UPXINFO should additionally list the
> stub/header size.

If I'll find a proper solution for all cases, it will be included.

---
Forum admin

> > 1). Shouldn't the help screen contain either a URL (e.g.
> > http://www.bttr-software.de/) or at least your e-mail
> > address?
>
> No. That's left to the manual. I think search results for "bttr software"
> are sufficient: http://www.google.com/search?q=bttr+software

You're assuming a computer is always connected to the Net. Besides, planning on migrating URLs anytime soon? Didn't think so.

> > 2). What, no LFN support? Aren't there Pascal units around that can
> handle
> > that? (At worst just use int 21h,7160h to convert LFN to SFN.)
>
> LF-what? Do you really need this? It will "blow" the binary by
> probably 100 bytes.

No, I don't majorly need it, but it'd be nice. Besides, 1). you're already over 4k, so a tiny drop more probably won't increase the used cluster size any (won't waste any "real" space that you aren't already using), and 2). SFN aliases are not 100% guaranteed to exist for all files (e.g. I copied a file to NTFS from some Linux distro recently, and while most modern distros support NTFS r/w fine, this one didn't create a SFN alias, so I had to ZIP/UNZIP it just to create one). And yes, I'm aware that TP55 doesn't natively support inline asm, but it can't be that hard to workaround, can it? (Inline emit raw bytes for the machine code? Isn't that what people did before TP6?)

> > > 1). Shouldn't the help screen contain either a URL (e.g.
> > > http://www.bttr-software.de/) or at least your e-mail
> > > address?
> >
> > No. That's left to the manual. I think search results for "bttr
> software"
> > are sufficient: http://www.google.com/search?q=bttr+software
>
> You're assuming a computer is always connected to the Net. Besides,

Then please tell me, why you suggest to provide a URL or even an e-mail address, if the user's computer is not connected to the Internet.

> planning on migrating URLs anytime soon? Didn't think so.

Sorry, I don't understand.

> > LF-what? Do you really need this? It will "blow" the binary by
> > probably 100 bytes.
>
> No, I don't majorly need it, but it'd be nice. Besides, 1). you're already
> over 4k, so a tiny drop more probably won't increase the used cluster size
> any (won't waste any "real" space that you aren't already using), and 2).

If aPACK compresses the updated executable tight enough.

> SFN aliases are not 100% guaranteed to exist for all files (e.g. I copied

UPXINFO was made for DOS, where SFNs always exist.

> a file to NTFS from some Linux distro recently, and while most modern
> distros support NTFS r/w fine, this one didn't create a SFN alias, so I
> had to ZIP/UNZIP it just to create one). And yes, I'm aware that TP55

But I don't want to work around your buggy Linux. Why not use DOS?

> doesn't natively support inline asm, but it can't be that hard to
> workaround, can it? (Inline emit raw bytes for the machine code? Isn't
> that what people did before TP6?)

Yes, and I'm already doing this for some parts of the source code.
What's a safe way to detect, if LFNs are available?

---
Forum admin

> Yes, and I'm already doing this for some parts of the source code.
> What's a safe way to detect, if LFNs are available?

I think Int21.71A0 should work well. Do "stc" before the "int" opcode, because DOSes without any Int21.71 functions will leave CF unchanged and set al to 0. If the flags are NC, test the returned bx's bit 14 (4000h). If it's 1, LFNs should be supported.

---
l

> I think Int21.71A0 should work well. Do "stc" before the "int" opcode,
> because DOSes without any Int21.71 functions will leave CF unchanged and
> set al to 0. If the flags are NC, test the returned bx's bit 14 (4000h).
> If it's 1, LFNs should be supported.

I found this code from the Free Pascal RTL (system.pp). And I think, it's buggy, because it assumes, that LFNs on other drives are available too, if drive C: already supports these?!

function CheckLFN:boolean;
var
  regs     : TRealRegs;
  RootName : pchar;
begin
{ Check LFN API on drive c:\ }
  RootName:='C:\';
  syscopytodos(longint(RootName),strlen(RootName)+1);
{ Call 'Get Volume Information' ($71A0) }
  regs.realeax:=$71a0;
  regs.reales:=tb_segment;
  regs.realedi:=tb_offset;
  regs.realecx:=32;
  regs.realds:=tb_segment;
  regs.realedx:=tb_offset;
  regs.realflags:=carryflag;
  sysrealintr($21,regs);
{ If carryflag=0 and LFN API bit in ebx is set then use Long file names }
  CheckLFN:=(regs.realflags and carryflag=0) and (regs.realebx and $4000=$4000);
end;

---
Forum admin

> Yes, and I'm already doing this for some parts of the source code.
> What's a safe way to detect, if LFNs are available?

FPC's way (system unit)

function CheckLFN:boolean;
var
regs : TRealRegs;
RootName : pchar;
begin
{ Check LFN API on drive c:\ }
RootName:='C:\';
syscopytodos(longint(RootName),strlen(RootName)+1);
{ Call 'Get Volume Information' ($71A0) }
regs.realeax:=$71a0;
regs.reales:=tb_segment; //seg(rootname)
regs.realedi:=tb_offset; // ofs(rootname);
regs.realecx:=32;
regs.realds:=tb_segment; //seg(rootname)
regs.realedx:=tb_offset; //ofs(rootname)
regs.realflags:=carryflag;
sysrealintr($21,regs);
{ If carryflag=0 and LFN API bit in ebx is set then use Long file names }
CheckLFN:=(regs.realflags and carryflag=0) and (regs.realebx and $4000=$4000);
end;

Note that there are 32-bitisms( copytodos, sysrealintr instead of dos() and real(e) prefixes of registers), but that should be easy to remedy.

Maybe this should be combined with a drive check first (in case C:\ is not valid? like iirc an IDE zipdisk and a shell command to another drive can have this?)

> > I think Int21.71A0 should work well. Do "stc" before the "int" opcode,
> > because DOSes without any Int21.71 functions will leave CF unchanged
> and
> > set al to 0. If the flags are NC, test the returned bx's bit 14
> (4000h).
> > If it's 1, LFNs should be supported.
>
> I found this code from the Free Pascal RTL (system.pp). And I think, it's
> buggy, because it assumes, that LFNs on other drives are available too, if
> drive C: already supports these?!

Hmm, I just posted the same. Yes, and moreover it assumes C: is valid, which isn't always the case IIRC, see other post.

But do you really want to parameterise the entire RTL's I/O functions with a lfnsupport per drive? Isn't that a bit too much?

(specially if you are worried about 100 bytes exe size)

> > Yes, and I'm already doing this for some parts of the source code.
> > What's a safe way to detect, if LFNs are available?
>
> FPC's way (system unit)

[snip]

see my previous message

---
Forum admin

> But do you really want to parameterise the entire RTL's I/O functions with
> a lfnsupport per drive? Isn't that a bit too much?

Fortunately that's not needed in my special case.

---
Forum admin

> > I think Int21.71A0 should work well. Do "stc" before the "int" opcode,
> > because DOSes without any Int21.71 functions will leave CF unchanged
> and
> > set al to 0. If the flags are NC, test the returned bx's bit 14
> (4000h).
> > If it's 1, LFNs should be supported.
>
> I found this code from the Free Pascal RTL (system.pp). And I think, it's
> buggy, because it assumes, that LFNs on other drives are available too, if
> drive C: already supports these?!

Yes, it's buggy. Although DOSLFN (and Windows?) provides a "Fallback"-Mode for drives that support only SFNs (redirect LFN functions to SFN functions) you can't assume this is always true. RxDOS f.e. doesn't have any "Fallback"-Mode. (On the other hand, above check doesn't work in the old RxDOS 7.1.5 anyway because of a serious misunderstanding...)

Just check the LFN API for each drive you're operating on.

---
l

> > You're assuming a computer is always connected to the Net. Besides,
>
> Then please tell me, why you suggest to provide a URL or even an e-mail
> address, if the user's computer is not connected to the Internet.

It's for people who do have the Internet, of course. Whatever, not really important I guess, probably no critical bugs to report anyways.

> > planning on migrating URLs anytime soon? Didn't think so.
>
> Sorry, I don't understand.

Is your site changing addresses anytime soon? I hope not!

> > SFN aliases are not 100% guaranteed to exist for all files (e.g. I
> copied
>
> UPXINFO was made for DOS, where SFNs always exist.

Yes, but at least two DOSes (RxDOS, ROM DOS) support LFNs natively, right? Even DR-DOS (at one time) had a beta FAT32 LFN driver of some sort (probably recalled due to patent worries, bah).

> > a file to NTFS from some Linux distro recently, and while most modern
> > distros support NTFS r/w fine, this one didn't create a SFN alias, so I
> > had to ZIP/UNZIP it just to create one). And yes, I'm aware that TP55
>
> But I don't want to work around your buggy Linux. Why not use DOS?

That's not a bug. And I think even Windows allows you to turn off the DOS compatibility names (supposedly faster?). Strange how Windows can be considered both good and bad for the same thing: compatibility. (The people who say, "Compatibility slows us down!" are the same ones who say, "HLLs are the future ... besides, cpus are fast enough!")

> What's a safe way to detect, if LFNs are available?

As mentioned, I think DJGPP's libs use int 21h,71A0h in various places. So I'd assume that's a good way. Take a look at IO95 (written for C) if you want a second opinion.

> Yes, but at least two DOSes (RxDOS, ROM DOS) support LFNs natively, right?

You're better saying "at least one DOS". RxDOS's current LFN code doesn't really work and supports only some of the Int21.71 functions (and some of these supported functions are not very well written). And that just besides all the other RxDOS bugs. Don't consider using it for anything serious right now.

> Even DR-DOS (at one time) had a beta FAT32 LFN driver of some sort
> (probably recalled due to patent worries, bah).

I think there was one DRFAT32 driver and another DRLFN driver. (All versions I know are betas.) They however had a special interface so if used together, DRLFN provided LFNs on DRFAT32 partitions as well.

> > But I don't want to work around your buggy Linux. Why not use DOS?
>
> That's not a bug.

Probably the bug isn't in that Linux driver, but rather in the other NTFS driver. It should translate LFNs without SFNs "on the fly", that is, if anyone requests SFNs (applications inside NTVDM or whatever), create them "virtually".

---
l

> > > planning on migrating URLs anytime soon? Didn't think so.
> >
> > Sorry, I don't understand.
>
> Is your site changing addresses anytime soon? I hope not!

No.

> > UPXINFO was made for DOS, where SFNs always exist.
>
> Yes, but at least two DOSes (RxDOS, ROM DOS) support LFNs natively, right?

Yes, but there still is a SFN for every LFN.

> > > a file to NTFS from some Linux distro recently, and while most modern
> > > distros support NTFS r/w fine, this one didn't create a SFN alias, so
> I
> > > had to ZIP/UNZIP it just to create one). And yes, I'm aware that TP55
> >
> > But I don't want to work around your buggy Linux. Why not use DOS?
>
> That's not a bug.

Depends on your point of view.

> As mentioned, I think DJGPP's libs use int 21h,71A0h in various places. So
> I'd assume that's a good way. Take a look at
> IO95
> (written for C) if you want a second opinion.

Thanks for the URL! It's a pitty Steffen left FreeDOS.

---
Forum admin

> > > Yes, and I'm already doing this for some parts of the source code.
> > > What's a safe way to detect, if LFNs are available?
> >
> > FPC's way (system unit)
>
> [snip]
>
> see my previous message

(I wrote that post at work, and got interrupted for more than an hour somewhere in the middle, hence the double post)

> What, no LFN support? Aren't there Pascal units around that can handle
> that?

Found one: DOS70P20.ZIP

DOS70 version 2.0 - February 1998
----------------------------------

DOS70 is a powerful, easy-to-use
Turbo Pascal unit, implementing
MS-DOS 7.x extensions and file
handling routines.
Features:
- over 40 long filenames functions
and procedures
- over 10 functions and procedures
implementing virtual machine
services
- over 20 general MS-DOS functions
and procedures
- text file interface
- complete, comprehensive manual
- DOS 7.1 specific functions.
- full source & examples included.
- a new unit using PChar strings is
present in this package.
- compiles with Turbo/Borland Pascal
5.5/6/7.0 for Dos/Windows.

> > What, no LFN support? Aren't there Pascal units around that can handle
> > that?
>
> Found one: DOS70P20.ZIP

I already knew that unit and I don't like it very much.

But I didn't forget your feature request. First function is ready for use in UPXINFO. Two more to follow.

---
Forum admin

> > > What, no LFN support? Aren't there Pascal units around that can handle
> > > that?
> >
> > Found one: DOS70P20.ZIP
>
> I already knew that unit and I don't like it very much.

Why not? If it works, it works. It even claims to work with (free) TP 5.5. Oh well, whatever.

> But I didn't forget your feature request. First function is ready for use
> in UPXINFO. Two more to follow.

Okay, no pressure.

> > I already knew that unit and I don't like it very much.
>
> Why not? If it works, it works.

It doesn't work (always).

> Okay, no pressure.

I'm currently very short of time. I'll probably release UPXINFO 1.0 w/o support for LFNs and leave adding that to others.

Or will I convert UPXINFO to NASM completely? I don't know...

---
Forum admin

> > > I already knew that unit and I don't like it very much.
> >
> > Why not? If it works, it works.
>
> It doesn't work (always).

Does Win2k have LFN bugs in that regard? I've heard something like that. Maybe NTLFN helps?? (Dunno.) Anyways, it's not THAT important.

> Or will I convert UPXINFO to NASM completely? I don't know...

Does TP have a way to output .ASM or do you have to manually disassemble it? I was actually (half-jokingly) going to suggest to make it portable to be able to be compiled in the new FreePascal, which supports LFN natively (as all DJGPP-ish programs do). And that can output .ASM, albeit 386+, which may or may not be what you want. Granted, it won't be a 4 kb .EXE anymore, but you could (drum roll please) ... UPX it!!

> > It doesn't work (always).
>
> Does Win2k have LFN bugs in that regard?

No. The unit is just "stupid".

> Maybe NTLFN helps?? (Dunno.) Anyways, it's not THAT important.

No, thanks!

Q6 Will this work under Windows 2000 ?
A This package works only under Window NT 4.0 be it Workstation or Server

> Does TP have a way to output .ASM

No.

> or do you have to manually disassemble it?

Yes.

But I decided to stay with TP and build additional functions as .OBJ files using small R86.EXE (part of free LSI C-86 trial). TP is able to link with external .OBJ files then.

> I was actually (half-jokingly) going to suggest to make it portable to
> be able to be compiled in the new FreePascal, which supports LFN natively
> (as all DJGPP-ish programs do). And that can output .ASM, albeit 386+,
> which may or may not be what you want. Granted, it won't be a 4 kb .EXE
> anymore, but you could (drum roll please) ... UPX it!!

Sorry, but I want to fit this tool to a single floppy.

---
Forum admin

> > I was actually (half-jokingly) going to suggest to make it portable to
> > be able to be compiled in the new FreePascal, which supports LFN
> natively
> > (as all DJGPP-ish programs do). And that can output .ASM, albeit 386+,
> > which may or may not be what you want. Granted, it won't be a 4 kb .EXE
> > anymore, but you could (drum roll please) ... UPX it!!
>
> Sorry, but I want to fit this tool to a single floppy.

I don't see why this wouldn't be possible. Unless you still use single sided 5 25" floppies.

> I don't see why this wouldn't be possible.

But it would still require a 386.

> Unless you still use single sided 5 25" floppies.

Floppies are huge. I use 32K (not "M"!) Bee cards.

---
Forum admin

> > I don't see why this wouldn't be possible.
>
> But it would still require a 386.

Yes. With a floppy. Probably currently a working floppy is worth more.

> > Unless you still use single sided 5 25" floppies.
>
> Floppies are huge.

Yes, ranging from 3.5 to 5.25 in some esoteric unit.

> I use 32K (not "M"!)
> Bee
> cards.

Yes, and I use half bits punched with a tootpick in toiletpaper. Really.

> > Floppies are huge.
>
> Yes, ranging from 3.5 to 5.25 in some esoteric unit.

Smile when you say that, pardner.

> Yes, and I use half bits punched with a tootpick in toiletpaper. Really.

I won't ask about the reader.

> Now I "finished" that project and would



> Trivia: UPXINFO.EXE has been compressed using aPACK, not UPX.

see shot ...



Obvious "ToDo" :

- Add support for APACK, PKLITE, ...

Rugxulo wrote:

> 2). What, no LFN support?

Seems to be a feature.

> Aren't there Pascal units around that can handle that?
> (At worst just use int 21h,7160h to convert LFN to SFN.)

I still don't see a LFN enabled DOS.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Obvious "ToDo" :
>
> - Add support for APACK, PKLITE, ...

Denied. Why do you think I named this tool UPXINFO?

---
Forum admin

> > Trivia: UPXINFO.EXE has been compressed using aPACK, not UPX.
>
> see shot ...

What is it supposed to show? That UPXINFO finds no UPX info where there is in fact no UPX info to be found? If so, thank you.

> Obvious "ToDo" :
>
> - Add support for APACK, PKLITE, ...

Why?

> I still don't see a LFN enabled DOS.

ROM-DOS

> > Obvious "ToDo" :
> >
> > - Add support for APACK, PKLITE, ...
>
> Denied. Why do you think I named this tool UPXINFO?

You should just rename it to APACKPKLITEUPXANDOTHERS-INFO

---
l

> Rugxulo wrote:
>
> > 2). What, no LFN support?
>
> Seems to be a feature.

I still think making the source portable enough to compile via FreePascal would solve that problem (at least, for those interested) while keeping the main version .EXE small (TP55). Marco, you wanna volunteer?

> I still think making the source portable enough to compile via FreePascal
> would solve that problem (at least, for those interested) while keeping
> the main version .EXE small (TP55). Marco, you wanna volunteer?

Current source code compiles to 49K (no compression) with FPC 2.2.2 and supports LFNs. I think, that's OK for a 32-bit HLL thing. Still have to write some source code comments and a short manual.

---
Forum admin

> Current source code compiles to 49K (no compression) with FPC 2.2.2 and
> supports LFNs. I think, that's OK for a 32-bit HLL thing. Still have to
> write some source code comments and a short manual.

Gold medal for you!!

> Gold medal for you!!

You find my postal address by looking at the imprint.

---
Forum admin

I uploaded a new test release as upxdump-26-aug-2008.zip.

Archive contains a 16-bit TP55 binary compressed with aPACK (5.27K) in folder "DOS16". In folder "DOS32" you will find a 32-bit FP222 binary compressed with UPX (21.8K). Archive still lacks source code and documentation.

Changes:
* As you can already see from this post's subject or the file name, this baby got a new name.
* Detection algorithm changed. Now I use a nearly 1:1 C-to-Pascal translation of PackHeader::fillPackHeader().
* Support for big-endian files added. This has been tested on the UPX for "Atari TOS/MiNT" binary only.
* Some messages adjusted. Mostly on user request by Christian Masloch.
* LFN support added by using Free Pascal. On user request by Rugxulo.

---
Forum admin

> I uploaded a new test release as
> upxdump-26-aug-2008.zip.
>
> Archive contains a 16-bit TP55 binary compressed with aPACK (5.27K) in
> folder "DOS16". In folder "DOS32" you will find a 32-bit FP222 binary
> compressed with UPX (21.8K).

Very useful, nice job!

> Changes:
> * As you can already see from this post's subject or the file name, this
> baby got a new name.

Normally you can't rename a baby already born, but I'll let it slide.

> * LFN support added by using Free Pascal. On user request by Rugxulo.

Now all we have to do is add a mention of it to here.

> Denied.

Maybe add a "recovery" feature allowing to fix and decompress "hacked" (RTFL - see license of UPX) executables as next ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Maybe add a "recovery" feature allowing to fix and decompress "hacked"
> (RTFL - see license of UPX) executables as next ?

Sorry, but what do you mean?

---
Forum admin

> Very useful, nice job!

Thanks! I'm currently writing a short user manual using Halibut.

> > * LFN support added by using Free Pascal. On user request by Rugxulo.
>
> Now all we have to do is add a mention of it to
> here.

Sorry, I don't see the point.

---
Forum admin

> > Maybe add a "recovery" feature allowing to fix and decompress "hacked"
> > (RTFL - see license of UPX) executables as next ?
>
> Sorry, but what do you mean?

Some people violate the UPX license by making the resulting .EXE not unpackable. DOS386 apparently wants you to be able to heuristically find such .EXEs and make 'em unpackable again.

> > > * LFN support added by using Free Pascal. On user request by Rugxulo.
> >
> > Now all we have to do is add a mention of it to
> > here.
>
> Sorry, I don't see the point.

Irony: it's basically an article against the need for UPX re: FreePascal, but your tool is written in FreePascal to identify UPX'd binaries.

EDIT: Typo.

DOSferatu wrote:

(nothing yet)

Rugxulo wrote:

> Some people violate the UPX license by making the resulting .EXE
> not unpackable. DOS386 apparently wants you to be able to
> heuristically find such .EXEs and make 'em unpackable again.

Incredible: someone did understand my post

> Irony: it's basically an article against the need for UPX re: FreePascal,
> but your tool is written in FreePascal to identify UPX'd binaries.

To identify the evil

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> DOSferatu wrote:
>
> (nothing yet)

But he released a "Pre-PreRelease" version (no sound, no multiplayer) of his top-view 2D shooter XPYDERZ. Site is in German only, but archive also contains an English README.

> Rugxulo wrote:
>
> > Some people violate the UPX license by making the resulting .EXE
> > not unpackable. DOS386 apparently wants you to be able to
> > heuristically find such .EXEs and make 'em unpackable again.
>
> Incredible: someone did understand my post

I won't add this feature, because I just don't have a need for. After releasing UPXDUMP's source code, you're welcome to submit a patch for adding that.

---
Forum admin

> > DOSferatu wrote:
> >
> > (nothing yet)
>
> But he released a "Pre-PreRelease" version (no sound, no multiplayer)
> of his top-view 2D shooter XPYDERZ. Site is in German only, but archive also
> contains an English README.

Correct, all the files from Xpyderz are dated Aug. 12, 2008. He's got some older cool stuff too (Centipede from 2005, PONG, PICS8050, FAQREAD, THEORY) but all without source. Anyways, I particularly like "Theory of Clockwork" (reminds me of I, Robot) and VECCHARS is like text from Major Havoc. Heck, even Xpyderz looks like Vindicators. (Guess he likes Atari, heh.) So yeah, he's obviously a fan of DOS (and BP7, in particular). BTW, the ASM86.GER FAQ looks very very useful (even if some of it is already well-documented elsewhere). Of course, I guess it'd be more useful if I understood German. (But at least the 8086-586 asm timings + pseudocode seems nicely done. I think the optimizations part could be greatly increased, but that'd be hard to fully research correctly.)

P.S. Google Language Tools is your friend (well, mine at least).