Understanding System Software: Core Functions and Operational Necessities Explained

System software might sound like a complex term, but it’s really the backbone of every computer or device you use. If you’ve ever wondered what keeps your laptop running smoothly, manages your files, or lets your apps talk to your hardware, system software is the answer. It’s a crucial part of technology that handles the core functions of a device, ensuring everything works together seamlessly. In this guide, we’ll break down what system software is, its main functions—like operating systems, disk management, utilities, and hardware management—and why it’s so important for your tech experience. Whether you’re a tech enthusiast or just someone curious about how your device works, this explanation will help you understand the essentials in a simple way.

What Is System Software?

System software is a type of program that acts as a bridge between your device’s hardware and the applications you use every day. Think of it as the manager of your computer—it handles all the behind-the-scenes tasks so you can focus on browsing the web, playing games, or editing photos. Without system software, your hardware (like the processor, memory, or hard drive) wouldn’t know how to work with the apps you love.

At its core, system software provides the operational necessities that keep a device running. This includes things like the operating system (OS), which is the most well-known example of system software. But it also covers other tools like disk management programs, utilities that help maintain your system, and drivers that let your hardware communicate with the rest of the device. System software is different from application software (like your web browser or a game) because it’s not something you interact with directly—it works quietly in the background to make everything else possible.

Core Functions of System Software

System software has several key roles that ensure your device operates smoothly. Let’s dive into the main functions it handles, so you can see just how important it is.

1. Operating Systems: The Heart of Your Device

The operating system, or OS, is the most critical piece of system software. It’s the program that starts up when you turn on your computer, managing all the hardware and software on your device. Popular operating systems include Windows, macOS, Linux, and mobile systems like Android and iOS. The OS handles tasks like running apps, managing memory, and keeping your files organized.

For example, when you open a photo-editing app, the operating system makes sure the app has enough memory to run, connects it to your screen and mouse, and lets it save files to your hard drive. Without an OS, your computer would just be a collection of parts with no way to work together. The operating system also provides a user interface—like the desktop on your laptop or the home screen on your phone—so you can interact with your device easily.

2. Disk Management: Keeping Your Storage in Check

Another important function of system software is disk management. This involves organizing and maintaining the storage on your device, whether it’s a hard drive, SSD, or external USB drive. Disk management tools handle tasks like formatting drives (preparing them to store data), creating partitions (dividing a drive into sections), and checking for errors that might cause data loss.

For instance, if you’ve ever used a tool to “defragment” your hard drive on a Windows computer, that’s a disk management utility at work. Defragmentation rearranges scattered pieces of data on your drive, making it faster to access files. Disk management also ensures that your files are saved properly and can be retrieved when you need them, keeping your storage system efficient and reliable.

3. Utilities: The Maintenance Crew

System software often includes utilities—small programs that help keep your device running smoothly. These tools handle maintenance tasks that you might not think about but are essential for performance. Examples include antivirus programs that protect against malware, disk cleanup tools that remove unnecessary files, and backup software that saves your data in case of a crash.

Utilities are like the janitors of your computer, quietly tidying up and fixing issues before they become big problems. For example, a utility might scan your system for outdated drivers (software that connects your hardware to the OS) and update them to keep everything working properly. These tools are often built into the operating system or available as separate downloads, giving you an easy way to maintain your device’s health.

4. Hardware Management: Connecting the Pieces

Hardware management is another key role of system software. Your device has many hardware components—like the processor, graphics card, keyboard, and printer—that need to work together. System software, particularly device drivers, ensures that these components can communicate with the operating system and your apps.

A device driver is a small program that acts as a translator between the hardware and the OS. For example, when you print a document, the printer driver tells the printer what to do, translating the document’s data into a format the printer understands. Without drivers, your hardware would be useless, as the operating system wouldn’t know how to use it. System software also manages resources like memory and processing power, making sure each piece of hardware gets what it needs to function.

5. Other Operational Necessities: The Glue That Holds It Together

Beyond these main functions, system software handles other operational necessities that keep your device running. This includes managing system resources (like CPU usage), scheduling tasks (deciding which app runs when), and providing security features (like user authentication). These tasks happen in the background, ensuring your device is stable and secure while you use it.

For example, when you’re multitasking—say, watching a video while downloading a file—the operating system makes sure both tasks run smoothly without crashing. It allocates resources like memory and processing power to each task, balancing everything so you don’t notice the complexity. These operational necessities are what make system software so vital—it’s the glue that holds your tech experience together.

Why System Software Matters

System software might not be something you think about every day, but it’s what makes your tech life possible. Without it, your computer or phone would be a lifeless collection of parts, unable to run apps, connect to the internet, or even turn on. It’s the foundation that supports everything you do, from sending an email to playing a game to editing a video.

For someone with a bit of tech experience, understanding system software can also help you troubleshoot issues. If your computer is slow, knowing that a disk management tool can defragment your drive might solve the problem. If a piece of hardware isn’t working, you might need to update its driver. System software gives you the tools to keep your device in top shape, making your tech experience smoother and more enjoyable.

The Bigger Picture: System Software in Everyday Life

System software isn’t just about computers—it’s everywhere. Your smartphone, gaming console, smart TV, and even your car’s navigation system all rely on system software to function. In a broader sense, system software supports the digital world we live in, powering the devices that keep us connected, entertained, and productive. It’s a reminder of how technology has become a seamless part of our lives, thanks to the quiet work of system software in the background.

As technology evolves, system software continues to grow more advanced. Modern operating systems like Windows 11 or macOS Ventura come with features like virtual desktops, voice assistants, and cloud integration, making them more powerful than ever. At the same time, they still handle the core functions—managing hardware, organizing storage, and keeping everything secure—that have been part of system software for decades. It’s a balance of innovation and reliability that keeps our devices running smoothly.

Further References and Resources

If you’d like to dive deeper into system software, there are plenty of resources to explore. Books like Operating System Concepts by Abraham Silberschatz (Buy book - Affiliate link), Peter B. Galvin, and Greg Gagne offer a detailed look at how operating systems work, perfect for those who want a more technical understanding. Websites like HowStuffWorks (howstuffworks.com) have articles on system software, disk management, and hardware drivers, written in a way that’s easy to follow.

