Author Topic: architecture/substitute of cmd.exe ?  (Read 17979 times)

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
architecture/substitute of cmd.exe ?
« on: October 01, 2018, 12:22:32 pm »
The restrictions of the OS/2 commandline window are nervy. 4OS2 has the same restrictions. There's another command line program "take command", but it is no more supported yet and does not support basic cmd.exe commands like "dir /s".

I am the author of the ME Editor and of the DO.EXE commandline program. With ME.EXE, you can already import stdout:
dir /s | me in

I am thinking about a cmd.exe substitute. Basic functionality (dir, md, cd) has to be programmed in the new program, more complicated commands should be run via cmd.exe, while cmd.exe pipes it output to ME. That's because for every cmd command, cmd.exe has to be restarted and "forgets" old settings like the current directory or assign statements, so all functionality where the window has to remember something has to be reprogrammed.

I would like to ask: Is it right that the command line window (frame, fonts, buffer) is part of cmd.exe, so it is not possible to re-program the window only and not the commands? In 4os2, only the commands were reprogrammed, so I assume it is started via cmd.exe.

David McKenna

  • Hero Member
  • *****
  • Posts: 742
  • Karma: +24/-0
    • View Profile
Re: architecture/substitute of cmd.exe ?
« Reply #1 on: October 01, 2018, 01:10:33 pm »
 Hi Martin,

  You should check out the 32 bit command interpreter by Jonathan Pollard (if you haven't already):

http://hobbes.nmsu.edu/pub/os2/util/shell/cmd-1-1.zip

  It also needs these dll's:

http://hobbes.nmsu.edu/pub/os2/dev/32-bit/conrt-1-0-3.zip

  I seems to me to be better than the OS/2 supplied command line...

Regards,

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
Re: architecture/substitute of cmd.exe ?
« Reply #2 on: October 01, 2018, 03:01:42 pm »
I installed Jonathan Pollards program, but I did not understand the purpose. Besides bad performance of e.g. "copy" in some circumstances, what is the need of replacing cmd.exe commands? In former times, there were lacks of 16 bit commands, but in newer OS/2 versions these problems were fixed.

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.

RickCHodgin

  • Guest
Re: architecture/substitute of cmd.exe ?
« Reply #3 on: October 01, 2018, 03:46:36 pm »
I installed Jonathan Pollards program, but I did not understand the purpose. Besides bad performance of e.g. "copy" in some circumstances, what is the need of replacing cmd.exe commands? In former times, there were lacks of 16 bit commands, but in newer OS/2 versions these problems were fixed.

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.

If there's some way we can write a custom .EXE loader, then we can intercept the various function calls it links to for scrolling and displaying text.  We would be able to capture keystrokes, output text, introduce new shell features to the existing cmd window through new keystrokes not currently recognized.

In a DOS window, we could do this with a TSR.  In OS/2 we can do it with hooks into the DLL linking for all of the functions it uses.

Andi B.

  • Hero Member
  • *****
  • Posts: 811
  • Karma: +11/-2
    • View Profile
Re: architecture/substitute of cmd.exe ?
« Reply #4 on: October 01, 2018, 03:47:49 pm »
IMHO it's easier to take 4os2 sources and add and additional pm to overcomes the 8k character restriction. That's what TakeCommander did but unfortunately we do not have the sources. Some left overs are still in place though. In fact I started this with my 4os2 sources. I think it's easier to add a pm window to 4os2 than adding all the commands to an existing pm program like ME. Of course I'm biased ;)

Anyway the restrictions are the same. You have to redirect (or dup) stdin/stdout/stderr which makes the whole thing even more incompatible to standard cmd.exe. Regardless if you take 4os2 or your editor as base. Remember people even complain about 4os2 to cmd compatibility although it's nearly perfect.

For me Jonathan Pollards cmd replacement is useless cause we do not have the sources. And as I understand he is not willing to open source it. Beside that I did not found any good reason why I should learn his different syntax.

Beside JPs cmd replacement there are build in cmd shells (sort of) in VisualSlickEdit, NEDPM, LarsenCommander, ...? At least the VS implementation overcomes the 8k character limit. But it does not support ANSI colors. And I guess does have some resource problems (using it much for huge compile tasks makes it slow). And we do not have sources too. Maybe the NEDPM implementation is better. Hope aschn will comment on that here.

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
Re: architecture/substitute of cmd.exe ?
« Reply #5 on: October 01, 2018, 10:40:28 pm »
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

  • Sr. Member
  • ****
  • Posts: 368
  • Karma: +2/-0
    • View Profile
