7 ms·

I wonder what the overall adoption rates are for UWP. As someone who's written Windows software since the 90s, I can't shake the feeling that Microsoft just ch

I wonder what the overall adoption rates are for UWP. As someone who's written Windows software since the 90s, I can't shake the feeling that Microsoft just churns out completely new development stacks every few years.

DaiPlusPlus 8y ago
This is exactly what is holding back Win32: there has not been any serious development of the desktop developer story since WPF in 2005 (WPF only received token updates since then, the last major update was in 2010 when they finally added a DataGrid control, lol) - but WPF is not well-suited for many types of software which have to fall-back on “pure” Win32 and the story there is nothing but depressing. Apple got it right with Cocoa (nee Nextstep) - it’s something they have been gradually building on with incremental improvements, continuously forwards and upwards - whereas Microsoft has been launching new, short-lived and incompatible (and incomplete) platforms for the past 15 years: WinForms, WPF, Silverlight, Jupiter (Win 8.1), UWP (Win10), etc. The story is so bad Microsoft’s own flagship software has to build their own UI frameworks (Office has its own, Windows Media Center had some arcane prototype of WPF, even the Windows 10 Start Menu uses some UI+Graphics framework that’s not exposed to third-party developers). Win32 needs some serious work - not least because Win32 is “infected” with GDI which has its own issues. WinRT was nice but nowhere near sufficient.
- TazeTSchnitzel 8y ago
  When Apple introduced Cocoa they also introduced Carbon however, an extension of the legacy MacOS APIs. Apple already slowly killed their Win32.
  - simongray 8y ago
    It's actually kind of impressive how much transitional stuff Apple has introduced and then removed with Mac OS X and how right many of their decisions turned out. I guess Cocoa itself was an extension of the legacy NextStep API too. They also had Classic for running old Mac apps directly in OSX and later Rosetta for running PowerPC binaries on Intel (I guess the same tech was used for the 32->64 bit transition). So many technologies have been smoothly deprecated and removed over the years by Apple.
    - pjmlp 8y ago
      Because Apple does the "take it our way or leave" approach. Which is also a reason why they hardly have a meaningful market share across the enterprise world.
      - scarface74 8y ago
        Sure they do. It’s on mobile. While MS isn’t going anywhere in the Enterprise, anyone who is focused on the desktop when it comes to MS development instead of web, cloud, or even cross platform mobile development is headed down a dead end.
        pjmlp 8y ago
        A little secret, laptops and 2-1 convertibles are desktops as well, while being mobile.
        scarface74 8y ago
        If we want to be pedantic, a desktop could be considered mobile too since you can pick it up. But in the real world when people talk about “mobile software” everyone knows that people are talking about iOS and Android. No one is chasing after the Windows software market, it’s been a diminishing platform for the past decade.
        pjmlp 8y ago
        In the real world people are working on laptops, while using iOS and Android mostly to consume content, play games, browse web and show plane tickets. When they actually become a match to laptops and 2-1 convertibles, maybe. And there Chromebooks are no where to be seen outside US school system, iPad Pros are mostly a gimmick in rich countries and Android 2-1 are basically phone apps with keyboard.
        scarface74 8y ago
  - ken 8y ago
    Yes and no. They've taken down the documentation, but there's still a number of (non-GUI, non-kernel) Carbon APIs that are still not deprecated (as of 10.11, at least), and still allowed in the Mac App Store. I'm using AHGotoPage() because NSHelpManager has no equivalent and nobody has been able to explain to me how to make that class do a similar task reliably. (In hindsight, AppleHelp is such a disaster that I should have just avoided it entirely, as almost every other app does.) MAS reviewers have given me grief over many things my app does, but never any Carbon calls. The last time I saw any Carbon APIs deprecated was 10.8, I think (6 years ago).
    - amaccuish 8y ago
      They're about to removed (carbon apis) AFAIK with the move to 64bit only no?
