Because I hate losing my mind with Apache

Posted on January 12, 2024 by neozeed

I needed to setup another WordPress for something else, and I host it on a server with no https. However of course it’s fronted by a proxy with https. And WordPress embeddeds the http into the stream, and changing that with redirects causes it to ping pong like crazy.

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.

Using an AIM-VPN EPII Plus in a Cisco 3845 or how to convert an EPII to HPII

Posted on January 11, 2024 by neozeed

this is a guest post by night3719

I got a 3845 for cheap with an AIM-VPN/EPII-PLUS salvaged from a 2851. At the seller’s place I installed the card and tested the 3845 there. When IOS was booting up I noticed a message along the lines of “AIM type unsupported by this platform”. I didn’t think much of it and just thought maybe I was using a version of IOS that didn’t support the module.

When I got home I threw a bunch of different IOS versions at it and nothing worked. Something was off.
As it turns out, there are 3 variants of that card, one for 1800 (BPII), one for 2800 (EPII) and one for 3800 (HPII) (note: the cards support other routers too but compatibility is a mess).

When I looked up the other variants, I immediately noticed something interesting: the modules seem identical. After looking at questions people who had similar issues posted on the Cisco community forums, something caught my eye: the output from show diag. I noticed that command spits out an EEPROM dump. As it turns out, the only difference between the cards is the contents of that EEPROM.

There are two 93C46A EEPROMs on the board, one connected to the crypto chip which probably holds config data for it and the other connected to the connector that goes to the main board. Okay, all I have to do is flash that chip with the dump I found online, right?

*circled red is the EEPROM for the card, circled blue is the crypto EEPROM*

Wrong.

The contents are obfuscated. Luckily however, two friends far smarter than I am (special thanks to Rachel Mant <[email protected]> and nyanpasu64!) figured out the obfuscation technique and one of them wrote code that encodes/decodes it

def bitSwap(value: int) -> int:
    result = 0
    for bit in range(8):
        result |= ((value >> (7 - bit)) & 1) << bit
    return result

def addrSwap(value: int) -> int:
    result = value & 1
    for bit in range(1, 6+1):
        result |= ((value >> (7 - bit)) & 1) << bit
    return result

data = [
    #data to be encoded or decoded goes here
]

for i in range(0x80):
    byte = data[addrSwap(i)]
    print(f'{bitSwap(byte):02x}', end = '\n' if (i % 16) == 15 else ' ')

I used their code to encode the output from the show diag then flashed it with my TL866. To my surprise, it worked, and the card works even on the latest IOS for this thing (15.1(4)M12a as far as I know)!

And just like that, it works!

So it turns out GCC could have been available on Windows NT the entire time!

Posted on January 8, 2024 by neozeed

This is going to be a bit convoluted but here goes.. GCC isn’t a monolithic compiler, instead it’s various parts are separate programs. This lets us tackle it one part at a time. And/Or bypass a lot of it until I want to tackle it.

I’m sure many people have explained this far better than I ever could but in C you write source files (obviously), the pre-processor reads those and ‘header’ files that describe interfaces to libraries, other objects, various macros and definitions (magical numbers) and the pre-processor will read those files, and do simple macro expansion and test insert/replacements to generate a single .i file at the end of it’s run.

The C compiler (cc1) now reads that single .i file and translates it into native assembly. This allows for ‘mid/high level’ aspects of C to be machine independent (portable) but now will be written into a very system dependant assembly file, the single .S file. One thing of note is that so far everything is text files. You can edit the assembly file as you would any document, or even further ‘process’ it if needed/wanted.

The assembler ax386 (GAS) will then read the single assembly file and write a a binary object file hi.OBJ. There typically isn’t all that much to be said about assemblers although fancier ones allow for really strong Macro capabilities like Microsoft MASM.

From here on, it’s all binary objects!

The linker then takes your object files, and links them together with other system objects and system libraries into an executable, in this case. Linkers can build all kinds of other things, but for now we’re just pretending its static C compilation like it’s the 1970’s.

