TMurgent Technologies

Destination for Application Virtualization

Application Adaptation

From the TMurgent dictionary...
Application Adaptation
1. The art of adapting software that was written to run in one environment to perform effectively in another through the use of "work-arounds".
2. Modifying an application at the source code level to extend functionality or deployability.
3. Modifying an application at the binary level to customize or deploy.

The big problem with software applications in the server environment is that we use it differently than the developer intended.  It might old, legacy, applications.  It might be desktop apps.  They just don't work as well and worse -- they behave badly and interfere with everything else running on the server - especially Terminal Servers.


Problem Application behavior usually falls into one (or more) of the following categories:

  • Outmoded development methodology.  The PC development methodologies of the 1980's and early 1990's do not work well in today's computing environments.  Because the computers were slower, and more importantly we expected the PC to only do one thing at a time, it was OK for an application to consume all available CPU to give the user the best performance.  We adapt these applications by controlling CPU usage.
  • Multi-instance issues.  Sometimes the developer didn't consider that more than one copy might run at the same time.  This might lead to either Multi-instance or Multi-User issues.  Multi-instance issues occur when the developer depends upon a single entity on the computer - perhaps a file it writes to or a communication port.  We adapt these applications by intercepting the interface to that single entity and redirecting it.
  • Multi-user issues.  Multi-user issues appear when the developer uses the HKEY_LOCAL_MACHINE registry hive when HKEY_CURRENT_USER is appropriate.  We often adapt these applications by using a product like SoftGrid/App-V.
  • Affects shared components.  Microsoft calls it "dll hell". Administrators usually aren't as nice.  The problem here is not usually the developer, but the one lowly intern assigned to write the installer.  Typically poorly trained and asked to build the installer at the last second, mistakes are made that cause the installer to break existing applications by overwriting dll files used by other applications.  We adapt these applications either by correcting the installer, devising workarounds for co-existence, or isolating the application.
  • Bugs.  Hey, they happen.  Sometimes we can modify the behavior without access to the source code.


Approaches to solve the problem.
Application Analysis.
We can perform an analysis of the binary application. Starting with the binary packaged product, we analyze all changes made by the product during installation and at runtime.
From this "fingerprint" we can determine where the problem areas lie. Then we can devise remediation steps to work around these problems or provide development advice or assist the ISV to make changes in a future release so as to avoid these problems.
Binary Modification
We can sometimes alter application behavior by modifying the binary product. Common approaches include removing unwanted functionality by removing menu items.