Easily convert 16bit asm to 32bit with DEBUGX.COM?

Post by William Gallant
I have never found any 16bit to 32bit asm converters
( always told there is none ). My theory is to take a
16bit program and pass it through a modified DOS DEBUG
program such as Paul Vojta's DEBUGX.COM and spew
out 32bit. Does this seem possible?

Suppose, for the sake of argument, that you had such a converter. What
16-bit program do you have in mind that it would be useful to convert?

Best,
Frank

William Gallant

2014-06-30 04:20:29 UTC

Suppose, for the sake of argument, that you had such a converter. What
16-bit program do you have in mind that it would be useful to convert?

Best,
Frank

------
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.
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?

Frank Kotler

2014-06-30 07:02:41 UTC

William Gallant wrote:

...

Post by William Gallant
I want to convert a program called "DOS Sharp APL/PC".
Ever heard of it?

No. Is this it?

http://www.milinta.com/APL.html

They seem to have Windows and Linux versions, if so.

Post by William Gallant
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.
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?

Unlikely to be much faster just by converting it to 32-bit. As Johann
points out, there are memory model considerations. A dos program
probably depends on int 21h - a 32-bit version of it might run on DJGPP
or some other dos extender - pretty obsolete in itself. If you want to
make it faster, you'd probably want to use modern features which
probably aren't used in the 16-bit code. Hand-translating or rewrite
from scratch would probably be necessary. Maybe even skip 32-bit and go
straight to 64-bit. I've been hoping that was just a flash in the pan,
but it looks like it's catching on. :)

Best,
Frank

Rod Pemberton

2014-06-30 10:11:32 UTC

On Mon, 30 Jun 2014 03:02:41 -0400, Frank Kotler

Post by Frank Kotler
Unlikely to be much faster just by converting it to 32-bit.

That's another thread entirely.

But, on my AMD Phenom II 3.2Ghz, 16-bit real-mode (RM) code is so,
so, so, (utterance) slow, you wouldn't believe it. I'd swear they
dropped in an 8Mhz or 12Mhz 8086 core just for RM. My older
AMD X2 5600+ 2.8Ghz processor was thousands upon thousands of times
faster. Things that took a few seconds in RM DOS now take up to
15 minutes. I believe this is purely a processor issue, i.e.,
minimizing support for RM. It's fast once in protected mode,
be it Windows SE or Linux.

Wolfgang, have you seen this issue?

Rod Pemberton

Frank Kotler

2014-06-30 18:53:19 UTC

Post by Rod Pemberton
On Mon, 30 Jun 2014 03:02:41 -0400, Frank Kotler

Post by Frank Kotler
Unlikely to be much faster just by converting it to 32-bit.

That's another thread entirely.
But, on my AMD Phenom II 3.2Ghz, 16-bit real-mode (RM) code is so,
so, so, (utterance) slow, you wouldn't believe it.

Okay, I stand corrected.

Best,
Frank

wolfgang kern

2014-06-30 21:29:05 UTC

Post by Frank Kotler
Unlikely to be much faster just by converting it to 32-bit.

That's another thread entirely.
But, on my AMD Phenom II 3.2Ghz, 16-bit real-mode (RM) code is so,
so, so, (utterance) slow, you wouldn't believe it. I'd swear they
dropped in an 8Mhz or 12Mhz 8086 core just for RM. My older
AMD X2 5600+ 2.8Ghz processor was thousands upon thousands of times
faster. Things that took a few seconds in RM DOS now take up to
15 minutes. I believe this is purely a processor issue, i.e.,
minimizing support for RM. It's fast once in protected mode,
be it Windows SE or Linux.
Wolfgang, have you seen this issue?

Sorry, I cannot confirm that true-Real-Mode were slow on any of
my Phenom II's.
RM is still faster than PM especially when 16-bits are enough.
But heavy delayed legacy I/O could be found on all new boards.

Perhaps your RM-setup is corrupted ?

__
wolfgang

James Harris

2014-06-30 21:40:05 UTC

