en:docs:os2:api:vio

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
en:docs:os2:api:vio [2021/09/14 05:51] – prokusheven:docs:os2:api:vio [2021/09/14 09:51] (current) – prokushev
Line 1: Line 1:
 {{page>en:templates:fapiint}} {{page>en:templates:fapiint}}
  
-OS/2 Video Subsystem (VIO in short) aimed to provide text-mode and graphics-mode (full screen sessions only) video output. Original VIO supports 43 functions which mostly improvement of Video BIOS INT 10H API. Functions are much richer comparing to Video BIOS. It is supports Logical Video Buffer, which allow to have output in background sessions, while screen no accesable. Temporary video session allow to build message notifications system to handle errors and exceptions. Most of functions (41 function) can be replaced by user-defined functions by Alternate Video System. Alternate Video System can hanlde function and then return to caller or pass control lower, to Base Video System. You can register not all but some Alternate Video Subsystem functions, and user Base Video Subsystem for othe functions. Some VIO functions supported in Dual-mode applications by Family API. Under DOS functions simplier but powerfull yes. Many command line tools are Dual Mode applications, as well as many MS-DOS base Microsoft products also dual-mode applications. VIO also provide limited set of graphic mode support. VIO originalli is 16-bit and implemented starting from fist version of OS/2.+====== OS/2 Video Subsystem ======
  
-====== Video Subsystem ======+===== Family API (OS/2 mode) ===== 
 + 
 +OS/2 Video Subsystem (VIO in short) aimed to provide text-mode and graphics-mode (full screen sessions only) video output. Original VIO supports 43 functions which mostly improvement of Video BIOS INT 10H API. Functions are much richer comparing to Video BIOS. It is supports Logical Video Buffer, which allow to have output in background sessions, while screen no accesable. Temporary video session allow to build message notifications system to handle errors and exceptions. Most of functions (41 function) can be replaced by user-defined functions by Alternate Video System. Alternate Video System can hanlde function and then return to caller or pass control lower, to Base Video System. You can register not all but some Alternate Video Subsystem functions, and user Base Video Subsystem for othe functions. Some VIO functions supported in Dual-mode applications by Family API. Under DOS functions simplier but powerfull yes. Many command line tools are Dual Mode applications, as well as many MS-DOS base Microsoft products also dual-mode applications. VIO also provides limited set of graphic mode support. VIO originalli is 16-bit and implemented starting from fist version of OS/2.
  
 <diagram> <diagram>
Line 21: Line 23:
 OS/2 Video subsystem placed in VIOCALLS.DLL. Called VIO function passes control to internal VIO router function which, depends on registered functions replacement, routes call to Base Video Subsystem (BVSCALLS.DLL) or to registered Alternate Video Subsystem. OS/2 Video subsystem placed in VIOCALLS.DLL. Called VIO function passes control to internal VIO router function which, depends on registered functions replacement, routes call to Base Video Subsystem (BVSCALLS.DLL) or to registered Alternate Video Subsystem.
  
-Such route in original OS/2 1.x serie. OS/2 1.2 includes additional functionality. Base Video Subsystem now uses Base Video Handlers ro access hardvare. Also Global Video Sybsystem hook was added. Base Vide Handler is a sort of video hardware abstraction layer. Global Video Subsystem allow to add notification hooks after VioRoute call.+In pseudo code it looks like this 
 + 
 +<code> 
 +Application calls VioGetAnsi in VIOCALLS 
 +VioGetAnsi calls VioRoute 
 +if AVS registered then 
 +  VioRoute calls AVS VioGetAnsi 
 +  if AVS VioGetAnsi requires to call BVS then 
 +    VioRouter сalls BVS VioGetAnsi 
 +else 
 +  VioRouter calls BVS VioGetAnsi 
 +Return to application 
 +</code> 
 + 
 +OS/2 1.1 introduced Program Manager and VIO was extended to support windowed OS/2 text-based sessions. This extended Vio was named as Advanced VIO. 
 + 
 +Such route specific to OS/2 1.0 and 1.1. OS/2 1.2 includes additional functionality. Base Video Subsystem now uses Base Video Handlers to access hardware. Also Global Video Sybsystem hook was added. Base Vide Handler is a sort of video hardware abstraction layer. Global Video Subsystem allow to add notification hooks after VioRoute call.
  
 <diagram> <diagram>
