My latest Xenix build

[resman]

It's probably just the one cli *nix looks like any other Not at all dissimilar to any Dos variant prompts looking like another.

Didn't old SCO do all the hard work anyway?

It's more a dig at linux but this link does contain some interesting tidbits all the same;

http://www.softpanorama.org/People/...rosoft_shortlived_love_affair_with_unix.shtml

Not that the shell is that different, but the include programs give it a certain "flavor".

I thought this site had some interesting tidbits, too. This from inside the Microsoft Xenix group: http://seefigure1.com/2014/04/15/xenixtime.html

Certainly Microsoft had a lot to do with the tools used to build Xenix (at least after the CMERGE compiler). I think that all changed with SCO Unix.

 

[md95065]

Certainly Microsoft had a lot to do with the tools used to build Xenix (at least after the CMERGE compiler). I think that all changed with SCO Unix.

Yes, essentially all of the x86 XENIX tools were from Microsoft - the C compiler. masm and the linker were just XENIX ports of the equivalent MSDOS tools (although considerably down rev in terms of version). Microsoft did pretty much all of the core kernel porting work for XENIX on both the 286 and the 386 with SCO providing additional drivers and tools. There had also been an 8086 port which ran on the Altos 586 (and possibly a few other machines) and I believe that these systems all had some rudimentary "memory management" hardware implemented in discrete logic external to the cpu. The 8086 (8088 actually) port to the IBM XT was, however, an SCO effort and a version of it also ran on on some 8086 based Burroughs systems as a task under the native OS, "BTOS".

SCO UNIX was based on AT&T's System V Release 3.2/386 - the development tools for early SCO UNIX systems were a curious hybrid of Microsoft and AT&T tools including several object format converters. Those systems could also run both 16 and 32 bit XENIX x.out format binaries as well as 32 bit COFF binaries.

It was quite a long time before the last of the MS development tools finally disappeared.

 

[Scali]

Yes, essentially all of the x86 XENIX tools were from Microsoft - the C compiler. masm and the linker were just XENIX ports of the equivalent MSDOS tools (although considerably down rev in terms of version).

Then I guess the C compiler is actually Lattice C. Microsoft licensed Lattice C in the early days, and continued developing that codebase up to Visual Studio .NET, when they finally had a C compiler that they had written from scratch.
You'll notice that some 'quirks' from Lattice C are not present in the newer compilers.
One well-known example is the scoping of variables in a for-loop in C++:
for (int i = 0; i < 10; i++)
{...}

This will put int i outside of the scope of the for-loop in Lattice C. So you can access its value below the for-loop (and you cannot redefine i in the next for-loop because it is already defined in that scope).
In most other compilers the scope of i is only in the for-loop itself.

Funny enough on Amiga I used SAS/C, which is also a Lattice C-derivative. It had this same quirk, as well as some others I was used to up to VC++ 6 in the Microsoft world
I bet the XENIX tools are based on this compiler core as well (although I suppose back then there was no C++ support yet).

 

[kb2syd]

I would have LOVED to networked it my deskpro but no network is configured nor is uucp and floppys work well enough for now. My eyes were straining on that low resolution and that was a top priority.

I figured you would at least have getty running on one serial port. Not the best to make an assumption like that. That would have been my first step once I got it running, but that's me.

 

[resman]

Then I guess the C compiler is actually Lattice C. Microsoft licensed Lattice C in the early days, and continued developing that codebase up to Visual Studio .NET, when they finally had a C compiler that they had written from scratch.
You'll notice that some 'quirks' from Lattice C are not present in the newer compilers.
One well-known example is the scoping of variables in a for-loop in C++:
for (int i = 0; i < 10; i++)
{...}

This will put int i outside of the scope of the for-loop in Lattice C. So you can access its value below the for-loop (and you cannot redefine i in the next for-loop because it is already defined in that scope).
In most other compilers the scope of i is only in the for-loop itself.

Funny enough on Amiga I used SAS/C, which is also a Lattice C-derivative. It had this same quirk, as well as some others I was used to up to VC++ 6 in the Microsoft world
I bet the XENIX tools are based on this compiler core as well (although I suppose back then there was no C++ support yet).

Your example uses an ANSI construct that doesn't seem to be recognized, even with the -Me flag. I ran the Xenix compiler (and passes 0 through 3) through 'strings' looking for anything interesting and only found a build date in 1985. According to Wikipedia, this should be version 3.0. Running masm through 'strings' found a version of 3.09.

 

[md95065]

Then I guess the C compiler is actually Lattice C. Microsoft licensed Lattice C in the early days, and continued developing that codebase up to Visual Studio .NET, when they finally had a C compiler that they had written from scratch.
[ ... ]
I bet the XENIX tools are based on this compiler core as well (although I suppose back then there was no C++ support yet).

