Vince, I just this moment finished testing them, and yes. (However, if you're going to put these things out into the world, so to speak, the 64-bit pset should be named pset64.exe so that it is clear as to what kind of target processes it's able to handle.) (You might also want to make the error messages more reflective of what the problem is (targeting the wrong process type; i.e., "You must use PSet64" and "You must use PSet") rather than just stating what Windows API failed. The later is useless information from a user's perspective.) Although, now that I think of it (as usual!), targeting a 32-bit TCC instance from a 64-bit PSet just crashes the 32-bit TCC instance. You might be able to tell if the process failed (I no longer remember), but crashing the target TCC instance is an unacceptable outcome if it can be avoided (maybe it can't). While it would be somewhat too late, at least if you can tell that the process failed you could emit an error message to the effect "The TCC instance crashed because it was 32-bit and you used the 64-bit PSet on it."
However, unless 1. I can tell whether my target is 64-bit or 32-bit, and 2. I have code to set a variable that works for each target type (knowing what it is) that runs in 32-bit mode, this is all academic for me (although I was glad to test your stuff). My program needs to run equally well in both 32-bit and 64-bit TCC sessions. (Although, now that I think about it a bit, failure trying it one way could be tested for and the other way tried if that's the case.)
Although (and please forgive me for my bad memory here if that's the case) is it true that you used exactly the same source for both the 32-bit and 64-bit DynamicSetEnvVars and the only difference was that one was compiled for 32-bit and the other compiled for 64-bit? If that is the case then it does me no good whatsoever because I want one program that is able to target both 32-bit and 64-bit TCC instances. And even if the sources were somewhat different, if the 32-bit version had to be compiled for 32 bits and the 64-bit version had to be compiled for 64 bits the same thing is true for me - I intend for there to be a single executable that has to run in both 32- and 64-bit TCC instances, and if that can't be achieved I'm left with using file(s) to store my persistent data as I am working on doing now. - Dan