Line 37: Line 55:
 | |!@4 | | |!@4 |
 | EEE  |EEE=Base Video Handlers | EEE  |EEE=Base Video Handlers
 +| |!@4 |
 +| EEE  |EEE=[[en:docs:os2:modules:BVSCALLS|Base Video Subsystem]]
 | |!@4 | | |!@4 |
 | CCC  |CCC=VIO router | CCC  |CCC=VIO router
Line 43: Line 63:
 </diagram> </diagram>
  
-In late OS/2 versions (3.x?) actual code of Video subsystem and Base Video Subsysten was moved to DOSCALLS.DLL (see Fig). OS/2 Video Subsystem is 16-bit. Later three independed versions of 32-to-16 bit wrapper subsystems was developed (See Fig)+In pseudo code it looks like this 
 + 
 +<code> 
 +Application calls VioGetAnsi in VIOCALLS 
 +VioGetAnsi calls VioRoute 
 +if AVS registered then 
 +  VioRoute calls AVS VioGetAnsi 
 +  if AVS VioGetAnsi requires to call BVS then 
 +    VioRouter сalls BVS VioGetAnsi 
 +else 
 +  VioRouter calls BVS VioGetAnsi 
 +If GVS registered then 
 +  VioRouter calls GVS VioGetAnsi 
 +Return to application 
 +</code> 
 + 
 +In OS/2 2.0 and later VIO still 16-bit. In late OS/2 versions (3.x?) actual code of Video subsystem and Base Video Subsysten was moved to DOSCALLS.DLL (see Fig). VIOCALLS and BVSCALLS is a forwarders to DOSCALLS. 
  
 +As not part of official OS/2 distribution three independed versions of 32-to-16 bit wrapper subsystems was developed (See Fig). EXMWRAP.DLL was part of eComstation 1.0 and later releases.
  
 <diagram> <diagram>
Line 55: Line 92:
 | BBB  |BBB=[[en:docs:os2:modules:DOSCALLS]] | BBB  |BBB=[[en:docs:os2:modules:DOSCALLS]]
 | |!@4 | | |!@4 |
-| CCC  | - | -@2 |DDD|DDD=Alternate Video Subsystem/Global Video Subsystem|CCC=VIO router+| CCC  |CCC=VIO router 
 +| |!@4 | 
 +|DDD|DDD=Alternate Video Subsystem 
 +| |!@4 | 
 +| CCC  |CCC=VIO router
 | |!@4 | | |!@4 |
 | EEE  |EEE=[[en:docs:os2:modules:BVSCALLS|Base Video Subsystem]] | EEE  |EEE=[[en:docs:os2:modules:BVSCALLS|Base Video Subsystem]]
Line 62: Line 103:
 | |!@4 | | |!@4 |
 | EEE  |EEE=Base Video Handlers | EEE  |EEE=Base Video Handlers
-</diagram> 
- 
-Under DOS original IBM Family API or JdeBP's Family API applications uses following call route 
- 
-<diagram> 
-|  AAA |AAA=Application 
 | |!@4 | | |!@4 |
-| BBB  |BBB=[[en:docs:os2:modules:API.LIB]] +| EEE  |EEE=[[en:docs:os2:modules:BVSCALLS|Base Video Subsystem]]
-</diagram> +
- +
-Under HX DOS Extender OS/2 Emulation Family API applications uses following route +
- +
-<diagram> +
-|  AAA |AAA=Application+
 | |!@4 | | |!@4 |