Well, there wasn't even the first ANSI C standard at the time - we are talking about mid 1980's here and the standard wasn't finished until 1989.
That being said, the Microsoft C compiler had support for quite a few ANSI features from early on - notably function prototypes - and I believe that least one of the Microsoft compiler team, Ralph Ryan, was on the X3J11 committee.

I had previously used Lattice C in around 1983 when it was one of the few x86 compilers available and I had access to all of the XENIX source code when I worked at SCO from 1987 onwards and never saw any indication that the Microsoft compiler was based on the Lattice compiler (but I had never seen the Lattice source code and it certainly is possible that is where the code originated).

Your example uses an ANSI construct that doesn't seem to be recognized, even with the -Me flag. I ran the Xenix compiler (and passes 0 through 3) through 'strings' looking for anything interesting and only found a build date in 1985. According to Wikipedia, this should be version 3.0. Running masm through 'strings' found a version of 3.09.

Yes - version 3.x sounds right - we never got much beyond that - Microsoft wasn't really interested in maintaining support for XENIX by then so newer versions of the compiler always needed a substantial amount of work to get them running on and generating code for XENIX. Source code control was almost unheard of at that time and there was a lot of code churn going on making it both difficult and expensive to attempt to stay up to date.

The compiler in question was known as the "cmerge" compiler and, as I recall, also had a BASIC front end. There was also some evidence that someone at some time had tried to leave open the possibility for Fortran and Pascal front ends as well - presumably to allow the new compiler to replace the much older Fortran and Pascal compilers that Microsoft had at the time (and while I don't know for sure, I think that it is a very safe bet that *those* older compilers were almost certainly bought from someone else, but I don't know who) - but there was no real commercial interest for either of those languages from Microsoft's customers so, AFAIK, none of that ever happened.

The four people that I know were involved in the development of the Microsoft C compiler at the time were Ralph Ryan, Greg Whitten, Hans Spiller and Dave Weil and in some of the earlier versions of the compiler if you ran the binary for one of the intermediate passes of the compiler (p2 or p3, I think) by hand with the "-1234" flag it would print out their names.

 

[resman]

The four people that I know were involved in the development of the Microsoft C compiler at the time were Ralph Ryan, Greg Whitten, Hans Spiller and Dave Weil and in some of the earlier versions of the compiler if you ran the binary for one of the intermediate passes of the compiler (p2 or p3, I think) by hand with the "-1234" flag it would print out their names.

I went looking for these names in all the compiler passes, but didn't find them. However, I must have missed running 'strings' on p3 earlier, as it displays "Microsoft C Compiler version 3.00.17", built on August 30, 1985. Thanks for all the historical information, very interesting.

 

[md95065]

I went looking for these names in all the compiler passes, but didn't find them.

I really can't remember which version of compiler it was that had that "feature" - although I said that is was an "early" version it may actually have been an "early 386" version. I also have a feeling that the names were trivially encrypted and would not have shown up as plain text in the binary.

 

[Scali]

I had previously used Lattice C in around 1983 when it was one of the few x86 compilers available and I had access to all of the XENIX source code when I worked at SCO from 1987 onwards and never saw any indication that the Microsoft compiler was based on the Lattice compiler (but I had never seen the Lattice source code and it certainly is possible that is where the code originated).

Well, it's on the Wikipedia page: https://en.wikipedia.org/wiki/Lattice_C

The compiler was subsequently repackaged by Microsoft under a distribution agreement as Microsoft C version 2.0.[3] Microsoft developed their own C compiler that was released in April 1985 as Microsoft C Compiler 3.0.[4]

As far as I know, their C compiler was more of a fork of Lattice C than an actual rewrite (unless Microsoft tried REALLY hard to be completely compatible with Lattice C, including various quirks and compiler-specific features, which stuck with them until they did another rewrite for VS.NET).
So it seems that versions 1.x and 2.x are just rebranded Lattice C, and with version 3.x, Microsoft started doing actual development on the compiler.

 

[md95065]

Well, it's on the Wikipedia page: https://en.wikipedia.org/wiki/Lattice_C
As far as I know, their C compiler was more of a fork of Lattice C than an actual rewrite (unless Microsoft tried REALLY hard to be completely compatible with Lattice C, including various quirks and compiler-specific features, which stuck with them until they did another rewrite for VS.NET).
So it seems that versions 1.x and 2.x are just rebranded Lattice C, and with version 3.x, Microsoft started doing actual development on the compiler.

OK, that makes sense.

The compiler that we are talking about here, which is the only one that I had any direct knowledge of, is 3.x and, according to that Wikipedia article:

Microsoft developed their own C compiler that was released in April 1985 as Microsoft C Compiler 3.0.

Which is also consistent with my recollection that Microsoft were actively working on that compiler at the time.
My guess is that, by time I saw it most of it was either completely new or had been substantially rewritten.

 

[resman]

