Category Archives: Uncategory

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!

Progress measured in … lines of code :)

Progress is being made. The current tool of choice is Free Pascal. It is by no means a bad product. In fact, it’s a pretty damn great product. But just about every line of code needs to be tweaked, slightly modified, etc. Or so it seemed when porting the Event handling yesterday, which “only” took three hours. Part of this is obviously due to poor design on my part, but I can’t take credit for everything :)

Mike and I have been discussing issues with running the DOS version under Windows 10 Pro (64-bit), hosted by VirtualBox in a FreeDOS 1.2 virtual machine. There seems to be some sort of flow control issue disturbing the transfer of data. I’m hoping Mike finds (and solves) this problem. But, it may come to the fact that the problem is in VirtualBox after all.

While “waiting” for Mike, I’ve been porting some more code, and also began setting up FreeDOS under QEMU instead. It looks promising and feels somewhat surreal to be able to just move around virtual machines, converting them from VirtualBox under Windows 10 to QEMU under Ubuntu Linux 16 on a completely different physical machine, and it “just works”. I came across a fairly good page while configuring networking for QEMU and FreeDOS here: pclosmag.com/html/issues/201208/page11.html

I will jot down a full description of how I got it working, if I get it working. The next step is to get a “modem emulator over Internet” (i.e. a “virtual modem”) working in this context.

There’s something going on …

So I guess I took another three years to think about this, judging from the previous post(s) :-) But this time, I have actually managed to make some “progress”. That is, if you consider reviving a 30 year old DOS program progress.

I have been able to get FreeDOS up and running under VirtualBox. I have been able to locate my old copies of Borland Pascal, TASM, MASM, VirtualPascal, and Watcom. I was also very glad to see that there’s something called Open Watcom these days. That may prove to be very useful for this mission. The OS/2 stuff will have to wait for just a bit, I need to compile all the DOS stuff and see that the code actually still works.

The first version of FrontDoor was released in 1986 (and I managed to locate the original announcement). If I’m not mistaken, the first version of FrontDoor with mailer capabilities was out in 1987. That’s 30 years ago!