Comment by slg | Hacker News Reader

Comment by slg | Hacker News Reader

Parent Full thread

>A single developer can start up a Winforms project and throw something together in a matter of days to weeks. It can only be used by people on desktops running Windows while they are at the office, but that is fine because that is the world of 2004.

...

>People underestimate how simple Windows everywhere made life for developers. Amazing documentation, stupid good tooling, and an obscenely stable platform to develop against. A major OS version came out what, once every 3 or 4 years? And unless you were writing drivers, that major OS version wasn't going to break anything.

I was doing this exact work during this time and things weren't that easy back then either. Does anyone remember DLL Hell[1]? Even if everyone was running Windows on an corporate machine, it was still more difficult to deploy new code than it is today. Being able to deploy the same code to a wide variety of different machines is a huge cost saver today.

[1] - https://en.wikipedia.org/wiki/DLL_Hell

I was doing that exact work back then, as well, and DLL hell was mostly gone by then. If you had a dependency, you simply packaged it alongside your main binary, and it wouldn't affect any other app on the system. DLL hell only arose when apps would try to install their dependencies globally (i.e. into \WINDOWS or \WINDOWS\SYSTEM32), but it was already rather uncommon by early 2000s, except for the most foundational runtimes like the C++ one.

.NET pretty much solved the problem even for globally deployed dependencies by imposing physical versioning, and added file signatures for good measure, so that your dependency would literally be on that exact copy of the DLL.

I had direct experience with some apps in VB6, some in Delphi, some in .NET/WinForms, and even one in C++/wxWindows. None of them had any DLL hell issues. Not as in I dealt with them, but as in they simply never arose in the first place.

> Even if everyone was running Windows on an corporate machine, it was still more difficult to deploy new code than it is today

Is that true? As someone who was also doing native Windows desktop applications back then (C# and VB in .net from 2006-2010), ClickOnce handled everything pretty reliably for Windows XP/Vista/Server (even with weird DLL requirements -- for example, I had to ship a QuickBooks Desktop API wrapper and propritary Epson drivers in our .net desktop app)

Yes, it's not quite as reliable as "go to my-app.com". But it was way more reliable than Electron's current self-updating (.net ClickOnce loaded in a tiny fraction of the time that Slack and Discord's Electron apps take to check for updates on every launch)

Well that Wikipedia page exists so I wasn't the only one running into the issue. I will note that the time period you listed is a few years after this problem peaked. These issues were a lot more pronounced in the VB Classic era and were greatly improved in the first few releases of the .Net Framework. Your timeframe is just after that.

Static linking worked fine, there is a reason small apps shipped with the vb6 runtime dlls in their zip file.

And for locked down corporate machines life was even easier. Same base image, same libraries installed.

Also DLL hell had been solved by the Windows XP timeframe with side by side installs of multiple dll versions.

Reply on news.ycombinator.com