Understandinglow-level APIs

Writing software can be a daunting task. You need to consider many things when you try to convert your ideas into something that works on the machine. After all, there are so many things you need to tell the computer before it doessomething useful.

But we are in luck. Many of the instructions we need to give the CPU are encapsulated in frameworks, tools, packages, and other pieces of software. These building blocks allow us to focus on what we want to build instead of how the CPU might interpret our instructions. That makes life alot easier!

This chapter looks into those building blocks, how they help us, and how we can best use them. This chapter also covers how .NET works and where it comes from. This is important: most developers take the advantages of .NET for granted. That is fine since the framework hides much complexity. However, when writing lower-level system software, it is essential to know why things...

You can visit the following link to view all the code in thischapter:https://github.com/PacktPublishing/Systems-Programming-with-C-Sharp-and-.NET/tree/main/SystemsProgrammingWithCSharpAndNet/Chapter01.

Well, maybewe are going a bit too fast. Before we can look at low-level and high-level APIs, we need to agree on what anAPI means.

API is an abbreviation for application programming interface. Although technically correct, it doesn’t tell us much. We need a better definitionof API.

Whatare interfaces?

Let’s begin with the terminterface. That alone can be defined entirely differently, depending on whomyou ask.

An interface canbe asoftware interface, which is the boundary between two pieces of software. For instance, a database such as SQL Server allows users to access data by accepting SQL queries. That is the main interface for thatdatabase system.

Another definition of an interfacewould be ahardware interface. The USB ports on your computer and the peripherals you connect to your machine using them arehardware interfaces.

Of course, in C#, we also have interfaces...

Previously, weexamined the difference between low-level and high-level programming languages. Like the APIs, lower and higher mean how close to or far away you are from the actual machine. Programming in C means you are very close to the hardware; programming in C# means you are far away. Of course, being further away means you are working in abstractions. The advantage is that many things are simplified, as seen earlier in this chapter. Also, with many abstractions, moving your code to other platforms ismore manageable.

The magic that makes this possible is the .NET runtime. Since the first version, the designers have always aimed to shield you from the low-level stuff as much as possible. This lets you write your code quickly and focus on functionality insteadof boilerplate.

.NET is a complex topic. But in short, it comes down to a set of tools in many different forms that help you achieveyour goal.

Fun fact

Before...

We have established that .NET gives you many tools to develop something quickly. It also helps you out by shielding you from the low-level details ofthe underlying operating system. But it also allows you to use low-level APIs if youneed to.

But how can we access those APIs? The answer isPlatform Invocation, or (P/Invoke). We can use this tool to access the Win32 API directly. P/Invoke bridges the gap between the two platforms so that we can mix and match to ourhearts’ content.

Note

Win32 is the name of the SDK and the APIs made available. There is no such thing as a Win64 API. Our code is compiled against 64-bit Windows if you run that platform, yet we (and Microsoft) still call it theWin32 API.

How doesP/Invoke work?

P/Invoke involves a couple of steps. These are the steps you must follow to use a Win32 API in a .NET application:

1. Find the API you wantto use.
2. Find the DLL the APIresides in.
3. Load that...

In the previous examples, we did a little bit of error checking. If we couldn’t get the handle, we showed a message. We did the same thing if we couldn’t write to the console. I realize it’s funny to write to the console that the system cannot write to it (look atline 33, for instance), but you get what Imean here.

But this isn’t good enough if you want to know what’s going on for real. We need a more thorough way ofhandling errors.

In .NET, we are used to getting exceptions whenever things go wrong. We know how to deal with that. In the low-level world, things are different. When something goes wrong, we get0 back, and we’re left to deal with it. We could continue with the code without being bothered by the error. We could even ignore the results of a call to an API. However, that would lead to disaster. You should always check and deal with the results of an API call. How to deal with that is something we discuss...

Working with low-level APIs such as the Win32 API opens up a treasure trove of new and powerful tools. However, it comes with acouple of downsides. Debugging your code suddenly gets a lot harder, and it also becomesmore critical.

There are a couple of areas you need to be aware of when you want to debug your code usinglow-level APIs:

• Error handling
• Interoperability
• Debugging tools
• Compatibilityand portability
• Documentation andcommunity support

Each of these can pose a challenge, requiring you to think about your debugging strategy before you start coding. Let’s go through thepotential issues.

Error handling

Asmentioned previously, you’re responsible for error handling when using low-level APIs. You don’t get exceptions from the functions you call when something goes wrong. You always have to be careful to check the return code of the calling code to see if it is 0. And...

This chapter looked at the difference between low-level and high-level APIs. We dove into the foundations of .NET by examining the BCL and CLR. Then, we examined how to call into low-level APIs such as the Win32 API. We did that by reimplementing the ubiquitousConsole.WriteLine into code that the Windows operating system can run without using the BCL. That led us to discuss error discovery and error handling, and how to best goabout them.

We also discussed the issues you might encounter when you start doing that sort of coding. We mentioned the differences in type systems and the issues you might have when dealingwith debuggers.

I hope this chapter has made you appreciate the .NET Framework and the hard work the BCL and CLR do for you as a developer. But I also hope you realize the power you get when using the Win32 API or other third-party libraries written in Cor C++.

System programming relies heavily on these techniques. Although using these APIs ties you...