Chris2005
Banned
"The 80386 introduced 'virtual 8086' mode. The host OS sets up memory a memory region which looks like classic flat real mode addressing inside of the virtual 8086."
Don't you mean segmented addressing? Or does that happen when virtual-8086 mode gets wrapped up into a command prompt?
"When in virtual 8086 mode the processor behaves just like a real 8088/8086, but with some differences. You can alter memory all you want, but touching I/O ports is a bit of a problem. The host OS has to intercept and decide whether to pass the request through to real hardware, emulate it, or do something else. Depending on the host OS that gives you the ability to touch real hardware directly."
real mode (which even modern processors start up in, then get switched to protected mode by the OS) and virtual-86 mode are two different things though. A processor/OS setups up a virtual machine (or multiples), and that becomes a process as you pointed out. I'm not nitpicking, just trying to understand and get the terminology correct. Then again maybe that is nitpicking...
From what I've read in the distant past, M$ took part in the design of virtual-86 mode, which in reality makes sense because the major impetus was probably to create an environment for all the legacy code built on top of their premier OS. So then, the implementation of a "DOS" prompt was for the purpose of allowing nasty messy old dos apps to run eh unimpeded, so it's going to have to allow low level hardware calls and such, regardless if this is by emulation or not. Printer access and even disk access could be issues, but I thought that disk sectors could be altered (floppy anyway) at least with W95-98. Those are "peripheral" issues though (for many programs, except things like disk editors and whatnot), and "typical" low level access has to be allowed - like accessing the timer chip or whatever.
"You could literally boot DOS 5 in a window..."
If you "run" command.com from the start button, you're executing dos (or at least that version that's specific to the os you're using). NT based OS' aren't "integrated" with a 16 bit dos obviously, so you're running something else? (and please let's not get into a discussion over my using that once nasty nasty term from the Chicago days - integration. I probably should have chose something else altogether).
It's been said on classiccmp recently that you can execute windoze 3.11 (and anything else earlier?) from the command prompt or? run prompt.
"It's certainly easier to exploit a virtual 8086 than it is to write an emulator, but you need access to the host OS."
via DLL's and whatnot?
So essentially I was thinking along the lines that something like the Tandy 2000 could be emulated using virtual-86 mode, depending on if/how you get to tailor the access to low level stuph. Just food for thought.
Don't you mean segmented addressing? Or does that happen when virtual-8086 mode gets wrapped up into a command prompt?
"When in virtual 8086 mode the processor behaves just like a real 8088/8086, but with some differences. You can alter memory all you want, but touching I/O ports is a bit of a problem. The host OS has to intercept and decide whether to pass the request through to real hardware, emulate it, or do something else. Depending on the host OS that gives you the ability to touch real hardware directly."
real mode (which even modern processors start up in, then get switched to protected mode by the OS) and virtual-86 mode are two different things though. A processor/OS setups up a virtual machine (or multiples), and that becomes a process as you pointed out. I'm not nitpicking, just trying to understand and get the terminology correct. Then again maybe that is nitpicking...
From what I've read in the distant past, M$ took part in the design of virtual-86 mode, which in reality makes sense because the major impetus was probably to create an environment for all the legacy code built on top of their premier OS. So then, the implementation of a "DOS" prompt was for the purpose of allowing nasty messy old dos apps to run eh unimpeded, so it's going to have to allow low level hardware calls and such, regardless if this is by emulation or not. Printer access and even disk access could be issues, but I thought that disk sectors could be altered (floppy anyway) at least with W95-98. Those are "peripheral" issues though (for many programs, except things like disk editors and whatnot), and "typical" low level access has to be allowed - like accessing the timer chip or whatever.
"You could literally boot DOS 5 in a window..."
If you "run" command.com from the start button, you're executing dos (or at least that version that's specific to the os you're using). NT based OS' aren't "integrated" with a 16 bit dos obviously, so you're running something else? (and please let's not get into a discussion over my using that once nasty nasty term from the Chicago days - integration. I probably should have chose something else altogether).
It's been said on classiccmp recently that you can execute windoze 3.11 (and anything else earlier?) from the command prompt or? run prompt.
"It's certainly easier to exploit a virtual 8086 than it is to write an emulator, but you need access to the host OS."
via DLL's and whatnot?
So essentially I was thinking along the lines that something like the Tandy 2000 could be emulated using virtual-86 mode, depending on if/how you get to tailor the access to low level stuph. Just food for thought.
