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.

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.0ProcessTamerTray.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.

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-1614NB: 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.

By that, I mean really well:

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! _______________________

The latter point also indicates that a new option is probably required: Start-up PT in quiescent (Inactive) mode.

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).

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?

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?______________________________

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:

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.

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._____________________

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.

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.

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.

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?