DonationCoder.com Forum
DonationCoder.com Software => Mouser's Zone => ProcessTamer => Topic started by: mouser on December 17, 2016, 07:27 PM
-
I'm interested in hearing reports on this new beta version (v2.14), which supports x64 machines natively.
Unified win32 and x64 setup betas:
- https://www.donationcoder.com/Software/Mouser/proctamer/downloads/beta/ProcessTamerSetup.exe
Or if you prefer portable version:
- x64 version: https://www.donationcoder.com/Software/Mouser/proctamer/downloads/beta/ProcessTamerPortable64.zip
- and win32 version: https://www.donationcoder.com/Software/Mouser/proctamer/downloads/beta/ProcessTamerPortable32.zip
-
Note: This latest new version will install into \Program Files\ on x64 machines, instead of \Program Files (x86)\ as the older version did, so you should uninstall old version if you are installing new on an x64 machine.
Your settings should still carry over.
-
@mouser: Thanks! Shall try it out.
-
Is this still okay to try out? I'd like to test it out :)
-
Give me a day to upload a new version.
-
New x64 build with additional support for high-dpi displays:
- https://www.donationcoder.com/Software/Mouser/proctamer/downloads/x64/ProcessTamerSetup.exe
- or https://www.donationcoder.com/Software/Mouser/proctamer/downloads/x64/ProcessTamerPortable.zip
Let me know how it works for you.
-
Thanks! Just a couple of questions, how does this version work with 32bit games? I play some on a 64build Windows 10 system, they don't show up on the process list (unless I uncheck 'Hide 1% Normal CPU).
Is that working right? They always showed on the last version, which I assume was the 32bit version. Their usage was much higher than 1% too. I actually found that version to be doing more with them than this one and the games didn't lag as much with v.2.11.01 as they do using the 64build Process Tamer.
Can you explain why there are such differences and which one I should use for lag-free gaming?
-
This version should work identically for 32bit processes.
It sounds like they are not taking up as much of your cpu on the new machine -- so there's nothing really for Process Tamer to do.. Which is a good thing :)
If there are OTHER processes on the pc that are using up lots of cpu, it's THOSE processes that you might want to lower the priority for.
You could also try enabling the function "Boost Foreground Process to High Priority" to boost the speed of any game that you are playing.. Though that's a bit of an extreme action to take.
-
Ah yes, that makes sense. Yes, this machine is much more better than my last build - I'm still playing some of my old 32bit games on it, I don't want to give them up :)
Okay, so I'll try and lower the priority of some of the listed process (that Firefox is a monster!)
Thank you!
-
Not sure why, but this latest version of ProcessTamer doesn't seem to work fully.
ProcessTamerConfigurator.exe is v2.13.1.0
ProcessTamerTray.exe is v2.0.10.1
ProcessHacker shows the PT process as running OK, and its icon sits in the Systray, but it can't seem to come up with the About or Configure panels.
I shall investigate to see if I have some settings or something somehow left over from the previous version and which might possibly be messing it up.
I shall also check whether I have all the latest Windows OS updates.
PC is an HP Pavilion-15 laptop with an Intel i7 CPU, running Win10-64 PRO.
UPDATE: 2017-03-26 1449hrs
I made these changes, which seemed to fix it:
- Set PORTABLE=TRUE in ConfigDir.ini file (may not be relevant for all users).
- Set CONFIGDIR = . in ConfigDir.ini file (may not be relevant for all users).
- Restored old DonationCoder_processtamer_InstallInfo.dat file to application folder (C:\UTIL\Windows utilities\FindAndRunRobot\Plugins\ProcessTamer).
- Restored old DonationCoder_processtamer_Key.dat file to application folder (C:\UTIL\Windows utilities\FindAndRunRobot\Plugins\ProcessTamer).
I can confirm that PT seems to have no problem with either killing processes or adjusting the CPU priority of processes, with the several 32-bit and 64-bit apps that I have tried so far.
The only shortcoming seems to be that the PT Configure pane suffers - in common with most other @mouser apps - from the excessively minuscule and apparently 1-pixel thick character font, making it difficult to read without magnification or specs of some sort (for those with imperfect vision).
-
Whilst I have not given PT an exhaustive test, I have given it a pretty good look-over, and this is me reporting back with my experiences and a sort of "Mini-Review" regarding ProcessTamer v2.13.01 (per "About"), comprising:
- ProcessTamerConfigurator.exe (is v2.13.1.0)
- ProcessTamerTray.exe (is v2.0.10.1)
_______________________
OS is Windows 10-64 Pro: Build 14393.rs1 release inmarket.170303-1614
NB: This is a relatively cursory summary, so my apologies in advance for any mistakes I may have made or important points overlooked (let me know and I can correct them).
I had previously more or less given up on earlier versions of PT that I had trialled because, though they worked to some extent, they simply didn't always work too well. That is, PT didn't always do what it was supposed to do. This made them "unreliable" for my purposes, so I would generally prefer not to use them until they were improved.
However, this latest 64-bit incarnation of PT seems to work beautifully. :Thmbsup:
By that, I mean really well: :Thmbsup: :Thmbsup: :Thmbsup: :Thmbsup: :Thmbsup:
- It works well for the purposes intended.
- It works just as well for 32-bit or 64-bit processes (so far, without fail).
- It happily deals with and kills persistently-recurring superfluous system overhead annoyances that may be forced on the users and that are not necessarily needed all the time, and which keep reinstating themselves - e.g., such as GoogleCrashHandler.exe, DropboxUpdate.exe, SkypeHost.exe
- It seems to do exactly what it should do (was designed to do) and as documented in the Help file.
- It is easy to use with the relatively intuitive GUI provided - which also seems rather well-designed for the purposes intended.
Especially nifty/useful features:
- CPU Measuerment Smoothing sliding scale.
- PT Toggle: Double-clicking the PT icon in the Systray is a toggle to enable/disable PT. This also seems to be the quickest way to immediately control the application and (say) stop it from killing stuff that you might not want it to do just yet, but for which you have not yet had time to change the Configure pane. The user has to be quick though, as PT may be even quicker! :D
_______________________
The latter point also indicates that a new option is probably required: Start-up PT in quiescent (Inactive) mode.
Would be useful to include:
- Start-up PT in quiescent (Inactive) mode - start-up option needed, as above.
- Restart specified processes at timed/periodic intervals - e.g., useful with misbehaving/unstable/runaway processes including, for example RuntimeBroker.exe, SynTPEnh.exe, SynTPHelper.exe.
- Configuration saves: (For some reason, I thought this functionality was included, but I couldn't find it.) The ability to save different PT configurations as named Configuration Files, so that the user can select a particular configuration that is specifically better-suited to whatever the user is wanting to do with the computer in that particular session - e.g., (say) clear out superfluous system overheads prior to gaming.
_______________________
Needs improvement:
The only criticism I could make is as per my comment above:
The only shortcoming seems to be that the PT Configure pane suffers - in common with most other @mouser apps - from the excessively minuscule and apparently 1-pixel thick character font, making it difficult to read without magnification or specs of some sort (for those with imperfect vision).
-IainB
To put this into perspective: In the scheme of things, not having a more legible Configure pane is not a showstopper. The requirement for an ergonomically visually better GUI is, in terms of priority:
- probably Priority "C" (Nice-to-have) for most ordinary-sighted folk, and
- only becomes Priority "B" (Highly-desirable) for folk who need to wear reading glasses, and
- would probably only become Priority "A" (Mandatory) for people with much worse eyesight problems.
_______________________
Bit of a digression:
The reasoning behind why I persist in my crusade pushing for visual and ergonomic improvement in computer GUI design:
Spoiler
- Having learned from the development in military/scientific applications, I have tended to focus on visual and ergonomic improvement as a mandatory requirement and design objective in the GUI of computer programs that I have been responsible for developing (either as a developer or as a project manager). Suitable visual and ergonomic design of these programs was usually specified in the requirements for the contracts for development, and was the subject of end-user acceptance-testing prior to production release and final payment of contract.
- The fact that my eyesight needs the help of reading glasses is compounded by my having a couple of physical eye problems, one of which is a form of Fuchs endothelial dystrophy (which may be genetic/inherited or may stem from damage after being exposed to high-UV sunlight and having severe snow-blindness in my teens). The effect is that the quality of my eyesight varies throughout the day and in differing kinds of ambient light.
- All this has made me acutely aware of the reasoning for the above objective - i.e., functional efficiency of use of computer programs can be seriously inhibited/impeded by poor visual and ergonomic design of the GUI. The designer needs to aim to meet the eyesight and physical requirements of all potential users of the GUI, in most typical working conditions/environments - e.g., the operator may be sat in a brightly-lit office, or in the dimly-lit inside of a military tank. Again, from experience, many/most developers would seem to be blissfully unaware of whatever the visual or other ergonomic requirements of the users might be, with the result that they may unwittingly inflict on the users a sometimes punishingly difficult/unpleasant ergonomic interface and leaving users with little or no option to ameliorate the severity of that interface to better match their peculiar requirements. A classic example of this could arguably be the widely-used MS Office 2016 product (which is otherwise an excellent product).
_______________________
-
Thanks for the nice review, Iain. I will try to add the features you are mentioning.
Now regarding this:
The only shortcoming seems to be that the PT Configure pane suffers - in common with most other @mouser apps - from the excessively minuscule and apparently 1-pixel thick character font, making it difficult to read without magnification or specs of some sort (for those with imperfect vision).
The new version should incorporate my fixes for high-DPI displays which should make for nice big clear fonts on a machine where you have text size set to larger than 100%, which presumably is what you are running?
-
@mouser:
The new version should incorporate my fixes for high-DPI displays which should make for nice big clear fonts on a machine where you have text size set to larger than 100%, which presumably is what you are running?
______________________________
-mouser
In response: No, that is not the case for me. I am usually using a 15" laptop display at DPI 100%.
I don't wish to appear rude, but the very fact that you asked the question like that might indicate that you don't perceive what I am on about - as though in a state of cognitive blindness - despite all my going on about visual perception and the ergonomics of the GUI.
To see things from my perspective on this issue, one probably needs to have made some effort to study and understand the theory and extensive research related to psychological visual perceptual issues and ergonomics in analogue and digital displays, but especially (in this case) regarding GUIs on computer/digital displays of different types. This would assist in the comprehension of what the perceptual and ergonomic issues probably are.
This ideally would include at least a cursory study of optics and the different effects of differing eye problems on human eyesight and perception. Until one does that, one's paradigm might well be stuck in the "Yeah, adjusting the DPI will fix it" frame of mind, because that will be one's currently preferred perception of reality for such matters (and why not?).
Of course, it's always possible that I "just don't get it" about the DPI, I suppose, but at least I have repeatedly tried to vary the DPI settings and that was shown to be pretty useless (see below).
Because I have had to study those things above, I tend to see that many of the perception and ergonomic issues relate to things including such as, for example:
- Depth of field of lenses in the eye or spectacles.
- Focal length of lenses.
- The effect of viewing natural (reflected) light versus viewing a light source, at different frequencies, on the eyes and the human nervous system.
- The effect of different types of ambient light on the perception of information on a display screen.
- Perceptual disorganisation caused by the use of certain contrasting colours in combination and at varying brightness levels, the effect of which can be amplified by optics - certain eyesight (lens) aberrations.
- The effect of the colour (temperature) of light on the human nervous system (e.g., hence the use of f.lux).
- The use of lines to emphasis boundaries between one coloured area/object and other neighboring objects (e.g., a background).
- The use of deep (non-pastel) colours to emphasise boundaries.
- The objective to enable max/optimum speed of perception and comprehension of text in the mind of the reader/viewer (for speed/efficiency).
- The deliberate use of text fonts that research has shown can enable max/optimum speed of perception and comprehension of text in the mind of the reader/viewer.
______________________
I know that you have been focused on and put a lot of work into getting your apps to respond nicely to changed DPI settings, but from my perspective, ergonomically, changing the DPI setting is likely to be worse than useless.
I don't use/change the DPI setting - it stays at 100% (which is "recommended").
One can see why it's recommended if one does change the DPI setting. For example, as a test, I just now changed it to 125% (125% was the only alternative setting that the system allowed me to do). It was a constipated process. I had to do it using the CursorRight key because dragging the slider didn't work as the setting just kept snapping back to 100%.
Having made that change and after I had logged off/on again, the visual effect of the changed DPI setting (125%) was grotesquely apparent and about as subtle and ergonomically useful as hitting the display with a brick - so one can see why it's recommended that it be left at 100%. >:(
Furthermore, changing the DPI expunges all/any customised system Settings for text settings (see example below), and resets them to default. So, after going back to DPI 100%, one has to tediously, manually set them to one's preferences again.
Interesting point:
- Experience of experimentation with these settings leads one to the discovery that they would seem to be far more useful than one might at first have thought.
- They seem to be far superior to and more flexible and make much better (more efficient) use of the display "real estate" area than messing with the DPI, which latter should evidently be left well enough alone for laptop displays (QED) - unless one absolutely has to change them as a last resort for some reason.
For interest, here is a copy of my notes on the system settings pane that I refer to above:
[ You are not allowed to view attachments ]
It seems to me that, at the moment, the "best" solution to fix the problem of excessively miniscule fonts in these configuration panes would seem to be to change the mode of the pane so that the user can either (say):
- (a) adjust the fonts and colours of the pane (which could do the job quite nicely, just like in the CHS GUI), or
- (b) (as a provisional workaround) zoom the pane in/out, with the zoom level being remembered for when that pane is next opened by that user.
-
It's interesting to hear your thoughts on this stuff. You are fighting an uphill battle in trying to keep your text dpi setting to just 100% and yet hoping to be able to customize the font settings in each individual application.
I have provided such functionality in some of my programs (FARR and CHS), but the overhead to maintain such things makes it impractical for most of my apps, and it creates yet another set of user interface oddities that I have to try to plan for.
I am working hard now to properly support the official > 100% text font settings for high dpi configurations -- that seems to me the best way forward in the long term.
At some point the desire to completely customize the font settings, while admirable, seems like it may become not worth the effort, and biting the bullet to get used to the windows > 100% text size may be the way to go, despite it's imperfections..
As an aside -- one thing to be aware of when testing the windows high dpi (>100%) text settings is to make sure you reboot or logout afterwards, otherwise things are very glitchy until you do.
-
@mouser:
It's interesting to hear your thoughts on this stuff. You are fighting an uphill battle in trying to keep your text dpi setting to just 100% and yet hoping to be able to customize the font settings in each individual application.
_____________________
-mouser
Ah, sorry, I am not "...hoping to be able to customize the font settings in each individual application". I think it's a PITA. I would love it if the DPI settings change helped, but it doesn't (QED). So far, the only alternative that actually usefully works seems to be the path that I have followed - the PITA path. You don't seem to see that, from what you write above and later: "...biting the bullet to get used to the windows > 100% text size may be the way to go, despite it's imperfections.".(?)
Nor do I have a "...desire to completely customize the font settings". as you suggest. Quite the opposite. It's a tedious PITA.
What I do have is a mandatory requirement to be able to easily and rapidly read the screen displays from the apps I use. So I am just using the available, sometimes kludgy, workarounds to be able to maintain that.
From my understanding, those aren't "imperfections" anyway, they would seem to be serious design flaws that Microsoft has been and is presumably still trying to rectify. One of the biggest design flaws was the Windows 8 OS/GUI fiasco, and they fixed that to a greater extent with Windows 10 (which isn't bad at all, all things considered). This screen display problem would seem to be something of an embedded hangover from that fiasco. Apple computer displays suffer no such problems (never have really), so it's not like it's a technical constraint for the technology available.
Therefore, the correct term would seem to be "design flaw".
At the moment MS seems to have fenced that problem to some extent and not declared a solution path. I feel sure they'll get there eventually.
Meanwhile, when they recommend (as they do) that the DPI setting be left at 100% for my laptop display, I'll heed their advice. I suspect that they probably know better than I what they are talking about there.
Where you say:
As an aside -- one thing to be aware of when testing the windows high dpi (>100%) text settings is to make sure you reboot or logout afterwards, otherwise things are very glitchy until you do.
-mouser
- Yes, thanks. I did mention that "I had logged off/on again" after making the changes.
-
Uploaded latest beta version (v2.14) with x64 support:
New unified win32 and x64 setup beta:
- https://www.donationcoder.com/Software/Mouser/proctamer/downloads/beta/ProcessTamerSetup.exe
Or if you prefer portable version:
- x64 version: https://www.donationcoder.com/Software/Mouser/proctamer/downloads/beta/ProcessTamerPortable64.zip
- and win32 version: https://www.donationcoder.com/Software/Mouser/proctamer/downloads/beta/ProcessTamerPortable32.zip
-
Note: This latest new version will install into \Program Files\ on x64 machines, instead of \Program Files (x86)\ as the older version did, so you should uninstall old version if you are installing new on an x64 machine.
Your settings should still carry over.
-
My previous feedback was regarding x64 ProcessTamer v2.13.01 (per "About"), comprising:
- ProcessTamerConfigurator.exe (is v2.13.1.0)
- ProcessTamerTray.exe (is v2.0.10.1)
This latest version is x64 ProcessTamer v2.14.01 (per "About"), comprising:
ProcessTamerConfigurator.exe (is v2.14.1.0)
ProcessTamerTray.exe (is v2.0.14.1)
All seems to work fine - really well - as per my earlier notes/review for v2.13.01, but I shall report anything new that occurs.
I did have a few very odd problems earlier - after doing the test DPI change up to 125% and then back to 100% (because at 125% it was useless for my purposes).
Notes on these problems:
- Though I had not made any changes to the sound system, the sound disappeared and Windows Audio service seemed to be stuck in "Stop pending". Could not be fixed and persisted across COLD re-boots of the system.
- CHS (ClipboardHelp&Spell) persistently and frequently hung without error message and had to be terminated via ProcessHacker. Every time CHS was shut down like that, it would not restart (or would hang soon after restart) if PT (ProcessTamer) was running, so PT had to be closed first, then CHS restarted, then PT started. Rinse and repeat. I guess this was because I had set PT to force the CHS process HIGH, so PT had some residual hooks, or something, into that process. This fun also persisted across COLD re-boots of the system.
- I fixed it all quite by chance after some trial-and-error. What eventually worked was uninstalling the sound card (which thought it was functioning properly), and doing a COLD re-boot. After re-boot, the sound card came up as present OK but was disabled and could not be enabled. It only worked normally after I did a second COLD re-boot. After that CHS also seemed to work fine and simultaneously with PT, as it should have and had done previously.
All that took a couple of hours (elapsed time) of mucking about, making me regret that I had ever tried changing the DPI settings in the first place. So be warned. :down:
-
Thanks for the report, Iain. :up:
-
This feedback is for ProcessTamer v2.14.01 x64 (per "About"), comprising:
- ProcessTamerConfigurator.exe (is v2.14.1.0)
- ProcessTamerTray.exe (is v2.0.14.1)
Since my previous feedback of 2017-03-30, PT has been running pretty much continuously on my laptop. In that time, as far as I am aware, PT has been running perfectly and doing exactly what is expected of it (I have it set so that it pops up an alert each time it does something), though I have not tested the full functionality of the software.
It is a real pleasure to have PT back from the grave, up and running so nicely on my laptop. It's like the return of the prodigal son. In future, I might need to shut PT down under certain circumstances that I am yet to experience, but until then it will probably usually be constantly "ON" after boot-up, though I have not tested it yet as "Start with Windows", preferring so far to start it manually after boot-up, so as to avoid potential conflict at boot-up time.
By the way, I have a workaround for the "Configuration saves" requirement I mentioned above: I save different versions of ProcessTamer.ini and manually load/rename the one I want, prior to starting-up PT. I will probably automate this using AHK when I settle on the best approach for me. Either way, it's a kludge, but it does/will work.
Related question: Is it possible to run PT with a parameter that tells it the filename of the .ini file to use, or is the filename ProcessTamer.ini fixed as the default? :tellme:
-
Related question: Is it possible to run PT with a parameter that tells it the filename of the .ini file to use, or is the filename ProcessTamer.ini fixed as the default?
I could certainly add that function.
-
@mouser:
Well, if you wanted to minimise changes/work and keep PT small and fast - AS-IS - then adding the parameter functionality could possibly obviate 2 of the 3 things I requested above:
- Start-up PT in quiescent (Inactive) mode.
- Configuration saves (and loads).
___________________
- as they could then perhaps be done via an AHK interface.
However the third:
- Restart specified processes at timed/periodic intervals.
- would not be quite so simple, though again, it could probably be achieved with AHK in some way.
-
^^ My comment above:
Having just re-read the discussion on NANY 2015 Release - Splat (Simple Program Launching and Termination) (https://www.donationcoder.com/forum/index.php?topic=39934.msg372550#msg372550), I belatedly realised that, by intelligent use of SPLAT we might be able to arrive at the same ends and achieve Nirvana and avoid functional duplication in/with ProcessTamer - to a greater extent, at least.
So, PT could remain "lean and mean".
What do you think? :tellme:
-
I was prompted to post this comment here after reading the discussion at ProcessTamer-Setting process priority not working with Windows 10? (https://www.donationcoder.com/forum/index.php?topic=45837.msg421414#msg421414).
I am still running the latest ProcessTamer v2.14.01 x64 ß (as a Portable app.), with no problems.
One interesting point is that I have observed one annoyingly persistent Win10 system process that seems to be either:
- (a) escaping being shut down by PT for some reason, or
- (b) (and more probably) it is being shut down properly, but a "ghost" of its Notification icon temporarily remains in the Systray. The process is LocationNotificationWindows.exe (set to Force Kill).
The app is not found as a running process in Process Hacker, and never seems to appear in the Systray proper, only appearing in the clickable > sign in the Systray. When I left-click on the > sign, the app icon (a circle with a solid dot on the middle) is shown momentarily and then disappears.
PT seems to be correctly repeatedly killing the app when it is started (it apparently cannot be turned off even though location awareness reporting is disabled in Settings), but Windows is continually trying to restart it. I would suppose that its Systray icon is maybe not being expunged from the (hidden) Systray display buffer, even after the app has been killed.
-
It doesn't work for me. I am using the latest beta on Windows 7 x64.
-
Hello all,
This is an old thread but I would like to provide my feedback for the Win10 version.
There is a problem with getting CPU usage. It is not registering. See photo.
[ You are not allowed to view attachments ]
@Mouser: When will the next version come out? It has been a few years without improvement.
BTW, I will be sending some Bitcoin your way. Hold it for another 5-10 years and then it will be worth a lot more. A retirement fund :)
By any chance, can we obtain or open source Process Tamer if no further development will be conducted? It would be nice to have a community effort to expand the software to our needs and fix the several issues within it.
-
Are you running PT as Administrator?
-
Looks like this project is dead.
Windows 10 Version 1909, Build 18363.1500: Process Tamer is completely broken now... Can't change the priority with Process tamer automatically, not responding to the changes, no response from Mouser, wish there was some activity here to use this program. Time to look for alternative to Process tamer.
-
Hi Papatech.
Because Process Tamer is one of the few apps I've made that exists in a non-gui form that wouldn't require much effort for others to build, I think open sourcing the code makes a lot of sense if I'm going to to update it much.
Let me chew on it a little more. I'd like to get it all working on windows 10.
-
@Papatech +1
@mouser +1
Thanks for all the hard work and I hope for a working version very soon. Good luck
-
Hi Papatech.
Because Process Tamer is one of the few apps I've made that exists in a non-gui form that wouldn't require much effort for others to build, I think open sourcing the code makes a lot of sense if I'm going to to update it much.
Let me chew on it a little more. I'd like to get it all working on windows 10.
-mouser
Any update on this?