What's inside a .EXE File?
HTML-код
- Опубликовано: 19 янв 2023
- What is inside the Windows Executable or the executables for other operating systems? I take a look at the past from the days of DOS until the present and crack open a few EXE files to get a look inside. Explored also is programming without a compiler, linker, or any kind of processing code before execution. Is programming in raw machine code possible?
Altair 8800 Demonstration:
• Altair 8800 - Video #...
Learning x64 Assembly:
• Modern x64 Assembly 1:...
stackoverflow.com/questions/6...
kernel32 lib:
github.com/repnz/snax86/blob/...
kernel32 and kernel64 are the same thing.
Windows 1.0 online:
www.pcjs.org/software/pcx86/s...
Actually, Windows hasn't been DOS at its core since Windows Me. Windows XP and later are based on Windows NT, which doesn't use DOS.
This wasn't bad, but missed or simplified a lot about the actual exe content. Exe files (or PE files) are organised in sections. There are different sections in it and usually only one contains your code. There are other sections which may contain resources, text or much more importantly import / export sections. While an EXE file usually does not have an export section, it usually has an import section. The content is essentially a special "contract" by the OS and your application. When the OS starts your program, the OS takes care of loading your file into memory of its own process that the OS created. The OS will scan through the import table, look up shared libraries and imported function names and dynamically load those DLL into your application and also resolves those requested methods. That way your program actually has access to certain functions that are either part of the OS or some other utility libraries. The export table usually only exists when compiling a DLL file which internally is also a PE file. Of course the export section serves the opposite of the import section. So the OS can look up a method or other symbol that the library exports when loading the DLL for an application.
I did actually handcraft an EXE file. I did that as a part of writing a simple compiler for a stack-based language.
Rarely these days do you hear people refer to C as high level, but I'm always glad when it is.
7:06
i don't think its true that windows is still running on dos nowadays though. thats my only critique. its running on the NT kernel now and has for a long time. I think that message about not running in dos mode was made for the time before home versions of windows used the NT kernel, so pre windows XP.
Okay, I just want to say, that one of the reasons of big size of the .exe file is compiling mode - Debug. You can basicly see there three calls of third system interruption right after the end of "main" function - they are inserted by compiler to prevent running out of function (if you, for example, forgot to write "ret" instruction). Debug mode generates terrible amount of auxilary code, which can help you in debugging. All your actions, even in assembly, are checked by debugging instruments in runtime to help you in search of mistakes. So for pure research you should better disable all of debug utilities (part of them is still used even in "Release" mode) in project settings. But even with that, this video was interesting, thank you for your work.
That "Gesundheit" killed me🤣🤣
I'm sure several people have pointed it out by now, but the extra code you were seeing is from the CRT (C Runtime,) since despite being written in assembly, you were compiling your program as a C program.
EXE File also contains Icons, Bitmaps, Cursors, Dialog Defintions. The function LoadBitmapA for example loads a bitmap inside the current exe file. Many of this resources can be viewed (and sometimes edited) with PE Explorer or similar programs.
For those interested, I find Dave's Garage "The World's Smallest Windows App" video a fantastic explanation of how you can take out everything but the bare minimum from a PE.
the MZ at the beginning of DOS executables stands for "Mark Zbikowski"... who was one of the main developers responsible for developing the file format.
I remember when MS DOS had a debugger. It was fun to start the debugger and tell it to just "go". Debug would dutifully attempt to execute whatever the IP register was pointing to. The machine would jump off a cliff if it could and you told it to
CS student so I have a few notes on this:
This is one time i wish i could double like a video.
Amazing video! I never really thought about exe files that way before - you explain it so well! I always learn something cool from your channel - thank you!
I really like the accompanying visuals you included at the end!
If I remember correctly, in DOS you could also create COM files as well as EXE. I think these were basically executables for small programs like command line utilities.
I just want to say that this was an amazing video. You could have just stopped after the theoretical first section, like most other videos do, but you went the extra mile and showed how it works in practice. Honestly, if the rest of your work is just half as good as this one, you've got potential for blowing up!
you can create much smaller executables if you use masm for instance. it doesn't add all the "unnecessary" stuff if you dont need it, and you can set the data blocks yourself, optimising your executable.