Meet the people behind the BBS scene and people who made FidoNet what it once was, a long time before “the Internet” :)
(Playlist with eight parts)
(Full length movie)
keybase.io
You can find me at keybase.io/joho68
We’ve set-up a keybase.io team too, just drop us a note via keybase that you want to join (“frontdoor.wall”).
FrontDoor and Windows XP
We might as well start at the back :) Here’s a rough HOW-TO for running FrontDoor with Windows XP; https://wiki.defsol.com/howto/windowsxp
wiki.defsol.com
At some point I suppose it had to be done, so I’ve now put things in motion to create the Wiki. I’m sure it’ll have to be re-arranged a million times, but it’s a start. The porting and writing of codes has priority, so don’t expect any wiki miracles anytime soon :)
The FidoNet Nodelist History of Me :)
nodehist.fidonet.org.ua/?name=Joaquim+Homrighausen
(Nice service by the way)
To DrawWindow() or JustWriteToStdOut() ..
I knew one of the first mental showdowns when porting FrontDoor would always be the windows part. The visual windows that is, those silly “beautifully” framed squares displayed on the screen while just about any part of FrontDoor is running.
And now, I’m at a crossroads. There are a few ways of doing this, of course. There always are. The problem is that I’m not so keen on spending my time on something that nobody really wants or needs, when I would be much better off spending my time implementing new (to FrontDoor) protocols, methods, concepts.
I have ideas on how to do this much better than it’s currently implemented. It has to do with pipes and streams and similar concepts. But again … where is time best spent?
Finding other bugs, that I cannot fix
It’s bound to happen. When looking for your own crap, you find someone else’s crap :)
Serial device I/O is probably not at the top of the list for any product these days. But when you’ve reached a version level of 5.x, you’d expect the product to be at least “mature”. Enter VirtualBox which seems to have problems when transporting data between the Host and the Guest. I’m not sure this is entirely related to “Serial I/O” or “UART” as VirtualBox likes to call it. But since that’s where I ran into it, that’s what I’ll label it as until they tell me different :)
There are, obviously, ways to get serial I/O working in VirtualBox. But this particular scenario, where I wanted to run NetSerial on the Windows 10 Pro (64-bit) host, and access the virtual COM ports in a Guest OS, does not seem to be the optimal way of doing things in VirtualBox. (Moving NetSerial into the Windows XP Guest solves the issue, but that sort of defeats the purpose, since I want to be able to use the emulated COM ports from any Guest OS, and not just Windows-based OSs).
The VirtualBox bug filing is here:
www.virtualbox.org/ticket/17093
FidoNet 2:20/4609
It took me by surprise, but I actually forgot some of the FM (Editor) keyboard shortcuts! #LOL
Messing around with FastEcho, AreaFix, ARCmail, nodelist compiling, TCP/IP port overrides, and setting up some sensible routing.
It seems like many years later, I’m finally re-connected to and with FidoNet. Who knows, I might just be posting in FDECHO soon, or possibly start a flame war in NET_DEV. I’m sure some things have changed, while others haven’t.
Well, 2:20/4609 is semi-alive. It’ll be a while until I have it online 24/7. But considering I do some of the compiler builds around 03:15 in the morning, I guess you can almost say I’m 24/7 :)
Why the “4609”? Well, there are historical reasons!
Gah! It’s the dreaded “Direct Console Output” problem #WTF :)
The last few days have seen progress. Some very widely used libraries have been ported (that is not to say they will actually work of course, but it’s a damn good start).
When “going back” to a unified library (RTL) as the one found in FreePascal, it’s actually sometimes more work than continuing using your own code. So I’m trying to keep this somewhat balanced. One “issue” with FreePascal is actually the number of platforms it supports. Because of this, it needs to do some thing in a fairly generic manner. That isn’t to say it’s slow or bad, but I often want to be one layer closer to the operating system (specially if it gives the application some sort of edge vs the generic stuff).
And there is a *lot* of code to port …
Not to mention the dreaded “Direct to screen writes” that used to be a requirement for DOS programs, unless you wanted the user to enter retirement before the BIOS screen updates had finished. No, that was not a joke, the PC BIOS screen handling code sucked, in a word. Fortunately, there were alternatives, and since FrontDoor has already been ported once to OS/2 (i.e. “not DOS”), some consideration has already been taken for the portability issues. But it’s not all that exciting to sit down and re-invent the weel … I’d much rather spend my time implementing things FrontDoor isn’t doing at the moment.
Oh well. Another few thousand lines of codes done. G’night!
Virtual COM Port for 64-bit QEMU Hosts and Guests
So QEMU looks like it’s the answer to many things when it comes to virtualization, regardless of your needs for a Guest OS. This post is not about whether or not QEMU is the greatest thing since sliced bread though, which may disappoint you if you’re a QEMU fan. I’ve spent the better part of three days reading up on virtual devices in QEMU Guests, more speficially serial (or “COM”) ports.
And I need, of course, “something”, that will expose a serial port to the Guest, and on the Host side, it needs to connect to “other systems”. The connecting to other systems part is fairly simple. When told to, it needs to “call” a remote system using TCP/IP and establish a connection. Once connected, it needs to act as a bridge between the remote system and the virtual serial port that the Guest is using.
You would think that using your favorite search engine and looking for “Virtual Serial Port” or “Virtual Ports in QEMU” would yield a barrage of hits, with detailed instructions on how someone has already done this. That’s what I was thinking anyway. Three days later, it turns out that this is not the case. There are many projects that, by name and first impressions, look very promising. But they all come up short in one way or another. And I do need this to be simple, because the problem is not complex in itself. The best candidate so far is something called “tcpser” (originally written Jim Brain). It also emulates a modem (to some extent) so that the application in the QEMU Guest can issue an “ATDT thedestination.com” to establish a data connection. I also ran across a few forks and improved versions.
There is only one problem with tcpser, or rather, with the equipment I often develop on: Most modern laptops have no physical serial ports. tcpser wants to talk to /dev/ttyS0 or COM1 (or any other physical serial port) because it needs to read line status like DCD/CD/DTR/DSR and so on.
If you can find a Virtual COM Port emulator for 64-bit Linux or 64-bit Windows that actually behaves like a serial port, then you’re better at “internet searching” than me :) But for the time being, I’m trying to see if I somehow can fake the appearance of a port to tcpser and then take it from there. This is not was I was supposed to be working at in regards to the Reboot project, but then again, sometimes you dig way too deep for your own good :)
If you want the “requirements list” for what I need, here you go:
- Must be able to establis a raw Telnet session with system over Internet
- Must not be suffering from problems with “special characters”
- Must not require the remote system to be hardwired
- Must not require the remote port to be hardwired
- Must support ATDT as the signal to create the connection
- Must somehow honor DTR to disconnect
- Must work with QEMU
- Must work with 64-bit Linux, as a minimum requirement (Host)