
Microsoft and the UWP for Enterprise Delusion - garganzol
https://deanchalk.com/microsoft-and-the-uwp-for-enterprise-delusion-f22fcbbe2757
======
zamalek
These are only opinions, just like the article. I agree with the author that
mobile isn't enterprise. Even _if_ enterprise is clamoring for it now, it is a
fad for precisely the reasons that the author pointed out. It's a local
minimum of productivity that we will eventually tunnel out of; to an area
where a real productivity curve exists (mouse, keyboard and monitor most
likely).

I disagree that UWP is synonymous with mobile and the author has used the two
interchangeably incorrectly. UWP, in theory, runs on all devices but -
newsflash - Windows mobile is completely dead. It's exactly like having a go
at Linux because it supports DEC.

All UWP is, is a more modern version of WPF that supports more than one
execution target (CLI, JS or native). It so happens to run across many
devices. I can't see why you wouldn't develop your enterprise software using
it (apart from the horrific store) because it's no different from any other
stack. If you don't care about it working on mobile, don't deploy to mobile.
If you don't care about XBox, don't care about XBox. If you care about one
platform only, support that one platform only.

The bonus is that if you aren't enterprise, and do care about the platforms
you support, you can carry your skills there. Now, you'd be utterly mad to
actually use it (as you would depend on users mad enough to use the store) -
but that's the idea behind it.

~~~
therockhead
The platform UWP needs to run on is Windows 7. Without that support it’s not
an option for my company.

~~~
dingo_bat
Why though? Does your company mandate 10 year old cars too?

~~~
jenscow
Cars are physical objects that degrade with use/time.

An operating system will run as good as it did 10 years ago (just not as good
as those released 10 years later)

~~~
hamandcheese
This isn't strictly true, as exploits are found the experience can definitely
degrade.

------
__d
I work in a similar space, although more focussed on the backend. I agree with
everything you say _as is applies to banking /trading_.

BUT ... it's not clear to me that the majority of enterprise software
development falls into this category. I think the vast majority is quite
likely old VB apps that work perfectly well as web apps.

Most information workers don't have the density or latency constraints that
the finance space does.

And where they do, I think in most cases their needs are satisfied by a small-
ish set of applications: Excel, AutoCAD/ProE/Solidworks/etc,
Photoshop/Illustrator/etc, VisualStudio, and so on.

I do think Microsoft (and Windows) needs a story for the development of
"professional" apps like these. And UWP doesn't work for them. I'm not sure C#
and WPF does either: how many of even Microsoft's own professional apps are
written (or being rewritten) in C#?

Perhaps banking/trading is just too small a market to make it worth
Microsoft's while to care about? Perhaps it's a market best served by a third-
party stack/tools?

~~~
seanmcdirmid
Visual Studio is written in C# and I think WPF, but I'm not sure anymore at
this point. Most professional apps have a wide audience, and therefore can
justify more development resources, so they tend to get written in harder ways
(C++ and whatever UI works there). C#/WPF work great for apps that require
lower costs/more productivity because they aren't going to a million seats.

~~~
ComputerGuru
Visual Studio is not written in C#/WPF, it’s written in a mess of legacy COM
and WIN32 code with some C# and SWF.

(Visual Studio for Mac is, of course, an entirely different product and
codebase).

~~~
sjmulder
I'm quite sure the IDE is WPF. You can attach a debugger to it and inspect the
WPF component tree.

~~~
copper_think
You're both right. Yes, it's WPF, and there are lots of parts written in C#.
But the parent is right -- Visual Studio is C++ using COM and Win32 at its
core, going back all the way to the Visual Basic IDE that shipped as part of
Visual Studio 6. It would be a very difficult port to Mac, Linux, etc. As of
this writing there is even no 64-bit version for Windows (although that's just
a matter of spending the time and money to do it.)

The brand name has been re-used for other software. Visual Studio for Mac is
Xamarin. Visual Studio Code is on the Electron platform.

~~~
chrisbennet
Surprisingly, the lack of a 64 bit version is a performance choice.

 _”For a long time now developers have been asking why Visual Studio hasn’t
