Github Actions

[Torinde]

Would be good to have automatic builds / Github actions - like crazii/SBEMU#21.

A combined package with SBEMU would also be useful, but I don't know if you can do that across repositories (e.g. USBDDOS action to get the latest artifact from SBEMU-main and SBEMU action to get latest artifact from USBDDOS-master)

@volkertb, can you help with some of that?

[volkertb]

I can look into that. But the README mentions "cross toolchain on linux not tested". There are ways to build in DOS in GitHub Actions Worklows. I created a container image that was meant for such workflows. But it would complicate the pipelines, and likely make them slower too.

Being able to cross-compile and build the binaries from Linux (in addition to being able to build them from within DOS) would be beneficial.

[crazii]

I'll add a makefile for Linux, and test it on MinGW.
BTW, I remember there was a free-to-use BCC cmdline toolchain (without IDE) release by Borland, it could be used to build the BC edition. I'll try to add another makefile for that too.

UPDATE: the BC toolchain is win32 only, not working on DOS. besides I cannot find a valid download link, maybe it could be found on webarchive but that site is again off limits for me.
EDIT: found one on here: https://osdn.net/projects/sfnet_udev/downloads/OldFiles/freecommandLinetools.exe/

[volkertb]

I know you are the primary developer and putting the vast majority of the work in, but I would like to implore you to try not to be dependent on toolchains that include any closed source components, especially if they are abandonware. In my opinion, software isn't truly "Free" if it depends on any non-Free components for it to be built. Some may consider that a form of purism, but to be considered for inclusion in open source distributions such as FreeDOS, this is important as well.

Also, from a purely practical sense, it's better when the build tools that we depend on are also still being maintained and improved.

Personally, I would consider the ability to also be buildable on those older closed source compilers and toolchains (in addition to the primarily supported open source ones) to be a nice bonus at best.

And also for the purpose of CI/CD, open source toolchains are a much better choice, especially when this allows the DOS binaries to be cross-compiled from a Linux environment.

[crazii]

Either you got me wrong or I'm not sure what's the point. I totally agree with you on free softwares.

As said in the readme, the project initially was planned to build through DJGPP, OpenWatcom, Borland C.
There're 2 reason that the Openwatcom is abandoned: 1) DOS4G/W or DOS32A has limit DPMI support, which still needs a HDPMI host to get full DPMI support. 2) 32 bit mode doesn't have 16 bit inline assembly.

There're also 2 reason that BC was included, which is not mentioned in the readme:
1.The original project was built using Turbo C, but that's not really important
2.The most important thing (for me) is that it's just FUN. I might be emotional involved easily when talking about Borland C, because I was a big fan of Borland. I still remember the happy coding times with TC++/BC++ that Borland brought me like DOS games. Retrogaming is fun, but it's also true for retrocoding.

There's no need to be 'a bonus at best' because it just DOESN'T HURT, because there's a DJGPP built that's being worked on at the same time.
Using Borland C is also practical for debugging; DJGPP is too slow on an old P3 PC and is too slow on modern PC when boot and compile on USB-disk, but BC is way faster than that (tens of times faster or more), and saves a huge amount time for me. compile on modern PC and pull & plug on the testing PC is also wasting too much time.

There's also a possibility that OpenWatcom is brought back, but in real mode, which drops DPMI support and uses the same approach as in BC. But I'm focused on the EHCI now and too busy to test & try that. it will be planned. But even with Openwatcom working, I'm not dropping BC personally.

[Torinde]

FYI, but probably you're aware already:

OpenWatcom is in active development - maybe you can make an Issue/PR there about the missing functionality?

There are also JWasm, Jwlink, HX-OpenWatcom-Debugger and forks thereof (e.g. jwasm.info)

[crazii]

Created.
open-watcom/open-watcom-v2#1178

[volkertb]

@crazii It looks like I indeed misinterpreted your earlier post. Thanks for your clarification. I understand your fondness of Borland C, and the practical benefits it brings to have it supported as well.

I was just reminded of other open source projects that do exclusively depend on closed source toolchains (notably SoftMPU), which made me worry about it here as well, but that's not justified.

[volkertb]

@crazii @Torinde PR created. Please have a look: #6

NOTE: with the most recent (Watcom-related?) changes, DJGPP builds started failing again. I tried fixing them, I could not immediately figure it out, and I wanted to have the PR out first, since it was working locally right up until the last few upstream commits were pushed.

[volkertb]

@crazii I just realized, if you are indeed going to try supporting (Open) Watcom in addition to DJGPP and Borland C, I could add a workflow to automatically test builds with Open Watcom as well as DJGPP. That way it is immediately noticed when any pushed changes breaks compatibility with either of those two compilers. What do you think?

[crazii]

I'm currently working on the OpenWatcom build, there's progress, but freezes on some real mode call, I didn't take care of the DJGPP compiling yet, there might be failure, I can fix them now, and I will finally check it when the OpenWatcom is ready.
BTW the DJGPP makefile can work under Linux and DOS, and the OpenWatcom will be the same.

[crazii]

I just pushed the fix for DJGPP. I'll check the PR later, maybe when the Openwatcom is done.

[volkertb]

Thanks! After rebasing on these fixes and fixing a few more things in the workflow, everything appears to be working now in my PR.

The workflow now successfully builds the EXE with DJGPP and publishes it as a release. 👍

Two remaining minor items before this PR can be merged (other than it having to be reviewed):

• I still need to uncomment a line in the workflow so that the publish job will only run on commits and merges to the default (master/main) branch. I had it commented out to test that job while I was working on it.
• Instead of TODO, we might want to place some other text or template in the release notes. Just let me know what to put there.

Thanks again!

[crazii]

Cool. TODO is not a release notes but a dev memo, are you talking about CHANGLOG? it simply record change histories.
Share you idea on release notes. And there's still some to be done, i.e. the exe should show a version string and a probably copy right string.

[crazii]

BTW you can test the binary with your Mac Mini, the EHCI driver might works, I've tested it on two laptops and it works fine.
If it doesn't you make build a debug edition (make DEBUG=1) to check the logs on the screen.