I must say I learn more from reading these threads than I got from any computer course in college. Of course back then there were no personal computers. The one thing I do know is that without DX Labs hamming would not be as enjoyable as it is for me and without Windows I couldn't run DX Labs. So on this Covid 19 Easter Sunday I give thanks to both and the ongoing challenges they provide. Thanks for all? you do Dave.
73 Jeff / KI0KB

On 2020-04-12 2:34 PM, Gilbert Baron W0MN wrote:

I have to agree but I doubt there is an anti malware application in existence that would not be susceptible to this problem and since defender has only given me this one problem over the years I will stick with it. Free and for the most part as effective as any antivirus can be. I think not running as an admin and effective backups are the real protection even though they are a real pain at times.
Outlook Laptop Gil W0MN
Hierro candente, batir de repente
44.08226N 92.51265W EN34rb
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Dave AA6YQ
Sent: Sunday, April 12, 2020 13:02
To: [email protected]
Subject: Re: [DXLab] Fear, Uncertainty and Doubt Regarding Anti-Virus / Anti-Malware Solutions like Defender etc...
Regarding the lengthy post from Max NG7M appended below,
1. Windows is vulnerable to malware because it fails to implement well-known operating system security measures; correcting this architectural defect would break many existing Windows applications, some of which can no longer be updated because their source code or unique development tools no longer exist. Microsoft has chosen to live with this defect and mitigate it with anti-malware applications, which are provided by many software companies and Microsoft itself.
2. During Microsoft's two unsuccessful attempts to recruit me (once to lead the Visual Studio organization, once to lead the Windows Mobile organization), I interviewed with several senior Windows developers and executives. They acknowledged that "protected folders" and "User Account Control" (UAC) provide little actual security value; these mechanisms were introduced to visibly demonstrate that Microsoft was taking security concerns seriously. "Oh, so you want a secure operating system, do you?" one of them joked.
3. There is no evidence that installing DXLab applications in
c:\Program Files
or digitally signing them would protect them from mis-identification by Microsoft anti-malware applications.
4. Since there is no malware in any DXLab application, Microsoft anti-malware applications that identify them as malware are by definition defective. If you chose to use a defective anti-malware application, enable it to autonomously upgrade itself, and enable it to autonomously quarantine applications it considers malware, then you should not be surprised when one of you applications suddenly stops working.
5. Microsoft's "solution" to their defective anti-malware is to accept submissions of executables incorrectly identified as malware for reconsideration. Over the past several days, multiple attempts to submit the 4.5 megabyte executable for Commander 14.5.5 stalled; the Microsoft submission site was evidently over-subscribed. Last night, the submission site took less than a minute to accept Commander's executable; today, the submission status shows "not malware". How long it will take for this updated determination to reach deployed instances of Windows Defender is anybody's guess. Will this stop the next public version of Commander from being mis-identifed as malware? Unknown.
My inclination at this point is to add Microsoft anti-malware to the list of applications that can interfere with DXLab applications in
<>
Control your computing environment, or it will control you.
73,
Dave, AA6YQ
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Max NG7M
Sent: Sunday, April 12, 2020 11:53 AM
To: [email protected]
Subject: [DXLab] Fear, Uncertainty and Doubt Regarding Anti-Virus / Anti-Malware Solutions like Defender etc...
As we can see, the FUD (Fear, Uncertainty and Doubt) regarding Anti Virus / Anti Malware solutions (MS Defender in this case) have reached a new rhetorical level in regards to DXLab applications / exe's. (based on the number of posts)
First off, I'm not suggesting Dave AA6YQ change anything at this point because the effort would be rather high and the migration of currently installed application exe's to the proper location for a modern day operating system bring a level of complexity along with the change... installer changes and proper use of User Access Control (UAC) would be required along with changes to the installer code used by DXLab (digital signing of exe code etc...). So I'm happy with the way things are and I know that I need to exclude the directory where DXLab applications are installed in my Anti Virus software. So let me make that clear, I'm not complaining or suggesting that Dave do anything to address why this topic keeps coming up over and over and over and over and over again. Well, other than repeating the current solution and referring users to how you need to exclude the DXLab installation path from your anti-virus / anti-malware solution. The bitching and complaining about controls that are put in place to protect you and other users in what is in effect a shared network (the Internet) is rather comical at this point.
If you want to know why DXLab executables are getting identified as having problems, the problem is not Windows Defender or any other anti-virus / malware solution. Identifying Defender as the problem, just exposes your ignorance around this topic. In a nut shell, the problem is where the exe's (any any other executable code like dll's) for DXLab are getting installed along with the fact that the exe's are not digitally signed. If you don't agree, ask a software engineer who has been coding and helping release commercial Windows exe based (rich client) applications for over 30 years. And it helps if the engineer you are asking has had extensive experience related to using industry standard practices which are designed to help users keep their computers safe. Your lack of understanding about bad actors out there that are trying to exploit executable code and at what OS level this code can execute, is not helpful to the discussion. Stop acting like you are a 'safe computing expert' when you are not one... especially when you are disparaging solutions that have been put in place to protect you and others despite your own stupidity.
So for DXLab users at this stage of the game... which I am one of them and very happy with the amazing job Dave has and continues to do an amazing job with this free software offering! I'm perfectly happy excluding the default directory location where DXLab exe's are installed from my anti-virus software solution as an exclusion. I'm trusting Dave to not deliver exe based code that is malicious. And even if it pains me so, I'm letting the DXLab installation process install this executable code (that is not digitally signed) in a read/write location.
If you are happy with what you have and have excluded your DXLab installation path from your anti-virus / malware solution's scans, then you can stop reading now... or you probably never made it this far anyway. If you want more of the details as to what the industry standard has been for decades now, keep reading. DXLab has been around so long, it may be hard for Dave to justify a big change (and personal expense to digitally sign things) at this point. I total get that as I have stated above. However, when other users spew out fear, uncertainty and doubt regarding this topic, they should be corrected and their ignorance should be exposed.
Solutions like Windows Defender (a darn good free solution) are designed to protect you despite your, ignorance and laziness. You can give someone a Twenty Dollar Bill for free and then based on their ignorance, they will complain that you didn't give them two Ten Dollar Bills.
For decades now, the industry and creators of commercial operating systems in use in business and at home have tried and tried to make commercial and home computing safer. Linux / Unix based OS's and even MS Windows (make your silly evil sounds and wiggle your fingers in the air), have been trying to get software developers to locate executable code in a OS level protected directory structure. i.e. for Linux it would be /bin, or /usr/bin etc... for Windows it would be C:\Program Files (x86) for 32bit executables, and or C:\Program Files for 64bit executables. Constrains are put in place to protect the executable code in these directories using an OS level of User Access Control to keep code from executing at a 'root' level or administrator level (in the case of windows) where bad / malicious code could do all kinds of bad things... install key loggers to steal you passwords, or execute code to encrypt all your data and hold you hostage to ransomware schemes. Or just help use your computing power and network bandwidth to jump start other evil bad things without you even knowing day after day and week after week.
For the above reasons and many others not even listed, modern OS's and their designers do all they can to try and get software installed into protected areas of the file system and to only be run at levels where other bad code can't do bad things without you knowing. Is it perfect? nope but it's better than nothing and it's better than just burying your head in the sand and turning off all the protection.
So what is a Mother to do? The best practices which have been in place for decades now (and are not enforced with a draconian solution yet) are to install executable code in protected directories like, you guessed it: C:\Program Files etc... AND to locate application down a path specific to data like c:\Documents\YourUserName where read write access to data is based on user privilege's. AND in the case of executable data you digitally sign your executable code with a signature that can be verified by a known good certificate authority. (do a google search on PKI infrastructure if you want to learn more) this is what virus scanning software is looking at when it scan for issues. If the exe code of application A is properly signed and in the proper directories, then it's less likely to report a false positive. (yes a pretty simple description of what is going on)
Older software that has been around for a long time gets a bit of a pass on the above, but users are still required to know what is going on when they trust this software. DXLab applications fall into this category. Exclude the installation paths from virus scan's / malware scans. It's just the way it is right now, and only Dave can decide if the effort and cost is worth it to revamp the install locations and incur the cost of executable code signing into his build routines of the VB application in question, not to mention move all the read/write data to User/Document paths and deal with UAC. The arm flailing and weeping and wailing and gnashing of teeth from existing users of an amazing and free application, would reach an exponential level if they had to move their data around etc.... even if automated in the installer. I shudder at the flood of questions if this change were made and I'm guessing Dave would fear the same thing on the groups.io list here. I certainly don't speak for Dave at all.
An example of another amazing and free Ham related application that has adopted most if not all of the above standards is N1MM Logger+. Multiple developers in this case are coding on the N1MM project. N1MM Logger+ exe's are signed (see the link at the end of this post) and N1MM's installer tries to get you to install the exe's down the proper path in a Windows operating system. However, as we all know... you can override all of this and in effect disable all the efforts to try and protect you from yourself. But there is a cost here... time, money and laborious education. And this requires dealing with a new set of questions from uninformed users.
So, at the end of the day... DXLab users need to understand the current state of how DXLab is coded and how and where it is installed and understand that the exe's are not signed. It's okay if you understand that Dave clearly isn't out to deliver malicious code, but DXLab, like many other older exe based applications install into a directory structure that violates current best practices in the software industry. It's just the nature of the technical debt incurred with an older application that has been around for a long time. Again, I'm not suggesting Dave stop the train and crack this nut. We get the benefit of using DXLab which is an amazing suite of applications written by one super human developer and we just need to understand that the legacy nature of the installation and location of the data and exe's will make it suspect for industry standard virus scanning / malware scanning / bad actor detection software. Stop blaming Windows and modern virus / malware scanning / detection solutions and start understanding and why things were created they way they are.
In the ending of this massive diatribe of mine, executable code on a modern OS needs to be installed in OS / UAC locations and the exe code needs to be signed. Data needs to be installed in OS / UAC controlled locations where read/write is possible for the processes that need access to this data. And all executable code should be signed with a known digital certificate that is trusted by a known certificate authority so you a user knows where the code comes from in the first place. Is it all 100% fool proof? Nope, but it's better to understand how things work rather than spewing out the continued FUD around this ongoing topic.
Image showing the digital signature on the main N1MM exe <>

