Antivirus and Application Compilation


This is an update of a post that originally appeared on 
April 2, 2014.

Sometimes applications don’t get along, especially when one application is designed to create new content at a low level and the other is designed to prevent low level access to a system. Such is the case with compilers and antivirus applications in some cases. I haven’t been able to reproduce this behavior myself, but enough readers have told me about it that I feel I really do need to address it in a post. There are situations where you’re working with source code from one of my books, compile it, and then have your antivirus application complain that the code is infected with something (even though you know it isn’t). Sometimes the antivirus program will go so far as to simply delete the application you just compiled (or place it in a virus vault).

The solution to the problem can take a number of forms. If your antivirus application provides some means of creating exceptions for specific applications, the easiest way to overcome the problem is to create such an exception. You’ll need to read the documentation for your antivirus application to determine whether such a feature exists. In most cases today, antivirus applications also provide settings that accommodate specific applications and you’ll want to check with the antivirus vendor and/or community support to see if this need has been met.

In some cases, the compiler or its associated Integrated Development Environment (IDE) simply don’t follow all the rules required to work safely in protected directories, such as the C:\Program Files directory on a Windows system. As far as I know, all of the development environments currently used in my books do follow the rules, so you shouldn’t have a problem in this area, but please let me know if you do. Often, the workaround for this problem is to install the application in a directory that the user owns and just avoid the security issue.

Not including the application in the Windows path can cause problems and I cover this issue in the Adding a Location to the Windows Path post. In addition, there are problems with installing the source code in a path containing spaces or lacks proper access. I discuss these issues in the Source Code Placement post.

Unfortunately, creating exceptions and installing the application in a friendly directory only go so far in fixing the problem. A few antivirus applications are so intent on protecting you from yourself that nothing you do will prevent the behavior. When this happens, you still have a few options. The easiest solution is to turn the antivirus program off just long enough to compile and test the application. Of course, this is also the most dangerous solution because it could leave your system open to attack.

A safer, albeit less palatable solution, is to try a different IDE and compiler. Antivirus programs seem a little picky about which applications they view as a threat. Code::Blocks may cause the antivirus program to react, but Eclipse or Visual Studio might not. Unfortunately, using this solution means that steps in the book may not work precisely as written. In addition, unless the compilers are compatible, the book’s source code may not compile at all without changes. Because I can’t cover every contingency, I also can’t support using a compiler other than the one specifically called out in a book.

Getting a different antivirus application is also a good idea. Antivirus applications and IDEs have come a long way since I originally created this post, but some antivirus applications really don’t work well and create more headaches than they’re worth. The choice is up to you, of course, but with the wealth of antivirus programs available on the market today, there isn’t a good reason to avoid getting something new when the situation warrants.

My goal is to ensure you can use the examples in my books without jumping through a lot of hoops. When you encounter problems that are beyond my control, such as an ornery antivirus application, I’ll still try to offer some suggestions, but I can’t take time to fix your system. In this case, the solution truly is out of my control but you can try the techniques offered in this post. Let me know if you find other solutions to the problem at [email protected].

Adding a Location to the Windows Path

This is an update of a post that originally appeared on February 17, 2014.

A number of my books tell the reader to perform tasks at the command line. What this means is that the reader must have access to applications stored on the hard drive. Windows doesn’t track the location of every application. Instead, it relies on the Path environment variable to provide the potential locations of applications. If the application the reader needs doesn’t appear on the path, Windows won’t be able to find it. Windows will simply display an error message. So, it’s important that any applications you need to access for my books appear on the path if you need to access them from the command line.

You can always see the current path by typing Path at the command line and pressing Enter. What you’ll see is a listing of locations, each of which is separated by a semicolon as shown here (your path will differ from mine).

Using the Path command displays the current path.

In this case, Windows will begin looking for an application in the current folder. If it doesn’t find the application there, then it will look in C:\Python33\, then in C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common, and so on down the list. Each potential location is separated from other locations using a semicolon as shown in the figure.

There are a number of ways to add a location to the Windows path. If you only need to add a path temporarily, you can simply extend the path by setting it to the new value, plus the old value. For example, if you want to add C:\MyApp to the path, you’d type Path=C:\MyApp;%Path% and press Enter. Notice that you must add a semicolon after C:\MyApp. Using %Path% appends the existing path after C:\MyApp. Here is how the result looks on screen.

Adding a path is a relatively simple process using the Path= command

Of course, there are times when you want to make the addition to the path permanent because you plan to access the associated application regularly. In this case, you must perform the task within Windows itself. The following steps tell you how.

1. Right click This Computer (or Computer) and choose Properties from the context menu or select Settings (or System in the Control Panel). You see the a Settings (System) window similar to the one shown here open (precisely what you see depends on which version of Windows you have, the figure shows Windows 10).

    The Settings window in Windows 10.

    2. Click Advanced System Settings. You see the Advanced tab of the System Properties dialog box shown here.

    The Advanced tab provides access to your permanent path in Windows.

    3. Click Environment Variables. You see the Environment Variables dialog box shown here. Notice that there are actually two sets of variables. The top set affects only the current user. So, if you plan to use the application, but don’t plan for others to use it, you’d make the Path environment variable change in the top field. The bottom set affects everyone who uses the computer. This is where you’d change the path if you want everyone to be able to use the application.

    There are paths that affect only the current user and those that affect the system as a whole.

    4. Locate the existing Path environment variable in the list of variables for either the personal or system environment variables and click Edit. If there is no existing Path environment variable, click New instead. You see a dialog box similar to the one shown here when working with Windows 10 (other versions of Windows will show a different dialog box, but the purpose is the same, to edit the path).

    Each path location appears on a separate line to make it easy to edit.

    When you open a new command prompt, you’ll see the new path in play. Changing the environment variable won’t change the path for any existing command prompt windows. Having the right path available when you want to perform the exercises in my books is important. Let me know if you have any questions about them at [email protected].

     

     

     

    Source Code Placement

    This is an update of a post that originally appeared on October 12, 2015.

    I always recommend that you download the source code for my books. The Verifying Your Hand Typed Code post discusses some of the issues that readers encounter when typing code by hand. However, I also understand that many people learn best when they type the code by hand and that’s the point of getting my books—to learn something really interesting (see my principles for creating book source code in the Handling Source Code in Books post). Even if you do need to type the source code in order to learn, having the downloadable source code handy will help you locate errors in your code with greater ease. I won’t usually have time to debug your hand typed code for you.

    Depending on your platform, you might encounter a situation the IDE chooses an unfortunate place to put the source code you want to save. For example, a Windows System might choose the Program Files folder, which contains a space and doesn’t allow saving of files unless you specifically override the default rights. Fortunately, modern IDEs do manage to avoid many of these problems, but you still need to be aware that they could exist, especially when using an older IDE.

    My recommendation for fixing these, and other source code placement problems, is to create a folder that you can access and have full rights to work with to store your source code. My books usually make a recommendation for the source code file path, but you can use any path you want. The point is to create a path that’s:

    • Easy to access
    • Allows full rights
    • Lacks spaces in any of the pathname elements
    • On a local drive, rather than a cloud drive in many cases

    As long as you follow these rules, you likely won’t experience problems with your choice of source code location. If you do experience source code placement problems when working with my books, please be sure to let me know at [email protected].