🚀 go-pugleaf

I got the following response from Kai-Uwe Rommmel regarding my
questions about porting between OS/2 <-> Unix.  Since most of his
comments are of general interest and a couple of other people
have expressed interest in the subject, I am posting my reply
to Kai-Uwe:

In his reply Kai-Uwe Rommel <rommel@dssiegert4.informatik.tu-muenchen.de>
writes:
-
-In article <3126@public.BTR.COM> you <car@btr.com> write:
-
->One of the first things that I had to decide was what to do about 
->the Unix fork() call.  The application makes use of fork to spawn off
->background processes.  The "right" thing to do is probably to redesign
->the app to use threads instead of fork().  However, the app will be
->thrown away and I only needed to verify that the other pieces are
->working.  Because of this, I thought that moving the application to
->OS/2 would be made a lot easier if I could emulate fork.  
-
-I am not shure what you need fork() for. Do you need only to fork off a
-background process to execute a new program or do you need the forked
-child to continue execution on the same image with the inherited data?
-

The latter.  I need the forked process to continue the execution path
of the parent w/ retcode=0 (indicating child) and, very importantly,
inheriting the current state of the parent's data space.

->After thinking about it I decided that fork() could not be easily emulated
->using threads.  A forked process inherits its own copy of the data
->segment (with current values) and also inherits other context like
->installed signal handlers (which this application makes use of).  All
->of these characteristics convinced me that it would be easier to
->simulate fork() by spawning an OS/2 process.  I have been able to
->come up with a scheme (hack?) that works but I still have a few 
->questions:
-
-How did you manage to simulate the inherited data? Sometimes I started
-porting a korn shell to OS/2 which uses fork() often and needs to
-continue work in the child on the inherited data segment. I did not find
-a solution (but have to tried much since then).
-

What I did was not very clean at all but it works.  The fork() routine
does the following:

1) Gets the return address off the stack.  This is where the child
needs to start executing.

2) Calculates the size of the data seg, allocates a shared data seg
and copies the current data to it.

3) Using info from DosGetInfo starts a copy of itself via DosExecPgm.

4) Waits on a semaphore.  Both the shared memory and semaphore use
the parent pid as part of their name.

5) The child process is now started.  At the start of main I need to
have a fork_setup() call.  In this routine, I create a semaphore.
This will only be successful for the first process.  Thereafter, it
is an indication that the process is a "forked" one.  This is why
I asked the question re a cleaner way to determin process identity.

6) Having determined that it is a child process, it gets the parent's
pid, accesses the shared memory, copies to its data seg, clears
the semaphore on which the parent is waiting and lastly jumps to 
the return address which was saved in step 1.

Other setup can be done in the fork_setup routine.  For example, I
enable a couple of signals handlers.  

I would not use this code for anything that would be used long term but
as I said before I just need it to get an application running asap and
both will be thrown away.

->1) Has anyone had a similar experience?  what did you do?
-
-As said, nothing yet.
-
->2) Is there a way in OS/2 to start a second process without having
->to specify an executable file that the OS will have to load from disk?
->In other words,  why can't I just tell the OS where the code is?
-
-Not as far as I know. DosExecPgm() or DosStartSession() are the calls I
-know that can be used to start a new process.
-

Judging from the responses I have received, I think you are right.

->3) Is there a clean way for a process to determine that IT is the
->first process in a session?  i.e., one that was not spawned off by
->another process in the same session.
-
-Hmm, I don't have the docs here and I am not shure if it is possible to
-determine the screen session of the parent process by a documented call.
-But there is an undocumented call DosQProcInfo() which is used by the
-PSTAT utility of OS/2 and that can be used to get the whole process tree
-of the system. I posted some documentation about it in
-comp.os.os2.programmer long time ago and have used it in the port of
-MS-SH 1.6 to OS/2.
-

It sounds useful.  Could you please email or repost this info?  Does
anyone know if this interface is been documented in OS/2 2.0?

->4) I would also like to hear about any other things to watch out for
->in porting code from one OS to the other and general comments on
->what others may have experienced.
-
-- Signal handling. SIGINT is associated with ^C, SIGBREAK is associated
-with ^BREAK and SIGTERM is generated if another process tries to kill
-the process (yes, this can be catched !).
-

SIGUSR1, SIGUSR2 and SIGUSR3 can also be used with signal() to setup
a signal handler.  However, the raise() function can only be used
within the same process.  I don't know how the MS C signal() function
implements signal().  I emulated signal() and kill() using PFLG_A-PFLG_C
in place of SIGUSR1-SIGUSR3.

-- File handle inheriting when using _pipe() (and perhaps _popen() and
-_pclose()) from the C 6.0 libraries. 
-

A named pipe can be open, read, written, closed by a process using
MS C library calls but I don't think they can be created.  This
would require the library function to perform DosMakeNmPipe and
DosConnectNmPipe.

Note here a difference between Unix and OS/2 named pipes.  When a
client closes the named pipe in OS/2, the server must issue a 
DosDisconnectNmPipe followed by a DosConnectNmPipe to enable a new
client to open the same pipe.

Another difference if I am not mistaken in Unix several clients can
open the same pipe with their written messages all going to the
server end (in sequence).  In OS/2, if you want the pipe to serve
multiple clients, it seems like you have to create multiple instances
of that pipe and create a thread for each instance to "listen" on.
You can probably use just one thread but it will need to determine
on which instance of the pipe data has arrived.  In any case it still
differs from Unix pipes.

-- When doing character mode screen output interactively, good old
-termcap and ANSI sequences are much better than VIO and easier to get
-working. STDOUT should be set to binary mode and output should be
-buffered with about 1k before writing it with write() to stdout.
-
-- Keyboard inbut with getch() from the C lib is not sufficient for all
-purposes because of ^S, ^Q, ^P handling. KbdCharin() is better, when the
-keyboard is set to binary mode (raw mode).
-
-Kai Uwe Rommel
-
-/* Kai Uwe Rommel, Munich ----- rommel@lan.informatik.tu-muenchen.dbp.de */
-
-DOS ... is still a real mode only non-reentrant interrupt
-handler, and always will be.                -Russell Williams
-

+ ---------------------------------------+-----------------------------------+
| Carlos Rimola-Sarti			|		email: car@btr.com  |
| Communications Solutions, Inc.	|		phone: 415-903-2585 |
+---------------------------------------+-----------------------------------+