Post by Rod Pemberton
On Mon, 30 Jun 2014 03:02:41 -0400, Frank Kotler

Post by Frank Kotler
Unlikely to be much faster just by converting it to 32-bit.

That all sounds *far* too big a difference to be due to just the CPU. Have
you worked out exactly what takes a long time? Are normal non-IO,
non-trapping instruction streams slow? Could it be repeated trapping to SMM
which is slow? That is more likely to be caused by the machine emulating
hardware than by the CPU itself being slow to run RM code.

Post by Rod Pemberton
I believe this is purely a processor issue, i.e.,
minimizing support for RM. It's fast once in protected mode,
be it Windows SE or Linux.
Wolfgang, have you seen this issue?

For any on this ng who don't know, Wolfgang has commented in
alt.os.development that true RM is faster than 32-bit Pmode on the CPUs he
uses.

James

NimbUs

2014-07-01 10:51:52 UTC

wrote ...

Post by Rod Pemberton
But, on my AMD Phenom II 3.2Ghz, 16-bit real-mode (RM) code

is so,

Post by Rod Pemberton
so, so, (utterance) slow, you wouldn't believe it. I'd swear

they

Post by Rod Pemberton
dropped in an 8Mhz or 12Mhz 8086 core just for RM.

That all sounds *far* too big a difference to be due to just

the CPU.

I heartily concur. Sounds like a "bug" in the processor or, much
much more likely, user's settings and measurement processes...

Post by James Harris
you worked out exactly what takes a long time? Are normal non-

IO,

Post by James Harris
non-trapping instruction streams slow? Could it be repeated

trapping to SMM

Post by James Harris
which is slow? That is more likely to be caused by the machine

emulating

Post by James Harris
hardware than by the CPU itself being slow to run RM code.

SMM isn't likely to cause SUCH degradation, besides SMM is
active in all processor modes, not just during RM, so if that
were a buggy SMBIOS, the machine wouldn't work at all...

Post by Rod Pemberton
I believe this is purely a processor issue, i.e.,
minimizing support for RM.

Again, not likely to cause SUCH degradation. I know real mode is
being deprecated, but not to the point of slowing it
hundredfolds without anybody complaining, but you :)

How exactly do you set up your processor to test real mode
operation ? To me the most likely cause for 100x slower is
memory accesses, either or both the memory controller and MTRRs
(memory typing registers) and caches not properly initialised
by, what have you, BIOS, EFI ? My bet is on MTRRs. If they are
left at their default setting, all the memory is uncached and
that would produce the kind of utter slowness you have reported.
I should know, having played with truly unitialised processors
(no BIOS, no nothing), running own experimental code that I will
flash into mother-board's EPROM...

You could test this hypothesis by examining the contents of your
processor's MTRRs (as well as other interesting "architectural"
Machine Specific Registers).

Shall be interested to hear whatever you find out

--
NimbUs

James Harris

2014-07-01 21:10:22 UTC

Post by NimbUs
wrote ...

Post by Rod Pemberton
But, on my AMD Phenom II 3.2Ghz, 16-bit real-mode (RM) code

is so,

Post by Rod Pemberton
so, so, (utterance) slow, you wouldn't believe it. I'd swear

they

Post by Rod Pemberton
dropped in an 8Mhz or 12Mhz 8086 core just for RM.

That all sounds *far* too big a difference to be due to just

the CPU.
I heartily concur. Sounds like a "bug" in the processor or, much
much more likely, user's settings and measurement processes...

Haha - that reminds me of a line from 2001 A Space Odessey. The computer Hal
who has just malfunctioned says: "Well, I don't think there is any question
about it. It can only be attributable to human error."

http://sundry.wikispaces.com/transcript-2001

Post by NimbUs

Post by James Harris
you worked out exactly what takes a long time? Are normal non-

IO,

Post by James Harris
non-trapping instruction streams slow? Could it be repeated

trapping to SMM

Post by James Harris
which is slow? That is more likely to be caused by the machine

emulating

