Path: utzoo!attcan!uunet!steinmetz!itsgw!rpi!rpi.edu!shadow From: shadow@pawl.rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: Unix V7 functionality under (or along with) AmigaDOS? (*LONG*) Message-ID: Date: 17 Mar 89 22:08:47 GMT References: <6157@cbmvax.UUCP> <6185@cbmvax.UUCP> <6237@cbmvax.UUCP> <6298@cbmvax.UUCP> Sender: usenet@rpi.edu Reply-To: shadow@pawl.rpi.edu (Deven Thomas Corzine) Distribution: comp Organization: RPI Public Access Workstation Lab, Troy NY Lines: 100 In-reply-to: jesup@cbmvax.UUCP's message of 15 Mar 89 23:23:05 GMT In article <6298@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >In article deven@pawl.rpi.edu (Deven Corzine) writes: >>>>Say, if I replaced that Command Dir lock that's in the CLI structure >>>>for that one CLI process, would it look there without having to >>>>assign c: elsewhere? >> >>> You believed the name of the field, didn't you? Poor naive boy. :-) >>>It's really the BPTR to the path list. >> >>Figures. What form is this path list in? BCPL array of BSTRs? BCPL >>array of locks? Something else? > BPTR to a linked (BPTR) list of locks. (as in: {BPTR next; >BPTR lock;}). (Note all locks are BPTRs to filelock structure (or >things bigger than filelock structures)). Ok. I understand... >>In other words, there would be a program which would be run (from the >>CLI or Workbench) which would initialize the Unix-type system, install >>the run-time library as permanently ram-resident, You can do this >>easily, can you not? I mean, without dealing with LIBS: and >>disk-based libraries and all that? I want the library to be part of >>the data (and/or code) of this executable program, and have it use >>that to install it as a permanently ram-resident Exec Library, without >>any such library in LIBS:... I haven't looked closely at the Library >>routines, but as I recall, it seemed doable enough. > Sure, just make sure it isn't unloaded (cli_module = NULL), and >do a MakeLibrary exec call. cli_module? That's the seglist for the loaded program in the CLI structure, isn't it? I intended to use AllocMem (or AllocEntry, maybe) and copy the data, allowing the CLI/Workbench to unload it, or whatever. Either way, I guess. >>The original program would return to caller after completing >>initialization and starting the separate system process, so as to >>avoid any hassles with having to RUN the program, etc. > Will work fine. I have a significant question as to the operation of AddTask(), RemTask() and the relationships between them, memory allocation and task termination. The Exec RKM (V1.1) is rather unclear, I'm afraid... First, AddTask(task,initialPC,finalPC). I understand that task is a pointer to an initialized task structure and initialPC is the entry point of the task. That's straightforward enough. My question concerns the finalPC argument. If finalPC is 0, does it simply cause a RemTask(), or will it follow the list in the tc_MemEntry field and FreeEntry() for each entry in the list? (Or does RemTask() do this?) Does it free the memory associated with the task structure itself, or the tc_MemEntry list? Does it try to? If you can, would you post the actual code it uses when you specify 0 for finalPC? It would make things much clearer. As for RemTask(), does it ONLY remove the task from the Exec task ready/waiting queue, (between a Disable()/Enable() pair, of course) or does it try to do any memory or resource deallocation as per above?? It makes a big difference... >>One more thing. I need a name. "Unix" is clearly out. "Amix" I >>rather like and would use, but now it's taken, too. "Minix" I don't >>especially like and would give the wrong impression, as this would not >>be a Minix port. >... >>I'm pretty much at a loss for what to call it. It would probably be >>nice to have it end in "ix", just for consistency. (everyone ELSE >>does it!!) :-) So... have you (or anyone) ANY suggestions what this >>could be called? > Well, if it takes forever to finish, you could call it Vaporix. :-) >How about Maxix? Micrix? Amigix? (AIX is out) Fooix, Barix, FooBarix? >Fix? Trix (maybe GNU or some such grabbed this) Vix (visual Unix)? It make take awhile, but hopefully not forever. Amigix seems the best of those... FooBarix is amusing, though... :-) >>p.s. I saw your old address in shell.doc on that shell 1.03 beta >>disk... 2340 15th Street??? I live at 2346!! Hey, we're neighbors! > Yup, used to live there around 2 years back. Had friends that lived >at 2348 (the "O-den"). Isn't the circularity of the world suprising? 2348? (like, on the corner?) All I know is there's a doctor's office there... (and they don't ike us parking in the lot...) >-- >Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.