How do Delphi, WPF .NET Framework, and Electron perform compared to each other, and what’s the best way to make an objective comparison? Embarcadero commissioned a whitepaper to investigate the differences between Delphi, WPF .NET Framework, and Electron for building Windows desktop applications. The benchmark application – a Windows 10 Calculator clone – was recreated in each framework by three Delphi Most Valuable Professionals (MVPs) volunteers, one expert freelance WPF developer, and one expert Electron freelance developer. In this blog post, we are going to explore the Hardware Access metric which is part of the flexibility comparison used in the whitepaper. The calculator app itself does not make use of the hardware access in each framework so the comparison is between frameworks themselves.
Table of Contents
Access to Device-Specific Hardware
Does the framework facilitate access to data from device sensors (GPS, microphone, accelerometers, camera, etc.) and physical action through similar devices? Frameworks that “throw open the doors” to the multitude plethora of sensors and actuators available on smart devices today create business opportunities and novel solutions to consumer pain.
Delphi’s standard libraries provide easy access to nearly every database type available and allow developers to access operating system functionality on every platform as well as interact with I/O devices and hardware sensors. WPF can access Windows operating system functionality and I/O devices through .NET libraries but with managed code after compilation rather than native code. Electron provides hardware access from its node.js process and can access some but not all operating system functions via node.js libraries.
After reviewing all three frameworks, Delphi holds the lead in the flexibility category due to its flexible and automated deployment to all major platforms, scalability to every level of development, and visual design system. WPF with .NET Framework is competitive on the Windows platform but lacks the ability to compete on macOS or mobile devices. Finally, Electron has the fewest barriers to entry and the most development tool options but relies heavily on manual deployments, cannot target mobile devices directly by default, is the least scalable, and lacks the same hardware and operating system access of its competitors.
Let’s take a look at each framework.
Delphi Hardware Access
Delphi’s FMX framework includes libraries that allow interaction with a device’s peripheral sensors and components regardless of platform. These libraries compile into native code. The Delphi RTL, direct memory access, and other low level features give it full access to the hardware platform, including inline assembly code on x86 desktop platforms.
Here are two examples featuring conditional compilation and inline assembly (between asm and end; tags).
Kernel Mode Driver
It is possible to create kernel mode drivers for Windows in Delphi. Kernel Mode Drivers are defined by Microsoft as “Kernel-mode drivers execute in kernel mode as part of the executive, which consists of kernel-mode operating system components that manage I/O, Plug and Play memory, processes and threads, security, and so on. Kernel-mode drivers are typically layered. Generally, higher-level drivers typically receive data from applications, filter the data, and pass it to a lower-level driver that supports device functionality.”
https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/
Windows Management Instrumentation (WMI)
Delphi offers easy access to WMI and there is an open source project that will quickly generate the code you need. According to Microsoft WMI is defined as “is the infrastructure for management data and operations on Windows-based operating systems.”
https://docs.microsoft.com/en-us/windows/win32/wmisdk/wmi-start-page
The RTL provides a component, TBluetooth, that gives you access to all the Classic Bluetooth features of the RTL. Drag a TBluetooth component from the Tool Palette onto a form or data module of your application.
A sensor measures a physical quantity and converts it into a signal that can be read by an application. System.Sensors.Components provides your applications with components that let you obtain information from many different types of hardware sensors.
TBiometricSensor | TBiometricSensor is a wrapper for TCustomBiometricSensor. |
| TElectricalSensor | TElectricalSensor is a wrapper for TCustomElectricalSensor. |
| TEnvironmentalSensor | Wrapper for TCustomEnvironmentalSensor. |
| TLightSensor | Wrapper for TCustomLightSensor. |
| TLocationSensor | TLocationSensor is a wrapper for TCustomLocationSensor. |
| TMechanicalSensor | Wrapper for TCustomMechanicalSensor. |
| TMotionSensor | Wrapper for TCustomMotionSensor. |
| TOrientationSensor | Wrapper for TCustomOrientationSensor. |
| TScannerSensor | Wrapper for TCustomScannerSensor. |
This sample project shows how to use and manipulate the camera of a device. The sample demonstrates the use of the TCameraComponent.
WPF .NET Framework Hardware Access
WPF .NET Framework can access numerous Windows libraries for sensors, I/O devices, and other peripherals for PCs. WPF’s access to hardware is through managed code rather than native code, but there is a native (unmanaged) interface through P/Invoke. This bridge limits some access.
Electron Hardware Access
Electron can access operating system functions and hardware peripherals through node.js libraries. It’s cross-platform Chromium base facilitates high level hardware access on all major desktop platforms. Electron’s access to hardware is through managed code rather than native code and can only access features exposed through libraries.
Explore all the metrics in the “Discovering The Best Developer Framework Through Benchmarking” whitepaper:
Download the Free Delphi vs. WPF vs. Electron for Windows Desktops Whitepaper