Seems not be compilable anymore

[h0ly0ne]

Try compiling it within the available docker framework - but only ends with an error in BUILD.LOG:

MAKE Version 5.2  Copyright (c) 1987, 2000 Borland
	bcc32 helper.c
Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x004a2734).

When trying everything within a 32bit VM and doing the compilation manual it seems to work - so somehow the docker image for the distribution and/or borland tools are crashing against each other.

[binary-manu]

@h0ly0ne Thanks for reporting. I'll have a look at the problem.

[binary-manu]

I was not able to reproduce the issue simply because I get an early showstopper: on my daily driver, trying to build the container results in a rpm process using 100% of one core and taking minutes to install each package inside the container.

I tried switching to Leap 15.4 since 15.2 is well beyond EOL. With this image, I can build a PART.EXE which seems to work inside a QEMU instance running FreeDOS.

@h0ly0ne Can you try the branch patch/buildsys-update on your system?

[h0ly0ne]

Tried branch patch/buildsys-update - seems to be the same result as with master branch.
Just to clarify my host system a bit more indepth, as your daily driver had also some issues - i am using windows 10 (x64) with docker-desktop (and WSL2). Seems to work pretty fine with the XOSL docker container - but as the RPM container uses a different distribution and wine in addition it is quite useluss to compare these two.

See my full dump message attached - maybe you are able to read something more useful as I am able to.

BUILD.LOG

[binary-manu]

After setting up Docker Desktop with WSL2 backend on a Windows 11 system, I can reproduce the error. This does not happen on my Arch Linux system.

I'll have a look at it.

[binary-manu]

Here's what I have found so far.

bcc32.exe (and only that executable) crashes when run under any WSL2 machine, either directly from the guest or indirectly from inside a container. The base image used for the container or the WSL2 distro are irrelevant. Conversely, it works fine when run under Windows or inside a VirtualBox VM.

So now we have 3 ways to build the project under Windows, but just one works:

1. run the helper container under Windows using Docker Desktop or Podman Desktop. This effectively means building inside a WSL2 Linux VM where Wine and DOSBox run. This doesn't work as bcc32.exe crashes.
2. run Borland make directly from Windows and have it compile the stuff. This doesn't work either because part of the toolchain is made of DOS tools which cannot run under 64-bit Windows 10/11.
3. install VirtualBox/Hyper-V/VMWare, run a full Linux VM and build there. This works.

I tried a variant of 2: run make under Windows but using DOSBox to execute DOS stuff, just like Wine does. For this, I have created some extra scripts under tools/winwrap. Their usage is simple; open a PowerShell and type:

cd C:\path\to\repo
cd tools\winwrap
Set-ExecutionPolicy -Scope Process Bypass
powershell build.ps1

This PowerShell script maps the src and tools directories as S: and T:, modifies the PATH so that the toolchain can be found and runs make. The magic happens when a DOS tool like tasm.exe is run: a wrapper .bat script is found first because the winwrap folder precedes the BC5/BIN folder in the PATH. This file extracts its basename and calls a common PowerShell wrapper which runs DOSBox with an appropriate configuration file, containing commands to run the DOS tool in the emulated environment. It also appends logs to src/BUILD.LOG as usual.

For this to work, there are some prerequisites:

• S: and T: must be available;
• DOSBox must be installed and in your path.

The extra batch files are needed because it seems that directly using .ps1 files does not work. The wrappers must be old .bat files or make won't run them. Also, at the moment every time DOSBox is run its window goes on the foreground which can be annoying. It think it is possible to suppress that with a couple of env vars. I'll try that later.

I rarely use Windows these days, and PowerShell even less, so much of this is copypasta from StackOverflow. Improvements are welcome.

@h0ly0ne can you give it a spin on your Windows 10? It's available at patch/buildsys-update.

[binary-manu]

With the last commit DOSBox has been silenced: it will no longer open a new window every time it is invoked. The full build should be quiet, with no windows showing.

[h0ly0ne]

I've given it a shot and tried my own implementation of a build-environment without docker-container (as it really feels a lot cleaner without the additional component requirements) - just dosbox-x (interchangeable with dosbox on this use case), pkzip+pklite+unxutils (for preparations and packaging) are automatically fetched and used for the whole compilation (using minimum required borland files from BC5.0) - just the logging is currently completely missing.

@binary-manu if you are interested in taking a look i've currently commited my changes on my fork on master h0ly0ne/rpm

[binary-manu]

@h0ly0ne I tried you branch and liked your approach. Doing everything from inside DOSBox-X spawns less processes than the Windows/DOS entry/exit of my code (which mirrors what Wine does). I just needed to install a more recent version of PowerShell on Windows 11 because the default version lacked some features. Perhaps you may want to add a note in the docs.

I see you dropped *nix build support from your Windows branch. Are you going to focus on Windows exclusively once this branch is merged into master? In this case, I'd avoid merging my trivial Windows workaround and focus on *NIX only (which is the goal of the repo) and add a link to your fork for people interested in building under Windows.

[h0ly0ne]

@binary-manu at the moment I'm trying to get the building process as smooth as possible (for both RPM and XOSL) - therefore I was forced to use PowerShell 7 to get as bug free as possible. I'll add this in the README panel as soon as I am finished with the polishing.

Overall I am not really able to do the "hard" stuff on *NIX systems (including fine-tuning for docker) - so I'll be able to keep/merge your modifications but will just keep these things as they are. Additionally as I am not that hardcore git-person I've just thought creating a branch with just my windows-focused changes would be a good idea. If you have a preferred way to do that, just tell me what to do and I'll drop my fork/branch and integrate everything in your structure.

[h0ly0ne]

Just one thing regarding the issue compiling within docker in a WSL2 machine and the crashing bcc32.exe - I'll give it a try with your most recent release and replacing DOSBox with DOSBox-X and replacing the bcc32.exe with the 5.0 version - maybe I'll get some luck on that to get the *NIX variant somehow working again (without doing the workaround with windows)