It’s amazing how terrible this thing has always looked to me. As far as ‘proof’ I remember being able to fake it out by doing a ‘copy con win.com ^Z’ type thing to create a fake windows directory with win.com & kernel286.exe … I think. But back when this was a NEW! product, I had to install Windows 3.0 anyways to get the CGA driver.

I don’t know how I used Windows with CGA either.

Speaking of impossible, back in the dark ages of Windows/286 2.1 this thing snuck out:

One day I’d love to get this Italian Windows 2.1 and frame it? I don’t know who snuck in the Buone Fest onto the box art, but I’d like to think it was subversive, as I hadn’t seen anything like that on any of the other retail Operating System packaging?

It’s been a real struggle this year from the relocation, losing just about everything that I’d tried to do, then losing my job, that brief absolute terror of being unemployed with zero callbacks trying to job hunt to now spending nearly every waking hour at work.

Speaking of stress, I haven’t had to build a physical network in ages, and this was news to me that all the SFP connectors are now vendor locked. Thinking I could just buy some cheap SFP DAC cables and plug away and I was greeted with the fact that neither the Dell, nor Cisco switches would recognize them. Oddly enough, Linux/Windows didn’t care at all. I had ordered some RJ45 10 gig SFPs to run across the data centre, and found out as well that I’d ordered Cisco keyed generic ones, and yes of course they don’t work in the Fortigate firewalls, nor the Dell switches. Those needed their own special ones. Luckily for me I had been pulling out all the old SFPs from decommissioned equipment as I had figured that the single mode fiber optics may be useful if I ever need anything, and there was a couple of these Alcatel-Lucent SFP-GIG-T (1gig) modules that at least saved the day in that I could connect stuff, while waiting for the trial and error of needing 2 weeks to get the appropriate 10 gig interfaces.

Also with mentioning is that Dell switches configure in cluster groups and the 25 gig clusters have to be configured down to 10gig mode to recognize and work with 10/1gig modules.

port-group 1/1/5
 mode Eth 25g-4x
!
port-group 1/1/6
 mode Eth 10g-4x

For example.

Speaking of, setting up a LACP bundle on the Dell switch was a snap! Just remember your port-groups!

interface ethernet1/1/1
 description "WIN-HVN-100 port 0"
 no shutdown
 channel-group 1 mode active
 no switchport
 flowcontrol receive off

There isn’t all that much to do in the individual ethernet ports, but you get the idea. Since I’m short on cables, I’ve only got the first two ports populated, but I’m aiming for 4×25 per server!

interface port-channel1
 description WIN-HVN-100
 no shutdown
 switchport mode trunk
 switchport trunk allowed vlan 50,75-78,150,875,901-902

I did find that by explicitly allowing the VLANs onto the port helped a lot. And by default, the switches do LACP so there isn’t all that much to do.

And checking the LACP status is a snap as well:

hyperv-lan-core-01# show interface port-channel 1 summary
LAG     Mode      Status    Uptime              Ports
1       L2-HYBRID up        1 day 21:45:26      Eth 1/1/1 (Up)
                                                Eth 1/1/2 (Up)
                                                Eth 1/1/3 (Down)
                                                Eth 1/1/4 (Down)

Needless to say, I was happy as ‘it just worked’!

Speaking of which, I deployed Hyper-V 2019 Server. Shame VMware had to go get Broadcomm’ed as there won’t be any more free Hyper-V servers, but for now it’s fine.

I had meant to write more on setting up Hyper-V as doing it through PowerShell is a bit daunting at first.

First setup your load balancing network team. In this case I’m using a 4 port 25gig card:

New-NetlbfoTeam -Name "Converged Network Team" -TeamMembers "Integrated NIC 1 Port 1-1","Integrated NIC 1 Port 2-1","Integrated NIC 1 Port 3-1","Integrated NIC 1 Port 4-1" -TeamingMode lacp

The port names are 100% system dependent, but you can get the idea. And setting the LACP was surprisingly easy.

The next step is to create a virtual switch

New-VMSwitch -Name "Converged Network Switch" -NetAdapterName "Converged Network Team"

I just load everything onto the same switch as I’m old, and trust my VLANs. And the servers are 1u so they don’t exactly have a lot of NIC’s for splitting stuff out but as always do what works for you.

The next step is to add the virtual network card onto my management VLAN in this case it’s 75

add-vmnetworkadapter -switchname "Converged Network Switch" -name Management -managementos
set-vmnetworkadaptervlan -managementos -vmnetworkadaptername "Management" -vlanid 75 -access

From there you can now use the ‘sconfig’ and setup your management IP address, load up Windows patches, load more drivers, and manage the server using the remote RSAT tools. Be sure to enable the remote desktop, unless you really love to type.

I went ahead and installed these services to get my servers onto an existing Hyper-V cluster. I’m sure some can be removed, but YMMV as always:

Install-WindowsFeature -Name FileAndStorage-Services
Install-WindowsFeature -Name File-Services
Install-WindowsFeature -Name FS-FileServer
Install-WindowsFeature -Name Storage-Services
Install-WindowsFeature -Name Hyper-V
Install-WindowsFeature -Name NET-Framework-45-Core
Install-WindowsFeature -Name NET-Framework-45-Features
Install-WindowsFeature -Name NET-WCF-Services45
Install-WindowsFeature -Name NET-WCF-TCP-PortSharing45
Install-WindowsFeature -Name Failover-Clustering
Install-WindowsFeature -Name Multipath-IO
Install-WindowsFeature -Name RSAT
Install-WindowsFeature -Name RSAT-Feature-Tools
Install-WindowsFeature -Name RSAT-Clustering
Install-WindowsFeature -Name RSAT-Clustering-PowerShell
Install-WindowsFeature -Name SNMP-Service
Install-WindowsFeature -Name Windows-Defender
Install-WindowsFeature -Name PowerShellRoot
Install-WindowsFeature -Name PowerShell
Install-WindowsFeature -Name WoW64-Support

Interestingly enough, on 2019 the option is there for the Linux Subsystem. I didn’t install it, but that’d be an interesting thing to share out.

I did have some weird issue with remoting and explicitly enabled it with a

Enable-PSRemoting -Force

It’s probably me, but it worked for me.

Then it’s a matter of adding all the other virtual networks Hyper-V seems to love:

add-vmnetworkadapter -switchname "Converged Network Switch" -name Backup -managementos
add-vmnetworkadapter -switchname "Converged Network Switch" -name "Live Migration" -managementos
add-vmnetworkadapter -switchname "Converged Network Switch" -name Cluster -managementos
set-vmnetworkadaptervlan -managementos -vmnetworkadaptername "Backup" -vlanid 76 -access
set-vmnetworkadaptervlan -managementos -vmnetworkadaptername "Live Migration" -vlanid 77 -access
set-vmnetworkadaptervlan -managementos -vmnetworkadaptername "Cluster" -vlanid 78 -access

