APEs programming

the installer has to *know* which ape file is the latest, with version resource you can do a simple comparison. lower chances to fuck it up.

ok, i noticed i wrote some bs before. however, it's still true that the filedate is very unreliable to determine the version. using a checksum would be more reliable, but the installer had to know the checksum for every installer. so, the version resource remains the best way. i'm pretty sure that every guide to coding would mention these as proper standards anyway and i don't see a need to act like a rebel (you are just lazy!).

Originally posted by Yathosho
ok, i noticed i wrote some bs before. however, it's still true that the filedate is very unreliable to determine the version. using a checksum would be more reliable, but the installer had to know the checksum for every installer. so, the version resource remains the best way. i'm pretty sure that every guide to coding would mention these as proper standards anyway and i don't see a need to act like a rebel (you are just lazy!).

I get your point about the file date/time being unreliable but its better than nothing. Maybe fallback to date/time if the version is absent?

As for version resources being good practice... the version resource system is a hacky pile of crap of its own. The real coder's solution is to get the information from the PE header like Windows does... whether or not there is a suitable API for doing this though is another matter entirely. I'm sure that has something to do with the general crappiness of versions in executable code. Rather than solve the problem MS devoted their attention to their horrible WinSxS / .NET assembly system.

It's all very backwards... "DLL hell" is only an issue if you suck at writing DLLs and programs to begin with. IMO there is nothing for MS to fix, except maybe the crappiness of their PE/COFF implementation which:
(O/S side)
* isn't consistent across the different flavours of Windows (a "do nothing" executable that runs on XP may not run on Vista)
* doesn't conform to the actual PE/COFF specs
* doesn't conform to their own PE/COFF specs
* isn't accurately documented anywhere (that I've found)
* isn't necessarily used as the source of information for .exe properties sheet
* doesn't come with an API to use it
(compiler side)
* doesn't grumble if there is missing information (i.e. no version)
* doesn't check the validity of values
* imposes more restrictions than either version of the standard or the implementation require

I went off on a bit of a tangent there... but the relevant point to this discussion is that the PE could provide a checksum AND a version if it wasn't implemented by MS monkeys.

While we're talking about detecting versions.. Can PB somehow detect the AVS version in the same, or some other way?

If it could, the installer could prevent installing Video Delay and [the other pre-installed one, convo filter?], if the current AVS version also includes those effects, or even remove those (unwanted) duplicates

pimpbot already disables the sections for those apes in during setup. however, the user can override this and install the APEs anyway. in that case and extra question will bother the user, default action set to no overwrite. pimpbot also warns the user if an APE with version resource is newer than the one included the installer.

Then, did Micro D use an old version? During the installation of xen-ON, it tried to install Video Delay (the checkbox is green)

afaik videodelay is circulating around in two different names. pimpbot uses delay.ape since day one, but maybe that's a mistake.

edit: is the ape part of avs? when did that happen?

I don't have a delay.ape in my \avs folder, but I can use video delayin my presets. I just installed delay.ape there (for testing), there are two instances now.

Don't know when it was added, but my guess would be ever since 2.81b.