Max NG7M

On Sun, Apr 12, 2020 at 12:58 PM, <nigee.gardner@...> wrote:

Good morning. I have been using the DXlabs suit for a? while now to control my Icom IC7300. I like it very much. Main use is doing data modes, FT8 PSK31 etc. It has been working well controlling JTDX via Commander. Just lately I have been getting an error message from JTDX saying its lost control, rig error, I click on retry and starts working again. The other thing I noticed is when the transmit period starts the rig isn't being keyed until about 5 or 6 seconds into the cycle. I did initially think it may be RF getting in, but then noticed this error always happened during RX. So, I shut down Commander, reconfigured JTDX to control the rig directly, and all works fine again. So I am assuming theres suddenly and issue between JTDX and Commander?. BTW Commander also works ok standaloan. Any ideas?

73 Nigel G0CQZ

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Dave AA6YQ
Sent: Sunday, April 12, 2020 13:02
To: [email protected]
Subject: Re: [DXLab] Fear, Uncertainty and Doubt Regarding Anti-Virus / Anti-Malware Solutions like Defender etc...

Regarding the lengthy post from Max NG7M appended below,

1. Windows is vulnerable to malware because it fails to implement well-known operating system security measures; correcting this architectural defect would break many existing Windows applications, some of which can no longer be updated because their source code or unique development tools no longer exist. Microsoft has chosen to live with this defect and mitigate it with anti-malware applications, which are provided by many software companies and Microsoft itself.

