Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!pdn!palan!ckctpa!crash From: crash@ckctpa.UUCP (Frank J. Edwards) Newsgroups: comp.sys.amiga.programmer Subject: Re: RCS (and porting GNU stuff) Message-ID: <1991Jun14.170211.1525@ckctpa.UUCP> Date: 14 Jun 91 17:02:11 GMT References: <1991Jun11.224756.18225@sol.UVic.CA> <1991Jun12.081252.11729@newshub.ccs.yorku.ca> Organization: Edwards & Edwards Consulting Lines: 191 In article <1991Jun12.081252.11729@newshub.ccs.yorku.ca> shields@nexus.yorku.ca (Paul Shields) writes: >denhaana@sol.uvic.ca (Albert Den Haan) writes: >> I ftp'ed the RCS implementation from ab20 >>last week in hopes of getting the same facilities on my amiga. No such luck. > >I'd love a working RCS for Amiga. Hmmm. I have one which I use all the time under AmigaDOS -- both 1.3 and 2.0[24]. One thing though: make sure the stack is at least 25K and 40K would be better. It was posted to comp.binaries.amiga quite awhile ago; check archive sites for it. The binaries must have been posted during '89 or early '90 because there's an "unofficial rcs patch" in v90i134 of the c.sources.a archive. >[...] >I haven't ported any Unixy/Gnuy stuff to Amiga. But I have tried porting >such programs to MS-DOS. The issues are usually: Basically the same, with a couple of additions... > - compiler .. the choices seem to be SAS or Manx. Portable programs > strictly conforming to ANSI C should not break the compiler, but they > do anyway. Compiler bugs may break code in statements or macros that > are fairly complex. This forces you to exercise all of the code to > verify that it works the same under Amiga as Unix, so extensive testing > is necessary. Good run-time debugging facilities are helpful, as is > having a Unix machine around to compare behaviour. I have had to port a Un*x cpp program in order to run Un*x code through it to generate the ".i" (preprocessed) file and _THEN_ compile it with Lattice/Manx ("Lattice" because this was awhile ago :-) Definitely use the Commodore developer tools (it's worth becoming a developer _just_ to get some of the great tools those guys write), such as Enforcer (traps reads/writes to inviolate memory), MungWall (pads memory in front of and behind memory allocations/frees in an attempt to cause Enforcer hits if you use free'd memory), and others. > - operating system calls .. Amiga O/S calls are not very > helpful. Semantics of the filesystem may differ enough to cause > problems. Big point here: only one task can have a file open for write at a time. This was a big problem for the C News "expire" and "relaynews" programs, since they open a file then attempt to unlink (remove) it. Can't be done while the file is open... > Environment variables differ radically. Process > creation mechanisms differ radically: fork(), exec(), system(), popen() > may not be present and may be broken. Many programs (probably > RCS, too) execute a fork() then exec() a Unix command in the > child process. Managing something as simple in Unix as pipes can > become a nightmare. Yes and no. Most code does fork() immediately followed by exec(). This is easily arranged with a function call which has been #ifdef'd into place as a substitute for fork/exec. "system()" is the same way. And pipes are not all that tough using the 2.0-specific System() call. (In fact, I have some routines which emulate the popen/pclose functions under both 1.3 and 2.0, but 2.0 is the only one I understand! ;-) > - run-time libraries .. depend on what comes with the compiler and > are by no means complete. this was the biggest factor porting to > MS-DOS. standard functions and whole systems available in all Unix's > were not present, like regexp, dbm, curses, and termcap. This is a major problem. However, the C News "dbz" package can be used (almost) anywhere that dbm is used (big caveat regarding dbz "assumptions" so don't just presume plug'n'play). There are also regexp functions available in source form (I use the GNU package). Curses is another biggie -- I cheated on this one, but there are curses packages for the Amiga (all I've seen so far are SAS libraries) in beta test. If you need termcap instead, through out the code -- it's too old! The only portable cursor package is curses, and there are even some differences in implementations... > Several, > like open(), ioctl(), had weirdly different semantics which didn't > match Unix and broke instantly. See above. > - programming environment infrastructure.. the makefiles for the Unix > programs often assume the existence of other programs which have not > been ported, and assume the compiler has a standard set of switches. Yeah, this one's a real bummer. Especially the makefiles that call the shell with some fancy multi-line command sequence. Usually I comment out the original action(s) and hard code the equivalent steps, ie. ######################################################################## foo: bar cd ../include; for i in *.h; do mv $i `basename $i .H`.h; done ...becomes... foo: bar execute makefile.sh1 makefile.sh1 ---- cd /include list to t:xxx lformat "makefile.sh1b %s" execute t:xxx makefile.sh1b ---- ; Change the file given as first parameter to a different extension etc, etc. ######################################################################## > patch, unshar, uudecode, tar, compress, and ed often are necessary for > applying patches. No problem. There are implementations of patch, unshar, uu{en,de}code, tar, compress (mine does dynamic memory allocations ;-), and ed (called "ked" in the RCS package). > The software itself may require that "standard" > commands (sh, ed, sed, grep, sort, awk, date, dc, wc, etc.) be present > in order to work.. And it's vital that those must work exactly as > expected. Again, C News has these expectations because of all the shell scripts. I had to rewrite all the shell scripts into Execute scripts (and I'm still hearing about how they don't work!!). Most of these are available from various places: sed, grep (from SKsh), awk (GNU awk I ported myself), wc (from SKsh), and ed (from RCS). A couple of'em: "sort" and "dc" can be major problems. I don't port that code!! :-( Although sometimes I've found that the program uses sort or dc in only a very limited form. Actually, since there is a port of Perl for the Amiga, I was sorely tempted to use Perl for all of the C News scripts... But I didn't want to get into the position of having to provide such a large package just to get some simple control messages to work, etc. >...And now a complaint to the programming community, some of >which doesn't seem to have this down yet: > > If you make an Amiga (or MS-DOS) port or workalike of a Gnu or Unix > command which is a software building block, then you can't change > its features. Otherwise the porting curve for other software is > too steep. Ahhh, yes and no. If a feature is left out as being "too hard to implement", I don't mind -- if it's documented as such! But the statement above stands: don't change the way a feature works, or how it's invoked, without making it extremely plain that such-and-such has been done. > If you PD or sharware any such tool, PLEASE don't restrict its > use, and PLEASE release source... so that when somebody discovers > that the program is broken, they don't have to come back to you > to support it. I agree -- don't restrict its use. But concerning source... If it's going to be PD (or is GNU) then of course, but I think Shareware is another issue. When I released C News I did so as a service to the Amiga community. But my newsreader consisted of long hours spent (both by me and my beta testers -- thanks Larry! :-) trying to tune what the program did and how it functioned. I distributed the newsreader as shareware, without source, to secure the code. I didn't want someone complaining to me that his copy, which he got from Joe Schmoe, didn't work and would I please fix Joe's changes? The other constraint on source is the sheer bulk of it. Take the GNU C compiler, for instance. If someone ports it to the Amiga, then they have to make the source available under the terms of the GPL, but they don't have to provide it unless you ask for it and they can charge you for distribution/media/etc. C News wasn't covered by the GPL, and in fact the licensing _DID_NOT_ say that source had to be provided, but source was sent to Fred Fish anyway just to get the programming examples (and how to work around certain problems) out to the Amiga programming public. >thanks, >Paul Shields >shields@nexus.yorku.ca Your welcome. And I think a FAQ&A for porting code would be a good idea. Also, one site that kept track of the "ls-lR" listing of the Amiga archives would be great, ie. perhaps ab20 could keep on-line the volume listings for c.s.a, c.b.a, and perhaps the ones for c.s.{unix,misc,games} as well with a notation of which sites archive which newsgroups. Whew!! My ingers are tired (see ;-) so i'm going to sign off now. -- Frank J. Edwards | "I did make up my own mind -- there 2677 Arjay Court | simply WASN'T ANY OTHER choice!" Palm Harbor, FL 34684-4504 | -- Me Phone (813) 786-3675 (voice) | Only Amiga Makes It Possible...