shadow@pawl.rpi.edu (Deven T. Corzine) (03/19/89)
Just a quick summary of the current state of a project of mine tentatively named "Amigix". I am in an information and idea gathering stage now, and welcome input from any and all, about what I should do, what I shouldn't, etc. Flames to /dev/null. Oh, yes. If you think of a better name than "Amigix", tell me. (I prefer Amix, but C-A took it... :-) The idea is to implement an environment which provides Unix V7 compatibility at the source code level, with SysV, BSD and amiga extensions as appropriate. This includes functions such as alarm(), dup(), fork(), exec(), read(), write(), open(), close(), etc. I also hope to implement shared text segments (resident programs, though not necessarily loaded if not in use at all) and if I get really sick I may take a stab at dynamic linking. (I'll hold off on that one quite a while, likely.) One important design goal is the same as for Exec: keep everything as dynamic as possibly and use dynamically allocated nodes in Exec lists for system structures instead of a static table. That way, you are limited only by the hardware capabilities of your machine, not by arbitrary choices in the operating system. The basic design is to have a run-time library (opened with OpenLibrary()) which implements the Amigix functions and utilizes a system task for coordination purposes. The system task will be an AmigaDOS process which coordinates the Amigix system and also makes calls to AmigaDOS for file system requests made by any Amigix process. (An Amigix process will NOT be an AmigaDOS process, and as such will be unable to directly use the dos.library routines.) The system task will also be responsible for (Amigix) process creation and termination, including full cleanup of allocated resources. It will coordinate communication with AmigaDOS and its own file system task (eventually) via Exec message passing. At that level, the message passing will be completely internal and transparent to the user. (Similar to AmigaDOS's packets.) An initialization program would create the system task and make the library, both from its own data (or maybe) code segment, and exit when the initialization is done, not having modified itself with, say, a seglist split... The allocation tracking routines will probably track for regular tasks and AmigaDOS processes, but do no automatic deallocation. Well, that's a quick summary, for now. Send any commants and ideas to shadow@pawl.rpi.edu, NOT deven@pawl.rpi.edu. Keep in mind that this project may or may not dissolve into Vaporix [:-)] due to time constraints, etc. So I'm not making any promises, but I hope to do it, sooner or later. When/if I do, I'll tell folks. 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.
johnm@trsvax.UUCP (03/23/89)
I like the idea but think it needs at least one more thing. A unix compatible wildcard expansion mechanism. With this we could build the set of unix tools that so many of us would like to have on our Amigas. A shell just doesn't cut it in many situations because... A) Many have really annoying restrictions on what you can enter in the shell. One of the older shells would not let you run EXECUTE under it. What a pain. B) Tools don't sit there continually sucking up memory. A shell does. C) You can't replace PART of a shell. You can replace ONE tool. Even if you only get partway, post what you get done. It will be welcomed. John Munsch
kevin@uts.amdahl.com (Kevin Clague) (03/24/89)
In article <261600001@trsvax> johnm@trsvax.UUCP writes: > >I like the idea but think it needs at least one more thing. A unix compatible >wildcard expansion mechanism. With this we could build the set of unix >tools that so many of us would like to have on our Amigas. A shell just >doesn't cut it in many situations because... > > A) Many have really annoying restrictions on what you can enter in the > shell. One of the older shells would not let you run EXECUTE under it. > What a pain. > > B) Tools don't sit there continually sucking up memory. A shell does. > > C) You can't replace PART of a shell. You can replace ONE tool. > >Even if you only get partway, post what you get done. It will be welcomed. > >John Munsch I appreciate the spirit of this posting, but let's not let it get into a religious discussion of wildcards like the one in comp.sys.amiga. Thanks, Kevin -- UUCP: kevin@uts.amdahl.com or: {sun,decwrl,hplabs,pyramid,seismo,oliveb}!amdahl!kevin DDD: 408-737-5481 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 [ Any thoughts or opinions which may or may not have been expressed ] [ herein are my own. They are not necessarily those of my employer. ]
deven@pawl.rpi.edu (Deven Corzine) (03/25/89)
In article <0fsYK90nyi1010tJHM2@amdahl.uts.amdahl.com> kevin@uts.amdahl.com (Kevin Clague) writes: >In article <261600001@trsvax> johnm@trsvax.UUCP writes: >>I like the idea but think it needs at least one more thing. A unix >>compatible wildcard expansion mechanism. With this we could build the >>set of unix tools that so many of us would like to have on our Amigas. >>A shell just doesn't cut it in many situations because... >> >> A) Many have really annoying restrictions on what you can enter in the >> shell. One of the older shells would not let you run EXECUTE under it. >> What a pain. >> >> B) Tools don't sit there continually sucking up memory. A shell does. >> >> C) You can't replace PART of a shell. You can replace ONE tool. >> >>Even if you only get partway, post what you get done. It will be welcomed. >I appreciate the spirit of this posting, but let's not let it get into >a religious discussion of wildcards like the one in comp.sys.amiga. The idea here is to make things as functionally compatible with Unix as is reasonably possible. The filename matching wildcard expansion is handled by the shell, and will be, but I may put in library routines to support it and make it easier to write different shells. For the shell *I* write, I fully intend to implement Unix-style wildcards (with some extensions I have in mind) AND Unix-style pathnames. (i.e. open("../file",...) would be internally translated to an AmigaDOS Open("/file",...) call, while "/file" would be translated to ":file", etc.) Later, I'll probably implement my own file system to go along with it, which will use the Unix syntax directly. For now, a simple translation and underlying calls to AmigaDOS for the actual FS management will work. I have some serious gripes with the Execute() function, and haven't decided whether or not to support it. As far as the C:Execute command goes, I don't expect to directly support that, either; that kludge is fairly tied to the CLI's mode of operation. I will, however, have a scripting language as part of the shell's functionality, and as such will be able to do all an AmigaDOS Execute script can do and more. Perhaps I will supply a shell script which aliases commands to make Execute scripts run under my shell. We'll see. The AmigaDOS CLI is a shell. A pathetically simple and poorly designed shell, but it IS a shell. And it is ALWAYS in memory, using that space. However, ALL the CLI's in the system use the SAME code for their CLI, so the overhead isn't so great; probably on the order of 10K + 1K/CLI or so... The shell I write I expect to be generally running with a shared text segment. Whether or not I'll try to implement shared text segments as part of the file system interface or not, I'm not sure. (Probably sooner or later, in some form.) I expect the complexity of the shell to be on the order of that of Unix sh or csh. (Though not early versions, of course.) The shell syntax will be quite similar as well. And many more tools, like filters and utilities, will NOT be built into the shell. There will be a dividing line. Who says you can't replace PART of a shell? That depends on what you want to replace and how the shell is implemented... (and you can always change the source and recompile.) Don't worry; I am sick of the wildcard flame wars, and they don't belong in comp.sys.amiga.tech anyhow. _I_ am implementing this, so it will be implemented _my_ way. The coder's rule: he who writes the code makes the rules. 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.
jesup@cbmvax.UUCP (Randell Jesup) (03/29/89)
In article <DEVEN.89Mar25014448@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: >For the shell *I* write, I fully intend to implement Unix-style >wildcards (with some extensions I have in mind) AND Unix-style >pathnames. (i.e. open("../file",...) would be internally translated >to an AmigaDOS Open("/file",...) call, while "/file" would be >translated to ":file", etc.) How are you going to deal with device and volume names? >The AmigaDOS CLI is a shell. A pathetically simple and poorly >designed shell, but it IS a shell. And it is ALWAYS in memory, using >that space. However, ALL the CLI's in the system use the SAME code >for their CLI, so the overhead isn't so great; probably on the order >of 10K + 1K/CLI or so... CLI is MUCH smaller than 10K, AND it's in ROM. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
deven@pawl.rpi.edu (Deven Corzine) (03/30/89)
In article <6405@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >In article <DEVEN.89Mar25014448@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: >>For the shell *I* write, I fully intend to implement Unix-style >>wildcards (with some extensions I have in mind) AND Unix-style >>pathnames. (i.e. open("../file",...) would be internally translated >>to an AmigaDOS Open("/file",...) call, while "/file" would be >>translated to ":file", etc.) > How are you going to deal with device and volume names? A fair question. Undecided. Possibly I will stick to the device:path approach, though contrary to the general scheme of Unix. I suppose I COULD implement it as /dev/device/path, but that seems rather contrived and awkward, so... Of course, there is the point that Unix is NOT well suited for a floppy disk-based environment... allowances must be made. (along with changes. I see things in Unix to be improved upon.) >>The AmigaDOS CLI is a shell. A pathetically simple and poorly >>designed shell, but it IS a shell. And it is ALWAYS in memory, using >>that space. However, ALL the CLI's in the system use the SAME code >>for their CLI, so the overhead isn't so great; probably on the order >>of 10K + 1K/CLI or so... > CLI is MUCH smaller than 10K, AND it's in ROM. Good. It would be a sad commentary on someone if it were as large as 10K for what little it does. A more realistic estimate is maybe 1-2K, depending mostly on the overhead of BCPL... [but of COURSE it's in ROM... :-)] BTW, why is it that C:Execute is 8K [or so] simply to execute a command file, when the code is clearly in ROM or in the boot code of AmigaDOS to begin with, for S:Startup-Sequence behaves no differently from any other execute file... except that it does not require C:Execute to exist... [well, I suppose .key type stuff may not be supported [or logical] for the startup-sequence, but the point remains...] 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.
brant@uf.msc.umn.edu (Gary Brant) (04/01/89)
In article <DEVEN.89Mar30045831@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: +In article <6405@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: + +> How are you going to deal with device and volume names? + +A fair question. Undecided. Possibly I will stick to the device:path +approach, though contrary to the general scheme of Unix. I suppose I +COULD implement it as /dev/device/path, but that seems rather +contrived and awkward, so... + +Of course, there is the point that Unix is NOT well suited for a +floppy disk-based environment... allowances must be made. (along +with changes. I see things in Unix to be improved upon.) Just sticking my $0.02 in here; I think that your system would be much more useful if you stay compatible with the AmigaDOS file system, at least to the extent that they can coexist on the same disk/ partition. This way all files would be accessible from either system (an important consideration I think). I also think that AmigaDOS deals with named volumes better than *nix. Count me as another who would love to see V7 functionality on the Amiga & couldn't care less whether internally it is really *nix in the purist sense. + + +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. -Gary Brant ARPA: brant@uf.msc.umn.edu
deven@pawl.rpi.edu (Deven Corzine) (04/02/89)
In article <11844@umn-cs.CS.UMN.EDU> brant@uf.msc.umn.edu (Gary Brant) writes: >Just sticking my $0.02 in here; I think that your system would be >much more useful if you stay compatible with the AmigaDOS file system, >at least to the extent that they can coexist on the same disk/ >partition. This way all files would be accessible from either system >(an important consideration I think). I also think that AmigaDOS >deals with named volumes better than *nix. Without doubt, AmigaDOS deals with named volumes far better than Unix systems do. To begin with, I intend to internally have the open() function actually call the AmigaDOS Open() function (along with some other file descriptor initialization) and use AmigaDOS files. Later, I hope to write my own filesystem, similar to the Unix FS, but dealing with named volumes better, as AmigaDOS does. At that point, it can run either standalone or alongside AmigaDOS. (Unlike Amix, I'm afraid.) So, yes... files will be cross-accessible. 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.