MSDOS emulation in MS V7 ?
Terence
that has MS V7 installed till some date in October.
Has anybody been able to try out the DOS emulation under V7 and are
they any new problems that werrn't in NT or XP? Or any old ones
corrected?
Jim Leonard
There is no DOS emulation in Windows 7. It was removed. Use DOSBox
or VirtualBox instead.
Peter Schepers
That's not entirely true. I'm running Win 7 RC1 right now. I use Open
Watcom C 1.8, installed for DOS, under the Command Prompt. I work on,
edit, compile and run my DOS-based application. Full-screen no longer
exists, and I have my suspicions that many games won't work anymore but
DOS is not gone in 32-bit Win 7.
PS.
Zaphod Beeblebrox
"Peter Schepers" <sche...@ist.uwaterloo.ca> wrote in message
news:h9to63$ae4$1...@rumours.uwaterloo.ca...
Also keep in mind that 64-bit flavors do not include support for
16-bit programs, so all of those old command-line utilities and games
will no longer work. Of course, that isn't limited to W7 - 64-bit
versions of Vista and XP have the same issue.
--
Zaphod
Arthur: All my life I've had this strange feeling that there's
something big and sinister going on in the world.
Slartibartfast: No, that's perfectly normal paranoia. Everyone in the
universe gets that.
Terence
<Zaphod.Arisztid.Beebleb...@gmail.com> wrote:
(in reply to):-
>
> > That's not entirely true. I'm running Win 7 RC1 right now. I use
> > Open
> > Watcom C 1.8, installed for DOS, under the Command Prompt. I work
> > on,
> > edit, compile and run my DOS-based application. Full-screen no
> > longer
> > exists, and I have my suspicions that many games won't work anymore
> > but
> > DOS is not gone in 32-bit Win 7.
>
> Also keep in mind that 64-bit flavors do not include support for
> 16-bit programs, so all of those old command-line utilities and games
> will no longer work. Of course, that isn't limited to W7 - 64-bit
> versions of Vista and XP have the same issue.
>
> --
> Zaphod
That is not true either, I'm glad to say. Curious to know why one
might think so.
.
I have been running hundreds of for-DOS ASM and Fortran-compiled
programs (put together in 1985) that run perfectly in all WS O/S from
V3.1 through NT and NP. Recent re-assemblies or re-compilations still
run perfectly, including all the screeen control based on the old DOS
services.
I have NOT tested anything under Vista. My preference is still NT
Professional, so I'm waiting to see what V.7 brings.
But lack of full screen will be a blow.
So, any DOS emulators out there that would run under V7?.
Rugxulo
It's only a guess, but I suppose that Win 7 probably only halfway runs
DOS stuff as Vista's NTVDM is almost always buggier than XP's, even.
But Vista does more or less work halfway (esp. w/ SP1's DPMI limit
registry hack).
64-bit mode (as designed by AMD) has no native support for V86
emulation, so any OS that wants 16-bit support has to fully emulate
that part (as DOSEMU allegedly does nowadays). Win2k3 doesn't even
support the DPMI limit registry fix, and MS has no intention of fixing
it (no more SPs for them). In other words, NTVDM is dead to them, they
don't care, it's just old half-working code that will eventually
disappear when most people start needing > 3 GB of RAM.
Vista does not have full-screen anymore, and that's most annoying when
a program makes a (BIOS video?) call, hence such apps (even textmode)
don't work at all, even if they only made a simple query. FreeDOS'
diskcopy and Watcom-compiled ZIP were the examples that I remember
seeing. Also, any .BAT using patch.exe, update.exe, install.exe, etc.
will trigger UAC (work around this by using a makefile instead). And
other annoying issues ....
DOSBox is good and works well, but it's still very very slow (approx.
fast 486 speeds for me). VirtualBox is a fast virtualization program,
much faster than the QEMU it's based upon, but it has wimpy DOS or 16-
bit support in general (various bugs, probably from lack of testing or
interest). Win 7 will have an optional downloadable but free XPM ("XP
Mode") using VirtualPC but only for Business and Enterprise, and your
cpu will need VT-X (virtualization extensions), which not all Intel
chips have.
Zaphod Beeblebrox
> "Terence" <tbwr...@cantv.net> wrote in message
> news:c7ef79df-5a16-441c...@m3g2000pri.googlegroups.com...
> On Sep 30, 10:04 pm, "Zaphod Beeblebrox"
> <Zaphod.Arisztid.Beebleb...@gmail.com> wrote:
> (in reply to):-
> >
> > > That's not entirely true. I'm running Win 7 RC1 right now. I use
> > > Open
> > > Watcom C 1.8, installed for DOS, under the Command Prompt. I
> > > work
> > > on,
> > > edit, compile and run my DOS-based application. Full-screen no
> > > longer
> > > exists, and I have my suspicions that many games won't work
> > > anymore
> > > but
> > > DOS is not gone in 32-bit Win 7.
> >
> > Also keep in mind that 64-bit flavors do not include support for
> > 16-bit programs, so all of those old command-line utilities and
> > games
> > will no longer work. Of course, that isn't limited to W7 - 64-bit
> > versions of Vista and XP have the same issue.
> >
>
> might think so.
If you re-read my post more carefully, you'll see that I am talking
about 64-bit versions of Windows. No 64-bit Windows versions support
16-bit executables, period. See
http://support.microsoft.com/kb/282423 and others.
> .
> I have been running hundreds of for-DOS ASM and Fortran-compiled
> programs (put together in 1985) that run perfectly in all WS O/S
> from
> V3.1 through NT and NP. Recent re-assemblies or re-compilations
> still
> run perfectly, including all the screeen control based on the old
> DOS
> services.
Glad to hear it. Guaranteed that your experiences are with 32-bit
versions of Windows. Try them on a 64-bit version and you will see.
>
> I have NOT tested anything under Vista. My preference is still NT
> Professional, so I'm waiting to see what V.7 brings.
> But lack of full screen will be a blow.
Agreed, it does. I'm still not sure why MS dropped full-screen mode
support from the command environment.
>
> So, any DOS emulators out there that would run under V7?.
DOSBOX works under Vista. Although I don't know about Windows 7, it
seems likely that DOSBOX will supply a compatible version if it isn't
already.
Rod Pemberton
news:5328bc93-29eb-4811...@e34g2000vbm.googlegroups.com...
> 64-bit mode (as designed by AMD) has no native support for V86
> emulation, so any OS that wants 16-bit support has to fully emulate
> that part (as DOSEMU allegedly does nowadays).
If DOSEMU has emulated 16-bit support, it should work on non-x86 cpu's.
Yes? But, Q #1.4 the doesmu-HOWTO.txt documentation says it won't... And,
16-bit emulation isn't listed as provided functionality in Q #1.1. I'm not
sure of the underlying functionality used by DOSEMU. But, since 16-bit
emulation isn't listed, this seems to imply that native cpu support of a
16-bit mode is required, i.e., v86 mode. It supposedly will run using
libSDL instead of glibc. If they've added 16-bit emulation, great! It
should work on non-x86 cpu's for other *nix's with glibc and on 64-bit Vista
using libSDL. Yes?
Rod Pemberton
Rugxulo
On Oct 5, 5:30 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
I don't think you should get your hopes up for anyone porting it, but
it does definitely run under x86-64 (as I had heard before but never
tried). I'm on XUbuntu 8.04.1 now (which I downloaded last year), did
"sudo apt-get install dosemu" and "sudo sysctl vm.mmap_min_addr=0",
and it mostly works (see below), even 16-bit stuff though that ain't
nearly as fast. But it works! (DOSEMU 1.4.0.0)
P.S. Put stuff in "~/.dosemu/drive_c/". You also may need to "dpmi -m
0xe000" or whatever to increase DPMI RAM available (since it's
ridiculously low by default, only 20 MB ?!?!?!). Also try "set DIRCMD=
%DIRCMD% /lfn" and "lfnfor on" and "lfnfor complete on".
Success: command.com, bef.exe, miniruby.exe, inv2.com, tdep.exe,
filetype.com, asm.exe, warplink.exe, upx.exe, eta.exe, sseta.exe,
v.com, 7zdecdj2.exe, scrndump.com, paq8o8z.exe
Fail: perl.exe (see below), ruby.exe (see below), befi.com
(self-modifying crashes the VM ??)
"
ERROR: Fault handler re-entered! signal=11 _trapno=0xE
ERROR: cpu exception in dosemu code outside of DPMI client!
"
==================================
C:\tmp>asm /B60 inv2;
Arrowsoft Assembler
Public Domain v2.00c (64K Model)
Copyright (c) 1986, 1987 Arrowsoft Systems, Inc.
Free memory=30658, Warnings=0, Errors=0
Assembly Ended.
C:\tmp>warplink /c inv2
WarpLink 2.70 Copyright 1989-93 Michael Devore. All rights reserved.
C:\tmp>ver /r
FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00]
DOS version 7.10
FreeDOS kernel build 2036 cvs [version Aug 18 2006 compiled Aug 18
2006]
C:\tmp>unix uname -a
Linux ubuntu 2.6.24-19-generic #1 SMP Wed Jun 18 14:15:37 UTC 2008
x86_64 GNU/Linux
Jim Leonard
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:5328bc93-29eb-4811...@e34g2000vbm.googlegroups.com...
>
> > 64-bit mode (as designed by AMD) has no native support for V86
> > emulation, so any OS that wants 16-bit support has to fully emulate
> > that part (as DOSEMU allegedly does nowadays).
>
> If DOSEMU has emulated 16-bit support, it should work on non-x86 cpu's.
DOEMU worked (works?) but utilizing the v86 mode of the CPU to provide
a protected area, but I wouldn't use it today (it's over a decade
old). Something like DOSBOX (a DOS "emulator" built specifically for
games but works with most apps) is definitely good enough, and if you
really want true DOS/16-bit/whatever then just run a virtualization
solution like VirtualBox.
Ross Ridge
>64-bit mode (as designed by AMD) has no native support for V86
>emulation, so any OS that wants 16-bit support has to fully emulate
>that part (as DOSEMU allegedly does nowadays).
While you can't switch to virtual 8086 mode directly from 64-bit protected
mode, you can switch to 32-bit protected mode and from there switch to
virtual 8086 mode. I believe that's what DOSEMU does to run MS-DOS apps
on x86_64 versions of Linux.
(And if that didn't work, there's always the old reset the CPU trick..)
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
Rugxulo
On Oct 6, 10:23 am, Ross Ridge <rri...@csclub.uwaterloo.ca> wrote:
> Rugxulo <rugx...@gmail.com> wrote:
> >64-bit mode (as designed by AMD) has no native support for V86
> >emulation, so any OS that wants 16-bit support has to fully emulate
> >that part (as DOSEMU allegedly does nowadays).
>
> While you can't switch to virtual 8086 mode directly from 64-bit protected
> mode, you can switch to 32-bit protected mode and from there switch to
> virtual 8086 mode. I believe that's what DOSEMU does to run MS-DOS apps
> on x86_64 versions of Linux.
I don't know the details, but I doubt that's what happens. At least,
under X I'm pretty sure it doesn't. Who knows what it does in pure
console as root when you want to use direct video access. But if it
switches to 32-bit compatibility / legacy mode, doesn't that freeze /
disable all the running 64-bit stuff?? Wouldn't the kernel have to
have special support for that? No, I think they just fully emulate the
16-bit stuff and other 32-bit stuff runs native. At least, there's a
noticeable delay in 16-bit stuff, but 32-bit runs as normal.
> (And if that didn't work, there's always the old reset the CPU trick..)
You mean LOADALL? I don't think that has been supported on x86 since a
long time.
Rugxulo
On Oct 6, 7:35 am, Jim Leonard <mobyga...@gmail.com> wrote:
> On Oct 5, 12:30 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
>
> > "Rugxulo" <rugx...@gmail.com> wrote in message
>
> >news:5328bc93-29eb-4811...@e34g2000vbm.googlegroups.com...
>
> > > 64-bit mode (as designed by AMD) has no native support for V86
> > > emulation, so any OS that wants 16-bit support has to fully emulate
> > > that part (as DOSEMU allegedly does nowadays).
>
> > If DOSEMU has emulated 16-bit support, it should work on non-x86 cpu's.
>
> DOSEMU worked (works?) but utilizing the v86 mode of the CPU to provide
> a protected area, but I wouldn't use it today (it's over a decade
> old).
Hey, if it works, why not use it? At least some OSes (Win9x) rely on
it, so may as well. And to be honest, it's more like two decades old
now (386 -> 1986), heh. The Pentium's "VME" (virtual interrupt flag?)
made it even faster (hi, JEMM386!).
At one time, NetBSD also could run DOSEMU (vm86 syscall), but I don't
know if they kept up maintenance for that.
> Something like DOSBOX (a DOS "emulator" built specifically for
> games but works with most apps) is definitely good enough,
DOSBox is okay, but the authors specifically shun adding compatibility
and features that games don't need. They have thankfully fixed a few
non-gaming bugs recently in 0.73, but don't expect them to implement a
full DOS. Plus, DOSBox is *extremely* slow running compilers. But the
big advantage is that it can run on non-x86 (albeit slowly) and on
more than just Linux. (It was actually easier for me to run DOSBox on
my Dad's Mac OS X PPC than fooling with getting native stuff.) Plus
sound in DOSEMU seems to be a problem, so DOSBox definitely beats it
there. But you do need at least a 1 Ghz machine or faster just to run
DOSBox at decent (486, heh) speeds. Fine for modern machines but not
fine for older ones.
> and if you really want true DOS/16-bit/whatever then just run a virtualization
> solution like VirtualBox.
VirtualBox is much faster than DOSBox due to its JIT hack, but even it
has bugs (and doesn't run on Win2k anymore). At least OpenSuSE has it
by default, I think. But sharing files with it is very hard, so DOSBox
(or even DOSEMU) definitely wins there.
Ross Ridge
> While you can't switch to virtual 8086 mode directly from 64-bit protected
> mode, you can switch to 32-bit protected mode and from there switch to
> virtual 8086 mode. I believe that's what DOSEMU does to run MS-DOS apps
> on x86_64 versions of Linux.
Rugxulo <rug...@gmail.com> wrote:
>I don't know the details, but I doubt that's what happens. At least,
>under X I'm pretty sure it doesn't. Who knows what it does in pure
>console as root when you want to use direct video access. But if it
>switches to 32-bit compatibility / legacy mode, doesn't that freeze /
>disable all the running 64-bit stuff?? Wouldn't the kernel have to
>have special support for that?
It would work exactly same way it does with a 32-bit kernel except that
it requires two mode transitions to get in and out of virtual 8086 mode
instead of just one. With a 32-bit kernel, DOSEMU doesn't let the MS-DOS
program have direct access to hardware, it doesn't freeze 32-bit "stuff",
and it requires special support in the kernel. On a 64-bit kernel it
would work the same way.
Anyways, looking at the Linux kernel source, it seems it doesn't have
special support for entering virtual 8086 mode in the 64-bit kernel, so
you're right DOSEMU must be using a software CPU emulator on 64-bit Linux.
It's not however a fundamental limitation of the CPU.
>> (And if that didn't work, there's always the old reset the CPU trick..)
>
>You mean LOADALL? I don't think that has been supported on x86 since a
>long time.
No, I mean having the keyboard controller reset the CPU, which was the
only way a 80286 processor could switch back to real mode after entering
protected mode. It's still supported by current PCs. By comparision,
it's easier to real-mode code on a 64-bit operating system than it is
to real-mode code on a 16-bit protected mode operating system.
Terence
> Ross Ridge <rri...@csclub.uwaterloo.ca> wrote:
> > While you can't switch to virtual 8086 mode directly from 64-bit protected
> > mode, you can switch to 32-bit protected mode and from there switch to
> > virtual 8086 mode. I believe that's what DOSEMU does to run MS-DOS apps
> > on x86_64 versions of Linux.
Read with great interest.
Thanks to the carful posters.
Funny, my son just sent me a Commodor-64 emulator, so there's hope fo
a complete reasonably fast DOS emulator in the future.
I don't think that emulating code, even Fortran compiler code, is a
great problem, but emulating the vast DOS service calls would be a
different matter; and its my own use of these to simulate Windows-like
facilities in my DOS software is what I am trying to protect.
I always have the escape route of recompiling our commercial (Fortran)
code with a Windows compiler; but te bloat is a factor of 15 times.
Jim Leonard
> Funny, my son just sent me a Commodor-64 emulator, so there's hope fo
> a complete reasonably fast DOS emulator in the future.
> I don't think that emulating code, even Fortran compiler code, is a
> great problem, but emulating the vast DOS service calls would be a
> different matter; and its my own use of these to simulate Windows-like
> facilities in my DOS software is what I am trying to protect.
You can emulator DOS easily using VirtualBox or vmware, they provide a
virtual CPU/environment so you can run actual DOS. They're very fast.
Terence
I just tried out V.7 on a Dell.
Basically, it works, but doesn't offer full screen among the options,
but you CAN stretch the line length (I treid 170) and change the
default fault font to something that approximates to a full screen
presentation. Line heights are really too short and make reading a
line difficult. I hope a final version will bring back "full screen".
pe...@nospam.demon.co.uk
tbwr...@cantv.net "Terence" writes:
There's an ongoing thread in comp.lang.clipper on the subject of
Win7 and DOS apps which you might find useful.
Pete
--
"We have not inherited the earth from our ancestors,
we have borrowed it from our descendants."