Some notes on UnixWare

A long while back, I got this UnixWare 7 kit on ebay.. So I figured it was as good a time as any other to install it and give it a whirl…

Now one cool thing is that 7.1 will install on Virtual PC 2007, and runs quite nice.. The one trick is to not give it too much memory. I found that 1GB of ram made it run horribly, while 256MB had it running great.

Another weird thing is that if you suspend the VM for any reason, the network will stop working. The only fix is to reboot the VM. Also

Also the C compiler, while not the most feature rich one out there is amazingly fast.. It builds Quake in around 5 seconds, once all the source is ‘fixed’. Also if you want to build any X11 programs, be sure to install the linux compatibility, or have a handy source of X11 headers to grab, as for some reason my UW7 didn’t include them.. ?

So yes, with a bunch of tweaks from the SUN source version of QuakeWorld, here it is:

Quake-on-UnixWare

Quake 1 for UnixWare 7.

And naturally it’ll run Dungeon as well with some f2c magic. The only caveat is that you can’t build the libf2c with any optimizations or it’ll crash or give really strange results….

Dungeon 2.5.6 on UnixWare

Dungeon 2.5.6 on UnixWare

Dungeon 2.5.6 on UnixWare.

Other then that, UnixWare is just another SYSV wrapped up in CDE. But I do recall it being used in the call center world, in conjunction with some seriously old unix machines (think NCR 386!), mostly doing voicemail and other stuff. I think it was the UnixWare 2.x stuff that all included that PC emulation software that could run Windows with the Netware client.. OH the horrors of someone loading up that and lotus notes to check mail on the VM server.. people did notice!!!!!!

I’m not sure if people still use UnixWare with Avaya G3’s anymore.. I know the G3’s were busy moving to linux, but I don’t know about all the support stuff, so for all I know CMS & friends still run on Solaris/UnixWare.

It’s a shame UnixWare got a bad rep from the SCO lawsuits, as it’s a pretty fast & responsive Unix, and too bad they never did get it ported to the Itanium & x64. I mean it’s still not too late, but I suspect the required investment to make it happen is just too great.

pcap and IPX/SPX

I found this link where someone had implemented a virtual NE2000 for DosBOX, allowing you to run among other things DOOM!

This reminded me of my own work to add pcap into Qemu back in the 0.9.0 days… SO I figured I’d try to build the thing out and see how they interact!

So the first thing to do was build DosBOX, and add the patch. I found that 0.73 worked pretty well for this!

So after some hammering around, I got it to build, and launched it on two separate machines (one over terminal server) on my lan, and launched the oldest network doom version I could find to get things going.

Doom multiplayer IPX-SPX

Doom multiplayer IPX-SPX

And there we go. Now in the dosbox.conf you have to make sure that they have unique MAC addresses, and of course, that they are bound to the correct physical nic. in the config file, there is a list option that will print out the possible choices then you can just put the number, or the full name into the right spot on the ini file. I’ve build a prebuilt win32 version of this with all the DLL’s and the gravis ultrasound enabled… You can download it here.

The next thing I did was search high & lo for my patches to Qemu, and thankfully I’d emailed them to myself as it seems all the other places are dead… So with a little playing with Qemu 0.90 to enable the adlib, and remove some logging messages, I’d built a client machine again with Doom. Naturally I had the DosBOX & Qemu face each-other off.. Sadly this is a little SLOW.

DOSBox and qemu IPXSPX Doom

DOSBox and qemu IPXSPX Doom

For those that wish to download, you can find the Qemu client & server files.

Now for Qemu, you’ll need to get that full NIC name… Dosbox provides a great way to see what it is, just paste it into the batch files, and you’ll be good to go.

And remember you’ll need WinPcap installed!!!!!!

BSD-games & Solaris fun.

I was getting bored with a stock Solaris 2.4 system, so I decided to load up some basic BSD games. Since I like the torture of it, I went to build them from source.

OH MY GOD.

I don’t mean to complain too much, but holy crap, the configuration for the BSD games package is INSANE.

