The Makefile was incorrectly tying together _ICON and icon.rc, making it
impossible to use one without the other. To fix this we introduce a new
DEP_ICON_RC flag, which indicates we need to use the icon.rc file (in
addition to regular icon support). DEP_ICON now only indicates we need
to support _ICON, and does not attempt to build the resource
information.
The purpose of moving the EXEs is so that they are not captured in the
build artifacts. They would be nice to have, but they end up being a few
hundred MBs in size so much too large to bother saving.
Currently there is a bug where if a variable width font is in use and
text printed would exactly fit to the end of the row, it is instead
wrapped and printed on the next line.
Ex. You're printing a character that is 10 pixels wide, starting
from position 90 on an image that is 100 pixels wide. This should fix,
but instead your character will be printed on the next line.
The reason this happens is an off by one error, cursor_x (effectively
the X value passed to LOCATE) is one based even when using a variable
width font where cursor_x represents a pixel location. The location that
check if the next character can fit on the screen never handles the base
one, so it ends up treating the ending Y coordinate as one past where it
will actually end, which makes the code thing the print will go past the
edge of the screen.
To fix we simply subtract one before doing the comparison to give us the
actual ending pixel column.
The resource file we create contains two separate values for FileVersion
and ProductVersion. Currently, they are actually represented by two
separate values in $VERSIONINFO and effectively require duplicating the
information between them.
My understanding is that the string values should always be the same as
the numerical versions, so to make $VERSIONINFO easier to use this
changes the logic so that setting the numerical version will
automatically also set the string version if values for them are not
provided.
windres has a handy feature of allowing us to feed it an executable and
it will give an error code depending on whether that executable has a
resource section or not. We can use that feature to create a quick test
to verify the distributable has the resource information on it.
Previously, the creation of the icon.rc file was restricted to be
Windows only because Windows is the only platform with a use for that
file. Unfortunately, this breaks a fundimental assumption about how the
QB64 C++ generation works, because we only have one set of
`./internal/source` files from which we build all versions of QB64 for
all platforms. Due to that, the built version needs to include all files
needed by all platforms, regardless of which one is doing the building.
So to that end, all platforms should produce the icon.rc, even if it
will not be used on that platform.
Additionally, the path to the icon file in `icon.rc` is problimatic
because it is made into an absolute path. This blocks `qb64.bas` from
using `$EXEICON` because the absolute path is not predictable, as
the location we create ./internal/source will be different from the
location we build ./internal/source. Effectively this means that the
`icon.rc` file in `./internal/source` would always be wrong.
The solution is to not use an absolute path, with the other option being
to have the icon in the same directory as the resource file. This is
actually relatively easy to acomplish since icon files are not terribly
large and we can simply copy it into the temp directory.
Thus, that is what this change does - the specified icon file is copied
into the temp directory as `icon.ico`, which allows use to use
`icon.ico` in the `icon.rc` file and have it always work regardless of
directory.
The internal logic was also cleaned up a bit. The creation of these
files is no longer Windows specific, and the $EXEICON parsing no longer
writes to the `icon.rc` file - rather, the entire thing is generated
together, with both the $VERSIONINFo and $EXEICON depending on which
were provided.
