VM Cells

Parent Previous Next

VM Cells.

Each VM has a public storage space named VM cells. This storage is defined as a two-dimensional grid with rows and columns of data cells. It works very much like a spreadsheet where each cell can either be empty or contain a value:


COLUMNS

-1

0

1

2

ROWS






-1






0



123

"My string"

0x12FF4E

1



456

"And yours"

0x3355EF

2


"Hello"

"How"

"Are"

"You"


Cells provide a flexible method for the transport of data from the host to the VM, or from one VM to another, before calling the Main function, and the results of the execution can be placed in cells as well to be returned to the calling VM or host application. Cells can contain integer, string or blob values.


Rows and columns are 32 bit integers providing an index range of 232 x 232 (also having negative indexes).


Please notice the possibilities for using the cells as data records, however each cell is completely independent of the others.


Internal and External Access.

The cells of a VM are public and can be accessed both internally and externally.


Internal access is done from within the running bytecode using the library functions found in the group Interface Current VM.


External access is done from either the host using the DLL API or from another VM. When one VM access the cells of another VM, the @VMCellxxxx library functions of the group Interface Other VMs are used. The DLL API provide similar capabilities.


Cells and Security.

VM cells are not encrypted. Given the fact that the host application is open to a cracker - and that the primary purpose of VM cells is to transport data between the host application and the VM in the DLL - it is not relevant to encrypt cells.


In case sensitive data must be transported internally from one VM to another, it is recommended to convert the data to blob variables and implement some sort of binary encryption in bytecode, before transporting the blobs in cells using the library function @VMCellSetBytes and others.