- snaky 8y ago
  The majority had stopped at (right before) WPF it seems > In fact, at a recent conference I was at with a large group of C# consultants. When the audience was polled on which desktop UIs their clients were using, the vast majority were WinForms, a small group was WPF, and almost no one was UWP https://iamtimcorey.com/ask-tim-is-winforms-dead/ https://iamtimcorey.com/ask-tim-is-winforms-dead/ And many did long before WinForms > Less than a year ago, a manager asked me if I could write a library for a client that would allow VB6 to access a RESTful API. https://blog.submain.com/death-winforms-greatly-exaggerated/ https://blog.submain.com/death-winforms-greatly-exaggerated/
- pjc50 8y ago
  > The story is so bad Microsoft’s own flagship software has to build their own UI frameworks I think this might be the other way round: if they're not eating their own dogfood, it's much easier for the UI framework to come adrift from actual use cases. It's really telling that in Windows 8/10 they "modernised" some, but not all, of the control panel UI. It's basically random as to whether a setting you need will be in a Metro-flavoured window or a Win32-flavoured one. To me, the trouble with everything after WinForms is that it lacks a really compelling reason to upgrade. It's not easier to develop for and it's not nicer to use, and on many desktop systems the font rendering is much uglier in the new system. It does perform better at high DPI, but (catch-22) few people use high DPI windows systems because it's not well supported by even the OS let alone the applications.
  - pjmlp 8y ago
    I do Windows development since 3.0, currently maintaining a couple of Forms and WPF applications, the Forms are the hardest to maintain due event handling spaghetti code instead of proper MVVM with data binding, no use of Table/StackLayout components and still do background handling in BackgroundWorker classes.
    - GordonS 8y ago
      How is the Visual Studio WPF designer these days? I worked on a WPF app around 5 years ago, and the form designer in Visual Studio was appalingly slow and quite buggy. I also wasn't a big fan of XAML - no matter how much time I spent using it, it mostly seemed more difficult and awkward to get components where you wanted them than with WinForms.
      - maxxxxx 8y ago
        The designer is fine now.
      - pjmlp 8y ago
        Quite good. I always do a mixture of Blend and Studio. Never had any big problem that I can remember of since Visual Studio 2012.
- MichaelMoser123 8y ago
  What's bad about GDI? (I used to do windows but have not been following, I remember that you need to do GetDC and ReleaseDC on a window handle to get the device context and then to release it - in pairs, else...)
  - buckminster 8y ago
    It doesn't do antialiasing.
    - setquk 8y ago
      GDI+ does.
      - testvox 8y ago
        GDI+ Is better in a lot of ways, but has the major downside of being limited to software rendering only.
      - quietbritishjim 8y ago
        GDI+ is a completely different replacement API, not just an extension/update of GDI.
  - DaiPlusPlus 8y ago
    It's a graphics API designed for early-1990s needs. It's missing things we expect today like 30-bit colour support and all-VRAM memory (GDI was hardware accelerated but they gimped it in Windows Vista to ensure compatibility with the DWM). When working with Win32 it just isn't possible to avoid having to use GDI, for example dealing with painting to a window surface Win32 will give you a GDI device context by default - for example, similarly handling Win32 messages like WM_PAINT uses parts of the GDI API. Finally, each process on Windows has a limited number of GDI objects it can use as well. Oh, and using GDI/GDI+ in a service context (e.g. ASP.NET or a Windows Service, is not supported: https://blogs.msdn.microsoft.com/dsui_team/2013/04/16/using-direct2d-from-a-service-in-c/ https://blogs.msdn.microsoft.com/dsui_team/2013/04/16/using-...) Direct2D is nice - but setting it up in your code isn't easy - and Microsoft does not maintain an up-to-date C#/.NET library for Direct2D.
- baybal2 8y ago
  remember WinJS, another vapourware
- dragonwriter 8y ago
  > The story is so bad Microsoft’s own flagship software has to build their own UI frameworks The story is so bad because the Microsoft units making flagship desktop apps aren't productizing their UI frameworks (not suggesting that this is their choice), instead leaving the firm with public UI framework offerings not tightly grounded in that kind of use experience. Good frameworks don't lead to internal flagship use, internal flagship use leads to good frameworks through tight feedback between real-world use and framework development.
