The end of Netburst in 2006

[YKhan]

Not only single-processor, but single *task*. There was no concept of
preemption in 3x or Win95.

Windows 95 was definitely pre-emptive, that was one of the big
improvements from Win3x to 95. And Windows 3.x was able to preempt DOS
boxes (Virtual-8086 DOS apps).

Yousuf Khan

 

[YKhan]

Back then virtualization was not that well known at the desktop level - I
don't see how that could have helped them that much. They also were making
money on QEMM386 because it took M$ 7-8 years to figure it out and they
never quite got there.

Well, it could've helped them if they could've virtualized Windows
underneath a Desqview supervisor. They were able to do it, in a
severely restricted fashion: they could run Windows 3.x in "Standard"
mode (which was basically a 16-bit protected mode), but not in
"Enhanced" mode (which was a 32-bit protected mode). That was because
Microsoft never implemented the DPMI (DOS Protected Mode Interface)
standards properly -- strange considering it was Microsoft's own
standard -- DPMI apps should be able to act as both DPMI master or
slave if there is already another DPMI master present, Windows could
only be a master.

But Qemm could've been modified to become a hypervisor much like what
VMWare eventually did. Qemm had the ability to trap privileged
instructions and if instead of just shutting down an errant program, it
actually tried to accomodate it with emulated instructions, it would've
become a virtualizer.

Yousuf Khan

 

[George Macdonald]

Well, it could've helped them if they could've virtualized Windows
underneath a Desqview supervisor. They were able to do it, in a
severely restricted fashion: they could run Windows 3.x in "Standard"
mode (which was basically a 16-bit protected mode), but not in
"Enhanced" mode (which was a 32-bit protected mode). That was because
Microsoft never implemented the DPMI (DOS Protected Mode Interface)
standards properly -- strange considering it was Microsoft's own
standard -- DPMI apps should be able to act as both DPMI master or
slave if there is already another DPMI master present, Windows could
only be a master.

That's a bit much calling DPMI Microsoft's standard. It was only an
attempt to put a M$ moniker on VCPI and fit it into M$'s framework. Gates
himself had long meetings with Robert Smith of Phar Lap to learn how to do
this stuff. It was obvious why M$ did not want to implement the full DPMI
1.0 specs - Phar Lap, which was the leader in DOS Extenders, got Phucked.

This was all the usual order of business ofr M$: "collaborate" with
"partners" so you can steal their ideas/technology and shut them down.

 

[keith]

Not on the desktop? Well not for everybody but there was VM/PC on an
AT/370 card... or was that just a name? I guess it didn't really do VM did
it? BTW any idea if there is still such a card as the AT/370 for a modern
machine and how one obtains one and at what cost?

I'm not sure I'd put these too far in the "virtual" bucket. They were
rather software and memory limited, not to mention single user.
(Small) point taken though.

 

[keith]

Windows 95 was definitely pre-emptive, that was one of the big
improvements from Win3x to 95. And Windows 3.x was able to preempt DOS
boxes (Virtual-8086 DOS apps).

NO it certainly wasn't. Win95 couldn't walk and chew gum at the same
time. It was advertised as (cooperative) multi-tasking, which meant that
it wasn't at all. Win95 was pretty much a shell over Win3.x. OS/2 would
turn circles around Win95, simply because it *WAS* a preemptive
multi-tasking system. Remember the CZ-1000 IDE controller? It worked
fine on Win95 because it *couldn't* multi-task.

 

[YKhan]

NO it certainly wasn't. Win95 couldn't walk and chew gum at the same
time. It was advertised as (cooperative) multi-tasking, which meant that
it wasn't at all. Win95 was pretty much a shell over Win3.x. OS/2 would
turn circles around Win95, simply because it *WAS* a preemptive
multi-tasking system.

