A Developer's Strange Love, or: How I Learned to Stop Worrying and Love Windows

This is an essay about how to deal with a feeling that comes with Windows app development: the fear that it will break differently from one environment to the next. It is not an article that explains how to call an API.

DLLs, COM, 32-bit / 64-bit, privileges, DPI, distribution. This piece is about why Windows carries all of these worries in the first place, and about how to turn that worry into design, testing, and observation. If you want something concrete to take away and act on, you are welcome to read only the “Worry / Design response / How to check” table in section 6.

1. The Conclusion First

When you build Windows apps, there is a lot to worry about.

Will it launch on this PC? Will it work in environments without administrator privileges? Will the 32-bit / 64-bit difference break it? Japanese paths, long paths, network drives, old DLLs, COM components, ActiveX, printers, serial communication, antivirus software, Windows Update.

Once you start thinking about it, the worries never end.

But at some point, I began to think differently.

Maybe this is not a flaw, but evidence that Windows has carried real-world business on its back.

Windows is not a pristine utopia. But it has absorbed the software, the equipment, the business workflows, and the human habits that have kept running in the field for decades.

That chaos is exactly what makes Windows interesting, and what makes it worth engaging with as a developer.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (14 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. Windows App Development Comes with Many Worries

In Windows app development, “the code is correct” is not enough.

It works in the local environment. It works on the developer’s PC. It works in the test VM, too.

Even so, there is no guarantee it will work on the customer’s PC.

For example, things like this happen:

• A DLL cannot be found
• The Visual C++ runtime is not installed
• The .NET Framework version does not match
• Loading a 32-bit DLL from a 64-bit process fails
• The COM registration is broken
• The 32-bit and 64-bit versions of regsvr32.exe get mixed up
• Code that assumes the current directory breaks under Task Scheduler
• Writing under Program Files triggers a permissions error
• AppData\Roaming and AppData\Local get used the wrong way around
• It crashes on Japanese user names or Japanese folder names
• Files cannot be opened on long paths
• It works on a mapped network drive but not on a UNC path
• The UI breaks in high-DPI environments
• Coordinate calculations drift across multiple monitors
• Print output differs depending on the printer driver
• USB devices, cameras, measuring instruments, and serial communication go unrecognized depending on the environment
• Antivirus software blocks part of the processing
• Behavior changes after a Windows Update

Lined up like this, it is a little dizzying.

Problems that a web app can confine between the browser and the server spread across the entire PC in a Windows app. The file system, the registry, user profiles, printers, devices, the network, security policies, installers, runtimes.

The application is less “running on top of the OS” than placed inside a working business environment.

That is why Windows app development is hard. But I think dismissing it as “Windows is just bad” misses the point.

What rides on top of it is the complexity of the real world.

3. Windows Is the OS of the Field

Windows is not an OS that exists only for the latest technology.

Factories, hospitals, government offices, schools, laboratories, broadcasting, inspection equipment, reception terminals, report-printing terminals, warehouses, retail stores, accounting, payroll, inventory management. In places like these, many Windows PCs are still running today.

And what runs there is not just the latest web services.

There are Excel macros. There is Access. There are old VB apps. There are .NET Framework business apps. There are resident apps written in C++. There are COM components. There is ActiveX. There are ODBC connections. There are printer drivers. There are barcode readers. There are measuring instruments on serial connections. There are vendor-supplied SDKs.

What is more, none of these exist in isolation.

People operate them, print reports, swap USB devices, drop CSVs into shared folders; nightly batches run, and the next morning’s work begins. They run inside that whole chain of activity.

Windows is not merely a substrate for launching apps. It is a platform that absorbs the field’s daily work, its existing assets, its peripherals, and even its people’s habits.

That is why it sometimes looks old. Sometimes it is complicated. Sometimes you wonder why on earth a certain thing still remains.

But that also means it has never carelessly thrown the old things away.

4. Backward Compatibility as a Form of Love

If all you wanted was to make an OS look beautiful, cutting away the old mechanisms would be easier.

Delete the old APIs. Delete the old runtimes. Delete the old settings screens. Treat old apps as things that simply do not run.

Do that, and perhaps the design becomes cleaner. Perhaps the documentation gets shorter. Perhaps developers feel a little lighter.

But behind that, there are business apps that stop working. There is equipment that grinds to a halt. There are work sites left in trouble.

Windows backward compatibility is technically a nuisance. There is WOW64 (Windows 32-bit On Windows 64-bit), which runs 32-bit apps on 64-bit Windows. The registry and DLLs can appear differently to 32-bit and 64-bit code. There is the structure, confusing on first encounter, where C:\Windows\System32 is the 64-bit side and C:\Windows\SysWOW64 is the 32-bit side.

COM (Component Object Model, the Windows mechanism that lets applications exchange components) is a nuisance too. Dropping a DLL in place is not enough; registration may be required. Is the registration per user or per machine? Is it 32-bit COM or 64-bit COM? Are administrator privileges required?

.NET Framework is the same. Today there is the option of using modern .NET, like .NET 8 / .NET 9. But in the field, .NET Framework 4.x apps are still out there. That is not mere oldness. It means that version has supported real business for many years.

Backward compatibility is not a concept that is merely beautiful. It is, rather, a heavy responsibility.

Keeping old things running means carrying technical debt. But at the same time, it is a form of integrity: not stopping the users’ business.

This, I think, is where Windows has something worth loving.

5. Windows Is an OS of Geological Strata

In Windows, the technologies of each era are stacked like geological strata.

Win32. COM. ActiveX. Windows Forms. WPF. .NET Framework. UWP. WinUI. Windows App SDK. MSIX. PowerShell. Windows Terminal. WSL.

Each had its era of arrival, its strengths, and the work sites where it has been used.

If you look only at the new, the old may look like clutter. But in Windows app development, there are many situations where you cannot ignore the older strata.

For example, even when building a WPF app, printing can bring you into contact with GDI (Graphics Device Interface, the drawing and printing machinery Windows has carried since its early days) and with printer driver issues. Even writing C#, if a vendor SDK is a native DLL, you touch P/Invoke (Platform Invoke, the mechanism for calling functions in a native DLL from C#) and bitness issues. Even when building new screens, you may need to keep existing COM components or Excel integration.

Windows is not a perfectly manicured garden. It is closer to a vast city that has been extended and rebuilt again and again.

There are main boulevards. There are underground passages. There are old back alleys. There are new high-rises.

It is easy to get lost. But deep in those alleys, important business is still running today.

If you want to follow that record of extension and rebuilding concretely, as a timeline rather than an essay, see Why Windows Became What It Is Today: The Evolution of Windows Through a Developer’s Eyes. It lays out Windows 95 through Windows 11 as a sequence of changes seen from a developer’s point of view. Read that one if you want to know which stratum was laid down when.

What a developer needs is not the judgment that “old means unnecessary.” It is discerning which stratum of technology supports which business.

6. Turning the Hassle into Design

The title says “to stop worrying.”

But to stop worrying does not mean getting sloppy. Nor does it mean pretending not to see the problems.

To stop worrying is to turn the worry into design.

For example, if you are anxious about whether it launches, turn the launch check into a smoke test.

Start-Process .\MyApp.exe

And do not just launch it. Also try it with no configuration file, no log folder, standard user privileges, no network connection, no printer configured, high DPI, long paths, and Japanese paths.

If DLLs make you anxious, verify the dependencies. If the Visual C++ runtime is required, decide whether to bundle it in the installer or to state it explicitly as a prerequisite. If you use native DLLs, do not leave the x86 / x64 / AnyCPU relationships vague.

If COM makes you anxious, write the registration steps into a runbook and reproduce them from scratch on a test PC.

# Example: registering a 64bit COM DLL
C:\Windows\System32\regsvr32.exe .\SomeComponent64.dll

# Example: registering a 32bit COM DLL
C:\Windows\SysWOW64\regsvr32.exe .\SomeComponent32.dll

If permissions make you anxious, avoid designs that only work with administrator privileges. Put per-user settings in AppData and machine-wide settings in ProgramData. Avoid designs that write logs under Program Files.

If paths make you anxious, include Japanese characters, spaces, long folder names, and UNC paths in your tests.

New-Item -ItemType Directory -Path "C:\テスト 用\とても長いフォルダー名\さらに深いフォルダー" -Force

If DPI makes you anxious, check at 100%, 125%, 150%, and 200%. With multiple monitors, check that nothing falls apart when a window crosses displays with different scaling factors. WinForms, WPF, and WinUI each approach DPI awareness differently, so verify per UI technology.

If memory and handles make you anxious, use Application Verifier, WinDbg, ProcDump, Process Explorer, and the like. If crashes make you anxious, keep event logs, dumps, and application logs.

Get-EventLog -LogName Application -Newest 20

Or, in newer environments, check the event log like this:

Get-WinEvent -LogName Application -MaxEvents 20

If you are anxious about defects that will not reproduce for you the way they happen in the field, raise the granularity of your logging. “An error occurred” is not enough. Which file was it trying to open? Which device was it looking for? Which user was it running as? Which path was it trying to write to? Which DLL could it not load?

Turn the worry into something you can observe.

In Windows app development, this matters enormously.

Put on a single page, everything so far comes out like this.

The left column of this table is simply a list of worries. With the two columns on the right, worry turns into work.

7. “It Works on the Customer’s PC” Is the Final Goal

Working in the development environment matters. Tests passing in CI matters. Working on a clean VM matters.

But for a Windows app, the last thing standing in your way is “does it work on the customer’s PC?”

That PC already has things installed. There may be an old printer driver. There may be a proprietary security product. Network drives may be mapped. The user may not have administrator privileges. There may be reasons Windows Update cannot be applied right away. It may be an environment with no route out to the internet.

That is why the distribution method matters too.

Is handing over an exe enough? Should it be an MSI? ClickOnce? MSIX? Can it be distributed with winget? Will it go onto an internal distribution system? Is an offline installer needed? Is code signing required? Will SmartScreen or antivirus software block it?

Only when you cover not just the app itself but installation, updates, uninstallation, log collection, and recovery procedures do you get close to “usable in the field.”

In Windows app development, software is not finished at delivery. It needs to launch in the customer’s environment, today and tomorrow.

8. Why I Love Windows Anyway

Windows has its hassles. That is a fact.

DLLs. COM. The registry. UAC. DPI. Printers. Runtimes. 32-bit / 64-bit. Network drives. Long paths. Japanese-language environments. Security software. Windows Update.

List the hassles and they never stop coming.

To spell out the abbreviations: UAC is User Account Control, and DPI is Dots Per Inch, which here means the display scaling setting. Both are also another way of saying that an app cannot be self-contained.

But much of that hassle comes from the fact that Windows has carried real-world business for a very long time.

It does not discard the old assets, yet it takes in new technology too; it has a GUI and a CLI; it takes on local apps and the web, peripherals and business terminals, personal PCs and corporate PCs alike.

That is not a beautiful, unified philosophy.

But it is strong.

And as a developer, it is worth taking on.

Building software that runs reliably on Windows is not merely a matter of calling APIs. It means reading the constraints of the field, understanding the existing assets, finding the fragile spots, testing, observing, and fixing what needs fixing.

It is unglamorous. But it has value.

9. Conclusion

In Windows app development, the worries never run out.

But many of those worries are the result of Windows, as an OS, having taken on real business, real work sites, real equipment, and real human operation over a very long time.

That is why I do not think of Windows as merely an old OS.

It is a huge, complex, slightly clumsy platform that has kept running while coming to terms with reality.

And building software that runs reliably on top of it still carries great value today.

Stop worrying.

But that does not mean letting your guard down.

Turn the worry into design, testing, and observation.

That is how, little by little, I came to love Windows.

Reference Links

• Application Verifier - Overview - Microsoft Learn
• High DPI Desktop Application Development on Windows - Microsoft Learn
• Setting the default DPI awareness for a process - Microsoft Learn
• Running 32-bit Applications - Microsoft Learn
• Maximum Path Length Limitation - Microsoft Learn
• MSIX documentation - Microsoft Learn
• Version compatibility in .NET Framework - Microsoft Learn

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.