Post by James Harris
hardware than by the CPU itself being slow to run RM code.

SMM isn't likely to cause SUCH degradation, besides SMM is
active in all processor modes, not just during RM, so if that
were a buggy SMBIOS, the machine wouldn't work at all...

Post by Rod Pemberton
I believe this is purely a processor issue, i.e.,
minimizing support for RM.

Again, not likely to cause SUCH degradation. I know real mode is
being deprecated, but not to the point of slowing it
hundredfolds without anybody complaining, but you :)
How exactly do you set up your processor to test real mode
operation ? To me the most likely cause for 100x slower is
memory accesses, either or both the memory controller and MTRRs
(memory typing registers) and caches not properly initialised
by, what have you, BIOS, EFI ? My bet is on MTRRs. If they are
left at their default setting, all the memory is uncached and
that would produce the kind of utter slowness you have reported.
I should know, having played with truly unitialised processors
(no BIOS, no nothing), running own experimental code that I will
flash into mother-board's EPROM...
You could test this hypothesis by examining the contents of your
processor's MTRRs (as well as other interesting "architectural"
Machine Specific Registers).

I doubt that MTRRs being set to uncacheable would be enough. Rod was talking
about many orders of magnitude.

Post by NimbUs
Shall be interested to hear whatever you find out

Me too.

James

NimbUs

2014-07-02 10:41:13 UTC

Post by Rod Pemberton
But, on my AMD Phenom II 3.2Ghz, 16-bit real-mode (RM) code

is so,

Post by Rod Pemberton
so, so, (utterance) slow, you wouldn't believe it. I'd

swear

Post by Rod Pemberton
they

Post by Rod Pemberton
dropped in an 8Mhz or 12Mhz 8086 core just for RM.
I believe this is purely a processor issue, i.e.,
minimizing support for RM.

Again, not likely to cause SUCH degradation. I know real mode

Post by Rod Pemberton
being deprecated, but not to the point of slowing it
hundredfolds without anybody complaining, but you :)
How exactly do you set up your processor to test real mode
operation ? To me the most likely cause for 100x slower is
memory accesses, either or both the memory controller and

MTRRs

Post by Rod Pemberton
(memory typing registers) and caches not properly initialised
by, what have you, BIOS, EFI ? My bet is on MTRRs. If they

are

Post by Rod Pemberton
left at their default setting, all the memory is uncached and
that would produce the kind of utter slowness you have

reported.

Post by James Harris
I doubt that MTRRs being set to uncacheable would be enough.

Rod was talking

Post by James Harris
about many orders of magnitude.

Oh yes having to wait for every memory access (reads,
especially) could effectively slow down a processor by more than
one order of magnitude, the precise measure of that slowdown
depending on processor, chipset and memory system details, and
of course the type of computing load.

This is not saying I'm certain /this/ is what's been impeding
Rod's machine.But it's a possibility more so than the processor
magically slugging in real mode, even if AMD removed some
special tuning it couldn't slow real mode to the point reported
by Rod. Therefore I'm suspecting the problem must stem from the
BIOS dropping support for DOS (and similar "legacy" stuff) and
omitting some necessary initialisations...

Without Rod telling us more about his machine, whether a branded
or custom-made rig, impossible to devine anyway. Am seeing Rod's
message that he has "BIOS not EFI", or is that "BIOS emution
under EFI" ?

Post by Rod Pemberton
Shall be interested to hear whatever you find out

Me too.

--
NimbUs

Rod Pemberton

2014-07-01 23:33:37 UTC

On Tue, 01 Jul 2014 06:51:52 -0400, NimbUs

Post by NimbUs
wrote ...

Post by James Harris
you worked out exactly what takes a long time? Are normal
non-IO, non-trapping instruction streams slow? Could it be
repeated trapping to SMM which is slow? That is more likely
to be caused by the machine emulating hardware than by the
CPU itself being slow to run RM code.

SMM isn't likely to cause SUCH degradation, besides SMM is
active in all processor modes, not just during RM, so if that
were a buggy SMBIOS, the machine wouldn't work at all...

