First of all, everything in a computer is in the form of "0 s & 1 s" . The fact that the computer can display some of these as text, pictures, sounds, 3D models, etc. is just a matter of how you interpret them. But down there, at the metal, it s all just "0 s & 1 s" (also known as bits). Note though that they are always grouped together in groups of 8, and these are called "bytes". It s really for the sake of efficiency, because operating with every bit individually would be too tedious. Actually, todays computers don t even operate on single bytes anymore (or rather - they do it very rarely). Mostly you operate with 4 or 8 bytes at a time, depending on whether you have a 32-bit or 64-bit CPU (that s in layman s terms, it s actually a bit more complicated than that).

As for a .DLL file - like an .EXE file, it contains bytes that describe instructions that a CPU can execute. The CPU takes these bytes directly from the .DLL/.EXE and executes them without any further modifications. That s why these files are CPU-specific. In different CPU architectures the same combination of bytes means different things, so a .DLL/.EXE will run correctly only on the CPU for which it was designed. On other CPUs these bytes will mean some other instructions, and when run, the program will most likely do some utter nonsense and crash immediately.

The assembly commands you mentioned also deserve an explanation. "Assembler" is not a language that a CPU can understand. It s a language a human can understand. It was created because writing directly in machine code (the bytes that the CPU actually understands) is very difficult. What you get is utter gibberish on the screen (try opening some .EXE file in Notepad!) but every bit has to be precisely set for it to work.

So assembly language is basically the same thing, except these instructions are written in text that humans can read. For every machine code that a CPU can understand, there is am instruction with a human-friendly name. An assembly compiler simply reads these instructions and replaces them with the bytes that represent the actual instructions for the CPU to execute. It s a 1:1 operation. Every command in assembly language matches a single machine instruction (again, in layman s terms).

So you see, there isn t even a single assembly language. Every CPU architecture has its own assembly language, because they each have different instructions.

Note though that all this applies to native .DLL/.EXE files. .NET files are different - they don t contain machine code, but rather instructions for an abstract, nonexistent CPU. It s like Java bytecodes. When a .NET .DLL/.EXE is run, the .NET runtime translates it from the abstract instructions to the instructions that the specific CPU can understand. They use a lot of tricks to make this very fast, so these files run almost as fast as simple .DLL/.EXE files.

Does this clear things up? :)

Native DLLs (not .NET assemblies) usually contain machine code that can only be run on a certain platform. The machine code is a sequence of bytes that the processor treats as instructions (ADD, MOV, etc.).

In Windows, dll s are stored in the PE format which is basically a collection of sections that holds the information about how to map it into memory. some sections contains the program s code (which is of course processor dependent), others contains the program s data, other the exported and imported functions and so on.

Managed code is compiled to some intermediate language that is JITed by the run-time as it is executed. therefore, your dll won t contain any processor dependent code and you ll be able to execute your program on any platform with the relevant run-time.

it depends on your DLL. generally, a DLL contains executable code as an EXE file. those code DLLs are processor dependent since the code can only be executed on a specific platform. the code is stored using the same "format" as an EXE file (binary machine code).

however, a DLL can sometimes contains only data: they are then called "resource DLL" and are not processor dependent at all. they act as a container for data files used by applications.

note that many DLLs are hybrids: they contain both code and resources. for example, most DLLs which comprises the user part of the Windows operating system are hybrid: you can open them using Visual Studio or a Resource Explorer to see the resources (the data segments) they contain, or open them with Dependency Walker or dumpbin to see the functions (the code segments) they contain.

(of course this answer is really Windows specific, i don t know for .so files which are the linux equivalent of a DLL)

Both a DLL and an EXE contain executable code.

In the case of a DLL it doesn t have the necessary parts to be directly executable. It must be called from an other piece of executable code. One DLL can call another, but all must ultimately be called from and EXE.

So the rules about what s compatible with what processor that apply to EXEs also apply to DLLs.