Usage of mmio* function set of MMOS/2: Difference between revisions
No edit summary |
No edit summary |
||
Line 11: | Line 11: | ||
Format IOProc actually transforms corrseponding file format to common MMOS/2 format and vice versa. | Format IOProc actually transforms corrseponding file format to common MMOS/2 format and vice versa. | ||
Actually, IOProcs can call each other. For example, PNG IOProc uses CF IOProc to read PNG data from compound file. CF IOProc uses HTTP IO Proc to read compound file from HTTP stream. And HTTP IOProc uses TCP IOProc to read HTTP stream via TCP protocol. So, to read PNG data byte-stream comes via four I/O procedures. | |||
TCP->HTTP->CF->PNG[->Bitmap] | |||
== Codecs == | |||
Exist special type of IO Procedures named "codec". Codec procedure can COde (compress/encrypt/etc.) and/or DECode (uncompress/decrypt/etc.) byte-stream. To continue above example lets add codec to chain: | |||
TCP->HTTP->CF->PNG[->Bitmap] | |||
^ | |||
v | |||
Z Codec | |||
In this example PNG IO Procedure reads PNG data and moves corresponding data array to Z codec which decompress data and returns to PNG IOProc. | |||
Logic of above solutions is easy: reuse code. Different IOProcs can use common codecs and read byte-stream from different places. | |||
== Usage == | == Usage == | ||
From user (application level) point of view no difference which file you loading. Is it GIF, PNG, JPEG, BMP or something other. | From user (application level) point of view no difference which file you loading. Is it GIF, PNG, JPEG, BMP or something other. It is work of IOProc subsystem of MMOS/2 to handle corresponding format. So, user has two tasks | ||
# Read image | # Read image | ||
# Store image | # Store image | ||
=== Reading image === | |||
Image reading is easy thing. Let's try to read image, create bitmap and display it. | |||
=== Storing image === | |||
Now let's try reverse method: storing. Lets create image from resource, get data from bitmap and store data. | |||
== Creating new procedure == | == Creating new procedure == | ||
=== I/O Procedure templates === |
Revision as of 14:13, 8 July 2005
by Prokushev
I/O Procedures
I/O Procedures (IOProc in short) are set of DLLs which provides MMOS/2 access to format/file data. IOProc handles all I/O tasks:
- Storage access (Storage IOProc)
- Format handling (Format IOProc)
Storage IOProc is lowest level of IOProc hierarhy.
Format IOProc actually transforms corrseponding file format to common MMOS/2 format and vice versa.
Actually, IOProcs can call each other. For example, PNG IOProc uses CF IOProc to read PNG data from compound file. CF IOProc uses HTTP IO Proc to read compound file from HTTP stream. And HTTP IOProc uses TCP IOProc to read HTTP stream via TCP protocol. So, to read PNG data byte-stream comes via four I/O procedures.
TCP->HTTP->CF->PNG[->Bitmap]
Codecs
Exist special type of IO Procedures named "codec". Codec procedure can COde (compress/encrypt/etc.) and/or DECode (uncompress/decrypt/etc.) byte-stream. To continue above example lets add codec to chain:
TCP->HTTP->CF->PNG[->Bitmap] ^ v Z Codec
In this example PNG IO Procedure reads PNG data and moves corresponding data array to Z codec which decompress data and returns to PNG IOProc.
Logic of above solutions is easy: reuse code. Different IOProcs can use common codecs and read byte-stream from different places.
Usage
From user (application level) point of view no difference which file you loading. Is it GIF, PNG, JPEG, BMP or something other. It is work of IOProc subsystem of MMOS/2 to handle corresponding format. So, user has two tasks
- Read image
- Store image
Reading image
Image reading is easy thing. Let's try to read image, create bitmap and display it.
Storing image
Now let's try reverse method: storing. Lets create image from resource, get data from bitmap and store data.