I don't know how to detect, measure, or change this anyway.

Post by NimbUs
How exactly do you set up your processor to test real mode
operation ?
To me the most likely cause for 100x slower is memory accesses,

...

Post by NimbUs
either or both the memory controller and MTRRs
(memory typing registers) and caches not properly
initialised by,

DOS doesn't init MTRRs, e.g., for LFB. Maybe, the BIOS missed
some too? ...

Post by NimbUs
what have you, BIOS, EFI ?

Award Modular BIOS V6.00PG

No EFI. Well, AFAIK. It's not setup that way, if supported.

Post by NimbUs
My bet is on MTRRs. If they are left at their default setting,
all the memory is uncached and that would produce the kind of
utter slowness you have reported.

...

Post by NimbUs
I should know, having played with truly unitialised processors
(no BIOS, no nothing), running own experimental code that I will
flash into mother-board's EPROM...
You could test this hypothesis by examining the contents of your
processor's MTRRs (as well as other interesting "architectural"
Machine Specific Registers).

I'm not sure how to do that. There are some DOS utils that will
set certain MTRRs. Is there an x86 instruction for this?

Post by NimbUs
Shall be interested to hear whatever you find out

Well, I was hoping to not spend any time of this, and I don't
plan too, unless viewing MTRRs is easy.

Rod Pemberton

NimbUs

2014-07-02 10:57:14 UTC

Post by NimbUs
You could test this hypothesis by examining the contents of

your

Post by NimbUs
processor's MTRRs (as well as other interesting

"architectural"

Post by NimbUs
Machine Specific Registers).

I'm not sure how to do that. There are some DOS utils that

will

Post by Rod Pemberton
set certain MTRRs. Is there an x86 instruction for this?