A follow up to my original XENIX build involved changing the keyboard to the original Deskpro keyboard. I wasn't a real fan of the layout, but it did have the control key in the proper location, as opposed to the Enhanced keyboard that gave me carpal tunnel syndrome trying to reach for it. I was worried the keyboard construction was going to be similar to the Portable's design that used the foam pads (that all disintegrate over the past 30 years). Luckily the Deskpro's keyboard uses a rubber membrane, which doesn't give the best tactile feedback in the world, but didn't fall apart:


The next addition was a second Seagate ST-225 20Mb drive for my home directory. Now, there is 20 Mb for XENIX & swap, and 20 Mb for my files. Oddly, when I went to do a low-level format on the drive I chose an interleave of 4 (the default is 6). I figured the 7+ Mhz V30 should be able to handle a tighter interleave. This was the value I used for the first drive - it gave me about 300K of bad sectors, but has worked well. The second drive gave a ton of read errors with an interleave of 4, At an interleave of 3, almost every block gave a read error. Going back to the default of 6, there were zero errors. So an interleave of 6 it is ( I would have expected the interleave to change the read rate, not affect the error rate). The second drive is above the first:


Lastly, with 20Mb to fill up, doing the floppy shuffle just wasn't going to cut it. XENIX 86 doesn't have any network support, but it does have UUCP. I already had a serial connection between my OpenStep 4.2 machine which I could 'cu' into from XENIX 86. But, to get UUCP working between the two requires editing some configuration files to make all the pieces happy. XENIX 86 uses an incredibly ancient version of UUCP from Unix 5.0 (uucp v2), probably because it was small. Finding documentation for such an old version is a little difficult. The magic involves two files that live in /usr/lib/uucp; L-devices and L.sys. Here are my versions to directly connect the serial port.

L-devices:

DIR	tty1a	0	9600

L.sys:

next Any tty1a 9600 tty1a ogin:-@-ogin: uucp

These are very minimal to directly connect to another machine, 'next' in my case (for NextStep). I can move a file from XENIX to OpenStep with a command like 'uucp myfile next!~/myfile'. Although the XENIX 86 configuration is pretty easy, the real hassle is in setting up the host machine. UUCP configuration has caused much gnashing of teeth and pulling of hair. That part is up to you. However, I can now transfer files back and forth between OpenStep and XENIX 86. It doesn't seem to want to recurse into directories, so a tar file is the easiest way to move all the files in a directory tree.

I think I've taken this setup as far as it will go. I think all my other machines are jealous.

Dave...

 

[albert.wik]

Unfortunately the C compiler doesn't have inline asm - at least that I could figure out. I tried asm, _asm, and __asm to no avail. Finding a working version of masm would really make this a nice development system for DOS. It's interesting that all the tools work fine on the 8086 except masm. Perhaps I'm doing something wrong.

Dave...

I'm currently, as of writing, running the "lorenzo" 286.img image from archive.org. It has masm, but I haven't tested it.

-Albert.

 

[ForOldHack]

Amazing to see this in hardware. My Turbo-XT had a V20 ( being IBM cloned and not compaq cloned ), I also had a Seagate ST-225, and replaced the disk controller with an OMTI-RLL, which the guy swore was Xenix compatible, and it was one of the ONLY disk controllers that was. The ST-225 was a bit slow, so I got a CMI-63xx? 20Mb, and was told by the same OMTI-RLL guy that the drive really had 640 cylinders and not 615. Guy was right again. So... Dos 3.3, Windows 1.03 and Xenix...

I partitioned the CMI as 15MB ( I almost wrote GB ), Xenix, and 5MB Dos/Widows, and the ST-225 as 5Mb Xenix, and 15MB DOS.

The *entire* Xenix runtime and developer tools fit on the 15Mb partition, and I followed the manual to the 't' and put the swap files on the second drive, as well as any user files, and user directories.

Ran like a champ. Worked my way throught K&R and hit every non-ATT pothole there, feeling kind of tough, we tarred the source for nethack, and sent it over uucp, and untarred it... still plenty of room, and tried to run the make file.
After every .a file was made, it was compressed and sent to the user drive... we would stop it, and check if it was behaving, and it was... so we let it fly... about 5 hours later it restarted and would not boot Xenix. We ran fsck for several hours, and that gave up from exaustion too. Reinstalled everything, and it booted... but dreams of doing something serious with it, were gone.

I would look for RLL controllers for this. The Max partition size is 32MB so a 20Mb drive, becomes a 30Mb drive. Breathing room. A CMI-62xx goes from a 21.5 drive to a 33MB drive, and there is about 700k left over for another partition... ( this of course was the place to put the swap file... ).

MASM was standard for Xenix, albet renamed to something else, and I believe it was based on MASM 3.0.

 

[albert.wik]

MASM was standard for Xenix, albet renamed to something else, and I believe it was based on MASM 3.0.

You seem to be right about v3.0.

# uname -a
sysname=XENIX
nodename=(empty)
release=2.3.2
version=SysV
machine=i80286
origin=3
oem=3000
serial#=8530
# strings /bin/masm | grep Micro
Microsoft MACRO Assembler, V3.09

-Albert.