Building Synchronet on Debian Stretch

Yay

I still run an ancient BBS, using Synchronet on OS/2.  The problem being that I not only get port scanned an incredible amount of times, but so many things out there now logon as root/root and they think they are on a Linux machine and can then shell script their way into some exploits.  Ive tried rate limiting, and other methods, but I end up with so many distributed connections that SIO can’t cope and it’ll crash.  A reboot will fix it, of course, but rebooting 2-3 times a day is a bummer.  So I thought I’d front my BBS with a stub BBS, which means building Synchronet from source.  And while there is some guides on how to do this, I naturally hit some weird undocumented error.

So yeah, get ready for this fun error:

jsapi.cpp: In function ‘JSIdArray* JS_Enumerate(JSContext*, JSObject*)’:
jsapi.cpp:3988:16: error: cannot convert ‘bool’ to ‘JSIdArray*’ in return
return false;

So it turns out that GCC 6 and higher won’t compile the older javascript engine that Synchronet relies on.  Ok, so I figured I would just fix the cast and go on my way.  But no, as part of the build process once it figures out that I’ve tampered with a file it’ll re-unpack the engine and break on the same error again.  And this is why I find things that try to be so ‘easy’ and holding (I’m looking at you Cmake!!!!) end up being totally black box, and absolutely useless.

So what I really need is g++ 4.x, and what is the quickest and easiest way to get the old compiler?  Ugh, grab the package from the prior version Jessie.  Seriously.  Add this into your /etc/apt/sources.list

deb http://ftp.us.debian.org/debian/ jessie main contrib non-free

and then run:

apt-get update && apt-get install g++-4.9

And take the new line out of /etc/apt/sources.list or you will have hell to pay.

After that it was a matter of modifying some of the logon code to streamline the logon process, and to gut the ‘ham radio’ door into something that’ll telnet to the OS/2 BBS.  After a bit of work it actually works.  I even tested Zmodem, and that works too!

Logging into the proxy

I need some ASCII art or something.  That and probably turn off new user registration.  Guest access is all anyone can get on the proxy.

Telnet menu

I could probably do more here.  Years ago I ran some public access Ancient UNIX stuff, but the problems were that it got slammed from the internet.  But if Synchronet can keep up with the idiots on the outside, I guess this works as a jump point into something else?  I may have to see about adding some 386BSD, and Linux 1.0

QEMUOS2 via modern Synchronet

And here we are, at the old BBS.  I never got that many people to begin with, and I did like having the only OS/2 BBS on the internet up.  The other BBS O-Zone seems to have given up, as their domain expired.  So it’s just me, once more again.

I’m sure the vast majority of people won’t care, but I guess I finally hit the tipping point where 1996’s SIO just can’t keep up in 2017’s world of relentless port knocking.

SQL Server 6.5 on Windows 10 x64

SQL Server 6.5 running on Windows 10

In the same effort as getting SQL Server 4.21a running on Windows 10, I found that SQL Server 6.5 will run as well.  For what it’s worth, SQL Server 6.0 runs, but the enterprise manger will not run, giving this fun error:

sdf

The SQLOLE OLE object could not be registered.

And SQL 7.0 just bombs out with this:

x

Your SQL Server installation is either corrupt or has been tampered with (unknown package id).

Which clearly means I’m missing something in trying to transplant settings.  However for some reason SQL 6.5 I can register the SQLOLE type, and boom!

SQL 6.5 in action

SQL Server 6.5 running on Windows 10

SQL Server 6.5 running on Windows 10

On Win64 vs Win32 and COM objects

I should mention that when registering a COM object you typically run something like this:

regsvr32.exe \mssql\binn\SQLOLE65.DLL

Which picks up the one in the default path.  What about system32?

%SYSTEMROOT%\system32\regsvr32.exe \mssql\binn\SQLOLE65.DLL

Well it turns out that this ‘system32’ directory is actually the 64bit system directory!  And attempting to do this will just result in the error:

64bit regsvr32 on a 32bit COM object

64bit regsvr32 on a 32bit COM object

The module was loaded but the call to DllRegisterServer failed with the code 0x80040005. Well great.  This typically goes back to a permissions issue, or the wrong regsvr32.exe being called.

However on a Win64 based OS, you actually need to specify the Win32 version of regsvr32 which actually lives in the SysWOW64 directory, and run the command prompt at administrator!  So you would run it like this:

%SYSTEMROOT%\SysWOW64\regsvr32.exe \mssql\binn\SQLOLE65.DLL

