for crafting MSDOS .exe files, with form@fix

This file is valuable for crafting MSDOS .exe files, with form@fix. First frame this, followed by a mnemonic file, or a few -- like fix80x86.htm as well as 8086.htm (or, 80386.htm, depending on the specific application).

//	\F "fixDX.htm"     \\this file
//	\F "fix80x86.htm"  \\the common subset of mnemonics for 8086 & 80386.
//	\F "fix8086.htm"   \\or, 80386.htm -- those specific to 8086 or 80386.

If the files are not in the folder where form@fix is running, specify the target folder, too. For example,

//	\F "c:\Program files\form@fix\fixDX.htm"	\\this file
//	\F "c:\Program files\form@fix\fix80x86.htm"
//	\F "c:\Program files\form@fix\fix8086.htm"	\\or, 80386.htm



The MSDOS .exe files almost always suppose a two-byte int format. But if your form@fix processor is not the fixDX, the default int width may be something else. For fixWin, that is 4-bytes. Therefore, what we would like to have first, is the certainty of what we suppose. Set the format-width, as well as the remz-offset, manually.

\r rOffset0	\r MSDOS	\r MSDX


//To go forward more than the width of ARZ? No way.
//	Therefore, locating at the byte following ARZ.
\a+ 0xFFFFFFF	\r widthOfARZ


//From there, walk back 9 bytes,
//	because the platform-info is 9-bytes wide. 
\a- 9


//for MSDOS .exe files, default format is WORD,
\r1 defaultWidth	\a+1 1 2


\r4 remzOffset	\a+4 4 0xffffffc0	\\.exe running offset is -40
			\a+4 4 0xffffffff	\\filling



For scratch work, not written to the .exe file but useful toward that, we may allocate the piece of memory beyond a point. Set that at a point beyond the length of your final .exe, for the two portions not to overlap. I like to set that at 0x5000 (that is, 20480 bytes). Modify this (to less, or more), depending on the specific application.

\a 0x5000	\\toward  form@fix@RunTime_Max




format specifying

For byte data-or-remz,

\r =
\r =1	\\the platform =1
\r attr=	\\byte-width, although flexible for the future
\\r+ is 0    \a+1 4
\\width is 1 \a+1 1   1   \a+1 3

For padding from byte-width to int-width

\r fiz	\*= 1 0    \\fill with zeroes, if positive
\r -fiz	\*= 1 0xFF \\fill with 0xFF to sign-extend, if negative 

For word data-or-remz,

\r =.	\\the default int-width is this.
\r =2	\\the platform is =2
\\r+ is 0		\a+1 4
\r int	
\\width is 2	\*= 2 0 0 0

For dword data-or-remz,

\r =4	\\the platform is =4
\\r+ is 0    \a+1 4
\\width is 4 \*= 4 0 0 0

as was

In case, we would refer to the int-width of the fix.exe that is processing this file,

//ARZ.Zero, the [platform.r+]-free offset.
//	Purely, the 0th byte of ARZ, that is.

\r RZ
\\r+ is 0    \a+1 4
\\width is 0 \a+1 4

This default format is useful for a remz (or, remz-list) like for frag. Good, because otherwise frag would have to acept only a single width for all platforms. For coding in fixDX, that is a waste to accommodate the double-width of Win32. Not to mention that, for a future support of Win64, the thing would get totally problematic.




A few run-time only conveniences. Although referrable while fixing the .exe, do not refer to such a run-time-only remz, from within your .exe, because that would be what is known as dangling-pointer problem.

\r [?]	\'?'	\*= 0	\\frag for not returning a result
\r {/}	\*=4 0	\\empty set

f0 is only a fancier name, to fill with zeroes, at byte-width, e.g: with \a+f0 20 to fill with 20 zeroes. i.e: "1" is the fill-width, not the filler-value. Filler is zero, if not explicitly specified.

\r f0	\*=4 1



A few for conveniently referring to a macro type. Macro-flag is 0x80. The letter 'F' plus 0x80 is 0xC6.

\r mid80.macro
	\a 0xD0	\r Pm	\\Petri transition
	\a 0xD5	\r Um	\\UCLA control-node
	\a 0xC6	\r Fm	\\Nutt F-transition
	\a 0xCA	\r Jm	\\Nutt J-transition
	\a 0xD4	\r Tm	\\Nutt T-transition
	\a 0xD8	\r Xm	\\Nutt X-transition
	\a 0xD9	\r Ym	\\Nutt Y-transition
	.\a 0xCB	\r Km
	\a 0xC4	\r Dm	\\Danthine mod for  X-transition
	\a 0xE2	\r bm	\\binary loc
	\a 0xF0	\r pm \\Petri loc
