What’s really wrong with Win32?

17

Okay, people. Let’s put the cards on the table. I want cogent, detailed reasons why we have to move on from Win32 and/or .NET to whatever the next thing may be (UWP, or whatever).

Not trying to start any flames or war here either. 🙂

But I’m going through it in my own mind, and I’m not satisfied with just “out with the old, in with the new.” Or nebulous reasons like “Win32 was for another era.”

I was hoping we could shed light on the real technical reasons.

And I say this as someone who just recently published a simple game to the Windows 10 Store, a UWP app. Thing is, I wrote it in Clickteam Fusion, and it created the Visual Studio project for me. All I had to do was package it. I didn’t see the nuts and bolts.

Come on now, don’t be shy. Speak up! 🙂

Comments (17)

17 responses to “What’s really wrong with Win32?”

  1. Chris_Kez

    In reply to skane2600:

    All fair points, though I wasn't specifically talking about UWP. I'm just asking whether Microsoft could have already created a store for Win32 programs (which would be compatible with Windows 7) if they were simply motivated to get a cut of software sales. I think there's more to their vision of Windows 10 and beyond than just "Kill Win32. Open UWP Store. Profit."

  2. JimP

    This is easy. UWP apps are more secure and use a single update service.

    • hrlngrv

      In reply to JimP:

      I accept UWP apps are more secure. OTOH, the single update service is NBD compared to how most Linux distributions handle updates, especially distributions using Debian packages. Everything installed using dpkg or apt can be updated using a single command or automatically without interaction. MSFT could offer an online service and a local service. 3rd party developers could register their upgrades with MSFT's online service, and the local service could poll the online service whether upgrades were available, and if so, download and launch them. This is approximately what the Windows Store does, except that it's also the source for any upgrade files. It really wouldn't be impossible to extend this to standard, unpackaged desktop software if ISVs had any interest in it.

  3. John Scott

    I sort of see the model of UWP trying to be like the model of Android and IOS. Have a secure place to download apps and have them updated in a organized manor. Windows 10S is pushing that direction, the issue of course is at this point Microsoft has totally failed at providing a robust store front of apps.

  4. PanamaVet

    Eventually 32 bits will not be enough to store the current date.


    We should prepare now.


  5. hrlngrv

    In reply to Chris_Kez:

    I rather doubt that for larger ISVs the advantages of the Windows Store would be worth 30% of gross sales. As evidence for that conjecture I point to the dearth of larger ISV offerings in the Windows Store. If the Windows Store were worth it, wouldn't there be more offerings?

    Windows Store is likely to be a net positive for all the ISVs currently using it and a net negative for all the ISVs not currently using it. For workplace software at least, there's an overwhelming vote that it's not currently worthwhile.

  6. ErichK

    As long as we're on the subject of moving on from legacy stuff, is the Registry ever going to go away? Not that I want it to, but ... I mean, when we transitioned to Window 95, it was touted as being superior to .INI files. But it seems now there's a push by some for it to be deprecated in favor of something new, but I don't know what that would be. plist files, maybe. ;-)

  7. hrlngrv

    In reply to WP7Mango:

    Forgot to mention display scaling. Qt provides display scaling for Windows, macOS/OS X and Linux for otherwise standard desktop software. I figure MSFT could adapt Win32 for display scaling if it had any interest in doing so rather than pushing UWP.

    If UWP is necessary for display scaling, then MSFT itself needs to put together some more complex UI apps which show that UWP might be able to replace Win32, say maybe a new generation QuickBASIC with facilities for pulling in web queries or rss feeds and displaying condensed info in live tiles.

    • WP7Mango

      In reply to hrlngrv:

      The display scaling issue has already been discussed many times, even by Microsoft. Fixing display scaling in Win32 is basically impossible without breaking a whole load of desktop applications.


      Microsoft already had store apps for software development, such as Project Siena.

      • hrlngrv

        In reply to WP7Mango:

        Break them. Provide container windows as virtual monitors which could display 2x or 4x native resolution. Old software could run in such virtual monitors. Newer software could take advantage of scaling.

        There was a lot of obsolete 16-bit software when Windows 95 and NT4 came out in the mid to late 1990s, and many ISVs survived to produce 32-bit versions. It could happen again. Also, since this would be adapting to hardware realities rather than just MSFT's whims, there wouldn't be much griping.

        As for Project Sienna, at least for build 16257, Microsoft "Project Siena" in the Windows Store shows up as currently not available.

      • skane2600

        In reply to WP7Mango:

        Project Sienna isn't suitable for professional development. While MS couldn't magically make existing Win32 apps scale, I don't see any reason why additional Win32 APIs couldn't be added that allow future applications to scale.

  8. longhorn

    MacOS is doing fine with Win32 level security (no sandbox, no antivirus)

    Linux is doing fine with Win32 level security (no sandbox, no antivirus)

    Windows is doing fine with Win32 security (no sandbox, antivirus is recommended)


    There is no need to go back to the dark Middle Ages (functionality-wise) with sandboxed apps. Because Android is so secure... Can we stop the Modern bs right now? Just scan those Win32 apps and put them in a Store for people who are paranoid to download from the net.

  9. WP7Mango

    In reply to ErichK:

    As FalseAgent says, you can write a UWP app in .NET, using either C# or VB. The main difference is the UI layer because that's done using XAML, so no WinForms for UWP apps. If you're familiar with WPF desktop development or web development, you'll be fine with developing UWP apps.

Leave a Reply