Browse Prior Art Database

Operating system libraries management – multi-layer model

IP.com Disclosure Number: IPCOM000234180D
Publication Date: 2014-Jan-16
Document File: 4 page(s) / 76K

Publishing Venue

The IP.com Prior Art Database

Abstract

There are a number of issues related to conflicting or missing packages that are required to install and operate an application on a certain type of operating systems before the installation. That is sometimes a show stopper to proceed with successful installation. Those required libraries most often are given as a requirement before the installation. And prerequisites checkers are not always successful to discover them during the preinstallation phase.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 39% of the total text.

Page 01 of 4

Operating system libraries management - multi -layer model


There are a number of issues related to conflicting or missing packages that are required to

install and operate an application on a certain type of operating systems before the installation. That is sometimes a show stopper to proceed with successful installation. Those required libraries most often are given as a requirement before the installation. And prerequisites checkers are not always successful to discover them during the pre-installation phase.

Another type of problem is caused by the update in the certain required package. For instance, due to change on a function within a library that is included by the operating system media causes post-installation issues although application appears to complete successfully. That causes malfunction of the installed application. And it creates an extra burden for Application Administrators to figure out this issue. That requires more often removing the installation by down-grading the package and reinstalling the application again to achieve running error-free application

Example: Application A gives an error "The procedure entry point could not be located in the dynamic library filename.dll" when it is installed after Application B

This is a generally problem with shared libraries. The issue is that a dependent DLL (filename.dll) as in this example has been found in the search path from another directory. But is actually a different version and does not meet the requirements for Application A . Operating system searches for DLLs (Dynamic Link Libraries) using the file name. And when it finds a match,Operating system loads it. If this loaded DLL does not have an expected entry point then it returns the following message "The procedure entry point could not be located in the dynamic library filename.dl". There are certain workarounds for that as written below.


1. Using DLL(Dynamic Link Library) redirection

The "Dll redirection" mechanism was introduced in some non-linux operating systems . For an application abc.exe, if there is a file abc.exe.local exists, Operating system(OS) will first look at abc.exe's application directory, before start the regular dll search. To mitigate the COM problem, the redirection applies both to full path dll loading, as well as partial name loading.


2. Using an intermediate batch script that modifies the PATH environment variable before running the control versioning (application) tools

set PATH =

;%PATH%

That will allow rearranging the paths to be at the front of the search path. If you open a command prompt, and then use this batch script to setup the correct environment.


3. Using some of the path statements into the local user settings, and then switch between users to run the different applications.

What we want to protect with following disclosure is:

moving responsibility of delivering required libraries versions to operating system instead of particular application.


creating and maintaini...