Topics

16

Programming / again colored text output of commandline programs (MeShell)

« on: May 07, 2020, 07:47:36 pm »

We already discussed the question how commandline programs with colored text output are working. Meanwhile, I got feedback that several programs like the gcc compiler and other programs coming from Unix do not show colored output in MeShell. So they do not use ESC sequences which run through the pipe without problems. But the VIO window rests empty - in comparison to Laurence which programmed a sample for me (see here) where the output is shown without colors in MeShell and simultaneously colored in the VIO window.

So it seems that there is a third way of showing colored text besides a VIO output to the screen buffer and ESC sequences via Stdout. Can someone explain please how this works? The linked thread contains an attachment with a colored tree.exe. It seems to be an old 16 bit application. It shows colored directory names in the original commandline window, MeShell shows the output without color and the MeShell VIO window rests empty. This behaviour seems to happen often with utilities coming from Unix like gcc.

17

Programming / MeShell and PAUSE in a cmd file

« on: April 15, 2020, 05:29:39 pm »

Meanwhile, I have published a stable beta version of MeShell 0.51 (see Utilities). But there's one problem left where I need your help for brainstorming.

PAUSE is a command which is defined in cmd.exe or 4os2.exe. It does not handle Stdin, but it does also not handle normal VIO keyboard input. I do not understand completely how it works, because a key input into the MeShell original VIO window has no effect. It seems that it is compiled completely internally. And this is a problem for MeShell. In comparison to "MORE", where I programmed an expedient substitute, I have no Idea at the moment how to handle the PAUSE problem. I hope that you have ideas how to handle the problem.

Programming a tiny "pause.exe" does not work because cmd.exe executes "pause" directly without checking the PATH directory list for external programs.

Till now, I found a convenient solution for every problem, and I hope that someone here has an idea how to solve this problem.

18

Programming / how to stay a window on top

« on: April 02, 2020, 09:15:25 pm »

OS/2 distinghishes between a standard "window" and a "dialog window". A visible difference is that a standard window has got an arbitrary icon on the system menu button. A dialog window has only a drop down array icon. Both windows can run in modal and non-modal state. The standard "window" is created with the API call "WinCreateWindow" or "WinCreateStdWindow". A dialog window is created with WinCreateDlg or with WinLoadDlg (from a resource) and a parameter is the address of a message processing function.

An interesting difference in the behaviour of both types of window is that a dialog window continously stays on top, even another window of the program gets the focus, also in non-modal state.

My question: Is there a flag where a window created with WinCreateWindow gets the same behaviour of staying on top like a "dialog window" does?

The reason is that I want to add a specific property to the WDsibyl component library. In Freepascal Lazarus, such a property exists (tForm.Formstyle = fsStayOnTop). The WDsibyl tForm component is completely based on WinCreateWindow, also all standard controls do so.

19

Utilities / MeShell commandline frontend timetable

« on: March 25, 2020, 11:12:03 am »

The last 3 month, I have posted a lot of very OS/2 specific programming questions in the programmers section. Meanwhile, the project of a new OS/2 commandline frontend made a lot of progress. At the moment, I am fixing only minor bugs (false cursorposition in editor...) and the main job is done. A lot of things work better than I originally expected.

What is already done:
- Adaption of the ME editor for the new purpose
- Base cmd.exe functionality (especially cursor up/down command history)
- Base stdin/out functionality
- handling VIO input/output
- User settings notebook, load and save settings
- (soon) saving and restoring output

What I do not implement in the first version 0.5, but for the 1.0 version:
- Command completion with flyover dropdown field (as an user option)
- WPS integration (e.g. doubleclick to a filename from "dir" output opens the file via WPS default connection)
- navigation/history window with a tree, sorted by: Level 1 current directory, Level 2 entered command to jump back into the editor and to restore old commands

But this stuff is much more easier to implement than the stuff which is already done.

I need some help from you for specific jobs:
- I am not an english native speaker (I am german). I need a real native speaker which reads and corrects my english docu. The english docu draft for version 0.5 will be finished in perhaps 1 week and will be extended later.
- If the program should be localized besides english and german, I need help from native speakers. A few text parts (from the WDsibyl environment) are already in nederlands, italian and russian. But first, I have to divide all language specific data from the normal code. Localization makes only sense when the 1.0 version will be nearly finished (in perhaps 2-3 month).

After receiving the corrected english docu, I will publish the first version 0.5. I do not want to publish a version with bugs which are already known and at the moment, I myself find continously minor bugs in daily use and can fix them without problems.

20

Programming / Shared Memory correct usage

« on: March 21, 2020, 11:42:28 am »

I want to use one Shared Memory in both directions. Samples in the internet are poor.

In the server, I wrote:

rc := DosAllocSharedMem(SharedMem, NULL, 4096/*smaller has no effect*/, PAG_WRITE | PAG_READ | PAG_COMMIT | OBJ_GETTABLE);

SharedMem is an untyped pointer.

I transfer the pointer value via commandline parameter to the client.

The pointer value is hold in ulong4.

In the client, I wrote:

      SharedMem = (VOID*) ulong4;
      SharedMem2 = (VOID*) (ulong4+8);
      rc = DosGetSharedMem(SharedMem, PAG_READ | PAG_WRITE);
      PSharedULONG = (PULONG) SharedMem;
      PSharedULONG2 = (PULONG) SharedMem2;
     
I can write the values in the server and read the values in the client, but not reverse (crash). I wrote in the client:

    *PSharedULONG2 = 2;
    //Now it crashes. PSharedULONG also crashes.

Where is my mistake?

21

Programming / Observing if a program uses vio calls

« on: February 25, 2020, 06:49:43 pm »

In the german forum os2.org I started a thread with a problem for my PM commandline frontend, which only supports stdin and stdout, but no VIO calls. If a program writes directly into the screen buffer, my PM window does not show it. So the user has to switch between VIO and PM stdout window - I have got a button in my PM window doing that. It would be useful if the program recognizes automatically if a program which is executed via cmd.exe writes VIO output, so the VIO window could get visible automatically.

My first idea was to analyse the EXE binary and search the string VIOCALLS. In the thread, I was told that there is a better way. The program exehdr.exe from the OS/2 2.45 Toolkit in combination with the following rexx script

Code: [Select]

/* analyse executable import viocalls */
parse upper arg efn SuperfluousArguments
if (efn == '') then return

ifn = 'exehdr.txt'

'@e:\os2ddk\base32\tools\os2.386\bin\exehdr /v 'efn' > 'ifn

needle = ' imp '
do while lines(ifn) <> 0
  haystack = linein(ifn)
  there = pos(needle,haystack)
  if (there > 0) then do
    line = substr(haystack,there+length(needle))
    if (left(line,8)=='VIOCALLS') then say line
    end
  end

return

shows not only the fact that a program uses VIO calls, it shows also the number. The list of VIO calls is here:

Code: [Select]

VIOENDPOPUP             VIOCALLS   1
VIO16ENDPOPUP           VIOCALLS   1
VIOGETPHYSBUF           VIOCALLS   2
VIO16GETPHYSBUF         VIOCALLS   2
VIOGETANSI              VIOCALLS   3
VIO16GETANSI            VIOCALLS   3
VIOSETANSI              VIOCALLS   5
VIO16SETANSI            VIOCALLS   5
VIODEREGISTER           VIOCALLS   6
VIO16DEREGISTER         VIOCALLS   6
VIOSCROLLUP             VIOCALLS   7
VIO16SCROLLUP           VIOCALLS   7
VIOPRTSC                VIOCALLS   8
VIO16PRTSC              VIOCALLS   8
VIOGETCURPOS            VIOCALLS   9
VIO16GETCURPOS          VIOCALLS   9
VIOWRTCELLSTR           VIOCALLS  10
VIO16WRTCELLSTR         VIOCALLS  10
VIOPOPUP                VIOCALLS  11
VIO16POPUP              VIOCALLS  11
VIOSCROLLRT             VIOCALLS  12
VIO16SCROLLRT           VIOCALLS  12
VIOWRTCHARSTR           VIOCALLS  13
VIO16WRTCHARSTR         VIOCALLS  13
VIOSETCURPOS            VIOCALLS  15
VIO16SETCURPOS          VIOCALLS  15
VIOSCRUNLOCK            VIOCALLS  18
VIO16SCRUNLOCK          VIOCALLS  18
VIOWRTTTY               VIOCALLS  19
VIO16WRTTTY             VIOCALLS  19
VIOGETMODE              VIOCALLS  21
VIO16GETMODE            VIOCALLS  21
VIOSETMODE              VIOCALLS  22
VIO16SETMODE            VIOCALLS  22
VIOSCRLOCK              VIOCALLS  23
VIO16SCRLOCK            VIOCALLS  23
VIOREADCELLSTR          VIOCALLS  24
VIO16READCELLSTR        VIOCALLS  24
VIOSAVREDRAWWAIT        VIOCALLS  25
VIO16SAVREDRAWWAIT      VIOCALLS  25
VIOWRTNATTR             VIOCALLS  26
VIO16WRTNATTR           VIOCALLS  26
VIOGETCURTYPE           VIOCALLS  27
VIO16GETCURTYPE         VIOCALLS  27
VIOSAVREDRAWUNDO        VIOCALLS  28
VIO16SAVREDRAWUNDO      VIOCALLS  28
VIOGETFONT              VIOCALLS  29
VIO16GETFONT            VIOCALLS  29
VIOREADCHARSTR          VIOCALLS  30
VIO16READCHARSTR        VIOCALLS  30
VIOGETBUF               VIOCALLS  31
VIO16GETBUF             VIOCALLS  31
VIOSETCURTYPE           VIOCALLS  32
VIO16SETCURTYPE         VIOCALLS  32
VIOSETFONT              VIOCALLS  33
VIO16SETFONT            VIOCALLS  33
VIOMODEUNDO             VIOCALLS  35
VIO16MODEUNDO           VIOCALLS  35
VIOMODEWAIT             VIOCALLS  37
VIO16MODEWAIT           VIOCALLS  37
VIOGETCP                VIOCALLS  40
VIO16GETCP              VIOCALLS  40
VIOSETCP                VIOCALLS  42
VIO16SETCP              VIOCALLS  42
VIOSHOWBUF              VIOCALLS  43
VIO16SHOWBUF            VIOCALLS  43
VIOSCROLLLF             VIOCALLS  44
VIO16SCROLLLF           VIOCALLS  44
VIOREGISTER             VIOCALLS  45
VIO16REGISTER           VIOCALLS  45
VIOGETCONFIG            VIOCALLS  46
VIO16GETCONFIG          VIOCALLS  46
VIOSCROLLDN             VIOCALLS  47
VIO16SCROLLDN           VIOCALLS  47
VIOWRTCHARSTRATT        VIOCALLS  48
VIO16WRTCHARSTRATT      VIOCALLS  48
VIOGETSTATE             VIOCALLS  49
VIO16GETSTATE           VIOCALLS  49
VIOPRTSCTOGGLE          VIOCALLS  50
VIO16PRTSCTOGGLE        VIOCALLS  50
VIOSETSTATE             VIOCALLS  51
VIO16SETSTATE           VIOCALLS  51
VIOWRTNCELL             VIOCALLS  52
VIO16WRTNCELL           VIOCALLS  52
VIOWRTNCHAR             VIOCALLS  53
VIO16WRTNCHAR           VIOCALLS  53
VIOASSOCIATE            VIOCALLS  55
VIO16ASSOCIATE          VIOCALLS  55
VIOCREATEPS             VIOCALLS  56
VIO16CREATEPS           VIOCALLS  56
VIODELETESETID          VIOCALLS  57
VIO16DELETESETID        VIOCALLS  57
VIOGETDEVICECELLSIZE    VIOCALLS  58
VIO16GETDEVICECELLSIZE  VIOCALLS  58
VIOGETORG               VIOCALLS  59
VIO16GETORG             VIOCALLS  59
VIOCREATELOGFONT        VIOCALLS  60
VIO16CREATELOGFONT      VIOCALLS  60
VIODESTROYPS            VIOCALLS  61
VIO16DESTROYPS          VIOCALLS  61
VIOQUERYSETIDS          VIOCALLS  62
VIO16QUERYSETIDS        VIOCALLS  62
VIOSETORG               VIOCALLS  63
VIO16SETORG             VIOCALLS  63
VIOQUERYFONTS           VIOCALLS  64
VIO16QUERYFONTS         VIOCALLS  64
VIOSETDEVICECELLSIZE    VIOCALLS  65
VIO16SETDEVICECELLSIZE  VIOCALLS  65
VIOSHOWPS               VIOCALLS  66
VIO16SHOWPS             VIOCALLS  66
VIOGETPSADDRESS         VIOCALLS  67
VIO16GETPSADDRESS       VIOCALLS  67
VIOGLOBALREG            VIOCALLS  70
VIO16GLOBALREG          VIOCALLS  70
XVIOSETCASTATE          VIOCALLS  71
XVIO16SETCASTATE        VIOCALLS  71
XVIOCHECKCHARTYPE       VIOCALLS  72
XVIO16CHECKCHARTYPE     VIOCALLS  72
XVIODESTROYCA           VIOCALLS  73
XVIO16DESTROYCA         VIOCALLS  73
XVIOCREATECA            VIOCALLS  74
XVIO16CREATECA          VIOCALLS  74
VIOCHECKCHARTYPE        VIOCALLS  75
VIO16CHECKCHARTYPE      VIOCALLS  75
XVIOGETCASTATE          VIOCALLS  76
XVIO16GETCASTATE        VIOCALLS  76

But this solution anlyses only the program code and I do not know if the API calls are really exeuted. For example, XCOPY uses VIO calls, but only in very special circumstances I have not found out yet.

There is a program os2trace  which excatly makes the job I need: Observing an application and journaling which API calls it calls.

The perfect solution would be if my PM program observes the EXE file which is executed via cmd.exe in the known session which is controlled by my program like os2trace does. Is the author Dave Blaschke still acitive? Perhaps he or someone can explain or help me with the code I need. I would need a simple C or Pascal commandline program which observes a specific binary and gets an output "VIOCALL used!" if a VIOcall is sent. Then I could copy these lines into my PM program in an own thread.

22

Programming / different types of keyboard input in cmd.exe

« on: February 19, 2020, 11:07:38 am »

I have recognized another tricky problem for my cmd.exe frontend: The types of keyboard input

There are in my opinion three types of keyboard input which have to be handled different in my editor:

(1) Prompt: The user types input after a prompt, can edit it and sends the input to cmd.exe by pressing ENTER. Before pressing ENTER, cmd.exe does not see any input at all.

(2) program read input: A commandline program requests user input, e.g. a Y/N query, or a string. This input is also finished by pressing ENTER.

An important difference between (1) and (2): In (1), cmd.exe echos the input as stdout. (4os2 does not.)

(3) Collecting text lines via "COPY CON": The editor collects several lines of user input and the input is finished by typing Ctrl-Z. After pressing Ctrl-Z, all lines incl. line end characters (^M^J) are sent to cmd.exe in one step.

In type (3), both cmd.exe and 4os2.exe does not allow to edit the previous lines, you cannot use the up cursor key. (But I will manage this.)

Stdin/out programs always require ENTER after a user input. VIO programs also allow a single keyboard key to continue processing.

My PM editor frontend needs to know which of the three types of keyboard input is current. To distinguish between (1) and (2), I analyze the prompt string which is shown at the beginning of the line.

My question concerns the type (3) "COPY CON": I need to interpretate the command which the user types behind the prompt. My first idea is to search for "<space>CON<space>" ? Which example commands do you have where this type of edit mode gets activated?

23

Programming / Manipulating a PM window from another program

« on: February 17, 2020, 10:23:52 am »

For my commandline frontend, I need to manipulate the VIO window where cmd.exe runs. I have got the window handle. I want to remove buttons in the window title, because the user should neither close the window, nor minimize or maximize. I assume I have to use a WinSetWindow* call and I can use the constant  WS_MAXIMIZEBOX for example. But I did not find any documentation, I only found one for Windows in the Internet. Any hints are appreciated.

24

Programming / problems programming a new text window for cmd.exe/4os2.exe

« on: December 30, 2019, 01:02:08 am »

One year ago, I wrote about my desire to get a substitute for the limited VIO window when using cmd.exe or 4os2.exe without 8000 character limit and with all editor functionality.
https://www.os2world.com/forum/index.php/topic,1859.msg18588.html#msg18588

The last year, I was very busy with other things, but meanwhile I began to program. I am the author of ME Editor and other editors. The editor is an OOP (wdsibyl) project where I can easy manage modifications.

I managed now to excute the original cmd.exe with pipes for stdout, stdin and stderr. The basic input/output functionality works already. But  I need your help with some sophisticated problems.

The editor gets first executed, starts the pipes and executes cmd.exe in the background via
cmd.exe /K >outpipe 2>errorpipe <inpipe

For specific commands like mode, cls the commands will be interpretated by the editor and not cmd.exe, or gets interpretated by both. The current directory will be hold both in the editor and in cmd.exe. I will manage to turn the 4os2 escape codes into colors. All these things seem to make no problems to program (all not programmed yet).

But for three problems I have no solution yet:

(1) While cmd.exe is busy, the editor has to turn into read-only mode. The time period begins with an <ENTER> after typing the command, so the editor knows this moment. But when is the job finished and cmd.exe turns to idle state, the editor should turn to read/write and should accept the next command. I have no idea how the editor can get the information that cmd.exe is in idle state again.

A dirty solution would be to wait for [C:\] or a simular string. But this is not possible. And this is the next problem.

(CHANGED: Problem (2) is non-existant. It was a bug in my editor code.)
(2) A stdout output of cmd.exe waits until the line is finished with an carriagereturn. This has got a strange effect to my program: When starting the program, I do not see [C:\] at the moment. Then I type my command, e.g. "dir", press ENTER and the editor shows the "dir" output. But the last line with the command prompt [C:\] is not shown. It is only shown after entering the next command. Programs with an success indication with dots ...... are invisible while exeuting and waiting. So my question is: Is it possible to force stdout output in cmd.exe when the line is not terminated by a carriagereturn? Or do you have another idea how to sailing round the problem? The only idea for me at the moment is to simulate this output by adding a prompt and to swallow the first line output. Not a pretty solution. And the success dot problem is still not solved.

(3) Not all textmode programs do write into stdout, but there is text output shown nevertheless. This output gets shown in the hidden cmd.exe VIO window and not in my editor window. Can someone explain what this means and perhaps how to get this text in stdout nevertheless?

25

Programming / GpiCreateLogFont size problem with discrete sizes (longint)

« on: December 18, 2019, 09:22:05 am »

I have got a problem with a print preview function where the size of a font is calculated via the actual window size. Changing the window sizes makes ugly font size steps, because  the FATTRS. lAveCharWidth parameter for GpiCreateLogFont is a integer and not a floating point parameter. The typical values are about 10, so there are 10% steps which really looks ugly.

Other programs manage the problem, e.g. PDF viewers or OpenOffice. Is there a substitute for GpiCreateLogFont or how can I solve this problem?

26

Programming / WinQuerySwitchList Dead Entries

« on: November 28, 2019, 04:56:40 pm »

I am using the WDsibyl Delphi-like programming environment where I made already a lot of minor changes the last 15 years...

I have got a problem with dead entries in the window list when closing windows. In most cases, all works fine, but when closing the main window of a program without closing sub windows before, some specific sub windows do not disappear from the window list which is accessable via WinQuerySwitchList API call. In the OS/2 window list (Ctrl-ESC), they disappear. But e.g. in the MOLE list which is using the WinQuerySwitchList API function, they are still shown and since ArcaOS, shutdown faiis with a query "continue?".

If I understand the OS/2 API correct, the WinDestroyWindow (hwnd) API call should delete the Window from the list. The API call is executed twice, one for the form window and one for the frame. So it should disappear from the list, but it does not.

Any ideas?

27

Setup & Installation / RAM disk does not work anymore

« on: August 07, 2019, 09:00:43 am »

ArcaOS RAM disk does not work anymore. A hardware problem is possible, I had two other programs which does not run anymore (and I could fix it by re-copying the content of C). Four files are used:

c:\os2ldr.cfg (hidden)
file content:
RAMDISK = HPFS PERSIST *:
RAMDISKNAME = Z

c:\os2\boot\HD4DISK.ADD
c:\os2\boot\MEMDISK.ADD

Then there's a setup program with user interface:
C:\sys\bin\HIDISK.EXE

Any ideas what is also needed ? How can I find out why it fails?

28

Setup & Installation / ArcaOS fix for Windows seamless problem ?

« on: April 07, 2019, 11:02:32 pm »

I am waiting for an ArcaOS fix to solve the Win16 seamless windows problem. Does anyone heared about any efforts? On my old computer, it did work with eCS 1.2 and SNAP. Not only the missing seamless functionality is a problem, the performance of the Win16-only drivers is extremeley bad.

29

Utilities / 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.

30

Utilities / DO.EXE new version commandline utility 1.99

« on: August 25, 2018, 12:31:36 am »

I have downloaded a new version of my DO.EXE commandline utility:

DO for OS/2 archive file
DO for Windows (32 bit) archive file

DO.EXE is a swiss army knife command line enhancement. Since the last published version 1.46, I have added a handful new functions.

- DO SHOWCLONE, KILLCLONE: find and delete clone files
- DO EVERY: time-related executing of batch files, .e.g. every 3 days
- DO RENAME

and, most important:

- DO COPY
in variants. DO COPY shows the copied file names, DO PCOPY shows a progress bar. (With copy or xcopy, you won't get feedback for a long time when copying big files to slow drives like USB sticks.)
It is faster than XCOPY, because it can handle several file exensions simulateously. It collects all files before beginning with copying.
DO COPY can handle files larger than 4 GB on FAT32 drives. (There really seems to be no program which fits the problem.)

Please report bugs. 1.99 is a beta version, but it seems to work fine.
Please read the docu. DO.EXE can cause harm with only few input. By default, DO.EXE includes subdirectories.

A Linux and Macintosh version will follow. DO.EXE ist written with WDsibyl, and the other platforms with Freepascal-Lazarus.