At it’s heart GCC processes text files.

The first part in this insane experiment, is to build GCC 1.40 with Microsoft Visual C++ 1.0. Surprisingly it didn’t take an insane amount of messing with stuff, and I got an executable! But everything it compiled failed to assemble. Looking at this fragment, even if you don’t know i386 assembly you might spot the error:

main:
        pushl %ebp
        a b,c
        pushl %esi
        pushl %ebx

Yeah, it’s the “a b,c” part. Those are NOT valid i386 opcodes!

Just because it compiled didn’t mean it actually worked.

I used MinGW to build the same source, same Makefile, and I got a working executable. Annoyed I started compiling random files with Microsoft C, and finally found the file that broke it all, it turned out to be insn-output.c needing to be compiled with the “/D__STDC__” flags. A quick modification of the Makefile and now I have a working CC1!

Okay, great, it’s well known back in the early dangerous ages of the 1980’s/1990’s that everyone wasn’t running Linux, nor were binary distributions of GCC that far spread, rather I think to re-enforce the source was available it was expected that you’d use your system compiler. Systems like DJGPP/EMX take the path of binding a.out object files into something that MS-DOS can run via a dos extender, or the bind utility to allow you to run the a.out on OS/2. What I wan’t to do is verify that in fact Windows NT was a viable host for GCC back in the public pre-releases of 1991.

I’m sticking with the December build 239 version as it has working floating point. Something that GCC has intrinsic support of, and I don’t feel like trying to work out emulation.

The next step is to try to build it with the family mode-OS/2 version of the C compiler, which of course lead to the real issue of this 16bit hosted cross compiler:

        cl386 /u /Od /Ic:\MSVC32S\C386\INCLUDE /I. /Iconfig /c combine.c
Microsoft (R) Microsoft 386 C Compiler. Version 1.00.075
Copyright (c) Microsoft Corp 1984-1989. All rights reserved.

combine.c
combine.c(1734) : fatal error C1002: compiler is out of heap space in Pass 2
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x2'
Stop.

Very frustrating. I tried mixing and matching from Visual C++ 1.0 & this old compiler, and while it did compile, it doesn’t run. does it mean anything?!

GCC 1.40 compiled by Microsoft 386 C Compiler. Version 1.00.075

I should point out that this should be an expected working configuration as GCC does build on Xenix using the 32bit Microsoft C 5.1/386 compiler. Furthered again that Xenix and these 1991 versions of NT use the same 32bit OMF object format. And expanding on the Xenixnt experiment using the Xenix’ified GAS assembler with old Visual C++ includes & libraries to produce a possible retro-early port of GCC to NT, the next move is to bulid GAS on NT.

Xenix GAS 1.38 compiled by by Microsoft 386 C Compiler. Version 1.00.075

GAS gave me some weird issues with ctype.h where it runs fine with the one from Visual C++ 1.0 but the OS/2 & NT pre-release both fail. However the old Pre-release compiler cannot deal with the much newer ctype include file. So after much hammering I amputated whatever was bothering it, and it’s just enough to build & run. Great!

Going back to the phases, I used a simple hello world program:

void main() {
 printf("Hello World!\n");
}

While not being a good program, it doesn’t include stdio.h, nor does it return anything. It’s terrible. But in this case it allows me to be lazy and sidestep the pre-processor cpp.exe. This way I can just directly run it through cc1 and get my assembler file hi.S

Next I pass it to ax386 (GAS) and get the resulting object file hi.OBJ

And finally link it with link.exe in this case.

And with all the drama I’ve now compiled a simple hello world program on Windows NT.

If it were 1991, I would hollow out gcc.c so it doesn’t use signals or forks to invoke the needed phases, and of course build the pre-processor. In addition, libgcc needs to be compiled to allow for floating point operations to work correctly. None of which is impossible, although I’m not sure it’s all that needed as it isn’t 1991.

