TUHS February 2002

tuhs@tuhs.org

35 participants
45 discussions

by Rhys Weatherley

Hi, I've been lurking here for a week or two, reading the archives on porting v7 to x86, etc. On a lark, I downloaded the v7 sources and started to "upgrade" them so the userland can build and run on top of modern OS kernels such as Linux. The bulk of libc is the same (warts and all), with the "sys" layer replaced with modern syscalls. Perhaps it is a bit "sacrilegious", but I believe it makes the code more accessible for experimentation, and it should solve the "how do we get a PDP-11 compiler" problem: we use the original hosted on top of a modern kernel as a cross-compiler. Check it out and let me know what you think. Most of the libraries have been upgraded, with a handful of the simpler command-line utilities. http://www.southern-storm.com.au/v7upgrade.html Cheers, Rhys.

23 years, 1 month

I N T E R N E T I N C O M E ! ! !

by casanndra2002＠yahoo.com

23 years, 1 month

Legal ramifications putting certain things on my web site?

by Derrik Walker v2.0

I've started porting some of the old UNIX programs to Mac OS X. I've got about 1/2 the games, that should be ok, but I also have other things like crypt and makekey. I'd like to make these available in binary form, but I don't want the men in black knocking at my door either... Any thoughts? On a side note, I simply can not believe how easy it is to compile this old code under Mac OS X. for some of it, it's proving easier than porting Linux code ( if you've only known how long I worked on linux's fortune, and the old one just compiled no fuss, no problems ). Also, if your wandering why ... that's easy, because I can. Thanks. - Derrik firebug(a)apk.net http://junior.apk.net/~firebug --------------------------------------------------------------------------------------------------- The number of UNIX installations has grown to 10, with more expected. -- The Unix Programmer's Manual, 2nd Edition, June 1972

23 years, 1 month

[pups] PDP11-23

by Pieter Visser

Hello, I ám still have a working Dec pdp11-23. It runs on CTS-300 with 10 Mb Harddisk and a Tape drive for back-ups I think the programm is writen in dibol. I f you want more information about this system please reply by email If anyone can help me with the following questions. Can i connect an windows/dos sytem to the pdp11-23 and run the program. Is it possible to copy the program and run it on a Windows/Dos based machine. Hope to hear from sombody, Pieter Visser The Netherlands e-mail p.visser(a)tip.nl handy +31-(0)6-53630275 phone +31-(0)165-313597 work +31-(0)76-5022800 fax +31-(0)76-5022090

23 years, 1 month

Re: Porting Unix v6 to i386

by Aaron J. Grier

On Fri, Feb 01, 2002 at 10:24:30AM +0000, P.A.Osborne wrote: > The reason I want the compiler is that it will generate standalone 16 > bit code on a sensible platform. GCC doesnt produce 16 bit code as > far as I am aware - so personally I thought it would be amusing (I > must be mad) to use tools that run under DOS (well OS/2). support for PDP-11 was added to gcc a few months ago. I don't think it's been well tested, but support exists in current versions of binutils and gcc. http://pdp11.nocrew.org/ there's also support for the m68hc11/12 which are 16-bit. it seems like support for 80{,1,2}86 in gcc should be possible; it just hasn't been done yet. another compiler that might be worth looking at is SDCC http://sdcc.sourceforge.net/ which is currently targeted towards 8-bit MCUs. of course bootstrapping via the original K&R compiler would be the "classic" way to do it, though. ;) -- Aaron J. Grier | "Not your ordinary poofy goof." | agrier(a)poofygoof.com "[...] I generally haven't found IDM guys to be very good live acts, most of them just sit down at their laptop and tweak reaktor." -- Brandon Daniel

23 years, 1 month

Re: [TUHS] Re: Porting Unix v6 to i386

by John Holden

Aaron J. Grier wrote :- > support for PDP-11 was added to gcc a few months ago. It's been around since 1991 as a patch, but it didn't keep up with the newer versions of gcc

23 years, 1 month

Re: [pups] screen 3.9.9 vs. 2.11BSD write() to fifo and/or select() on socket

by Steven M. Schultz

Hi - > From: David W Talmage <talmage(a)cmf.nrl.navy.mil> > I thought that I'd read in the FM that they do. I see now that I was > mistaken,perhaps delusional. I see now that <sys/stat.h> contains the gospel: > > #define S_IFIFO 0010000 /* named pipe (fifo) - Not used by 2.11BSD */ :) Adding FIFOs to the kernel would make an interesting project though - perhaps when I become inspired/motivated I'll give it a try. > Sounds like I'm in for some deep hacking if I continue with this. Will > overlays help me here? Overlays will help if the code comes out to more than 64KB. Alas, overlays will _not_ help the dataspace requirements. The last time I looked at 'screen' I saw things like "char buf[32768];' sprinkled thru the code. So you might be in for some serious hacking to trim back the sizes of arrays/buffers/etc. It probably would also be a good idea to 'string'ify the program (there are tools to assist doing this - take a look at how sendmail and lint are built). > I wonder if setitimer() will fare any better. alarm() is obsolete. The gospel according to /usr/src/lib/libc/gen/alarm.c says: /* * Backwards compatible alarm. */ #include <sys/time.h> #include <unistd.h> unsigned int alarm(secs) unsigned int secs; { struct itimerval it, oitv; register struct itimerval *itp = ⁢ timerclear(&itp->it_interval); itp->it_value.tv_sec = secs; itp->it_value.tv_usec = 0; if (setitimer(ITIMER_REAL, itp, &oitv) < 0) return (-1); if (oitv.it_value.tv_usec) oitv.it_value.tv_sec++; return (oitv.it_value.tv_sec); } <g> > I'll send a progress report if I decide to continue this project. Thanks for > your help, Mr. Schultz. What I think you're seeing is the race condition that fork() has - there is no guarantee which process (parent or child) runs first. The test program does the fork() and the child runs to completion before the parent enters the select(). At that point the parent will wait until the alarm goes off. One thing you might try is create two separate programs. One would create the socket and wait for the other program to connect and send a string. If that works it shows that the UNIX domainsockets are working as expected and that the fork() race is indeed the problem. IF the client/server tests fail then there is something wrong in the UNIX domain socket handling that needs to be addressed. Good Luck! Cheers, Steven Schultz

23 years, 1 month

Re: [pups] screen 3.9.9 vs. 2.11BSD write() to fifo and/or select() on socket

by Steven M. Schultz

Hi! > From: David W Talmage <talmage(a)cmf.nrl.navy.mil> > Would someone please advise me about fifos and sockets in 2.11BSD? Ok ;) Don't use fifos - they don't exist (as you probably have found out by now :)) > I'm having > trouble porting screen 3.9.9, the multiplexing terminal emulator, to 2.11BSD fifos and sockets are just the tip of the iceberg when it comes to 'screen'. Eons ago (when screen was a fairly new program) I made an attempt at porting it and ran into the address space problems - seems that screen wants to use lots of large buffers, has lots of strings (all the help, etc) and so on. > because of them. I'm running Mr. Schultz's 2.11BSD with all patches up to > #442 on Mr. Brandt's p11 emulator version 2.9. FWIW, I have INET in my kernel > but I've ifconfig-ed only lo0. Thanks for the "ownership" label but I think of it more as being a 'steward' and coordinator than anything else p11 2.9? Wow, I've an old patched/hacked 2.5 because I can't seem to find p11's home now - begemot.org doesn't mention anything about "p11". > The fifo test portion of the configure script fails when writing to the fifo. > The write() returns -1 and sets errno == 79, "Inappropriate file type or Right, FIFOs don't exist. One of those things I never could find the need or time for ;) > format". This happens when I run the test as root, as I must in order to use > mknod() to create the fifo. See fifotest.c, below. If 2.11's mknod can create fifos that is _news_ to me. I don't recall seeing (or adding) that capability. > screen can use sockets instead of fifos. That portion of the configure script > fails as well. It fails in that it does not return from the select() on the > socket until the alarm goes off. See socketstest.c, below. Now that is very strange. Unix domain sockets do work (syslogd uses them for example) so I'm at a loss to explain why the test program isn't working. One thing I did do is after running "./a.out&" was do an immediate 'ps'. That should see 2 a.out processes due to the 'fork()' call. I only say one. This tells me that the alarm was started (obviously since alarm(5) is the first thing executed) but the child process raced thru and exited before the parent got to the select() call. With the child exited the select() will block until interrupted by the alarm() call. Steven Schultz sms(a)2bsd.com

23 years, 1 month

[pups] screen 3.9.9 vs. 2.11BSD write() to fifo and/or select() on socket

by David W Talmage

Would someone please advise me about fifos and sockets in 2.11BSD? I'm having trouble porting screen 3.9.9, the multiplexing terminal emulator, to 2.11BSD because of them. I'm running Mr. Schultz's 2.11BSD with all patches up to #442 on Mr. Brandt's p11 emulator version 2.9. FWIW, I have INET in my kernel but I've ifconfig-ed only lo0. screen's configure complains that it finds no usable fifo or socket. The fifo test portion of the configure script fails when writing to the fifo. The write() returns -1 and sets errno == 79, "Inappropriate file type or format". This happens when I run the test as root, as I must in order to use mknod() to create the fifo. See fifotest.c, below. screen can use sockets instead of fifos. That portion of the configure script fails as well. It fails in that it does not return from the select() on the socket until the alarm goes off. See socketstest.c, below. /* fifotest.c */ #include "confdefs.h" #include <sys/errno.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> /* #ifndef O_NONBLOCK #define O_NONBLOCK O_NDELAY #endif #ifndef S_IFIFO #define S_IFIFO 0010000 #endif */ char *fin = "/tmp/conftest254"; main() { struct stat stb; int f; (void)alarm(5); #ifdef POSIX if (mkfifo(fin, 0777)) { #else if (mknod(fin, S_IFIFO|0777, 0)) { #endif printf("mknod failed\n"); perror("mknod"); exit(1); } if (stat(fin, &stb) || (stb.st_mode & S_IFIFO) != S_IFIFO) { printf("stat failed\n"); exit(1); } close(0); #ifdef __386BSD__ /* * The next test fails under 386BSD, but screen works using fifos. * Fifos in O_RDWR mode are only used for the BROKEN_PIPE case and for * the select() configuration test. */ exit(0); #endif if (open(fin, O_RDONLY | O_NONBLOCK)) { printf("open #1 failed\n"); exit(1); } if (fork() == 0) { printf("f0\n"); close(0); if (open(fin, O_WRONLY | O_NONBLOCK)) { printf("f0 open #2 failed\n"); exit(1); } close(0); if (open(fin, O_WRONLY | O_NONBLOCK)) { printf("f0 open #3 failed\n"); exit(1); } if (write(0, "TEST", 4) == -1) { /* FAILS HERE */ printf("f0 write failed %d\n", errno); perror("write"); exit(1); } exit(0); } printf("f1\n"); f = 1; if (select(1, &f, 0, 0, 0) == -1) { printf("f1 select failed\n"); exit(1); } exit(0); } /* socketstest.c */ #include <sys/types.h> #include <sys/socket.h> #include <sys/un.h> #include <fcntl.h> char *son = "/tmp/conftest254"; main() { int s1, s2, s3, l; struct sockaddr_un a; (void)alarm(5); if ((s1 = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) { perror("socket"); exit(1); } a.sun_family = AF_UNIX; strcpy(a.sun_path, son); (void) unlink(son); if (bind(s1, (struct sockaddr *) &a, strlen(son)+2) == -1) { perror("bind"); exit(1); } if (listen(s1, 2)) { perror("listen"); exit(1); } if (fork() == 0) { if ((s2 = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) { perror("f0 socket"); kill(getppid(), 3); } (void)connect(s2, (struct sockaddr *)&a, strlen(son) + 2); if (write(s2, "HELLO", 5) == -1) { perror("f0 write"); kill(getppid(), 3); } exit(0); } l = sizeof(a); if (close(0) == -1) { perror("close"); } if (accept(s1, &a, &l)) { perror("accept"); exit(1); } l = 1; if (select(1, &l, 0, 0, 0) == -1) { /* DOESN'T RETURN BEFORE SIG_ALARM */ perror("select"); exit(1); } exit(0); } -- David Talmage (talmage(a)cmf.nrl.navy.mil) ITT Industries, Advanced Engineering & Sciences, Advanced Technology Group

23 years, 1 month

4.4BSD-Lite binaries for SPARC and PMAX

by Jochen Kunz

Hi. I plan to do a BSD exhibition at the VCFE. Main focus is 4.3BSD{,-Tahoe,-Reno} on VAXen. But I want to show 4.4BSD-Lite on HP300, SPARC and PMAX too. I have the 4.4BSD-Lite HP300 binaries, but nothing for SPARC and PMAX. Are there any binaries still around? I don't want to struggle with a SPARC and PMAX bootstrap... Ahh, and 4.2BSD-Reno for HP300 is missing too... -- tschüß, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/

23 years, 1 month

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS February 2002