Sure ! Read up about RDMSR/WRMSR instructions, and learn about
memory typing and MTRRs from (AMD or Intel's) X86 systems
programming manuals

Post by NimbUs
Shall be interested to hear whatever you find out

Well, I was hoping to not spend any time of this, and I

don't

Post by Rod Pemberton
plan too, unless viewing MTRRs is easy.

It /is/ easy, i would say, at least for a clax86 regular !

Another realtively quick test of your own suggestion (that
somehow you processor is extremely slow in real mode only) :
write a program which starting from real mode will put your
processor into protected mode (of one or another flavour), and
see if the sluggishness magically foes away (I betcha not).
Add paging, etc... and see what gives.

Other simple test you can do : time (RDTSC) a code loop that
does only computations (w/o any memoy access). Is it still
slow ?

Just my 2 cents of advice anyway...
Cheers,

--
NimbUs

Rod Pemberton

2014-07-01 23:33:08 UTC

On Mon, 30 Jun 2014 17:40:05 -0400, James Harris

Post by Rod Pemberton
On Mon, 30 Jun 2014 03:02:41 -0400, Frank Kotler

Post by Frank Kotler
Unlikely to be much faster just by converting it to 32-bit.

That all sounds *far* too big a difference to be due to just the CPU.
Have you worked out exactly what takes a long time?

No. I have no idea what it is and haven't really looked for it.
The DOS setup is the same as the prior machine, except it's using
a hard drive instead of solid-state disk.

Post by James Harris
Are normal non-IO, non-trapping instruction streams slow?

It seems to be the executing code. It's always a possibility that
the XMM and DPMI hosts could be incompatible with the hardware
somehow, or doing something that's bogging the hardware. They're
about all I load.

Post by James Harris
Could it be repeated trapping to SMM which is slow?

AFAIK, it could be. I don't know how to determine if the BIOS is
using SMM. I think we may have discussed this on a.o.d.

Post by James Harris
That is more likely to be caused by the machine emulating
hardware than by the CPU itself being slow to run RM code.

It's a bit like the old turbo switch when off, but worse...

Rod Pemberton

Alexei A. Frounze

2014-07-03 09:04:43 UTC

Post by Rod Pemberton
On Mon, 30 Jun 2014 03:02:41 -0400, Frank Kotler

Post by Frank Kotler
Unlikely to be much faster just by converting it to 32-bit.

That's another thread entirely.
But, on my AMD Phenom II 3.2Ghz, 16-bit real-mode (RM) code is so,
so, so, (utterance) slow, you wouldn't believe it. I'd swear they
dropped in an 8Mhz or 12Mhz 8086 core just for RM. My older
AMD X2 5600+ 2.8Ghz processor was thousands upon thousands of times
faster. Things that took a few seconds in RM DOS now take up to
15 minutes. I believe this is purely a processor issue, i.e.,
minimizing support for RM. It's fast once in protected mode,
be it Windows SE or Linux.

It would be interesting to measure (with PIT/TSC/RTC) execution times of some simple math routine in RM and PM (possibly DPMI) under DOS or off a bootsector. And whether the difference, if any, persists after multiple mode switches.

I wonder if power management/control, typically absent in DOS, is to blame.

Also, is it a UP or MP box? NUMA?

Alex

Rod Pemberton

2014-06-30 10:16:43 UTC

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?

MVS/380
http://mvs380.sourceforge.net/

GCCMVS
http://gccmvs.sourceforge.net/

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.

Rod Pemberton

William Gallant

2014-06-30 15:21:24 UTC

Sorry so late -- just woke up.
I don't know if it's compiled "C" code.
The mainframe binary file which runs under the DOS
emulator is pure IBM System/370 assembler ( a 370
load module nucleus ).
As mentioned above, patching through QEMU or Bochs
seems a good idea. This is the same idea i tried to
originally describe when i suggested running through
a modified DEBUG program. Like running 16bit code
step by step -- each instruction being changed to
32bit and logged while being run.

--- IOTW, the converter need to have a damn good AI.

No, not even IDA Pro the latest version has good enough AI.
--------------------------------
No. Is this it?

http://www.milinta.com/APL.html

They seem to have Windows and Linux versions, if so.
---
Better yet the Sharp APL/PC can be found at --
http://www.math.uwaterloo.ca/apl_archives/apl/sharp.apl/

William Gallant

2014-06-30 16:21:56 UTC

Forgot...

Another version at:

ftp://www.graco.unb.br/pub/ASME/OTHER/APL-ISW.ZIP

-- Willaim

Johann Klammer

2014-06-30 03:58:06 UTC

just the opcodes?
What about the addressing, memory model differences?
(segmented/flat etc..)

AFAIR there are instruction prefixes, that override operand sizes, and
the default is given by the cpu (some bit in a control register, I believe)

But that will not magically work If you want the code to run in a
different memory model. The addresses will all be completely wrong..

wolfgang kern

2014-06-30 07:37:40 UTC

Beside that every demanded programming should be possible ...
but for sure not 'easily'.
The problem is that such a tool would need to be more than
just smart as it must be able to detect the functionality
of one asm-text-source and guess the targets environment to
convert it into another.

The main differnces between 16 and 32-bit modes are addressing
and the assumed environment.

I think that a RM to PM16 conversion might be less complicated.
But an automated PM16 to PM32 conversion will ask for much more.

If you just want to convert parts of code rather than executable
files, you could try FASM. I'd wonder if it would not correct
interprete and compile an 16-bit ASM-text as 32-bit too.
Compile it as '.bin' with 32-bit.
A disassembler would show you that the 32-bit version is full
of '66'and'67'-prefix, which is perhaps not what were after :)

So a manual rewrite is often the better and faster solution.
__
wolfgang

2014-06-30 07:47:10 UTC

Assuming that the converter doesn't need to change the program's execution
mode (e.g.: real-mode to protected-mode, or vice versa), it's possible but
difficult and tedious. Otherwise, it'll be much more difficult.

The converter need to be capable of mapping every single data byte or even
data bits including data structures, aside from the instructions. And figure
out how much they can be restructured. Each time it fails to do this, it'll
decrease the probability of success to reconstruct a working program.