2. During Microsoft's two unsuccessful attempts to recruit me (once to lead the Visual Studio organization, once to lead the Windows Mobile organization), I interviewed with several senior Windows developers and executives. They acknowledged that "protected folders" and "User Account Control" (UAC) provide little actual security value; these mechanisms were introduced to visibly demonstrate that Microsoft was taking security concerns seriously. "Oh, so you want a secure operating system, do you?" one of them joked.

3. There is no evidence that installing DXLab applications in

c:\Program Files

or digitally signing them would protect them from mis-identification by Microsoft anti-malware applications.

4. Since there is no malware in any DXLab application, Microsoft anti-malware applications that identify them as malware are by definition defective. If you chose to use a defective anti-malware application, enable it to autonomously upgrade itself, and enable it to autonomously quarantine applications it considers malware, then you should not be surprised when one of you applications suddenly stops working.

5. Microsoft's "solution" to their defective anti-malware is to accept submissions of executables incorrectly identified as malware for reconsideration. Over the past several days, multiple attempts to submit the 4.5 megabyte executable for Commander 14.5.5 stalled; the Microsoft submission site was evidently over-subscribed. Last night, the submission site took less than a minute to accept Commander's executable; today, the submission status shows "not malware". How long it will take for this updated determination to reach deployed instances of Windows Defender is anybody's guess. Will this stop the next public version of Commander from being mis-identifed as malware? Unknown.

