What is the difference between the SDK, API and DLL?

There is a common misunderstanding between the 3 terms, often they are used by people to mean the same thing, but they’re not.

An SDK is a toolkit provided by a software developer, to be used within 3rd-party applications, to interact with the target application (in this case the target application is MSFS itself).

An API is an endpoint (or, more accurately, an interface) within the target application, for 3rd-party applications to connect to, for communication, usually bidirectionally (accepts requests and provides responses).

A DLL is a library that can be used by one or more applications, it usually provides a collection of methods and properties for applications to reuse, without having to rewrite the same, or similar code, each time we need to perform a task.

An SDK can be provided in DLL format (as it is with the SimConnect SDK), an API cannot, it’s built-in to the target application.

It is rare for a target application developer to provide both an API and an SDK, however, MSFS does have both.

The problem is, only the SDK was intended for us to use in our own applications, there is very little documentation relating to the API or the communication protocol used.

The SDK and API were originally developed when MSFS was first released (as FSX), you can imagine they have evolved a lot over the years. However, they are generally backward compatible, meaning you don’t have to rewrite your code every time there’s a new version released.

So there you have it, they are similar but are distinctly different and used for different pruposes.


For a more detailed explanation, with links and industry definitions, see the comment provided by @Steeler2340 on another thread.

1 Like

Great Explanation … Thank You.

maybe you can add to this what a “Sandbox” is, especially as it applies to MSFS, and its implications.

1 Like

And beta testing, patching, etc.

Yes – I would be most fascinated to see an definition of what MSFS “Beta Testing” is !!

The normal definition may be:

But as far as the game industry is concerned, and in particular MSFS, it would appear to be somewhat different.

1 Like

I look on the problems with the positive spin that if we had to wait until the sim was flawless before we got to play if then it wouldn’t have been released during Covid and it’s really really helped me get through this period.

1 Like

A Sandbox in computing terms is a safe place insulated from the production software or environment which allows testing to take place without risking external software or hardware setups/ I am sure there is an ‘official’ definition but that’s my understanding

Thanks @ScruffyDuckJon - appreciated the input (don’t see much of you these days )

I was looking to add to some clarifications about technical terms used wrt MSFS - as opposed to a typical Google search for the term “sandbox”

I was really looking for a description in the context of MSFS, and how the Sandbox in MSFS affects how it works, and the advantages & limitations of MSFS using one.

Well, I don’t know whether there is a specific meaning of “sandbox” in the context of FS2020 - where did you pick up that term? Here in the SDK forum? - but I can give you a general definition (in the context of software / development):

A “sandbox” is a “space” within which a given process - or an entire application - is confined. So don’t just think of a “separate computer not connected to other production systems”: it is really an “address space” which the “process” may access - but nothing beyond!

That’s as abstract as it can be, I know, so let’s quickly make a concrete example: web browsers (Firefox, Chrome, IE, …) typically implement a “sandbox” (a dedicated address space) within which they execute the JavaScript downloaded from various web sites.

Have a look at some of the JavaScript downloaded from various locations when you visit e.g. flightsimulator.com:

Do you trust all those sources? Some yes, some no (the screenshot is from a “script blocker” called uMatrix, in case you wondered: a Firefox extension)… but your browser trusts none of those sources really!

But still the browser needs to execute that code (JavaScript). After all, that’s what you - as a user - expect it to. But what if a malicious piece of code would try to access your files stored on your computer? Certainly you wouldn’t want that either! Except of course you wanted to upload a file to a web page - but even then you don’t want to give permission to the actual JavaScript!

Enter “sandboxes”: so the JavaScript is executed within a “safe environment” where it is given certain permissions. For instance it may do computations, taking away precious CPU power - but perhaps only to some extend (you don’t want a web site to mine for crypto currencies while you’re visiting it). It may access your browser history. It may access certain key strokes (shortcuts).

But a JavaScript certainly mustn’t access your local files. It must not even be able to access your RAM at will! It must not be able to download resources from any location of the web except from where the Script originated itself (“cross border scripting”). Etc. etc.

And the browser takes care of all this by putting the “process” (which executes the JavaScript) in a dedicated memory area, the “sandbox”, given (or rather) taking away “privileges” to that process, so I can only access and execute a well-defined set of API (“functions”) which are considered “harmless”. But still enough such that the JavaScript can do “meaningful stuff”.

Now you can imagine how difficult it is to define “meaningful stuff”. Even “harmless stuff” like giving JavaScript access to “high precision timers” on your computer might seem to be a “trivial” and “good thing” to do. After all, you want that e.g. a website could measure your download/upload speed with the highest precision. Right?

Well, it turns out that when you give JavaScript access to high precision timers (which measure the time in the range of nano-seconds) that “evil” JavaScript can mis-use this for various “timing attacks”. And yes, that was (and is) a real issue, e.g. here https://bugzilla.mozilla.org/show_bug.cgi?id=1217238

And even when you have defined the “useful stuff JavaScript (or generically again: a process) is allowed to do” the even harder thing is to make sure that your sandbox is really sealed!

The concept of “sandbox” doesn’t just exist in the context of web browsers. The programming language Java also has a sanbox, and since JavaScript (possibly compiled to “web assembly”) is also used to extend FS 2020 functionality I guess FS 2020 also has a sandbox for its extensions (in the context of so-called WASM modules).

I hope that helps :slight_smile:

The “sandbox” concept is widely used on mobile operating systems, too. Each app runs in its own sandbox, it can’t access anything it isn’t supposed to. At least on iOS.

And on macOS, apps distributed through the App Store run sandboxed. Such an app can’t open files outside their sandbox, except files that the user specifically chooses to open in the app. I am sure something similar exists in Windows. (But surely not enforced to the same extent, many Windows users still are very much in the old “just download this executable from the internet and run it” mindset. Not intended as criticism, that is what they want, and who am I to try to tell them otherwise.)

1 Like