Move the whole application folder and you shouldn't have that problem. But I don't know why you want to move an installed application to a different place.

If a malware/antivirus scanner finds malware or a virus it will tell you the name of the file. It shouldn't be that hard to find a file with a known name and path, regardless how many other files are there.

On a reasonable configured Linux system a normal user doesn't have the write permissions for system files. Even if a malware is running in the users context, it can't change system files.
That is exactly the point why you only log in to a root account if you want to maintain a system, never for normal use. For that reason it was so easy for malware to infect Windows XP systems, the main user had administrator/root rights by default.

If program uses additional data files and they are all within program folder (and program uses relative paths to access them), then it is possible to make program moveable, but you'll have to move entire program folder.

When loading dlls program checks multiple location, starting with program's folder. If you keep program-specific dlls there, you can move them with the program. It is quite easy to make software that can be moved anywhere (entire folder) within one machine. Certain system-wide components, have a fixed location. As a result, if you want to move app to another machine, you'll have to ensure that all "non-standard" system-wide components are present. Typically that means installing VC++ Redistributable. Another thing is registry settings. Registry settings are system-wide, so all copies of application will access same branch of registry and share settings (IF app stores settings in registry). If application cannot create default registry settings automatically, you won't be able to move it onto other machine, and will have to either copy registry settings (export *.reg file) from another machine, or run installer.

Keep in mind, that commercial software developers do not want to make "moveable" application in order to prevent piracy. From commercial developer's point of making moveable app makes sense only if you use hardware key or online authentication.

An exe can be run from anywhere. Program becomes non-moveable(within same machine) when it starts relying on its installation location or absolute path. Program becomes non-moveable(to another machine) when it starts relying on not-really-standard system-wide components and cannot create default registry settings (program doesn't have to use registry, by the way). There is no mechanism that forbids moving an exe into another location. Installer normally simply ensures that all system-wide components (.NET framework, VC redist) are present and sets registry to initial values.

Read this
You can break program into parts, and have multiple teams working onto different components. You can completely replace internals of the dll with something else without updating the program, and as long as internals behave according to program's expectation, program will keep working. .

Suspicious processes can be noticed using task manager, there are sites listing malware-related files. Plus there will be AV alarm.

On properly configured system user doesn't have write access to anything except his personal folder ("home" dir on linux, "My documents", desktop and c:\users\username|c:\documents and settings\username on windows). On such system all system files are read-only, and software can be installed only by administrator. This is standard linux security setup. Of course, if you're working as admin/root, it will make infecting system easier, however even in this situation AV may help you.

Different people have different opinions, and different approaches have different advantages/disadvantages. I'd suggest to get more practice with programing/computers and see how things work yourself. If you're interested in WinAPI, msdn have plenty of material. Before asking a question, try using google to find answers. An information about DLLs, for example, was very easy to find.

What do you mean by program uses relative paths to access them ?



So you can only do this if all the files and DLL are in the folder and you move the folder?
So not all the DLL have to be in the folder if you move it?


What do you mean?



It cannot be run if you move exe out of the folder in other folder and try to use the program.

What do you mean.




What do you do if new Malware makes it way to system and the anti-virus scanner and malware remover tools don't know it is malware do to it is a new malware and the anti-virus scanner and malware remover tools have not been updated.

Is that not how some malware slip by anti-virus scanner and malware remover tools the malware is so new and the anti-virus scanner and malware remover tools do not know it is malware and get on the computer .



So pro makes the computer run faster ,better for CPU , easy for updates and easer for the programmers.The cons more files on the computer


The cons if the OS does not use DLL harder for updates , not so many updates ,slower computer,harder on hardware and harder for the computer programmers.

Seems to me that you try to argue about things you don't understand even in a basic sense.

As stated above, a program will look for DLLs in different places. If you move an applications folder you do have to move the completefolder, including all DLLs in there.
But a program is free at install time to install its DLLs to a system directory. If that is so it doesn't matter were the application is located on the machine, it will find the DLLs in any way.

I would do nothing. How will you get noticed about malware/viruses if you are not alarmed by your malware/antivirus tool?
Or want you say that you regularly have a look at all your system's files to find viruses that aren't detected by your scanner?
By the way, there are only a few viruses out there for Linux, and if you set up your system in a sane way you hardly will get infected.

I was not sure why you can move application in Mac OS X but not Linux or windows.

I understand.



Why would the program install it DLL there.

Also when moving the complete folder with all the files and DLL in it to the trash you still have to find all the other DLL files on the computer and go in the registry to remove the entry !!!! it be faster to use the uninstall utility.

Even uninstall utility are not 100% at removing programs and leave some traces behind.

I never said that this is a way for uninstalling, it is a way for moving.
Of course you should use the uninstall utility, it is itS purpose. The same is true for Linux, where you should use your package manager for installing/uninstalling, except you know exactly what you are doing (same for Windows).
Because the application developer decided to do so. Take for example the Office suite, there are different program folders for its parts, but there are also DLLs that are used by all of its programs, so you install the DLLs to a system folder where every program can find them.

But this has nothing to do with the install utility itself. All that the install utility does for uninstalling an application is to start an uninstall program delivered by the application developer. If the developers don't do there job right it is not the install utility that is to blame.

It is just that Windows, MacOS X and Linux are different operating systems. They behave different and do their stuff different. Not more, not less. It is rather pointless to ask "Why can I do this on Mac, but not on Windows. Why can't you transport your furniture with a motorcycle, although you can do it with a van? They are both vehicles, but they are different.

How do you know that ? I.e. I am not a Windows guy, but the idea if DLL caching seems to be a pretty generic one, and I have vague recollections that on Linux it wasn't that way originally. I.e. I think that Linux DLL caching was implemented several years ago.

As far as I know, "shared memory" is used by windows, linux, unix, osx and others.
In particular parallel (fork-, threadable applications like numbercrunching apps)
like to use that. While each of the tasks/threads has a data segment of it's own,
they all can share most of the code/libraries.
However ... what was the main question and, more interesting, the purpose of this
discussion thread? Maybe to build up some heat and get some more traffic volume?

And shared memory has nothing to do with shared libraries. The former is used for IPC, the latter are used as common pieces of different applications; also, shared libraries imply run time linking.

Linux uses shared libraries and windows does not .

If each program loads its own DLL if a program locks up the OS and other programs will not.If using shared libraries if a program locks up the other program and even OS could lock up.

That is why windows does not use shared libraries .That why windows have more DLL files and feels more bloated but the less chance of other programs locking up if one program locks up.

Say I have 2 IE open one at google and one at linuxquestions org if the IE at linuxquestions org locks up it will not lock up the other IE google do to the fact each program loads it's own DLL than Linux that likes to shared its DLL.

The down side with not shared DLL and each programs loading it's own DLL like windows is you get OS that feels more bloated.

Incorrect, windows dlls are shared libraries. DLL code segment may be shared across multiple applications.

A program cannot lock up OS, unless there's kernel/driver bug. Nothing locks up because of DLLs.
You should distinguish between code segment, thread and process. A code segment stored within library can be loaded once and used by multiple applications. Although multiple processes will use same segment, even if one locks up, it will not affect system.

Look, I do not know what person have told you bunch of fairy tales about dlls and libraries, but I suggest to find that person and put him/her in a hospital ASAP.

Modern operating systems are multithreaded. It means that multiple programs a being executed in parallel (whether they are really executed in parallel depends on number of CPU cores). As long as OS is properly written, A bug or a crash withing single program cannot bring down entire system.

I suggest to get any programming book and get more programming practice. Some experience with assembly programming wouldn't hurt either - at least you'll understand concepts of code/data segments. Also, read about "protected mode", and multithreaded programming.

Dynamic Loadable Libraries are useful for a number of reasons, which have already been stated above, in random order:
1) lower memory footprint
2) shorter startup time
3) Inventing the wheel only once