My inclination at this point is to add Microsoft anti-malware to the list of applications that can interfere with DXLab applications in

<>

Control your computing environment, or it will control you.

73,

Dave, AA6YQ




-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Max NG7M
Sent: Sunday, April 12, 2020 11:53 AM
To: [email protected]
Subject: [DXLab] Fear, Uncertainty and Doubt Regarding Anti-Virus / Anti-Malware Solutions like Defender etc...

As we can see, the FUD (Fear, Uncertainty and Doubt) regarding Anti Virus / Anti Malware solutions (MS Defender in this case) have reached a new rhetorical level in regards to DXLab applications / exe's. (based on the number of posts)

First off, I'm not suggesting Dave AA6YQ change anything at this point because the effort would be rather high and the migration of currently installed application exe's to the proper location for a modern day operating system bring a level of complexity along with the change... installer changes and proper use of User Access Control (UAC) would be required along with changes to the installer code used by DXLab (digital signing of exe code etc...). So I'm happy with the way things are and I know that I need to exclude the directory where DXLab applications are installed in my Anti Virus software. So let me make that clear, I'm not complaining or suggesting that Dave do anything to address why this topic keeps coming up over and over and over and over and over again. Well, other than repeating the current solution and referring users to how you need to exclude the DXLab installation path from your anti-virus / anti-malware solution. The bitching and complaining about controls that are put in place to protect you and other users in what is in effect a shared network (the Internet) is rather comical at this point.

If you want to know why DXLab executables are getting identified as having problems, the problem is not Windows Defender or any other anti-virus / malware solution. Identifying Defender as the problem, just exposes your ignorance around this topic. In a nut shell, the problem is where the exe's (any any other executable code like dll's) for DXLab are getting installed along with the fact that the exe's are not digitally signed. If you don't agree, ask a software engineer who has been coding and helping release commercial Windows exe based (rich client) applications for over 30 years. And it helps if the engineer you are asking has had extensive experience related to using industry standard practices which are designed to help users keep their computers safe. Your lack of understanding about bad actors out there that are trying to exploit executable code and at what OS level this code can execute, is not helpful to the discussion. Stop acting like you are a 'safe computing expert' when you are not one... especially when you are disparaging solutions that have been put in place to protect you and others despite your own stupidity.

So for DXLab users at this stage of the game... which I am one of them and very happy with the amazing job Dave has and continues to do an amazing job with this free software offering! I'm perfectly happy excluding the default directory location where DXLab exe's are installed from my anti-virus software solution as an exclusion. I'm trusting Dave to not deliver exe based code that is malicious. And even if it pains me so, I'm letting the DXLab installation process install this executable code (that is not digitally signed) in a read/write location.

If you are happy with what you have and have excluded your DXLab installation path from your anti-virus / malware solution's scans, then you can stop reading now... or you probably never made it this far anyway. If you want more of the details as to what the industry standard has been for decades now, keep reading. DXLab has been around so long, it may be hard for Dave to justify a big change (and personal expense to digitally sign things) at this point. I total get that as I have stated above. However, when other users spew out fear, uncertainty and doubt regarding this topic, they should be corrected and their ignorance should be exposed.

Solutions like Windows Defender (a darn good free solution) are designed to protect you despite your, ignorance and laziness. You can give someone a Twenty Dollar Bill for free and then based on their ignorance, they will complain that you didn't give them two Ten Dollar Bills.

