This is on Windows XP.
I have a running process (that I'd like to stay running). If I copy over a dll that it uses (as in, replace it with a newer version), will this cause problems for the running process, or is the code already loaded such that it won't matter?
I believe the DLL will be held open while in use and, therefore, you will not be able to write to it.
You shouldn't be able to copy over a dll that is in use by a running process. In order to replace the dll, it would need to be marked for deletion and replaced upon the next reboot. If you wished to do this manually, then you would need to stop the process.
If you can copy over it - then the dll isn't in use as you suspect, if it is being late bound then you could copy over it during a time when the process doesn't actively have it locked - and providing the internals of the dll don't have any adverse effect on the active process, it should be fine.
Of course, not knowing anything about the dll in question, nor the internals or programming standards used in the development of said dll - I wouldn't be able to say one way or the other.
Beware though, copying over any dll has the potential to have adverse effects on applications that rely on it, and that includes your operating system.
The behaviour will always be process specific. Some process take shadow copies, some lock the DLL, others load to memory and forget about the file system until next time it's loaded.
Even if you can write over the DLL, the process will be very unlikely to react to change until it is restarted. Maybe it will restart automatically. (IIS running an ASP.NET app is an example of this). You'll just have to try.
Probably never advisable.
Generally, you should avoid this practice. While it may work, in theory, especially if you control the long-running process and the DLL both, and can guarantee no one else needs it, Windows really doesn't like to do this sort of thing.
I recommend reading Raymond Chen's recent November, 2008 on Technet ("Windows Can but Won't") for more information as to why this is generally not a good practice, and incidentally why reboots are often needed from app installers.