And you should get:

adf

32bit regsvr32 working

With this COM object registered, you can now launch the Enterprise manager!

Also I found a semi fun way to rename the SQL server:

sp_configure ‘allow updates’, 1
go
reconfigure with override
go
delete sysservers
go
sp_addserver YOURSERVERNAME,local
go
shutdown
go

Running this and it renamed the local SQL instance, and shut it down.  Restarting and it connected to itself just fine.  Naturally change YOURSERVERNAME to whatever your hostname is.  SQL server always wants to be called whatever the actual hostname is, otherwise things break in strange and confusing ways.

Thoughts

Is this terribly useful?  Probably not.  But I think it’s kind of interesting to run 90’s era server software in the 21st century.  Sure I wouldn’t want to run any of it in any type of production environment, but it shows at it’s core how Win32 has not drifted.  However looking at the Microsoft Management console of SQL Server 7.0, and how it will not either run on Windows 10, nor will the snapin run show just how fragile the house of COM turned out to be, and meanwhile good old fashioned Sybase/Win32  code still runs from 1993 onward.

I suppose the next thing to do is to try it on Wine, or a fun enough debugger/syscall trace to see what on earth SQL 7.0’s problem is.  I don’t have any doubt that it’s nothing that can’t be fixed, although back to the root point, would you really want SQL 7.0 in 2016… or even SQL 2000 for that matter.

Retro computing for $99

I was cruising around New Capital Computer Plaza, looking for some cisco console cables, and I saw a bunch of old Xeon desktop computers for sale.  Prices were in the 250-500 USD range, which seemed pricey to me.  And keeping in mind that my desktop is already a Xeon E3-1230, it did seem kind of pointless.  But then I saw this Dell Precision 490 for about $99 USD.

Dell Precision 490

Dell Precision 490

Great, so what are the general specs?

Well, the ‘nice’ thing about Dell is that they keep all their old stuff online, so looking at the specsheet we can see It’s not a bad machine for something circa 2006.  Even archive.org has the old pricing online too!

Mine came with a Xeon 5160, 8GB of ram, 250 GB disk, and an ATI HD 4850

  • Dell Precision Workstation 490 Desktop – 32bit $2,852
  • Dual Core Intel® Xeon® Processor 5160 3.00GHz, 4MB L2,1333 [add $930]
  • 4GB, DDR2 SDRAM FBD Memory, 533MHz, ECC (4 DIMMS) [add $570]
  • 4GB, DDR2 SDRAM FBD Memory, 533MHz, ECC (4 DIMMS) [add $570]
  • 250GB SATA 3.0Gb/s,7200 RPM NCQ Hard Drive with 8MB DataBurst Cache™ [add $90]

By my calculations this machine was about $5,012 USD, and that isn’t including the after market video card, which would be about $180 USD when it was new in 2008, bringing the total MSRP on this thing to $5,192 USD!

Of course it is now 2016, and this machine is 10 years old, with an 8 year old video card.  Also of interest is that it came licensed for Windows XP x64, which was the first publicly available AMD64 OS from Microsoft.  Unlike traditional Windows XP, this 64bit version is actually built around Windows server 2003.

The computer came with a pirated copy of Windows 7, which I wanted to promptly remove.  I have an old MSDN copy of Windows XP x64 that I wanted to install, however the optical drive is broken, and I needed to install from USB.  Thankfully even though this machine is old, it can boot from USB devices.  The first step was to download WinSetupFromUSB 1.2 to get XP onto a USB stick.  Naturally once I had booted from USB, the disk controller wasn’t supported.  The BIOS screen revealed that it was a:

Serial ATA AHCI BIOS, Version iSrc 1.02.25 07222007. Copyright (c) 2003-2006 Intel Corporation. Copyright (c) 2003-2006 Dell, Inc. Controller …

This translated into the Intel iaStor product, and I was able to slipstream in the last version from 2009, 8.9.0.123 into the USB by using nlite.

I have to say that once I had removed the gratuitous pirated Chinese Windows 7, and installed XP that this machine was pretty damned snappy!  As always I updated to service pack 2.

The onboard NIC is a Broadcom NetXtreme 57xx gigabit NIC, which unlike the ‘gigabit’ NIC on my newer desktop, this one actually works at 1Gb.

With Windows XP installed, I went to the AMD/ATI site, and found the download for the HD 4xxx series, and went ahead and installed Steam.

