This question already has answers here:
What is the difference between assembly code and bytecode?
(7 answers)
Closed 2 years ago.
I understand this may sounds like an googleable answer.
However, I have looked around on internet and still cant get an satisfied answer
I know both are Intermediate language and it is the code between source code and machine code.
bytecode is generated by compiler and it is more often used in Java context before getting into machine code.
assembly code is also the code before machine code.
My question is that before getting into machine code, both are the last step to go into machine code. So what is the difference between them?
Assembly is a programming language. It's a human readable form of machine code.
Byte code is machine code for a virtual machine. It needs to be translated from that virtual machine to the actual machine it's running on. Byte code could also be represented in an assembly syntax for that virtual machine.
I think difference is only in the terminology. Assembly code we use for .NET and byte code for java.
Related
This question already has answers here:
System Calls in Windows & Native API?
(5 answers)
How to write hello world in assembly under Windows?
(9 answers)
Make a program using only system-calls not windows dll's [duplicate]
(1 answer)
Closed 11 months ago.
I still coudnt find any hint and hope somebody can usher me to the right pad:
If I want to programm in the pure plattform-indipendent x-86 assembler code without any NASM macros or functions with (), but with push, call and pull. How I can I find the right functions? The translator into opcode does find them. However do their places change in the different versions? Since there are no different versions of the Compiler into opcode, I suppose they do not. I hardly can find any adresses on the internet
What I actually search is something like the dos interrupts for windows 10 or 11
I also struggled finding sources on what to do. Platform independent coding basically means you are writing your own operating system. This is because it requires you to write a boot loader that takes your program, and moves it into the memory. It also requires you to make your own drivers and libraries: VGA driver, stdout (print functions), stdin, etc.
If you like, you can check out my repo here. I already hacked together my own boot-loader, linker script, etc. that handles the boringly complicated things! I also have a library (located in BODY/data.s) that features a ton of functions that I wrote myself. You can use these to help guide you in writing your own drivers if you'd like!
In order to use this development platform however, you need to install:
GNU binutils
GRUB (already included on most linux)
XORRISO
QEMU
This is all meant to run in linux. If you are using macos or windows, I recommend using either WSL or virtual box to install linux on your system! The code might also be slightly different that what you are used to, as it's called GAS assembly, which alters from the intel syntax.
Please reply if you have any issues with this, or need a better tutorial on how to set this up.
Finally, I recommend checking out osdev.org. There's great info on ports (how you communicate with the kb, mouse, etc.) and how the VGA ram works.
Hi I know C++ and I searched and found that windows 10 written in C/C++ & Assembly but I have no idea how windows 10 works, Is it because I don't know the assembly? Do I understand when I learn Assembly?
If you learn assembly, it will help you to better understand the concept of operating system and communicate directly with hardware, but it is not your definitive solution. However, companies like Microsoft usually have their products closed source and you can not easily understand that Exactly which section is written in what language, and finally, if you are thinking of writing an operating system, it is difficult for you as a single person, I suggest you form a team
This question already has an answer here:
Make a program using only system-calls not windows dll's [duplicate]
(1 answer)
Closed 4 years ago.
For educational purposes, I am trying to create a (32-bit) exe on Windows from assembly code that does not rely on the standard C library or Windows DLLs.
I can create a program that starts to run (and that I am able to debug with gdb) however I am not sure how to cleanly exit the program. All tutorials either link to the standard C library and define a main function or use the ExitProcess WinAPI call which is defined in a DLL.
On 32-Bit Linux, I'd use the int 0x80 instruction with the exit syscall. Apparently, Windows does not meaningfully implement these interrupts.
So, is there a way to cleanly return from my program?
Windows has some system calls like all (traditional) operating systems. Read Operating Systems: Three Easy Pieces to learn more about OS.
But Microsoft Windows is proprietary software. The system call interface is undocumented by Microsoft, could be specific to a particular version, and you need time-consuming efforts to reverse engineer it. See also this.
People have already done the reverse engineering and published the results at https://j00ru.vexillium.org/syscalls/nt/32/.
So making system calls directly is possible, but very unpractical except as a learning experiment on your own desktop (not for executables you distribute).
The other part of what you want, avoiding having any DLLs loaded/mapped into your process's virtual address space, may actually be impossible.
This question already has answers here:
Is there a Visual Basic 6 decompiler? [closed]
(6 answers)
Closed 8 years ago.
I have an VB6.0 Application designed by a programmer. Unfortunately we are not able to reach this guy and we badly need to do some modifications in the application at the earliest.
The software was designed and complied on Windows XP device. We only have is EXE File.
I would appreciate if anybody could help me in extracting the source code using its EXE file.
Thanks in Advance
No. All MS programs have two compilers. The first is language specific, the second is shared between all languages (C2.exe). So your program is very similar to a C++ program once made.
Compilers strip all names (programs use memory addresses, names are lost once translated).
Also compilers optimise. They throw away unused code, they optimise away functions, they optimise away stack frames. You turn optimisations on after debugging.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I´m looking forward to learn an assembly language.
I searched web for the tutorial and found different tutorials with different syntax of assembly.
There is any difference between 8086 assembler, nasm and gcc?
What is the better way to learn code with in assembly language?
thanks.
Basically there are two flavours on the x86 chipset which is AT&T or the Intel snytax. Most people I know prefer the Intel syntax because it is much easier to understand, but of course this is also a matter of getting used to. When I learned assembly on 6510 or M68000 I found the AT&T syntax closer related, it is rather confusing with it's adressing modes IMO.
If you instruct gcc to write the assembly sourcefile it uses AT&T syntax by default, but you can switch that to Intel as well using
gcc -S -masm=intel test.c
nasm is an assembler and gcc is a compiler so they have quite different purposes.
As for learning assembly there are lots of tutorials, for example The Art of Assembly. But if you really want to learn it, IMO the best way is to start debug and enter some instructions and see what they are doing and how they change reigsters and flags, writing small loops first.
This way you can focus on the instructions and not fight with the assembler source syntax as well.
I wouldnt start with x86, not a good first instruction set even if you have the hardware. ARM, msp430, avr, and some others are better and have open source simulators where you can get better visibility. I would start small, simply adding or anding a few numbers, write a memory location, read it back, that kind if thing. The simulators (can) prevent you from needing to make system calls to "see" your results, likewise they can definitely help you work through hangs and crashes, which you will get and which IMO leads to giving up on the whole thing. Once you know more, you can switch to hardware or try another instruction set (each new one gets exponentially easier than the prior) leading to x86 if you by then still feel there is a need...With x86 I recommend going back to the early days, find an 8088/86 simulator, learn the original instruction set, then if you still feel the need, then skip to 80386 and newer. You will also need to be able to switch formats in your head, gnu using AT&T was a cardinal sin (gnu assembler folks commit these sins regularly BTW, it is almost expected), but unfortunately we now have these two competing formats. With practice you should easily be able to tell what format is being used on inspection of code, but mentally switching back and forth may still be a challenge.