Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!public!car From: car@public.BTR.COM (Carlos Rimola-Sarti car@btr.com) Newsgroups: comp.os.os2.programmer Subject: Re: Porting from Unix to OS/2 Message-ID: <3153@public.BTR.COM> Date: 22 Jun 91 01:15:17 GMT References: <3126@public.BTR.COM> <1991Jun21.144327.18895@watson.ibm.com> <3152@public.BTR.COM> Organization: Communications Solutions, Inc. (CSI) Mountain View, California Lines: 164 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 writes: - -In article <3126@public.BTR.COM> you 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 | +---------------------------------------+-----------------------------------+