OS/2, eCS & ArcaOS - Technical > Utilities

architecture/substitute of cmd.exe ?

<< < (2/5) > >>

Martin Vieregg:
I still do not understand where the "silly" commandline window is programmed. It seems that all shell programs use the same restricted window. Is it part of pmshell.exe ? What information is hold in cmd.exe? Only the syntax of the commands or also the commandline PM window with its functionality?
My main interest is to reprogram the window, not the functionality. Reprogramming the functionality is only necessary if it is not possible to divide the window from the commands.

Valery Sedletski:
2Martin Vieregg: At 1st, I don't understand why 4os2 is not good for you. CMD.EXE limitations are mostly because it is 16-bit. 4os2 overcomes most of these limitations. What is about a scrollback buffer (like Linux has, which allows to scroll back by Shift-PgDn/Shift/PgUp) -- it is not a part of shell. It is a part of PMVIOP (VIO shield), or, most probably, BVHWNDW (a Basic Video Handler). The Basic Video Handler is a text mode video driver, it handles the video mode, including a full video buffer. A scrollback buffer is a video buffer which has more size. BVHWNDW draws a VIO screen in a VIO Shield window. VIO Shield (PMVIOP.DLL) is a PM DLL which has a WindowProc's for VIO window/DOS window/VIO window properties doalog/selection area (when you select text with mouse). Also, there are BVHVGA/BVHSVGA, which draw VIO screen in fullscreen sessions. So, we probably, need to implement a replacement BVH's for fullscreen and windowed OS/2 sessions. Or, better, an additional layer on top of BVH's, which will handle large scrollback buffers and scrolling. Maybe, it needs to be a proxy DLL for BVH's.

CMD.EXE / 4OS/2 have no relation with scrollback buffers. They are simple VIO programs. Any VIO program (like e.g. FC/2) should support scrollback, independently from CMD/4OS2.

ivan:
Hi Martin,

When you say you want to reprogram the commandline window what do you want to do with it?  If it is to change the size on opening use something like /k mode 80,45% in the parameters section of the properties dialog box, I use that to give me a reasonable sized window for things like the dir command.  It is also possible to customise the dir command with something like SET DIRCMD=/o:-d /p  (which gives a sorted by date and paged display), in CONFIG.SYS.

Anything else , sorry but you are on your own.

BTW, Thanks for the ME Editor.  I find it useful when I need a text file open and available on the desktop for days - the other editors force a reboot after a week if they are left open.

Valery Sedletski:
So, this relates with overall architecture of VIO subsystem. There is VIOCALLS, which is a VIO router. It can use Base Video Subsystem (BVS), or Alternate Video Subsystem (AVS). AVS can replace BVS. BVS is a default video subsystem (BVSCALLS.DLL). The examples of AVS'es are KShell (by Ko Myung Hun) which is a wrapper for BVS, adding unicode support for console (Korean symbols, for example). Another example of AVS is VIOROUTE (by Nickk). It implements VIO support on top of ANSI/VT100 terminal. (Used to run VIO programs over SSH).

I think, it is possible to create a special AVS, which will add extra features, like scrollback buffer support, on top of BVS.

Another idea would be a filter BVH which adds extra features. (for example, BVHSVGA is a filter on top BVHVGA).

André Heldoorn:

--- Quote from: Martin Vieregg on October 01, 2018, 03:01:42 pm ---My main interest is to have no more 8192 character buffer limitation (mode 80,102, 160,51) and a more comfortable editing and copy/paste functionalty.

--- End quote ---
ISTR (about) 8160 is a restriction of the Vio* APIs (or similar old OS/2 components); not of an application like CMD.EXE.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version