After answering what feels like 100+ questions (it very well may be) you can eventually try to build BSD-games… but much to my dismay the 2.x series all hinges on you basically having a GNU environment, and well… I didn’t want to spend that much time just to run robots & fortune.

So thanks to this great page, there is some hints on building BSD=games 1.5 for Solaris… But where on earth to find something this old?! This is the weird thing, all of this older free software is being destroyed wholesale… I know right now people just don’t care, but there most certainly is this ‘digital’ divide that is coming, where most of our current history will be lost forever… Hell if nukes fell tomorrow, good luck to anyone decoding a DVD… And god help them if they succeeded. It certainly wouldn’t be worth the effort.

Anyways, with a bunch of searching I found a site in Germany with the goods.

Now the real fun starts…

I’m using gcc 2.8.1, because that is what was in the GNAT package. Anyways for some programs I was encountering errors like this:

gcc extern.o init_field.o main.o make_level.o move.o move_robs.o play_level.o query.o rnd_pos.o score.o flush_in.o -lncurses -lnsl -lsocket -L/usr/ucblib -R/usr/ucblib -lucb -o robots
Undefined first referenced
symbol in file
_tty main.o
_pfast main.o
_echoit main.o
_tty_ch main.o
_rawmode main.o
ld: fatal: Symbol referencing errors. No output written to robots
make: *** [robots] Error 1

I know.. .WTF?! So after building & rebuilding ncurses, I found on some obscure Fortran list that the linker in Solaris is… weird. So to save anyone the hell, here is the “correct” string in this instance.

gcc extern.o init_field.o main.o make_level.o move.o move_robs.o play_level.o query.o rnd_pos.o score.o flush_in.o -L/usr/ucblib -R/usr/ucblib -lcurses -ltermcap -lucb -lncurses -o robots

Notice the difference? Yeah, the big one, is that now it linked. The position of the -L & -R really matters to the SUN linker.

Another error I was getting (in this example from tetris) was this:

In file included from screen.c:59:
screen.h:62: parse error before `__P’
screen.h:63: parse error before `__P’
screen.h:64: parse error before `__P’
screen.h:65: parse error before `__P’
screen.h:66: parse error before `__P’
screen.h:67: parse error before `__P’
screen.h:68: parse error before `__P’

I assume in the future (or was it the past?) that this __P macro would be standard with GCC? Maybe it’s a linux-isim? I don’t know. What I do know is this block

#undef __P
#ifndef __P
#if __STDC__
#define __P(protos) protos
#else
#define __P(protos) ()
#endif
#endif

Will fix it.

Another weird error revolves around setjmp.h . Now I know in Solaris some headers have to be included in a certain order or all hell will break loose, or the part you are looking for just won’t be included. But I just mined out the relevant parts to get what I wanted…

In file included from /usr/ucbinclude/setjmp.h:44,
from screen.c:47:
/usr/include/sys/ucontext.h:24: parse error before `sigset_t’
/usr/include/sys/ucontext.h:24: warning: no semicolon at end of struct or union
/usr/include/sys/ucontext.h:25: warning: data definition has no type or storage class
/usr/include/sys/ucontext.h:28: parse error before `}’
/usr/include/sys/ucontext.h:28: warning: data definition has no type or storage class

So I just removed the reference to setjmp.h & instead put in this:

#define _JBLEN 10 /* ABI value */
typedef int jmp_buf[_JBLEN];

And it was happy. Now I know this is a HORRIBLE “FIX” but heh, sometimes you just want the dammed thing to compile!

Next I was getting these weird sigset_t errors…

screen.c: In function `stopset’:
screen.c:238: `sigset_t’ undeclared (first use in this function)
screen.c:238: (Each undeclared identifier is reported only once
screen.c:238: for each function it appears in.)
screen.c:238: parse error before `sigset’
screen.c:242: `sigset’ undeclared (first use in this function)
screen.c:244: parse error before `)’

And again I just mashed in the definition of:

typedef struct { /* signal set type */
unsigned long __sigbits[4];
} sigset_t;

Lastly was another error revolving around sig_t … So just inserting this:

typedef void (*sig_t) (int);

Into the code, got it to stop complaining.

