DEV Community: Nalin Jayasinghe

Understanding Programming: From Machine Language to .NET

Nalin Jayasinghe — Tue, 04 Feb 2025 10:39:56 +0000

In this post, we will write the same program "Hello, World!" in three different languages:

Machine Language (Binary)
Assembly Language (Human-Readable Machine Code)
.NET (C# - High-Level Programming)

Machine Language – The Pure Binary Code

At the core of every computer is the CPU (Central Processing Unit), which only understands binary instructions 1 and 0. This is called Machine Language (or machine code).

Here’s an x86 Linux machine code program that prints "Hello, World!":

10111000 00000100 00000000 00000000
10111011 00000001 00000000 00000000
10111001 00000000 00010000 01100000
10111010 00001101 00000000 00000000
11001101 10000000
10111000 00000001 00000000 00000000
11001101 10000000

How It Works

The binary code directly controls the CPU to make the system perform tasks such as displaying text on the screen.
It’s extremely difficult to read and write manually, which is why higher-level languages were developed.

This is why Assembly Language exists to make machine instructions human-readable.

Assembly Language – A Step Closer to Humans

Instead of raw binary, Assembly Language allows us to use mnemonics (like MOV, INT) to represent machine instructions.

Here’s the same "Hello, World!" program in x86 Assembly:

section .data
    message db "Hello, World!", 0xA  ; Define message string

section .text
    global _start  

_start:
    mov eax, 4       ; System call number (sys_write)
    mov ebx, 1       ; File descriptor (stdout)
    mov ecx, message ; Message address
    mov edx, 13      ; Message length
    int 0x80         ; Call kernel (print message)

    mov eax, 1       ; System call number (sys_exit)
    int 0x80         ; Exit program

How It Works

Readable mnemonics (MOV, INT) replace binary opcodes.
Still CPU-specific (different CPUs have different assembly syntax).
Better than raw machine code but still hard to write for complex applications. This is why we use high-level languages like .NET (C#).

.NET and High-Level Programming

Instead of dealing with system calls and registers, we can simply write:

Console.WriteLine("Hello, World!");

How It Works

The C# compiler converts this into Intermediate Language (IL).
The .NET runtime (CLR - Common Language Runtime) translates IL into machine code at runtime.
Console.WriteLine() abstracts away low-level system calls, making it easier to print text.

Comparison of All Three Approaches

Feature	Machine Code	Assembly Language	.NET (C#)
Readability	Hard (binary)	Medium (mnemonics)	Easy (English-like syntax)
Portability	CPU-specific	CPU-specific	Cross-platform (Windows, Linux, macOS)
Productivity	Very low	Low	High
Performance	Very high	High	High (Managed by runtime)

Conclusion: From Machine Code to .NET

Machine code is the raw language of computers (binary) and is tightly tied to the hardware architecture (CPU-specific).
Assembly language is a step up but still closely tied to hardware.
.NET (C#) allows developers to write clean, portable, and powerful applications without worrying about system calls or registers.

By using high-level languages like C# in .NET, we can focus on solving real-world problems without dealing with low-level hardware details.

Handling Missing Configuration with Fallback Values in Azure Functions

Nalin Jayasinghe — Mon, 26 Aug 2024 12:08:04 +0000

When developing Azure Functions, it’s essential to handle configuration values gracefully, especially if some values might be missing. In this post, we’ll explore how to use fallback values in Azure Functions for a timer trigger to ensure reliable operation even when configuration is incomplete.

Function Definition

Let's start with the function definition. Here’s how you can set up a timer-triggered Azure Function that uses an environment variable for its schedule:

[FunctionName("DataProcessingFunction")]
public static async Task Run([TimerTrigger("%MyFooSchedule%")] TimerInfo myTimer, ILogger log)
{
    log.LogInformation($"DataProcessingFunction executed at: {DateTime.Now}");
    // Your function logic here
    await Task.CompletedTask;
}

[FunctionName("DataProcessingFunction")]: This attribute names the function.
[TimerTrigger("%MyFooSchedule%")]: The function is triggered based on the schedule defined by the MyFooSchedule environment variable.
ILogger log: Used to log execution details.

Sample appsettings.json

Here is an example of what your appsettings.json file might look like:

{
  "AzureWebJobsStorage": "UseDevelopmentStorage=true",
  "MyFooSchedule": "0 */15 * * * *", // This is the schedule for the timer trigger
  "FUNCTIONS_WORKER_RUNTIME": "dotnet"
}

AzureWebJobsStorage: Specifies the storage account used by Azure Functions.
MyFooSchedule: Defines the timer schedule for the function. In this example, it triggers every 15 minutes.
FUNCTIONS_WORKER_RUNTIME: Indicates that the function app uses the .NET runtime.

Why Use Default Environment Values?

Using default environment values for timer triggers offers several benefits:

Reliability: Default values ensure that your function will continue to operate even if the expected configuration is missing. Without a default, a missing schedule might prevent the function from running entirely.
Ease of Development: During development and testing, you might not always have all configuration values set up. Default values allow you to test your function without needing to configure every detail in the environment.
Consistency Across Environments: When deploying to different environments (e.g., development, staging, production), having default values helps maintain consistent behavior if environment-specific configurations are not set.
Error Prevention: Default values prevent runtime errors and issues related to missing or incorrect configurations. This makes your function more robust and easier to manage.

Static Constructor for Default Values

To handle cases where MyFooSchedule might not be set, use a static constructor to provide a default value:

static DataProcessingFunction()
{
    // Default schedule (every 5 minutes)
    var defaultSchedule = "0 */5 * * * *";
    var schedule = Environment.GetEnvironmentVariable("MyFooSchedule") ?? defaultSchedule;

    // Set the environment variable
    Environment.SetEnvironmentVariable("MyFooSchedule", schedule);
}

Default Value: "0 */5 * * * *" specifies a default schedule of every 5 minutes.
Check and Set: The constructor checks if MyFooScheduleis set. If not, it assigns the default value.

Full Code Example

Combining both parts, here’s the complete code for the Azure Function with fallback configuration:

using System;
using System.Threading.Tasks;
using Microsoft.Azure.WebJobs;
using Microsoft.Extensions.Logging;

namespace MyFunctionApp
{
    public static class DataProcessingFunction
    {
        static DataProcessingFunction()
        {
            // Default schedule (every 5 minutes)
            var defaultSchedule = "0 */5 * * * *";
            var schedule = Environment.GetEnvironmentVariable("MyFooSchedule") ?? defaultSchedule;

            // Ensure the environment variable is set
            Environment.SetEnvironmentVariable("MyFooSchedule", schedule);
        }

        [FunctionName("DataProcessingFunction")]
        public static async Task Run([TimerTrigger("%MyFooSchedule%")] TimerInfo myTimer, ILogger log)
        {
            log.LogInformation($"DataProcessingFunction executed at: {DateTime.Now}");
            // Your function logic here
            await Task.CompletedTask;
        }
    }
}

Conclusion

By using a static constructor to provide fallback values, you ensure that your Azure Function can handle missing configuration gracefully. This approach enhances the reliability of your function and simplifies the process of maintaining and debugging configuration issues. Default environment values not only prevent runtime errors but also improve the consistency and robustness of your functions across different environments.

.NET MAUI (Cross Platform framework)

Nalin Jayasinghe — Sat, 14 May 2022 09:40:16 +0000

.NET MAUI stands for .NET Multi-platform App UI.

.NET MAUI is a first class cross-platform framework for creating native mobile and desktop apps with C# and XAML.

Using .NET MAUI We can develop apps that can run on Mobile (Android, iOS) and Desktop (macOS, Windows) from a single shared code-base.

.NET MAUI is open source and is the evolution of Xamarin.Forms.

.NET MAUI and Xamarin.Forms has many similarities. Xamarin.Forms need separate project for each platform. However, .NET MAUI can create multi platform apps using a single project. One of the key aim of .NET MAUI is to implement your app logic and UI layout in single code-base. Also .NET MAUI allow you to add platform-specific code and resources if necessary.

Creating a cross-platform app is not easy task due to deferent OS and device specs. .NET MAUI simplified it by abstracts them into a single shared project that can target Android, iOS, macOS, and Windows.

.NET MAUI single project provides the following features:

A single shared project that can target Android, iOS, macOS, and Windows.
A simplified debug target selection for running your .NET MAUI apps.
Shared resource files within the single project.
A single app manifest that specifies the app title, id, and version.
Access to platform-specific APIs and tools when required.
A single cross-platform app entry point.

Conclusion
I am very excited about .NET MAUI and all the productivity and performance it will bring. I look forward to build apps using .NET MAUI and share my learnings and experiences with you all.

Thanks for reading!
Feedback is always welcome.