Windows 95 was definitely pre-emptively multitasked. Sure, the old
16-bit Windows apps continued to be multitasked cooperatively, but the
whole 16-bit Windows environment was put into its own virtual machine
and that virtual machine was preemptively multitasked in the bigger
32-bit context. All 32-bit apps were preemptively multitasked.

Remember the CZ-1000 IDE controller? It worked
fine on Win95 because it *couldn't* multi-task.

No, I don't remember it, but what's hardware gotta do with how programs
are multitasked?

Yousuf Khan

 

[YKhan]

That's a bit much calling DPMI Microsoft's standard. It was only an
attempt to put a M$ moniker on VCPI and fit it into M$'s framework. Gates
himself had long meetings with Robert Smith of Phar Lap to learn how to do
this stuff. It was obvious why M$ did not want to implement the full DPMI
1.0 specs - Phar Lap, which was the leader in DOS Extenders, got Phucked.

This was all the usual order of business ofr M$: "collaborate" with
"partners" so you can steal their ideas/technology and shut them down.

I think DPMI 0.9 was entirely Microsoft's baby. DPMI 1.0 was supposed
to be what brought VCPI together with DPMI. But Microsoft's compliance
never exceeded 0.9 level.

Yousuf Khan

 

[George Macdonald]

I think DPMI 0.9 was entirely Microsoft's baby. DPMI 1.0 was supposed
to be what brought VCPI together with DPMI. But Microsoft's compliance
never exceeded 0.9 level.

It's all hazy to me now - it could be that M$ invented DPMI when they
finally had to sell some DOS Protected Mode software... maybe around the
time they acquired FoxPro and then they had a half hearted attempt at DOS
Protected Mode with their Powerstation compiler - not sure what all the
dates would be. I'm pretty sure there was "collaboration", with Phar Lap
at least, in DPMI's definition.

 

[Keith R. Williams]

Windows 95 was definitely pre-emptively multitasked. Sure, the old
16-bit Windows apps continued to be multitasked cooperatively, but the
whole 16-bit Windows environment was put into its own virtual machine
and that virtual machine was preemptively multitasked in the bigger
32-bit context. All 32-bit apps were preemptively multitasked.


No, I don't remember it, but what's hardware gotta do with how programs
are multitasked?

Good grief, Yousuf. Don't you think the first place you'd see multi-
tasking is in the I/O? If there were two tasks issued to the
controller at the right (wrong) time, it decided to clip two bytes off
one of the buffers; the file just lost two bytes (can you say bit-
rot?). This problem *never* appeared in Win95 because two transactions
couldn't happen. Win95 was mostly a prettier DOS shell than Win3.1.

BTW, the CMD CZ-1000 (I think that was the number anyway[*]) was a rip-
off of one of the early Intel PCI IDE controllers, right down to this
bug.

[*]I'd look it up, but I have no internet access here.

 

[George Macdonald]

Good grief, Yousuf. Don't you think the first place you'd see multi-
tasking is in the I/O? If there were two tasks issued to the
controller at the right (wrong) time, it decided to clip two bytes off
one of the buffers; the file just lost two bytes (can you say bit-
rot?). This problem *never* appeared in Win95 because two transactions
couldn't happen. Win95 was mostly a prettier DOS shell than Win3.1.

The way I remember it was that that IDE controller, and some others, could
only work in "serialized transaction" mode, which placed some restrictions
on the IDE driver in PIO Mode and ruled out Bus Mastering mode completely.
Win95(A) never had Bus Mastering driver support but Win95(B) (sort of)
did... if you count the driver of the week comedy we went through with
Intel et.al. at that time.

The way I recall it, even from the start, Win95 *was* sold as having
preemptive multitasking; OTOH anyone who used it could be excused for
thinking that it didn't. Again, it's hazy, but as I recall that was as
much to do with the legacy 16-bit GUI compatibility and the infamous
"Windows Resources" as anything else.

BTW, the CMD CZ-1000 (I think that was the number anyway[*]) was a rip-
off of one of the early Intel PCI IDE controllers, right down to this
bug.

