The end of Netburst in 2006

  • Thread starter Thread starter YKhan
  • Start date Start date
keith said:
Not only single-processor, but single *task*. There was no concept of
preemption in 3x or Win95.
Click to expand...

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
 
George said:
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.
Click to expand...

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
 
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.
Click to expand...

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.
 
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?
Click to expand...

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.
 
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).
Click to expand...

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.
 
keith said:
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.
Click to expand...

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.
Click to expand...

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

Yousuf Khan
 
George said:
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.
Click to expand...

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
 
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.
Click to expand...

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.
 
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?
Click to expand...

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.
 
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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

Oh, that's a good one - love it!;-)
 
Keith said:
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.
Click to expand...

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

Yousuf Khan
 
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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

Oh, that's a good one - love it!;-)
Click to expand...

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.
 
Or more likely because they serialized access to the controller through
the device driver by adding queueing buffers in memory.
Click to expand...

More likely because the I/O was 16bit DOS, as was most of the OS. Once in
16bit, everything serialized.
 
keith said:
More likely because the I/O was 16bit DOS, as was most of the OS. Once in
16bit, everything serialized.
Click to expand...

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
 
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:
Click to expand...

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.
Click to expand...

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