I’m running Comodo 3.0.10.238 in Win XP x64 with SP2. I found that a bug I reported some time ago is not fixed yet: ICMP code and type are not logged.
They have been logged before (i.e., in v3.0.8.214) in an unusual format (multiplied by 256) in the columns for TCP/UDP source and destination port. In the current version, these fields are empty for ICMP packets.
I consider this a bug because there is no way to verify if the ICMP rules work as configured. As you can see on the attached image, there’s no way to understand why a specific packet came through while another one was blocked.
Since I cannot check which rules apply, I cannot confirm egemen’s statement that the bug I reported before is a matter of log visualization only.
They could fix it but many apps don’t work properly with 120 DPI. You can try to reduce your DPI settings to match your display REAL DPI.
You need to divide your screen pixel resolution with you display inches values (width or height) anyway if you have a real ruler at hand you only need to place it on your display and set you custom DPI settings
Yes, and one of the applications is Comodo Firewall Professional. Please no excuses, like they could fix it. I for one am not willing to make changes to my system just to accommodate an application because it can’t handle DPI settings. Actually, in my case (115 DPI) the updated GUI is usable and a tick better then it was with 2.4.
Blame to Ms as nobody uses DPI as it should be. From a technical standpoind DPI is used to attain a device independent representation of an image.
Anyway it is common to use 120 DPI instead of enlarging system fonts.
What I consider a bugreport though is that V3 may not operate correctly using the REAL DPI not a 120 one.
This mean that it is needed to test V3 after adjusting the DPI value by hand.
New technology often means higher screen resolutions which tend to make screen items to small to view comfortably. At least for those people that do not have the best eyesight, DPI is the clean way of compensating for this. It should not matter if I use 96 DPI or 120 DPI. They are both offered as Normal and Large by the system in the display settings. I’ve never heard of REAL DPI - what is that?
MY XP system adjusts very well when changing the DPI setting. The changes are system wide for all
menus, windows, text, etc. It’s the applications that stumble on this. An application programmer needs to have a clue on how to do the scaling, otherwise you end up with truncated fonts, menus, etc. I can list dozens of applications that can handle DPI changes without screwing up the displays. If it does ■■■■■ them up, I consider it a bug.
That is my opinion on DPI, but this is getting OT so I will stop here.
You can try to reduce your DPI settings to match your display REAL DPI.
You need to divide your screen pixel resolution with you display inches values (width or height) anyway if you have a real ruler at hand you only need to place it on your display and set you custom DPI settings
As I have no indepth knowledge about the programming aspects of DPI aware softwares may best guess is that there is a limitation in Windows API that accounts for these types of issue.
If windows was really DPI agnostic there would be no issue at all as DPI only means actually how to obtain a 1:1 size correspondence on a visual device.
This means that if a device DPI is correctly set the inch sizes of an image will be always the same regardeless of the device.
This does not means that there is not a BUG but it means that the bugtesting should be handled in a different way.