setquk 8y ago
Very very very low. Win32 is a lower portability risk than UWP. Genuinely that’s what I’ve heard people say. Most of the UI and event stuff can be moved to wx or equivalent in a few months and deployed on other platforms. UWP and you’re up shit creek. Most companies are on the fence with running away from windows. It moved too fast, costs too much money to keep up with and has too much friction. Take a look on the windows store for the massive uptake. Not. Half of it is still win32 and the rest is written by MSFT, crapware or abandoned. Everything is in a right state despite the marketing to the contrary.
threeseed 8y ago
There is also Electron/Javascript. Skype/Teams are developed in it and they have invested a lot of effort into TypeScript.
- vardump 8y ago
  Skype has become so clunky and slow lately, so I find myself avoiding it whenever possible. Could this be the reason behind the worse quality?
- jcelerier 8y ago
  There's also Qt which they used for OneDrive
  - pknopf 8y ago
    Yup, and you don't even need to touch C++ these days. All C# and QML! https://github.com/qmlnet/qmlnet https://github.com/qmlnet/qmlnet (I'm the author)
  - tinus_hn 8y ago
    I’m not sure if it’s true but it seems to me like they replaced their own client with an alternative one they bought from another company, which has parts written in Qt.
- maxxxxx 8y ago
  Honestly, if I had to develop a new desktop app for Windows I would seriously think about Electron. It's frustrating that there is no premier desktop app framework for Windows anymore. UWP is too limited, WPF is pretty much deprecated. Win32 has a huge learning curve and finding devs would be very difficult. Pretty sad situation. Maybe their secret plan is to push people into writing web apps with ASP.NET? Event that doesn't work because a lot of people will use Node instead.
  - pknopf 8y ago
    Why not Qt?
pjmlp 8y ago
Like everyone else, the biggest difference is that Microsoft keeps the old tech around, while most other companies are willing to loose customers that don't want to move into the new stacks. On one side it is a big reason why they have achieved their market size on the desktop, on the other side we reach this kind of situations where new tech improved tech like Singularity, Midori, Longhorn or now UWP gets thrown into the garbage can in the name of backwards compatibility. Quite sad.
- maxsilver 8y ago
  Microsoft shot themselves in the foot with UWP. It's actually pretty nice to write apps with it (in my personal opinion, anyway). But UWP only supports Windows 10. Very few commercial products are able to drop Windows 7 support (and like, literally zero enterprise products can drop Windows 7 support). So, no matter how nice UWP gets, most companies that would still be willing to write a native Windows app are 5+ years out from being allowed to adopt it, entirely because of how Microsoft chose to release it.
  - ColinWielga 8y ago
    Yeah, UWP not supporting win7 pretty much killed it. Might not be an issue in 5 years, by then MS will probably has a new new framework .
  - opencl 8y ago
    UWP doesn't even support Windows 8, it is strictly Windows 10. Not that 8 is very relevant.
    - maxsilver 8y ago
      Oops, sorry, you are correct, I got it mixed up with the 8/8.1 SDK. Fixed.
  - maxxxxx 8y ago
    "Very few commercial products are able to drop Windows 7 support (and like, literally zero enterprise products can drop Windows 7 support)." You would be suicidial if you based any product you want to sell to business on UWP. Not only doesn't it Win 7 or 8 but I don't see in what way UWP is better than WPF.
mrweasel 8y ago
WinForms will out live UWP, WFP and pretty much everything else Microsoft develops in terms of GUI frameworks. It works for the vast majority of programs that businesses need, it's easy to use and so far it's been the best investment in terms of learning a "framework". If Microsoft want's to move forward, they need to consider moving new stuff into WinForms and expand that with the features of UWP, WPF, XAML and other technologies they've tried to introduce over the years.
- maxxxxx 8y ago
  "If Microsoft want's to move forward, they need to consider moving new stuff into WinForms and expand that with the features of UWP, WPF, XAML and other technologies they've tried to introduce over the years. " They could have done this 10-15 years ago. It's too late now.
vbezhenar 8y ago
I don't even know how to use UWP. I'm learning Rust and writing some applications using WinAPI is my plan. WinAPI usage seems to be fairly straightforward. But I have no idea how to write UWP application with Rust.
SyneRyder 8y ago
> As someone who's written Windows software since the 90s, I can't shake the feeling that Microsoft just churns out completely new development stacks every few years. That's the theme behind one of Joel Spolsky's old essays, Fire And Motion: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ "Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features. Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don’t have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP. The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft."

