Post a Comment
Raymond Chen's blog is my favorite among Microsoft employees. He shows great insight into the design decisions of Windows (things like why do we have both find.exe and findstr.exe at the same time, or how was Windows memory manager changed to acomodate for SimCity's bug).
It looks like there are different cultures at Microsoft. While the business side is definitely not my favorite, there are still some technical guys who care.
Edited 2013-02-09 20:34 UTC
The technical side is pretty good.
I used to have my share of issues about Microsoft until I worked in a few Fortune 500 companies.
Then I realized how they are seen from the outside and the differences between engineering, marketing and business.
Eventually I came to understand why Microsoft does certain things.
Rupert Murdoch ( http://en.wikipedia.org/wiki/Rupert_Murdoch ) and his companies are good examples of this. Microsoft doesn't even touch the shit these guys pull off.
Same here. While I tend to take issue with a lot of the company's actions, it's often pretty clear that the developers themselves - for the most part - are commendable. They're not the ones who sue other companies, they're not the ones who make the decision not to play nice with others, and they're not the ones who spread FUD (again, for the most part). They just tend to be a bunch of people wanting to do some really cool stuff with the mighty resources M$ has, and who hope that what they create manages to slip through the management/marketing/legal divisions unscathed.
And all the backwards compatibility stuff that people complain about...that takes a huge amount of work. The fact that Windows can completely change its kernel and graphical implementation without breaking most programs written 20+ years ago is nothing short of an engineering miracle.
siride,
"The fact that Windows can completely change its kernel and graphical implementation without breaking most programs written 20+ years ago is nothing short of an engineering miracle."
I mostly agree, but it hasn't been completely smooth. Some of the stuff I wrote in VB in the 90s stopped working. Of course the only reason I found out was because I was poking around my early career archive for fun. Someone would need to test a large sample of software from that era to assess how well compatibility has held up in general.
Another article that was along these lines:
http://www.osnews.com/story/26623/Why_was_Pinball_removed_from_Wind...
Keyword "mostly".
And, in any case, it's much better than compared to OS X or, especially, Linux. You have to rewrite programs written for different versions of the same GUI toolkit. The only thing you can really count on is the kernel interface and, to a greater or lesser extent, glibc's interface. Everything else is subject to change (and change it does).
By the standards of the day, I suspect DOS worked as well on the 286 as it did on the 386. But yea if by modern OS you mean something that used protected mode for process isolation and timeslicing, then 386 was the first serious intel processor for that.
It predates my experience, but my understanding is that the 286 included a very buggy form of protected mode, and lacked VM86 real mode virtualization. The silly engineers at intel failed to include a way to switch the processor out of protected mode, so the chipset makers actually incorporated external logic to do a hard reset on the processor every time one needed to switch between real mode programs.
So this is how windows multitasked on the 286, by continually rebooting the cpu - a feature MS continued to include a couple generations later. I kid 
It predates my experience, but my understanding is that the 286 included a very buggy form of protected mode, and lacked VM86 real mode virtualization. The silly engineers at intel failed to include a way to switch the processor out of protected mode, so the chipset makers actually incorporated external logic to do a hard reset on the processor every time one needed to switch between real mode programs.
So this is how windows multitasked on the 286, by continually rebooting the cpu - a feature MS continued to include a couple generations later. I kid
You got it wrong. Let me explain as I was already a long time computer user on those days.
The 80286 already had everything a CPU needs for modern operating systems, at least 16 bit ones.
What happened was that Intel thought everyone would be so amazed with the possibilities of protected mode, that no one would care for real mode any longer, hence the no inclusion of programming instructions to switch back to real mode.
But MS-DOS users were reluctant to go 100% to Windows 3.0, specially given the hardware restrictions, lack of software and the novelty of the GUI for many of them.
So Microsoft needed a way to keep MS-DOS applications running inside Windows 3.0, that is how the continuous reset on Windows came to be.
And history replayed itself with long mode.
But long mode isn't nearly as bad as 80286 protected mode, and it wasn't invented by Intel. You can still run legacy code on 64-bit processors just fine. It's just more painful than it was. But it's 2013 and if you need to run 16-bit real mode programs, you neither need a modern processor nor a modern OS.
It's possible to switch from long mode, it isn't even hard (just setup the new environment with interrupts disabled and then clear the long mode bit).
In comparison the only way to return to real mode in the 80286 was to setup some data in the realtime clock module and then do a hardware reset. When the processor have initialized it jumps to the reset vector in the BIOS and pretty early the BIOS code checks the RTC memory and if enabled it jumps to a specified code location.
moondevil,
"You got it wrong. Let me explain as I was already a long time computer user on those days."
I actually agree with everything (else) in your post, but was anything factually wrong in mine? It's definitely possible but your response didn't make it clear what is wrong.
I find it very strange how intel failed to anticipate the need for a mode switch, but mainboard manufacturers did by implementing the external 286 reset logic. Was there an early generation of 286 mainboards which didn't support a cpu reset?
Your comment:
This was only required if you needed to start a MS-DOS program from inside Windows. Otherwise it was running in full 16 bit protected mode with all required features.
I am not sure, but that could have been the case with Xenix systems, which did not require MS-DOS compatibility.
moondevil,
"This was only required if you needed to start a MS-DOS program from inside Windows. Otherwise it was running in full 16 bit protected mode with all required features."
Yes of course, software could be built for the 16bit protected mode. If you want to say the 286 was capable of multi-tasking, then I'll have to admit that it's technically true, but it required all software to be rewritten for it. The 386 was intel's first processor suited for general purpose multi-tasking, that's my opinion anyways because the 286 needed external chipset logic to continuously reset itself into real mode to run the majority of software avaiable at the time.
Edited 2013-02-10 21:04 UTC
"You got it wrong. Let me explain as I was already a long time computer user on those days."
I actually agree with everything (else) in your post, but was anything factually wrong in mine? It's definitely possible but your response didn't make it clear what is wrong.
I find it very strange how intel failed to anticipate the need for a mode switch, but mainboard manufacturers did by implementing the external 286 reset logic. Was there an early generation of 286 mainboards which didn't support a cpu reset?
No. There could perhaps be mainboards that doesn't support the reset protocol needed but that's unlikely.
Doing the reset itself can be done in software without extra hardware by triggering a triple fault, just load the interrupt description table pointer with something faulty and then do a software interrupt.
Megol,
"Doing the reset itself can be done in software without extra hardware by triggering a triple fault, just load the interrupt description table pointer with something faulty and then do a software interrupt."
Ah, very clever! And here I was thinking it was an oversight by the bastards at intel, how wrong I was. My faith is restored 
Yeah, I was floored when I found out that you couldn't switch out of protected mode on the 286. I think they really learned their compatibility lesson with that, because almost all processors afterwards have been great at adding new features and modes without destroying the ability to use legacy software. DOS still boots on modern processors.
Microsoft had a license to use the Apple user interface. Apple argued that the license only applied to Windows 1.0, and not to any subsequent release of Windows!?
Yeah, it was a totally bizarre argument. Apple lost -- as they should.
Digital Research did not have a license to use the Apple user interface. This was before the look-and-feel issue was completely settled, and they didn't have a fallback defense.
History is repeating itself in the phone world. Microsoft has a patent cross-licensing agreement with Apple. Most of the other players don't.
Edited 2013-02-10 17:39 UTC
Windows 3.1 had multiple Kernels too. Windows 95 shifted the differences tot he HAL, but there were multiple HAL's for the different processor families (AMD, INTEL, Cyrix etc) and if you installed Window 95 on one box, the HAL might be so specific that it wouldn't actually boot without a lot of effort on another. That issue still exists with XP (if you've ever tried to move an XP hard disk, or VM image even, to a new [virtual] machine, you'll know this specific pain.)