Yep I definitely recall that sinking feeling every time I saw "CMD IDE
Controller" in Device Manager of a new system.

[*]I'd look it up, but I have no internet access here.

Oh, that's a good one - love it!;-)

 

[YKhan]

Good grief, Yousuf. Don't you think the first place you'd see multi-
tasking is in the I/O? If there were two tasks issued to the
controller at the right (wrong) time, it decided to clip two bytes off
one of the buffers; the file just lost two bytes (can you say bit-
rot?). This problem *never* appeared in Win95 because two transactions
couldn't happen. Win95 was mostly a prettier DOS shell than Win3.1.

Or more likely because they serialized access to the controller through
the device driver by adding queueing buffers in memory.

Yousuf Khan

 

[keith]

The way I remember it was that that IDE controller, and some others, could
only work in "serialized transaction" mode, which placed some restrictions
on the IDE driver in PIO Mode and ruled out Bus Mastering mode completely.
Win95(A) never had Bus Mastering driver support but Win95(B) (sort of)
did... if you count the driver of the week comedy we went through with
Intel et.al. at that time.

The way I recall it, even from the start, Win95 *was* sold as having
preemptive multitasking; OTOH anyone who used it could be excused for
thinking that it didn't. Again, it's hazy, but as I recall that was as
much to do with the legacy 16-bit GUI compatibility and the infamous
"Windows Resources" as anything else.

It may have been sold that way, but it didn't work in this reality.

BTW, the CMD CZ-1000 (I think that was the number anyway[*]) was a rip-
off of one of the early Intel PCI IDE controllers, right down to this
bug.

Yep I definitely recall that sinking feeling every time I saw "CMD IDE
Controller" in Device Manager of a new system.

[*]I'd look it up, but I have no internet access here.

Oh, that's a good one - love it!;-)

You've never heard of off-line news-reading? ;-) I was in Maine for the
weekend (anniversary) and there are no local dial-up POPs in the southern
part of the state. To get access I had to go down the hill to the lobby,
where they had an open WiFi warm-spot. "Here" was in our room.

 

[keith]

Or more likely because they serialized access to the controller through
the device driver by adding queueing buffers in memory.

More likely because the I/O was 16bit DOS, as was most of the OS. Once in
16bit, everything serialized.

 

[Yousuf Khan]

More likely because the I/O was 16bit DOS, as was most of the OS. Once in
16bit, everything serialized.

Doubtful, since the 32-bit disk device drivers first started appearing
with Windows 3.1. I can recall there were tons of concern about this
fact:

"Microsoft is going to do what? They're going to replace the BIOS
routines with 32-bit protected mode device drivers? Why? What's wrong
with the BIOS? The BIOS has been handling disk i/o since the beginning
of the PC, it's got the job nailed down tight. How could they possibly
improve upon the BIOS? This is Microsoft, the first implementations of
the drivers are bound to be flakey. So why not just use the BIOS? ",
&c.

Of course, we've never looked back, the BIOS is barely used to do
anything other than create the initial disk drive maps which it then
hands to the OS now.

Yousuf Khan

 

[keith]

Doubtful, since the 32-bit disk device drivers first started appearing
with Windows 3.1. I can recall there were tons of concern about this
fact:

There is a lot more to the filesystem than device drivers.

"Microsoft is going to do what? They're going to replace the BIOS
routines with 32-bit protected mode device drivers? Why? What's wrong
with the BIOS? The BIOS has been handling disk i/o since the beginning
of the PC, it's got the job nailed down tight. How could they possibly
improve upon the BIOS? This is Microsoft, the first implementations of
the drivers are bound to be flakey. So why not just use the BIOS? ",
&c.

Of course, we've never looked back, the BIOS is barely used to do
anything other than create the initial disk drive maps which it then
hands to the OS now.

Oh, please tell me more (obvious stuff). Sheesh!