Hacker News Reader

Comment by pjc50 | Hacker News Reader

The WinForms API also survives from the mid 80s, and is interestingly different. I believe the classic controls were originally drawn in the kernel?

View on HN

Sorry for the pedantry, but you're thinking of the Windows API, specifically the user interface bit (user32.dll as of Windows 95 and NT but it existed before) which is based on GDI which is hardware accelerated. It still exists but it rarely used for new applications today, but it was certainly in use for a very long time.

WinForms was briefly promoted as a successor, based on GDI+. It was quickly abandoned, as was GDI+ which never got hardware acceleration, in favour of WPF which is based on DirectX which is obviously hardware accelerated. But in that small time it caught on and continues to be used for new projects because it's a simpler programming model than WPF and it's not obvious in Visual Studio that it's been abandoned (it's not quite deprecated).

One can use WPF just like WinForms, with code behind and plain drag-and-drop of components.

The problem is that when beginners start searching for tutorials they usually land on MVVM, data binding and how WinForms style is a bad practice and they end up feeling overwhelmed.

Ironically MVVM is also possible to do in WinForms, but the capabilities aren't as rich as in WPF, so very few end up going that route.

MS Windows is definitely a good counterpoint to this blog post. Whatever the kernel/userspace split (which has changed over time), the basic Windows model is that the logic & code of the windowing system is all in the 'server' (i.e. the OS libraries, sometimes including kernel-space code).

The 'clients' (Windows applications) don't have to do their own font rendering, widget drawing, etc, they can use several different 'server' APIs to do so. Even so, the framework has proved remarkably long-lasting, with decades-old programs still capable of running on modern systems.

Actually the logic and windowing happens in each client in user space, which is why you can’t build alternative window managers, and Microsofts policy of compatibility ‘shims’ and hacks that allow chosen old software (and they choose a lot of software) to work on modern systems has nothing to do with it.

Have a quick search online, and you'll find plenty of alternative window managers for Windows. But it's besides the point, because both styles of graphical windowing systems can support alternative window managers.

The Windows ‘solution’ is really fragile and dangerous because it involves injecting code into all programs.

If there’s a vulnerability the whole system is compromised, if there’s instability the whole system crashes and if part of the system is separated out, like what Windows does with windows belonging to elevated processes, these windows follow the original rules set by Microsoft.

WinForms is much more recent than that. It was introduced along with the .NET Framework around 2000.

The original classic controls were implemented in USER.EXE (which was actually a DLL) starting in Windows 1.0 around 1985. WinForms wrapped these controls and others in a .NET interface.

You probably mean Win16/Win32, not WinForms. But it only survives in the sense that it’s still there, not in the sense that it’s still useful. How many applications created in the last five years use Win32 for anything but creating a top-level window (usually via Chromium/Electron)?

> How many applications created in the last five years use Win32 for anything but creating a top-level window (usually via Chromium/Electron)?

I think that you're in a bubble for that one. Many business domain-specific applications are still directly written against Win32 even today. UWP didn't manage to catch up for now either.

Electron usage is mostly only in startup-y apps and some IDEs.

No experience is universal, so I'm curious in what industry you encounter Win32. Or do you mean WinForms? I often work with industrial manufacturing companies in Europe, with a mindset about as far from that of Silicon Valley startups as you can imagine. You usually won't find Electron there. Many "legacy" projects are in WinForms. But for newer stuff, I see lots of WPF and Qt projects, both of which don't use native controls.

Qt has more impact as far as I can see. However, where I went, I didn't see it resulting with anything deployed to production yet...

That is also my experience.

Outside games, most modern Windows applications, specially in the areas you mention, I have also seen WPF/Qt, with plain old Win32 just as glue for underlying OS APIs.

There are still some odd ones that keep doing MFC, or enjoy a mix of Delphi/C++ Builder.

The only old style C Win32 applications I have seen in the wild during the last decade tend to be surviving applications from the 90's, done by companies not so much into Windows C++ frameworks.

How many Windows applications have been created in the last five years at all?

Not much of a PC gamer, are you? :)

We were talking about widget libs and non-cross-platform apps, so PC games didn't come to mind for both reasons.

I still mourn the days of shareware.

Reply on news.ycombinator.com