With a little bit more work, I got the floating point support to compile, which relies on both a working ‘native’ compiler, and a working GCC to compile the 2nd half. I usually use phoon, or Phases of the Moon, to test floating point, and as you can see, it’s working!

I’m not sure if there was a 32bit version of Microsoft C/386 available for Microsoft OS/2 2.00 betas. Also, I don’t know if the Microsoft link386 for OS/2 can also link Xenix 386 object files? Would it have been possible to bootstrap GCC/GAS on Microsoft OS/2 2.00? I really don’t know, and as of this writing no versions of the old Microsoft OS/2 2.00 betas have surfaced.

** update from the future, turns out that I found a way to convince the cl386 compilers from the NT Pre-Releases in 1991 to re-build an existing GCC that was built for NT. The catch is the linker, LINK386 of course, as the format was constantly changing. However the object files are fine, and I was able to just copy them over on diskette and re-link the compiler. It even ran. It’s not tested at all, so it turns out the 1989 compiler wasn’t good enough, but the 1991 was.

It’s interesting to me to see that even before GCC 2.6, that vintage versions from 1991 would compile and run directly on Windows NT.

I uploaded the source on github, along with some binaries.

The Rise of Unix. The Seeds of its Fall. / A Chronicle of the Unix Wars

Posted on January 5, 2024 by neozeed

It’s not mine, rather it’s Asianometry‘s. It’s a nice overview of the rise of Unix. I’d recommend checking it out, it’s pretty good. And of course, as I’m referenced!

The Rise of Unix. The Seeds of its Fall.

And part 2: A Chronicle of the Unix Wars

A Chronicle of the Unix Wars (youtube.com)

Years ago I had tried to make these old OS’s accessible to the masses with a simple windows installer where you could click & run these ancient artifacts. Say 4.2BSD.

Download BSD4.2-install-0.3.exe (Ancient UNIX/BSD emulation on Windows) (sourceforge.net)

Installing should be pretty straight forward, I just put the license as a click through and accept defaults.

Starting BSD via ‘RUN BSD42’ and the emulator will fire up, and being up a console program (Tera Term) giving you the console access. Windows will probably warn you that it requested network access. This will allow you to access the VAX over the network, including being able to telnet into the VAX via ‘Attach a PTY’ which will spawn another Tera Term, prompting you to login.

You can login as root, there is no password, and now you are up and running your virtual VAX with 4.2BSD!

I converted many of the old documents into PDF’s so you may want to start with the Beginners guide to Unix. I thought this was a great way to bring a complex system to the masses, but I’m not sure if I succeded.

As it sits now, since 2007 it’s had 776 downloads. I’d never really gotten any feedback so I’d hoped it got at least a few people launched into the bewildering world of ancient Unix. Of course I tried to make many more packages but I’d been unsure if any of them went anywhere. It’s why I found these videos so interesting as at least the image artifacts got used for something!

But in the off hand, maybe this can encourage some Unix curious into a larger world.

Other downloads in the same scope are:

Enjoy!

Win32Emu / DIY WOW

Posted on January 4, 2024 by neozeed

This is a guest post by CaptainWillStarblazer

When the AXP64 build tools for Windows 2000 were discovered back in May 2023, there was a crucial problem. Not only was it difficult to test the compiled applications since you needed an exotic and rare DEC Alpha machine running a leaked version of Windows, it was also difficult to even compile the programs, since you needed the same DEC Alpha machine to run the compiler; there was no cross-compiler.

As a result, I began writing a program conceptually similar to WOW64 on Itanium (or WX86, or FX-32), only in reverse, to allow RISC Win32 programs to run on x86.

The PE/COFF file format is surprisingly simple once you get the hang of it, so loading a basic Win32 EXE that I assembled with NASM was pretty simple – just map the appropriate sections to the appropriate areas, fix up import tables, and start executing.

To start, I wrote a basic 386 emulator core. To complement it, I wrote my own set of Windows NT system DLLs (USER32, KERNEL32, GDI32) that execute inside of the emulator and then use an interrupt to signal a system call which is trapped by the emulator and thunked up to execute the API call on the host.