For decades now, the industry and creators of commercial operating systems in use in business and at home have tried and tried to make commercial and home computing safer. Linux / Unix based OS's and even MS Windows (make your silly evil sounds and wiggle your fingers in the air), have been trying to get software developers to locate executable code in a OS level protected directory structure. i.e. for Linux it would be /bin, or /usr/bin etc... for Windows it would be C:\Program Files (x86) for 32bit executables, and or C:\Program Files for 64bit executables. Constrains are put in place to protect the executable code in these directories using an OS level of User Access Control to keep code from executing at a 'root' level or administrator level (in the case of windows) where bad / malicious code could do all kinds of bad things... install key loggers to steal you passwords, or execute code to encrypt all your data and hold you hostage to ransomware schemes. Or just help use your computing power and network bandwidth to jump start other evil bad things without you even knowing day after day and week after week.

For the above reasons and many others not even listed, modern OS's and their designers do all they can to try and get software installed into protected areas of the file system and to only be run at levels where other bad code can't do bad things without you knowing. Is it perfect? nope but it's better than nothing and it's better than just burying your head in the sand and turning off all the protection.

So what is a Mother to do? The best practices which have been in place for decades now (and are not enforced with a draconian solution yet) are to install executable code in protected directories like, you guessed it: C:\Program Files etc... AND to locate application down a path specific to data like c:\Documents\YourUserName where read write access to data is based on user privilege's. AND in the case of executable data you digitally sign your executable code with a signature that can be verified by a known good certificate authority. (do a google search on PKI infrastructure if you want to learn more) this is what virus scanning software is looking at when it scan for issues. If the exe code of application A is properly signed and in the proper directories, then it's less likely to report a false positive. (yes a pretty simple description of what is going on)

Older software that has been around for a long time gets a bit of a pass on the above, but users are still required to know what is going on when they trust this software. DXLab applications fall into this category. Exclude the installation paths from virus scan's / malware scans. It's just the way it is right now, and only Dave can decide if the effort and cost is worth it to revamp the install locations and incur the cost of executable code signing into his build routines of the VB application in question, not to mention move all the read/write data to User/Document paths and deal with UAC. The arm flailing and weeping and wailing and gnashing of teeth from existing users of an amazing and free application, would reach an exponential level if they had to move their data around etc.... even if automated in the installer. I shudder at the flood of questions if this change were made and I'm guessing Dave would fear the same thing on the groups.io list here. I certainly don't speak for Dave at all.

An example of another amazing and free Ham related application that has adopted most if not all of the above standards is N1MM Logger+. Multiple developers in this case are coding on the N1MM project. N1MM Logger+ exe's are signed (see the link at the end of this post) and N1MM's installer tries to get you to install the exe's down the proper path in a Windows operating system. However, as we all know... you can override all of this and in effect disable all the efforts to try and protect you from yourself. But there is a cost here... time, money and laborious education. And this requires dealing with a new set of questions from uninformed users.

So, at the end of the day... DXLab users need to understand the current state of how DXLab is coded and how and where it is installed and understand that the exe's are not signed. It's okay if you understand that Dave clearly isn't out to deliver malicious code, but DXLab, like many other older exe based applications install into a directory structure that violates current best practices in the software industry. It's just the nature of the technical debt incurred with an older application that has been around for a long time. Again, I'm not suggesting Dave stop the train and crack this nut. We get the benefit of using DXLab which is an amazing suite of applications written by one super human developer and we just need to understand that the legacy nature of the installation and location of the data and exe's will make it suspect for industry standard virus scanning / malware scanning / bad actor detection software. Stop blaming Windows and modern virus / malware scanning / detection solutions and start understanding and why things were created they way they are.

In the ending of this massive diatribe of mine, executable code on a modern OS needs to be installed in OS / UAC locations and the exe code needs to be signed. Data needs to be installed in OS / UAC controlled locations where read/write is possible for the processes that need access to this data. And all executable code should be signed with a known digital certificate that is trusted by a known certificate authority so you a user knows where the code comes from in the first place. Is it all 100% fool proof? Nope, but it's better to understand how things work rather than spewing out the continued FUD around this ongoing topic.

Image showing the digital signature on the main N1MM exe <>


