| Imagine a symphony orchestra where the violins and the percussion sections had different versions of the score. It would require a heroic effort to play the simplest musical composition. This is the life of the Windows developer. Do I use MFC? Visual Basic or C++? ODBC or OLEDB? COM interface or C-style API? Even within COM: Do I use IDispatch, dual, or pure v-table interfaces? Where does the Internet fit into all of this? Either the design had to be contorted by the implementation technologies that the developers understood or the developers had to learn yet another technological approach that was bound to change in about two years . Deployment of applications can be a chore. Critical entries have to be made in a Registry that is fragile and difficult to back up. There is no good versioning strategy for components . New releases can break existing programs, often with no information about what went wrong. Given the problems with the Registry, other technologies used other configuration stores, such as a metabase or SQL Server. Security in Win32 is another problem. It is difficult to understand and difficult to use. Many developers ignored it. Developers who needed to apply security often did the best they could with a difficult programming model. The rise of Internet-based security threats transforms a bad situation into a potential nightmare. Despite Microsoft's efforts to make development easier, problems remained. Many system services had to be written from scratch, essentially providing the plumbing code that had nothing to do with your business logic. MTS/COM+ was a giant step in the direction of providing higher level services, but it required yet another development paradigm. COM made real component programming possible. Nonetheless, you either did it simply, but inflexibly, in Visual Basic, or powerfully, but with great difficulty, in C++, because of all the repetitive plumbing code you had to write in C++. | 
