There’s nothing worse than a Delphi programmer writing code like a Visual C++ programmer. Delphi developers have the distinct advantage of creating applications that are isolated within the Windows OS. This is why applications compiled for Windows 3.1 are still running on Windows 7. However, Borland didn’t cover every area—especially when it comes to non-isolated code. One major gap is Internet-oriented applications. In this realm, the Delphi developer is forced to rely on MS libraries. Sure, there are third-party Delphi libraries available, but relying on them is no better than depending on MS libraries. If anything, it’s worse. We all know how many third-party libraries fade into obscurity or are left to rot over time.
It’s surprising how some developers, particularly those outside Europe or regions with ongoing lawsuits against MS, still assume that every computer in the world has MS Office and Internet Explorer installed by default! The truth is, that’s far from the case. You can’t afford to assume, or even hope, that the client has the latest Windows OS version, complete with service packs, IE updates, XML libraries, .NET, Java, and all the associated dependencies installed. You must begin by assuming they have none of these. Only then can you ensure your application is robust enough to work across all Windows platforms.
Relying on MS libraries is obviously not ideal for a Delphi programmer (or anyone, really). But we still need to connect to the Internet, download files (admittedly, a bit fancy for Delphi!), and maintain system independence and robustness. So, we’re stuck between two options: using third-party libraries that will likely be obsolete and unsupported in no time, or relying on MS libraries. The problem with using Delphi code to interface with MS libraries for Internet connectivity is that it often feels unreliable. It’s not multithreaded, and it lacks proper support for detecting connectivity issues. Your application could freeze if the physical connection drops, the modem fails, the ISP goes down, or the web server stops responding.
So, let’s break down the pros and cons:
Third-party Delphi libraries:
- They may get abandoned or outdated.
- Large libraries (like Indy) can significantly increase compilation time.
- Difficult to maintain.
- Often poor or no support.
- Many of them lack anti-freezing features.
MS libraries (e.g., IE):
- Might not work on all computers (especially in Europe).
- No anti-freezing support.
- Hard to use (and often no documentation).
Honestly, I’m torn between the two evils: an app freezing while trying to connect to the Internet, or failing to download a file until you convince the user to manually install MS-related libraries. And really, if you end up asking the user to visit the MS website to install the required libraries, you might as well direct them to your website and let them manually download everything your program needs. 🙂
Some might immediately think the “solution” is to bundle the necessary libraries with your app and install them when the program starts. But hold on—do you really want to mess with the user’s system? They’re extremely protective of their computers. The second they see you installing stuff into their system, they’ll be on forums declaring your app is trying to hijack their machine.