One important thing for this matter is the capability to identify which
codes are used for calculation, and which are for retrieving/storing data.
Not just simply identify which are function, loose code, or unused code.

It'll need a code refactoring capability to properly convert 16-bit to
32-bit calculations that require more than one instructions.

IOTW, the converter need to have a damn good AI.

FYI, I don't think the great IDA version is even capable of this, yet.

Rod Pemberton

2014-06-30 10:10:57 UTC

On Sun, 29 Jun 2014 23:12:52 -0400, William Gallant

Let me know if you find a good answer to this.

There are "binary translators" out there, but none that
I've found to be useful for x86 real-mode 16-bit to
protected-mode 32-bit. I searched for many five to eight
years ago.

There is one exceptional x86 binary translator. It's
called FX!32. It converted x86 to DEC Alpha instructions
and stored the resulting code as DLLs. Maybe, you could
find another and convert it back to x86.

Other options including patching QEMU or Bochs or some other
appropriate PC emulator to save translated code. That's
likely to only work for some emulators, i.e., those which
translate to x86 instead of converting instructions their
own internal instruction set.

Another option would be to find an emulator that uses
a binary translator and modify it to log all the
intruction conversions as the program is executing.
You'd have to thoroughly test all aspects of the program.
E.g., perhaps an x86 emulator on an x86 Mac.

Rod Pemberton

Rod Pemberton

2014-07-01 23:16:12 UTC

On Mon, 30 Jun 2014 06:10:57 -0400, Rod Pemberton

Post by Rod Pemberton
On Sun, 29 Jun 2014 23:12:52 -0400, William Gallant

S2E project has a branched project known as RevGen in their GIT
depository. It's supposed to be able to convert x86 code to LLVM's
IR allowing LLVM tools to analyze the code. They seem to use it
together with QEMU.

S2E (RevGen is a branch in GIT)
http://s2e.epfl.ch/

A .pdf describing it's capabilities:
http://infoscience.epfl.ch/record/166081/files/revgen.pdf

Rod Pemberton

1***@nospicedham.gmail.com

2020-08-03 09:18:46 UTC

I think it is semi possible, i think a program could be made to run an assembaled assembaly file coded in 16 bit asm, and then from that generate a 32 or 64 bit asm file that gives an ok output.

e.g:

8086:
======

.data
text db "Hello World!",10,13,0
...

.code
mov dx, text
mov ah, 09h
int 21h
...

translated from output to nasm 32:
section .text
mov rax, 1
mov rdi, 1
mov rsi, 72
mov rdx, 1
syscall

mov rax, 1
mov rdi, 1
mov rsi, 101
mov rdx, 1
syscall

mov rax, 1
mov rdi, 1
mov rsi, 108
mov rdx, 1
syscall

mov rax, 1
mov rdi, 1
mov rsi, 108
mov rdx, 1
syscall

mov rax, 1
mov rdi, 1
mov rsi, 111
mov rdx, 1
syscall

mov rax, 1
mov rdi, 1
mov rsi, 32
mov rdx, 1
syscall

mov rax, 1
mov rdi, 1
mov rsi, 119
mov rdx, 1
syscall

mov rax, 1
mov rdi, 1
mov rsi, 111
mov rdx, 1
syscall

mov rax, 1
mov rdi, 1
mov rsi, 114
mov rdx, 1
syscall

mov rax, 1
mov rdi, 1
mov rsi, 108
mov rdx, 1
syscall

mov rax, 1
mov rdi, 1
mov rsi, 100
mov rdx, 1
syscall

mov rax, 1
mov rdi, 1
mov rsi, 33
mov rdx, 1
syscall

mov rax, 1
mov rdi, 1
mov rsi, 10
mov rdx, 1
syscall

mov rax, 1
mov rdi, 1
mov rsi, 13
mov rdx, 1
syscall

mov rax, 1
mov rdi, 1
mov rsi, 0
mov rdx, 1
syscall

mov rax, 60
mov rdi, 0
syscall

; or something along those lines

but displaying text is easy and so more advanced things would not be able to translate very well but this is just a concept.

