[VS6] add Dockerfile and docker-compose to build the code

[PiecePaperCode]

Added two dockerfiles

Dockerfile & docker-compose.yml

With this two files you can locally build your copy of the source code. The binarys are dropped down on your build directory ./build/docker

No dependency needed to be installed on the development machine only docker

[tintinhamans]

I don't know how I feel about having a dependency on master branch of a repo outside of our control.

[PiecePaperCode]

can we inhouse vs6 in TheSuperHackers as a repo. Otherwise you need to hund it from an outside repo.
itsmattkc is a youtuber i follow an wich i trust to not have tempered with the distribution of vs6. Maby a trusted member can source the vs6 files and provide them in a repo.

[xezon]

No idea about the nature of VS6 redistributability. @OmniBlade @Generalcamo thoughts?

Locally I am using the VS6 SP6 package that OmniBlade has put together.

[tintinhamans]

No idea about the nature of VS6 redistributability. @OmniBlade @Generalcamo thoughts?

Locally I am using the VS6 SP6 package that OmniBlade has put together.

Perhaps we can think about making this a mandatory mount that the user provides, that way it is not redistributed inside of the image.

[Generalcamo]

Agreed with @tintinhamans, I am uncomfortable with distributing this.

[PiecePaperCode]

I have optimized the image.
The current size is now 2.8G. From 5G
The biggest culprit for the size is wine.
I generate the wineprefix on the fly.
This ads another 2G to the runtime instead inside the image

[tintinhamans]

Actually, why not expand on this entire idea and implement devcontainers?

They are supported in many IDEs: VS, VSCode and more.

[PiecePaperCode]

Actually, why not expand on this entire idea and implement devcontainers?

They are supported in many IDEs: VS, VSCode and more.

Yeah dev containers are a interesting approach but for this PR its out of scope.
Devcontainers should be in its own PR or/and a new issue.

[edbird]

My question would be why do you want to do this. Expressed another way, what is the advantage, or even purpose of, creating a temporary self-contained environment to build an executable, to then not run that executable in the same environment.

I am somewhat a Docker advocate myself, but in this context, it doesn't seem to make much sense. Typically, if you want to build an application inside a Docker container, this is becuase you want to run the application inside the same environment.

A Docker container is simply a way of reproducing the same environment across multiple physical or virtual machines. In other words, it abstracts away the complexities (configuration) of an environment, because a container image gives you not just an application to run, but also a preconfigured environment in which to run it.

Sorry for labouring the point somewhat, I'm sure many reading this will already know these things.

Let me know your thoughts.

[PiecePaperCode]

My question would be why do you want to do this. Expressed another way, what is the advantage, or even purpose of, creating a temporary self-contained environment to build an executable, to then not run that executable in the same environment.

I am somewhat a Docker advocate myself, but in this context, it doesn't seem to make much sense. Typically, if you want to build an application inside a Docker container, this is becuase you want to run the application inside the same environment.

A Docker container is simply a way of reproducing the same environment across multiple physical or virtual machines. In other words, it abstracts away the complexities (configuration) of an environment, because a container image gives you not just an application to run, but also a preconfigured environment in which to run it.

Sorry for labouring the point somewhat, I'm sure many reading this will already know these things.

Let me know your thoughts.

Its a valid point. This file is for people who just want to get started building the code without installing VC6 or VC2019 and hunting all the deps needed or setting the correct build environments vars. Its kinda a executable manual. Dev containers are an alternative but in my case out of scope for this PR. If somebody want to convert it to a dev container and use this PR as a reference i would be pleased.

Otherwise i have gone further and set up a Gpu docker environment that would run the game and you cold connect via web browser to see the game rendered wich would make it more a complete example.

[mirogajdos]

Typically, if you want to build an application inside a Docker container, this is becuase you want to run the application inside the same environment.

This is false. You typically want to standardize build env and run final app wherever you need to as your customer would have. If we don't include deployment of web services majority of use cases for docker in development is to streamline dev env setup. It's much easier to say to newcomer to install docker and run some docker compose instead of N long getting started list which can result in many inconsistencies based on your machine state.

[OmniBlade]

While I'm all for using containers to create standardised build environments, I'm not sold on the containers run command being to run the build as that gives little scope to customise the build that is run. I'd rather it gave me a prompt to run the configure myself and perhaps included wrapper scripts that encapsulated the wine commands or included a toolchain file with the appropriate wine wrapped commands.

[OmniBlade]

This won't work as it is here, you need to run the cleanup as part of the other RUN commands that perform apt operations. The results of previous run operations become baked into the image as read only layers.

[OmniBlade]

Again this needs to be part of the previous runs (one for each that downloads a zip) if the idea is to save space in the image as the result of the previous run become read only.