-| BBB  |BBB=[[en:docs:os2:modules:VIOCALLS]] +| CCC  |CCC=VIO router
-</diagram> +
- +
-Under DOS osFree Family API supports following route +
- +
-<diagram> +
-|  AAA |AAA=Application+
 | |!@4 | | |!@4 |
-| BBB  |BBB=[[en:docs:os2:modules:VIOCALLS]] +|DDD|DDD=Global Video Subsystem
-| |!@4 | +
-| CCC  | - | -@2 |DDD|DDD=Alternate Video Subsystem|CCC=VIO router +
-| |!@4 | +
-| EEE  |EEE=[[en:docs:os2:modules:BVSCALLS|Base Video Subsystem]]+
 </diagram> </diagram>
  
-osFree attempts to combine all aproaches and provide following callflow+<code> 
 +Application calls VioGetAnsi in VIOCALLS 
 +VIOCALLS forwards to DOSCALLS 
 +VioGetAnsi calls VioRoute 
 +if AVS registered then 
 +  VioRoute calls AVS VioGetAnsi 
 +  if AVS VioGetAnsi requires to call BVS then 
 +    VioRouter сalls BVS VioGetAnsi 
 +    BVSCALLS forwards to DOSCALLS 
 +else 
 +  VioRouter calls BVS VioGetAnsi 
 +  BVSCALLS forwards to DOSCALLS 
 +If GVS registered then 
 +  VioRouter calls GVS VioGetAnsi 
 +Return to application 
 +</code>
  
 +osFree attempts to combine all aproaches and provide following callflow
  
 <diagram> <diagram>
Line 109: Line 144:
 ||||| |!@4 | ||||| |!@4 |
 ||||| CCC  |CCC=VIO router ||||| CCC  |CCC=VIO router
-||||| |!@4 | 
-||||| DDD |DDD=Global Video Subsystem 
 ||||| |!@4 | ||||| |!@4 |
 ||||| EEE  |EEE=[[en:docs:os2:modules:BVSCALLS|Base Video Subsystem]] ||||| EEE  |EEE=[[en:docs:os2:modules:BVSCALLS|Base Video Subsystem]]
Line 117: Line 150:
 ||||| |!@4 | ||||| |!@4 |
 ||||| EEE  |EEE=Base Video Handlers ||||| EEE  |EEE=Base Video Handlers
 +||||| |!@4 |
 +||||| EEE  |EEE=[[en:docs:os2:modules:BVSCALLS|Base Video Subsystem]]
 +||||| |!@4 |
 +||||| CCC  |CCC=VIO router
 +||||| |!@4 |
 +||||| DDD |DDD=Global Video Subsystem
 </diagram> </diagram>
 +
 +===== Family API (DOS mode) =====
 +
 +Under DOS original IBM Family API or JdeBP's Family API applications uses following call route
 +
 +<diagram>
 +|  AAA |AAA=Application
 +| |!@4 |
 +| BBB  |BBB=[[en:docs:os2:libraries:API]].LIB/[[en:docs:os2:libraries:FAPI]].LIB/FAMAPI.LIB
 +</diagram>
 +
 +Under HX DOS Extender OS/2 Emulation Family API applications uses following route
 +
 +<diagram>
 +|  AAA |AAA=Application
 +| |!@4 |
 +| BBB  |BBB=[[en:docs:os2:modules:VIOCALLS]]
 +</diagram>
 +
 +Under DOS osFree Family API supports following route
 +
 +<diagram>
 +|  AAA |AAA=Application
 +| |!@4 |
 +| BBB  |BBB=[[en:docs:os2:modules:VIOCALLS]]
 +| |!@4 |
 +| CCC  |CCC=VIO router
 +| |!@4 |
 +| DDD|DDD=Alternate Video Subsystem
 +| |!@4 |
 +| CCC  |CCC=VIO router
 +| |!@4 |
 +| EEE  |EEE=[[en:docs:os2:modules:BVSCALLS|Base Video Subsystem]]
 +</diagram>
 +