OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: Martin Iturbide on November 21, 2014, 02:11:00 pm
-
Hi
I want to update the architecture graphic I made some time ago. But I want to try to understand more about some components that are not posted there.
Right now I want to start with the GPI API (http://www.edm2.com/index.php/OS2_API:GPI). I want to see if it can be represented somewhere on the graphic or not. If GPI depends (needs) PM to run it should be on top of it, but if PM depends on GPI, GPI should on the down side of PM. But I have no idea about GPI, are there any command line apps (non PM) that can use GPI APIs?
Here it goes the graphic for people to remember it:
(http://4.bp.blogspot.com/-zYeRhXwB620/UaY-58CbCDI/AAAAAAAAEYo/kNPot3NkrxA/s1600/OS2+Architecture+Graphics+v3.png)
-
I think that GPI should be a small box inside PM. I think that if pmgpi.dll contains all GPI functions, maybe it is a component of PM.
-
I think that GPI should be a small box inside PM. I think that if pmgpi.dll contains all GPI functions, maybe it is a component of PM.
Sure. They chose the prefixes well in those days.
-
I'm still not sure if "Control Program" should be at the down of "Presentation Manager". Does anybody knows if PM required "Control Program" to function?
Control Program looks like an important set of instructions (don't laugh if my ignorance please :) ) and if PM uses/requires that instructions, I'm drawing this interpretation wrong.
-
The control API is the basic stuff, all you need for DOS like functionality and what everything else is built on top of (excepting stuff built on DOS such as winos2). To quote cp1.inf from the toolbox
The lowest-level functions supplied by the OS/2 operating system are those provided by the kernel and the kernel's subsystems-the control programs of the operating system. The Control Program functions involve the most basic aspects of program execution, such as memory management, file handling, and process, thread, and session management. They also involve more sophisticated programming tasks, such as exception handling and interprocess communications. The names of all the system functions in the Control Program API are prefixed with the letters "Dos", as in DosAllocMem.
So pretty much everything is on top of "Control Program"
-
Thanks Dave.
I had updated the graphic. I was also advised that SOM does not depend on Presentation Manager, so it should not be a layer up the PM.
Let me know if this is a more adequate one.
-
Looking better. I notice that you don't have OS/2 Full Screen Session in your graphic, should be beside Presentation Manager as a full screen program can run independent of the PM in its own session and can manipulate the graphics controller independent of the PM. Often they were also the "family class" of programs where the same binary could run under DOS or OS/2.
Examples of using full screen graphics with EMX are the vesa library http://hobbes.nmsu.edu/download/pub/os2/dev/emx/contrib/vesa19.zip (http://hobbes.nmsu.edu/download/pub/os2/dev/emx/contrib/vesa19.zip) and the svga library http://hobbes.nmsu.edu/download/pub/os2/dev/emx/contrib/svgakt19.zip (http://hobbes.nmsu.edu/download/pub/os2/dev/emx/contrib/svgakt19.zip) and of course there was/is XFree86 where we could run the exact same X drivers as *nix.
One other point is that some consider the "control program" to be part of the kernel with some of it contained in the kernel and some of it in doscall1.dll. From what I understand, doscall1.dll can be considered part of the kernel depending on your viewpoint.
-
Hi Dave
I agreed that I miss a "OS/2 Full Screen Session" component to represent that command line applications can run over it and not over CPI. But does the "OS/2 Full Screen Session" has other name? which are the parts, exe, DLLs of that component?
Thanks for the feedback.
-
I'm not aware of a better name then "Full Screen Session". The components can be pretty minimal, especially for a text mode application running on a FAT drive, basically the kernel and DOSCALL1.DLL along with the various device drivers and supporting DLLs needed to come up to a command line. Examples are the first couple of install floppies or the util disks that used to be able to be created from system setup.
An example is TEDIT.EXE which depends on DOSCALL1, SESMGR.DLL, KBDCALLS.DLL, NLS.DLL and VIOCALLS.DLL and I guess cmd.exe.
It's nice to also have something to set up the printer spool and a minimal shell such as tshell (also has hints for running in 4MBs of memory) http://hobbes.nmsu.edu/download/pub/os2/util/shell/tshell.zip (http://hobbes.nmsu.edu/download/pub/os2/util/shell/tshell.zip) to allow changing sessions and even DOS support.
-
One other point is that some consider the "control program" to be part of the kernel with some of it contained in the kernel and some of it in doscall1.dll. From what I understand, doscall1.dll can be considered part of the kernel depending on your viewpoint.
Opps... I don't have a viewpoint of that :) I'm limited by my knowledge on this subject.
Here goes the updated graphic with the "Fullscreen Session".