For example, up above, you can see that the emulated app calls MessageBoxA inside of the emulated USER32, which puts 0 in EAX (the API call number for MessageBoxA) and then does the syscall interrupt (int 0x80 in my case), which causes the emulator to grab the arguments off of the stack and call MessageBoxA.

To ease communication between the host’s Win32 environment and the emulated Win32 environment, I ran the emulated CPU inside of the host’s memory space, which means that to run applications written for a 32-bit version of Windows NT, you need a 32-bit version of win32emu (or a 64-bit version with /LARGEADDRESSAWARE:NO passed to the linker) to avoid pointer truncation issues, to prevent Windows from mapping memory addresses inaccessible by the emulated CPU.

To get “real” apps working, a lot of single-stepping through the CRT was required, but eventually I did get Reversi – one of the basic Win32 SDK samples – to work, albeit with some bugs at first. Calling a window procedure essentially requires a thunk in reverse, so I inserted a thunk window procedure on the host side that calls the emulated window procedure and returns the result.

After this, I got to work on getting more complicated applications to work. Several failed due to lack of floating-point support, some failed due to unsupported DLLs, but I was able to get FreeCell and WinMine to work (with some bugs) after adding SHELL32. I was able to run the real SHELL32.DLL from Windows NT 3.51 under this environment.

One might wonder why I put all this work into running x86 programs on x86, but the reason is that there’s the most information about, and I’m most proficient with, Windows on the 386. Not only does Windows on other CPUs use other CPUs, but also there’s different calling conventions and a lot of other stuff I didn’t want to mess with at first. But this was at least a proof-of-concept to build a framework where I could swap the CPU core for an emulator for MIPS or PPC or Alpha or whatever I wanted and get stuff running.

Astute readers might be wondering why I didn’t take the approach taken by WOW64. For those who don’t know, most system DLLs on WOW64 are the same as those in 32-bit Windows, the only ones that are different are ones with system call stubs that call down to the kernel (NTDLL, GDI32, and USER32, the first of which calls to NTOSKRNL and the latter two calling to WIN32K.SYS). WOW64 instead calls a function with a system call dispatch number, which does essentially the same thing. The reason for this is that the system call numbers are undocumented and change between versions of Windows. WOW64, being an integrated component of Windows, can stay up to date. If I took this approach, I’d either have to stay locked to one emulated set of DLLs (i.e. from NT 4.0) and use their system call numbers on the emulated side, or write my own emulated DLLs and stick to a fixed set of numbers, but either way I’d somehow have to map them to whatever syscall numbers are being used on the host.

As I went on, I should probably also mention that what I said earlier about loading Win32 apps being easy was wrong. Loading a PE image is pretty straightforward, but once you get into populating the TEB and PEB (many of whose fields are undocumented), it quickly gets gnarly, and my PEB emulation is incomplete.

Adding MIPS support wasn’t too much of a hassle, since the MIPS ISA (ignoring delay slots, which gave me no shortage of trouble) is pretty clean and writing an emulator wasn’t difficult. The VirtuallyFun Discord pointed me to Embedded Visual C++ 4.0, which was invaluable to me during development, since it included a MIPS assembler and disassembler, which I haven’t seen elsewhere. After writing a set of MIPS thunk DLLs and doing some more debugging, I finally got Reversi working.

There’s still some DLL relocation/rebasing issues, but Reversi is finally working in this homebrewed WOW!

I’d encourage someone to write a CPU module for the DEC Alpha AXP (or even PowerPC if anyone for some reason wants that). The API isn’t too complicated, and the i386 emulator is available for reference to see how the CPU emulator interfaces with the Win32 thunking side. An Alpha backend for the thunk compiler can definitely be written without too much trouble. Obviously, the AXP presents the challenge that fewer people are familiar with its instruction set than MIPS or 386, but this approach does free one from having to emulate all of the intricate hardware connections in actual Alpha applications while still running applications designed for it, and I’ve heard the Alpha is actually quite nice and clean. MAME’s Digital Alpha core could be a good place to start, but it’ll need some adaptation to work in this codebase. Remember that while being a 64-bit CPU with 64-bit registers and operations, the Alpha still runs Windows with 32-bit pointers, so it should run in a 32-bit address space (i.e. pass /LARGEADDRESSAWARE:NO to the linker).

