[h.sie]

@Yoriyin: These values (10%) are intended only as a first approach. Then long-time tests have do be done in order to see if this approach works in principle and in order to eventuallly fine-adjust some parameters like probabilities.

@Stiebler: It's not related to file system security. In Memory Map of Ollidbg2 you see some flags which determine how the modules of sh3.exe and dll's are loaded. EnvSim.act e.g. is divided into several sections (PE-header, code, data, ressources, imports). Only the data section has write permission. I could use it for my counter, but who guarrantees that my single counter byte is not overwritten by other data? That is, because assembler patching does not go the (correct&secure) way by allocating memory, as one does in C++, because it would be too complicated - at least for me. so my counter is not protected from being ovrwritten in that data section. A simple common used way for patching is to add / expand a special data section with write access as I did at the end of sh3.exe. That data cannot be overwritten, simply because sh3.exe does not know about that additional data area, where my fixes and data are located. I tried to do the same with EnvSim.act, without success, because I didn't manage to change the PE header and the access flags accordingly.
Only way out: Use expanded data section from patched sh3.exe, but then you HAVE TO USE patched sh3.exe.
Other way out: Writing code without the need to store data as I try by randomly set windspeed=low instead of using a counter.

h.sie