Is it possible to convert a DOS Application to a Win32 Console Application? I have an old program I wrote a long time ago, lost the source to it and asked myself now if it's possible to convert the DOS Binary to an actual Windows Binary, which runs in Command Line Prompt?
This is not possible. The DOS program will attempt to use DOS system calls that do not exist under Windows. The program will need to be updated and rebuilt for Windows. You might have some success running the original program in a DOS emulator.
See other answers about running a DOS program under Windows.
To convert a DOS program to a Win32 console application, one would have to convert the 16-bit (8086) code within the DOS program to 32-bit (i386) code. This is a very hard task to do right, and probably that's why there is no converter readily available. (Alternatively, an emulator can run 16-bit code without conversion, see the other answers and comments.)
However, not all DOS programs contain 16-bit code, for example programs using DOS extenders built with the Watcom C/C++ compiler (or, equivalently, with OpenWatcom: owcc -bdos4g prog.c) contain only 32-bit code. Windows can run 32-bit code directly, but API calls (e.g. opening and reading a file, allocating memory, getting the current time, writing colorful text to the console) have to be converted from the DOS+DPMI API to the Win32 API. Such a conversion is technically possible and feasible (even on the final .exe file, without access to the source code), and it is much easier to do correctly than the conversion of 16-bit code to 32-bit code. However, I still don't know of a converter readily available.
Please also note that conversion graphics and audio code to the Win32 API is very hard, but that's out of scope in this question.
Related
I am currently trying to get an executable running in memory. Because it is high likely that someone will ask later: Yes, it will be used for malicious software in order to hide it from AV. It is only for educational purposes, in specific for a school project (will be part of my graduation).
However the question concerns something else. I found a really good source at Github: https://github.com/aaaddress1/RunPE-In-Memory, which works perfectly for my uses (I already changed it for my purposes etc), except for the trojan I want to run. I tried it with several, e.g Darkcomet or Darktrack (It needs to be something old what is already well known to demonstrate how you could reuse them). I thought because Darkcomet it coded in Delphi (which outputs a native?), it would work like any other EXE-File (Like the ones provided at Github), but it just does not start. In Darkcomet there is also an option for making the malicious server file noticeable, so it is safe that I did not fail at any port-forwarding stuff.
My first intention then was to open the EXE in a text editor and look if it is even the same architecture. I can find "PE L" in both binaries, so as far as I know it is both 32bit. A thing what seemed strange to me were the two lines
"This program cannot be run in DOS mode." for the compiled runPE loader
and
"This program must be run under Win32" for the trojan executable.
Furthermore the two Binaries differ in the first chars: MZ and MZP.
After opening up more binaries and testing them, I came to the conclusion that the ones with "This program must be run under Win32" do not work.
As far as i know and also googled, there are DOS and Windows executables. But if there are only these two types, why is there a difference?
"must be run under Win32" == "cannot be run in DOS mode." in my opinion.
I also looked up those two terms , but I only get Threads about people who try to run these Windows-PEs in DOSBox or similar things.
So, my actual two quesions are:
-What is the difference between "This program must be run under Win32"(Type1) and "This program cannot be run in DOS mode."(Type2)
-Why does it not work if I want to push a (Type1)program into the Memory with the (Type2)RunPe-InMemory executable which I made from the Github repository.
What is the difference between ... (Type1) and ... (Type2)
Nothing:
A "PE" executable consists of some MS-DOS EXE file followed by a 32- or 64-bit part.
If you start the "PE" executable under MS-DOS (or any compatible operating system), DOS will ignore the 32- or 64-bit part and execute the MS-DOS EXE file at the start of the "PE" executable file.
A few programs are written in a way that the DOS EXE file at the start of the PE file is doing the same as the Windows part, so you can use the same EXE file both under DOS and Windows.
However, in most cases the DOS part only prints some error message saying that the program cannot be started under MS-DOS.
What you see here are two different MS-DOS programs at the start of the PE EXE files; one program prints the error message "This program must be run under Win32", the other one prints "This program cannot be run in DOS mode."
Furthermore the two Binaries differ in the first chars: MZ and MZP
This is also not a difference:
The third byte of MS-DOS files is one of many bytes describing the length of an MS-DOS program. Because you have different MS-DOS programs, they also have different lengths.
In one case the byte has the value 80, which is shown as "P" in a text editor.
In the other case the byte might have the value 10 (as an example), which is not shown as character in a text editor.
Why does the runPE not work with a specific type of executables?
Not having seen the trojan, I cannot answer this.
However, I have seen many trojans which do not use a correct "PE" file format.
(However, in these cases the "errors" were after the "PE L", not in the "MZ"-part.)
I am making a retro text adventure game in Turbo Pascal that will be played in MS-DOS, and I want it to be in the COM file format. I've looked it up and have found nothing on this subject. If you can help me that would be greatly appreciated.
Something other than that, whenever I try to run my program (compiled into EXE) from DosBox it can't run due to "This program cannot be run in DOS mode". Is this because I'm using Turbo Pascal 7 and need to downgrade? Thanks a lot of you can figure this out.
Set your TP7 to target dos, not windows. Note that you might have an Windows only TP product (also known as TPW)
COM files will still be out of your reach, but at least DOS exe files should run in dosbox. Keep in mind that COM files have a 64k limitation, and therefore are of limited interest.
Free Pascal is working on a DOS16-bit Dos compiler that can generate com files directly from (64-bit) Windows, and while it is working, it is not released yet.
I was trying to make my program accept input without the user having to press enter, so I tried the following:
mov ah,01h
int 21h
But it just crashes my program over an unhandled exception. This seems to be the way to do it according to much that I have read, so why isn't it working for me?
Now, I am fairly new to this language so I still do not exactly understand the process of how this piece of code works, so I would also appreciate what the logic is behind accepting input by pressing enter and accepting input without the user having to press enter.
MY OS is Windows, by the way.
Your code looks like MS-DOS-era assembly. VS2010 doesn't support generating DOS executables, and modern versions of Windows (the 64-bit kind) don't support running them, either. Looks like you were going by some old book or site, one that was written in late 80'es-early 90's. Back at that time, assembly was way more relevant and marketable as a job skill. Not so much these days, although some assembly knowledge won't hurt.
Decide what do you want to learn. If you want to learn modern assembly (and target Windows), get some recent guidance. The techniques are quite different, and int21h isn't among them :) If you're indeed after DOS-era assembly, set up a DOS virtual machine with DOSBox, and find some old free assembler. Visual Studio 2010 won't help you here. The latest version of Visual C++ that generated 16-bit executables was v1.5x.
Specifically why does your program crash. Int21h was how MS-DOS exposed its applciation program interface (API). Windows doesn't support it for Windows executables - there are other ways of invoking the API. When you assemble with Visual Studio 2010, you end up with a Windows executable, not a DOS one, and there's no option to generate a DOS one. As for the Windows executables, they're not supposed to invoke interrupts at all - that's a crash condition.
You need to obtain a tool set that can generate 16 MS-DOS programs. These should run on DOSBOX, or on a Virtual PC with MS-DOS installed on it. Microsoft included 16 bit tool sets up to Visual C / C++ 1.52, but Visual C / C++ 4.0 and 4.1 also contain the 1.52 16 bit tool set. The older version of the compilers would be named Microsoft C 8.xx or earlier version. I don't know if any the early versions of Visual Studio (2002 or 2003) include the 16 bit tool set.
Use the linker version 5.60 to generate 16-bit DOS applications. You can get this from:
http://download.microsoft.com/download/vc15/Update/1/WIN98/EN-US/Lnk563.exe
Dirk
I've always been curious as to how one extension, EXE, can be as versatile as it is in that if you assemble an assembly program, you get an EXE in machine code for your processor but if you compile a C# or other .Net program, you also get an EXE except that it is run in the proper runtime environment. I'm not sure if this is different from OS to OS (I imagine it is), but when an EXE is executed, how is it determined how to execute it?
On a related note, if I were writing my own programming language, how would I tie in my runtime environment into this mechanism?
When compiling a .NET program to an EXE, it's more than just a blob of bytecode (like Java). There's actually native executable created that will load the .NET runtime and hand off the .NET bytecode to it, or display a friendly-ish error message indicating that the framework is not available.
The format is even more flexible than that, as every Windows EXE actually includes a DOS program at the beginning which will display an error ("cannot run in DOS mode") when executed as a DOS program.
You can read more details on the PE format on Wikipedia: http://en.wikipedia.org/wiki/Portable_Executable
I remember a few years ago(2002) there was a multipartite virus that could be run natively on linux and windows. I don't know if a compiler could be specially craft an executable so that it could be read as both ELF and PE, so that the os would start executing at different entry points. Or a program that could merge two programs, one compiled using mingw, one compiled in native linux, to one program.
I don't know if such a program exists, or could it exist, and I'm know this could be implemented in Java or some scripting language, but that's not a native program.
Imagine the possibilities, I could deploy a program with linux and window (and perhaps os/x)libraries, and one main executable that could be run on any os. The cross-platform support would compensate the bigger size.
Windows programs have a DOS stub in the beginning, and I just ran an ELF executable through debug.com, which said that the first instruction of this exe was JG 0x147. Just maybe something could be done with this...
No.
Windows and Linux use vastly different binary file formats. See Portable Executable (Windows) and Executable and Linkable Format (Linux).
Something like WINE will run Windows executables on Linux but that's not the same thing.
This is actually a really terrible idea for multiple reasons.
Cross-compiling across operating system boundaries is extremely difficult to do properly.
If you go for the second route (building separate PE binaries on Windows and ELF on Linux, and then somehow merging them) you have to maintain two machines, each running a different OS and the full build stack, and you'd have to make sure that you tested both versions separately before gluing them together.
Dynamic linking is already a pain to properly manage, on Windows and on Linux; static linking can generate binaries that are much more inconvenient to deal with than whatever imaginary benefits you get from providing one single file type to your end-user.
If you want to run the same binary executable file on multiple OSes, your options are Java, Mono, and potentially NativeClient, the browser plug-in Google's developing to work around the "webapps are too slow" problem.