There's at least 3 things that you could call "loaders" in Linux. The "ld" part of a compile, that puts together various object (.o) and archive (.a) files into a single executable is one. "ld" also checks shared object (.so) files to see if the dynamic linker can work correctly.
The dynamic linker (do man ld.so
for details) gets run by the Linux kernel as part of starting up an ELF format executable. It reads linking information from the ELF file, and then (at least) maps in shared object files (.so suffix). The details are rather involved, and at least sometimes involve updating the GOT, a section in memory that maps a compiled-in branch destination to the actual, as-loaded address of the library code. See: http://netwinder.osuosl.org/users/p/patb/public_html/elf_relocs.html for a lot of details.
There's also a piece of the Linux kernel that reads in executable files, that's sometimes called a "loader". When you configure a linux kernel, you can choose to include or exclude some of these executable file formats (a.out, mainly) loaders. I had the code of linux 2.6.20.9 lying about, and I found "loaders" for different executable formats in linux-2.6.20.9/fs/: binfmt_aout.c, binfmt_elf.c, binfmt_script.c, and a few others.
I know next to nothing of how Windows does this same process, but it must do most or all of the same things.
Don't know about python, but I've moved Java applications from Windows to Linux and vice-versa. Java makes the "write once, run anywhere" claim which may not be 100% true, but with very little work I was able to make it true enough (basically everything works great on Linux, a few issues on Windows).
I'll use W and L for Windows and Linux:
W: files and folders are case insensitive. L: case sensitive. Test file name capitalization carefully on Linux because Windows hides these issues.
Windows has a more granular file permissions system, that lets you use intersections of various groups and permissions. Linux has a simpler system of one group and one user per file or folder. Plus an execute-bit. Well, there are some other little things like setting the execute bit on a folder makes the permissions cascade the way they do in Windows vs. being set to the user and group that created each file the way they do by default in Linux. These issues mostly come into play when zipping and unzipping files, for instance during an install.
W: drives are mounted in the root folder as letters. L: Drives are mounted anywhere as anything. A single file can appear multiple places in your file system (symlinks).
Folder separator: W: \ L: /
Path separator: W: ; L: :
End of line in a text file: W: \r\n L: \n
Default character set: W: ISO-8859-1 L: UTF-8
You need to know which Linux distribution you are targeting. Two areas of difference are how System V init scripts are handled and how super-user tasks are performed (sudo vs su). Also you mentioned an install script. Apt and Yum are popular, but you need to work with the tool that your distribution uses. Use yum on RedHat, apt on Debian, etc.
This is why you need a Linux machine for testing, whether virtual or physical. It must use the same exact distribution you are targeting. Have someone set up a dual-boot on an old server or something. I also strongly recommend cygwin for every developer. The file permissions aren't quite the same as Linux, and you can set it to case sensitive (though it's more useful case insensitive on Windows) but it makes a pretty reasonable test bed.
It doesn't hurt you to know both (Windows and Linux) and once you do, you can make an informed choice about what works best for you. I was a Windows-only developer for the first 10 years of my career. I've been almost purely Linux for the last 4-6 years, so some of my Windows information might be old. I still run Windows in a virtual machine to do testing on Internet Explorer.
One thing you will get used to quickly on Linux is that you can solve most problems by Googling the error message. 90% of command line tools tell you how they work if you type "man ." If you really need it, most source code is easily available, depending on the distribution. When I solve a problem in Linux, I feel like I learned something about how computers really work. In Windows, I feel like I just keep blindly trying stuff until something works. When I find the solution, I'm lucky to remember everything I tried, no less know what it all means.
So I'd encourage you to spend some of your own time learning Linux and this job might be a way to get paid for some portion of that learning. But don't mistake temptation for opportunity. If the time frame is truly short, or money is tight, you may have to say that you have to deploy to what you know (Windows) or not take the job.
Best Answer
As far as Windows and C# is involved you can always use the Environment.Newline
to determine the default new line character of the system the program is ran on.
also, you can use text.Replace("\n","\r\n") to switch to windows return.
There are still compatibility issues when managing files and especially office related ones, some arcane COM apis are also newline sensitive.