So the upshot is that after manually linking a bunch of these programs, and manually installing the binaries & datafiles (Solaris 2.4’s install doesn’t work the way BSD-games 1.5 expects…) I finally could do this:

UNIX(r) System V Release 4.0 (solaris24)

login: rootb
Password:
Last login: Sat Dec 12 19:01:49 from qemunat
bash# fortune
There can be no twisted thought without a twisted molecule.
— R. W. Gerard
bash#

Now the big question…. Was it worth it?

Yeah sure, I learned a valuable lesson about the linker. The rest, not so valuable.

Frotz on Xenix

Well after having some fun with gcc, I wanted to try something a little more… “fun”. I’ve had good luck in the past with ‘dumb frotz‘ on the old BSD stuff (4.2/4.3 etc) but surprisingly I had no luck at all with gcc & xenix.

Well that was rather odd.

So in some crazed attempt I tried the regular version of Unix Frotz 2.32. Xenix was lacking the memmove procedure, but thanks to an old post here, I was able to get it running under Xenix.

Ok, fair warning it is SLOW. It’ runs the cpu into 1.0 levels… I don’t know why. My attempts at building gdb and using it from that old Soviet site hasn’t met with much luck.

Oh, and it was easier to massage some make files with gnumake.

But it does run!

If anyone want’s to give it a whirl it’s available here.

Well today I got my new Dec Alpha running!

Ok, my friends say I’m insane to have bought this… but I couldn’t resist.

It’s a DEC Alpha 221164 machine, with 64MB of ram, and a 4GB disk!

It’s the best technology of 1996-1997!

So I’ve gone ahead and installed Windows NT 4.0 on the beast… at 600Mhz it’s pretty dammed fast… considering how old it is. Although I suspect a Pentium III I found in the garbage with a 1Ghz cpu is 2x faster…..

But at any rate, this is a DEC Alpha, the long time geek cpu of dreams etc…
What makes this slightly useful for me, is that I do have Visual C++ 4.0 & 6.0 for the Alpha. So at least I can build *SOME* stuff to run on the thing….

So I’ve been fighting the compiler, and it seems it’s default blended optimizations do *NOT* work on my machine.. I’m sure this will be fun down the road. However it seems setting the target cpu to the 21064 produces ok code.. I’ve got to bench the stuff, but at least my exe’s are not crashing.

So what have I manage to produce today so far?

Well…

unzip is a major one.. It’s hard to use a machine today without it.

The other thing I’ve manage to get running, is Quake! I’ve included my source & project trees as it was a feisty little thing to build..

I’m currently building & testing over terminal services so I don’t know what the speed is on the console… Also, this build does not include networking… I’m sure the winsock code will work just fine, I’m just not in a good position physically to test it, as Quake1 will *NOT NAT* correctly.. Also the SDL sound doesn’t actually output anything, so I’ve built it with the null sound driver..

I’d love to get that m68k->C build of frontier elite to go on the Alpha but I’m afraid my 64mb of ram will be a major constraint..

I know this isn’t much of an emulation thing, as the only emulator that possibly can run Windows NT for the Alpha costs upwards of $16,000 USD… It’s cheaper to score an alpha on ebay for $100 USD.

Well here is the screen shot…

Quake on the Dec Alpha

 

I know it’s not much to ‘look’ at, but the pallet is correct, because it’s a real Alpha!.. Unlike the MIPS thing.

More ports… more tradewars…

more etc…

Some of the stuff is getting ironed out, it plays better for sure.

I had to start separating things out to make some older C compilers happy…

I still do not understand how ‘float’ types keep changing sizes between 16bit/32bit compilers…. Was there ever ANY consistent floating point types in C between 16/32bit? It really sucks to have binary data and find out you cannot ‘read’ it…..

Did people just force people to dump their data into ASCII, and reload it into 32bit formats, and tell everyone to ONLY use 32bit?

I know I’m like 15 years late to this party, as everyone is going through the win32 to win64 thing… Although I’m surprised Tradewars C’s win64 version runs happily with a win32 generated data file…….

Oh and ports in this version:

MS-DOS (realmode)
Win16 (QuickC for Windows’s QuickWin)
Win32 (Visual C++ 1.0’s CLI libc.lib exe… )
Win64 (Visual Studio 2008 cli)
Linux (x86 built with debian -static…..)
OS/2 (16 bit built with Microsoft C 6)

Although it supports multiple users, it’s still a single player game… I suppose it shouldn’t be too hard to constantly check the user record & sector record of where they are with stuff changing…..?

Anyways my work is here: https://sourceforge.net/projects/tradewarsc/

Boring weekend…

Ok so I had a boring weekend…. And it’s spilled over to today.

I’m getting burnt out but what happened is I found out that Turbo Pascal 5.5 is now FREE!

Which I thought was VERY cool.. So after a while of googling around for neat & interesting Pascal stuff, I came across this BBS door game, called TradeWars, that included the source!

While going through the source it seemed it could be easily ported to C so I started late Friday (or was it Saturday AM?)…

Anyways I’d feel safe with a tentative ‘public’ release of the source..

My C is based on the Pascal, which is in turn based on the BASIC code.. I’ve tried to keep it true to the pascal so there is a LOT of 2 letter variables, and a lot of WTF’s? BUT I did add comments as I was going through it.

It *SHOULD* be somewhat portable C, and I haven’t included binaries just yet… It’s still a work in progress, but I wanted to let out a WIP thing…

You can find the project here: https://sourceforge.net/projects/tradewarsc/

Oh and a screenshot:

Trade Wars C 0.7 on Windows 3.0

Trade Wars C 0.7 on Windows 3.0

It builds on both 16bit & 32bit machines… Once I get it far more fleshed out & running then I’ll sanitize the data as for now it’s using the same data & message files…

Zork via FORTRAN

I don’t know why I even started down this path, but anyways I felt the urge today to break out some Fortran.  The problem is that I acquired Microsoft Fortran 5.0 in university, however… it’s on 5 1/4” diskettes!!!

So that wasn’t going to happen.

So I figured there had to be some kind of GNU Fortran compiler, and there is.. G77.  However it needs to be tied into a release of GCC.  Which sounds great, but I was hoping to build this on a few different platforms, and on my AMD 64 platform it’s GCC 3.3 (SUA), and on my NeXT it’s 2.5.8..  Even in the notes it says you’ll need about 100MB of space to build it, which is also a nice way of saying it’ll take FOREVER.

Then I remembered something we used on the RS/6000 because it was more ‘combatable’ then the Microsoft stuff, as it was derived from the first Unix Fortran compilers… f2c.

First you’ll need the source, which thankfully is still up on the original site  This part is a bit tedious as the source is not in a single easy to get file.  You’ll need to get the source from here.  Once you’ve downloaded the files, I’d recommend saving them somewhere else.. You don’t want to have to right click like wild to get them…  Alternatively I’ll host them all here to save someone all that effort.

Building f2c is really quite simple on any UNIX’like platform.  First you’ll need the f2c source, and unpack it somewhere….  Then you *MAY* have to adjust the makefile.u for the CC/CFLAGS variables as your C compiler may not be gcc or cc, also you may or may not want the –O flags (optimize).  On my NeXT I turned off the optimizations, since this is a 33Mhz machine, and I don’t want to wait all day, and I ran it with –O0 -pipe.  Then just simply run

make –f makefile.u f2c

bash-2.01$ make -f makefile.u f2c
cc -c -O0 -pipe main.c
cc -c -O0 -pipe init.c
cc -c -O0 -pipe gram.c
cc -c -O0 -pipe lex.c
cc -c -O0 -pipe proc.c
cc -c -O0 -pipe equiv.c
cc -c -O0 -pipe data.c
cc -c -O0 -pipe format.c
cc -c -O0 -pipe expr.c
cc -c -O0 -pipe exec.c
cc -c -O0 -pipe intr.c
cc -c -O0 -pipe io.c
cc -c -O0 -pipe misc.c
cc -c -O0 -pipe error.c
cc -c -O0 -pipe mem.c
cc -c -O0 -pipe names.c
cc -c -O0 -pipe output.c
cc -c -O0 -pipe p1output.c
cc -c -O0 -pipe pread.c
cc -c -O0 -pipe put.c
cc -c -O0 -pipe putpcc.c
cc -c -O0 -pipe vax.c
cc -c -O0 -pipe formatdata.c
cc -c -O0 -pipe parse_args.c
cc -c -O0 -pipe niceprintf.c
cc -c -O0 -pipe cds.c
if cc sysdeptest.c; then echo ‘/*OK*/’ > sysdep.hd; elif cc -DNO_MKDTEMP sysdept
est.c; then echo ‘#define NO_MKDTEMP’ >sysdep.hd; else echo ‘#define NO_MKDTEMP’
>sysdep.hd; echo ‘#define NO_MKSTEMP’ >>sysdep.hd; fi
ld: Undefined symbols:
_mkdtemp
rm -f a.out
cc -c -O0 -pipe sysdep.c
cc -c -O0 -pipe version.c
cc  main.o init.o gram.o lex.o proc.o equiv.o data.o format.o  expr.o exec.o int
r.o io.o misc.o error.o mem.o names.o  output.o p1output.o pread.o put.o putpcc.
o vax.o formatdata.o  parse_args.o niceprintf.o cds.o sysdep.o version.o  -o f2c

All being well, you’ll have a new & exciting f2c executable.  I manually just copy the f2c into /usr/local/bin & the f2c.h to /usr/local/include.

Next you’ll need the f2c io library.  Thankfully this one IS zipped up and it’s available here.  Alternatively I’ve got a copy here (better). *NOTE that the ‘official’ version of the lib doesn’t extract to a sub directory… Grr  Extract the library source, and again you may need to modify the makefile to suit your compiler (CC/CFLAGS).  Then go ahead and make the library.

make –f makefile.u

cc -c -DSkip_f2c_Undefs -O0 -pipe etime_.c
ld -r -x -o etime_.xxx etime_.o
mv etime_.xxx etime_.o
ar r libf2c.a f77vers.o i77vers.o main.o s_rnge.o abort_.o exit_.o getarg_.o iar
gc_.o getenv_.o signal_.o s_stop.o s_paus.o system_.o cabs.o ctype.o derf_.o der
fc_.o erf_.o erfc_.o sig_die.o uninit.o pow_ci.o pow_dd.o pow_di.o pow_hh.o pow_
ii.o pow_ri.o pow_zi.o pow_zz.o c_abs.o c_cos.o c_div.o c_exp.o c_log.o c_sin.o
c_sqrt.o z_abs.o z_cos.o z_div.o z_exp.o z_log.o z_sin.o z_sqrt.o r_abs.o r_acos
.o r_asin.o r_atan.o r_atn2.o r_cnjg.o r_cos.o r_cosh.o r_dim.o r_exp.o r_imag.o
r_int.o r_lg10.o r_log.o r_mod.o r_nint.o r_sign.o r_sin.o r_sinh.o r_sqrt.o r_
tan.o r_tanh.o d_abs.o d_acos.o d_asin.o d_atan.o d_atn2.o d_cnjg.o d_cos.o d_co
sh.o d_dim.o d_exp.o d_imag.o d_int.o d_lg10.o d_log.o d_mod.o d_nint.o d_prod.o
d_sign.o d_sin.o d_sinh.o d_sqrt.o d_tan.o d_tanh.o i_abs.o i_dim.o i_dnnt.o i_
indx.o i_len.o i_mod.o i_nint.o i_sign.o lbitbits.o lbitshft.o h_abs.o h_dim.o h
_dnnt.o h_indx.o h_len.o h_mod.o h_nint.o h_sign.o l_ge.o l_gt.o l_le.o l_lt.o h
l_ge.o hl_gt.o hl_le.o hl_lt.o ef1asc_.o ef1cmc_.o f77_aloc.o s_cat.o s_cmp.o s_
copy.o backspac.o close.o dfe.o dolio.o due.o endfile.o err.o fmt.o fmtlib.o fte
ll_.o iio.o ilnw.o inquire.o lread.o lwrite.o open.o rdfmt.o rewind.o rsfe.o rsl
i.o rsne.o sfe.o sue.o typesize.o uio.o util.o wref.o wrtfmt.o wsfe.o wsle.o wsn
e.o xwsne.o dtime_.o etime_.o
ar: creating libf2c.a
ranlib libf2c.a

This will take longer then f2c.. Or at least it did on my NeXT.

Then I just copied the library libf2c.a into /usr/local/lib then ran ranlib over the library again.

Ok now we should be able to build a FORTRAN program.  Let’s try something small.

      program hello
      print *, ‘Hello!’
      end

I’ve tried to preserve the leading 6 blank spaces.  You should be able to copy the above program, and save it as hello.f  Now we should be able to translate, compile and run the program!

bash-2.01$ f2c hello.f
hello.f:
   MAIN hello:
bash-2.01$ cc hello.c -lf2c -o hello
bash-2.01$ file hello
hello:  Mach-O executable (for architecture m68k) not stripped
bash-2.01$ ./hello
Hello!

Awesome!  Now let’s try something much bigger, say some old Fortran source to the old ‘dungeon’ game, better known as Zork!  This source is available all over the place as dungeon-2.5.6.tar.gz, and I’ll provide a link as well here.

Download, and extract the files (gzip –dc dungeon-2.5.6.tar.gz|tar –xvf –) and you’ll have your dungeon directory.  Building this should be pretty simple, if the above program built and ran without errors.  On my SUA (Vista) machine, I had to force the –I/usr/local/include flags to find the f2c.h..  So you may need some tweaking it all depends.

Again on my NeXT I changed the CFLAGS to –O0 –pipe.  On my Vista SUA I had to specify that CC=gcc.

Once done, go ahead and run make.

\ar d libdungeon.a dmain.o np2.o
\ranlib libdungeon.a
cc -s -o dungeon dmain.o np2.o -L. -ldungeon -lf2c -lm
f2c -A -C -Nn802 textcnv.f
textcnv.f:
   MAIN:
cc -O0 -pipe -c textcnv.c
cc -o textcnv textcnv.o –lf2c

If all went well that should be how the last lines look.  We should now have a dungeon executable!

bash-2.01$ file dungeon
dungeon:        Mach-O executable (for architecture m68k)

Awesome!

So let’s enter the game, shall we?

bash-2.01$ ./dungeon
Welcome to Dungeon.                    This version created 30-AUG-90.
You are in an open field west of a big white house with a boarded
front door.
There is a small mailbox here.
>

So, now we have built the f2c translation package, and managed to build a trivial hello world program, and something a little more complex like Dungeon/Zork.

Now I can play with my numerical recipes book with my pseudo Fortran kit.

Quake for the MIPS (NT4)

Well I started this off hoping I could get Quake running on Windows NT 3.1 … I’m almost there I have the null version running just fine. However I’m not all that great with DIB programming so I was looking thru SDL and saw that it has a WINDIB driver!

So with a LOT of tweaking through SDL 1.2.13 I got it to compile with Visual C++ 1.0!! However it is lacking one critical call, the CreateDIBSection api call in GDI is not present in NT 3.1. So remembering all the MIPS stuff as of late, and that I have Visual C++ 4.0 which should easily support this call, I first got it running with Visual C++ 2.0 on the i386 (Under XP of all things). So it was just a matter of building the source, and making sure there is no errors, uploading it to the emulator, and rebuilding for the MIPS.

And after 30 minutes, I got my exe, and it ran!

Quake 1.06 on the MIPS/NT

Quake 1.06 on the MIPS/NT

I’ve included a link for any other MIPS people out there that want to play quake. I haven’t built the networking as I was having issues with my network earlier and couldn’t get it working…

The exe is available here.

And the source code with all the bits is right here.

In this build I’m not building SDL as a DLL or static library, but rather compiling Quake right into the source. Now that SDL is running on the MIPS, and possibly other Win32 OS’s (I have yet to test Win32s… I suspect the inherent threading in SDL will prevent it, but could the DBI calls be made directly stripping out SDL…?) but who knows, I think anything past 3.51 would work.