DaiPlusPlus 8y ago

This is exactly what is holding back Win32: there has not been any serious development of the desktop developer story since WPF in 2005 (WPF only received token updates since then, the last major update was in 2010 when they finally added a DataGrid control, lol) - but WPF is not well-suited for many types of software which have to fall-back on “pure” Win32 and the story there is nothing but depressing. Apple got it right with Cocoa (nee Nextstep) - it’s something they have been gradually building on with incremental improvements, continuously forwards and upwards - whereas Microsoft has been launching new, short-lived and incompatible (and incomplete) platforms for the past 15 years: WinForms, WPF, Silverlight, Jupiter (Win 8.1), UWP (Win10), etc. The story is so bad Microsoft’s own flagship software has to build their own UI frameworks (Office has its own, Windows Media Center had some arcane prototype of WPF, even the Windows 10 Start Menu uses some UI+Graphics framework that’s not exposed to third-party developers). Win32 needs some serious work - not least because Win32 is “infected” with GDI which has its own issues. WinRT was nice but nowhere near sufficient.

TazeTSchnitzel 8y ago
When Apple introduced Cocoa they also introduced Carbon however, an extension of the legacy MacOS APIs. Apple already slowly killed their Win32.
- simongray 8y ago
  It's actually kind of impressive how much transitional stuff Apple has introduced and then removed with Mac OS X and how right many of their decisions turned out. I guess Cocoa itself was an extension of the legacy NextStep API too. They also had Classic for running old Mac apps directly in OSX and later Rosetta for running PowerPC binaries on Intel (I guess the same tech was used for the 32->64 bit transition). So many technologies have been smoothly deprecated and removed over the years by Apple.
  - pjmlp 8y ago
    Because Apple does the "take it our way or leave" approach. Which is also a reason why they hardly have a meaningful market share across the enterprise world.
    - scarface74 8y ago
      Sure they do. It’s on mobile. While MS isn’t going anywhere in the Enterprise, anyone who is focused on the desktop when it comes to MS development instead of web, cloud, or even cross platform mobile development is headed down a dead end.
      - pjmlp 8y ago
        A little secret, laptops and 2-1 convertibles are desktops as well, while being mobile.
        scarface74 8y ago
        If we want to be pedantic, a desktop could be considered mobile too since you can pick it up. But in the real world when people talk about “mobile software” everyone knows that people are talking about iOS and Android. No one is chasing after the Windows software market, it’s been a diminishing platform for the past decade.
        pjmlp 8y ago
        In the real world people are working on laptops, while using iOS and Android mostly to consume content, play games, browse web and show plane tickets. When they actually become a match to laptops and 2-1 convertibles, maybe. And there Chromebooks are no where to be seen outside US school system, iPad Pros are mostly a gimmick in rich countries and Android 2-1 are basically phone apps with keyboard.
        scarface74 8y ago
- ken 8y ago
  Yes and no. They've taken down the documentation, but there's still a number of (non-GUI, non-kernel) Carbon APIs that are still not deprecated (as of 10.11, at least), and still allowed in the Mac App Store. I'm using AHGotoPage() because NSHelpManager has no equivalent and nobody has been able to explain to me how to make that class do a similar task reliably. (In hindsight, AppleHelp is such a disaster that I should have just avoided it entirely, as almost every other app does.) MAS reviewers have given me grief over many things my app does, but never any Carbon calls. The last time I saw any Carbon APIs deprecated was 10.8, I think (6 years ago).
  - amaccuish 8y ago
    They're about to removed (carbon apis) AFAIK with the move to 64bit only no?
