[simion314]

Thanks for response, I agree with parts of your response but I do not understand what you mean with "components encapsulating Windows APIs, COM, WinRT" in comparison with .Net , I mean .Net also wraps the majority of the win32 and other APIs.

[DelphiABall]

Delphi has make it very easy to call the Windows API, COM and WinRT, with wide coverage, and encapsulates some of the complexities to make it easier for developers, as you would expect from any good programming tooling today.

Where it gets very cleaver is actually in the way OOP/components are used under the hood to already make many modern features cross-platform ready!

e.g. The same component used by developers for linking to the Notifications API's on Windows 10, works on Android, iOS and macOS! Under the hood, Interfaces are providing back the platform specific implementation, but at a high level you just work with the same component in code, making it very fast to develop cross platform.

The same is true of the RTL for parallel programming, file access etc. - This is thanks to the way API's get encapsulated. I hope that answers the question.

[simion314]

Thanks for trying to respond, it was clear to me that Delphi is similar with Qt ,Java and .Net and encapsulates platform specific stuff in OOP components. My question was why Delphi over C# ? The answer seems to be that if you don't want or can't use the .Net runtime dependency, or maybe if you want small binary size or small memory usage.

My conclusion is that for Windows only GUI there is no major advantage in favor of Delphi, .Net has more tools and libraries. For cross platform it seems Delphi has a superior story though with official support for GUIs on major platforms so is more similar to the Qt Toolkit (Qt also includes a GUI designer and non GUI related components).

[candiodari]

Yes but the resulting .exe depends on like 20 installed .dlls. For starters, the .NET runtime, which will fundamentally limit where your app runs.

Second updates in those underlying dlls and runtimes may prevent your app from working correctly.

So if the customer doesn't have or screws up their .NET installation, your app stops running. Getting a Delphi app to stop running on windows through bad sysadminning ... I haven't seen it done.

Think of C# apps like java .jar applications. They end in .exe, but they're not, not really. And at least .jar makes it a lot clearer it needs a JRE to run, and it's cross platform to boot.

[kcartlidge]

> Yes but the resulting .exe depends on like 20 installed .dlls. For starters, the .NET runtime, which will fundamentally limit where your app runs. Second updates in those underlying dlls and runtimes may prevent your app from working correctly.

Not these days (for newer codebases).

The DotNet Framework has that issue with the runtimes, but it's been a fair few years since Microsoft were suggesting people start new projects with the Framework for much other than WinForms.

The present and the future of DotNet is DotNet Core, which can produce cross-platform single-file stand-alone dependency-free binaries, well suited to a copy/paste deploy if you want.

That said, away from Windows you're a bit screwed for the GUI. It's a great flow for cross-platform console tools and web apps/servers though, especially with the free VS2019 Community Edition or, better still given it is many gigabytes less and cross-platform, with VS Code and the C# plugin.

[simion314]

Your reply is not what I asked.

I know the issues with the .Net dependency, like user has 4.0 but the app depends on 4.5 or similar problems. But this is not a big issue and you can if you want bundle the Java or .Net runtime inside the application.

Anyway I was aware of this binary size / memory usage difference in favor of unmanaged code, my question was something else, if you can clarify that or admit it was an error would be great.