I have to say that Half-Life 2 runs GREAT.  According to it’s onboard FPS counter I was getting anywhere around 60-180 FPS.  Pretty awesome.  Fallout 3 runs pretty snappy too.  I tried Deus Ex: Human Revolution, and much to my surprise this vintage 2011 game runs on my 2006 Windows XP x64 setup.

What about the overall internet experience?  Well this being Windows XP, You are pretty limited by the traditional browsers.  Internet Explorer 6 is the default browser which to say it’s dated is an understatement.  I prefer Internet Explorer 7 over 6, but they are both so old it doesn’t matter. Internet Explorer 8 is also an option. The last version of Google Chrome to support Windows XP was 49.0.2623.75.  Chrome 49 plays youtube just fine, Scripted Amiga is a little pokey, but does run.

And how does this thing compare to my normal desktop?  Running Geekbench 2, I get a score of 3396 vs 10864.  Now keep in mind this $99 machine only has a dual core processor, while my newer machine has a quad core + hyper threading CPU.  An interesting comparison is with the Xeon E5320 CPU, with the Dell eking out a victory.

Installing additional software was possible via Virtual Clone Drive, while I did have ISO images of stuff I’ve had physical media of in the past, a broken drive wasn’t going to help me read anything.

I didn’t activate it, but Windows 10 will run on this machine as well.  I’ll probably upgrade by getting a second JD210 heat sink (I already found another 5160 processor for $10)

It’s a great machine for sub $100.  I’d hate to have spent over $5,000 on this thing, but it’s kind of cool to see that a 10 year old machine like this can still be sort of usable.  Of course updating the software will certainly go a long way in making it really usable.

OpenWatcom v2

I know what you are thinking, wouldn’t it be great if you could create MS-DOS executables directly from a Win64 desktop with no MS-DOS needed?

Well, I just found out about this unofficial Open Watcom v2 project that targets the usual suspects, allows you to compile from Win64!

Hello World!

Hello World!

Some of the features of this fork include:

  • New 2-phase build system, OW can be build by platform native C/C++ compiler or by itself
  • Code generator properly initialize pointers by DLL symbol addresses
  • DOS version of tools now support long file names (LFN) if appropriate LFN driver is loaded by DOS
  • OW is ported to 64-bit hosts (WIN64, Linux X64)
  • Librarian support X64 CPU object modules and libraries
  • RDOS 32-bit C run-time compact memory model libraries are fixed
  • Resource compiler and Resource editors support WIN64 executables
  • OW text editor is now self containing, it can be used as standalone tool without any requirements for any additional files or configuration
  • Broken C++ compiler pre-compiled header template support is fixed
  • Many C++ compiler crashes are fixed
  • Debugger has no length limit for any used environment variable

Binaries are available on sourceforge.

So how does it fare?  I thought I’d take the old Wolf4GW, and compile it with this toolset.  The first hurdle I hit was this fun feature:

  • The C++ compiler now treats warning W737, implicit conversion of pointers to integral types of same size, as an error.

Which is an integral part of wl_menu.cpp .  So this was somewhat problematic, until I just commented out that block, and while I was expecting no working keyboard, I’m able to play, and load/save games…. Even the boss key works.

Wolf4GW

Wolf4GW

So with the W737 taken care of, I have to say this thing compiles FAST.  Incredibly FAST.  If for some reason you have to build 16bit or 32bit anything, you should look at a 64bit tool chain, well assuming you have a 64bit computer by now.

If anyone want’s to build their own Wolf4GW with the newer OpenWatcom, my source drop is here.

Now this reminds me of “turning the engine off and then back on again at 55 mph.”

the v86-64 patch, Allows you to enter v86 mode from long mode on a 64bit linux kernel.

Basically it works just like an old school DOS Extender, where it’ll switch from long mode, to 32bit compatible mode, then enter v86 mode run some code, then re-enter 32bit mode, to jump back into 64bit long mode.

From an old mailing list:

PERFORMANCE
This 64-bit DOSEMU compile runs substantially slower than the 32-bit compile
that I used previously on this computer.  I have several rather large
PowerBASIC/DOS programs that are, in fact, the main reason why I use DOSEMU.

Up until a couple of days ago, I had Fedora 7/i386 on this computer.  I just
happen to still have the numbers when compiling one of those programs with
PowerBASIC/DOS under DOSEMU:

With F7/i386:  1686600 lines per minute -- total time to compile the program:
0.2 seconds

With F8/x86_64:  230400 lines per minute -- total time to compile the program:
1.6 seconds.