It is not bloat, it's actually being lean: you only load function-calls when you need them. If you had to learn french, dutch, english, chinese, taiwanese and bulgarian and keep that in your mind all the time, your head would be pretty stuffed. Now, if you always can use a "dictionary" which you can access really fast; you don't have to spend years learning all these languages, but you just take the book that suffices. What's even better: if they add or replace a few words, so their meaning becomes more clear (not different), it's in the replaced book. No need to learn that, or get your local copies you keep everywhere updated. (this analogy goes so wrong in a few senses, but you get the idea: it's fast, it's reliable and it's logical)

That is why also windows uses shared libaries, but in a different way; I don't have windows, so I cannot reproduce anything. But what makes you think that windows loads each dll anew upon each executable (re)start? It may seem so; The dll may be loaded at, say, address 0x123 (small memory model for today). Application A1 will point to that address space for those functions (and thus has a reference to that memory location). The same application (A2) executed anew, will also point to this address space, and thus have a reference to this memory location. This is important, because the OS will want to free up this memory (or move it to a slower memory space, e.g. swap) if no application has any references to it.

What happens if an application "locks up"? It doesn't actually lock up the system. It may claim so many resources from the system, that the system may appear to be locked up. There are various ways an application may lock up: it gets into an endless loop from which is no escape. Depending on what is in that loop, the cpu may become (very) busy. That way, the kernel and/or other processes may not get the (all) time slices, that are needed to perform other tasks; Other resources may also cause this. When an application hooks (deep) into the kernel, the application may cause a kernel panic (BSOD) causing the system to go down, or send the kernel into an endless loop. Windows has had this in previous versions (prior to windows 7 afaik this has gradually become less and less common, but in early versions the integration of explorer and other applications deep into the OS (kernel) was a cause for many crashed windows :-)

Anyway, I think there's quite some stuff to learn for you. Pay good attention in your computing classes and don't listen to people that are to be put in hospital ;-)

quote I reason for such an bloated system in Windows is Windows will take control of
all avaible resources. When you open two programs in Windows it opens two copies
of the same system files. Each being rename as file name(1), (2), etc. Linux
opens them as share.

As for so many files open when Windows is booted and running. If you have, say
an HP D1660 printer, it will load all three drivers for the D1600 series and so
on for all hardware you have. Linux will only open the one driver for the
printer you have and most hardware you have. quote

============================================================================

The above quote is what I got in e-mail why one of the reason windows is bloated .
So how does this work with DLL files?


I thought a bad DLL file or a program that does not release a DLL can?

I did not know that having DLL cut down on not trying to make a OS bloated.


So in other words if we did not have DLL file windows would be more bloated.

PROTIP: Ignore everything in the email this quote came from.

huu?