snaky 8y ago
The majority had stopped at (right before) WPF it seems > In fact, at a recent conference I was at with a large group of C# consultants. When the audience was polled on which desktop UIs their clients were using, the vast majority were WinForms, a small group was WPF, and almost no one was UWP https://iamtimcorey.com/ask-tim-is-winforms-dead/ https://iamtimcorey.com/ask-tim-is-winforms-dead/ And many did long before WinForms > Less than a year ago, a manager asked me if I could write a library for a client that would allow VB6 to access a RESTful API. https://blog.submain.com/death-winforms-greatly-exaggerated/ https://blog.submain.com/death-winforms-greatly-exaggerated/
pjc50 8y ago
> The story is so bad Microsoft’s own flagship software has to build their own UI frameworks I think this might be the other way round: if they're not eating their own dogfood, it's much easier for the UI framework to come adrift from actual use cases. It's really telling that in Windows 8/10 they "modernised" some, but not all, of the control panel UI. It's basically random as to whether a setting you need will be in a Metro-flavoured window or a Win32-flavoured one. To me, the trouble with everything after WinForms is that it lacks a really compelling reason to upgrade. It's not easier to develop for and it's not nicer to use, and on many desktop systems the font rendering is much uglier in the new system. It does perform better at high DPI, but (catch-22) few people use high DPI windows systems because it's not well supported by even the OS let alone the applications.
- pjmlp 8y ago
  I do Windows development since 3.0, currently maintaining a couple of Forms and WPF applications, the Forms are the hardest to maintain due event handling spaghetti code instead of proper MVVM with data binding, no use of Table/StackLayout components and still do background handling in BackgroundWorker classes.
  - GordonS 8y ago
    How is the Visual Studio WPF designer these days? I worked on a WPF app around 5 years ago, and the form designer in Visual Studio was appalingly slow and quite buggy. I also wasn't a big fan of XAML - no matter how much time I spent using it, it mostly seemed more difficult and awkward to get components where you wanted them than with WinForms.
    - maxxxxx 8y ago
      The designer is fine now.
    - pjmlp 8y ago
      Quite good. I always do a mixture of Blend and Studio. Never had any big problem that I can remember of since Visual Studio 2012.
MichaelMoser123 8y ago
What's bad about GDI? (I used to do windows but have not been following, I remember that you need to do GetDC and ReleaseDC on a window handle to get the device context and then to release it - in pairs, else...)
- buckminster 8y ago
  It doesn't do antialiasing.
  - setquk 8y ago
    GDI+ does.
    - testvox 8y ago
      GDI+ Is better in a lot of ways, but has the major downside of being limited to software rendering only.
    - quietbritishjim 8y ago
      GDI+ is a completely different replacement API, not just an extension/update of GDI.
- DaiPlusPlus 8y ago
  It's a graphics API designed for early-1990s needs. It's missing things we expect today like 30-bit colour support and all-VRAM memory (GDI was hardware accelerated but they gimped it in Windows Vista to ensure compatibility with the DWM). When working with Win32 it just isn't possible to avoid having to use GDI, for example dealing with painting to a window surface Win32 will give you a GDI device context by default - for example, similarly handling Win32 messages like WM_PAINT uses parts of the GDI API. Finally, each process on Windows has a limited number of GDI objects it can use as well. Oh, and using GDI/GDI+ in a service context (e.g. ASP.NET or a Windows Service, is not supported: https://blogs.msdn.microsoft.com/dsui_team/2013/04/16/using-direct2d-from-a-service-in-c/ https://blogs.msdn.microsoft.com/dsui_team/2013/04/16/using-...) Direct2D is nice - but setting it up in your code isn't easy - and Microsoft does not maintain an up-to-date C#/.NET library for Direct2D.
baybal2 8y ago
remember WinJS, another vapourware
dragonwriter 8y ago
> The story is so bad Microsoft’s own flagship software has to build their own UI frameworks The story is so bad because the Microsoft units making flagship desktop apps aren't productizing their UI frameworks (not suggesting that this is their choice), instead leaving the firm with public UI framework offerings not tightly grounded in that kind of use experience. Good frameworks don't lead to internal flagship use, internal flagship use leads to good frameworks through tight feedback between real-world use and framework development.

setquk 8y ago

Very very very low. Win32 is a lower portability risk than UWP. Genuinely that’s what I’ve heard people say. Most of the UI and event stuff can be moved to wx or equivalent in a few months and deployed on other platforms. UWP and you’re up shit creek. Most companies are on the fence with running away from windows. It moved too fast, costs too much money to keep up with and has too much friction. Take a look on the windows store for the massive uptake. Not. Half of it is still win32 and the rest is written by MSFT, crapware or abandoned. Everything is in a right state despite the marketing to the contrary.

