THE ORIGINAL APPCOMPAT (June 2013)

aka solving a 20 years old (for me) mystery.

DOS v5.0 introduced the concept of DOS loading "high". That is, into the high memory area - that special 64kb area at the top of the first megabyte of memory.

As a result of this change, programs now loaded to a much lower address in memory than they did before. This change also exposed a previously unknown bug that exists in the code produced by certain versions of the Exepack utility, or Link* with the "/EXEPACK" option. There were a number of workarounds that involved forcing an allocation of 64kb (e.g. using loadfix) to ensure that the program loaded above the 64kb block - the usual "black box" solution.

What made me think to solve it now?

I was working on a patch for DOSBox. The program worked in DOSBox if loadfix was run first, but it worked in all cases in real DOS. Ah, the mystery deepens.

What's more interesting is that I saw the issue only by luck. I needed EMM386.EXE to be running and providing access to the Upper Memory Block area; I needed to load my debugger into the Upper Memory Block area; I needed to be debugging a program that was so large that it would not fit into the Upper Memory Block area along with the debugger; and, of course, I needed that program to be packed by ExePack.

It wasn't likely, but it happened.

So, on the left is the code as it would be found on disk. On the right is the code that I saw on that day, 20 years ago, in my debugger (and shortly thereafter, I found two other variations).

0032MOVBX,ES............0032PUSHES
0034MOVAX,DS............0033MOVAX,DS
0036DECAX............0035DECAX
0037MOVDS,AX............0036MOVDS,AX
0039MOVES,AX............0038MOVES,AX
003BMOVDI,000F............003AMOVDI,000F
............003DPUSHDI
003EMOVCX,0010............003EMOVCX,0010
0041MOVAL,FF............0041MOVAL,FF
0043REPZSCASB............0043REPZSCASB
0045INCDI............0045INCDI
0046MOVSI,DI............0046MOVSI,DI
0048MOVAX,BX............0048POPDI
............0049POPAX
004ADECAX............004ADECAX
004BMOVES,AX............004BMOVES,AX
004DMOVDI,000F............004DMOVCX,0204
0050MOVCL,04
0052MOVAX,SI............0050MOVAX,SI
0054NOTAX............0052NOTAX
0056SHRAX,CL............0054SHRAX,CL
0058JZ0063............0056JZ006B
005AMOVDX,DS............0058MOVDX,DS
005CSUBDX,AX............005AORSI,-10
005EMOVDS,DX............005DSUBDX,AX
0060ORSI,-10............005FJNB0069
0063MOVAX,DI............0061NEGDX
0065NOTAX............0063SHLDX,CL
0067SHRAX,CL............0065SUBSI,DX
0069JZ0074............0067XORDX,DX
006BMOVDX,ES............0069MOVDS,DX
006DSUBDX,AX............006BXCHGSI,DI
006FMOVES,DX............006DPUSHDS
0071ORDI,-10............006EPUSHES
............006FPOPDS
............0070POPES
............0071DECCH
............0073JNZ0050
0074LODSB............0074LODSB
0075MOVDL,AL............0076XCHGDX,AX
0077DECSI............0077DECSI
0078LODSW............0078LODSW
0079MOVCX,AX............0079MOVCX,AX
007BINCSI............007BINCSI
007CMOVAL,DL............007CMOVAL,DL
007EANDAL,FE............007EANDAL,FE
0080CMPAL,B0............0080CMPAL,B0
0082JNZ008A............0082JNZ0089
0084LODSB............0084LODSB
0085REPZSTOSB............0085REPZSTOSB
0087JMP0090............0087JMP008F
0089NOP
008ACMPAL,B2............0089CMPAL,B2
008CJNZ00F9............008BJNZ00F9
008EREPZMOVSB............008DREPZMOVSB
0090MOVAL,DL............008FXCHGDX,AX
0092TESTAL,01............0090TESTAL,01
0094JZ0050............0092JZ004D
............0094NOP
............0095NOP

Wow, quite different. What happened there?

Well, DOS went and rewrote that unpacking code for me, on-the-fly, as the file was loaded into memory.

That's right - DOS went and "hot-patched" my code to avoid a bug. No warning, and no explanation - at the time, I didn't have an Internet connection, but it seems likely that even if I had, it would never have occurred to me to search for an answer. Or if I did, the answer would not have been documented anywhere yet, anyway.

The mystery is finally solved. As for DOSBox, you just have to use loadfix, but now you know why.

(*) Specifically, Link 3.x where x is 51 or larger, all 4.x, and 5.x where x is 15 or smaller.

Copyright (c) 2013 Peter Ferrie
All rights reserved

This site is hosted by 000webhost.com



Free web hostingWeb hosting