The F8/x86_64 DOSEMU is running approximately 13 times slower.

Which I bet runs a bit faster than an old 386.

Qemu 1.7.0 released!

The main qemu page hasn’t been updated yet, but the download page has the source to the new version of Qemu.

I’ve gone ahead and built binaries for OS X, both a full version, and  a i386 minimal version.

As always testing is very minimal, all I’ve done is installed MS-DOS 6.22 & Doom 1.1, and tested the SoundBlaster 16 emulation.  And as with the pre-release versions, the adlib code is still broken.  And Ive done the ‘better’ fix in this code regarding that.

I haven’t run anything else, including fun things like the PowerPC & OS X emulation, MIPS with Windows NT, or even trying anything x64 based as I’m sure it is still broken from back in the Qemu 0.90 days.

Solaris 11 came out today

They blew the 11/11/11 launch date.  I guess Oracle really just doesn’t care about magical numbers or whatever.

I guess for the two or three people who even run this stuff (no doubt to run Oralce and it’s draconian licensing) you can find out all about it here.

It appears they still keep the Fortran stuff around for it…  Oh and this release is x86_64 only.  Sorry 32bit users.

Installing gcc (and I imagine everything else) revolves around the pkg command… In this case ‘pkg install gcc-3’ will download and install gcc 3.  While ‘pkg install gcc-45’ will install GCC 4!.  Don’t forget to install system/header or you won’t have things like stdio.h!!

Another GCC tidbit, is that you can build 64bit binaries with GCC 4.5 by supplying the -m64 flag!

While Solaris 11 installs somewhat quickly in VirtualBox (but wow does it take forever to boot), it is bare minimum…

Also for those who want it, here is lynx & ircII for Solaris Oh and a Quake World Server.  At least wget is in the base, but I don’t see why lynx isn’t.

A quick Neko x64 update!

Oh no!

Oh no!

For anyone who’s been using neko x64 on Windows Vista or Windows 7 and seeing something like the above, it turns out the fix was really easy and really simple. As mentioned by mikesword221, all you have to do is make it ‘always on top’.

Just right click on the cat in the task bar (he may be hiding, check under the up arrow…)

And make your settings something like this:

Configure Neko

Configure Neko

Then hit ok and Neko will now look normal, with no more ghosting.

Later on I’ll have to make an installer, and fix it so that neko is always on top.

Glorious Neko returned!

Glorious Neko returned!

 

Neko x64!

For no real reason today I remmeber that there used to be this cool program back in the Windows 3.0 days called Neko. I was trying to explain it to my girlfriend about this cat that would chase your mouse!  Click the picture above to play with neko in jdosbox.

I recall that Neko even made it to OS/2 as it was more interesting than the mouse trails alternative from Microsoft.

At any rate, I was wondering if there ever was a 32bit version of Neko… And much to my amazement I found there was a Neko95, and a Neko98! And they even ran on my x64 version of Windows… So after googling around, I found the source code to Neko 98!

So, I did the next best thing, which is download the source, fix a single casting ‘error’ in some square root function and I got it building under Visual C++ 2008. Then I figured, what the hell, added a target for the x64, and built… a 64 bit version of neko!

You can download the x64 binaries, and the source directory that I used here.

You may need some VC runtimes if your system is an old x64… At this moment it can be found here:

Or by searching for Microsoft Visual C++ 2008 SP1 Redistributable Package (x64)

Oh well at any rate, it’s cool to see Neko still kicking!

PS When I get back, I’ll have to see about an i386, MIPS, Dec Alpha and Itanium build… wink wink!

—edit

Neko98’s source code has been rescued, all saved here. and on github.

—years later

I just received this screen shot of Neko x64 rocking it on Windows 8 (Desktop mode)

Neko on Windows 8

Qemu 0.10.5 for windows

Well I screwed up the Proxmox VE thing and I needed to test some x64 stuff… Sadly the VM I used to build the x64 stuff was the proxmox… And I need it now!

So I found this site, which has the new qemu stuff built!

Just unzip it with 7zip.

And you should be good to go..

However for Windows 2003 x64 R2 it seems that those binaries crash on ‘starting windows’, apparently they were compiled with GCC 4 while the ancient qemu 0.90 built with GCC 3 works…

I’ve also found a source ‘fix’ for why 0.91 crashes on vista…:

patch hw/ide.c:

just replace all ‘free(buf)’ in guess_disk_lchs function to ‘qemu_free(buf)’.

Sounds easy enough. I’ll have to get a working toolchian.