V86
-
edy42
V86
I was wondering if anyone knew of a good tutorial about, or is able to explain Virtual 8086 mode. I read somewhere that this must be used to run 16 bit x86 code on a 80386 or other IA-32 processor, and I plan to use some of the BIOS functions in my kernel Any help would be appreciated. Thanks.
-
Ozguxxx
Re:V86
Hi, I do not know anything about virtual 8086 mode but it is not just for running 16 bit code on 386+ cpus. If you want to run 16 bit code then you can use real mode, I think what vm8086 supplies is being able to run protected 16 bit code on a 386+ cpus. So it is far more complex than writing simple 16 bit real mode code because you need 16 bit code and also a thing called monitor -some 32 bit code- to "monitor" actual runing code. So I think vm8086 mode can be postponed to not very near future until you think you really need it or you think that you are bored of life and looking for some action. 
-
BI lazy
Re:V86
Oh, but it is not so complicated, once one has got some nitty gritty done: User Process loading for instance - with difference between v86 tasks and normal tasks, a running pager, running multitasking ... and a good gpf handler which does the nitty gritty for the vm86 task - f. ex. "calling" the real mode interrupts (redirecting ip to the corresponding places)
Once I've got multitasking running, the first Usertask I've ever created was the vm86 task - for some graphic mode switches. Grub comes in handy here for it faciliates the loading of several modules along with the kernel: vm86 module, mm service, fs service, gui service, basic shell or init process.
in short vm86 mode faciliates the execution of 16 bit code under the protecting hands of a 32 bit operating system. Not that it is extremely recommendable to do too much with it, but it suffices for switches between graphics mode. Anything else I won't use it for.
stay safe
Once I've got multitasking running, the first Usertask I've ever created was the vm86 task - for some graphic mode switches. Grub comes in handy here for it faciliates the loading of several modules along with the kernel: vm86 module, mm service, fs service, gui service, basic shell or init process.
in short vm86 mode faciliates the execution of 16 bit code under the protecting hands of a 32 bit operating system. Not that it is extremely recommendable to do too much with it, but it suffices for switches between graphics mode. Anything else I won't use it for.
stay safe
-
Xardfir
Re:V86
I don't recommend using VM86 mode at all,
The reason being intel chips are only 'instruction set compatible' NOT 'hardware compatible'.
VM86 on 486 DOES NOT equal VM86 on your shiny new pentium 4.
If your os is to be unix compatible - port BOCHS it'll be easier.
I agree with BI - video switching and nothing else. Intel would be better off putting the silicon in its chips to better use.
The reason being intel chips are only 'instruction set compatible' NOT 'hardware compatible'.
VM86 on 486 DOES NOT equal VM86 on your shiny new pentium 4.
If your os is to be unix compatible - port BOCHS it'll be easier.
I agree with BI - video switching and nothing else. Intel would be better off putting the silicon in its chips to better use.
-
Tim
Re:V86
Er, Xardafir: I agree that newer chips are "instruction set compatible" but not necessarily "hardware compatible" with older ones. But V86 mode is included in instruction set compatibility. A lot of modern software relies on V86 mode -- basically, anything under a 32-bit OS which needs to be 16-bit uses V86 mode. So if Intel changed how that worked without telling anyone, it would break most operating systems.
Software which relies on V86 mode on a 486 will run fine on a Pentium 4, at least as far as the CPU is concerned, although actual non-CPU hardware devices might be different.
Software which relies on V86 mode on a 486 will run fine on a Pentium 4, at least as far as the CPU is concerned, although actual non-CPU hardware devices might be different.
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:V86
No, indeed: from the pentium 2 (iirc), you have options like "Virtual Interrupt Bit" and "VM software interrupts redirection map" that allow you to defer more of the VM supervising hassle to the CPU itself (it will for instance be told that the VM task is allowed to call INT13 but that INT8 still generates a GPF ...)Xardfir wrote: I don't recommend using VM86 mode at all,
The reason being intel chips are only 'instruction set compatible' NOT 'hardware compatible'.
VM86 on 486 DOES NOT equal VM86 on your shiny new pentium 4.
Intel makes sure that what works on CPU will still work on CPU++ -- unless you're using things that are explicitly tagged as "CPU-specific" like the infamous TRx registers on the 386
-
xardfir
Re:V86
Valid points. My post was more directed towards application support under an OS rather than a OS point of view but design choices affect OS design at a very low level.
TIM: So if Intel changed how that worked without telling anyone, it would break most operating systems.
I would put forward the view that application compatibility is so bad today is a result of VM86 not Microsoft/IBM/Linux not providing the neccesary support.
PYPE:from the pentium 2 (iirc), you have options like "Virtual Interrupt Bit" and "VM software interrupts redirection map" that allow you to defer more of the VM supervising hassle to the CPU itself (it will for instance be told that the VM task is allowed to call INT13 but that INT8 still generates a GPF ...)
Intel makes sure that what works on CPU will still work on CPU++ -- unless you're using things that are explicitly tagged as "CPU-specific" like the infamous TRx registers on the 386
A large amount of applications won't run on newer processors because of basic evolution. Chips get faster and newer instructions are added. A 386 will run slower than a pentium which will run slower than a pentium II/III/IV.
Even if an operating system supports a VM86 box (Windows, OS/2) applications will run badly or not at all. So much for compatibility - instruction set 'yes' - hardware 'no'.
A perfect example of VM86 badness is in the CPUID instruction. Why in heavens name didn't INTEL provide a way to selectively disable this instruction in VM86 mode. Programs look for a certain processor and then wham! WRONG PROCESSOR - I CAN'T RUN
Another example is clock cycle matching. You can't simply tell the VM86 box that you want it to match the 'clock cycles per instruction of a certain processor'. A feature like this would improve compatibility to no end - all the processor would have to do, is do nothing for certain clock cycles dpeinding on the setting. The VM86 box would run at the full speed of all the other apps but without all that horrible code to manage VM86 box timing.
INTEL may have supplied the extra virtual extensions but clock speeds had gotten too fast. Instruction set - yes, hardware no. And it's the hardware that't the problem. Just like the lobotomised 286, systems programmers now have to deal with lobotomised VM86 - wonderful idea when invented but today errrrrrr........................
I don't like VM86 mode at all. I would prefer emulation to hardware support. Emulation can give you the ability to 'switch off' CPUID and provide close 'clock cycle' correct timing which means a lot more programs can run.
Hope this moves the brain cells. Merry Christmas / hanakah / whatever :-*
TIM: So if Intel changed how that worked without telling anyone, it would break most operating systems.
I would put forward the view that application compatibility is so bad today is a result of VM86 not Microsoft/IBM/Linux not providing the neccesary support.
PYPE:from the pentium 2 (iirc), you have options like "Virtual Interrupt Bit" and "VM software interrupts redirection map" that allow you to defer more of the VM supervising hassle to the CPU itself (it will for instance be told that the VM task is allowed to call INT13 but that INT8 still generates a GPF ...)
Intel makes sure that what works on CPU will still work on CPU++ -- unless you're using things that are explicitly tagged as "CPU-specific" like the infamous TRx registers on the 386
A large amount of applications won't run on newer processors because of basic evolution. Chips get faster and newer instructions are added. A 386 will run slower than a pentium which will run slower than a pentium II/III/IV.
Even if an operating system supports a VM86 box (Windows, OS/2) applications will run badly or not at all. So much for compatibility - instruction set 'yes' - hardware 'no'.
A perfect example of VM86 badness is in the CPUID instruction. Why in heavens name didn't INTEL provide a way to selectively disable this instruction in VM86 mode. Programs look for a certain processor and then wham! WRONG PROCESSOR - I CAN'T RUN
Another example is clock cycle matching. You can't simply tell the VM86 box that you want it to match the 'clock cycles per instruction of a certain processor'. A feature like this would improve compatibility to no end - all the processor would have to do, is do nothing for certain clock cycles dpeinding on the setting. The VM86 box would run at the full speed of all the other apps but without all that horrible code to manage VM86 box timing.
INTEL may have supplied the extra virtual extensions but clock speeds had gotten too fast. Instruction set - yes, hardware no. And it's the hardware that't the problem. Just like the lobotomised 286, systems programmers now have to deal with lobotomised VM86 - wonderful idea when invented but today errrrrrr........................
I don't like VM86 mode at all. I would prefer emulation to hardware support. Emulation can give you the ability to 'switch off' CPUID and provide close 'clock cycle' correct timing which means a lot more programs can run.
Hope this moves the brain cells. Merry Christmas / hanakah / whatever :-*
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:V86
well, imho, if you need *that* level of detail, what you need is not a Virtual Mode on the CPU, but rather a software emulator "? la" BOCHS or DOSEMU ... note that VM mode may be an efficient way to implement that kind of feature (combined with "slowing down" techniques involving enhanced scheduling)
Note that in most of the times, what makes poor emulation of DOS-based progs in windows bochs comes from:
1. the hardware around the CPU is not emulated (sound cards, etc)
2. the so-called 8086 Dos program is trying to switch to protected mode
3. the emulated program tries to detect a WIN3.x environment to complaint it cannot run within it and thus Win9x may try hard to provide that requested environment ... (pure speculation)
Note that in most of the times, what makes poor emulation of DOS-based progs in windows bochs comes from:
1. the hardware around the CPU is not emulated (sound cards, etc)
2. the so-called 8086 Dos program is trying to switch to protected mode
3. the emulated program tries to detect a WIN3.x environment to complaint it cannot run within it and thus Win9x may try hard to provide that requested environment ... (pure speculation)
-
Tim
Re:V86
Bad applications cause bad application compatibility. Developers want to do something but they don't see how to do it using the documented interfaces. They hack around internal OS data structures and put together something that works. OS developer releases a new version of the OS and of course these internal data structures have changed (and when I say 'data structures', I'm including things like the layout of local variables on the OS's stack). The original developer's application breaks. Whom do the users blame? Not the application developer, because their program always used to work: they blame the OS that they just installed. So the OS developer needs to identify these broken applications, work out what they're relying on, and put in specific fixes to keep them working.xardfir wrote: I would put forward the view that application compatibility is so bad today is a result of VM86 not Microsoft/IBM/Linux not providing the neccesary support.
The full article from a Windows developer at Microsoft:
http://weblogs.asp.net/oldnewthing/arch ... 45481.aspx
This problem is less common on open source systems as the source code to the apps/the OS is available, and it's easier to demand that users upgrade to the latest version instead of applying a patch. It can happen with hardware, though -- look at unreal mode, which Intel has committed to supporting (because they have documented it, in a way) in the IA-32 architecture.
-
Xardfir
Re:V86
Perhaps my view shoud be phrased thus:
If edy42 is looking to use VM86 in his OS for system control puposes fine, but if he is seeking to provide application compatibility he should use emulation to avoid the pitfalls in software (as Tim mentioned) and problems with actual hardware limitations that I've listed before. At least if your OS runs BOCHS et al. you can boot up a 'real' DOS + windows + linux and avoid the software compatibility. Providing hardware compatibility should also be a simple matter of recompiling BOCHS to supply a particular environment (386, 486, pentium) - perhaps BOCHS developers will offer this as an dynamic option one day.
Providing the emulation option also puts paid to the 'My new OS can run everything' startups that constantly pop up.
The fun is in developing your own OS (with enough capability to run the emulator) - but allowing the emulator run all the rest of the code (good or bad).
Happy new year to all
If edy42 is looking to use VM86 in his OS for system control puposes fine, but if he is seeking to provide application compatibility he should use emulation to avoid the pitfalls in software (as Tim mentioned) and problems with actual hardware limitations that I've listed before. At least if your OS runs BOCHS et al. you can boot up a 'real' DOS + windows + linux and avoid the software compatibility. Providing hardware compatibility should also be a simple matter of recompiling BOCHS to supply a particular environment (386, 486, pentium) - perhaps BOCHS developers will offer this as an dynamic option one day.
Providing the emulation option also puts paid to the 'My new OS can run everything' startups that constantly pop up.
The fun is in developing your own OS (with enough capability to run the emulator) - but allowing the emulator run all the rest of the code (good or bad).
Happy new year to all
-
Tim
Re:V86
The point of V86 mode is to run 16-bit apps directly on the CPU while still allowing the OS to selectively disallow or emulate sensitive operations. Any privileged instruction will generate an exception, giving the OS the choice of emulating that instruction, providing entirely virtual devices to applications -- look at NTVDM's Sound Blaster support; or denying the operation and telling the user "your program did a bad thing".
I do not believe Xardfir's complaints about the hardware are relevant to most applications, since they apply to running 16-bit apps in real mode too. Your new computer is running your old DOS game too fast? Sorry, it wasn't written with 2004-spec machines in mind -- find a slower computer. Your old DOS game is looking for a specific CPU? Again, it wasn't written to be forward compatible. The only way to run such (brain-dead) old programs is through an emulator, or on the hardware they were designed to run on. However, there are a lot of applications which aren't brain-dead, and which will run acceptably on a V86 monitor. V86 monitors such as NTVDM on NT, DOSEMU on Linux and VMM on Win9x should be the default choice for running 16-bit apps on newer operating systems. If they don't work -- you might have some luck in an emulator.
As I have said before, V86 mode has a much more important use for we amateur OS developers: running high-res graphics in our operating systems. It's not perfect, but putting together a V86 monitor to use when you want to call INT 10h is a far better solution than stopping the OS, dropping down to real mode, making the call, then switching back to protected mode again. VESA isn't the best solution, but it's all most of us have. I shudder to think of a GUI which switches to real mode to switch banks on a non-LFB card. To do this is to revert to pre-386 technology.
I do not believe Xardfir's complaints about the hardware are relevant to most applications, since they apply to running 16-bit apps in real mode too. Your new computer is running your old DOS game too fast? Sorry, it wasn't written with 2004-spec machines in mind -- find a slower computer. Your old DOS game is looking for a specific CPU? Again, it wasn't written to be forward compatible. The only way to run such (brain-dead) old programs is through an emulator, or on the hardware they were designed to run on. However, there are a lot of applications which aren't brain-dead, and which will run acceptably on a V86 monitor. V86 monitors such as NTVDM on NT, DOSEMU on Linux and VMM on Win9x should be the default choice for running 16-bit apps on newer operating systems. If they don't work -- you might have some luck in an emulator.
As I have said before, V86 mode has a much more important use for we amateur OS developers: running high-res graphics in our operating systems. It's not perfect, but putting together a V86 monitor to use when you want to call INT 10h is a far better solution than stopping the OS, dropping down to real mode, making the call, then switching back to protected mode again. VESA isn't the best solution, but it's all most of us have. I shudder to think of a GUI which switches to real mode to switch banks on a non-LFB card. To do this is to revert to pre-386 technology.
-
xardfir
Re:V86
1). Doesn't it suck then how we have to kludge our OS's to get simple video working whilst the mainstream vendors get direct access to programming API's? Are the manufacturers scared to lose business by people being able to program their cards. Aren't we soooo lucky they let us have VESA :-\
2). I wouldn't consider applications written after 1993 to be (brain-dead). Already programs written 3 years ago are now non-functional on my pentium 4 due to hardware 'glitchiness' (so much for compatibility). Yes I have 10 computers and all the software that goes with them and I use them all because they do what I want them to do. And no I'm not one of those who hangs onto old technology.
The only reason I see then for VM86 mode existing is for Video mode switching. I'd be interested to know of any other uses for it. And no not for running realmode tasks
Final thought - why didn't VESA include a protected mode mode switching function in the original VESA specs? If they had, would VM86 be of any relevance?
Final thought 2 - I've just been reading about the internal structure of WIN3.1, in enhanced mode every program ran in a VM86 box (32bit, 16bit, DOS) with code shared between the boxes. Did any of this kind of thing occur in WIN NT/95 etc? If so would it explain the extra 'features' we have come so used to ;D?
Looking forward to your reply
2). I wouldn't consider applications written after 1993 to be (brain-dead). Already programs written 3 years ago are now non-functional on my pentium 4 due to hardware 'glitchiness' (so much for compatibility). Yes I have 10 computers and all the software that goes with them and I use them all because they do what I want them to do. And no I'm not one of those who hangs onto old technology.
The only reason I see then for VM86 mode existing is for Video mode switching. I'd be interested to know of any other uses for it. And no not for running realmode tasks
Final thought - why didn't VESA include a protected mode mode switching function in the original VESA specs? If they had, would VM86 be of any relevance?
Final thought 2 - I've just been reading about the internal structure of WIN3.1, in enhanced mode every program ran in a VM86 box (32bit, 16bit, DOS) with code shared between the boxes. Did any of this kind of thing occur in WIN NT/95 etc? If so would it explain the extra 'features' we have come so used to ;D?
Looking forward to your reply
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:V86
VeSA 3.0 does have a full-pmode programming interface. However, it is not available on all graphic cards, and even modern (okay, cheap modern, but modern anyway) cards does not support it.xardfir wrote:
Final thought - why didn't VESA include a protected mode mode switching function in the original VESA specs? If they had, would VM86 be of any relevance?
And about the non-disclosure of information, why would GfxCorp provide documentation for free if they can provide homemade drivers for their target customers (just like for WinModemSellersCorp) ? ... It will require them to produce the technical doc for the chip's interface, have a consistent (not ever-changing) interface, etc. that most programmers doesn't care of as they go through OpenGL, DRI or their windowz counterpart anyway ...