Linked by Thom Holwerda on Fri 3rd Dec 2010 22:14 UTC, submitted by poundsmack
Thread beginning with comment 452147
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
They are not the only ones.
When I was working at CERN, the groups that were part of the experiment I was working on, each had their own threading library.
One of the main discussion points in some of our meetings was when would all groups would use the same library, but they could not agree which library would win being the one.
That is what happens when you mix politics with software development.




Member since:
2009-12-10
When trying to understand Microsoft it is important to realize that the different divisions inside Microsoft effectively act as separate companies within the company.

In particular its important to realize that the .Net team is not the same team as the Windows team and they may not even share the same goals. In the same manner the Office team is also doing their own stuff and having their own agenda.
As an example of this the Office team initially invented the ribbon bar and introduced it in Word 2007. This was done entirely with their own code base and in their own way. Since the ribbon idea seems to be a great success, the upper management of Microsoft probably decided to make it an official OS feature and told the Windows team to implement it. The result is that the ribbon API introduced in Windows 7 has nothing to do with the original ribbons in Office and likewise nothing to do with .Net or WPF. It uses COM, Common Controls and XML.
A different example of this is the UI Automation API (System.Windows.Automation). It was originally created by the .Net team as their way of doing UI automation and accessibility. Windows itself did have an API for this already (called Active Accessibility) but at some point it was decided this new API was superior and should replace the old one. The Windows team therefore once again created official APIs for it and added it to Windows 7. It uses COM, like things always do when it comes from that team.
I don't think anyone at Microsoft really think you should use the old common controls API anymore. It is pretty obvious they only update those controls whenever the shell team needs a new feature and they barely document those new features anyway. I am sure they'd remove them from Win32 if they could, but obviously they cannot since half their own products (and anything based on MFC) uses them.
So what to use instead? Well, I'm pretty sure that if you ask the tools team, they'd answer WPF, because that's what they wrote for you. The office team uses their own controls and technologies. What the Windows team would answer? Now that's the good question. I haven't got a clue.