Further investigation shows us that fbcmd is failing to start with $C0000135 (“the program can’t start because %hs is missing from your computer. Try reinstalling the program to fix this problem.”) - not very helpful from windows at all (no more details, nothing in the event log).
I set up a server core vm to test with, and made some progress, in that it shows a messagebox with the name of the missing dll - copying opengl32.dll, glu32.dll and oledlg.dll from c:\windows\SysWOW64\ on my up to date W10 machine allows fbcmd to run.
Unfortunately, that doesn’t seem to work in the docker container, using this dockerfile
# escape=`
# Use the latest Windows Server Core image with .NET Framework 4.8.
FROM mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-ltsc2019
# Restore the default Windows shell for correct batch processing.
SHELL ["cmd", "/S", "/C"]
# Default to PowerShell if no other command specified.
CMD ["powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]
ENV chocolateyUseWindowsCompression false
RUN powershell -Command iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1')); choco feature disable --name showDownloadProgress
RUN choco install -y finalbuilder
COPY FB800-0001-000001.license c:\programdata\vsoft\finalbuilder8
ARG target="C:/Program Files (x86)/FinalBuilder 8/"
ARG src=fbcmd.exe
ARG src2=test1.exe
COPY ${src} ${target}
COPY ${src2} ${target}
COPY opengl32.dll ${target}
COPY glu32.dll ${target}
COPY oledlg.dll ${target}
Now these missing dll’s are statically linked from either the delphi runtime packages or from third party libraries, even though they are probably not used in fbcmd.
We’re continuing to look into this, as we’d really like to see fb running in docker.