I have an old MSDOS program that I might want to run on a modern(er) machine.
Is it possible to install some MSDOS on these machines and run the .exe program?
A cmd window does not work on my machine now: it's 64 bit.
This is the case, for the interested:
I am building a Win10 program to do some tricky calculation. But it's not ready yet to use. My customer comes with a question that I maybe could answer with an old program I have, that ran in DOS, back in the 80's and 90's.
I would try using the compatibility mode windows 7 offers (unlikely that will work).
Your best bet is an emulator like DOSBox.
Any x64 based Windows will not allow you to run old 16 bit DOS code, it wouldn't be able to run 16 bit Windows code either.
I tried the same on my Windows 10 x64 only seconds ago and received this (German) denial message:
In my scenario the exe is even able to run in 386 mode with a dos extender but this does not help either because the base is 16 bit code.
You will need some kind of emulation or virtual machine. I gave DOSBOX 0.74 a quick try and it was able to run my old 16 bit DOS program which even makes use of an dos extender. There is no need to install dosbox, you can simply unpack the exe using 7-zip and provide it alongside your own program and use it as a launcher.
Just create a dosbox.conf file and put it in the same directory dosbox.exe is in. This content will automatically simulate a C-drive for DOS and launch your program as soon as you start dosbox.exe from Windows.
[autoexec]
mount C C:\yourprog.dir
C:
yourprog.exe
Just an addition to emulation/VM answers: for me, big part of DOS programs worked when booted in Windows XP x32 safe mode with console support (sic!). On Vista and higher I was not able to run any DOS executable. So mostly you'll need DOSBox-like program, but XP is still a good oportunity, though.
Related
So I was writing assembly code in TASM. But now I want to migrate it to MASM and have it run on 32-bit Windows. Can I still keep the DOS interrupts or is there some other way to do it?
I want to ideally run this on Windows 10.
16 bit code from Windows 95 will still run on 32 bit windows at least until windows 7 (I don't have the software to try it on Windows 10).
However for 32 and 64 bit code, you have to start using the win32 api which use the less exciting "call" instruction instead of interrupts.
Simple answer: no, you can't. Under Win32/Win64, calling a DOS interrupt from a Windows program will crash your program with an "Invalid operation" message. Figure out what are you trying to do with DOS interrupts (console output? writing to files?), find corresponding Win32 API functions, and call them.
UPDATE: depends on what are you after. DOS interrupts are only available to DOS executables; Windows executables have to use Windows API. It's entirely possible to make Windows executables in assembly, MASM included, but you'd have to learn new techniques. Building DOS executables is supported in older versions of MASM, but that skillset is rather pointless in today's computing environment. For one thing, the DOS subsystem is slowly but surely going away from Windows - 64-bit versions of Windows don't have it anymore.
I have 16-bit command line tools that I want to run on Windows 7 x64
I don't want to use a Virtual Machine
Can the 16-bit tools be wrapped in some way?
Maybe a 16-bit CMD.exe emulator
http://takeda-toshiya.my.coocan.jp/msdos/
This may help you. (Japanese website)
Have you tried downloading XP Mode (http://www.microsoft.com/windows/virtual-pc/download.aspx) for Windows 7? I know it works for 16bit GUI applications, but I don't know about command line programs.
also, you might want to look at DosBox (http://www.dosbox.com). It runs old DOS games, i don't know how it interacts with Windows, however, so I don't know if you can access the file system, etc from DosBox.
good luck,
Mark
You must use some kind of a virtual machine. 16-bit is just not supported on Win64.
Try this if you are up to productivity apps. Its a variant of Dosbox
but built for old business apps
http://sourceforge.net/projects/vdos/
I'm developing a network redirector using RDBSS.
In our network redirector volume, a executable file which is packed from Inno Setup(Open source packer) can not be run.
When we do double-click the file in Windows Explorer, the Explorer shows this messagebox.
It works well on 32bit Windows. Only 64bit Windows is problem.
I guess it is related with npdll or MUP.
We have implemented npdll, and I thought it doesn't have any bug now. - Of course we also have npdll 64bit version.
Other executable files and any files work well for both 32 and 64OS.
If we run this file in 64bit Windows SMB volume, it runs fine.
So, I'm pretty sure some our codes have a bug.(npdll or redirector driver)
Could you guess anything about this?
P.S Is there a good document describing how MUP works? If you know, let me know please.
Thanks.
The other executables which work, are they 64-bit or 32-bit?
If only 32-bit processes (like InnoSetup) fail, could it be that you need to install both the 64- and 32-bit versions of your DLL on x64 systems? That's required for some DLL types (e.g. video codecs) if you want their functionality to be available to all programs, but I'm not familiar with RDBSS and thus don't know if it applies in this case.
how can i make a device input and output control program on windows 7??
Previously there was an option called debug where we wrote our programs. but as far as i know this feature is no more in windows 7. how can i do assembly on windows7??
You can use an assembler such as NASM, YASM, etc., or MASM which is free with Visual Studio Express (for non-commercial use).
I was thinking of Grdb, but it is only available for 32-bit, as a debug alternative.
I'm not sure what you are asking for with your first question, so I cannot answer it. I hope the above answers your second question.
It sounds more like you want to write a device driver? If so, download the Windows Driver Kit from Microsoft.
You can use this to write your driver in assmbly code if you wish. Be aware that this is NOT a trivial task.
What may be a better idea for you is to either install the WinXP virtual machine feature that comes with Windows7, or install WinXP/98/95 on an old machine, and do your coding on that. Under those OSes the driver model was simpler, and you could easily access the interrupts directly and/or easily elevate yourself into Ring 0 if you needed to.
Debug is available on Windows 7 32 bit, but not 64 bit.
Is it possible to run the COFF executable files on UNIX or the ELF executable files on Windows? And what would be the steps to be able to run either file type on Windows and UNIX. I'm just curious.
To answer your question properly, it is relevant to review what ELF, COFF, and PE are. These binary formats are essentially just containers that give directions to the operating system about how to execute the raw CPU instructions contained in the file. They are very much like audio/video containers like MKV, WMV, and OGG. Support for the executable format is either in the operating system or not. Microsoft Windows has consistently not given any support for COFF or ELF, until recently. With Windows 10, Microsoft has provided indirect support for ELF by building into the Windows kernel UserMode-Linux compatible system routines. A UserMode Linux kernel runs on top of the Windows kernel and runs all ELF binary formats almost as if it were running independent of MS Windows.
The alternative to using the UserMode-Linux (sub-kernel) being for Microsoft to rewrite the majority of the Linux API in a completely compatible format, their choice solves one other compatibility issue: The API. "A" stands for Application and "I" for Interface, however the API as an interface is mainly just a set of executable routines and environment assumptions. Access to the filesystem and most basic system routines is provided by the Windows kernel, while everything else is provided in the UserMode Linux kernel. This way not only can Windows run ELF formatted executables, but in can run the most popular ELF executables that are already made to run on the Linux API.
The reverse, the other half of the question, running PE (most Microsoft Windows executables) on Linux is possible as well. There are two runtime wrapping libraries that can run MSIL (virtual machine application) and Win32 (normal CPU application). Because the Linux kernel is extendable to recognize a certain byte format, then run an appropriate wrapper program, in effect the kernel supports PE and potentially more executable container formats. Therefore, Linux can run some PE programs either in the mono runtime (.NET/C# applications) or in the WINE runtime (Win32 C/C++).
To install the UserMode-Linux environment you can follow instructions provided on Microsoft's Development Network. To summarize:
Turn on Developer Mode: Settings | Update & Security | For Developers | Check the Developer Mode radio button
From the start menu, open “Turn Windows Features on or off”
Scroll down and check the “Windows Subsystem for Linux (Beta)” feature
Hit okay and reboot (required step)
Once rebooted, open a PowerShell/command prompt and run “Bash” and follow the simple prompts to accept Canonical’s license and kick-off the download of the Ubuntu image
After download has completed, you’ll be able to start “Bash on Ubuntu on Windows” from the Start menu
Be aware this method only works on Windows 10 and is still limited to text-mode console and a Win32 port of Xorg like vcXsrv for anything graphical. Cygwin or MSYS2 systems are not able to run ELF binaries, but make it possible to port and run the same applications that are normally ELF binaries on a Linux system.
To actually run executables and have them do useful stuff, you need to worry about the API, not just the executable file format. On a Linux machine with WINE installed, you can run Windows .EXE files from the command line and they do the same thing that they do on Windows.
The other way around is not really possible, however if you install CYGWIN on a Windows machine, and then rebuild the application from source with CYGWIN compilers, you will get an executable that runs on Windows and does the same thing that the Linux executable does on Linux. Lots of standard Linux tools are already ported and in the CYGWIN repository including stuff like X-Windows and GIMP.
http://lbw.sourceforge.net/ works better than line.
low was another project for doing the same thing, but that was the less working.
EDIT: http://atratus.org/ seems to do the same as well, without the need to have Interix/SFU.
COFF was originally introduced by UNIX (around System V or thereabouts) so yes, some UNIX probably still supports COFF format. It's been deprecated by Linux at least for a while, and presumably most other Unices have also deprecated or outright dropped support.
Windows ELF support is a bit more iffy - almost certainly not there without some deep trickery. You should be more specific about what you're trying to do here...