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 - Laurence Pithie

Pages: 1 2 3 [4] 5
46
General Discussion / Re: Strange hobbes.nmsu.edu behavior.
« on: February 03, 2020, 04:14:41 pm »

47
Article Discussions / Re: Qt 5 version 5.13.1 OS/2 Beta 1
« on: January 29, 2020, 03:29:56 am »
qt5-qtsvg-devel contains Qt5Svg.lib and qt5-qtsvg contains the Qt5Svg.dll and the plugins/qsvg.dll

48
The sample programs for the various DosException calls on edm2 all exhibit the same result.
http://www.edm2.com/index.php/DosSendSignalException Sends a signal exception to a process using it's pid. Howver sending the signal to the DosSetExceptionHandler, DosSetSignalExceptionFocus or DosAcknowledgeSignalException examples result in an error 205.
http://www.edm2.com/index.php/DosSetExceptionHandler
http://www.edm2.com/index.php/DosSetSignalExceptionFocus
http://www.edm2.com/index.php/DosAcknowledgeSignalException

49
It would appear that cmd isn't the signal focus for it's screen group, so it will not process  either the break or the intr signals. A process calls DosSetSignalExceptionFocus to become the signal focus. It looks as if cmd.exe doesn't do this, so it will only respond to the signals if it's the application that has current focus.

50
A returned pid of zero isn't normal. You can check  what pid you should be getting by running top and looking for the cmd process you launched. If you're using  zero as the pid in your call to DosSendSignalException then the Exception will not be sent to your process. There isn't a process with a pid of zero, SYSINIT is the base process and its pid is 1. So that's why you're getting a 205 error, there's no process with that pid.

The PID of the process will, if the EXEC_ASYNC flag is used, be in the RESULTCODES->codeTerminate field when the call to DosExecPgm returns. Are you saving the value before you call DosWaitChild? DosWaitChild will set that value to zero for a normal exit.

51
According to the toolkit documentation for DosExecPgm
Quote
If asynchronous execution is indicated, DosExecPgm places the process ID of the started child process into the first doubleword of the pRes structure. If EXEC_ASYNCRESULT is specified for execFlag, the parent process can issue DosWaitChild (after DosExecPgm) to examine the result code returned when the child process ends. If the value of execFlag, is EXEC_ASYNC, the result code of the asynchronous child process is not returned to the parent process.
If the process is run synchronously the codeTerminate field of the RESULTCODES structure contains the result code returned on completion of the process. When the process is run asynchronously the  codeTerminate field contsins the pid of the process. So to get the pid you need to run the process ansynchronously, and, if you want both the pid and the resultcode you have to run it asynchronously and call DosWaitChild.

52
No you need to create one pipe for stdin and stdout. You provide three parameters to the DosCreatePipe, Two HFILE pointers and the size of the pipe. Which one you designate the read handle and the write handle is arbitrary, what get's written to one end of a filehandle can be read at the other, so if you dup stdin with the first handle then your child process will inherit that connected to it's standard inout, so whatevr the parentr process writes to the first filehandle will be read by the standard input of the child, the process for the second file handle is similar, duping it with stdout so that it's inherited as the stdout of the child process. The parent can then read from that file handle anything the child writes to it's standout. Data can travel both ways through each filehandle, however coordinating reading and writing to a signel channel would be complex and error prone, hence the abstraction provides two channels and you use one for reading and one for writing.  If you want to connect stderr to a pipe you'll need to create a second pipe, dup stderr to one of the filehandles and use that filehandle tin  the parent to read the output of stderr in the child. If you're being tidy you call DosClose on the other filehandle.

So, each call to DosCreatPipe gives you two file handles.

In the parent
1. ***Save your stdin and stdout***
2  Dup one filehandle with stdin, one with stdout, The parent process's stdin is now the filehandle from the pipe. Ditto for stdout. The parents stdinput is connected to the filehandle in the pipe, the child process inherits that filehandle as it's standar output, so that's where it reads from.
3. Call DosExecProg, the child inherits the parents stdin and stdout which are the two filehandles returnd from the pipe call.
4. In the parent
***restore the saved stdin and stdout***
 So stdin in the parent is not stdin in the child. The parent writes to the filehandle that's connected to the child processes stdin. 

In the child
1 The filehandle that was returned in the DosCreatePipe call in the parent is inherited as stdin, the OS tells the child it's value is 0.
2. The other filehandle returned by the call to DosCreateFile in the parent is inherited by the child as it's standard output. The OS tells the child that it's value is 1.

The child reads from the filehandle with the value 0 and writes to the filehandle with the value 1. The parent reads and writes to the pipe, it's restored it's standard input and standard output to their original values after the call to DosExecProgram.

stdin and sdout are abstractions provided by the operating system. Every process reads from fd0 and writes to fd1, The OS  juggles what they actually point to behind the curtain. The parent process changes what it's stdin and stdout point to from fd0 and fd1 to whatever value is returned in the call to DosCreatePipe, the child inherits those values as it's stdin and stdout and the parent resores it's original stdin and stdout. So the parents stdout and stdin aren't coinnected ot the childs, the filehandles returnd from the call to DosCreatePipe are.


53
>OK. I have them via DosCreateNPipe parameter.
No, you haven't. You need to save the current stdin and stdout to  temporary file handles, your main process is a PM application, stdin and stdout are not necessarily what you think they are in that context, they're certainly not connecte to a console and you'll need to restore them at the end of this process. If you use a named pipe you don't have a file handle you have a handle to a named pipe. They're both unsigned longs, but they point to completely different structures. I suspect that the outcome will be tears before bedtime. Use an unamed pipe, you get two file handles a read handle and a write handle on the return from that call.

>>and call DosDupHandle on stdin and stdout setting them to the write and read handles of the pipe.

>I assume that the Outpipe of my program is the stdin of the child program and reverse. So I have to reverse the assignments in DosDupHandle.

No, your child process inherits the parent processes stdin and stdout which you set to the read and write handles of the pipe using the DosDupHandle call. Don't reverse them, you dup the read file handle with your parent process stdout so that the parent processs standard output is now the write filehandle of the pipe and then dup the read handle with the read file handle. Following this the parent process's standard input and standard output are the read and write filehandles of the unnamed pipe respectively. When your child process inherits the parent't processes stin and stout they'll be correctly linked to the appropraite ends of the pipe.

Following the call to DosExecProgram restore the parent process stdin and stdout from where you saved them at the start of this proces.
Now, when the parent process writes to the write file handle of the pipe it will go to the stdin of the child process because the other end of the write filehandle in the parent is connected to the read filehandle in the child and vice versa.


54
Applications / Re: Odin on Warp 4.52 virtualbox
« on: January 10, 2020, 04:11:50 pm »
The odin-win32k package is no longer supported and isn't recommended for general use. The supported method is to use the pe program to launch the windows executable. pe <windowsprog>. Having said that the installer dies complaing about disk space requirements in install.ini when I tried that.

55
Yes, you don't have the pid of the second cmd process and there's no simple way to get hold of it. .

You don't need to pass the pipe name to the child process. A child process inherits the open file handles of the parent. Create a pipe in the parent process, Save the parent processes stdin and stdout to temporary file handles and call DosDupHandle on stdin and stdout setting them to the write and read handles of the pipe. Then call DosExecProgram and following that restore stdin and stdout in the parent. At that point anything writtten to the pipe's write handle from the parent should go to stdin for the child and anything written to stdout in the child can be read from the pipe's write handle.


56
The 205 error meant that there isn't a process with a signal handler in the process tree. You should set  up an exception handler in the thread that calls DosExecProcess using DosSetExceptionHandler prior to issuing the DosExecProgram
You can run the process asynchronously by passing EXEC_ASYNCRESULT or EXEC_ASYNC as the third parameter in the DosExecPgm call. The latter flag discards any result from the called process.

57
Setup & Installation / Re: ArcaOS 5.0/Win98 SE Dual-Boot - Questions!
« on: January 09, 2020, 02:10:07 pm »
Arca comes with the airboot boot manager which removes the need for the OS2 boot manager and a boot manager partition. Create the partitions for the installation using the LVM partitioner on the ArcoA Installation CD. Select system management from the intial installation screen and from there acces the LVM tool. Then install windows before installing ArcaOS.

58
The function to send the break signal to a process is DosSendSignalException, using the pid of the process and XCPT_SIGNAL_INTERRUPT  or XCPT_SIGNAL_BREAK as the second argument. The Ctrl-C character combination or scancode(3) won't work. Ctrl-C is intercepted by the OS and a signal is sent to the process that has focus. You'll need to set a signal handler for the signal in your main process and within that send the signal to the child process using DosSendSignalException.

59
Applications / Re: program locked and cannot terminate its execution
« on: January 04, 2020, 09:54:49 pm »
If it's reopening; or, more accurately, failing to reopen, the file after a reboot it might be your restartobjects setting in config.sys.  try setting it it startupfoldersonly and removing anything else from that line.
http://www.edm2.com/index.php/RESTARTOBJECTS

Pages: 1 2 3 [4] 5