made to switch to 64-bit. Rather than effort or opportunity cost, the primary
reason is performance.”_
[https://www.infoq.com/news/2016/01/VS-64-bit](https://www.infoq.com/news/2016/01/VS-64-bit)

------
dingo_bat
I think we have to ask ourselves, why do we need apps that run on the local
machine anyway? 90% of my CPU time goes to Chrome/Firefox. Outlook in one of
those runs better than Outlook native on Windows. Play music in the browser
works as well as any native music player. Netflix in edge runs as good as the
UWP Netflix app. I suspect there's a lot of code reuse among them. There is no
mass market for desktop apps anymore.

Even things like slack run better in the browser than outside as an
independent app, because they anyway use a browser engine to run for
compatibility.

I use vim and VS code for editing. Vim doesn't need a new framework, and VS
code bundles an entire web browser engine within it (electron), again, for
cross platform compatibility.

All the internal company tools like code review, ticket management, etc. which
used to be native apps, now run in the browser, too.

So let me ask again, why do we need a new app framework at all? What we have
with WPF is good enough for the rare app that actually needs to run natively.
Everything else is a web app already.

~~~
garganzol
Web apps deliver scientifically non-reproducible results and have obvious
privacy implications. As a consequence, people cannot use them to design a
PCB, simulate a circuit, drive a production line and everything like that on
professional scale.

Yes, Web is a damn good technology for distribution, consumption and
communication, but I vaguely imagine a situation when a professional relies on
Web to do the real manufacturing job on a daily basis with guaranteed, stable
and reproducible outcomes.

Please note that enterprise is a huge paying market. You cannot ignore it, as
it lies behind everything you can buy in this world.

~~~
jenscow
But, would you consider UWP being appropriate with those types of
applications?

I mean, if an application is well suited for UWP, then it's probably better
off as a web app.

~~~
mcaravey
For example : I used to work for a power system analysis company that built a
UWP app for use by engineers while on the floor of a factory or something
similar. Is used for drawing electrical diagrams, data capture, and there had
been plans for some level of analysis in the app too. But the main reason it
is a UWP app is the touch interface. Not really feasible as a web app,
especially if there's no internet on the factory floor.

[https://www.microsoft.com/en-us/store/p/easypower-
onsite/9nb...](https://www.microsoft.com/en-us/store/p/easypower-
onsite/9nblggh5ggfk)

------
smacktoward
_> The Enterprise doesn’t care about mobile — it really doesn’t. _

The enterprise didn't care about minicomputers, until it did.

The enterprise didn't care about PCs, until it did.

The enterprise didn't care about Web applications, until it did.

In each of the above cases, there were people insisting that The Enterprise
would never follow the general market. The Enterprise has special needs, they
said. The Enterprise needs things the new tech can't provide, they said. They
kept saying that right up to the moment The Enterprise finally moved and made
their objections irrelevant.

Enterprise customers see the hot new stuff general consumers have access to.
They _want_ it. And they command big enough budgets that someone will
eventually get the hot new stuff up-armored and Enterprise-Readied so they can
use it to peel off a share of those budgets. By the time this actually gets
deployed the hot new tech isn't hot or new anymore, but that doesn't matter.
Once the first enterprise domino falls, the rest tend to fall pretty
predictably.

You can make a good living for a long time selling legacy tech into the
enterprise market. But "a long time" does not mean _forever._ Enterprise
software buyers move slowly, but they _do_ move.

~~~
phillipcarter
The author does a fair job explaining what he means:

> _The few mobile enterprise apps currently out there are more about
> productivity triage — a quick glance while your getting a latte — nothing
> more._

Do you disagree with that assertion, or just his general statement?

------
ricg
Another huge pain point of UWP: the whole suspend/resume concept.

UWP apps can't be closed by the user. The system manages the lifecycle and
there's no way for a developer to know when the app will be terminated and
when to save data.

To save your app's data you have to:

\- Register for a suspend event

\- Ask for an extended execution so that your app is not terminated within a
few seconds

\- Save your data and cross your fingers that the system does not terminate
your app anyway and your data is lost

I recently ported a document-based macOS app to UWP and this was the BIGGEST
pain point (aside from the fact that there's no easy way for an app to have
more than one window, ouch).

~~~
rymate1234
It's worse when your app requires to maintain a constant connection to a
server in order to function - when the app suspends good luck knowing when
that connection will be closed, even with an extended execution!

~~~
pjmlp
Well, that can be sorted out with a background task.

~~~
ricg
Even with a background task your app can be terminated by the system without
further notice after the suspend event (e.g. when the user powers off the
device). There's no orderly fashion in which an app can be terminated and save
its data.

~~~
pjmlp
The suspended even is the orderly fashion to save the data.

An ExtendedExecutionSession with a _SavingData_ reason, should be more than
enough for any kind of data.

~~~
naikrovek
Thank you. I was wondering if someone was going to mention this.

------
avinium
If anyone from MS is reading this, please consider throwing some support
behind WPF. It's actually a very reasonable framework for native development,
and with a few updates here and there, would be competitive (in terms of
developer-hours) with the latest JS frameworks.

I doubt that will happen, as MS is seemingly embracing the whole web-
services/HTML/JS model. VS Code might be the nail in the coffin - possibly an
Electron test-case to see if the entire VS proper can be ported over.

~~~
taspeotis
There's a glimmer of hope over here [1]. Microsoft updated the XAML Designer.
The new designer has support for UWP but note the comments. In particular "WPF
[support] will be shipped sometime after the UWP Designer has been released
and stabilized."

[1]
[https://blogs.msdn.microsoft.com/visualstudio/2017/09/11/a-s...](https://blogs.msdn.microsoft.com/visualstudio/2017/09/11/a-significant-
update-to-the-xaml-designer/)

------
starik36
The author has some good points. But the solution he proposes - bringing back
WPF with a bunch of features they didn't bother adding in the last 12 years -
that sounds questionable to me.

WPF wasn't really adopted the first time around. WinForms kept being used for
years (till this day) after WPF was the official guidance.

And now, after WPF was abandoned for UWP there is very little chance Microsoft
is going to resurrect it.

~~~
seanmcdirmid
WPF was very successful, it didn't kill off Winforms but it was used in many
many small enterprise apps.

Then Microsoft just...abandons it. Many were annoyed by that.

UWP would be reasonable if they didn't require giving up so many .net
features, I'm particularly disappointed that they killed off the DLR for it,
and made reflection more costly (because it is supposed to be ahead of time
compiled only). It also reminds me of Silverlight in the number of arbitrary
things left out from WPF.

So rather than switching from WPF to UWP, I've gone from WPF
to...Javascript/DOM/Canvas.

~~~
maxxxxx
Same here. I used to be a desktop guy but after Winforms, WPF, Silverlight,
WinRT and UWP new stuff will be web apps only. I don't trust MS on the desktop
anymore.

~~~
pjmlp
They still have a better track record than the competition regarding
supporting technologies, or changing direction on a whim.

So I am definitely betting on them, even though I also suffered some delusions
since Windows 3.x days.

------
ghostly_s
This article is pretty clueless, the author seems to be conflating his broad
experience in the banking industry with Enterprise as a whole.

> The Enterprise doesn’t care about mobile — it really doesn’t.

I guess I can't speak for The Enterprise, but only as someone who works in an
enterprise. We recently switched to a new service desk system with very strong
mobile support, from one with none. Responding to support tickets is a
significant aspect of my role, and this has been a _huge_ workflow boost to
me. Pretty much anything else we roll out to expand user's access in the
mobile space is being gobbled right up. I don't know what rock the author's
been living under but a statement like "The few mobile enterprise apps
currently out there are more about productivity triage [...]nothing more" is
crazy sauce. This space is exploding right now, although falling on their face
in that platform race does mean MS and UWP are playing a pretty minimal role
in it.

> enterprises do not buy their employees touchscreen laptops, unless there’s a
> really niche requirement — which is very rare.

Enterprise doesn't buy touchscreens laptops? We've bought hundreds of laptops
in the past year and almost all are touchscreen -- not because we give a shit
about that, but because _they are cheaper than spec 'ing a custom order from
our vendor to get one without_. I agree with the core tenet that touchscreens
on laptops are likely never going to be useful, but MS seems to be responding
to actual market conditions the author is ignorant of.

> we cannot take advantage of the super-accurate mouse and keyboard input
> devices that have been so amazing for so long.

I would posit the mouse is super accurate for pointing at fixed targets, but
has dreadful accuracy for drawing or any sort of path-based input. There's a
reason artists don't use them, and considering a broader range of input
paradigms is a decision I would not so quickly fault an OS developer for
making.

> Adobe have just release at design tool called XD that’s a UWP app. Compare
> its usability with its main (proper desktop) rivals like Photoshop and
> Sketch. The comparison is startling. XD feels like a small mobile app with
> limited capability, and its because that’s exactly what it really is.

XD is a _specialty app with an extremely limited feature set_. It is, by
design, vastly limited compared to PS because it's trying to compete with more
stripped-down successful prototyping platforms from competitors. This is a
complete red herring example.

------
polskibus
Can anyone explain, why would anyone ditch WinForms in favor of a newer
technology on .NET stack? I mean complex apps, not simple forms? Winforms is
close to metal (in the sense it is close to Windows), it's high performance in
contrast to WPF and its virtualization, it's been here for ages and can't
really disappear because WINAPI won't disappear.

~~~
Jaruzel
In order to make a WinForms app look native on Windows 10, you have to do a
LOT of manual layout/padding work. It is do-able but it's a lot of work.

Of all the main code platforms that MS push, I'm still pretty much tied to
WinForms - I prefer it, and it feels more intuitive to the way I think. It's
also been around over 2 decades now, and you can pretty much do ANYTHING with
it.

I skipped the WPF revolution, and am just about to dip my toe into UWP apps
(I'm not a professional coder). I think I'm going to find it a steep learning
curve :(

What I'd LIKE to see, is UWP running on Linux? That would really cement MS's
'run anywhere' concept.

~~~
pjc50
Why would anyone want to make an app look Win10 "native"? It looks horrible
(something is always up with the font rendering) and I'd actually prefer a
WinForms app.

~~~
skocznymroczny
What is considered "native" on Win10? The 'Metro' apps or normal 'boring'
Windows apps?

~~~
Jaruzel
'Win10 Native' in this context is making your app look like it's seamlessly
part of the OS. The big change is the default font:

Segoe UI Font:

\- Standard usage: 11pt Regular

\- Sub Headings: 14pt Semi-bold

\- Headings: 20pt Regular

WinForms in Visual Studio still defaults to MS Sans Serif 8pt - so you have to
change that at the form level before you even start. Plus all the controls
have NO padding around them, so you have to add padding manually or use panel
controls to space stuff. It's a pain, but not insurmountable.

------
flukus
The biggest downside for us is the deployment model, we'll stick with winforms
for the foreseeable future* but getting the software onto user machines is
still about as easy as it was in 1995, this is half the reason many apps
become web apps in the first place, instant deployment.

Hosting a corporate store is azure only which is a no go, so we're stuck with
the god awful click once.

There are no push deployments, when we release a new version we want everyone
to be on that version, not waiting for the app store to get around to it.

The store may have caught up in this regard, but we also need to control which
users get which version of the software for deploying preview builds.

The enterprise is MS's bread and butter and I always thought that they
understood it well, I increasingly think that they never understood it and
they just got lucky that for a time enterprise needs aligned with MS
capabilities.

*There is a project to replace many of our winforms apps with react, can't wait to see this crash and burn.

~~~
xab9
React will solve all the world's problems. If not React, then Angular.

I can't wait to see the projects falling apart when in two years G/Fb comes
out with The Next Big Thing.

------
technicalbard
I don't see a lot of engineering design, analysis and simulation software
being done in the browser or mobile device. There are a few examples, but the
really powerful stuff is desktop Windows (some still in WinForms) or
Unix/Linux. The cloud offers some great potential for doing HPC stuff on large
clusters, but the user interfaces necessary for DEFINING the problem aren't
something I want to do on a touch screen or in a web Client.

I still hate the webclients for major brand tools like SAP and Successfactors
where they still don't know about async calls...

------
m0ther
I agree with this.

I was skeptical about WPF at first, as I didn't like XAML at all. I'm happy I
stuck with it. Under XAML is a really elegant engine that you can interface
with directly (few of my WPF projects have any XAML in them at all).

I skipped UWP for the same reasons as OP, and because you can't (as far as I
have been able to figure out) distribute windows services with it. Win2D
looked like an answer to a lot of my design issues, but I got a sense that the
team building and maintaining it was smaller than mine.

If Microsoft heavily re-invested in the desktop I would be very happy.

~~~
cm2187
The problem of WPF in my opinion is the absence of strong typing (all binding
is based on magic strings) and the fact that if you want to customise a little
bit a control you are left rewriting it from scratch. WPF could be a lot
better and easier to use than it is.

~~~
m0ther
That binding system is XAML specific. If you bypass XAML, you bypass the magic
string binding as well.

I found interfaces a lot easier to build when I ditched the declarative markup
and interfaced with the control system directly. XAML as far as I can tell was
introduced as an attempt to woo web developers; but it's a thin layer _ON TOP_
of WPF. It seems like a lot of people believe it _IS_ WPF. WPF goes very deep.

~~~
vitorgrs
The same thing happens on UWP. People see XAML and thing that UWP is just
that.

------
drawkbox
I'll take the otherside, WPF was only useful on Windows desktops. UWP apps can
run on desktop, mobile even consoles. Before UWP developing across all devices
was much more difficult. Developing UWP with Xamarin you can get iOS, Android,
Windows platforms with very minimal differences in many cases. With .NET
Standard/Core 2 even older .NET libs work in many cases except a key part of
WPF, System.Drawing.

WPF was built on older non .NET Standard/Core that doesn't work for Microsoft
anymore, Windows lock-in is dead and that is what the WPF/Silverlight game
was. They tried to platform lock in at the Windows layer with WPF but it was
too late, mobile hit soon after.

Microsoft has to be cross platform now and the lock-in has been moved up to
Azure, their new OS for developers essentially.

I think UWP is a better platform than WPF even with less maturity. Lots of
people liked WPF as it was better than the previous iteration in Winforms, and
probably grew a liking to it, but UWP is now and trying to keep old Microsoft
platforms alive is a lost cause. Devs must move to what Microsoft is pushing
just as you do with Apple, if not, feel the wrath of the future.

~~~
insertnickname
_UWP apps can run on desktop, mobile even consoles._

Windows Mobile is dead, so UWP is really just for desktops and Xbox (and
Hololens, but no one cares). How many apps are going to be used on both
desktops and Xbox? Maybe some trivial ones, like a weather app. So,
realistically, UWP is for desktop apps, and it's just not as good as WPF for
that. It doesn't even come with a multi-column list control!

~~~
drawkbox
> Windows Mobile is dead, so UWP is really just for desktops and Xbox

Surface Pros are desktops but closer to tablets/iPad style. So it is like a
desktop on mobile platform really. Lots of business apps are going to the
Surface for control reasons like that. Who knows, maybe one day Microsoft
returns to mobile phones not just tablets, Surface Pros are making inroads and
Windows Ink is solid. Bill Gates tablet vision was too early, Microsoft has a
valid competitor, but yea it is technically 'desktop'.

Big reasons Microsoft went UWP: Surface/tablets, AOT compiling, Windows Store
and building compat with .NET standard/core 2, touch inputs + mouse input,
none of which WPF offered. UWP will evolve but it is going to closely match
iOS/Android more than Windows desktops of the past.

~~~
insertnickname
UWP does have some neat new stuff, but they didn't have to ignore the desktop
like they obviously did. Desktop is a second-class citizen in UWP.

------
DrTung
Agree 100%. I had a bunch of legacy Winform apps and faced the same dilemma.

Solved it by switching to Qt. It's excellent even if you just use it for
Windows development, i.e. never use any of its crossplatform abilities.

~~~
tonyedgecombe
But then you are stuck with C++ or some crappy binding for your favorite
language.

~~~
tolger
I am considering Qt as well. Modern C++ is a very nice language. I actually
prefer it over Java, and I do a lot of Java at work.

------
youdontknowtho
i think this guy nails it.

One if the ways that Microsoft proved WPF could be used for real apps was that
they wrote visual studio with it. you cant build visual studio witb UWP.

i hope that the platform gets there...but right now if i started a new windows
app i would use the centennial bridge.

~~~
naikrovek
You can, you just can't use Microsoft's provided UWP controls to do it.

------
alkonaut
I agree with the article: enterprise will never play well with store/uwp
nonsense. I have the same background - I work in high perf very heavy desktop
.NET and I can’t see any reason UWP would work here.

But: I also see where Microsoft are coming from. There is no _need_ to
innovate in this space. Microsoft want people to run mobile, touch, store...
and those of us doing heavy desktop can use third party tooling _or_ just stay
with the mature tools we already have. Microsoft will never sunset the legacy
win32 stack, and enterprises of the kind the author describes will never
choose a windows that doesn’t allow the standard win32 stack.

------
jarjoura
Reading the comments, I think most of you miss actual realistic complaints of
the author.

1) UWP apps are absolutely horrible to debug. They use some kind of COM broker
layer to deliver the majority of very cryptic framework level exceptions.
Almost everything IS an exception. There's also no way to get proper stack
traces in compiled applications and worse, only apps delivered through the
store will symbolicate the final crash point, so good luck trying to find the
root cause if it's not immediately obvious.

The level of absurdity here is, if you drop a file in a UWP app's drop target
that doesn't have foreground focus, the data broker will throw an exception
that you can't do that. There's no realistic way to manage that exception, so
if you're not diligent it'll crash your app.

2) Then there's the whole XAML interface framework. (Though they seem to
slowly be moving away from this to a more reasonable flexible framework, sort
of like iOS CoreAnimation, called Composition.) Originally it was meant to be
freely styled by "designers", but as the original WPF and Silverlight proved,
this flexibility resulted in terrible designs and apps looked cheap and
crappy. So the UWP XAML team instead built a completely stylized framework and
all the controls have hard-coded baked in assumptions about those styles
remaining unchanged. So in that aspect, even if you wanted to push UWP XAML to
allow for more information density, you would run into all kinds of show-
stoppers.

