Pro and Cons of using new MS technologies

Hi@all

I would be interested to know what you think about new technologies that Microsoft is developing. Is it worth porting these new technologies to other programming languages ??such as VB6 or TwinBasic or would you rather stick with the classic APIs and interfaces that are included in the "Windows SDK"? Is it worth looking at technologies such as WinRT, XAML Islands, WinUI2/3, "Windows App SDK" etc.? Microsoft is also known for quickly abandoning previously developed technologies. How would you decide? Wait and see whether Microsoft abandons a technology or use the technology now?

I tend to avoid MS' recent offerings as they all seem to go out of fashion as quickly as they come in. I cannot keep up building the necessary knowledge within those timescales.

MS seems to love change these days, change and disruption. It is a continuous process and I'd rather be driven by something solid that is going to remain for several years and be sure that it will be maintained in the future. I will try new stuff but I prefer it to come from an open source group that is dynamically growing or a 3rd party that shows it can be trusted to deliver.

Microsoft dictates and alienates. I don't like to be told the direction I should be going. I prefer the technology to prove itself first. Change for the sake of it, is pointless in my opinion. If change is driven by genuine improvement and that change is not coupled with some stupid ideology nor adds some equally negative step in another direction, then I will try it and see if it can prove itself for me, then I will adapt it.

Quote:

---

Originally Posted by -Franky-

Hi@all

I would be interested to know what you think about new technologies that Microsoft is developing. Is it worth porting these new technologies to other programming languages ??such as VB6 or TwinBasic or would you rather stick with the classic APIs and interfaces that are included in the "Windows SDK"? Is it worth looking at technologies such as WinRT, XAML Islands, WinUI2/3, "Windows App SDK" etc.? Microsoft is also known for quickly abandoning previously developed technologies. How would you decide? Wait and see whether Microsoft abandons a technology or use the technology now?

---

I suppose it really depends on what your ultimate aim is.

From a .Net point of view there are a few things to consider...

If you are looking at making a simple Windows Desktop application then WinForms is still a perfectly valid approach, plus the Framework itself abstracts out a fair chunk of the Windows API so there is less of a need to deal with the APIs directly.

WPF is still valid, if somewhat more difficult, if a Windows Desktop app is your goal.

If you are looking at targeting multiple environments (such as desktop and mobile) then MAUI is probably worth a look as it is the evolution of what used to be Xamarin forms.

WinUI is mainly for windows apps (I think) and is closely related to WinRT - never really felt the need to use any of these technologies personally.

3rd party options such as Avalonia UI are also good choices, similar to WPF conceptually but still being actively developed and maintained.

If you are looking at remaining with VB6 / TB then I would probably stick with existing approaches - I would imagine creating all the appropriate language bindings etc. for WinRT / WinUI would be a massive undertaking.

@yereverluvinuncleber I can understand your point of view. On the other hand, GDI+, WIC, XAudio2 and the Media Foundation were also new technologies years ago. I can't remember anyone refusing to use them because Microsoft might abandon them at some point. Of course, if you don't use these technologies, Microsoft will abandon them at some point or replace them with newer technologies.

@PlausiblyDamp It's not so much about which programming language you use. For example, you want to enhance the title bar of a WinForm app with interactive controls or be able to change the color of the title bar. Would you rather do this with classic APIs/WinProc (WM_-Messages) etc. or use the Windows App SDK NuGet package where this can be done with a few lines of code?

Quote:

---

Originally Posted by -Franky-

@PlausiblyDamp It's not so much about which programming language you use. For example, you want to enhance the title bar of a WinForm app with interactive controls or be able to change the color of the title bar. Would you rather do this with classic APIs/WinProc (WM_-Messages) etc. or use the Windows App SDK NuGet package where this can be done with a few lines of code?

---

In that case I would normally take this on a case by case basis - e.g. if I only wanted to do one specific thing like change the title bar colour then I might just go ahead and do it via the API rather than include a large dependency. If on the other hand I could see a nuget package providing a lot of useful functionality then I would opt for nuget.

One big advantage of using nuget packages, or at least the quality ones, is that they are often well written and tested. They will deal with a lot of edge cases and odd behaviours which might not be obvious if you are implementing this behaviour yourself.

Quote:

---

Originally Posted by PlausiblyDamp

In that case I would normally take this on a case by case basis - e.g. if I only wanted to do one specific thing like change the title bar colour then I might just go ahead and do it via the API rather than include a large dependency. If on the other hand I could see a nuget package providing a lot of useful functionality then I would opt for nuget.

One big advantage of using nuget packages, or at least the quality ones, is that they are often well written and tested. They will deal with a lot of edge cases and odd behaviours which might not be obvious if you are implementing this behaviour yourself.

---

And if the Nuget package uses a technology that is not included in the standard Windows SDK, no standard APIs or interfaces, but offers you new possibilities through new APIs, etc., would you use this Nuget package or would you rather say, I won't use this Nuget package because Microsoft might abandon the technology used at some point?

Quote:

---

Originally Posted by -Franky-

And if the Nuget package uses a technology that is not included in the standard Windows SDK, no standard APIs or interfaces, but offers you new possibilities through new APIs, etc., would you use this Nuget package or would you rather say, I won't use this Nuget package because Microsoft might abandon the technology used at some point?

---

I would typically be using a package that corresponds to the type of application I was developing, if I am using Winforms then I am not going to use a package that requires me to take a dependency on WinRT or WPF.