Max NG7M







--
W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Max NG7M
Sent: Sunday, April 12, 2020 11:53 AM
To: [email protected]
Subject: [DXLab] Fear, Uncertainty and Doubt Regarding Anti-Virus / Anti-Malware Solutions like Defender etc...

As we can see, the FUD (Fear, Uncertainty and Doubt) regarding Anti Virus / Anti Malware solutions (MS Defender in this case) have reached a new rhetorical level in regards to DXLab applications / exe's. (based on the number of posts)

First off, I'm not suggesting Dave AA6YQ change anything at this point because the effort would be rather high and the migration of currently installed application exe's to the proper location for a modern day operating system bring a level of complexity along with the change... installer changes and proper use of User Access Control (UAC) would be required along with changes to the installer code used by DXLab (digital signing of exe code etc...). So I'm happy with the way things are and I know that I need to exclude the directory where DXLab applications are installed in my Anti Virus software. So let me make that clear, I'm not complaining or suggesting that Dave do anything to address why this topic keeps coming up over and over and over and over and over again. Well, other than repeating the current solution and referring users to how you need to exclude the DXLab installation path from your anti-virus / anti-malware solution. The bitching and complaining about controls that are put in place to protect you and other users in what is in effect a shared network (the Internet) is rather comical at this point.

If you want to know why DXLab executables are getting identified as having problems, the problem is not Windows Defender or any other anti-virus / malware solution. Identifying Defender as the problem, just exposes your ignorance around this topic. In a nut shell, the problem is where the exe's (any any other executable code like dll's) for DXLab are getting installed along with the fact that the exe's are not digitally signed. If you don't agree, ask a software engineer who has been coding and helping release commercial Windows exe based (rich client) applications for over 30 years. And it helps if the engineer you are asking has had extensive experience related to using industry standard practices which are designed to help users keep their computers safe. Your lack of understanding about bad actors out there that are trying to exploit executable code and at what OS level this code can execute, is not helpful to the discussion. Stop acting like you are a 'safe computing expert' when you are not one... especially when you are disparaging solutions that have been put in place to protect you and others despite your own stupidity.

So for DXLab users at this stage of the game... which I am one of them and very happy with the amazing job Dave has and continues to do an amazing job with this free software offering! I'm perfectly happy excluding the default directory location where DXLab exe's are installed from my anti-virus software solution as an exclusion. I'm trusting Dave to not deliver exe based code that is malicious. And even if it pains me so, I'm letting the DXLab installation process install this executable code (that is not digitally signed) in a read/write location.

If you are happy with what you have and have excluded your DXLab installation path from your anti-virus / malware solution's scans, then you can stop reading now... or you probably never made it this far anyway. If you want more of the details as to what the industry standard has been for decades now, keep reading. DXLab has been around so long, it may be hard for Dave to justify a big change (and personal expense to digitally sign things) at this point. I total get that as I have stated above. However, when other users spew out fear, uncertainty and doubt regarding this topic, they should be corrected and their ignorance should be exposed.

Solutions like Windows Defender (a darn good free solution) are designed to protect you despite your, ignorance and laziness. You can give someone a Twenty Dollar Bill for free and then based on their ignorance, they will complain that you didn't give them two Ten Dollar Bills.

For decades now, the industry and creators of commercial operating systems in use in business and at home have tried and tried to make commercial and home computing safer. Linux / Unix based OS's and even MS Windows (make your silly evil sounds and wiggle your fingers in the air), have been trying to get software developers to locate executable code in a OS level protected directory structure. i.e. for Linux it would be /bin, or /usr/bin etc... for Windows it would be C:\Program Files (x86) for 32bit executables, and or C:\Program Files for 64bit executables. Constrains are put in place to protect the executable code in these directories using an OS level of User Access Control to keep code from executing at a 'root' level or administrator level (in the case of windows) where bad / malicious code could do all kinds of bad things... install key loggers to steal you passwords, or execute code to encrypt all your data and hold you hostage to ransomware schemes. Or just help use your computing power and network bandwidth to jump start other evil bad things without you even knowing day after day and week after week.

