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.
Causes
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.
Cures
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.