ml2mst wrote:
> Mark Kent schreef:
>> Peter Köhlmann <peter.koehlmann@xxxxxxxx> espoused:
>>> Mark Kent wrote:
>>>
>>>> Linonut <linonut@xxxxxxxxxxxxx> espoused:
>>>>> * Tim Smith peremptorily fired off this memo:
>>>>>
>>>>>> In article <NEJmk.5818$rD2.1387@xxxxxxxxxxxxxxxxxxxxxx>,
>>>>>> Linonut <linonut@xxxxxxxxxxxxx> wrote:
>>>>>>>> http://www.illuminata.com/perspectives/?p=347
>>>>>> Basically, it uses Linux as a sort of super-GRUB to set up the
>>>>>> hardware,
>>>>>> and load the ESX kernel, then the ESX kernel takes over. Then,
>>>>>> cleverly, to get a virtual machine running Linux, to use as a
>>>>>> management console, it uses that Linux to initialize a virtual
>>>>>> machine.
>>>>>>
>>>>>> This is a very sensible approach. You are going to use Linux in a VM
>>>>>> as a management console, so you are going to have a full Linux on the
>>>>>> disk
>>>>>> anyway. That Linux contains code to detect and initialize hardware.
>>>>>> So, instead of duplicating all that functionality in your kernel, let
>>>>>> Linux boot the hardware and set it up, then your kernel steps in and
>>>>>> pushes Linux aside.
>>>>>>
>>>>>> IBM did a similar thing in OS/2. After the BIOS loaded OS/2 and
>>>>>> started it, OS/2 would create a V86 task, and initialize that with
>>>>>> the BIOS and
>>>>>> its state. Then, if you had hardware that OS/2 did not know about
>>>>>> but that the BIOS did, OS/2 would use that virtual BIOS to access
>>>>>> that hardware.
>>>>>>
>>>>>> Come to think of it, Windows 95 did a similar thing with DOS. DOS
>>>>>> would initialize the hardware, load Windows 95, then Windows 95 would
>>>>>> virtualize that DOS.
>>>>> Thanks for that summary and history, Tim.
>>>>>
>>>> Windows 95 would virtualise the DOS? I don't think so.
>>> It did. Tim is right about that
>>
>> Not as I recall.
>>
>>>
>>>>> (Cue some jerk to call me a brown-noser for actually being nice to
>>>>> someone.)
>>>> I think his final claim is just wrong. A "thunk" layer springs to
>>>> mind, although I forget the details.
>>>>
>>> A thunking layer is something different
>>>
>>
>> I think you're confusing the dos window with the resident DOS 7.
>
> Correct, Windows (up to ME) was loaded as a bunch of extensions on top
> of DOS.
>
> It was easy to load in plain 16 bit DOS, using the following "trick":
>
> - ATTRIB c:\msdos.sys -r -s -h
> - EDIT c:\msdos.sys
> - add in the top section: BootMenu=1
> - ATTRIB c:\msdos.sys +r +s +h
>
> From now on, you would be presented by a bootmenu, after the bootstrap.
> So you were able to boot in "plain DOS". How ever, some extensions where
> loaded by default.
>
> To fire up some DOS games, that required at least 512 KB RAM, you had to
> choose option 5. from the bootmenu (confirm every step). In which
> you've had to skip quite a lot. Other wise these games would not work
> run (insufficient memory).
>
> Unfortunately this option was removed in Windows ME and required a
> separate boot diskette.
>
> Windows (up to ME) was fully DOS-based.
>
Only during boot.
After Win9x got the drivers loaded and was in control, the underlying DOS
was virtualized.
--
This problem was sponsored by Microsoft
|
|