And of course, don’t forget your shared storage, in this case my servers have that 4x25gig card, and a smaller custom 2×25 gig card that I used to storage A/B. Fun times!

From there I could use sconfig to join my machines to the domain, and then finally add them into the cluster, and start moving my workload over to the new servers, which is what I’ll be doing throughout the Christmas break.

Speaking of work:

They ordered this very Clark Griswald like Christmas tree. They had to cut it down to get the base to fit the lobby area with it reaching into the 2nd floor. It’d been so long since I’d seen something like this at work. But thats me working remotely for nearly 20 years.

Something awe inspiring about it.

Which reminds me of this Snoopy I saw on twitter. As terrible as life feels from time to time, there is a bit of hope, and fun here and there as my muse is always quick to point out when I’m feeling down.

And sometimes it’s better to just get it out, as who knows, maybe this could be useful in the future somehow.

Thanks for everyone’s ongoing support over on Patron and here. It really means the world to me.

Merry Christmas to all!

The UnixWare 7.1.1 install program has a date & time Y2k problem. And this always ends in whatever licensing you give it to install will expire and be nullified. Luckily this time while re-installing on VMware I saw if you defer the license on install, It’ll grant you a temporary eval license. It’s not going to matter as it’ll immediately expire, but it get’s us past the install.

Qemu however let’s you rev up the time machine and specify a starting time

-rtc base=1999-09-29T15:00:00

As simple as that. I found for installing with Qemu 8.0 (Latest win32) binary it worked well enough like this:

"c:\Program Files\qemu\qemu-system-x86_64.exe" ^
-m 1024 ^
-hda UnixWare711.vmdk ^
-cdrom SCO_UnixWare711.iso ^
-net nic,model=pcnet ^
-rtc base=2010-09-29T15:00:00

Installation in a stock boring VM goes fine, there is built in support for the AMD PCnet driver, so things ‘just work’. And then on the VMware reboot it never launches X11.

Under Qemu, I’m greeted by CDE and the login page. On VMware however…

I know t his used to work on VMware, but there is some regression in the VESA video driver. The fix was to use scoadmin and knock the video settings down to stock VGA. Luckily I have an X server running on Windows, so I could just export the display and set it up.

Whereas I had to set VMware to VGA:

And one more reboot, and I was at least given a graphical console:

Inputting the licenses

Being a commercial Unix from back in the day, it relies on License Numbers, and activation codes to actually use the software. I have the box, so I have codes so yay me. Post install, I could remove the expired licenses, and then input the ones that were in the box.

These are 5 user licenses, just enough to show off the system, I suppose: The advanced features of the day are nothing special these days, but it’s nice to have the PCC derived compiler, if not to compile GCC but more so for SYSV code from back in the day.

Networking

Networking for VMware is straightforward, I use the NAT interface VMnet8 that is installed by default, selecting a valid Tcp/IP address on the interface range gives me not only full internet access, but also allows me to easily telnet into the VM.

Qemu however…

"c:\Program Files\qemu\qemu-system-x86_64.exe" ^
-m 1024 ^
-hda UnixWare711.vmdk ^
-net nic,model=pcnet ^
-net user,hostfwd=tcp::42323-:23

I had been using the user mode SLiRP code for ages, but after all the MIT PC/IP fun, I was thinking I bet modern Qemu supports UDP transport for network traffic, and that it’d just integrate with HecnetNT just fine. And it does!

"c:\Program Files\qemu\qemu-system-x86_64.exe" ^
-m 1024 ^
-hda UnixWare711.vmdk ^
-net nic,model=pcnet,netdev=hecnet ^
-netdev socket,id=hecnet,udp=127.0.0.1:5001,localaddr=127.0.0.1:5000

Configuring the HetnetNT bridge was simple, as always make sure you have Wireshark/pcapng installed and simply run ethlist to get the list of interfaces:

D:\qemu>ethlist.exe
Network devices:
  Number       NAME                                     (Description)
  0  \Device\NPF_{E79F6278-3E7E-4547-955A-2080A0473AD6} (Local Area Connection* 8)
  1  \Device\NPF_{1D960E08-2A3A-43F7-BAD6-21FCB466717B} (Local Area Connection* 7)
  2  \Device\NPF_{98053A85-B049-45A0-AC33-961E2C136FCA} (Local Area Connection* 6)
  3  \Device\NPF_{BFA868ED-E508-4436-B085-EC815C4C544C} (LoopBack)
  4  \Device\NPF_{C75EAF23-0FA3-433B-B271-9CB0F5EB92D0} (VMware Network Adapter VMnet8)
  5  \Device\NPF_{B615DE21-AEC3-4347-916C-332AC4A4DA70} (VMware Network Adapter VMnet1)
  6  \Device\NPF_{82E5A370-6D3D-40AD-A9D5-C4E0E0C50F0D} (Ethernet)

And then create a simple bridge.conf file with the VMnet8 adapter and the UDP pariing to talk to Qemu:

[bridge]
update 127.0.0.1:5000
vmnet8 \Device\NPF_{C75EAF23-0FA3-433B-B271-9CB0F5EB92D0}


[tcpip]
update
vmnet8

Then launch the bridge program listening on port 5001:

D:\qemu>hecnet.exe 5001
Config filename: bridge.conf
Adding router ''update''. 0100007f:5000
Opening pcap \Device\NPF_{C75EAF23-0FA3-433B-B271-9CB0F5EB92D0}
Adding router ''vmnet8''. 00000000:0
Host table:
0: update 127.0.0.1:5000 (Rx: 0 Tx: 0 (Drop rx: 0)) Active: 1 Throttle: 0(000)
1: vmnet8 0.0.0.0:0 (Rx: 0 Tx: 0 (Drop rx: 0)) Active: 1 Throttle: 0(000)
Hash of known destinations:
Adding new hash entry [52:54:00:12:34:56]. Port is 0
Adding new hash entry [00:50:56:c0:00:08]. Port is 1
Adding new hash entry [00:50:56:f1:dd:d0]. Port is 1
Adding new hash entry [00:0c:29:9a:2b:fb]. Port is 1

It’s a little bit more involved to setup as we have to link the 2 programs via UDP, but I can say it’s totally worth it.

I can now easily FTP files into Qemu, and of course telnet as much as I want to. I don’t see why NFS wouldn’t work either.

Which brings us to the bigger elephant in the room, which one is ‘worth the squeeze’?!

I thought it’d be fun to do a totally unfair CPU intensive thing like building GCC. I would do a quick stage 3 compile blindly running this:

./configure --host=i386-sysv4 --target=i386-sysv4 --prefix=/usr/local/gcc-2.5.8
make
make stage1
make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O"
make stage2
make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O"
make stage3
make CC="stage3/xgcc -Bstage3/" CFLAGS="-g -O"

This way we can just look at the timestamps between completed releases. It does build C++ & ObjectiveC as well, and compared to machines from 1999 this is amazing!