For the above reasons and many others not even listed, modern OS's and their designers do all they can to try and get software installed into protected areas of the file system and to only be run at levels where other bad code can't do bad things without you knowing. Is it perfect? nope but it's better than nothing and it's better than just burying your head in the sand and turning off all the protection.

So what is a Mother to do? The best practices which have been in place for decades now (and are not enforced with a draconian solution yet) are to install executable code in protected directories like, you guessed it: C:\Program Files etc... AND to locate application down a path specific to data like c:\Documents\YourUserName where read write access to data is based on user privilege's. AND in the case of executable data you digitally sign your executable code with a signature that can be verified by a known good certificate authority. (do a google search on PKI infrastructure if you want to learn more) this is what virus scanning software is looking at when it scan for issues. If the exe code of application A is properly signed and in the proper directories, then it's less likely to report a false positive. (yes a pretty simple description of what is going on)

Older software that has been around for a long time gets a bit of a pass on the above, but users are still required to know what is going on when they trust this software. DXLab applications fall into this category. Exclude the installation paths from virus scan's / malware scans. It's just the way it is right now, and only Dave can decide if the effort and cost is worth it to revamp the install locations and incur the cost of executable code signing into his build routines of the VB application in question, not to mention move all the read/write data to User/Document paths and deal with UAC. The arm flailing and weeping and wailing and gnashing of teeth from existing users of an amazing and free application, would reach an exponential level if they had to move their data around etc.... even if automated in the installer. I shudder at the flood of questions if this change were made and I'm guessing Dave would fear the same thing on the groups.io list here. I certainly don't speak for Dave at all.

An example of another amazing and free Ham related application that has adopted most if not all of the above standards is N1MM Logger+. Multiple developers in this case are coding on the N1MM project. N1MM Logger+ exe's are signed (see the link at the end of this post) and N1MM's installer tries to get you to install the exe's down the proper path in a Windows operating system. However, as we all know... you can override all of this and in effect disable all the efforts to try and protect you from yourself. But there is a cost here... time, money and laborious education. And this requires dealing with a new set of questions from uninformed users.

So, at the end of the day... DXLab users need to understand the current state of how DXLab is coded and how and where it is installed and understand that the exe's are not signed. It's okay if you understand that Dave clearly isn't out to deliver malicious code, but DXLab, like many other older exe based applications install into a directory structure that violates current best practices in the software industry. It's just the nature of the technical debt incurred with an older application that has been around for a long time. Again, I'm not suggesting Dave stop the train and crack this nut. We get the benefit of using DXLab which is an amazing suite of applications written by one super human developer and we just need to understand that the legacy nature of the installation and location of the data and exe's will make it suspect for industry standard virus scanning / malware scanning / bad actor detection software. Stop blaming Windows and modern virus / malware scanning / detection solutions and start understanding and why things were created they way they are.

In the ending of this massive diatribe of mine, executable code on a modern OS needs to be installed in OS / UAC locations and the exe code needs to be signed. Data needs to be installed in OS / UAC controlled locations where read/write is possible for the processes that need access to this data. And all executable code should be signed with a known digital certificate that is trusted by a known certificate authority so you a user knows where the code comes from in the first place. Is it all 100% fool proof? Nope, but it's better to understand how things work rather than spewing out the continued FUD around this ongoing topic.

Image showing the digital signature on the main N1MM exe <>


Max NG7M

From: [email protected] <[email protected]> On Behalf Of nigee.gardner@...
Sent: Sunday, April 12, 2020 06:26
To: [email protected]
Subject: [DXLab] Cat control

?

Good morning. I have been using the DXlabs suit for a? while now to control my Icom IC7300. I like it very much. Main use is doing data modes, FT8 PSK31 etc. It has been working well controlling JTDX via Commander. Just lately I have been getting an error message from JTDX saying its lost control, rig error, I click on retry and starts working again. The other thing I noticed is when the transmit period starts the rig isn't being keyed until about 5 or 6 seconds into the cycle. I did initially think it may be RF getting in, but then noticed this error always happened during RX. So, I shut down Commander, reconfigured JTDX to control the rig directly, and all works fine again. So I am assuming theres suddenly and issue between JTDX and Commander?. BTW Commander also works ok standaloan. Any ideas?

73 Nigel G0CQZ

--

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop