2 great disassemblers... lost in time. SPECIFICALLY for DOS and 16 bit programs. They were the IDA PRO of THEIR days...
WCB (EXTREMELY rare to find. NEVER misses beginnings of a routine. NEVER)
SOURCERER (IF you can find it. THE disassembler to go to when professionals wanted to disassemble any file. INDUSTRIAL strength, MORE OPTIONS that you can throw a ...
I'll dive into the past and try to give an explanation of the different checks you are observing in your software. I found three references explaining the behaviour (as I hope), which I will reference to in this answer as /1/, /2/, /3/.
It is an archive article from the ...
Apparently a decompiler for DOS Basic executables already exists.
Going by examples from that page, quite a lot of the code can be recovered. I guess it used some form of P-code, or there was some additional metadata.
Descriptions of the decompiler's error messages can give some hints about various functions implemented by the Basic runtime.
debug with DOSBox debug-enabled builds
disassemble with IDA
try to compile your own empty qbasic EXE, and compare - this will help to telll the compiler code from the actual code of your game. You might do that automatically by creating a FLIRT-like signature of the empty EXE then import in your own EXE in IDA.
It's a minor speed optimization. The main loop for moving characters use movsw (move words) which was probably slightly faster than moving bytes. However, in case the number of bytes is odd, one byte would be left uncopied, and that's why there is an extra mosvb before and after it (so the extra byte is moved before or after, depending on alignment of the ...
This is the so-called "Rich header", added by Microsoft's link.exe (you can see the text "Rich" at the end of the mysterious block). It contains information about the versions of compilers and other tools which participated in producing the code of the executable. Some references:
Finding the Needle: A Study of the PE32 Rich Header and Respective Malware ...
But: it's not practically.
You could change the machine-code within the .exe, but that's not really practically if you want to change the interface/presentation. Also you would need to do it at least in assembly language.
If you want to improve the software, I think, the best would be to contact the developer and ask if you can help him to ...
DOS didn't have a concept of more than one application being able to run at the same time, with each of those applications able to allocate memory. Programs that stayed resident after termination weren't able to allocate more memory while another program was running. So, there was no fragmentation in memory, and no "memory location that was big enough".
there are no decent decompiler for 16b DOS afaik
Dosbox has an integrated debugger, otherwise try TurboDebugger - and opening the file in IDA simultaneously to document on the go. Also check this recent blogpost about such a situation.
I found the debug-enabled builds a bit unwieldy. But I found the combination of DOSBox and IDA quite nice using idados. It's an IDA Pro plugin which allows you to control the debugger of a debug-enabled DOSBox build from within IDA similar to how you can control a debuggee running one of the other supported remote debuggers.
Given the existing answer by ...
I know this question is old, but for future reference. You can download DOSBOX Debug version. It will give you a nice debug window where you can stem trough the assembler code. just run debug.exe program.exe og press alt+pause when the application is running. You need to know assembler to understand the output, but it is a very strong utility to look trough ...
The short answer is no - the source is not available if only the .exe is available. The source code is an entirely separate file which is generally not shared with the public. However, given the .exe file, it might be possible to "decompile" it into a form of source code which would allow a new .exe file to be produced, and which should match the existing ...
An old DOS EXE header is only 28 (0x1C) bytes long and is usually followed by the DOS relocation table if present. The IMAGE_DOS_HEADER struct of the NT PE header is much larger at 64 (0x40) bytes as it has been extended for the various other Windows executable formats.
Trying to interpret e_lfanew at offset 60 (0x3C) for a plain DOS executable as ...
MZ-format executables also have the PSP at CS-0x10 just before the data loaded from the file.
Quoting Tech Help!, probaly the best DOS programming reference:
EXE-format programs define multiple program segments, including a
code, data, and stack segment. The EXE file is loaded starting at
Two useful DOS debuggers come into my mind:
SoftIce is commercial, DeGlucker is freeware.
Edit: Gametools (G3X) is also a very useful TSR debugger for DOS. The best feature in Gametools is its memory scanner that can scan memory for exact values, for greater values than previous time and for lesser values than previous time. Then you ...
My answer is a little late; newcomer to this site. The Decompiler project was initiated in order to decompile MS-DOS EXE and COM binaries. The project has both a command-line and a GUI tool:
Use the following command with the command-line tool to decompile COM programs:
decompile --default-to ms-dos-com myprog....
The Reko Decompiler is updated regularly and works for 16-bit DOS executables.
It can generate C code from the disassembly.
It's written in C#/.NET so requires mono if you want to run it on linux or macos.
Without seeing the program, we can't say definitely one way or the other if it would be possible.
However, whenever the French text is at least the same size as the English equivalent, you can simply use a hex editor to overwrite the French text with the corresponding English text without any issue (leaving any left-over French characters in place, in order ...
Ok, you clearly have no idea what you are on about.
However this is not a problem, first learn why a C++ Decompiler is a weird thing to ask for. Second, if you are in luck the strings can be accessed directly from the program. Open the application in a decen hexeditor (HxD, 010, Hiew, Hexworkshop) and scroll down hoping you find the strings. Edit them (dont ...
That would be e_lfanew in the MZ header itself. For simple (16 bit) MSDOS software, this ought to be 0, and for any extended format it should point right to one of the specific LE, PE, or NE headers' identifiers (which all are exactly those two characters). As in all of these cases the header itself is a mere stub, e_cp (the total size of this executable in ...
Check 2: While check 1 tests if the high-order bits of the flag word can be cleared, check 2 tests whether they can be set. On an 80286, these bits cannot be set in real mode, while on an 80386 they can.
Check 3: This is testing what kind of shifter the processor has. Some (the newer ones) have a barrel shifter that effectively masks the shift count to the ...
In the end, the issue was due to the fixup tables. I wrote custom code to read the LE structure and thanks to some documents, figured out what offsets were being fixed up.
Please note, you need to parse the Fixup Page table and then loop through checking positions. Then read the record data.
In case of Watcom fastcall uses eax, edx, ebx, ecx for the first 4 arguments, however your code is pushing eax and is not restoring the stack afterwards. You should probably either add another pop (e.g. pop eax) after the call or an add esp, 4, OR use the esp value you saved in ebp, i.e. mov esp, ebp.
IDA Pro https://www.hex-rays.com/products/ida/ and my blog https://firebitsbr.wordpress.com/2015/09/28/list-of-pluginsscripts-for-ida-pro-both-re-malware-vulnerabilities-and-exploits/ many plugins for ida pro.