Theoretically, recompiling the application to support the full address space should enable emulation of AXP64 applications, since the Alpha’s 64-bit pointers will allow it to address the host’s 64-bit address space, but I’m not sure if my emulator is totally 64-bit clean, or if the AXP64’s calling convention is materially different from that on the AXP32 in such a way that would require substantial changes. In either case, most of the code should still be transferable.

I also want to get more “useful” applications running, like development tools (i.e. the MSVC command line utilities – CL, MAKE, LINK, etc.) and CMD. Most of that probably involves implementing more thunks and potentially fixing CPU bugs.

This project is obviously still in a quite early stage, but I’m hoping to see it grow and become something useful for those in the hobby.

For those who want to play along at home, you can download the binary snapshot here: w32emu.zip

A more complete version of the writeup is available here: https://bhty.github.io/og/win32emu_VirtuallyFun_Post.htm and you can find the project here https://github.com/BHTY/Win32Emu/.

In some weird twist almost all the old NetBSD source code is gone. again

Posted on January 3, 2024 by neozeed

I don’t know what is up, but it even was such a perplexing loss that even bitsavers is now saving NetBSD.

bitsavers doesn’t normally image files from active sites, but when archive.netbsd.org was down for an extended period of time and no mirrors were found, having at least the NetBSD iso files mirrored worldwide seemed like a prudent thing to do. This is a massive storage and bandwidth burden we’ve taken on, please be considerate towards us and our mirrors. For example, people trying to run 10’s of rsyncs in parallel will be banned.
aek 20231002

It reminds me back to the work of trying to revive NetBSD 0.8, and that fun adventure, then it all showed up. I saved it and moved on, but now it seems to be my turn to save the past again.

I know its a terrible URL but here it is : My old NetBSD archive

Highlights include:

I was interested in running the first public VAX versions, and 1.1 didn’t run on VAX so it didn’t interest me. Sorry.

Otherwise, you’re welcome

SINIX-Z 5.42 on 86Box

Posted on January 1, 2024 by tenox

(this is a guest post by Antoni Sawicki aka Tenox)

As part of nerdy new year celebrations I got Fujitsu Siemens Nixdorf Informationssysteme SINIX-Z running on 86Box. This was possible thanks to Plamen and Vlad!.

Update: got X11 going:

Also C compiler:

Also networking… apparently you have to manually connect it.

Here is a pre-installed image and 86Box configuration file. Now includes bash, gcc and gzip. These are also downloadable here.

Happy 2024

Posted on December 31, 2023 by neozeed

Sorry I’d been working on something but it’s just not going to happen quick enough for some NYE surprise.

Some of my favorite highlights include:

With of course the totally unexpected surprise of ‘Windows 2000 64-bit for Alpha AXP‘. What a year!

Hopefully the new year is a prosperous one.

86 DOS Version 0.11 found!

Posted on December 30, 2023 by neozeed

As of this moment, this is the oldest version of 86-DOS surviving in the wild. The prior version was 0.34. You can download a disk image over on archive.org. Thanks to F15sim for providing the uploads!

Getting this running was a little involved as I first had to build open-simh, I just used the Windows Subsystem for Linux (WSL) to build the altairz80 emulator. With the emulator built, you’ll need the BIOS 86mon.bin from schorn.ch as 86dos.zip. In the archive you’ll find 86-DOS 1.0 in the zip file. Simply editing the file 86dos and specifying the 0.11 download (I renamed it as it’s too long and too many spaces!) and you’ll be able to run 86-DOS.

There isn’t much on the diskette:

COMMAND COM
RDCPM COM
HEX2BIN COM
ASM COM
TRANS COM
SYS COM
EDLIN COM
CHESS COM
CHESS DOC

There is a simple chess game, although I’m not much of a player..

A:chess

Choose your color (W/B): W
Ply depth (1-6): 1
E2-E4
e7 e5

There is no source code in this disk image, but there is some stuff on the 0.34 image.

Just a quick post in that middle of the night.

Merry Christmas 2023!

Posted on December 25, 2023 by neozeed

It’s been… a trying year, and unfortunately the nonsensical stuff I had planned to do this year fell through. Sadly all I have is this half baked idea, so I’m sorry but I guess it’s better than nothing?

OS X 10.4.1 / Maklar, a lump of coal

While talking about Mach/XNU and of course how obvious with how ‘easy’ it was to build Darwin 0.3 for i386, I had noticed that the original Marklar 10.4.1 deadmoo image had all up and disappeared from the internet. Obviously, that had to be fixed, and I was able to locate a copy, and upload it to archive.org! (merry christmas?!)

Digging around further lead me to this post on macrumors.com, detailing the hardware that Apple used for the Apple Development Transition Kit, and how it was an Intel D915 Pentium 4 board. Neat! So digging around some more and I find this:

An entire setup guide by Mark Hoekstra! (RIP). The big takaway here is that if you want the accelerated graphics for the best Marklar experience you need an Intel board with the 915 chipset. Combing through theretroweb.com, you can find quite a few boards that used this chipset. I didn’t want to spend a lot of pateron money on this, so I thought I could do it on the cheap. I picked up a Dell 4700 motherboard, and some ‘as is’ 915 boards for their CPU’s and RAM.

I really need to get some SATA cables, I had to pull one out of my AMD64 machine to get this thing going. Which leads to the other issue how to boot this thing?!

I won’t touch much onto it as I couldn’t get any custom menus working at all so the usefulness is super limited, but I setup netboot.xyz at home, was able to netboot the board, and dd a deadmoo onto the SATA disk I pulled from the G5 iMac.

On many of these Dell boards there is only one fan jack, so I just made a simple breakout so I could drive some fans & a AIO liquid cooler. Although the dell boards suck when it comes to easy heatsink mounting.

Dell board with fan breakout & something heavy to hold the water block in place

It wasn’t pretty but it did work.

booting up

So yeah it booted up into OS X! It’s super fast. One thing that was always interesting is that running 10.4.1 under VMware or Qemu is that there is a lot of blitting ‘bugs’ that artifacts like crazy. And it does it on real hardware. It was pretty neat to see. Unfortunately there was a long term issus with the board that I didn’t really pay attention to the USB ports.

Even OS X noticed the USB problem

Since I was using PS/2 peripherals I thought I could just ignore it.

In order for the accelerated video to work you need the Intel 915 chipset with GMA-900 support.

I do have the PCI-E adapter, the ADD2 card that is apparently needed, but I was copying over some video files and the board suddenly powered off, never to power up again.

So in the end, I just had an hour or so running 10.4.1, and now I have 3 processors, about 4GB of RAM, and a box of dead boards. I did get lucky that the 22 GoodBoyPoints (GBP) did refund me the price of the board. So maybe I’ll tackle it again next year.

BOW the gift that keeps on giving

In BOW news, the excellent Win16 emulator WineVDM had enough updates where BOW starts to run. And yes my hammering of Apache does in fact run! I can’t imagine what to really put on a page to make it interesting, but behold bow.superglobalmegacorp.com.

Not sure what to say, BOW on WineVDM on Windows 10

I was going to try to do some DOSBox using Trumpet PPP to a Linux VM to give it internet access this way, but WineVDM is far easier to get working. YAY.

That about wraps it up

Sorry if you were expecting anything cohesive or making sense, but sadly it hasn’t. I’m not sure if pursuing the Marklar thing is worth it, although it was cool.

Virtually Fun

Fun with Virtualization