2020-08-04 08:10:18 UTC

Post by 1***@nospicedham.gmail.com

I think it is semi possible, i think a program could be made to run an
assembaled assembaly file coded in 16 bit asm, and then from that
generate a 32 or 64 bit asm file that gives an ok output.

[snip]

Post by 1***@nospicedham.gmail.com
but displaying text is easy and so more advanced things would not be able
to translate very well but this is just a concept.

I actually need DEDBUG's binary data manipulation so much that I had to make
my own DEBUG clone to remake that sole functionality, using VBScript.

https://pastebin.com/XfctsB1e

The dis/assembler part was considered but I've changed my mind, considering
that 32/64 bit (non DOS) programs use a not-so-simple image structure. Not
to mention the overwhelming x86 & x64 instruction sets and operating
environments.

It would be great if there's a full 32/64 bit version of DEBUG, rather than
a 32/64 bit DEBUG but with 16-bit functionalities.

Or, is there a 32/64 bit console based debugger (for Windows) with assembler
and binary file & memory manipulation already? Just like what DEBUG can do?
So far, I only found the GUI ones.

Frank Kotler

2020-08-04 19:49:55 UTC

Post by 1***@nospicedham.gmail.com

I think it is semi possible, i think a program could be made to run an assembaled assembaly file coded in 16 bit asm, and then from that generate a 32 or 64 bit asm file that gives an ok output.
======
.data
text db "Hello World!",10,13,0
...
.code
mov dx, text
mov ah, 09h
int 21h
...
section .text
mov rax, 1
mov rdi, 1
mov rsi, 72
mov rdx, 1
syscall
mov rax, 1
mov rdi, 1
mov rsi, 101
mov rdx, 1
syscall
mov rax, 1
mov rdi, 1
mov rsi, 108
mov rdx, 1
syscall
mov rax, 1
mov rdi, 1
mov rsi, 108
mov rdx, 1
syscall
mov rax, 1
mov rdi, 1
mov rsi, 111
mov rdx, 1
syscall
mov rax, 1
mov rdi, 1
mov rsi, 32
mov rdx, 1
syscall
mov rax, 1
mov rdi, 1
mov rsi, 119
mov rdx, 1
syscall
mov rax, 1
mov rdi, 1
mov rsi, 111
mov rdx, 1
syscall
mov rax, 1
mov rdi, 1
mov rsi, 114
mov rdx, 1
syscall
mov rax, 1
mov rdi, 1
mov rsi, 108
mov rdx, 1
syscall
mov rax, 1
mov rdi, 1
mov rsi, 100
mov rdx, 1
syscall
mov rax, 1
mov rdi, 1
mov rsi, 33
mov rdx, 1
syscall
mov rax, 1
mov rdi, 1
mov rsi, 10
mov rdx, 1
syscall
mov rax, 1
mov rdi, 1
mov rsi, 13
mov rdx, 1
syscall
mov rax, 1
mov rdi, 1
mov rsi, 0
mov rdx, 1
syscall
mov rax, 60
mov rdi, 0
syscall
; or something along those lines

Have you tun this code? I doubt it. Looka like it'll segfault to me.

Post by 1***@nospicedham.gmail.com
but displaying text is easy and so more advanced things would not be able to translate very well but this is just a concept.

Might be "possuble" but I doubt it'll ever be "useful". Yoo mich
difference between OSen!

Best,
Frank

William Gallant

2020-08-04 22:55:25 UTC

------

Since my first post, now there is GHIDRA, which can decompile a 16bit executable, and with adjustments a 32/64 bit recompile could be made.

-- William Gallant

Frank Kotler

2020-08-05 03:18:14 UTC

Post by William Gallant
Since my first post, now there is GHIDRA, which can decompile a 16bit executable, and with adjustments a 32/64 bit recompile could be made.
-- William Gallant

Let me say again: it may be possible, it is unlikely to be useful.

Best,
Frank

wolfgang kern

2020-08-05 10:46:34 UTC