-rwxr-xr-x 1 neozeed other 3495688 Mar 29 12:42 ./cc1
-rwxr-xr-x 1 neozeed other 2646888 Mar 29 12:37 ./stage1/cc1
-rwxr-xr-x 1 neozeed other 3495720 Mar 29 12:39 ./stage2/cc1
-rwxr-xr-x 1 neozeed other 3495688 Mar 29 12:40 ./stage3/cc1

Qemu timing

-rwxr-xr-x 1 neozeed other 3884076 Mar 28 20:12 ./cc1
-rwxr-xr-x 1 neozeed other 2647116 Mar 28 20:11 ./stage1/cc1
-rwxr-xr-x 1 neozeed other 3884124 Mar 28 20:11 ./stage2/cc1
-rwxr-xr-x 1 neozeed other 3884076 Mar 28 20:12 ./stage3/cc1

VMware timing

As you can see VMware is substantially faster when it comes to computation. This shouldn’t come to anyone as any surprise. And this isn’t a fair competition, but it does show that you can stage GCC on Qemu just fine, so that’s actually great!

Now let’s mix in some more nonsense, I have a Merge license so let’s try it! First off it really wants Windows 95 from CD-ROM. It will not accept anything else. I have a hacked-up copy of the floppy version of Windows 95 on CD-ROM, and it accepted that just fine, it appears to search through.CAB files looking for files to setup it’s preferred environment. I’m not all that familiar with the whole thing as PC’s are cheap, and virtual machines are even cheaper!

After the setup completed, I thought I’d try my Sarien 286/386 ports.

Sadly, neither worked. Maybe it’d have better luck with Windows 95 actually installed. I wanted some high colours so I went over to Qemu and found out that it cannot run Merge.

The error lies in a missing opcode 000000FF. Maybe it’s invalid to trigger an exception to call between DOS and the supervisor?

Either way it doesn’t matter, it doesn’t work. I did get feedback that it does run under KVM.

I don’t know why I didn’t think about doing the HecnetNT bridge earlier as it gives things far more flexibility for tapping into networks, or even being transported. I guess I should look at other transport mechanisms besides UDP since it’s 1:1. Also, it might be worth dropping the protocol restrictive filters to allow everything on the wire to flow.

Before I had it set to this:

(ether dst 09:00:07:ff:ff:ff) or (ether dst ff:ff:ff:ff:ff:ff)

It’s allowing one Multicast address for AppleTalk and the general ethernet broadcast address. Which is more or less okay but for everything else, you want to catch a wider net. The better choice is to use built in pcap macros:

((ether broadcast) or (ether multicast)

I can confirm that these do work for 86box, so I’ve copied the same into Cockatrice III. For those who wonder what the difference between Basilisk II & Cockatrice III is, I basically took a super old version of Basilisk II, ripped out as much platform code as I could, re-ported it to basic SDL, removed all the fancy clipboard/meta/drive sharing integration code, added a pcap network option to use the raw network for AppleTalk, and took the SCSI emulation from Previous so I can partition and format virtual ‘SCSI’ disks that I’ve even been able to use in a BlueSCSI!. I’ve sat down with a debugger some years ago and went through the SLiRP code catching as many faults when using Internet Explorer as I could, I think most of the ‘fix’ involved renaming clashing symbols, and while it’s not perfect it was a lot more stable than the default stuff. Although I haven’t touched it in years, and probably should look to borrowing a more modern version from elsewhere.

Linking this thing with TDM GCC is becoming a bit of a challenge so in case I forget here is how I’m currently statically linking libgcc/libg++ along with winpthread. All it should need now is SDL & working WinSock which every Win32 should have!

c++ -o CockatriceIII.exe        obj/main.o obj/main_sdl.o obj/prefs.o obj/prefs_dummy.o obj/sys_unix_sdl.o obj/rom_patches.o obj/slot_rom.o obj/rsrc_patches.o obj/emul_op.o obj/macos_util.o obj/xpram.o obj/xpram_dummy.o obj/timer.o obj/timer_common.o obj/clip_dummy.o obj/adb.o obj/serial.o obj/serial_dummy.o obj/ether.o obj/sony.o obj/disk.o obj/cdrom.o obj/scsi.o obj/video.o obj/video_sdl.o obj/audio.o obj/extfs.o obj/user_strings.o obj/user_strings_unix.o obj/sdl_pcap.o obj/scsi_dummy.o obj/audio_sdl.o obj/prefs_editor_dummy.o obj/basilisk_glue.o obj/memory.o obj/newcpu.o obj/readcpu.o obj/cpustbl.o obj/cpudefs.o obj/cpuemu.o obj/fpu_ieee.o cockatricerc.o ..\slirp\libslirp.a ..\drmingw-0.7.7-win32\lib\libexchndl.a -Wl,-Bdynamic -lSDL -lws2_32  -liphlpapi -Wl,-Bstatic -lgcc -lstdc++ -lwinpthread -static -static-libgcc -static-libstdc++

I’ve been able to map to my internal servers just fine, and connect using Internet Explorer so I suppose everything is fine!

All the cool kids love github so here you got, you can get it from the latest releases:

Releases · neozeed/CockatriceIII (github.com)

I’ll have to re-sync sourceforge. Although I do keep more resources on sourceforge since it’s clearly a lot better at file hosting.

“If you want to make a pie from scratch, you must first create the universe”

A little while ago I had touched briefly on the availability of of a PCC port to the 8086 done back in the early 1980’s that was hosted on VAX running 4.1BSD. I’d ruled it basically useless as you are restricted to 64kb .COM files, and I couldn’t get much of anything interesting running on it.

After all the fun of setting up NetManage Chameleon on Windows 3.0, over on IRC lys had mentioned I should try the MIT PC/IP stack. I never knew anything about it’s history but it became the first PC TCP/IP stack. You can read more about it from “Internaut“?

Dave Clark had gone to England for sabbatical and while he was there, had implemented TCP/IP in BCPL for the TRIPOS operating system, a predecessor of the Commodore AMIGA operating system. He brought the TCP/IP code back with him, and the Lab for Computer Science had a bunch of Xerox Alto workstations, and someone at LCS ported Dave’s TCP/IP to the Alto.

Then someone ported it to Version 6 UNIX and rewrote it in C. And that was what we took, and ported to PC DOS. At that point there were no C compilers that ran on the PC, and we were using a compiler that ran on a PDP 11/45 on Version 6 UNIX, and then on a VAX 750 running BSD v4.1. That was the AT&T; portable C compiler, and a group of people on the fourth floor of the LCS had written an 8088 code generator for it. This was before Microsoft C, and before 4.2 BSD.

Our first tasks were to bring up TFTP, TCP, and a telnet client under DOS. Several people were involved. Lou Konopelski did the initial TCP and telnet work, and Dave Brigham did similar work to what I did.

John Romkey – Internaut – How PC-IP Came to Be

What is even more notable about PCIP is that it’s the reason the whole ‘MIT License’ even exists, as word seems to have spread quickly about a TCP/IP stack for the IBM PC compatible market. Jerome Saltzer has documented it all, if you want to read about it (WARNING PDF!)

Romkey would even then go on to found FTP software in that wonderful pre public internet era, before the eternal September.

Over on bitsavers there are 3 files:

	8086_C_19850820.tar	2019-03-12 14:36	750K
	PC-IP_19850124.tar	2019-03-12 11:53	4.6M
	PC-IP_19860403.tar	2019-03-12 11:53	6.9M

Of course, the one thing that stands out is that these files look tiny. They aren’t even compressed! PCC, or the Portable C Compiler was released from AT&T, itself written in C, to make porting the C compiler easier to further allow Unix to be further easily ported. Now that I kind of had a mission, I decided to take the 8086 PCC leap, again.

Get the time machine ready!

Thankfully I had that 4.1c BSD image still up on sourceforge, aptly named: 4.1c BSD.7z, so I could follow my old instructions to create the tap file and start working with 8086 C, going back from 1985. And in no time, I had re-built the compiler, and assembler up and running. But I wanted more, as much fun as 4.1BSD is, I wanted to run everything natively on Windows.

At this point I’d remembered that this setup is a bit odd in that the object files that the assembler produces are OMAGIC (type 0407) a.out files. Thinking back to my old project of building Ancient Linux on Windows using vintage tools, it also uses OMAGIC a.out files! It’s not that unexpected as the original GNU ld linker from 1986 has hooks for both old magic & new magic (OMAGIC/NMAGIC) files, as this would be consistent from the era. Thinking this was my out, I might have a way of migrating the build process off of the VAX.

The first pass was to try to pull in all the VAX includes into my native Visual C++ 1.0, and get it to build with Microsoft C/C++ 8.0. The next thing to do of course, is look for where it’s doing anything with binary files and make sure it’s all set to O_BINARY/”rb”/”wb” where appropriate as MS-DOS/Win32/OS2 all handle text files differently from binary data. There is also fights with mktemp along with procedure name creep, like how ’round’ wasn’t a thing in 1980 but it sure is by 1993! Before the era of the 486DX/68040/Pentium not everyone had a math co-processor (FPU) so it’d make sense that a lot of things wouldn’t have this by default.

As a quick refresher the following diagram may be specific to the GNU GCC compiler, but the older PCC compiler uses the same methodology of first pre-processing files, then compiling them, assembling the resulting compiler output, then finally linking to an executable program. ( See – “So it turns out GCC could have been available on Windows NT the entire time“)

The steps for PCC 8086 are quite similar but to spell them out:

• Pre-process with GNU cpp
• Compile with PCC’s c86
• Assemble with PCC’s a86
• Link with GNU’s ld
• Extract the MS-DOS .COM file with cvt86

There isn’t much to talk about the pre-processor, so I’ll skip it, suffice to say from my cl386 research, and porting GCC to OS2/NT, it just worked.

Compiling the compiler

Surprisingly getting the compiler running wasn’t too difficult. I do remember getting this running before, so seeing it run again wasn’t too much of a surprise. The simple C program:

main(){
printf("hi from 8086 pcc\n");
}

Gives us the following generated assembly:

        .data
        .text
        .globl  _main
_main:
        push    bp
        mov     bp,sp
        push    si
        push    di
        sub     sp,#LF1
        mov     ax,#L14
        push    ax
        call    _printf
        pop     cx
L12:
        lea     sp,*-4(bp)
        pop     di
        pop     si
        pop     bp
        ret
        LF1 = 0
        .data
L14:
        .byte   104,105,32,102,114,111,109,32
        .byte   56,48,56,54,32,112,99,99
        .byte   10,0

So far, so good, right! Even for fun, I was able to build it using Microsoft C 6.0! I figured I may as well try to get as much out of that purchase as possible.

Strage binary formats in a strange world

One thing that was a constant problem for me is that the assembler generated garbage, it never gave me the a.out OMAGIC file. Opening it up in a hex editor, Hex Editor Neo, and it showed problem, right away.

The OMAGIC sequence in hex should be written down as 07 01, but when I looked at the output from my PC port the file was not only too big but it didn’t have the headder:

As you can see it’s just a bunch of zeros up front. Later on, I’d realize this was a ‘pad’ so it could be filled in later by the assembler when doing relocations. The file in question was rel.c which also should have been the hint. I don’t know if anyone saw it, but let me highlight it for you:

As you can see, where the file ends on the VAX, on the PC the OMAGIC header is being appended. I did a simple cut & paste in the editor, and the object file validated just fine. So why was this happening? In my rush to just add ‘binary’ flags to any file operations I had seen this in rel.c:

		(dout = fopen(Rel_name, "a")) == NULL)

I had taken this be an ‘append’ for whatever reason it would need to do that kind of thing. Well maybe that’s what it means in 1993, but in 1981 it doesn’t append, instead it just opens it normally. Is this a bug in the assembler, or a feature of 4.1BSD? Without debugging it, I just modified it to not append, as this was the only occurrence of an explicit append in the source code I could see.

		(dout = fopen(Rel_name, "wb")) == NULL)

And that did the trick, I now had a working assembler running on my PC!

But we are not out of the woods yet!

Naturally trying to build a much ‘larger’ Fibonacci program crashed the assembler. Luckily debugging it was a snap to find out that it was trying to free a static pointer. Or so I think. Today, in the future RAM is cheap, so I just commented out the offending free and now it was off to the linker.

When is advanced optimization a bad idea?

When the machine you wrote this for no longer exists. In the middle of the ld86 linker is this line:

		asm("movc3 r8,(r11),(r7)");

I have no idea why it’s there.

I don’t know what it should be doing.

This makes the linker un-portable.

However, as I’d mentioned before I did have the GNU linker that I’d successfully used to build Linux kernels, so there was hope!

C:\msvc32s\proj\8086pcc>\aoutgcc\bin\ld.exe -X -r -o hi.out crt0.b hi.b ./libc.a
C:\msvc32s\proj\8086pcc>cvt86 hi.out hi.com
C:\msvc32s\proj\8086pcc>msdos hi.com
hello from pcc for 8086!

I had now successfully run my first program without using the VAX. Although I had not mentioned a step yet, cvt86, this utility is described as creating a MS-DOS .COM file from an a.out file. I didn’t look into how it accomplishes this, but basically, it’s another linker. And this issue would come to complicate things as I had thought that everything was working.

libc & the heart of C

Libc, is simply put the central C library for getting everything done. While crt0 will setup the C environment everything else core from opening files, writing to the screen, and reading keyboard input is done through libc. So I thought re-building libc would be easy enough. To build the library you ‘archive’ them with the ‘ar’ archiver, then index them with ‘ranlib’. And again, from my a.out adventures building Linux I had both tools, however no matter what I was doing they did not work with cvt86. I wen’t back and rebuilt some kernels to verify, and yes it does generate archives but cvt86 was not happy.

