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

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

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

What are interfaces?

Let’s begin with the term interface. That alone can be defined entirely differently, depending on whom you ask.

An interface can be a software 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 that database system.

Another definition of an interface would be a hardware interface. The USB ports on your computer and the peripherals you connect to your machine using them are hardware interfaces.

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

Previously, we examined 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 is more 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 instead of boilerplate.

.NET is a complex topic. But in short, it comes down to a set of tools in many different forms that help you achieve your 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 of the underlying operating system. But it also allows you to use low-level APIs if you need to.

But how can we access those APIs? The answer is Platform 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 our hearts’ 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 the Win32 API.

How does P/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 want to use.
2. Find the DLL the API resides 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 at line 33, for instance), but you get what I mean here.

But this isn’t good enough if you want to know what’s going on for real. We need a more thorough way of handling 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 get 0 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 a couple of downsides. Debugging your code suddenly gets a lot harder, and it also becomes more critical.

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

• Error handling
• Interoperability
• Debugging tools
• Compatibility and portability
• Documentation and community support

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

Error handling

As mentioned 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 ubiquitous Console.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 go about 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 dealing with 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 C or C++.

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