Icon for odin.exe

[Hyrtwol]

Wanted to explore how Odin was handling windows resources and luckily it was very easy :)
For testing I ended up adding 2 icons to Odin.exe (based on the emblem in artwork) and kinda liked it and thought it was worth sharing.
This can maybe also serve as a "self test" of the resource feature. btw really nice we don't have to call the rc tool and it just build-in. Both icon files only contain a 16x16 and 32x32 to keep them small 3.5 KB as they are embedded in the exe. I used the 2nd icon for .odin files.
It made the compiler stand out nicely :) But this is ofc only interesing on windows so I understand this might not be the time for things like this ;)

[Kelimion]

We may want to check that ODIN_ROOT is set to something before adding the registry entries, or people will have a broken context menu with no clue why it doesn't work.

[Hyrtwol]

I have added a check here for the ODIN_ROOT env. var and bail out

[Hyrtwol]

check for ODIN_ROOT with an explanation on how to set it using setx

[Hyrtwol]

if ODIN_ROOT is defined a call to odin.exe report is made this will check if the path for ODIN_ROOT exists

[Hyrtwol]

I'll rethink this and get back with a better "solution" I think we have enough in sys/windos to code this in odin instead of using .reg files.

[Hyrtwol]

fyi i have repushed the brach, removed the .bat files for file registration it was not really good. will try to implement it in odin instead ;)

i ended up adding a manifest file and embed that during build, this should signal to windows that we prefer an UTF-8 codapge.
there is still a .rc file for program info like version etc (i just copied the info found in the source and license)

adding all this info seems to make windows defender less upset with odin compiled exe files :p

[Hyrtwol]

this is how the info looks like in properties

[Kelimion]

I've given it a quick read and it looks really great. I'll evaluate it (try it out) tomorrow, but I'm for this in principle.

(And I'm glad the .reg was dropped. It's easy enough for people to register .odin as a filetype in the course of right-clicking it and using Open with.)

[Hyrtwol]

the embedded data in VS

the manifest looks like this

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity name="odin" type="win32" version="2024.8.23.0" processorArchitecture="amd64"></assemblyIdentity>
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
            <requestedPrivileges>
                <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
            </requestedPrivileges>
        </security>
    </trustInfo>
    <application>
        <windowsSettings xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">
            <activeCodePage>UTF-8</activeCodePage>
        </windowsSettings>
    </application>
</assembly>

this is very basic and there is other info that could be added.
also let me know the the version info is ok, for the 4 digit version i just used: year, month, day, nightly
works for now, but not sure it this will change with a 1.0 release?
the version stuff in the build.bat is a bit ugly but didn't find a better way, maybe better to generate a header file that can be included instead of all the defines.
let me know what you think :)

[Kelimion]

I wonder if we shouldn't have major.year.month.day, which would be 0.2024.08.23 now, so we don't clash with any version numbering after 1.0.

And/or maybe add another custom field ReleaseType that can be set to nightly or monthly, so we know how to interpret the version number, as well as a Build that's the same version we see from odin version, e.g. dev-2024-08:a8bc6f08a.

We'll have to give it some thought. I don't know yet how we'll want to version our post-1.0 releases, and it may be good for @gingerBill to weigh in on that so we can incorporate that knowledge in this PR, and not run into "2024.08.24 > 1.2026.02.13" issues if we don't have to.

One option is to categorically state that all versions will be YYYY-MM-DD based, even after 1.0, and then the 4-field version could in fact be year.month.day.major, where major is 0 and will become 1. Which is as you proposed only with the last field recording the language's major version instead of whether it's nightly, which could be put in the ReleaseType or other sidecar field.

[Hyrtwol]

i tried to keep the output to a minimum, not sure if the -v here is good here, it will output

[vcvarsall.bat] Environment initialized for: 'x64'
Using codepage 1252 as default
Creating misc\odin.res


misc\odin.rc.
Writing VERSION:1,	lang:0x409,	size [10](https://github.com/odin-lang/Odin/pull/2600/checks#step:3:11)16.
Writing ICON:1,	lang:0x409,	size 2216
Writing ICON:2,	lang:0x409,	size [13](https://github.com/odin-lang/Odin/pull/2600/checks#step:3:14)84
Writing GROUP_ICON:101,	lang:0x409,	size 34.
Writing ICON:3,	lang:0x409,	size 22[16](https://github.com/odin-lang/Odin/pull/2600/checks#step:3:17)
Writing ICON:4,	lang:0x409,	size 1384
Writing GROUP_ICON:102,	lang:0x409,	size 34
main.cpp
libtommath.cpp
Parsing of manifest successful.

see https://github.com/odin-lang/Odin/pull/2600/checks

[Hyrtwol]

good call with the 0 prefix 0.2024.08.23
personally i usually try to go for https://semver.org/ but must admin using dates is easier :)
will try to tweak it over the weekend.
also yes please ask mr. bill i have shamelessly copy'n'pasted his name all over the place, i guess he should "consent" :D

[Kelimion]

good call with the 0 prefix 0.2024.08.23 personally i usually try to go for https://semver.org/ but must admin using dates is easier :) will try to tweak it over the weekend. also yes please ask mr. bill i have shamelessly copy'n'pasted his name all over the place, i guess he should "consent" :D

I took it up with Bill, and we've landed on: YYYY-MM for monthly releases and YYYY-MM-DD for nightlies.

[Kelimion]

But let's do this for release builds only, so the YYYY-MM format, and let's drop doing this on nightly/dev builds.

For one, most people who use a pre-built Odin use the monthly version, and it's also easy enough to build from source. I've yet to see Defender complain about an executable generated by odin.exe that was itself built on the same PC.