I have a general "feeling" that applications open faster on Windows than on Linux. I know this is too vague/non-scientific but if I were to compare load time of an application e.g. VLC on Windows and Linux how would I go about ? Also, I would like to study the differences in loading mechanism used by windows and Linux for binaries so any reference would very much appreciated.
The Linux loader can give you lots of information about the binding process.
LD_DEBUG=help ls
See the ld.so(8) man page for more details.
To really measure this you'd need to be able to flush the file cache on each OS before measuring.
One thing that Windows does is immediately after bootup it begins loading a list of frequently used DLLs and applications into file cache. This is called SuperFetch and it works pretty well.
Linux distros sometimes have a similar list that is preloaded into file cache by a program called readahead. The problem with the Linux distros is that this list is fixed at install time and isn't automatically updated, so it usually only includes programs such as the default user desktop, web browser, email application, etc.
To flush the file cache on Linux, do the following command as root:
echo 3 > /proc/sys/vm/drop_caches
To flush the file cache on Windows? I don't know, I will need to look.
Related
When reading the WSL documentation, it is stated that:
"Unlike our practice with trying to exclusively install programs and software on Ubuntu, our files and folders need to live exclusively on the Windows FS [...] Windows and Windows Apps can only read and write Windows files, and VSCode will be making our changes."
I understand the reasoning behind this and indeed, if one uses VSCode for example, it all makes sense. But my question is:
Is there any real reason why you couldn't keep your files (i.e. scripts) on the WSL filesystem itself? More specifically, if you don't ever intend to use the Windows filesystem (i.e you won't ever need a GUI or else), is there any sense in placing the files in the Windows FS?
Obviously you need to make sure you backup your data (GitHub or else) but aside from that, is there any downside? I guess what I'm saying is: can I use WSL like a VM? Can I keep BOTH software AND scripts all in WSL, separate from the Windows filesystem?
PS: The reason for avoiding a VM in this context is because I have a low spec laptop which has struggled a lot in the past with VMs (slow, not enough RAM), and so far, WSL seems be running much more smoothly.
Thanks
The simple answer is yes, you can use WSL as if it were a VM. WSL is for the most part fully-fledged Linux, and you can use Linux as your primary operating system, ignoring the fact you need to start it from within Windows. I haven't tried WSL 2, but it's said to be implemented as a fast VM, which is exactly what you ask for. (Further, the lack of GUIs can be mitigated using built in support for sending X data over SSH to the Windows half of your computer, and display it with an X Server. If I remember correctly, these two articles got me most of my way there.)
However, if you want to get pedantic, you can't store any files separate from your Windows filesystem on WSL 1. If you run e.g. Ubuntu, your Linux filesystem is instead always contained within %USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\LocalState, so it'll technically not be separate. I can't test WSL 2, but according to this article, WSL 2 also stores its data in that folder, just as a single VDHX image. Presumably every WSL distro stores its data on the Windows filesystem.
Warning: Do not access the files themselves in your Linux filesystem within AppData using Windows tools, or you run a high risk of corrupting those files.
Yes, you can, and only place files in the Windows filesystem if you want to share them with Windows programs. Moreover, in Windows 1903 you don't need to place files in Windows filesystem to share them with Windows Programs, they can access them.
In WSL2 they encourage you to keep everything in WSL filesystem to take advantage of the filesystem's performance improve.
So, yes you can and you should.
I have a running process started from a directory, let the executable name be foo.exe (windows), my doubt is can the process corrupt its own executable?
If so, will the next run not allow me to start the executable, or will the currently running executable display problematic behavior?
Similar doubts about some of the DLLs it may be using.
I am using windows, but answers both windows and linux appreciated.
Windows locks the executable while it is running, the .EXE cannot be edited nor renamed/deleted.
.DLL files are also read-only so they cannot be edited but they can be renamed so a evil program could perform a .DLL replacement attack.
Linux allows files to be unlinked while they are in use so replacement attacks apply. I don't know if there is a way to edit them in place.
If the executable is on a network share these restrictions might not apply, it would depend on the server implementation and the protocol used.
Generally, the answer is NO—unless there is some bug in the operating system. The operating system will open the executable as read-only. Some operating system then use the executable as the page file for read-only sections of the process. It would be impossible to write back to the executable in the absence of a bug in most operating systems.
I am fully aware of products like Wine and PlayOnLinux for using Windows application on Linux, but why am I unable to run .exe files on Linux? Is it because of something in the architecture of Windows operating systems that Linux doesn't use? Is it possible to create a linux distro or work with an existing one (Ubuntu, Mint, Debian, etc) to run .exe and .deb? If it is possible, what could be looked into and researched to be able to do so?
An executable file is a set of instructions the tells the program loader how to place the program in memory. An executable file can in turn reference shared libraries that are essentially executable files as well so the loading process is recursive.
First of all, the operating systems program loader needs to be able understand executable file format. This, the Linux loader does not do.
Second, any shared libraries referenced by the executable need to be available. Those libraries referenced in a windoze application are not going to be available on a linux system.
Even if you could get the past the first two hurdles, the operating systems would need to respond to system service calls in the same way. When you call an open file system service in Windows a linux system might interpret that as a close file system service call (or anything) (On Intel there are multiple ways of invoking system services).
I'm developing an application with Qt on Qt Creator and have been transferring and moving a project and its corresponding files from Windows to Linux, and vice versa. I've been noticing that on Linux the build is a lot faster compared to when I'm building the application on Windows. Is this normal? And if not, how can I fix it?
Normally a build on my Linux machine will take a few seconds, and on Windows it takes a long time and sometimes to the point that I just stop building.
It is not unnormal. Compilation typically creates lots of comparatively small files, and that's not where Windows file systems shine. In any case, double-check virus scanner settings, you might not want your temporary files scanned repeatedly.
I know about several projects for cross compiling between linux and Windows.
The Wine project is great for running windows application inside Linux.
andLinux is a linux running inside Windows.
My question is, can we compile a complete linux OS with a Windows compiler (like mingw32, visual studio , ...) in order to get a linux system which is fully compatible with the Windows PE executable format ?
As wine demonstrates, the PE format isn't really the problem with compatibility.
PE only defines how the program is pieced together at load time. Under windows, RUNDLL interprets it, loads all the program sections to memory, loads all the supporting dlls to memory and patches up the function pointers so that there is a program sitting in memory ready to go. (See http://msdn.microsoft.com/en-us/library/ms809762.aspx for more details. Its a good read!)
There is little stopping you writing a kernel module to do all of this. With the details in the page linked above it may not be to hard and someone may already have done it.
The real issue is the fundamentals of the operating system. Even if linux could load a PE, there would be problems around the fundamental difference in file names (\ or /) as well as the permissions model which is different and the windows registry which doesn't exist under linux. That's before you get into the different windowing model for GUIs.
Therefore the task of getting a windows program to run under linux is less about the program loader and much more about emulating all of the windows DLLs under Linux. As i understand it, this is the main heart of wine.