VB6 in Docker

[hwoarang]

Lets automate VB6 builds in the right way!

Yes, I know that there is pretty good github repo, but that is for old and terribly huge Windows 10 (mcr.microsoft.com/windows:1903) image. Not quite stable and having issues in CI/CD pipelines (espessially when dealing with in-process isolation mode).

So, what benefits we will have:
- Modern and lightweight Windows Server Core 2025 as base image
- automated and full VB6 Enterprise + SP6 setup inside, producing almost same lightweight image (final size in registry - 3.8 GB)
- UPX is installed too to provide optional DLL/OCX compression


Download -file redacted- file and run .\Build.ps1. Ensure you have Docker Desktop installed (with support of Windows Containers) and your powershell can execute scripts.

When image is ready, you can now run container to test:

- docker run -it --rm --mount type=bind,source="HOST_MACHINE_PATH_TO_PROJECT",target="C:\Build" winservercore2025vb6:latest powershell

Then, inside container powershell:

- & "C:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE" --% /MAKE "C:\Build\Project.vbp" /outdir "C:\Build" /out "C:\Build\Log.txt"
- "C:\Program Files (x86)\UPX\upx.exe" "C:\Build\Project.dll" -q -6 --no-lzma --compress-resources=0 --strip-relocs=0 --compress-exports=0

[hwoarang]

If you want to use produced image in your CI/CD pipeline (f.e. Github or Gitea) - put it into your private image registry, ensure you have a runner at Windows Server 2025 machine in host mode. Start docker container within your action yaml as: docker run --rm --isolation=process ...

[dday9]

I've removed the link to the file because it contains binaries. Uploading/linking to docker projects is fine, but include the docker-compose.yml and allow the user to download the images themselves.

[hwoarang]

I've removed the link to the file because it contains binaries. Uploading/linking to docker projects is fine, but include the docker-compose.yml and allow the user to download the images themselves.

Great, you've made this post useless then. That were official VB6 enterprise binaries with specifically adjusted STF files - there are no images for VB6 in dockerhub, unless somebody builds it and post at dockehub (or other public OCR). As you probably read main post - the aim is to build an image.

[dday9]

We have a long-standing policy of not allowing binaries and instead allow users to build for themselves. After 11 years of using the forum, I would have expected you to know this but gave you the benefit of the doubt. Put bluntly, do not link to or upload binaries.

[hwoarang]

We have a long-standing policy of not allowing binaries and instead allow users to build for themselves. After 11 years of using the forum, I would have expected you to know this but gave you the benefit of the doubt. Put bluntly, do not link to or upload binaries.

How about including STF file only then? Then people will only need to put their VB6 Enterprise binaries in proper folders before building image attempt

[wqweto]

How do you license VB6 IDE/compiler in a docker image? I thought this is impossible so Azure uses custom "user" build servers with everything licensed incl. 3-rd party OCX preinstalled (and licensed).

This is one of the reasons some people expect TB final release -- to use community edition in CI/CD pipelines.

cheers,
</wqw>

[hwoarang]

How do you license VB6 IDE/compiler in a docker image? I thought this is impossible so Azure uses custom "user" build servers with everything licensed incl. 3-rd party OCX preinstalled (and licensed).

This is one of the reasons some people expect TB final release -- to use community edition in CI/CD pipelines.

cheers,
</wqw>

I do not licence anything. You have to use licence key and build image on your own and put it into private OCR targeting your private build server, OR use it locally.

Community edition (or whatever they can call it), holding VB binaries will be anyway a violation of MS licence. And I'm not sure of what you mean with "3-rd party OCX preinstalled" - it was supposed to have VB6 binaries as standalone and selfcontained setup.

[dday9]

How about including STF file only then? Then people will only need to put their VB6 Enterprise binaries in proper folders before building image attempt

Yeah, that should be fine. An STF file isn't a binary file as far as I'm aware. My understanding is that it is a setup configuration file.

[wqweto]

And I'm not sure of what you mean with "3-rd party OCX preinstalled" - it was supposed to have VB6 binaries as standalone and selfcontained setup.

That's the point. This is not how a large VB6 app is built. It usually has dependencies on numerous 3-rd party OCX/DLL binaries (3-rd party = non-Microsoft) which are licensed even more expensive that VB6 compiler itself.

cheers,
</wqw>

[hwoarang]

That's the point. This is not how a large VB6 app is built. It usually has dependencies on numerous 3-rd party OCX/DLL binaries (3-rd party = non-Microsoft) which are licensed even more expensive that VB6 compiler itself.

cheers,
</wqw>

So that anyway changes nothing for this thread. It is about an instrumentary to build. Up to you what dependencies to include in final image (if you need it on each build).