There are a number of problems that arise from the way that software code files are conventionally handled; for example:
software is normally distributed as files of monolithic machine code such as executables(.exe) or dynamic link libraries(.dll) on Windows PCs (all the various types of hosts have similar file types). Any changes to the distributed code files can only be made by replacing one or more in their entirety and this can often involve downloading multiple megabytes of code.
in order for an application to function as designed, all the code files need to be present on the host machine in the correct versions. Although the Windows libraries are named 'dynamic link' no actual linkage information exists, the code in one file simple calls a particular entry point in another file and 'hopes' that the correct function with the correct specification exists at that entry. If it does not then it is likely to cause an exception and the lack of information in the code files means that the operating system is unable to explain what the problem is in meaningful terms.
if the application has a bug which causes a run-time exception to occur (such as an illegal memory access), then again an exception will occur which again cannot be usefully explained by the operating system.
there is no meaningful and reliable traceability from a code file back to the application and/or its designer/owner. Existing operating systems simply work on the filename and file type as they have done for almost 50 years. When a user starts an application then the operating system finds an executable of the correct name and essentially leaps into it as a blind act of faith. Simply renaming any existing file with the name of the executable can disrupt this process and cripple the application on the machine. Such a thing would normally only happen maliciously but it does indicate the almost total lack of information available to the operating system to keep the installation secure and to assist the users when something goes wrong.
Such situations are not compatible with the concept of adaptable applications.
In the case of Adapt then when a user is given access to an application all the information (the Total Design Knowledge) is potentially available to the user and this enables a much higher level of service to be provided. For example, when an error occurs then it is possible to provide much more meaningful help to the user.
Several types of error that can affect conventional applications (such as memory corruption) will not occur with Adapt as with the advantage of Total Design Knowledge many mistakes can be detected at the design stage, or simply may be unable to be entered. However, some errors can still be detected at run-time and when these occur then all details and their logical location can be shown in terms that make sense to the designer.
The availability of Total Design Knowledge also allows:
the application to provide help and guidance to users by explaining how to operate it;
the user to examine the application's data paths and algorithms*;
the possibility of better integration with other applications*;
users to make local adaptions to the applications*;
local adaptions to be propagated to other installations* as required.
(* assuming the user has permission to do so)
Code Storage within Adapt
As explained in Architecture all information is held in dAtas within Universal Storage and all the logic is defined in the Logics dAta. Before any logic can be actioned then the appropriate machine code portion for the target host is generated for each operation within the logic. The code portions are stored in the corresponding Codes dAta.
All the code that implements an application exists as separate code portions in the Code dAtas. Physically this means they are held in lists across a number of memory blocks. Should the designer make changes to the application logic then only the code for the relevant logic operations needs to be re-generated.
When an application is executing then, as the code is divided into many separate portions, only those that are currently in use have to be in local memory. When an application starts to execute one code block with be initially read to memory and others will subsequently be read as required depending upon the execution path(s). This means that only the bits of code needed for a specific task will be brought to local memory and code designed for other tasks or less common cases may not be.
This approach contrasts with conventional software where all the code in an executable file is read to memory in one lump even though much of it may not be needed in that particular situation. This is especially significant if the application is held in the cloud as it can start to execute having read just a few blocks rather than many megabytes.
True Dynamic Linking
The code portions read to memory are unlinked; i.e. they can include calls to other logics or may need to branch to one of several optional other portions. The actual memory addresses for the links cannot be known when the code portions are generated so where a call or a jump instruction is required before the code can execute properly, software interrupt instructions are generated instead. The relevant logic number and code portion numbers follow the interrupt instructions.
When such a code portion executes and a software interrupt occurs Adapt uses the logic and code portion numbers to resolve the actual address and then replaces the interrupt instruction with the appropriate call or jump. Subsequent executions of that code path will proceed uninterrupted as the links have already been established.
This technique contrasts with the conventional approach in which each executable file has all the links established by the linker. This has the initial benefit of simplicity at run-time but has a large cost in that it cannot subsequently be changed or adapted in any way. Additionally, it means that large amounts of code must be downloaded/read to memory which in many situations will not be executed.