Work in progress now compiles, and DOSbox-X

Well, the re-boot in progress seems to be moving in the right direction. FM, FD, FDSETUP, and FDNC now compile properly as they should.

Furthermore, they can talk to other FroDo:s, which is good. So the “commercial version” (which will be ditched, it’ll all be the same) can run in unlicensed mode. That’s one of the goals with this re-boot.

I also discovered that DOSbox-X plays very nicely with FrontDoor, even in a virtual Windows 10 32-bit environment under VirtualBox.

 

Partial recovery, of sorts

For some reason, I decided to check one of my laptops that I was using at the time of the crash. It was my go-to environment for the “Free Pascal conversion” project.

It turns out that I had actually not lost everything I thought I had lost. So I have tinkered some with an alternative setup here to see if I can get things to compile and build again.

I need to get a version out that doesn’t require a license. As previously stated, there will only be “mL” releases from now on. The “license” will be “free for non-commercial use”.

So far, FM has been re-compiled at version 2024.1 and handles an “invalid license” (or missing license) as it should.

I’ll keep you posted.

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?