Compatibility with HLL Compilers (C++, C#) and Operating Systems

The integration of assembler code with applications written in high-level languages brings benefits in particular scenarios, such as the implementation of complex mathematical algorithms and real-time tasks that require efficient and compact code. Nowadays, no one uses an assembler to implement a graphical user interface (GUI), as there is no reason to do so. Modern desktop operating systems are designed to provide a rich user experience, supporting languages such as C#, C++, and Python in the implementation of user interfaces (UIs) through the use of libraries. While those UI generation functions can be executed from the assembler level, there is virtually no reason to do it. A more effective approach is when the main application is written in a high-level language and executes assembly code as needed to perform backend operations efficiently.

Windows OS historically supports unmanaged code, written primarily in C++. This kind of code runs directly on the CPU. Since the introduction of the .NET framework, Windows has provided developers with a safer way of executing their code, called “managed code”. The difference is that managed code, written commonly in C#, is executed by a .NET framework interpreter rather than being compiled to machine code, as unmanaged code is. The use of managed code brings multiple advantages for developers, including automated memory management and code isolation from the operating system. This, however, raises several challenges when integrating managed code and assembly code.

Continue here

Programming for applications written in unmanaged code

Programming for applications written in managed code In the case of managed code, things get more complex. The .NET framework features automated memory management, a mechanism that automatically releases unused memory (e.g., objects for which there are no more references) and optimises the location of variables for improved performance. It is known as a .NET Garbage Collector (GC). GC instantly traces references and, in the event of an object relocation in memory, updates all references accordingly. It also releases objects that are no longer referenced. This automated mechanism, however, applies only across managed code apps. The problem arises when developers integrate a front-end application written in managed code with assembler libraries written in unmanaged code. All pointers and references passed to the assembler code are not automatically traced by the GC. Using dynamically allocated variables on the .NET side and accessing them from the assembler code is a very common scenario. GC cannot “see” any reference to the object (variable, memory) made in the unmanaged code; thus, it may release memory or relocate it without updating the reference address. It causes very hard-to-debug errors that occur randomly and are very serious (e.g. null pointer exception). Luckily, there is a strict set of rules that must be followed when integrating managed and unmanaged code. We discuss it below.