Re: architecture/substitute of cmd.exe ?
« Reply #6 on: October 01, 2018, 10:59:43 pm »
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.
« Last Edit: October 02, 2018, 01:42:50 am by Valery Sedletski »

ivan

  • Hero Member
  • *****
  • Posts: 1557
  • Karma: +17/-0
    • View Profile
Re: architecture/substitute of cmd.exe ?
« Reply #7 on: October 01, 2018, 11:07:39 pm »
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

  • Sr. Member
  • ****
  • Posts: 368
  • Karma: +2/-0
    • View Profile
Re: architecture/substitute of cmd.exe ?
« Reply #8 on: October 01, 2018, 11:10:39 pm »
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).
« Last Edit: October 01, 2018, 11:22:13 pm by Valery Sedletski »

xynixme

  • Guest
Re: architecture/substitute of cmd.exe ?
« Reply #9 on: October 05, 2018, 04:03:31 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.
ISTR (about) 8160 is a restriction of the Vio* APIs (or similar old OS/2 components); not of an application like CMD.EXE.

xynixme

  • Guest
Re: architecture/substitute of cmd.exe ?
« Reply #10 on: October 06, 2018, 03:53:48 pm »
A maximum of 8160 (80x102) is used in e.g. REXXUTIL.C indeed.

So one may have to write a PMCMD.EXE, which won't be compatible with CMD.EXE nor CMD.EXE's character mode anyway.

xynixme

  • Guest
Re: architecture/substitute of cmd.exe ?
« Reply #11 on: October 09, 2018, 10:37:31 am »
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.

Yet another advantage of ME is its Col mode (click on NormBlk to toggle), to e.g. delete a column of text in a file with a fixed line width.

RickCHodgin

  • Guest
Re: architecture/substitute of cmd.exe ?
« Reply #12 on: October 09, 2018, 11:06:28 am »
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.

Yet another advantage of ME is its Col mode (click on NormBlk to toggle), to e.g. delete a column of text in a file with a fixed line width.

Try the TSE editor.  It is DOS-based, but feature rich.  It allows editing of files up to available diskspace, has a macro programmable language with event hooks, column mode, line drawing mode, hex mode, syntax highlighting, can have multiple horizontal and vertical splitscreens up at the same time (even viewing different parts of the same file), and much more.

They made an OS/2 version, but it's no longer public.  You might be able to contact the author and get a copy.

I've never found a more feature rich editor.  There are also other versions including a Windows version.

https://www.semware.com/
« Last Edit: October 09, 2018, 12:31:46 pm by Rick C. Hodgin »

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
Re: architecture/substitute of cmd.exe ?
« Reply #13 on: October 19, 2018, 11:33:28 pm »
I am now thinking about to write a new input/output window for cmd.exe or 4os2.exe.

I can start cmd.exe from my editor main program with the /K option and with a output and input file to a pipe:
Code: [Select]
cmd.exe /K >\pipe\myoutpipe <\pipe\myinpipe
and then in my Editor program, a separate thread reads input from \pipe\myoutpipe and if a line has been edited and finished by pressing enter, the typed line gets written to \pipe\myinpipe.

Is it really so simple? Or is the connection between cmd.exe and the PM command window more sophisticated and I will fail with this concept?

Valery Sedletski

  • Sr. Member
  • ****
  • Posts: 368
  • Karma: +2/-0
    • View Profile
Re: architecture/substitute of cmd.exe ?
« Reply #14 on: October 20, 2018, 04:40:00 am »
2Martin Vieregg: cmd.exe and 4os2.exe nut only use stdin/stdout/stderr, but also use KBD/VIO API's to access console. E.g. 4os2 enables/disables ansi sequences via VIO API, implements menus (if you press PgDn, a menu with recently entered commands will be displayed). Editors usually use AVIO, to execute programs in their windows. So, stdin/stdout/stderr is a simplest case, but VIO API's are sometimes required. You can't start FC/2 in your editor by just redirecting stdin/stdout.