~~~
vitorgrs
They are not moving away from XAML to Composition. Composition will be just a
"backend" for XAML. Some XAML controls already use Composition and you don't
even notice it.

------
nlawalker
This is more about _desktop_ development than _enterprise_ development. With
that in mind, I think there's a better chance of people figuring out how to
get it done on UWP or with web technologies (perhaps with some help from MS)
than there is of MS improving support of WPF.

Azure is where it's at now for Microsoft, and WPF/desktop apps don't run on
Azure.

~~~
ThinkBeat
The client code could run in a browser or in a desktop application.

The juicy backend bits could run just fine in Azure.

------
jcastro
> Web apps don’t cut it. They don’t cut it as replacements for serious desktop
> apps.

I don't buy that. If the argument is that "the Enterprise" doesn't care about
mobile for this last decade, then it certainly didn't care about usable and
powerful desktop apps the decade before.

~~~
alkonaut
“enterprise” is a bit vague. But the IDE/Cad/Media creation apps aren’t going
to be mobile or web in 10 years either. It’s the “pro” apps that are key -
which perhaps isn’t “enterprise” depending on your definition.

------
jacksmith21006
Honestly do not see a lot of native development happening on Windows any
longer but far more wev interfaces of some kind. I really do not see native
coming back in a big way.

