On Mon, 30 Jun 2014 00:20:29 -0400, William Gallant
Post by William Gallant
I want to convert a program called "DOS Sharp APL/PC".
Ever heard of it? Also packaged as APLISW, and APLIPC.
These are IBM System/370 DOS emulators which run actual
SHARP APL for Mainframe images stored a binary file.
Would either of these two help?
Post by William Gallant
The DEBUGX project is just an idea i have been throwing
around in my head. Hand-translating is probably the best
idea since the emulator is a 48k DOS program which is
maybe 1-quarter data. Why would i do this? Maybe make
the emulator faster?
You're going to find that a few hundred bytes is a large
task if hand converting without the original source. If
it's compiled and optimized C code instead of assembled
assembly code, forget it. You'll never figure it out.
Is it compiled C code? Do you even know? I'd suspect
it's C code, or some type of compiled code, since it
came from a mainframe.
You have to disassemble piece by piece. The x86 opcode
map is packed, so there is no easy way to tell which
bytes you're supposed start disassembling from. You have
to disassemble based on the entry locations into the main
program and then called procedures and jumped or branched
to code blocks. You *can't* just pick any point or the
start of the file and dissassemble everything at once.
It doesn't work that way. After finding all the entry
and branch locations, you have to map those addresses to
code labels, map offsets to addresses, all manually.
You also have to separate data from code. Data will
disassemble as code, if you don't know it's not code.
So, you'll be tracking down *every* executable instruction
in the program.
Once you've created assembly source for the program, you
have to confirm it's the binary equivalent. Your assembler
is likely to encode certain instructions differently from
the original assembler used. The x86 has many encodings for
the same operations. This can produce huge differences
in the new binary, even when the code is 100% functionally
identical. But, once you've confirmed these are all correct,
you should be able to change the instruction sizes and recompile
large portions of the code for the different size without much
issue. However, anything dealing with segments or interrupts,
etc will likely have to be rewritten. You may have issues
with arithmetic too, being larger or with the sign bit, or
with clearing of upper registers, etc.
If you're going to do this, I'd recommend an assembler
which has a clean syntax and one where instruction syntax
for the disassembly is similar to the assembly. Believe
it or not, some differ enough that you *can't* feed the
disassembly directly back into the assembler. I'd suggest
NASM, even though it's not 100% with this either, but
it's better than many others.
But, I wouldn't try this with 48K. I recreated the assembly
source for two small projects. One project that had 3 files
totaling 6KB and another that was 3KB. It was quite a bit
of work. That was without rewriting instructions for one
mode to another.