Windows vs Linux

Operating systems each have a specific way of dealing with things. There are several aspects of these.

Unix-based OS's (like Linux) have a file system that runs like this: the root of the drive (either the entire partiton or drive) is denoted as '/' and every subsystem, or folder, is appended to that. There are a number of folders within the root drive. Some common ones are: /usr/bin (for binaries[programmes], and the latter is for user-specific binaries instead of system main binaries), /home (which is practically the Unix equivalent to C:\Users or C:\Documents and Settings), /dev (which houses information about the devices attached the the computer; RAM, hard drives, removable medium, etc.), /lib and /usr/lib (a library for data used by commands and applications), and many more. This is the basic workflow of how programmes interact with each other and the system in Linux. An application installed to /usr/bin will use data files present in /usr/lib/ coupled with preferences in /home/user/.programmename to be used the way a person wants it to be. It writes logs in a specific folder, and it saves temporary data in /tmp. Everything is perfectly organised. The root of the drive is a device, such as /dev/sda0 (sda1 meaning logical disk (sd or hd)  'a' (which means the first hard drive that the computer recognises), partition '0' (first partition on the hard drive) that has been mounted for use. This form of sorting devices makes everything run cleanly and efficiently.

On the other hand, DOS-based OS's (Windows) runs differently. Its devices are labeled as C:\, D:\, etc. (which, as I may point out, does not denote what hard drive they represent nor the logical order in which they are in). Its system files are all jumbled into a miasma of folders in C:\Windows by default, and user settings for each programme are in one of about 12 different places (C:\Users\%USERNAME%\AppData,  the installation folder, the root drive, C:\Windows, among others) creating general confusion and slowdowns in programmes. DLLs which are used to tell programmes what to do are stored in one of a number of C:\Windows\System folders (wsxs, system, system32, systemwow64, etc.). EXE executables (which can be installed in any number of places, to make things even more muddled) look up DLLs, INIs, and settings files in order to operate.

The discrepancies between the two types of data stuctures makes running an EXE on a linux installation virtually impossible, and vice versa. However, one must only create proper files and 'shortcuts' (called Symbolic Links) coupled with configuration files (that tell EXEs what to do) in order to direct EXE files around within a Unix file architecture and run them as if they were native Linux applications.

For instance, let's say foo.exe, when it is run, looks up its configuration file in C:\Users\bar\AppData\foo\settings.ini. Well, in Linux there is no C:\, etc. So instead, WINE steps in and tells it that /home/bar/.wine/drive_c/Users/bar/AppData/settings.ini is the actual place to look (effectively replacing the root drive of C:\ with /home/bar/.wine/drive_c). (This specific folder basically emulates a drive that you would see on a windows machine, and places it in a more obscure location so as to not create confusion by mixing Windows-specific files with Unix operating files. But in theory the folder (instead of ~/.wine/drive_c/) could technically simply be /)(From now on, for practical purposed, I will type ~/ to replace /home/bar/, which is synonymous in Linux). Next the programme parses a command that looks for its DLLs in C:\Windows\system32. Likewise, WINE must redirect it to ~/.wine/drive_c/Windows/system32 so that the application can function properly by retrieving the correct DLL files. After several iterations that take place like these, the programme is set up so that it can't even tell that it is not running on a native windwos machine, but a Linux one. If everything goes well, it will run.

WINE is not 100% accurate, because some programmes do not 'like' how their folder is not in a specific location, and WINE does not handle this exception properly, or perhaps the application calls a command that is used in the Windows window management system, and not Linux's X window management system, meaning that an error makes the application shut down, etc. These can often be fixed manually, to some or full extent. But for a majority of frequently-used applications, flawless usage is observed, and any problems in applications are logged and worked on.

Note: foo and bar are used to substitute filenames and usernames (respectively) for simplicity purposes, and are not meant to be a real file or folder that you may see.

------------------

This is by brief overview of OS's and WINE for you. Any questions, ask.