Programming Windows: Windows Forms (Premium)

Approximately 6,000 developers streamed into the Orange County Convention Center in Orlando, Florida in mid-July 2000 to hear a more concrete version of Microsoft’s vision for .NET.

They weren’t disappointed: Microsoft added substance to the vapor of the original June .NET announcement. It announced the .NET Framework and Visual Studio.NET, the C# programming language, a .NET-based successor to Active Server Pages called ASP+. They also learned that Microsoft would finally, and belatedly, consolidate its MS-DOS- and NT-based versions of Windows in a late 2001 product that was codenamed Whistler that would be the first to include bundled .NET technologies.

But the developers who attended this show came away with another prize: a set of CDs containing a very early version of Visual Studio.NET that Microsoft declined to make available to non-attendees. And so it would be another four months, in mid-November 2000, before most developers saw what Microsoft was doing to evolve its developer tools for the .NET era. And even then, the company was curiously quiet about the major and disruptive changes it was making to one of its most beloved tools ever, Visual Basic.

A bit of background.

As you may recall, Microsoft had long sought to combine the ease of use of the Visual Basic forms designer, which even beginners could use to create decent-looking Windows applications, with the sophistication of C++ or another modern object-oriented language. It briefly achieved that goal with the Java-based Windows Foundation Classes (WFC), but after a Sun Microsystems lawsuit scuttled those plans, Microsoft went back to the drawing board and created .NET. In many ways, .NET was based on Java, with some key enhancements. And one of those enhancements was that it was language agnostic. Any .NET language, in theory, would offer the same capabilities as any other .NET language.

Separately from that work, Microsoft had also been evolving its Visual Studio integrated developer environment (IDE) in the late 1990s and very early 2000s, first by offering all of its disparate programming tools in a single environment. But it had long wanted to create a Visual Basic-like visual forms designer that would work across multiple languages too. And with Visual Studio.NET, that was finally happening. Visual Basic.NET and C# could be used interchangeably, accessing the same .NET Framework libraries and the same visual forms designer to create Windows desktop applications.

The problem, for most Visual Basic fans of the day, was that Visual Basic.NET was not Visual Basic. Sure, it shared some of the same idiosyncrasies as what we’ll now call classic VB, but it more closely emulated C#, the sophisticated C++/Java-like language created by Anders Hejlsberg. And because the language and class libraries it used were object-oriented and not just object-based like classic VB, Visual Basic.NET was unsuitable for the amateurs and enthusiasts who had embraced its predecessor in droves. Put simply, Visual Basic .NET left behind most of the fans of classic VB.

For those that did conquer its steep learning curve, there were bigger problems for Visual Basic .NET to come down the road. Because C# and VB.NET were essentially identical from a capabilities perspective—Microsoft had even committed to co-developing and updating them in lockstep—there was little reason for the professional developers who used Visual Studio.NET to even consider VB.NET when the more familiar and sophisticated C# language existed. And Microsoft didn’t help matters by often documenting new capabilities only in C#, leaving VB.NET users—who were, by definition, less sophisticated—having to figure out C# anyway.

Those issues would become clearer over time. But from the perspective of mid-to-late 2000, it appeared that Microsoft was making all the right moves. And despite pushing web services perhaps a bit too heavily during its back-to-back .NET introductions in June and July, respectively, it was also working to modernize Visual Basic for the .NET era and make its capabilities available to C#—and, ostensibly, other .NET languages—as well.

This modernization came to fruition in two related solutions: Win Forms, which let VB.NET and C# developers create desktop applications using VB-like rapid application development (RAD) tools, and Web Forms, which did the same but for Windows Server-based web applications using ASP+.

Win Forms—which would quickly be renamed to Windows Forms, though most developers would come to refer to it as WinForms—was literally a version of Visual Basic but updated for the .NET era. As noted it, supported all compatible .NET languages—VB.NET and C#, effectively—and it provided access to the vast, object-oriented design .NET Framework libraries and all of its advanced functionality, including its managed execution environment and integrated security functionality.

For developers who had toiled to understand Microsoft’s earlier Windows development efforts like the C-based Windows API (Win32) or the C++-based Microsoft Foundation Classes (MFC), Windows Forms was a godsend that made it almost deliriously easy to create a professional-looking Windows desktop application. As with Visual Basic, one could use its forms designer to create application windows and dialogs without the need to write any code at all, and one could likewise link up those UI components with event handlers and other code without having to muddle through the Win32 mess of message pumps, header files, pointers, and other arcana. But unlike Visual Basic, that code was sophisticated, powerful, and object-oriented, as was the underlying .NET Framework libraries.

That Windows Forms is still viable as a desktop application development environment today is a testament to the quality of it, the C# (and VB.NET) language, and the .NET Framework, which finally made a WFC-style class library available to mainstream developers. I used Windows Forms to create two versions of my Notepad replacement, .NETpad, in 2019 and 2022 (one in VB and one in C#), and I’m updating the C# version now to adopt some new Windows 11-inspired features.

Not bad for a development environment that was created over 20 years ago.