~~~
pjmlp
Doing native development for Windows, of new .NET applications, during the
last 4 years.

Many business don't want anything browser related, or need applications
working in disconnected environments.

Enterprise has many special needs.

------
thebosz
One thing I'm not seeing is people talking about _the reason_ Microsoft
created UWP: as a competitor to responsive web frameworks that could run on
their Continuum and Windows on ARM platforms.

Full stop.

Of course, the _second_ they abandoned Windows Mobile, it made UWP irrelevant
(not that it was terribly relevant anyway).

Absolutely no one* wants to build an app that works only on Windows 10
desktops, Xbox and IoT devices. There's no use for that.

*Obvious hyperbole.

------
cra1ghunt
I understand the author's frustration, though I don't agree with all of his
points. However, what is Microsoft's motivation for investing in WPF at this
point? If they don't improve WPF, will enterprise customers stop using
Windows? Unless it moves the needle significantly one way or another, they
won't do much with WPF. Besides, they have their hands full on other fronts.

------
tinus_hn
The mistake made in this article is that the problem with UWP is not that it
is touch, but that it purports to be universal. There is no universal solution
that works on both touch platforms and the desktop. Either it sucks on one of
these or both of them.

The right solution is to make it so what can be shared is shared and what
needs to be specialized can be specialized.

------
rmrfrmrf
Enterprise isn’t Windows-only anymore. If you’re not targeting Mac and Linux,
too, you’re doing it wrong.

------
samcat116
This might apply for banking/trading, but it does not apply at all for
education markets.

------
jenscow
UWP comes from the "cloud-first mobile-first" Microsoft.

Neither are well suited to enterprise, and one of which has been canned.

------
lafar6502
Ha ha it would be a progress if they dug out win forms and made it official
api. And I’m not throwing away my Petzold

