Why is there a difference and what is it between assembly language in Linux and Windows?

Question

Why is there a difference and what is it between assembly language in Linux and Windows?

Answer 1

The raw assembly is the same, but memory allocation, IO, hardware access and interrupts are all different. To use those, you have to call OS routines. What those routines are called, how you link to them and the parameters they take are all different for each OS.



Also, those OSs block certain instructions (such as hardware IO) from user mode programs. Again you have to call the OS specific routines.



Making OS independent software in assembly language is very difficult.

Answer 2

The first guy is right to a degree. Assembly is what I think windows calls their assembly level language. But assembly language is machine specific. But as the other person that answered before me, there might be different codes for the calls to the operating system. For instance I think in windows, an interrupt code is 21, it might be something like 30 in linux but do the same thing.

Answer 3

i'll grant an define from an older textbook. "INTERPRETERS "An interpereter is a language translator like a compiler. It differs from a compiler in that it executes the source application right this moment extremely than producing merchandise code it somewhat is accomplished after translation is done. In thought, any programming language could properly be interpreted or compiled, yet an interpreter may be favored to a compiler gazing the language in use and the area decrease than which translation happens. for occasion, common is a language it somewhat is regularly interpreted than compiled. in addition, clever languages including LISP tend to be interpreted. Interpreters are regularly utilized in academic and application progression circumstances, the place classes are in all probability to be translated and retranslated many cases. on the different hand, a comiler is favored if velocity of execution is a huge-unfold attention, by using fact that compiled code is perpetually speedier than interpretered source code, in specific cases by utilising a element of c4ca4238a0b92382dcc509a6f75849b0 or greater. Interpreters, despite if, share many of their operations with compilers, and there is additionally translators that are hybrids, mendacity someplace between interpreters and compilers." [a million] don't be perplexed with some modern-day languagues. Java is at the start compiled to a language called byte code. This byte code is then translated. .internet is comparable in that it somewhat is compiled to a language it somewhat is then translated. common (standard, no longer mananged or comparable) C++ is compiled basically, the comparable as C.

Answer 4

They are mostly the same actually except for handling interrupts and so on which are done differently. You can get around this by coding your own operating system.



You can always talk directly to the machine via machine language.

Answer 5

Assembly language is not different, Assembly language is Assembly Language. Now the way Linux and Windows interacts with Assembly may be different, but Assembly will stay the same.

Answer 6

For a particular architecture (i.e. CPU type) the assembly language is the same. Realize that even modern intel CPUs have different instruction sets but in general most compilers stick to common instruction sets shared amoung all intel CPUs unless advanced instruction sets (aka extensions) are specifically enabled. MMX was one such extension.



Assembly really doesn't have much to do with device IO or drivers since assembly is *below* the operating system. In assembly, you write to or read from (poke/peek) memory locations which may be mapped to devices or be actual memory. If you are actually programming in assembly (not in a compiled language) then you'd just have to know what locations mean what. This "abstraction" is what the OS and compilers provide to higher level languages.



What you are confused about is binary executable format which *is* os dependent. Every executable binary contains information in it that helps the OS know how to run it and what it's called and so forth. Binaries contain the assembly instructions that needs to run but modern binaries are also often not self standing. The "assembly" code in a binary has to be "loaded" and run along with any other "shared" binary code fragments (i.e. shared libraries). This is where the portability breaks down. On the hardware abstraction side, there is also some runtime adjustments that the OS has to do in order to map the right locations into the assembly code. This is because hardware today are not in fixed predictable locations. The bios can move a device from one memory address to another at boot time or even at run time. This is basically what PnP is. It provides a way for the OS to modify how the bios positions hardware in memory to avoid conflicts. That is why if you are running an OS that is *not* PnP aware, you need to disable the feature in the bios so that the bios will initialize and fix those parameters for the hardware at boot time. Once the OS is done with relocation and device mapping, the "code" that is sent to the CPU is assembly and for all intents and purposes this code would be basically the same no matter what OS is used.



So what are some binary formats that are shared... well, ELF is one. Elf is used on various Unix and Unix-like OSs such as Linux and Solaris. Unfortunately binary compatibility is not a useful reality because it requires all the shared components to be compatible versions and format. In a sense, the WINE project in Linux is an attempt to emulate the Windows HAL (Hardware Abstraction Layer) in order to "load" a binary and do all of the necessary relocations for IO and shared components that windows does and then send it to the CPU. In a way, WINE is an attempt to create binary compatibility with windows "EXE" files.