Messages

1

Applications / Re: Programs that doesn't run

« on: August 19, 2023, 02:57:14 pm »

Vinit is the vrexx initialization routine. vrexx needs to be installed(as a minimum vrexx.exe, vrexx.dll, and devbase.dll in the same directory as the game should work)

2

Programming / Re: Autoconf and OS/2

« on: December 19, 2021, 03:12:14 am »

It appears to be a shell issue. When the system posix shell is Dash you get a broken makefile. setting it to bash fixed the issue.

3

Programming / Re: Autoconf and OS/2

« on: December 18, 2021, 02:45:30 pm »

Possibly dos vs unix line end issue?
https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings

4

Programming / Re: MeShell problem - start progname inherits stdin/out

« on: July 01, 2020, 04:25:25 pm »

fails because textfile.txt resides in the current directory an not in C:\. Any idea?

Before you issue the start command call  DosQueryPathInfo on the filename, passing FIL_QUERYFULLNAME as the second parameter. The fully qualified path name to the file will be in the buffer you pass as the third parameter You can get the buffer size for the returned full path name from DosQuerySysInfo using the QSV_MAX_PATH_LENGTH as the iStart and iLast parameter.

You'll need to parse the command line to ignore command line parameters and arguments to command line parameters, and deal with cases where more than one filename is passed on the command line.

5

Programming / Re: MeShell problem - start progname inherits stdin/out

« on: July 01, 2020, 11:16:44 am »

A program launched using the START command inherits the open file handles of the parent session. The /I parameter to the START command causes the new session to inherit the environment defined by the SET commands in config.sys instead of the CMD.EXE environment of the current session, in which case stdin will point to the keyboard and stdout will point to the monitor and won't be redirected to the pipe.

6

Utilities / Re: MeShell commandline frontend timetable

« on: May 22, 2020, 08:24:48 pm »

Code: [Select]

[C:\] zip<RETURN>
  adding: -

zip error: Interrupted (aborting)
(wild binary characters)When I try to  compress stdin in version 0.63 of MeShell the EOF doesn't seem to reach the zip process, so I have to use ctrl-c to interrupt the process. Is that the behaviour you are seeing?

 AFAIR you are using a named pipe to communicate between the parent process and the cmdhelper process. So, if you write an EOF to the named pipe from the parent, reading the EOF in the cmdhelper process is interpreted as  there's no data in the pipe, so it doesn't write anything to the standard input of the zip process.

Code: [Select]

[C:\]cat <RETURN>
Shows the same behaviour, Typing the EOF character (ctrl-z) doesn't end the CAT process, it's ignored. The simplest work around  is probably to use a semaphore to indicate to the cmdheloer process that it should write an EOF to the standard input of the command running in the shell when the user types ctrl-z in the parent application.

7

Programming / Re: MeShell and PAUSE in a cmd file

« on: April 17, 2020, 02:40:35 pm »

Stdout is read by the child program and piped to the editor. You check for a prompt in the child program.
Parent pipes command to child program
child program checks cursor position
child program writes command to stdout
child program checks for output on stdout
    if there is no output on stodut
           check cursor position
           compare cursor position with original position

8

Programming / Re: MeShell and PAUSE in a cmd file

« on: April 17, 2020, 01:51:10 pm »

But I do not receive redirected stdout in the described case

You need to check for the change in the cursor position in the child/helper application, then use VioReadCharStr to get the prompt text and send that text through the pipe to the main application.

9

Programming / Re: MeShell and PAUSE in a cmd file

« on: April 17, 2020, 12:34:31 pm »

The standard i/o functions move the Vio cursor. I've attached a simple program, with source, to demonstrate.

10

Programming / Re: MeShell and PAUSE in a cmd file

« on: April 16, 2020, 04:18:50 pm »

While there's no output to stdout until the eol is recieved the cursor position will have changed. Calling VioGetCurPos before issuing a command, check for output on stdout, and if there is no output call VioGetCurPos again and compare the two values. If the values differ then use VioReadCharStr with the two values you have for the cursor position to get the output prompt and display it to the user. It's similar to the logic you used for capturing Vio Output.

11

Programming / Re: how to stay a window on top

« on: April 04, 2020, 12:51:15 am »

One option would be to place the Main window behind the client window using WiinSetWindowPos when the client program is active. One way to  achieve that is by placing a check for the clinet program being active and calling WinSetWindowPos at the end of processing the WM_PAINT message in the main window procedure. Essentially what you woulld be doing is swapping the Z order of the two windows if the user brings the main window to the front while the client program is active.

12

Programming / Re: how to stay a window on top

« on: April 03, 2020, 09:32:13 am »

The FCF_SYSMODAL creation flag creates a system modal window. You can also use the WinSetSysModalWindow call to change a window into being the system modal window or from being the system modal window.

13

Programming / Re: Manipulating a PM window from another program

« on: March 29, 2020, 03:40:13 pm »

Pass the window handle of the Vio window as the first parameter of the WinSubClassWindow call with a pointer to the custom window procedure as the second parameter. Pass any messages that you don't explicitly process to the original window procedure (which is the return value from the WinSubClassWindow call) in a similar fashion to the way you pass messages you don't process to the standard window procedure in window classes you create in your own code. Because you can only subclass windows started in the same session you need ti issue this call from the helper app. There's a discussion on calling PM from AVIO here.
http://www.edm2.com/index.php/Calling_PM_from_AVIO_Applications

14

Programming / Re: Manipulating a PM window from another program

« on: March 29, 2020, 09:25:21 am »

One solution would be to  subclass the frame window and process WM_CLOSE and WM_QUIT messages in the custom window procedure.

15

Programming / Re: Shared Memory correct usage

« on: March 21, 2020, 01:51:46 pm »

As a suggestion, for avoiding pitfalls such as you describe in future, you should abstract your shared memory usage and wrap it in an api.