\a mid80.macro
\r- mid80.macro



\r width(formal)
	\*RZ 0 0 0 0 0 0 0 0 0 0
\* width(formal)\-f
\a width(formal)
\a+ 1
\*= 0 0 0	\\pad width(formal) to four-bytes

For a frozen@mid80 style fragging, for form@fix, we may think a single-transition "net." This T-transition is running the frag (predicate) that is to follow immediately after the "\F@ @FragFun" statement.

\r @FragFun
	

\'\\r .fm'

	//allocating the formal-list width, for returning-to afterward
	\'\\a+ width(formal)'

	\'\\r b1\\\'b\'\\*= 1\\*attr= 0'
	\'\\r b2\\\'b\'\\*= 2\\*attr= 0'


	\'\\r .L'
		\'\\*RZ b1 b2 0'


	\'\\r .M0'
	 	\'\\*RZ b1\\*= 1'
		\'\\*RZ 0'


	\'\\r a1'
		\'\\\'T\'\\*= 1'	\\T1
		\'\\*RZ b1 b2'
		\'\\*RZ {/}'	\\ immediately finishing
		\'\\r .t\\*RZ 0'	\\ activity/transition procedure

	\'\\r .A'
		\'\\*RZ a1 0'


	\'\\r .z'
	\'\\a .fm'
	\'\\*RZ .A {/} {/} .M0 .L .L {/} {/}' \\formal net.
	\'\\a .t\\*RZ .z'
	\'\\a .z'


\'\\r/ .fm'
\'\\r- .fm'
\*= 0



To tell MS-DOS, where to start running the .exe, the next frame is handy. This frame is in a null-terminated array. Notice that, the a \\ within a quoted range, is not for commentary. The quote will replace that. i.e: They are not double.

\r fixStArt.htm
   \'\\r! z\\a rFixStArt\\* z\\a z'
   ..\'\\*= 0xe 0x1f'	\\let DS=CS
   \'\0'
//Frame this, where wanted, with a	\F@ fixStArt.htm



For the DX format, assume that the file-offset is at the first byte of ARZ. Thus, rARZ is informative enough for the filelength of exe@dos.

\r fixFinish
	//cf. platform.fix for DX fixing.
	\'\\r rARZ\\*RZ rARZ'
	\'\\F* finishExe'	
	\'\0'	

//rARZ is reporting the running remz-to-ARZ, as set by fixFinish.

\r finishExe	\F@ @FragFun
	\'rARZ / 512 + 1 =@ rwExePageCount'
	\'	rARZ & 511  =@ rwExeLastPageByteCount ? .'
	\'512  =@ rwExeLastPageByteCount'
	\'	rwExePageCount - 1 =@ rwExePageCount\0'



\r form@fix@RunTime_Max  \\to keep in mind, the high-ARZ remz



\a 0

\a rOffset0
\'MZ'       \\ MSDOS signature at file start.
\r rwExeLastPageByteCount
\*=. 512    \\ Bytes on last page of file
\r rwExePageCount
\*=. 8      \\ Pages in file (Page==512bytes)
\*=. 0      \\ Relocations
\*=. 4      \\ Size of header in paragraphs 
\*=. 0      \\ Minimum extra paragraphs needed
\*=. 0xffff \\ Maximum extra paragraphs needed
\*=. 0      \\ Initial (relative) SS value
\*=. 0xffee \\ Initial SP value
\*=. 0      \\ Checksum
\r rFixStArt
\*=. 0      \\ Initial IP value
\*=. 0      \\ Initial (relative) CS value
\*=. 0      \\ File address of relocation table
\*=. 0      \\ Overlay number
\a+1 8      \\ Reserved. Zero-filled.
\*=. 0      \\ OEM identifier (for e_oeminfo)
\*=. 0      \\ OEM information; e_oemid specific
\a+1 20     \\ Reserved. Zero-filled.
\a+1 4     \\ address of new exe header


Forum: . . (Fair Menu . . . . . Fault Report? . . . . . Remedy for your case . . . . . Noticed Plagiarism?)

Referring#: 2.1
this file, mid80.net/formFix/fixDX.htm, was formerly http://www.geocities.com/ferzenr/fixDX.htm
Last-Revised (text) on Aug. 18, 2008
Written by: Ahmed Ferzan/Ferzen R Midyat-Zila (or, Earth)
Copyright (c) 2003, 2005, 2008 Ferzan Midyat. All rights reserved.