As small as GPUT2 is, there should not be a service as it take up the wrong resources from proper functionality. It's a nice thought to do it that way but as long as GPUT2 does so many jobs that tend to affect other resources and programs, the only thing GPUT2 could do, is start from scratch and build it one function at a time, provided it does not use Windows registry to store any settings, none. One feature I never liked is the temp window, you can't hide the graphs and just have numbers listed. Also, include more separation between 32 and 64 bit, I think some problems are from calling the wrong DLL's, calling a 32 bit DLL when a 64 bit is required and vice versa.
IMO
dont use the registry until GPUT2 works perfectly on all systems.
build the system interactive components first and the UI second, separate the processes.
re read my previous suggestions (and give reasons why something wont work so i can test for such reasons.
What really should happen here is gput2 needs to have its source code released so we can treat this software as open and some of us can actually help develop it. I for one would like an xml/lua interface, for obvious reasons that will minimize interface crashing.
EDIT IN: Change how the program saves settings is important, using *.ini or *.inf should be used to keep whoever uses the weak programming skills out of windows registry.
SpeedFan controls fans and temps, once you learn how to configure it properly. :cool:
