You do not generally store data directly inside a raw partition (at least, not with high-level concepts like files and directories). Normally you create what's called a filesystem (like FAT32 or NTFS or whatever) inside the partition (each partition would have its own separate filesystem), and that's what provides the OS the ability to organize data into files and directories.

Partitions just organize a disk into units that resemble separate smaller disks, but that's it—they don't say anything about what's actually stored there. The filesystem is a layout of data within a partition that OSes use to keep track of the high-level concepts like files and directories and such and decide where and how to store the actual data.



Ordinarily you can't install a raw Linux file hierarchy on FAT32 and have it work correctly because Linux relies on a lot of special filesystem features that FAT was never designed for. You'd need a filesystem designed for *nix systems like ext2/ext3/ext4/reiserfs/etc. for that. But you can store regular (i.e., non-system) data files on a FAT-style disk and access those from within Linux.

However, there are tricks to get around this problem that many distros use to let you install Linux on a USB drive and boot from it while still leaving the whole thing formatted in some variant of FAT and share files with non-Linux systems. There are several distros designed specifically to be installed on flash drives and possibly others with special installers that can do it.

The USB install of Linux Mint that I've been using is stored in a FAT32 format, although when running Linux from that drive, it can't be accessed as a FAT32 drive.

David, as tev said (to rephrase part of his point ever so slightly), FAT is for "files and such" in Linux only because it doesn't support important Linux features such as Linux-style permission bits and uid/gid on files, not because it was designed to be only for files or something. Before NTFS was introduced, Windows itself ran perfectly happily on FAT file systems.

And that is why trying to secure a Windows machine was an exercise in futility (arguably that's still true, but for other reasons). FAT file systems (FAT16/FAT32) have no concept of permissions, so any user can easily overwrite system files.

Some Linux systems can run on FAT32 because they have a modified FAT file system driver that stores file permission information inside special hidden files. It's a kludge, though, so you wouldn't normally use FAT32 in Linux except for storing "files and such".

Another method I've seen once or twice is one or more big files on the FAT or whatever filesystem that contain real Linux filesystem images and mounting them via loop device, though this has the drawback of permanently reserving a set amount of disk space that is unusable on non-Linux systems.

It also has the drawback that the Linux FS is limited to 4GB, since that is the maximum file size in FAT32 (older Linux kernels had a 2GB file size limit on FAT32, but any Linux version from the last few years should have a 4GB limit).

That's true if you stick with one (uncompressed) filesystem, but I don't think there's anything stopping you from creating extra “partitions” as separate FAT files and mounting them at various mountpoints to collectively bypass the overall 2GB/4GB limit.

Certainly, but that would get more awkward as you go, not to mention the pain of fragmentation within those blocks, and the potential need to either glob multiple FAT32 extents "files" for a large subtree of your storage or split one into two or more pieces.

Agreed, that in itself is a drawback as well.

Then I have a question:

If I want to code a computer program using x86 in the form of hex, I'd use the compiler NASM or whatever and write it in Hex, right?

So what are .exe's? x86? I really don't get that.

If you really wanted to write in x86 hex, then you'd probably be better off using a Hex editor than NASM, MASM, FASM, TASM, or any of the billion other Assemblers out there. However, you could conceivably use any of them and just do a bunch of hex insertions.

As for .exe's, they can be multiple languages. x86 executables are one format, x64 are another type, CIL executables are commonly available, etc...

Hex (short for hexadecimal) is a way to represent numbers, much like decimal is a way to represent numbers. Decimal is base 10, and hexadecimal is base 16.

x86 is a machine code. You could write a program in hexadecimal (since machine code is all numbers anyway), but as others pointed out already, you don't want to do that. It's very difficult to understand what all of those numbers mean unless you are extremely experienced.

Now, what you can do with NASM is write programs in assembly language. NASM is an assembler. Assembly language is one step above machine code. It is a set of mnemonics that translate almost directly to machine code instructions. Each assembly instruction is generally a simple statement such as

Code:

where "add" is the operator, and eax/ebx are the operands. The operands are what the operator works on. In this case, the value in the ebx register is added to the value in the eax register, and the result is stored in the eax register. This instruction is basically the same as "eax = eax + ebx" in a higher-level language.

There are many sites that explain x86 assembly language better than I can. If you want to learn x86 assembly language, I would search for one of them, or ask someone here or in another forum who is more familiar with x86. I personally am more familiar with Z80 and 68000 assembly language and not so much with x86, so I couldn't help you very much with it.

Using a hex editor, hein? A hex editor for me is like Hex Baker or XVI32 to open files and edit their binary code in the hex form of it. Could you please specify the hex editor thing please?

@christop: Thanks for the info, especially on operators and operands which I didn't know.

Scout, that's exactly what I mean by a Hex Editor (although they usually provide many other functions besides). I personally recommend HxD because it provides a lot of very useful features. You can just create a program and write your hex in as you wish.

Is that hex x86 or pure machine code (no language)?

It's also too bad HxD is Windows only, but I'll try and find something as good.

It's pure hex. There's no real difference betwee "x86 machine code" and random hex except in that "x86 machine code" is presumably executable by an x86 machine.

Also, if you're running Linux instead of Windows, I like Bless and I know Jonimus has mentioned another excellent one that I can't remember the name of.

Yeah, I use hex editors for pretty much everything
The only thing that gets more use is Windows itself...

http://home.gna.org/bless/index.html

Ok I'll give it a try. How dangerous is it to code? Cos I'm afraid of screwing up PC

Um, I wouldn't recommend trying to write executable hex on a computer. It's liable to turn out badly unless you know what you're doing.

Why would you want to write in hex when you can write x86 ASM using an assembler? Assemblers do all the hard work for you, allowing you to make the most out of your time programming.

To give you a better idea of what x86 machine code looks like, here is a short program in assembly language (this program uses Linux-specific system calls, so it won't work on Windows), and then its listing file after assembling it:

Code:


Here is the listing. The first column of numbers contains the address, the second column of numbers contains the machine code, and the text on the right is the original assembly code that translates into that machine code:

Code:

As you can see, the machine code is a bunch of numbers that don't mean much to you or me, but the processor understands what they mean.

Also note that if you just put in all of the machine code numbers into a hex editor, you won't get a complete executable program. For one thing, an executable file contains headers that tell the OS how big the code and data sections are and other information about the program. You would use a linker to create those headers after you assemble the assembly source code. It is possible to create the headers by hand (with a hex editor), but only experts should even consider doing that. The program above is only 47 bytes long, but the executable file (compiling with nasm and linked with ld) is 572 bytes, so there are 525 bytes of headers and/or padding bytes.

For another thing, you would have to relocate symbols to their proper starting address. I believe the values in brackets "[22000000]" would be different in an executable file since the program wouldn't necessarily start at address 0.