back to article In the frame with the Great MS Bakeoff: Microsoft sets out plans for Windows windows

Microsoft has revealed its plans for the future of the windowing API in Windows, a fundamental piece in desktop development, as part of the Project Reunion effort to untangle the mess caused by UWP (Universal Windows Platform). Writing code to make a window appear on the screen is the "Hello world" of Windows development. Back …

  1. Jusme

    This seems appropriate...

  2. karlkarl Silver badge

    I think this is a great idea and about time they focused on core tech rather than just piling layers on top. Microsoft should "improve" it by deprecating a number of "modern" Metro wrappers and focus on the standard winapi. Just add extensions to it. Kind of like how Motif (Xm) added extensions on top of XIntrinsics (Xt).

    The WndProc stuff was not actually too bad for using C (i.e a single callback with a "type" id). It also made wrapping it in objects i.e for C++ fairly easy.

    if they feel they must get away from C style architecture and onto C++, I really do hope they bring smart pointers in. I am sick of being carelessly handed a raw pointer that has no real consistent lifespan guarantees. If they are not skilled / disciplined enough to do this with C++ and have to migrate to Rust, then... well I guess people will stick with the old winapi due to legacy requirements and nothing will be achieved.

    1. ST Silver badge

      > Kind of like how Motif (Xm) added extensions on top of XIntrinsics (Xt).

      30 years ago.

      1. karlkarl Silver badge

        Are you suggesting that new stuff is always better?

        1. ST Silver badge

          > Are you suggesting that new stuff is always better?

          The answer is context-dependent. Why don't you ask Microsoft?

          On a related train of thought: Ask any UNIX/Linux UI programmer: Is Gtk+ or QT better than Motif? Do they still qualify as new in 2020?

        2. David Lewis 2

          Are you suggesting that new stuff is always better?

          I don't see a career in marketing in your future!

    2. jotheberlock

      I mean,

      a) Motif is a GUI toolkit while Xt is a set of tools for making a GUI toolkit (with Athena as the reference barebones GUI toolkit that shipped with X11), so it's not really comparable. Motif doesn't extend Xt, it sits on top of it.


      b) Nobody since has used Xt. Gtk doesn't use it. Qt doesn't use it.

      1. karlkarl Silver badge

        I am going to have to be careful with my wording so not to confuse. Or better yet...

        Notice how Athena widgets (Xaw) and Motif widgets can interact and exist together on the same Window? This is the benefit of having a common underlying base (Xt).

        This is what I meant. That way legacy "widgets" still work and nothing is lost. No-one is tied into a constant treadmill of re-engineering.

        Gtk+ and Qt are not good examples of what "good" GUIs should do. They are fairly inefficient, especially over remote connections. Microsoft's RDP needs to be a little bit more mindful of this kind of stuff. Linux dropped the ball a little with X11 and VNC is not really comparable in performance.

        1. ST Silver badge

          Gtk+ and Qt are not good examples of what "good" GUIs should do.

          Uh-huh. Right. That's why all current UNIX/Linux software that uses a GUI is written in one of these two. Including that mono (.NET) monstrosity for Linux (written in Gtk+).

          1. karlkarl Silver badge

            Like I said, just because they are used, doesn't make it the correct choice. The constant migration towards Wayland (which doesn't support multiple sessions) shows a considerable lack of interest in remote desktop.

            Losing a network aware GUI system is a mistake as far as I am concerned. X11 was fairly inefficient as far as these go (unfortunately compared to RDP) but it did support multiple sessions.

            1. IGnatius T Foobar !

              Like I said, just because they are used, doesn't make it the correct choice. The constant migration towards Wayland (which doesn't support multiple sessions) shows a considerable lack of interest in remote desktop.

              Actually there's nothing stopping them from building a Wayland compositor whose "display hardware" is actually an RDP session.

              1. Pascal Monett Silver badge

                What Borkzilla really needs is to understand is that the UI and the OS are two different things.

                Linux got that right, why can't Borkzilla ?

                Oh, right, legacy.

                1. 9Rune5 Silver badge

                  There is (or was) Windows Server Nano. No GUI.

                  Current version is container-only though.

                2. This post has been deleted by its author

                3. Warm Braw Silver badge

                  the UI and the OS are two different things

                  They really aren't. A reasonable Linux GUI needs something like D-Bus and reasonably performant filesystem notification so that the desktop can pick up on device hotplugging, directory views can reflect realtime changes to the file list, notifications can be handled, etc. It's only when you start creating the GUI that you realise what services the OS did not previously need to provide are now required. You probably also need a scheduler that can give priority to interactivity and assure realtime performance for audio and video. You might reasonably want to ensure the implementation of those services is appropriately layered, but in order to have a GUI you need an OS that has support for one.

                  Windows and Linux came at the problem from different ends - Windows focused on the GUI whereas it was rather more of a borrowed afterthought for Linux - but have ended up in largely the same place. The main distinction is that, having a commercial product to ship, Microsoft were prepared to blur layer boundaries to improve perceived performance - but that's an optimisation, not a fundamental design difference.

              2. karlkarl Silver badge

                I'm not convinced. By the time it gets to the compositor, it is OpenGL instructions. How are these going to be converted to high level RDP instructions? The best you will get is sending across a raster image like VNC where you lose a large amount of performance and bandwidth. This is why a "network aware" GUI system is crucial from the ground up.

                The best Wayland could do is probably send across the OpenGL commands, but this is still not going to be fantastic performance each frame.

                1. Kristian Walsh

                  It's funny to see X11 proposed as a model for Microsoft to follow. You guys must really hate Microsoft…

                  If I want bandwidth-efficient, remote application access from a Linux system, I use SSH.

                  If I want a graphical UI, I accept that it I have already demoted bandwidth efficiency in my priorities, so I use VNC or other system that works on raster images. Given the way GUI applications really draw their window content, as opposed to the way X advocates would like them to, there isn’t much difference between shipping window content bitmaps over the network versus the drawing instructions, and sometimes the bitmap is actually more efficient in cases where the display is composed of tens of thousands of drawing operations.

                  X11 was a system designed for a different, bygone, world, where centralised computers ran applications that were viewed on thin-client terminals (yes, I know the terminal isn't a "client" in X, but it is one in network terms). That is not how the majority of graphical application systems are used now, and there's a good chance that it never will be.

      2. Doctor_Wibble

        > b) Nobody since has used Xt. Gtk doesn't use it. Qt doesn't use it.

        I do! Though I realise the point wasn't about individuals. I use Xt and Xaw for basic remote display and remote menu stuff for simplicity and portability, in particular for clean/new systems.

        The extra gui toolkits just added extra layers of indirection, at a cost of large sets of extra package dependencies, some scary-scale bloat, and some rather annoying technical issues when trying to statically compile or strip the executable.

        Horses for courses I suppose. And the old-person attitude of preferring something that takes less than a week to copy over a modem link or can fit on a floppy disk, preferably both. I know the icon says Windows User but it fits my 'what is this newfangled nonsense' too :)

  3. Anonymous Coward
    Anonymous Coward

    I've migrated...

    ...right the fuck off the infinite Microsoft treadmill of fail.

  4. Ross 12

    They still don't get it do they?

    Nobody is going to port old code to a shiny new framework just because there's a new API - no matter how much nicer it is. That's simply not the reason anybody writes code. And for as long as Windows supports running win32 apps, people will keep win32 code around, and keep writing new apps in it to reach a wider audience than anything new.

    There's 25+ years of Win32 code out there in the wild. Half the developers have probably died, retired, or changed career. Half the source code probably no longer exists. Just as with COBOL, there'll be Win32 code out there running that people don't even know about and that probably hasn't been looked at since Y2k was a thing. There'll be code propping up businesses large and small all over the world who's in-house developers and external vendors have long since disappeared.

    Microsoft will never be able to rid itself of Win32 by trying to tempt developers to use something new. The only way they'll do it is to put their foot down and stop supporting it whilst making sure there's a clear and definite stable alternative - something that Microsoft are pretty much incapable of.

    I really think that Microsoft need to accept the fact that they're a 'boring' business software vendor - not a hip and trendy brand. They got the corporate world hooked on Windows, Office and VS etc, and that means they're stuck with them for the long term.

    1. don't you hate it when you lose your account Silver badge

      Re: They still don't get it do they?

      Microsoft talk as if this will simplify the mess. But it just sounds like more complexity and confusing.

    2. bombastic bob Silver badge

      Re: They still don't get it do they?

      From the article: In 2012 Microsoft decided to make a modern and more secure Windows system based on the Windows Runtime, or WinRT

      That word 'modern' - they keep using that word. it does not mean what they think (feel?) it means...

      And for as long as Windows supports running win32 apps, people will keep win32 code around,

      Until Micros~1 finds a way to kill it - like they did the "classic" windows desktop!!!

      (except for us anti-win-10-nic rebels who REFUSE to COMPLY and the many who switch to Linux or Mac instead)

      Back in the day, HP tried to introduce new products at lower prices than existing ones, with better features etc. in order to motivate people to get new products. THEN they'd EOL the old ones. This was when Mr. Hewlett and Mr. Packard still ran it. (not so much any more)

      What Micros~1 did is the exact opposite. They KILLED the old products by artificially "end of life"ing them, and swapped a PILE OF CRAP (Win-10-nic, TIFKAM, WinRT-ish foolishness) and told us we had to LIKE it, INSTALL it, UPGRADE to it, by FORCE (GWX) if necessary.

    3. Sil

      Re: They still don't get it do they?

      In my opinion, they get it and that's what they mean by:

      "He also promised that Microsoft will not alienate developers with "yet another solution".

      Win32 devs who aren't missing anything will continue with win32

      Win32 devs who are missing something, and this should be most devs developping modern applications compatible with touch and so forth, will get extended APIs that for all intent and purposes look like an evolution of Win32.

      Those who may loose a little are the UWP devs, if the upgrade to the new API isn't as automatable as forethought. However, they also win since everybody knows the divide is unsustainable and things had to evolve.

  5. IGnatius T Foobar !

    Two different windows are a problem ... so add a third!

    Adding a third method to create windows is probably the single worst solution to the problem they could have come up with.

    The correct solution would have been to have one API call the other, so it always boils down to the same code path.

    1. Nick Ryan Silver badge

      Re: Two different windows are a problem ... so add a third!

      The correct solution would have been to have one API call the other, so it always boils down to the same code path.
      This. Every time. There are many places even in Microsoft systems where the UI executes underlying scripts allowing the same functionality to be there whether using scripts or the provided UI. Doing this also means that most processes can be tested more thoroughly and even in an automated manner.

    2. Kristian Walsh

      Re: Two different windows are a problem ... so add a third!

      Architectually, UWP and Win32 are not compatible. UWP is designed around there being a graphics rendering pipeline, whereas WIn32 has the underlying concept that there is a grid of pixels in memory somewhere for everything, and it is shared between applications.

      This can be frustrating at times (e.g., in UWP, most loaded bitmaps are just lightweight handles into GPU surfaces: you cannot access the pixels in a BitmapImage control unless you explicitly render the control into your own memory buffer), but the upside is that the GUI operates tens to hundreds of times faster, never needs buffering, and you are able to offload all GUI assets into your graphics card's onboard memory rather than losing application memory for it.

      This approach seems to be a way of re-writing what can be rewritten of the old API using the new architecture, and leaving the rest in a kind of compatibility "island" drawing surface within those new windows.

      The closest similar problem was what Apple faced when moving MacOS to the pre-emptive multitasking kernel of OS X in 2000 (at least Win32 was designed with multitasking and thread-safety in mind; Mac Toolbox wasn’t). Apple’s approach was to simply bin everything and tell developers to use a completely new API; an approach that, as I hope is obvious, is something that would never work in the Microsoft ecosystem, where developers have a much more robust and equal relationship with the OS platform vendor.

  6. a_yank_lurker Silver badge

    Failure to think

    Code written awhile ago and is still actively used is not likely to be rewritten to use a new API just because the API exists as it is generally a waste of time. The only way to force users and devs to stop using Win32 is to stop supporting it and removing it from Bloatware at some point in time. But there is a lot of elderly, useful business code that would have to be rewritten; the howls of anguish would be loud. As far as consumer code, I am not sure how much would be affected but there will be some howling from them also.

    The only other alternative is to create an API that is so superior to the current APIs that when the next major revision done to the elderly code will be rewritten to use the new API. I do not think this scenario is very likely to happen as I do not think any new API will be that much better than its predecessor to warrant a rewrite.

    The Rejects of Redmond are stuck, either support Win32 for the foreseeable future or alienate your customers; pick your poison.

  7. Filippo Silver badge

    Most of User32?

    So, is this going to emulate a Win32 message cycle? I won't believe it until I see it, and if it doesn't, then porting most Win32 apps of any complexity is not going to be straightforward at all.

  8. Zippy´s Sausage Factory

    Crazy Train, now boarding

    One way ticket...

    Seriously, what are they thinking?

    "We've got two APIs. Nobody knows which one to use. What do we do?"

    "Obsolete one and kill it off?"

    "No, I've got a better idea - let's create a third, completely different, slower API and tell everyone to use that".

    You couldn't make it up, could you?

    1. Nick Ryan Silver badge

      Re: Crazy Train, now boarding

      It's not the first attempt either. There are probably four or five now?

  9. cornetman Silver badge

    I'm no Microsoftie, but Microsoft are between a rock and a hard place here.

    The main reason that people don't drift away from Windows is the ubiquity of Win32-based software out there.

    If they produced a Windows that would not run legacy software based on Win32, then they would alienate a shit ton of their users and many would be left with no choice but to migrate to something that can, perhaps Linux + Wine.

    However, if they want to move their APIs onto something different, why wouldn't a developer choose something a bit more future proof and platform independent like GTK, or let's face it, much of what is happening in the APP space is web-based anyway such that the browser is more important than the underlying OS.

    1. tiggity Silver badge

      Plus MS have a habit of creating new shiny and then scrapping it e.g. once upon a time it was all Silverlight is the next big thing ... look how that turned out.

      A lot of people will stick with basic Win32 just because there's a good chance it will keep getting supported for a long time and is happy to run on any old windows..

    2. Kristian Walsh

      I agree in principle, but not with the alternatives you offer.

      Web applications are horrifically inefficient, and subject to strange behaviour depending on client. When I write a UI, there are times when I need different components to align to the exact same pixel - doing that in web still degenerates into a nightmare of rules and javascript in too many cases.

      Plus, and this is a big one: right now, moving to Web means you get no code reuse from an existing C application. That's a problem for codebases that have decades of customer requirements baked into them.

      Adopting a cross-platform development framework for C/C++ code makes more sense, but I'd add a recommendation to use Qt instead of Gtk+. Yes, it has those odd SLOT/SIGNAL extension macros, but at least it doesn't force you to learn how to write a graphics toolkit just to do simple things like custom list cells and data bindings, and QtQuick is still so much easier to get good results with than anyone else’s GUI markup system.

  10. Anonymous Coward
    Anonymous Coward

    re: company seeks one true way

    Isn't that bleeding obvious?

    "Do it our way or not at all."

    1. Yet Another Anonymous coward Silver badge

      Re: re: company seeks one true way

      Yes if only they didn't keep abandoning the new way before it was able to do what the old way did

  11. Someone Else Silver badge

    No matter what new, improved, shiny Micros~1 comes up with, it will still be a pile, will be a PITA to work with, incomplete, and won't work as well as their previous new, improved, shiny.

    Qt, FTW.

  12. LenG

    What about what shows on screen?

    I no longer write windows code (thank <deity-of-choice>) but I still use windows (unfortunately). So my major gripe is not that there are two different APIs but that each creates a window which is significantly different to the other. The result on screen is simply a mess. The choice of final appearance should be in the hands of the end user. Up until Win 7 there was enough customization possible to maintain a pretty good emulation of Win2000 - which was a simple, clean interface. This was swept away with the catastropy which was Win 8 and initially in Win 10 user customisation and choice was more or less non-existant. You couldn't even change the colour of the title bar and, from memory, the initial release didn't even significantly emphasise the focus window. With add-ons and hacks this is partially resolved but you still can do nothing about the old-style v. new-style (ie control panel v. settings). This gets particularly irksome when one style bounces you into the other (control panel and settings once again being a good example).

    Windows really needs to look at the linux concept of a desktop. You can install any one of a number of different desktops with quite different look'n'feel.

    1. Richard Hewitt

      Re: What about what shows on screen?

      This ^ * 100

      They just don't get it, do they. B*gger up 25 years of familiarity at the altar of "Shiney Shiney"

    2. GioCiampa

      Re: What about what shows on screen?

      "Up until Win 7 there was enough customization possible to maintain a pretty good emulation of Win2000"

      Which is the first thing I did on every Windows box I had to use ... turn off all the (irrelevant) shiny and let the processor(s) handle the workload I was throwing at it.

      (This stopped, of course, when work migrated us all to Win10)

      1. Kristian Walsh

        Re: What about what shows on screen?

        That CPU argument was valid for Vista and 7's eye-candy modes but it doesn't hold water today. Windows 10's window design requires fewer drawing operations than that used in Win2000. A standard window with a title-bar, title and the the three control buttons in Windows 10 needs just eight graphic operations to draw. Shadows are done by the GPU at no CPU cost.

  13. LDS Silver badge

    The revenge of OS/2?

    Back then one of the aims of OS/2 was to replace the Windows API with something better designed. MS killed OS/2 because it wasn't compatible wirth Windows applications which would have required a deep rewrite. Now they are in the same position, each new API they design is killed by compatibility needs....

    1. david 12

      Re: The revenge of OS/2?

      MS killed OS/2 because it was owned by IBM and written in Assembler.

      1. davidp231

        Re: The revenge of OS/2?

        "MS killed OS/2 because it was owned by IBM"

        Not quite.... originally it was a joint effort, and ultimately had a falling out and went their separate ways. IBM's vision was seen in OS/2 version 2, and Microsoft's was NT 3.1. The popularity and spread of Windows 3 and 3.1 were the main things that killed off OS/2 - it was nothing to do with the fact it was written in Assembler.

  14. Richard 12 Silver badge

    We dropped XP support this week

    We're not going to drop Windows 7 support for a long time, nor 8.1.

    Nobody is going to even consider something that's "Windows 10 2109* only", because users don't even know which version of Windows 10 they have.

    A new windowing API is dead before it even arrives because Microsoft chose this "only one version forever" approach.

    * To pick a random future version

  15. Sanguma

    There SNAFU like an AFU

    Kinda like their other lines of development ... I was prowling around today on my Win8.1 box, looking for info on writing MS Windows device drivers. I'd installed Visual Studio Community 2017 last year, and was planning on doing something with it. But to write a Windows device driver, i'd need to install the WDK, and there's only two major versions of the WDK available, one for MS Windows 10 with Visual Studio 2019 installed, the other for MS Windows 8.x with Visual Studio 2013 installed.

    Happy happy joy joy!

    (I suppose I should add that this sudden love of writing MS Windows device drivers was brought on by my new MS Win 10 box happily informing me that I had a device which Microsoft would no longer support. So, I know which end of a compiler does which, I know something of how to fam something unpleasant down an MSWindows box's throat, I figured I'll write a device driver for that device ... happy happy joy joy! Their doc section hadn't been upgraded to Visual Studio 2019 ...)

  16. I am the liquor

    Bye bye UWP

    migrating code will be easier for Win32 applications than for UWP applications

    migrating UWP applications is intended to be "mostly automatable"

    If "mostly automatable" is the best they can promise for your UWP codebase, then it looks like UWP is getting thrown under the bus.

    All those "dinosaurs" who stuck with Win32-based programming and refused to engage with anything Microsoft invented after about 2005 must be feeling pretty smug now.

    There must be some law of software development that says something like "the newer an API is, the more likely it is to be obsolete."

  17. MJI Silver badge

    But Windows IS WIN32

    Any other reasons to run Windows?

  18. Mage Silver badge


    Scrap UWP. It was designed for phones, or have a completely different GUI not called Windows. One GUI for all kinds and sizes of screens and systems doesn't work. Also calling DIFFERENT OS "Windows" since early 1990s (CE, win on Dos with Program Manager, Win9x/ME, Embedded WinX, NT, embedded NT etc).

    Also have three distinct levels apart from HAL: The GUI (only called Windows on desktop/laptop WIMP), the OS excluding Kernel and the Kernel). Different names for different families. Only call the Desktop/Laptop WIMP version's GUI (only) "Windows".

    1. a_yank_lurker Silver badge

      Re: Simple

      If the Rejects from Redmond really want to migrate users away from Win32 applications they probably should do something like a new OS (let's call it Roof) that does not support Win32 applications natively. Roof would need to be compatible with either MacOS (not likely) , Android, or Linux so there are applications available immediately. The Rejects could then have a decadish long phase out of Win32 support in Bloat so users (companies) have time migrate to another API in Windows. If Roof becomes more popular than Bloat they could even slowly phase out Bloat altogether over a longer period.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021