Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Martin Vieregg

Pages: 1 ... 7 8 [9] 10 11 ... 17
121
Programming / Re: Observing if a program uses vio calls
« on: February 28, 2020, 04:30:08 pm »
If I exeute a binary directly, in most cases there comes VIO output immediately (I have no sample, but it can be different, too, that it first generates some stdout output "starting my app... please wait" and then switches to VIO, and after finishing VIO, some stdout is created (which wouldn't be a problem for me). In most cases, a first query after 400 ms without stdout output should be sufficient.

More sophisticated is the case of executing a cmd file. We discussed the case of sending the cmd file content line by line to cmd.exe stdin and the PM editor checks whether there's a VIO program in the sent text line or not. (We want to avioid this procedure.) I have got big cmd files in use which runs two minutes. It can happen that in such a long cmd file, a VIO program is placed between other stdout programs and commands.

Meanwhile, I have doubt, too, that a loop within the helper app is really useful. Instead, the PM editor could send a single query "VIO cursor position changed?" after 300-400 ms after the last received stdout. And if nothing happens at all - in the case the helper detects no VIO program and there's no stdout output anyway for seconds - the editor does not query anymore. Only if there's a new stdout output and a pause again, then it queries again. So the case of a cmd file should be covered.

In this case, I do not need a thread in the helper program which simplifies the code. No thread, no problem in suspending, resuming, memory access conflicts to consider and so on.

122
Programming / Re: Observing if a program uses vio calls
« on: February 28, 2020, 10:09:00 am »
Laurence, thank you for reasoning. Most things are congruent with my ideas, but I think that you have one circumstance not in view.
Quote
You shouldn't be continously polling the Vio cursor position, it's uneccessary. The only time you need to know if the Vio cursor has moved is following the completion of a command that produces no output on stdout.
If a VIO program waits for user input (e.g. a VIO-based editor or a menu program like DFSEE), I need a loop with continous querying. After again thinking about the problem, I have got this result: The PM editor has to send two kinds of queries to the helper:
1. A single query after a current command execution ends and a prompt is shown again: "Please tell me if VIO (cursor position) has changed and end the loop, if it is running".
2. A continous query via thread loop: "Please observe the VIO window and tell me immediately if VIO has changed."

The continous query is only sent to the helper if no stdout is shown for a specific time, e.g. 300 or 400 ms.
An option to optimize is to check whether the output contains Returns without Carriage (^M only without ^J). This output is typical for progress bars of stdout programs. In this case, a continous VIO observation is not necessary in my opinion. The editor knows it already.

This is all quite simple to program for me, because a lot of stuff can be reused: For the post from the PM window to the helper, I can use the semaphore and Shared Memory I use for the Ctrl-C exception. Then in the PM editor I have one unused thread left which starts the helper. I can add here a wait for semaphore loop. I have not to submit any data from the helper to the PM editor, I have only to wait for the semaphore event "pop VIO window now". This semaphore event is used in both cases 1. and 2.
So I will need a new semaphore. I will generate the semaphore fin the PM editor, the pointer value is submitted via commandline parameter to the helper again. Then I need a new thread in the helper executing the loop.

Two minor questions:
In the helper, I can recreate the thread if needed or suspend/resume the old thread. (Any ideas what is to prefer?)
When creating the new second semaphore, I hope that it is allowed that the receiver creates the semaphore? Normally the sender creates it. The way via commandline parameters to submit the pointer value is very easy for me.

123
Programming / Re: Observing if a program uses vio calls
« on: February 27, 2020, 12:58:51 pm »
Quote
2. Don't observe while executing, the PM app should care about output

Laurence, so in your opinion the loop/timer which continously queries the VIO cursor position should be placed in the helper app. Because non-PM programs do not know timer events, I have to create a thread with a DosSleep loop and continous querying VioGetCurPos. This only proceeds if the PM editor tells the helper doing so. If the prompt appears again in the PM editor, the editor tells the helper "tell me if the VIO cursor position has changed and end the loop."

124
Programming / Re: Observing if a program uses vio calls
« on: February 27, 2020, 11:08:13 am »
OK. I see it clear now and I think this should work:

1. Storing VIO cursor position before exeuting the command
The user presses ENTER in the editor main thread to send the new command to cmd.exe. The editor posts a semaphore "helper, please tell me the current VIO cursor position". I can use the semaphore I already use for the Ctrl-C exception because both posts are from the editor main thread. Then the helper queries the cursor position via "VioGetCurPos" and sends the information immediately back to the editor thread which waits for a second new semaphore in a thread. The data is hold in Shared Memory which I already have. Now the editor sends the user input to cmd.exe stdin (and not before receiving the cursor position from the helper to avoid a race problem).

2. Observing while executing
In a specific frequency (e.g. I have got already a timer with 250 ms), the editor asks the helper about the current cursor position in the VIO window (same procedure as 1.). If the x or y values have changed, the VIO window gets popped up.
This query only gets executed if there is currently no output received in the editor and/or if an EXE file is executed which has got VIO calls.

3. Observing when the command execution ends
If a prompt is shown again in the editor and the current command has ended execution, a last query of the VIO cursor position gets started. If there's a change of the VIO cursor position, the VIO window gets popped up. While the editor waits for user input (prompt state), no timer query to the helper proceeds.

So for me it seems, that in Point 2., it is sufficient to observe a coming input, so analyzing the EXE binaries gets obsolete which is a lot of problematic code (observing the execution of cmd files) I do not need anymore and is not programmed yet anyway.

In my opinion, this is a real perfect solution. If the executed command creates both VIO and Stdout, the VIO window is shown in any case when ending the command execution. In this case, I can program the VIO window position beneath the editor window so the user can see both outputs. So it is absolutely precluded that the user does not see a VIO output.

125
Programming / Re: Observing if a program uses vio calls
« on: February 26, 2020, 10:56:27 pm »
Quote
Your helper application isn't a presentation manager application, so the VioHandle should be zero.

Ah, yes, the helper application! Then I can simply use semaphores again. So I see three ways for doing the job:

(1) I create a thread in the helper program which always queries VioGetCurPos (e.g. 4 times every second, with a DosSleep in the loop) and observes the changes of the cursor position. If a change has been observed, it sends a message via semaphores to the PM application.

(2) The timer (not an additional thread) is in the PM application and it sends a query to the helper via semaphores. This query is only sent if some conditions are true
(a) a command is running (not prompt state)
(b) the application uses VIO calls
(c) no output is received for e.g. 1/4 or 1/2 seconds.
I think it won't be necessary to check all conditions. The helper remembers the last query and compares it with the new query. The helper sends the result back to the PM application via semaphores.

(3) In the case of the possibility that the PM helper can query directly the VIO handle (from "outside"), I would prefer the short way without helper app because it is easier to program.

But anyway, it seems that a clean solution will be definitely possible! What solution would be preferable in your opinion? Option (2) has different possibilities. So we have to discuss (b) if a VIO call analyzation of the binary is still necessary or can be resigned, because the curorpos query via helper needs less processor power.  Also condition (c) is to discuss. If a program generates both VIO output and stdout, it would be better to show both windows? It can happen that an application creates very fast some lines of VIO output and ends again. Perhaps some user settings would be helpful.

126
Programming / Re: Observing if a program uses vio calls
« on: February 26, 2020, 05:36:53 pm »
Laurence,

yes, that idea is very useful for my purpose ! VioGetCurPos requires a VIO handle. I have got a window handle and a session ID. How can I get the VIO handle?

127
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.

128
General Discussion / Re: Future death of the personal computer?
« on: February 20, 2020, 10:42:26 am »
In my opinion, the Personal Computer goes back to the way of usage he had in the late 80s and beginning 90s, before the WWW has been invented. It was a working tool for brain-workers and a toy for nerds. The "consumers" prefer tablet and smartphone. But I wonder that all the people accept the small screens. A big screen and overlapping windows alre an important advantage of Personal Computers.

129
Programming / Re: different types of keyboard input in cmd.exe
« on: February 19, 2020, 07:49:50 pm »
Code: [Select]
COPY filename.txt CON
Yes. the output is:

Code: [Select]
[Z:\]copy test.txt con:
one
two
        1 file(s) copied.

And in this case again, I have problems. I send the command to cmd.exe via stdin, and the file content is not shown in stdout, but the "1 file(s) copied." remark is shown.

Now I think I understand the problem. CON is the VIO window, not STDOUT ! In the VIO window, "one two" is shown, and the "1 file(s) copied" command is sent via STDOUT. So I have to simulate CON.

In the other direction (see two code fragments above), the same problem occurs. It does not work because cmd.exe waits for input in the VIO window and it does not get any. So after finishing the CON VIO command, the "one two" lines are received and interpretated as user prompt lines.

Is there a virtual file name like CON or NUL where I can write to stdout/read from stdin? Then I could simply change CON to the other expression, if the user wants this behaviour. (I will implement a lot of stored user settings.) I found this list for Windows in the Internet, OS/2 should be the same:
CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9

So there should be two different behaviours the user can choose: modify CON to stdin/stdout or popping up the VIO window like I want to program if a VIO program has been started.

130
Programming / Re: different types of keyboard input in cmd.exe
« on: February 19, 2020, 05:56:31 pm »
Laurence,

yes, I have to distinguish between the two directions to CON or from CON, and there's the notation "CON:" with semicolon. So "COPY CON" should fit the purpose, and I will delete obsolete spaces before.

Quote
However the command shell expects line oriented input, so if you send a line containing COPY CON then the shell will then read input on stdin line by line and echo that input on stdout, up until  it receives an EOF, which you're writing and reading stdin and stdout already anyway.

Yes, you are right and I was wrong. This simple test in cmd.exe shows the behaviour:

Code: [Select]
[Z:\]copy con test.txt
one
two
three^C

[Z:\]type test.txt
one
two

[Z:\]

But the behaviour in my editor when running cmd.exe as an "input to output compiler" without own window output is different:

Code: [Select]
[Z:\]copy con test.txt
one
two
^Cree

[Z:\]one
SYS1041: The name one is not recognized as an internal or external command, operable program or batch file.

[Z:\]two
SYS1041: The name two is not recognized as an internal or external command, operable program or batch file.
[Z:\]

I have no idea why the behaviour differs. I am sending "one" and "two" with carriage return + line feed to cmd.exe and nothing happens.


My intension is to have a behaviour close as possible to cmd.exe. It is a good idea to implement an editor functionality with a new unique command like "editz" , or you start an external editor.

Later, beta testing will find out the cases where the behaviour differs from cmd.exe and which I have not programmed yet. I can test it only for my own purpose, and everyone uses cmd.exe in a different way.

131
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?


132
Programming / Re: Manipulating a PM window from another program
« on: February 17, 2020, 06:23:41 pm »
Quote
SData.PgmControl = SSF_CONTROL_VISIBLE | SSF_CONTROL_MAXIMIZE;

PgmControl defines the window state when starting the window with DosStartSession. It would be started visible and maximized in this case. I want to manipulate the "maximize" button in the title bar. Laurence is right. I remember now that long time ago I already programmed it for my 4allCalc calulator, but meanwhile I do not practise regulary OS/2 API programming anymore. Any button has got a window handle, and with this window handle, you can do all the things you want.

Laurences code principally works, but WinEnableWindow FALSE makes the buttons non-functional, but they are normally shown. WinShowWindow FALSE deletes the buttons, but now there's a "hole" which is no more redrawn. The titlebar width is unchanged. The first trial, I made a programming failure and it did not work. I have to recalulate the correct width of the titlebar so it "fits" the holes. The correct titlebar width is the client width minus the width of the sysmenu button. This code works:

Code: [Select]
hw = WinWindowFromID(VIOhandle, FID_MINMAX);
WinEnableWindow(hw, FALSE); //turns off Min/Max functionality, but buttons are still shown
WinShowWindow(hw, FALSE); //do not show Min/Max buttons
//enlarge the titlebar width to fit the "holes"
hwtb = WinWindowFromID(VIOhandle, FID_TITLEBAR); WinQueryWindowPos (hw, &swp);
tbHeight = swp.cy;
hw = WinWindowFromID(VIOhandle, FID_CLIENT); WinQueryWindowPos (hw, &swp);
clWidth = swp.cx;
hw = WinWindowFromID(VIOhandle, FID_SYSMENU); WinQueryWindowPos (hw, &swp);
sysWidth = swp.cx;
ZOrderHWND = 0;
vLeft = 0; vBottom = 0; flOptions = SWP_SIZE;
WinSetWindowPos (hwtb, 0, vLeft, vBottom, clWidth-sysWidth, tbHeight, flOptions);

Because I need the System Menu of the VIO window, I cannot delete the System Menu and the user has got access to CLOSE which I do not want. Is it possible to disable the close functionality (also in the switch list) ? If not, I will restart the session automatically.

133
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.

134
Yes, Laurence, you are right. It is a race between the PM editor and the helper program. DosWaitNPipe in the helper program fits the purpose:

Code: [Select]
#define logwrite if (logging) {logf = fopen (ExeDir, "at"); fprintf
#define logend; fclose (logf);}
FILE *logf;
char Inpipename[50];
    logwrite (logf, "trying opening Inpipe %s\n", Inpipename); logend;
    rc = DosOpen (Inpipename, &cmd_stdin, &ulAction, 0, FILE_NORMAL, FILE_OPEN, OPEN_ACCESS_READONLY |
                   OPEN_SHARE_DENYNONE,(PEAOP) NULL);
    if (rc != 0) {logwrite (logf, "error %i Open Named Pipe %s\n", rc, Inpipename); logend;}
    if (rc == 231) { //Pipe is busy because Server did not finished calling DosConnectNPipe yet
      Timeout = 1000;/*ms*/
      rc = DosWaitNPipe(Inpipename, Timeout);
      logwrite (logf, "DosWaitNPipe returns %i\n", rc); logend;
      //try opening pipe again
      rc = DosOpen (Inpipename, &cmd_stdin, &ulAction, 0, FILE_NORMAL, FILE_OPEN, OPEN_ACCESS_READONLY |
        OPEN_SHARE_DENYNONE,(PEAOP) NULL);
      logwrite (logf, "second trial Open Named Pipe %s returns %i\n", Inpipename, rc); logend;
    }
    else {logwrite (logf, "successful open Named Pipe %s\n", Inpipename); logend;}

I can see in the logfile, that sometimes the additional code gets executed. Now I have to implement much more easier stuff.

135
If I understand it right, DosConnectPipe and DosDisConnectPipe using in the server only waits for client action opening and closing the pipe on the client end. I have to DosClose the named pipe both on the server and on the client end.

When ending the program, I inserted DosClose after DosDisConnectNPipe in my server program. And, alternatively, I use DosClose in the server program instead of DosDisconncectNPipe which should be not necessary (because I do not want to open the pipe again).

But the casually pipe busy error after restarting the program and its client still remains. ???

Pages: 1 ... 7 8 [9] 10 11 ... 17