For visual learners, YouTube is a great place to find tutorials and explanations. Channels like “Techquickie” have videos such as “What Is System Software? Explained in 5 Minutes,” which break down the basics in a simple way. Another good video is “How Operating Systems Work” by the channel “CrashCourse,” which dives into the role of the OS in managing hardware and software. You can also search for “disk management tutorial” or “what are device drivers” on YouTube to find step-by-step guides, often with visuals that make the concepts easier to grasp.

A Personal Connection to System Software

As someone who’s always been curious about tech, learning about system software has been eye-opening. It’s amazing to think about how much happens behind the scenes every time I turn on my laptop or phone. The operating system, the drivers, the utilities—they all work together so I can do simple things like watch a video or save a file. It makes me appreciate the tech I use every day and gives me a better idea of how to fix things when they go wrong.

System software might not be the most exciting topic at first glance, but it’s the foundation of everything we do with technology. Whether you’re a casual user or a tech enthusiast, understanding its core functions—like operating systems, disk management, utilities, and hardware management—can give you a new appreciation for the devices you rely on. It’s the unsung hero of the tech world, quietly keeping everything in order so you can focus on what matters.

Define the Virtual Memory technique?

Modern operating systems come with multitasking kernels. These multitasking kernels often run in to the problems related to memory management. Physical memory does not suffice for them to execute the tasks assigned to them because of being fragmented. So they have to take some additional from the secondary memory. But they cannot use this memory directly. Virtual memory offers a solution to this problem. 

What is Virtual Memory technique?

- Using this technique makes the fragmented main memory available to the kernels as a contiguous main memory. 

- Since it is really not the main memory but just appears to be, it has been named as the virtual memory and this technique is called the virtual memory technique. 

- Since, it helps in managing the memory, it is essential a memory management technique. 

- The main storage gets fragmented because of many programming and processing problems. 

- The main memory available to the processes and the tasks is virtualized by the virtual memory technique and then it appears to the process as a contiguous memory location. 

- This memory is a global address space. 

- Virtual address spaces such as these are managed by the operating system. 

- The real memory is assigned to the virtual memory by the operating system itself. 

- The virtual addresses of the allocated virtual address spaces are translated in to the physical addresses automatically by the CPU. 

- It achieves this with the help of some memory management hardware specially designed for this purpose. 

- The processes continue to execute uninterrupted as long as this hardware properly translates the virtual addresses in to real memory addresses properly. 

- If it fails in doing so at any point of time, the execution comes to a halt and the control is transferred to the operating system. 

- The duty of the operating system now is to move the requested memory page to the main memory from the backing store. 

- Once done with this, it then returns the control again to the process that was interrupted. 

- It greatly simplifies the whole execution process. 

- Even if the application would require more data or code that would fit in real memory, it does not have to be moved to and fro between the backing store and the real memory. 

- Furthermore, this technique also offers protection to the processes that are provided distinct address spaces by the isolation of the memory allocate to them from other tasks.

- Application programming has been made a lot easier with the help of the virtual memory technique since it hides the fragmentation defects of the real memory. 

- The burden of memory hierarchy management is delegated to the kernel which eliminates the need for the explicit handling of the overlays by the program. 

- Thus each process can execute in an address space that is dedicated to it. 

- The need for relocating the code of the program is obviated along with using relative addressing for accessing the memory. 

- The concept of virtual memory was generalized and eventually named as memory virtualization. 

- Gradually, the virtual memory has become an inseparable part of the architecture of the modern computers. 

- For implementing it, dedicated hardware support is absolutely necessary. 

- This hardware is built in to the CPU in some sort of memory management hardware. - If required for boosting the performance of the virtual memory, some virtual machines and emulators may employ some additional hardware support. 

- The older mainframe computers did not have any support for the virtual memory concept. 

- In virtual memory technique, each program can solely access the virtual memory.

How to determine the Operating System support for your product - Part 8

In this series of posts, I have been talking about the Operating System support provided in your applications. In the previous post (Operating System support for your software application - Part 7), I talked about support for 32 bit vs. 64 bit and also talked about how support provided by components can be a huge factor in the operating systems that you support. I took the example of a video application which depends on a large number of external components for codecs, encoders and decoders, for writing to DVD and Blu-Ray and for other parts of the application. If some of these components drop support for an operating system and that component is a critical part of the application, then it is time to take the decision to drop an Operating System. I know of a number of software applications that finally dropped support for Windows XP because 1) Microsoft is on its way to dropping support for Windows XP, with this support ending in 2014. 2) A number of external components dropped support for Windows XP and these were critical enough that the management team of the application finally bit the bullet and dropped support for Windows XP as well.
What happens when you cannot afford to drop support for an application such as where components have dropped support, but the customer profile is such that there is still revenue to be had from customers on this operating system ? Well, that is not a very nice place to be, but you still need to take a stand. If the revenue is important, then you will need to support that specific operating system. So what do you do ? There are a number of steps that you can take to ensure that your product remains on that operating system.
1. Well, you will need to make another effort to ensure that the external component retains support for that specific operating system. If the company or group providing the external component is not willing to provide full support, ask whether they are willing to maintain it to the level that was previously supported. If this is another group in the company, then the revenue potential provides some leverage to ensure that escalation can happen and support is maintained, even if it is at a lower level (only critical bug fixes are provided rather than all bug fixes).
2. The most risky approach. You take a chance and go with a component that is not supported by the provider on that specific operating system. The problem in this case would be that if there is some critical problem that has emerged, things can go out of control very easily, and lead to a situation where there are no good options.
3. Look for alternatives. There are very few functionality items that would not have multiple providers, even if the alternative is a less than perfect functionality. If using another component provides a solution, then you should evaluate the other component and use it if it meets your purpose (even if less than perfect).
4. Prepare for a reduced functionality. I have seen many products using such an approach. When there are no alternatives, and it is decided that support for the specific operating system needs to be continued, then it may be something as easy as dropping the component which has dropped support for the operating system, and having the product without the functionality provided by that component. This needs to communicated to customers as well so that they know that there will be reduced functionality on that specific operating system.

How to determine the Operating System support for your product - Part 7

In the previous post in this series (Operating System support for your software application - Part 6), I focused on the different roles and responsibility of stakeholders in the team, primarily the Product Management, the QE, and the developers. The Product Manager has to take the decision taking into account the various pros and cons of such a move, and also while evaluating revenue impact; the QE and development team would do their contribution to this discussion keeping in mind the impact on their effort, and any technical factors that could also influence the decision. In this post, I will talk more about the dependency and also briefly touch on the 32 bit or 64 bit discussion.
For some years now, there has been an ongoing discussion about the need to move applications onto a 64 bit architecture and stop support for 64 bit architecture. Most people will not understand this discussion, and the reason why it is a top item of discussion for many teams. In near layman's terms, when you state that your application is now 64 bit, it would mean that it can take inherent advantage of the benefits posed by the new wave of 64 bit operating systems, being able to allocate more memory, and numerous other technical advantages. Also, most Operating Systems that are now available are 64 bit. So why not go ahead and convert your application to 64 bit ? Well, converting your codebase to offer native 64 bit support is a project by itself, requiring a large amount of development and testing time. For teams that have limited resources, making such choices is not easy (and most teams cannot claim to have unlimited resources). In addition, you also need to realize that you would no longer be properly supporting consumers who still have 32 bit operating systems (and where the hardware has been supporting 64 bit for a long time now), so this is a decision that needs to be taken.
The other aspect of this post is in terms of the various components that your application would use. In today's world of software development, it is hard to think of a large software that the development team has totally written. Consider that your product is a large video manipulation application. Even though a lot of the workflows will be written by your team, the functionality of a number of sub-areas are better handled by using external components (which could be built by other teams within the company, or by other companies which specialize in such areas). For example, if you are looking at an application that allows users to organize, edit and manipulate videos, you would need support for the different video formats, you would need access to different encoders and decoders, you would need components for creating DVD's or Blue Ray discs as part of the end process. In all such cases, it is far more efficient and effective to use specialized software rather than trying to replicate all of them.
And this is where you dependency starts to dictate matters for you in terms of the operating system support. The external components that you use are created by companies that in turn have to take the same decision for operating system support as you do, and they would also have a large number of customers, based on whom they need to take decisions. It is entirely possible that you would end up in a scenario where some key component that you are using is dropping support for an operating system, and given its criticality in your own application, you are forced to also stop support for the same operating system.

How to determine the Operating System support for your product - Part 6

This blog has seen a series of posts on deciding the Operating System supported by your application. The previous post (Operating Systems supported by your application - Part 5) talked about the kind of constrains that there are for an operating system that is not supported - whether these prevent the user from installing the application on that operating system, or just give a warning and let the user install on the specific operating system. This post will talk in more detail about the process for the various stakeholders in the team that come to a decision about the operating systems to support.
The most important stakeholder is the Product Manager. It is the product manager who is responsible for the final state of the product, the system requirements for the product (which includes the operating systems to be supported in the application). The Product Manager is also the one who is responsible for the revenue requirements for the product, and supporting or dropping an operating system can make a difference to the revenue generated by a product by a few percentage (and these few percentage can make a huge difference in terms of whether targets are met or missed). Hence, it is for the Product Manager to take a final call on whether the product should drop a specific Operating System or not. However, it is perfectly fine for team members to be able to provide a lot of updates and constraints to the product manager.
Another important stakeholder is the QE team (the testers). During the testing phase, the team needs to draw up a plan of which are all the operating systems that need to be supported, need to decide the amount of effort to be spent in each operating system, and then actually put in the effort. Suppose a team supports Windows XP, Windows Vista, Windows 7 and Windows 8. In such a case, the team would use data about the approximate number of users on each operating system in order to prioritize the testing effort on each operating system (no testing team has enough resourcing to do all the tests and spend the effort that they would like to do). But you would still expect that if there are 4 operating systems, then the team would spend around atleast 15% on each operating system testing. In some cases, the testing for an operating system might take more time because there are more defects to be found on such an operating system (for example, we found a lot more problems on Vista, many of them related to the security issues because of the user security accesses control introduced in Vista).
So, the testing team would want that if there is a possibility of reducing an operating system because of a lesser number of users on such a system, then they would hold a number of discussions with the Product Manager on this topic, to ensure that their voice is heard and if they have any data, that is also passed onto the Product Manager (such data could be the increasing number of bugs that they are finding on older operating systems).
The development team are also important stakeholders. They are responsible for ensuring that the code is there for functionality to work the same on all the supported operating systems, something that can be problematic sometimes because the operating systems behave differently. In addition, there may be components in use that are not supported as well on older operating systems.
All these are stakeholders and opinions that need to be factored in before taking a decision on whether to drop a specific operating system. The decision needs to be taken after factoring in a lot of points.

In the next post, I will add more points on this particular topic (Operating Systems support for your application - Part 7)

How to determine the Operating System support for your product - Part 5

This particular series of posts talks about how to determine the support for previous Operating Systems provided in your application (Operating System Support in your application - Part 4). In the previous post, I talked about one major factor - when the maker of the Operating System (whether that be Microsoft or Apple) decides to drop support for the Operating System and will not provide any more bug fixes or other support. This gives a problem where even if you decide to support such an application, you will not get any bug fixes from the makers of the Operating System, which can be a huge potential problem given the interactions of the application with the Operating System.

In this post, I will talk about the process of cutting off support for an Operating System. There are 2 different methods which I have seen about how to cut off support for an Operating System. One of the ways is to provide a hard constraint, which means that the user will not be able to install on that specific Operating System, and the other is a soft constraint which means that the user is given a warning when trying to install on that version of the Operating System.

Consider the variation about using a hard constraint that prevents the user from installing on such an Operating System. What this means is that when the user tries to load the application on that specific version of the Operating System, the application determines the specific Operating System loaded on the computer, and then checks with the supported list of Operating Systems. If the Operating System is not to be supported, then the application installer will give an error to the user and prevent any installation on the user machine. 

Putting a hard constraint is needed when the makers of the software have made a determination that the user should be prevented on that Operating System. This can be when there is a high deal of uncertainty about whether the application will work well on that Operating System without any defects, or when the makers have decided that the version of the Operating System is not in wide user anymore. The hard constraints are also used when the Operating System installed on the user machines is controlled, such as in the case of higher end or specialized software.

The soft constraint means that the user will get a message during the installation process about the version of the Operating System not being supported, and will get an option about whether to proceed or not. If the user decides to go ahead, then the application will get installed. This is normally done when there is an expectation of very few problems on that specific Operating System, and the company does not really want to force the users of that specific Operating System to try alternative solutions. There will be need to be some testing of that specific Operating System, but not at the same level as that of the supported Operating Systems.

Read more in the next post (Determine Operating System support for your application - Part 6)

How to determine the Operating System support for your product - Part 4

In the previous post of this series (Determining Operating System Support for your application - Part 3), I wrote about the process of determining the number of people in your customer base who are using the Operating System in question. There are ways to do surveys and look at industry data, but there is some amount of variability involved even when analysing the data and some amount of assumptions need to be made. Of course, trying to make such decisions without trying your best case on how to get the data required for such analysis is something that organizations should avoid at all costs. Such decisions could cost money that the organization could ill afford, and hence such decision making should be done with a lot of deliberation.
In this post, let us consider another factor that is of great importance in deciding when to drop support for an Operating System from your application. This is related to the drop in support for a particular Operating System by the makers of the operating system. So, if you could consider the case of an operating system such as Windows NT or Win 2000, the support for all of these have been dropped by Microsoft, and if you were to try to get resolution for a problem on these operating systems with Microsoft, they would decline to provide you any support and ask you to upgrade to the newest operating system.
Now you are developing an application that will run on the operating system. Any application, especially those that accesses files on the local machines or that accesses devices on the local machines such as printers (and most applications give a print interface) have a dependency on the files of the Operating System. From time to time, there are problems that crop up where you need to work with the makers of the Operating System (typically Microsoft or Apple) and even expect them to make some fixes for you. When the makers of the Operating System withdraw support, they stop supporting such problems and no longer want to provide fixes for such problems.
So what do you do ? You could still provide support for the Operating System even when the maker of the Operating System is no longer providing any support, but there is an inherent risk in this decision. During the development process, you could run into a problem that could cripple your system and yet you don't have a solution, or a solution on your end is expensive and time consuming  In such cases, it will cause you significant problems; on the other hand, small problems that really are not problems could be all that are caused. And you have to consider that the maker of the operating system would also have thought a lot about dropping support, and there would have been some factors that went into such a decision.
Apple makes it even easier. As and when Apple releases new operating systems, new machines that are released are packaged with these new systems, and they even stop supporting older operating systems on these machines. Deciding on dropping older versions of the Mac is easier than that of Windows, also because the customer base using the Mac Operating System would be less than that of Windows.

Read the next post in this series (Operating System support for your application - Part 5)

How to determine the Operating System support for your product - Part 3

In the past post in this series related to how to determine the Operating Systems support for your application (Operating System Support - Part 2), I talked about trying to determine what your current users support. If your current users are using an Operating System in fairly significant numbers, then it would be hard for you to drop support for such an Operating System; you would risk turning off these users, preventing them from buying the newer version of your software, and drop a significant potential customer base. But, this decision remains a complicated one.
In the previous post, I talked about getting this data from current users. But it is not only current users from whom data needs to be taken. To ensure that you are not dropping potential users from your customer base, you need to do surveys to determine whether your potential users are having an Operating System that you are planning to drop. Consider the case of Windows XP at this point of time. It is an old Operating System and you would might think that most users have moved on from Windows XP. But suppose you decided to drop support of this Operating System from your newer version and then suddenly see a drop in sales, it would seem obvious that you did not do the required survey of your potential users before making such a significant decision.
So what needs to be done ? Well, this is a survey of your potential customers, and is not as easy as just getting data from existing users. However, at the same time, there are many ways to get data related to Operating System usage. At any time, if you just do a search for Operating System usage, you will find that there are a number of articles where surveys have been done to determine the prevalence of Operating Systems among people worldwide, in specific age groups, across geographies and so on. So, if you have a product whose potential customer base is primarily among people above the age of 40 in the United States, there will be some industry data related to such a customer base. Of course, the data will not be exactly in the way that you need, so you need to account for the assumptions, look at the variables and then do an analysis to determine the data appropriate for you and use that as an input for your decision making.
However, it is not just looking at industry data. Another input for decision making is to call for a survey that looks at a sample of your user base and then provides that data to you along with a factor that determines the error assumptions in the survey. The advantage of this method is that you can determine the exact assumptions to be made in the survey, the queries to ask, and then get the results. However, to get accurate results and to ensure that you are not making inaccuracies, the survey needs to be thought through properly, and this can be expensive. But the science of surveys is pretty much standard, and you can be fairly confident about the results.
Now you have got the data required for your decision making, and you need to add variables regarding whether people who have older operating systems will actually buy your software, since people who are comfortable with their current software and operating systems are likely to have a lower percentage chance of buying newer software, even if it is very useful.

More information in the next post in this series (Deciding Operating System Support for your software - Part 4)

How to determine the Operating System support for your product - Part 2

In the part 1 of their series (Determine the Operating System Support for an application - Part 1), I started with the discussion about the various Operating Systems that product teams could support, and some of the complications that come about in the decision making for deciding the Operating System support. In this post, I will talk about some of the other issues that help decide what the operating system support should be.
One simple factor that determines what older versions of Operating Systems you should support include determining the customer impact if you drop a version. In today's day and age, you would be hard-pressed to find a user who has Windows 95 or Windows NT on their machines or an equivalent older version of the Mac OS. Even if you did find somebody like that, the number of people who are actually on such Operating Systems would be very small, and you should be able to afford such users. The tricky park comes with Operating Systems that are closer to the current version, such as Windows XP. Now Windows XP has had 3 newer versions of the Windows Operating Systems that have been available after that, namely Windows Vista, Windows 7, and Windows 8. But, a number of people (especially older people) do not make their software upgrade decisions based on whether a newer version is available. If a newer version is available, and if their existing version provides the functionality that they are comfortable with, you will find a significant % of people will not upgrade their Operating Systems or their machines. I personally know numerous people who heard bad stuff about Windows Vista, decided that their Windows XP installation was fine, and refused to upgrade. If your expected customer base has people who are like this, then it would be foolhardy to do an upgrade unless you are sure about your figures. And this is where things get tricky. You have to do data reporting and data analysis to get enough information to take a decision.
Now even inferring from the data analysis may not be fairly straight-forward. How do you decide the data collection technique ? You would want to know from 2 sources - one would be the current users of the application, and the other would be potential users. None of these are easy methods.
Suppose you want to get this data from current users ? The ideal way would have been to have a mechanism within the application that connects on a regular basis to your computers and provides some information about the computer of the user, including the Operating System and Service Pack version of the software application. If you were getting this information from all your users, then it is very easy to consolidate this information and quickly determine how many of your users are on the Operating System on which there is a query about whether you should continue to support it. Suppose you have set a benchmark of 10% being the limit above which you will continue to support an Operating System, then this data will easily help you make a decision. At the same time, keep in mind that building such a system in the application is not easy. In this day and age of security and privacy considerations, you would need to ensure that such a mechanism passes legal and privacy guidelines. Further, keep in mind that some of your users may not be connected to the internet on a regular basis and hence the data you get is only from those people who are connected to the internet. As always, when you get data, you need to make sure that this data is an accurate as you can verify. The method used for data collection, the logic used for the data interpretation both need to be accurate and verified, else you will commit the grave mistake of taking a decision based on either wrong data or wrong analysis of data, both of which can cause grave problems.

This is it for this post, will continue in this series in the next (Determine Operating System Support - Part 3).

How to determine the Operating System support for your product - Part 1

You are working on your product, and one of the big factors determining the amount of effort needed for testing, and to some extent development, is the platform support that you offer. For both Windows and Mac, there are a large number of Operating Systems that have been released over the years, and if your product has been getting released into the market over a number of years, you would have had to support many of these Operating Systems. Consider the case of Microsoft Windows; it has had a number of operating systems released as time went by - Win 3.1, Win95, Win98, Win NT, Win 2000, Win XP, Vista, Windows 7 and now Windows 8 (I have been working on products that have been in the market supporting Operating Systems from Win 3.1). A number of people would ask as to what is the problem in supporting previous versions of Operating Systems. If you consider a software that is also released on the Mac, there are also different version of Mac OS that have been released over the years.
Now, there is a huge cost of maintaining software on these multiple Operating Systems (and when I say maintaining, I actually mean supporting these OS's on newer versions of the software). When you say that you are supporting an Operating System, this is not possible unless you have done a round of testing on that particular Operating System. So, the more Operating Systems that you have to support, the additional amount of testing that you have to do. Also consider that every Operating System would have had patches that need to be supported. So Windows XP is actually Windows XP, Windows XP Service Pack 2, Windows XP Service Pack 3. And we have seen many cases that the test results could be different because of the difference in the version number of common DLL's such as the Windows Runtime DLL's that are present in these Service Packs.
Many of these Operating Systems are very old, and not supported by Microsoft (or in the case of the Mac, not supported by Apple) anymore. In fact, Microsoft has already removed OS's earlier than Windows XP from their list of supported Operating Systems, and XP is also quickly on the way out. However, depending on your customer profile, decisions such as dropping support of various Operating Systems are not so easy. For products that are meant for layman consumers, not those who upgrade their machines periodically, you would find that a number of people are fine with using Windows XP and see no reason to upgrade to a newer Operating System. So, if your user base is comprised of such types of users, then dropping support for XP would mean that you no longer want business from such users. Further for people who on XP and have a previous version of your software, it means that you are no longer offering a path to buy a newer version, and they may end up using a software that is from a rival and you would have lost a customer.
So what are some of the other variables involved in decision making and how do you finally make a decision ?

Read the next post in this series (Selecting the supported Operating Systems - Part 2).

How to perform Cross platform testing and Cross browser testing using QTP?

Two types of particular testings can be performed easily using the quick test professional and they are mentioned below:

1. Cross platform testing and
2. Cross browser testing

What is meant by cross platform?

Cross platform can be defined as an attribute that can be given to a software system or application that can be operated across multiple computer platforms. Today there are two types of cross platform softwares available as mentioned below:

1. Softwares that require individual compilation for each platform that is supported by them and
2. Softwares that require no individual compilation and can be run directly on any platform that they support.

For a software system or application to be entitled as cross platform software it is required that it operates successfully on both the following:

   1. More than one operating system and

   2. Computer architecture.

- Checking a software whether or not it is cross platform compatible is a time consuming activity since all the different operating systems come with a different API or application programming interface. 

- Whenever a software system or application is designed as such that it can support multiple platforms, the demand for its quality assurance increases dramatically. 

- For ensuring this quality the cross platform testing is carried out.

What is meant by cross browser?

- Cross browser is an attribute for web sites, web applications, client side scripts and HTML constructs which are able to perform well in the environments or browsers which have the required features and also in the browsers and environments which lack those features. 

- Today, there are many browsers available and all of them are used by the end users for accessing the same web site or web application. 

- Therefore, it has become equally important that the web site or web application must be able to function properly on all web browsers. 

- This is ensured only by carrying out the cross browser testing.

- Also, the same request made on a web site or web application is handled differently by different browsers.

- Cross browser testing not just tests the client side of the web application but it also tests the server side behavior of the web site or application. 

- Therefore, there are two types of cross browser testing:

1. Server side cross browser testing
2. Client side cross browser testing

Now coming to how the cross platform testing and cross browser testing is performed using quick test professional. For performing these two types of testing in quick test professional you need to create separate actions for operating systems as well as browsers. 

How Cross Platform Testing is performed in QTP

- The cross platform testing can be facilitated with the help of built-in environment variable in quick test professional since using it one can dig up the information of the operating system. 

- Later, the actions recorded on this particular platform can be called. 

- On the other hand, using the actions created for the browsers you can extract the browser information. 

- The actions that are relevant to that particular browser should only be called. 

How Cross Browser Testing is performed in QTP?

Before beginning with the cross browser testing you need to get the type of browser that you are using by following an example mentioned below:

Browser( “core values”)

For getting a particular version of a browser,

getROproperty( “version” )

- Any dynamic browser changes are not allowed in quick test professional while the scripts are in running mode. 

- These scripts need to be configured for the current browser. 

- Also, you should set up the driver scripts in the beginning itself so that you can easily change your configuration settings whenever required. 

What are some common tools for installation testing?

Introducing a new student to the rest of the class gives us a practical example of the installation testing. The new student should be properly introduced to the rest of the class so that he/ she feel comfortable. Same holds true for software systems and applications. The effectiveness of any testing however also depends up on the type of the testing tools used. In this article we shall be discussing about some common tools for installation testing. 

If the installation of your software product fails, what impression it will make of you on the customer? Obviously it will cost you your reputation. How can you avoid such pathetic and embarrassing conditions? "Answer is by testing the software system’s or application’s installer with an appropriate combination of both the automated and manual processes on different machines and with different configurations". 

The factor of which you should be most concerned is nothing but “time” since installation testing eats up a lot of time, so you got to be wise and use testing tools that can save up your time. Execution of even a single test case takes a lot of time in installation testing. Now imagine if you are going to perform installation testing on a big software system or application? How much it is going to cost you? Before you start installation testing you need to decide on how many systems and configurations you are going to install the application software. Prepare a basic hard disk drive for this purpose with some other basic necessary components.

Role of Installation Testing Tools

- There are testing tools available that will help you in making sets of each of the configurations like file format and operating system that are used in the further installation testing.

- There are many other tools that can be used to automate the whole installation testing process.

- This involves setting out some systems for creating basic images of the base configuration. This can be done by using testing tools like Norton ghost which can create exact image of the operating systems very accurately and quickly.

- This step is guaranteed to save a huge amount of your time for each test case.

- Creating images takes only 5- 10 minutes whereas installing one Operating System with basic configuration takes up to one hour.

- There are some other tools that allow you to use one operating system with multiple attempts of installation.

- But in this case you will need to uninstall the application again and again and prepare the base state for the next installation.

- Apart from all the other testing tools, use flow diagrams also serve as a great aid for performing the installation testing.

- Use flow diagrams simplify the whole task so amicably.

- These flow diagrams can be further used for automating the test efforts since very easily these diagrams can be converted in to the automated scripts.

- Some test tools have been developed that test the installer scripts which are further used to check the disk space required for the installation.

- These tools make sure that only the required amount of space is utilized and not more than that otherwise an error is flagged. You should be careful with the fact that the space required is different for different file system formats.

- Another tool that can help you a big deal with installation testing is “distributed testing environment”.

- Adopting this methodology you can very effectively handle all the different test cases from just one machine and it saves you a lot of time.  

Explain the concepts of Directory traversal attacks?

Another name for directory traversal attack is path traversal attack and there is quite unfamiliarity among people regarding this security threat. We have dedicated this entire article to make you aware of this security threat.

What is meant by Directory Traversal Attacks?

- Directory traversal attacks involve the exploitation of the insufficient sanitization or validation of the security regarding the input data supplied by the end user.
- This results in the passing of the characters representing the traverse to parent directory to the API files.
- The directory traversal attacks are aimed at accessing a computer file that is not intended to be accessible by ordering an application to do so.
- The application acts to the commands of the attacker.
- Here, in such situations there is no fault in the program code and it works perfectly fine but, it lacks in security and that is what that is taken advantage of by the attackers.
- He/ she takes an advantage of the lack of the security of the software system or application.
- This is completely opposite to the exploitation of the bugs of a code.
- Some times directory traversal attacks are also denoted as the “_ _ / attack” (pronounced as dot dot slash attack).
- One common form of such attacks is the canonicalization attacks.
- Some other rare forms are back tracking and directory climbing etc.
- In every operating system there exists a common file that is often used by the hackers to crack the passwords.
- In some operating systems like UNIX, no such password file exists.
- Rather the passwords are stored in some shadow file which is not accessible to the users that are recognized as the unprivileged by the machine. - Password  files are useful in another way also i.e., for enumeration of the accounts on that particular machine and displays whatever are the user accounts present on the system.
- Many variations are observed in the directory traversal attacks based on the directory traversal attack strings used in different operating systems.
- Directory traversal attacks create quite a menace these days which becomes quite difficult to manage.

How to prevent directory traversal attacks?

Software engineers have formulated an algorithm for the prevention of directory traversal attacks which is like this:
- Process URI requests such that they do not invoke any file request. For example, execution of a hook in to the code.
-  Always specify the full path to the directory or file if any exists while normalizing all the characters whenever you have to process a URI request. For example, normalize %20 to spaces.
-  Assume the length of the string to be N and a normalized path exists for a document root that is fully qualified and that no files outside this are accessible.
-  Ensure that the first n characters of the string match exactly with the document root of the requested file.
-  If the above condition proves to be true allow the file to be served.
-  If the above condition is proved false, an error should be returned since the requested file is inaccessible.

An efficient control over the accessing of the web content is highly required for the effective running of the web server in a secure mode. Mostly the web servers employ either of the two security mechanisms listed below: 

1. Root directory:
This directory keeps the users bounded to the specific limits outside which nothing can be accessed. It is created in order to avoid the unauthorized access of the files containing sensitive data by unprivileged users.
2. Access control lists (ACLs): 
These lists find their use in the process of authorization.  The lists contain the information of the users who can legally access the files.

What is meant by debugging legacy code?

Debugging of the legacy code is an extremely important concept in the field of the software systems development. But, before we discuss about debugging the legacy code, we will first discuss about the legacy code.

Legacy code is not different from a normal source. It is also a type of source code that can be related to the following:
1. No longer supported manufactured operating system or,
2. No longer supported computer technology etc.

What is meant by Legacy Code

- Legacy code is also used in the modern versions of the operating systems and software applications wherever old features of the corresponding software applications are required to be included and maintained.

- Legacy code is required for giving support to serial interface even though the serial port is absent in many of the modern computer systems.

- It may also be needed to provide support to the older formats of the files like EBCDIC that requires encoding in the non- ASCII characters.

- This is a known fact and almost each and every one is familiar with it that most of source codes are dependent up on the platforms for which they have been designed.

- This fact proves that even if an environment or platform independent language is used, it is difficult to design, develop and execute a program that works independently of its environment and platform.

- It is also observed in some of the cases that whenever the platform for a software system, application or a program is changed (such as moving to a new operating system), the code present in the program does not work well without making appropriate changes to it and this is the code that is called the “legacy code”.

- In such situations alteration of the code becomes necessary and it is also a hectic task for the programmer or developer since this is required to prevent the code becoming a legacy code.

- The term legacy code also holds good for the source code that is not able to execute on a modern version of a software system, application or program and thus calls for a need of a compatibility layer to run.

- The best example for this would be a classic Macintosh application that runs in the classic environment but not in the Mac OS X.

Debugging of Legacy Code

- So many researchers have put forward their thoughts regarding the debugging of the legacy code.

- Legacy code has been interpreted as a source code without tests and reflecting its perspective of facing difficulty due to an absence of the automated regression tests.

- Michael feather defined some characterization tests for testing the legacy codes.

- Macro definitions of C and C++ languages have been defined as evil since they introduce subtle bugs and thus make the maintenance of the program difficult.

- One can face many difficulties in detecting the legacy code before the program crashes several times.

- When the external conditions are changed, it is required that the changes are also made accordingly.

- Since the environment is ever changing, one cannot expect the code to remain static as ever.

- The code also has to be evolved and replaced.

- Debugging is required for the legacy codes that are in production since this is the only way that can assure you that the changes you made to one part of the program are not affecting the other parts of the program.

- It is another problem that you might not be having sufficient budget and time to provide 100 percent coverage to the legacy code.

- But debugging of the legacy code produces robust code and speeds up the development process and also helps with a reduction of the risk of failure of the system.

How is testing done on different smart phones?

The word smart phone is all around us these days! Smart phones are on the verge of becoming the devices with the highest demand.

But what it is that makes a smart phone quite different from an ordinary feature both in performance and appearance? What is its smartness quotient?

To put it simple, we can say that:

- A smart phone apart from just making and receiving calls, grants one extravagant usability by means of many other features like listen to songs, send and receive e mails and edit the documents and so on.

- A smart phone has been made by putting together the features of both the mobile phones and PDAs (personal digital assistance).

- Features of cell phones like making calls and sending messages and PDAs features like organizer, calendar, alarm clock, portable media player etc are all incorporated in to a single device now popularly known as the “smart phone”.

- The smart phones can even be synced with one’s computer system.

- Eventually the smart phones achieved the capabilities like greater and better connectivity, web browsing, using third party applications and so on.

- Other advanced features include:
1. Pocket video Camera
2. Portable media players
3. Compact digital cameras
4. GPS navigation units

- The recent smart phones have web browsers pre- installed in them so as to facilitate the web browsing and accessing other web applications.

- The super a moled screens are now used instead of the earlier LCD displays.

- These smart phones very well support the standard web pages in their original form rather than optimizing them to be viewed through a phone like old feature phones.

How is testing on smart phones done?

- Smart phones also undergo rigorous testing to ensure that they are up to the standards and specifications.

- One way is to check the smart phone against a list of key features that must be in a cell phone for it to be a smart phone:

1. The Operating System

- A smart phone is always operated via an operating system rather than a proprietary firm ware as in the case of ordinary feature phones.

- Many of the smart phones make use of the following operating systems like iOS from Apple, Android from Google, Microsoft windows phones, Symbian from nokia, RIMS’s blackberry OS, Embedded Linux like MeeGo and Maemo etc.

- The above mentioned operating systems can be installed on different models.

- One is able to run third party applications on a smart phone only because the operating system of the smart phone is capable of integrating with the hardware of the phone.

- Likewise it also gains a third party support for the better functioning of its features.

2. Applications
- Even the ordinary feature phones include some sort of applications like address book, contact manager etc, but a smart phone serves even more.

- It includes applications for viewing and editing the Microsoft documents, download third party applications that serve other purposes.

3. Web access
- They have the capability of accessing the internet at high speeds via the advanced technologies of 3G and 4G and of course Wi- Fi!

4. Qwerty keypad
- Smart phone does includes qwerty key pad unlike the keypad of ordinary feature phones which have alphabetical order on top of a numeric keypad.

- It can be made available either through hardware or via the touch screens.

- Smart phones come in a whole lot of variety, in this case the performance and features of the models widely differ.

A smart phone is tested by testing its:

1. Usability: It involves the evaluation of the:
a) Menu navigation
b) Durability
c) Ease of use
d) Key pad layout
e) Software design
f) Screen resolution
g) Ergonomics

2. Call Quality: This involves the evaluation of the:
a) Ease of making and receiving calls
b) Managing contacts
c) Sound quality
d) Clarity of the reception
e) Messaging

3. Battery life: This involves the evaluation of the:
a) Talk time
b) Mp3 playback time

What are different features of smart phones?

Smart phones are now becoming a much in demand essential commodity for this third generation world. The demand for the smart phones has been increasing rapidly since the advent of much advanced and sophisticated technology.

One should be well versed with the current technologies in this tech savvy world and so we have this dedicated entirely to the discussion regarding smart phones.

Features of Smart Phones

- A smart phone is also like a mobile phone, but then what makes it different? Of course it’s so called smart features!

- A smart phone like any other phone is built up on a mobile computing platform but having more capabilities, abilities and connectivity when compared with their ordinary mobile counterparts.

- Today’s smart phones much like the earlier smart phones are incorporated with all the functions of a PDA (personal digital assistant), a camera as well as mobile phones or feature phones.

- But today’s technology has advanced so much so as to build smart phones that have functions of portable media players, pocket video cameras, compact digital cameras, GPS navigation units and so on incorporated in to them.

- The modern i.e., to say the recent smart phones come with more typical features like web browsers and super amoled touch screens which make the accessing of the web much easier than the ordinary feature phones on which only those web sites or pages can be viewed that have been optimized for the mobile phones.

- These smart phones are very much capable of displaying and accessing the standard web pages developed even with a very high resolution.

- Mobile broadband and wi- fi have also been incorporated in to these smart devices to provide them the ability of accessing data at high speeds.

- Many of the smart phones make use of the following operating systems:
1. iOS from Apple
2. Android from Google
3. Microsoft windows phones
4. Symbian from nokia
5. RIMS’s blackberry OS
6. Embedded Linux like MeeGo and Maemo etc

- The smart phones are designed in such a way that any OS can be installed on different models as well as one device is capable of receiving updates of more than one OS software all during its life time.

Difference between Feature phones and Smart phones

- Till now no official definition has been given regarding the difference between the feature phones and the smart phones.

- But, one point of significance is that the advance APIs or application programming interfaces for smart phones can run the third party applications with better integration with the operating system of the phone and its hardware.

- This much integration is not seen in ordinary feature phones.

- The feature phones in contrast to the smart phones make use of the proprietary firmware.

- A third party support is provided to these phones through platforms like BREW or Java ME and so on.

Features of first Smart Phone

- The first smart phone that was introduced was the IBM simon which was introduced in the year 1992. It had the following features:

1. Address book
2. Calendar
3. World clock
4. Note pad
5. Calculator
6. E- mail client
7. Fax and email features
8. Games

- It made use of a touch screen and stylus like modern smart phones.

- It lacked the ability to download third party applications as well as camera.

- However, that phone was highly sophisticated when compared to the other devices of that time.

Features of Nokia Communicator

- After that the nokia introduced its first smart phone range called “Nokia Communicator” releasing Nokia 9000 first in the range.

- The phone in this series had a clam shell like design with a QWERTY keyboard and a display with high resolution of 640 x 200 mega pixels.

- The screen sizes for the smart phones lie between 2 to 4 inches when measured diagonally.

- Some even come with a screen size of 5 inches but, this some what reduces the usability of the phone.

What are different compatibility and intersystem defects?

WHAT IS MEANT BY SOFTWARE COMPATIBILITY?

- Software compatibility is usually described as the compatibility of a software system or application to run without any problems on any major platform.
- It means that the software system or application is compatible with the major platforms and CPU architectures such as Intel or mercury etc.
- It also refers to the compatibility of a software system with different operating systems.
- It is very difficult to develop software that is compatible with many CPU architectures since during the compilation of such a system it shows different errors for the different CPU architectures.
- But such compatible application software do exist.
- The applications are developed and compiled for the various CPU architectures and these are then made compatible to with the various different CPU architectures via the operating systems.

WHAT IS INTERPRETED SOFTWARE?
- In contrast to the compiled software, the interpreted software does not show the above drawback.
- They are very well capable of running on multiple CPU architectures.
- But here one condition has to be fulfilled i.e., the interpreter should be available for that particular type of the CPU architecture.

Software incompatibility is more frequent among the newer software versions developed for the new versions of the operating system which is found to be incompatible with the older version of that software system or application version due to a lack of some features and functionalities.

The newer versions of a software system or application that are able to work with the older versions of the operating systems are said to possess the capability of the backward compatibility.

Compatibility testing is usually carried out to test the operational environment of a software application or program. The software system or application is checked for its suitability i.e., whether or not the application will be able to perform in that environment or not.

DIFFERENT COMPATIBILITY & INTER-SYSTEM DEFECTS
Defects affecting the compatibility of a software system or application are commonly called as compatibility and inter-system defects. These are:

DEFECT #1:
After completing the installation of the application software, the user executes that application and observes that he/she is not able to access some features and functionalities and also not able to view any pictures images, icons or data.

DEFECT #2:
Some browsers may show java script errors with applications developed in java language.

DEFECT #3:
Inconsistency is observed in some elements of a web application or a web site when viewed through different browsers.

DEFECT #4:
The software program is observed to behave differently on different browsers.

DEFECT #5:
Inter-system defects like corruption of data in an NFS mounted file. Usually data is not corrupted in an NFS system.

DEFECT #6:
- In some cases, an unauthorized user is very well able to access the control to a system which uses the LDAP methodology for the authentication purpose.
- This inter-system defect is common in ensemble, UNIX clients and VMS employing LDAP authentication system, windows clients and cache file versions.

DEFECT #7:
- Encryption of data base in VMS clusters.
- In such a defect the system usually becomes inactive and does not respond.
- Like the above mentioned defect, this defect also exists in ensemble versions. - This defect usually occurs when the data base is forced to shut down without the cache being closed.

DEFECT #8:
Failure of cluster mounted data bases.

DEFECT #9:
- Defect making the application server unresponsive.
- This defect is usually encountered when there is too much ECP traffic on the application or web site.
- This defect can affect all platforms.

DEFECT #10:
- Memory defects like core dumps which are generated during the start up of the cache.
- Because of this defect in some cases the start up can fail completely.

DEFECT #11:
Speed reduction in cache making it unresponsive. This defect occurs mainly when the amount of shared memory exceeds a specified limit.

What are different characteristics of compatibility testing?

First let us clear up with the concept of compatibility.

Compatibility of a software system or an application or any hardware system or components can be defined as the ability of that software system or hardware component to work efficiently with all the versions either newer or older of all CPU architecture designs and operating systems.

- Compatibility is one of the most important properties of any software system or application and hardware system.
- Not every where, every one uses the same CPU architecture designs and operating systems.
- Therefore, it becomes necessary to make software and hardware compatible will all sorts of systems available.
- Otherwise, the software or the hardware will remain confined to only one CPU architecture and operating system.
- There will be no benefit to the software and hardware developers who developed that software or hardware.

In other words, the software or the hardware product or artifact get promotion and hence it would not be widely accepted.
Keeping in view all these issues, care is taken to provide maximum compatibility to the software or the hardware system. Before its release to the open public, the software or the hardware product needs to undergo testing for determining its compatibility.
Such testing is called compatibility testing.

- Compatibility is categorized under non functional testings.
- Compatibility testing can be defined as the testing that is conducted on the software application or the hardware component to determine the concerned product’s compatibility with the computing technological environment.

A proper computing technological environment contains all of the below mentioned aspects:

- Bandwidth handling capacity: the environment should be able to handle bandwidth of the networking software and hardware.
- It should have a computing capacity of hardware platform like HP 9000 and IBM 360 etc.
- It should be compatible with all kinds of peripherals. In other words, it should have compatibility of peripherals. Peripherals include DVD drive, printers, monitors, speakers and so on.
- It should be compatible with all operating systems including UNIX, MVS, windows and so on.
- It should support all types of data bases like oracle, DB2, Sybase etc.
- It should be well compatible with other software systems like messaging tools, networking systems and web servers.
- It should be browser compatible. It should support all the available browsers till date like Netscape, internet explorer, Firefox, Google chrome, safari etc.

The above aspects together make up a proper and efficient computing environment to carry out compatibility testing for the software and hardware products.

Compatibility testing comprises many other small testings like peripheral compatibility testing, browser compatibility testing etc. browser compatibility testing is also known as user experience testing.
It involves the checking of web and network applications on all the available different browsers.

It is done to ensure the following:
- The application under testing should respond exactly in the same way with all the different browsers. It should exhibit same features and functionalities when run under different browsers.
- The visual experience for the users must be the same irrespective through which browser they are using the web application.
- The applications should be backwards compatible i.e., it should work with the older versions of the browser as well.
- The applications should be carrier compatible i.e., data transformation should be same no matter which carrier is being used. Some famous carriers include orange, sprint, Verizon, Airtel, O2 etc.
- Apart from software compatibility, the application should be hardware compatible.
- The applications should be compiler compatible i.e., there should be no difference in compilation by different compilers. All the compilers should compile the source code correctly.
- The applications should be able to run on emulators.