This is basically a trade off, does learning the new technology being enough benefits compared to the existing technologies I am familiar with?

I think there is a bigger difference between a nuget package and a full technology stack like WinRT than is obvious from this post. I wouldn't adopt an entire tech stack such as MAUI because of a single nuget package, it would typically be the other way round - once I had chosen a tech stack then I would evaluate the benefits of any given package.

Choosing something more fundamental, such as WinRT over WPF would be a different matter - in this case the tech stack would have major implications for how the software is designed and what it is capable of doing.

I can't avoid MS as we are using it at the office.
From my point of view after forcibly working with the new "all around azure" technologies....Avoid it like the plague. Countless DOS attacks, servers going up and down, paying extra for more security that initially was not clear that you might need it, cost on everything you do. Queries - logs , everything you hear the money "ding ding ding" sound. Also we are using graph for some email sends. Slow, not comparable to a nice exchange and I was importing it to send a simple mail , when he happily added 150MB to a project that previously send emails with 5-10 MB size.
I'm writing this for azure specific. Not sure on any new technologies MS might getting ready to release but what I see around these days is anything but MS. But well, office, plus I don't care I'm bored with programming so I don't look around much.

Quote:

---

Originally Posted by -Franky-

@yereverluvinuncleber I can understand your point of view. On the other hand, GDI+, WIC, XAudio2 and the Media Foundation were also new technologies years ago. I can't remember anyone refusing to use them because Microsoft might abandon them at some point. Of course, if you don't use these technologies, Microsoft will abandon them at some point or replace them with newer technologies.

---

I picked up GDI+ to use in my VB6 SteamyDock and I chose it precisely because it had a proven track record of functionality and support, it was quick enough and likely to be available forever. Just as important, I could learn from it and what I learned would stand me in good stead for the future. It filled my criteria perfectly.

When you are a hobbyist as I am - and not immersed in a new technology 100% of the day, then I can only learn in a gradual fashion step by step, I can't afford to waste my time learning temporary technologies that have an ever-decreasing shelf-life..

Quote:

---

Originally Posted by yereverluvinuncleber

I picked up GDI+ to use in my VB6 SteamyDock and I chose it precisely because it had a proven track record of functionality and support, it was quick enough and likely to be available forever. Just as important, I could learn from it and what I learned would stand me in good stead for the future. It filled my criteria perfectly.

When you are a hobbyist as I am - and not immersed in a new technology 100% of the day, then I can only learn in a gradual fashion step by step, I can't afford to waste my time learning temporary technologies that have an ever-decreasing shelf-life..

---

That's exactly what it's about. But it could still be that MS will give up on GDI+ at some point. There is still WIC in connection with Direct2D as a replacement for GDI+. But the fact is that newer technologies are more geared towards C#, WPF, UWP, etc. VB6 has long since left that and TwinBasic is only just starting to grow. What I'm trying to say is, is it still worth porting something like WinRT, XAML, App SDK, etc. for VB6 and/or TwinBasic? I can confirm that it works. It's just a lot of work involved, which may put many people off from dealing with these technologies.

I doubt that MS could remove GDI+ as it is such an essential layer on top of GDI. I suppose they could. It would mean a complete dumping a lot of the way that windows are drawn within the o/s itself and a rewrite of .NET wrappers that use GDI+ under the hood, replacing it with something they have already not replaced it with? I doubt that very much. It'll be there until Windows dies... but learning all the later stuff just in time for it to be deprecated- again? Too painful and my brain can only absorb so much.

As Olaf is fond of saying, using an open source graphics framework might make more sense or a stable multi-platform framework that has a proven track record. If it is too MS centric you can bet that your investment will soon be decried as being 'old', 'legacy' and "needs another re-write".

I'll listen and take advice for people that know better than me. I am listening.

I waited around coding and coding in VB6 and then TB arrived to drag me back into the sunlit uplands of future coding. I am now back at a place that resembles the cutting edge of development, a new product, language enhancements, all in trad VB.

I am of the opinion that if you keep your eyes open, a future WILL present itself.

GDI+ will certainly be around for quite a while. But in my opinion GDI+ is already a bit outdated because it is not flexible and Microsoft has not added any new functions for a long time. GDI+ only uses C# and VB.NET from the System.Drawing namespace and even there some GDI+ functions are missing. UWP, WPF etc. use WIC and Direct2D in the form of WinRT, XAML and the App SDK. I cannot imagine Windows itself using GDI+ to render windows.

Using Direct2D the way they based WPF on it is the weird one becasue DirectX (the underlying tech) is geared more towards games.

So what they ended up is desktop apps using gaming technology and they had to re-implement all the windows controls (EditBox, ComboBox, Buttons, etc.) over Direct2D/DirectX the way Olaf had to reimplement all controls in RC6 over Cairo. They look the same (or very close) but sometimes are not exactly 100% the same in behavior as reimplementing all the glitches is hard -- just think about what Wayne is doing with TB now.

cheers,
</wqw>

Quote:

---

Originally Posted by -Franky-

GDI+ will certainly be around for quite a while. But in my opinion GDI+ is already a bit outdated because...

---

Oh, yes, completely outdated but my reasons for using it were purely my own and not very sensible, I was learning old tech. from the late 90s/early 2000s, VB6 and GDI+ combined, VB.NET 2003 &c.