I still had the SIMH VAX running in case I needed it, so I just broke down and figured I’d just port the VAX ar/ranlib to the PC. I don’t know off hand what the problem was, and I didn’t feel like spending an eternity to try to correct it, and both of the programs are somewhat portable. But of course it wasn’t that simple as ar opens files in strange ways that work on 4.1BSD but yeild chaos on the PC.

#define ARMAG   "!<arch>\n"

#define SARMAG  8

#define ARFMAG  "`\n"

‘ar’ has it’s own magic, a simple !<arch> and a ` followed by a new line. On any UNIX the \n is 10 in decimal 0xa in hex. But on the PC it’s carriage return and linefeed! And yes despite setting all the opens to binary, it was constantly injecting carriage returns & linefeeds all over the place! Some-how the file was being opened in text mode. Thankfully debugging even in old Visual C is great and inspecting the temporary files lead me to find this part:

			f = creat(file, larbuf.lar_mode & 0777);

In a few places it uses the creat (or create call. In an interview Dennis Ritchie had mentioned that this was one of his regrets in life, not naming creat create) call, which of course never has to set a mode, as everything is binary in Unix, unlike the PC. Great.

Luckily the fix was very simple after every creat, simply set the file mode to binary.

			setmode(f,O_BINARY);

Great!

Apple pie!

Now I could re-build libc from source and link it to the Fibonacci program!

Yes it’d take this long to get to the point where I can now easily edit file on a modern machine and have a Win32 native toolchain! VAX no longer required! We’ve successfully extracted everything we needed from the 1980’s!

First contact!

Now it’s time to look at what brought us on this adventure, MIT PC/IP.

The MIT PC/IP (PCIP) does require changes to the libc to work correctly. Unfortunately, they didn’t provide the full copy of the libc, but rather some ed scripts. So, the first question is do I even have the version these are based off of to start? I don’t know, so I had guessed, and I had guessed incorrectly.

Configuring PCIP is somewhat involved, first you need MS-DOS 2.00 or greater which thankfully in the future is FREE! The next thing you need is a 3com 3c501 card. This is going to be a challenge but it’s just as any good time to mention 86box, and the latest version that I’ve been using that of course supports this kind of setup!

I can’t recommend it enough, 86box is like all the inconveniences of old software & hardware without having to spend a fortune for weird combinations, fighting to have space for it. I naturally setup a 386sx with CGA, 20Mb hard disk and a 3c501 card. It’s nice being able to also be very task specific, this doesn’t have to be a DooM/Quake machine!

the first thing you need to do is add the netdev.sys device driver that is created as part of building PCIP from source. a simple:

DEVICE=\NETDEV.SYS

in your config.sys is more than enough. However, how do you configure it? Well it’s the ‘custom’ program that binary edit’s the device driver.

YES, IT EDITS THE DEVICE DRIVER.

Setting stuff up is somewhat straight forward, however it displays TCP/IP information in decimal not in hex. I haven’t even looked into the how or why.

The first page options are kind of banal, it’s back in the day when people would use finger to find people on the internet and call them up or send emails. How cute. 1985 was a different world!

In the hardware options the only thing to check is the I/O base, IRQ & DMA for the Ethernet card. I just configured the card around 0x300/5/1 as it’s great being purpose built!

There is a separate window for telnet options. Naturally high speed connections frame far too fast for something built from 1985. I found lowering the TCP windows really helped with pacing.

As I had mentioned the site configuration displays all the information in decimal. Also, I’m wasn’t sure what is going on with the netmask, but looking at the old Windows calculator revealed it was being stored in OCTAL. It’s probably why the addresses have commas instead of periods. Although I had configured DNS it didn’t work, as it uses UDP port 42. It’s clearly doing something very early 1980’s.

So close and yet so far away. The only thing to do was try to figure out which of the libc stuff was ‘newest’ in the pure state and try to figure out where to go from there.

Redo!

While I had not configured the libc correctly, I had partial success! I could actually establish a telnet session! Libc wasn’t working correctly as every line feed didn’t generate a carriage return, as you’d need for MS-DOS leaving it with broken status.

But at the same time, despite all the weird ‘challenges’ for the most part ‘it just worked’. Which is pretty cool!

It turns out the answer was the 8086_C_19850820 file. As far as I can tell there was only one thing that didn’t patch correctly but I was able to build a libc in no time.. that didn’t work. In the patch it removes ulrem/auldiv from arith.a86 Not sure why, I haven’t messed with it. But that means I had to restructure to build with the non floating point n86c compiler as that’s the way PCIP is expected to be built. After rebuilding with this compiler and this seemingly properly patched library I finally had it working!

Instead of a garbled mess, I had something I could read!

Now instead of a garbled mess, I can see it was trying to display the connected IP, and a clock.

Sadly it doesn’t work with SLiRP. I’m sure it’s either classful routing or it really doesn’t like how SLiRP handles ARP. I suspect it’s also trying to do old style classful routing as well, which means you can’t just load arbitrary subnet masks wherever you want, to try to squeeze the 4 billion IP’s out of the internet.

Final thoughts

I suspect that although there were binaries in the above tar files, going through the effort to rebuild PCIP really wasn’t all that expected for most people to carry out. Sadly, there was no shared source ‘sites’ online, and we’re lucky enough someone kept a few tarballs lying around. I really can’t blame them for sticking with then current development tools, especially for what you’d need to build a C compiler back in the early 80’s. It’s a shame the QL or the Macintosh didn’t have the RAM or the DASD capacity to become that home cross compiler of the 80’s.

Most project just require you to work on that actual project, while this has been a substantially larger undertaking from anything normal, but I guess I’ve learned a bit along the way with all those “pointless” GCC port things I’d done, well it turns out they are incredibly useful! It’s been a fun archeological expedition for me, thankfully C is still a thing, I wonder what happened to all the ADA/Perl/Pascal/”Wave of the future” stuff that is always disappearing. At least more and more people work on full system emulation so there is always that!

For anyone that curious you can find all the code over on github:

https://github.com/neozeed/8086pcc

Against my better judgement, I’ve added a binary package on github.

And besides the NetBEUI being eaten on the network for no reason I can see, as I’m sure these machines should be able to talk to each-other this was the end result:

And what about not trying to create a machine account?

I should have expected this not to work.

Having dumped NetBEUI for TCP/IP, I can see them talk, it’s not a name resolution issue or anything like that. On the flip side can LAN Manager join a Windows NT domain? I’m not sure on that one either.

And not too surprising using the LAN Manager DOS client I can log onto the OS/2 domain just fine.

Kind of verbose and annoying but yes, it works!

However, despite LAN Manager 2.2 providing a TCP/IP stack to connect to both OS/2 and NT servers, there is no winsock interoperability dll. Do I really have to load more than one NIC and stack at the same time?!

The one thing I had been hoping to build up to was using mailslots, a UDP like IPC/RPC mechanism from back in the old dark days of early LAN Manager 1.0 The can be broadcasted to all nodes on the network that are listening by writing to \\*\MAILSLOT\<YOUR LOCAL BOX>. On the surface these broadcast type things are modern day terrible, we prefer lookup services like DNS, but in the 80’s it’s not like people were going to put tens of thousands of machines on a single network…

I cannot thank my Patrons enough for this attempt at doing something multitenant as I really did need Microsoft C 6, and the Windows 3.0 SDK. The example from the Lan Manager 2.0 Programmer’s Toolkit (Why was this stuff never in the base SDK?!) shows an OS/2 LAN Manager service providing rendering services over the network to render the Mandelbrot to the Win16 client. It’s actually very neat. It really gives OS/2 that pre-Windows NT feel, with the services as they are not in your face, although at the same time I’ve found that I had to do an interactive logon to get things started, so maybe LAN Manager OS/2 servers were not “Lights out”? I guess I need to look more into it, as it just feels more and more how NTOS2/ clearly grew out of OS/2 + LAN Manager.

Obviously as soon as I see this, thanks to getting my hands on the OS/2 6.78 network client, I also see it’s not only obsolete but going to be removed. If anything, it’s impressive that an OS/2 feature has remained in NT for so long.

The LAN Manager 1.0 disk sets, actually include headers & libraries, but no examples.

I had wanted to do something with TCPIP and mailslots, and I had figured that Windows NT would be the best glue being in that perfect space of OS/2 compatibility and robust TCP/IP, but I wasted far too much time to basically see that if they are not part of the same domain, the mailslot’s just don’t work.

I haven’t given up, but I primarily used Netware for PC networking back in the 90’s so this is all kind of new to me. Looking through resource kits online there doesn’t seem to be a lot of material about integrating LAN Manager into a NT Domain.

I’ll have to re-think this.

I did go a bit overboard showing how to install MS-DOS & Windows 3.0 on Qemu. Maybe it’ll help someone who wants to try to use Qemu, but is too scared? Maybe I moved too quickly.

One thing I did do differently in this run, is launching the monitor and a serial port as tcp servers so I could telnet into the VM, effectively having a way to share text like a clipboard back and forth. I’m kind of surprised I hadn’t really started using Qemu in this manner much earlier.

qemu.exe -L pc-bios ^
-m 16 ^
-hda apricot.vmdk ^
-net nic,model=pcnet -net user ^
-monitor telnet:127.0.0.1:4000,server,nowait ^
-serial telnet:127.0.0.1:4001,server,nowait ^
-fda yourdisk_here.vfd

Surprisingly it went surprisingly well, other than my goof of having the OS/2 driver instead of the MS-DOS driver for the nic.

Sadly, the tn3270 program bundled with Chameleon doesn’t work properly with Hercules.

As always I’ve uploaded it to archive.org: apricot-dos4-win3-chameleon3.7z

So this is by no means the best fix, it is *A* fix. For me. YMMV.

I had to add this into the site config from apache

<Directory /var/www/mynewsite.org/>
    Options Indexes FollowSymLinks MultiViews
    AllowOverride all
    Order allow,deny
    allow from all
    Require all granted
</Directory>

And does that work? no it sets up mod_rewrite (you did a2enamod it right?! RIGHT?!)

RewriteEngine on
Header always set Content-Security-Policy: upgrade-insecure-requests
RewriteRule ^$ /wordpress [L]

So the big thing here is updating the header. I had to search a bit to find that part, so yeah that was needed. The other part is that wordpress really wants to be in /wordpress not in the root, so a simple RewriteRule will put that in it’s place.

Good Grief.

I should explain my hosting situation more. I’ve been forced into some kind of nomadic situation, and thanks to some weird issue on Azure’s WordPress container thing my site ate itself. Like it literally destroyed the files. I had backups of course, and well either being evicted from a data centre because of the Windows CE Nethack scandal, or having hosting companies either go under with no warning, or drop me for being far too much traffic than they signed up for, I’d taken to not only owning my data but hosting it all myself.

I do enjoy the ‘nomad’ aspect of it all, but it’s a little crazy. I like to think of this as portable stealth hosting as I can blend into user traffic, and I can physically take my data with me. Of course, I have backups as well!

So to describe the setup I guess i need a fine MS Paint style drawing!

I have been using this kind of setup to some degree going back to when I setup the utzoo search engine back in 2017. I’d only expanded on it to host everything now. Working backwards I need to blend into residential traffic, so I need a typical 90’s like office vpn, which means PPTP. So going on lowendbox, I get some cheap VPS, install haproxy and PPTP server onto that. This way I’m basically renting out a static IP address for less than a Starbucks, but it let’s me have the freedom to move around and just look like user traffic, as the PPTP connection is bi-directional.

On the VPS I use a haproxy much like this:

	bind *:443 ssl crt /etc/haproxy/haproxy.pem
	redirect scheme https code 301 if !{ ssl_fc }
	mode http
	acl cloudflare src 173.245.48.0/20 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22 141.101.64.0/18 108.162.192.0/18 190.93.240.0/20 188.114.96.0/20 197.234.240.0/22 198.41.128.0/17 162.158.0.0/15 104.16.0.0/13 104.24.0.0/14 172.64.0.0/13 131.0.72.0/22
	tcp-request content accept if cloudflare
	tcp-request content reject
	acl host_utzoo hdr(host) -i utzoo.superglobalmegacorp.com
	acl host_utzoo hdr(host) -i altavista.superglobalmegacorp.com
	acl super_virt hdr(host) -i virtuallyfun.superglobalmegacorp.com
	acl host_blog hdr(host) -i virtuallyfun.com
	acl host_blog hdr(host) -i unix.superglobalmegacorp.com
	acl host_bow  hdr(host) -i bow.superglobalmegacorp.com
	acl host_blog hdr(host) -i oldlinux.superglobalmegacorp.com
	acl host_blog hdr(host) -i macmint.superglobalmegacorp.com
	acl host_blog hdr(host) -i tuhs.superglobalmegacorp.com
	acl host_nt31 hdr(host) -i winnt31.superglobalmegacorp.com
	acl host_blog hdr(host) -i superglobalmegacorp.com

        acl blog_path path_beg -i /wordpress
        acl blog hdr(host) -i virtuallyfun.com

	redirect prefix https://virtuallyfun.com code 301 if { hdr(host) -i virtuallyfun.superglobalmegacorp.com }

        http-request set-uri %[path,regsub(/wordpress/,/)] if blog_path blog
        redirect code 301 location https://virtuallyfun.com/ if blog_path blog

	use_backend utzoo if host_utzoo
	use_backend lenovo if host_blog
	use_backend nt31 if host_nt31
	use_backend bow if host_bow


backend utzoo
	server zoo1 192.168.23.10:8080

backend lenovo
	server blog1 192.168.23.10:80

backend bow
	server bow1 192.168.23.10:8888

backend nt31
	server apache 192.168.23.5:80

This way I can use various backend servers to split up various domains on the same port. Since cloudflare fronts I don’t need any weird SSL certificate with combination domains. I also get to sneak in a redirect for the old virtuallyfun.superglobalmegacorp.com, as google had a major fit about me not having it at the top level domain. The Windows NT 3.1 server is a Qemu virtual machine running on the VPS. It just has a static page so there wasn’t much point being all that sophisticated.

I then setup a Cloudflare account, and then point my domain directly to the VPS. This also let’s me grab a certificate from Cloudflare to load onto the VPS to encrypt the conversation from them to my VPS, just as the PPTP connection is also encrypted. Another advantage of PPTP over say IPsec is that older OSs like Windows NT 4.0 support it. Not to mention with tunnels being left up so incredibly long, once again I want to blend in as user traffic, and IPsec or OpenVPN just draws too much attention. It sure did in China, and sadly that’s the model I fully expect more and more of the world to be following.

The other advantage of Cloudflare is that they do some aggressive caching which makes hosting on a residential connection viable. In this case over the last 30 days I’ve only had to ‘upload’ 41 of the 158GB of traffic.

If something gets popular this can make all the difference! Again, it’s key to being stealthy.

In the same way it also allows me to host my own Exchange, or any other weird application. Which then takes me to the Apache config. I have Windows 10 on the Lenovo, and loaded up WSLv1 so I could have Windows natively integrate with the filesystem. I also like that it’s got such low overhead as WSLv1 is just a subsystem, unlike v2 being a lightweight VM, like shades of Win/OS2 back in the day. My setup takes a big page from running SWGEMU on WSLv1, where I use the Win64 version of MariaDB, and the Apache/PHP is in a Linux Ubuntu distro. The other advantage here is that as my Lenovo PPTP’s into the VPS, the Apache will by default listen on port 80. Which then leads to the whole needing to set security on the headers to allow the http to become a seamless https.

I also can have multiple things listening on different ports, just as I use haproxy again locally to split out the utzoo site onto the old Apache server with all the re-write rules, and then finally to the Windows NT 4.0 workstation with the Altavista Personal desktop search.

The overall performance on this low end Xeon E3-1225 v2 is quite acceptable.

As I had mentioned WSLv1 being a subsystem means that the processes are transparent so task-manager can immediately show yo what is going on. The opaqueness of Virtual Machines just adds to the time to identify any issues.

And all it takes is a scheduled task to dump the MariaDB, and run an xcopy onto my OneDrive, and now I’ve got a cloud backup. No plugins needed, no scripts that will break as cloud API’s are forever being depreciated and changing. Very nice!

I do like the flexibility of this being a somewhat simple setup. Not to mention being able to have more than one WSL container for various applications, being able to go so far as to break my Apache setup into multiple instances, all being ‘l7 routed’ through an instance of haproxy either at home, or in the VPS is very nice.

Oh, sure I could mess with self signed certs, and trust myself but I just didn’t want to deal with the overhead of double encryption. Maybe it’s something I’ll revisit later.

Also sorry for the ads. 2024 is starting out…. interesting.

A while back I was looking for a 19in 5:4 screen so I messaged a guy I know that would normally have something like it. When I asked him about it, he said he didn’t have any 19in screens, however, he has this “14in Sun LCD”. I was intrigued so I asked him to send pics of it. Lo and behold, this is what he sent me the next day:

Unfortunately, bad news came. He powered it on and told me it was flickering. Ok fine. These are hard to come by in my country (Vietnam) so I decided to get it anyways. He also cut the price by half, so it was reasonable-ish.

When I got home and powered it on…. yeah. It was flickering. I opened up the menu of the LCD and I quickly noticed something peculiar: the image was flickering but the LCD menu was not. When I opened it up, I made yet another interesting discovery: the whole thing is practically a sun ray duct taped to a normal LCD. The sun ray board is not driving the lcd directly, there’s a separate controller board (similar to what you would find in a normal standalone display without a sun ray shaped tumor on the back).

As it turns out the flickering was caused by a single cap that went bad. I replaced it and the image looks good.

There is a GUI thing I’ve read that allows you to configure various parameters of the sun ray so I tried to bring it up. No matter what key combo I pressed it didn’t show up. Once again, bad news came. My sun ray has the non-GUI firmware. The only way to enable it is to flash a GUI firmware or a firmware with GUI enabled (the firmware shipped with SRSS 5.1 and below has separate firmware files for GUI and non-GUI while SRSS 5.2 and later both GUI and non-GUI are a single file, GUI on/off is specified with a flag during flashing).

Okay then. No big deal, all I have to do is just flash the firmware, right? Well yes but no. I would very quickly find out that I don’t have the firmware. I had SRSS 5.4 installed and turns out, 5.3 and later stopped including the firmware and that was something you needed MOS for. Great job Larry!

Okay then. No big deal, all I have to do is just download SRSS 5.2, right? Once again, for the second time, yes but no.

*cough*

2 days later I got access to edelivery again. I downloaded SRSS 5.2. I uninstalled SRSS 5.4 and installed 5.2, all I have to do now is just flash the firmware right? riiiight??? Once again, for the THIRD time, yes but no. For some reason I was able to flash the firmware with “utload“ (which has GUI disabled) but I couldn’t flash it with “utadm“ despite it being able to connect to my T5220 and start a session just fine. As I would find out after one whole day wasted, I was supposed to use a separate network served by the T5220, and this is what I did:
Setup NET1 port as a dedicated interface for Sun Ray

-bash-3.2$ sudo utadm -a e1000g1
### Warning: DHCP Service is in the maintenance mode
             There could be a problem with the DHCP configuration

### It is strongly recommended to fix the problem and then use:
### "/usr/sbin/svcadm clear svc:/network/dhcp-server:default"
### to get DHCP service out of the maintenance mode before running utadm

Do you want to Continue?  (Y/[N]): y
### Configuring /etc/nsswitch.conf
### Configuring Service information for Sun Ray
### configuring e1000g1 interface at subnet 192.168.128.0
  Selected values for interface "e1000g1"
    host address:       192.168.128.1
    net mask:           255.255.255.0
    net address:        192.168.128.0
    host name:          t5220-e1000g1
    net name:           SunRay-e1000g1
    first unit address: 192.168.128.16
    last unit address:  192.168.128.240
    auth server list:   192.168.128.1
    firmware server:    192.168.128.1
    router:             192.168.128.1
  Accept as is? ([Y]/N):
### successfully setup "/etc/hostname.e1000g1" file
### successfully setup "/etc/inet/hosts" file
### successfully setup "/etc/inet/netmasks" file
### successfully setup "/etc/inet/networks" file
### Disabling Route Advertisement
### finished install of "e1000g1" interface

### Configuring firmware version for Sun Ray
        All the units served by "t5220" on the 192.168.128.0
        network interface, running firmware other than version
        "4.3_146928-01_2011.06.03.14.41" will be upgraded at their next power-on.      
       
### Configuring Sun Ray Logging Functions


DHCP is not currently running, should I start it? ([Y]/N): ### Error: unable to start dhcp services.
    Please restart dhcp manually after utadm has completed.

well… oops. Shouldn’t’ve ignored that. One “svcadm clear dhcp-server“ and one “svcadm restart dhcp-server“ later… Let’s try to flash the firmware.

-bash-3.2$ sudo utfwadm -A -e 00144F6F69CA -n e1000g1 -G force
-n interface option ignored.  It is no longer required with -e option.
        Unit "00144F6F69CA" will be upgraded at its next power-on
        if it is served by host "t5220" and is connected to
        the  network and is not already running firmware
        version "4.3_146928-01_2011.06.03.14.41".

### stopped DHCP daemon
### started DHCP daemon
### reinitialized DHCP daemon

For those who are wondering what the flags do:

Options:
        -A            # add the specified unit(s) to the upgrade list
        -D            # delete the specified unit(s) from the upgrade list
        -P            # print version information
        -R            # remove firmware modules from boot directory
        -a            # apply to all units connected to the specific interface
                      #  or subnet
        -e enetAddr   # apply to the unit given by the six hex bytes
                      #  of its ethernet address
        -n intf       # name of a dedicated network interface to enable upgrades                                                                                                                                                              on
                      #  (e.g., hme0, vge1, etc. "all" = all interfaces)
        -G option     # control enabling of configuration GUI on Sun Rays
        -g option     # control disabling of configuration GUI on Sun Rays
        -i filename   # append contents of filename to config files
        -N subnetwork # shared subnetwork address to enable upgrades on
        -d            # actively disable firmware download (useful with "-e")
        -V            # only generate version files, do not configure DHCP
        -F            # force firmware load even if downgrading
        -u            # use frame buffer to do download and decompression
        -f firmware   # use the firmware described by the path "firmware"
                      #  for upgrades on the given network interface(s)

Power cycle with CTRL+Pause+A and…

…success!

Fun fact: the firmware is stored temporarily in the framebuffer (iirc at least) The GUI can now be accessed:

I hosted a Porting Party last where where I setup my Dec Alpha as a terminal server allowing people from all over the world to connect in and cross compile software for the 64bit version of Windows for the Dec Alpha. While many problems were overcome, and many more remain, I have to say the most annoying thing was joining a domain hosted by a SAMBA server.

In my mind, I though the easiest way to get files in & out of the Alpha was not to use something like IIS/FTP where it would probably lead to end-less issues with text/binary/active/passive modes, but rather I should rent a VPS, install the OS default SAMBA and just map drives. The benefit of the VPS is that it has a public address, so no NAT is required. The VPS had an option for either CentOS (no) or Debian 10. I went with the Debian, and did an in place upgrade to 11, then 12. Nothing special.

I’d never actually used SAMBA as a domain controller before, but I thought this would be a fun experiment. So the idea is then that the VPS running SAMBA is the Domain Controller, and my Alpha joins it as a member server. Everyone else can use Windows or any SAMBA client and map drives, and then copy files to the VPS, and then copy back and forth from the Alpha to the VPS. This part worked fine.

What didn’t work was SAMBA version 4.

I had come up with this config, based on the fragments of the default config, and and hints from samba.org.

[global]
    netbios name = PDC
    passdb backend = tdbsam
    server max protocol = NT1
    username map = /usr/local/samba/etc/username.map
    workgroup = ALPHAPARTY
    server string = Samba Server
    security = user
    hosts allow = 127.0.0.1, <<<peoples networks...>>>
    load printers = yes
    log file = /usr/local/samba/var/log.%m
    max log size = 50
    passdb backend = tdbsam
    local master = yes
    os level = 33
    domain master = yes
    preferred master = yes
    domain logons = yes
    wins support = yes
    dns proxy = no
    add user script = /usr/sbin/useradd %u
    add group script = /usr/sbin/groupadd %g
    add machine script = /usr/sbin/adduser -n -g machines -c Machine -d /dev/null -s /bin/false %u
    delete user script = /usr/sbin/userdel %u
    delete user from group script = /usr/sbin/deluser %u %g
    delete group script = /usr/sbin/groupdel %g
[homes]
    comment = Home Directories
    browseable = no
    writable = yes
[printers]
    comment = All Printers
    path = /usr/spool/samba
    browseable = no
    guest ok = no
    writable = no
    printable = yes
[public]
    comment = share for everyone
    path = /public
    public = yes
    writable = yes
    printable = no
    creaet mask = 0777

I had endless issues with the machine account not being either created correctly or not being authenticated. I tried manually creating it, to no avail. No matter what I tried it didn’t work.

Working with NT 4.0 must be depreciated or something but no matter what I tried IT JUST DIDN’T WORK.

Feeling outraged, I purged the old Samba, downloaded the source code to 3.6.25, built that, and using the same configuration I had tried to put together, it just worked.

Adding users was somewhat straight forward:

useradd -M -s /bin/bash neozeed
passwd neozeed
/usr/local/samba/bin/smbpasswd -a neozeed
/usr/local/samba/bin/smbpasswd -e neozeed
mkdir /home/neozeed
chown neozeed /home/neozeed/

Creating both a Linux user & directory, and the SAMBA credentials. On the terminal server, all that remains was assigning a local home directory & profile directories, as you really don’t want those over the WAN.

I have no idea if this is a warning to others, or whatever the larger issue is.

Porting Party II

At any rate I’ll be running another porting party this coming weekend. I can host cross compiling fine, but we need people with the 64bit Whistler beta installed to test. The best way to get details is over on discord. Lately the IRC bridge is down more than it’s up, and I can’t effectively send out passwords & get your network block to allow access to the RDP, since I’m not going to open up worldwide access to a Windows NT 4.0 SP5 machine.

So for anyone interested in porting their C/C++ to either the 32bit Alpha Windows, or 64bit Alpha Windows come join us on discord!

I’ll fire up the Alpha on Friday afternoon GMT and expect the event to run all weekend!

I want to have an internet server that people can map drives to, for copying data in/out for the upcoming Dec Alpha AXP64 building extravaganza! I wan tot use my Dec Alpha for building since it’s got a gigabyte of RAM. One of the hard parts is that NT 4 is beyond obsolete, and twice as much on the DEC Alpha. I was figuring renting a VPS, and using it as a SAMBA server so people can simply map a drive from home, copy files to the VPS, terminal server to the Alpha, and copy files to & from the internet. Easy right?!

I was non stop getting this error:

System error 1326 has occurred.

Login failure: unknown user name or bad password.

Except I knew the username & password was correct.

The key part involved a few parameters to get it working. Although many people reported success by simply setting the protocol level, for me I had to set that and the lanman/ntlm auth to yes. Trying to enable NT4 compatible encryption didn’t work either.

[global]
   workgroup = WORKGROUP
   server min protocol = NT1
   client min protocol = NT1
   lanman auth=yes
   ntlm auth=yes

I’m not sure if it’s all that helpful to the world at large, or if it’s just super common knowledge, but I haven’t setup SAMBA in like forever. I guess I could go one further and join it to the domain but that doesn’t seem like it’s all that needed or all that smart.