threeseed 8y ago

There is also Electron/Javascript. Skype/Teams are developed in it and they have invested a lot of effort into TypeScript.

vardump 8y ago
Skype has become so clunky and slow lately, so I find myself avoiding it whenever possible. Could this be the reason behind the worse quality?
jcelerier 8y ago
There's also Qt which they used for OneDrive
- pknopf 8y ago
  Yup, and you don't even need to touch C++ these days. All C# and QML! https://github.com/qmlnet/qmlnet https://github.com/qmlnet/qmlnet (I'm the author)
- tinus_hn 8y ago
  I’m not sure if it’s true but it seems to me like they replaced their own client with an alternative one they bought from another company, which has parts written in Qt.
maxxxxx 8y ago
Honestly, if I had to develop a new desktop app for Windows I would seriously think about Electron. It's frustrating that there is no premier desktop app framework for Windows anymore. UWP is too limited, WPF is pretty much deprecated. Win32 has a huge learning curve and finding devs would be very difficult. Pretty sad situation. Maybe their secret plan is to push people into writing web apps with ASP.NET? Event that doesn't work because a lot of people will use Node instead.
- pknopf 8y ago
  Why not Qt?

pjmlp 8y ago

Like everyone else, the biggest difference is that Microsoft keeps the old tech around, while most other companies are willing to loose customers that don't want to move into the new stacks. On one side it is a big reason why they have achieved their market size on the desktop, on the other side we reach this kind of situations where new tech improved tech like Singularity, Midori, Longhorn or now UWP gets thrown into the garbage can in the name of backwards compatibility. Quite sad.

maxsilver 8y ago
Microsoft shot themselves in the foot with UWP. It's actually pretty nice to write apps with it (in my personal opinion, anyway). But UWP only supports Windows 10. Very few commercial products are able to drop Windows 7 support (and like, literally zero enterprise products can drop Windows 7 support). So, no matter how nice UWP gets, most companies that would still be willing to write a native Windows app are 5+ years out from being allowed to adopt it, entirely because of how Microsoft chose to release it.
- ColinWielga 8y ago
  Yeah, UWP not supporting win7 pretty much killed it. Might not be an issue in 5 years, by then MS will probably has a new new framework .
- opencl 8y ago
  UWP doesn't even support Windows 8, it is strictly Windows 10. Not that 8 is very relevant.
  - maxsilver 8y ago
    Oops, sorry, you are correct, I got it mixed up with the 8/8.1 SDK. Fixed.
- maxxxxx 8y ago
  "Very few commercial products are able to drop Windows 7 support (and like, literally zero enterprise products can drop Windows 7 support)." You would be suicidial if you based any product you want to sell to business on UWP. Not only doesn't it Win 7 or 8 but I don't see in what way UWP is better than WPF.

mrweasel 8y ago

WinForms will out live UWP, WFP and pretty much everything else Microsoft develops in terms of GUI frameworks. It works for the vast majority of programs that businesses need, it's easy to use and so far it's been the best investment in terms of learning a "framework". If Microsoft want's to move forward, they need to consider moving new stuff into WinForms and expand that with the features of UWP, WPF, XAML and other technologies they've tried to introduce over the years.

maxxxxx 8y ago
"If Microsoft want's to move forward, they need to consider moving new stuff into WinForms and expand that with the features of UWP, WPF, XAML and other technologies they've tried to introduce over the years. " They could have done this 10-15 years ago. It's too late now.

vbezhenar 8y ago

I don't even know how to use UWP. I'm learning Rust and writing some applications using WinAPI is my plan. WinAPI usage seems to be fairly straightforward. But I have no idea how to write UWP application with Rust.

SyneRyder 8y ago

> As someone who's written Windows software since the 90s, I can't shake the feeling that Microsoft just churns out completely new development stacks every few years. That's the theme behind one of Joel Spolsky's old essays, Fire And Motion: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ "Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features. Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don’t have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP. The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft."