🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #13122

Re: Using PIP:

#13122
From: Michael Richardson
Date: Sat, 16 Dec 1989 08:11
202 lines
7387 bytes
>In article <1610.AA1610@julie> mcr@julie.UUCP (Michael Richardson) writes:
>> alternate launching scheme, much more similar to the way the
>> workbench startup message works.
>
>Good for you.
>
>> I based it on Leo Shwab's wblaunch
>> code.
>
>Leo's? Not mine? What's Leo's look like?

  I honestly don't remember. Rest assured that I refered to some code
that you posted at some point too.

>Where in the Startup message?

  /* fast:exp/src/include/roguestar.h */

 struct RogueStartup {
   struct Message rs_Message;
   struct MsgPort *rs_Process;
   BPTR rs_Segment;
   LONG rs_dummy;             /* ALWAYS 0 -- would be NumArgs in WBStartup */
   char *rs_ToolWindow;       /* Usually NULL */
   int  rs_argc;
   char **rs_argv;
   int  rs_fhc;               /* Number of file handles to install */
   long *rs_fhv;
   int  rs_exitcode;
   BPTR rs_CurrentDir;
   char **rs_environ;         /* Arguments of environment space */
   int  rs_envcount;          /* Number of variables */
   char *rs_envspace;         /* Buffer containing variables */
   int  rs_envsize;           /* Size of buffer */
   long rs_closebits[2];      /* Close this filehandle (major kludge) */
 };

  Hmm... Guess I put in 64 bits for FileHandles...

  From boot:install/aztecc/include/workbench/startup.h:

   struct WBStartup {
     struct Message sm_Message;
     struct MsgPort * sm_Process;
     BPTR sm_Segment;
     LONG sm_NumArgs;
     char * sm_ToolWindow;
     struct WBArg * sm_ArgList;
   };

>What's the point of this? Workbench will pass variable numbers of arguments,
>and usually at least one (dirlock & name of the program itself).

  I don't want the locks. I pass the full file names. A possible modification
would use exec List instead of an array to hold the arguments.
  Note: the RogueLaunch program allocates memory for the argv and envp,
and copies. The child does own them. They are cleaned up by the cleanup
process. In order to provide the ability to invoke an synchronous task
and later decide to make it asynchronous (just don't close your window!)
I'll eventually turn this into rogue.library, and have it CreateProc()
an `init' process that will actually wait on the subprocesses, deallocate
storage and return error codes when you `RogueWait()' (or don't wait)
[who was it that was working on Edition 7 under AmigaDOS --- Doug Merrit
no? How is it going?]

>More details, please.

  fast:exp/src/rogue/_main.c:

  /* Copyright (C) 1986,1987 by Manx Software Systems, Inc. */

 [  What I'm to do about that line, I'm not sure yet. ]

  [blayh blah blah]

  pp = _FindTask(0L);
  if(alen) {
    _cli_parse(pp, alen, aptr);
    argc=_argc;
    argv=_argv;
    Enable_Abort = 1;
    _devtab[0].mode |= O_STDIO;             /* shouldn't close if CLI */
    _devtab[1].mode |= O_STDIO;
    goto normsetup;
  }
  else {
    int i;
    char *window;
    long wind;
    struct FileHandle *fhp;

    _WaitPort(&pp->pr_MsgPort);
    RogueStartMsg = (struct RogueStartup *)GetMsg(&pp->pr_MsgPort);
    if(RogueStartMsg->rs_dummy==0) {
      argv=RogueStartMsg->rs_argv;
      argc=RogueStartMsg->rs_argc;
      environ=RogueStartMsg->rs_environ;
      pp->pr_CurrentDir=RogueStartMsg->rs_CurrentDir;
      CurrentDir(RogueStartMsg->rs_CurrentDir);

      if(window=RogueStartMsg->rs_ToolWindow) {
        if(wind = _Open(window, MODE_OLDFILE)) {
          fhp = (struct FileHandle *) (wind << 2);
          pp->pr_ConsoleTask = (APTR) fhp->fh_Type;
          pp->pr_CIS = (BPTR)wind;
          pp->pr_COS = (BPTR)_Open("*", MODE_OLDFILE);
          goto normsetup;
        }
      }
      else if(RogueStartMsg->rs_fhc) {
        for(i=0; i<RogueStartMsg->rs_fhc; i++) {
          _devtab[i].fd=RogueStartMsg->rs_fhv[i];
          if(i<32) {
            if((RogueStartMsg->rs_closebits[0]&(1L << i))==0) {
              _devtab[i].mode |= O_STDIO;   /* shouldn't close if CLI */
            }
          }
        }
        pp->pr_CIS=_devtab[0].fd;
        pp->pr_COS=_devtab[1].fd;
      }
      else {
       normsetup:
        _devtab[0].fd = _Input();
        if(_devtab[1].fd = _Output())
                _devtab[2].fd = _Open("*", MODE_OLDFILE);
      }
    }
    else {
      /* We'd do the normal Workbench thing here */
      /* I suspect that this branch crashes. I don't run workbench and
         draw icons often enough to have every tried it.*/
      _exit(254);
    }
  }
  _exit(main(argc, argv));  /* so much for `void main()' :-) */
}

>    if((pin=AllocMem(sizeof(struct FileHandle),MEMF_PUBLIC|MEMF_CLEAR))==NULL) {
>      return(NULL);
>    }
>    if((pout=Open("PIP:4096",2000L))==NULL) {
                              ^^^^^

  man:util/ConMan.doc:
                                 ConMan V1.3
                   Copyright (c) 1987, 1988 by William S. Hawes
  ....

   ConMan is also a pipe-handler responding to the name PIP:NNNN, where
   NNNN is the "capacity" of the pipe.  It must be opened using a private
   packet called ACTION_DOUBLE (value 2000L), and the filehandle you get
   from a call to Open("PIP:",2000) counts for two and so can be cloned
   by your program.  After allocating a filehandle structure (using the
   AmigaDOS memory conventions), just copy the filehandle from Open()
   into the new structure --- and don't forget to Close() both of them!
   My WShell command shell uses the ConMan PIP: device as its pipe handler.

  Does this follow better now?

>(too bad there's no DupFH call. Commodore? Are you there Commodore? How about
> for 1.4?)

  YES. PLEASE.
  I believe that Colin Plumb had some other things to peeves having to
do with getting path names from FileHandles. I think they deserve to be
repeated...

 (Colin: remember that `message' you wrote me concerning CRCs? All 22k of it?
I posted it as crcinfo.zoo on 1:163/109 [aka atronx.UUCP, soon to be amiga.ottawa.on.ca].
The download count is quite respectable...)

>Sounds good. Where's the code?

  Coming. I want a working popen() call and I have to write the environment
variable stuff...

>Why don't you do this?
>
>        sprintf(PipeName, "%s:rogue%dpipe%d", PipeDevice, ProcessId, Sequence++);
>        pin = Open(PipeName, MODE_NEWFILE);
>        pout = Open(PipeName, MODE_OLDFILE);

  My last resort. Pipe: doesn't like.
  I've spent hours running dnet both here to school, and between myself and
other people, and I've _never_ gotten the scli server to work the DPIPE:,
or Matt's original pipe, or the 1.3 pipe...

  It took me three days to run Markus Wandel's exec disassembly because I
couldn't get the pipes to work. They just don't like me.




--

  :!mcr!:
  Michael Richardson
                    Amiga
             v--------+
 HOME: mcr@julie.UUCP | SCHOOL: mcr@doe.carleton.ca
 Fido: 1:163/109.10<--+ WORK: michael@fts1.UUCP
Technical Details
Message-ID: <1718.AA1718@julie>
Path: arc1-ca.pugleaf.net!utzoo!dciem!nrcaer!fts1!julie!mcr
References: <4689@sugar.hackercorp.com> <1610.AA1610@julie>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!dciem!nrcaer!fts1!julie!mcr
From: mcr@julie.UUCP (Michael Richardson)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Using PIP:
Keywords: dupping closing pipes
Message-ID: <1718.AA1718@julie>
Date: 16 Dec 89 08:11:38 GMT
References: <4689@sugar.hackercorp.com> <1610.AA1610@julie>
Followup-To: comp.sys.amiga.tech
Organization: Sandleman Software Works' Debugging Department, Ottawa, ON
Lines: 202