C++03 compatability

[Mecanik]

Amazing library, but it seems "too good to be true"... Does it work on OS starting XP and above ?

I`m asking because many things were added starting VISTA, and it would be nice to know if this library has any dependencies regarding OS.

[JustasMasiulis]

I wasn't sure myself so simply installed windows XP on a VM.

Because it works fine on win XP and on latest windows 10 I'd pretty confidently assume that it will work on vista and others too.
However windows xp toolset on visual studio was missing quite a few headers so you might need to trim down the #includes and do some find -> replace all but this might have been a fault on my side by using an existing project and changing up settings a bit instead of creating a new windows xp one.

[Mecanik]

Thanks, I will test as well on all the versions on multiple functions.

[Mecanik]

On this note, I can only compile and use this using VS 2017, 2015, 2013 ( + xp ) always fails. Might be some dependencies ?

[JustasMasiulis]

Yes, for XP there might be some changes needed to be done like remove and adding your own offsetof (which I wouldn't recommend on non MSVC compiler as they use intrinsics) however besides that only minor changes should be needed.

[Mecanik]

I don't think that's the only reason, I tried different versions of VS, none of them can compile. Only VS2017, and I think it's something to do with "constexpr"/c++11 I'm not sure. The errors are as following:

lazy_importer.hpp(319): error C3249: illegal statement or sub-expression for 'constexpr' function
lazy_importer.hpp(329): error C3250: 'value': declaration is not allowed in 'constexpr' function body
lazy_importer.hpp(333): error C3256: 'value': variable use does not produce a constant expression

I tried looking up on this on google, but I cannot find much - other that neither VS 2013/2015 supports "constexpr".

It would be great if your library would work lower than VS 2017.

[JustasMasiulis]

the library requires c++14. I'll look into what I can do about those errors, but that might take some time.

[Mecanik]

I see, c++14, well as I said if it's not impossible to have backwards compatibility that would be AWESOME.

Plus, it might resolve a lot of problems regarding XP for example. ( why do people still use XP ... ).

Thanks for all the effort.

[JustasMasiulis]

I will get it to work on VS 2015 soon which will probably include any c++11 compliant compiler, but I don't think that it is worth for me to port everything to any lower standard like c++03.

[Mecanik]

Yes indeed, VS 2015 (+XP) would suffice at least. However on this note, would it be possible to make work under VS 2013 - and if so, how much time/budget ?

[JustasMasiulis]

VS 2015 should work now. I might make a branch for XP support because as I said that would require rewriting offsetof which other compilers implement as an intrinsic. As for the c++03 I'd guess I would need to heavily rework compile time string hashing and use some macros to get rid of newest keywords which is quite a lot of work.

[Mecanik]

Alright then, got it. I will test your latest push right now, thank you!

[Mecanik]

It compiles and works great. Many thanks for your effort, I will test again on all OS.

[JustasMasiulis]

Sadly c++03 isn't really possible because there is no way to reliably hash strings at compile time. I might be able to work out some errors for VS 2013 which at least supports variadic templates, but won't really go lower as it isn't exactly useful.

Without the hashes being compile time I'd have to rewrite a large portion of the library code which would take me at least an hour or 2 + the time it will take to make the hashing semi-reliably compile time on release builds.

[Mecanik]

I would gladly help you if I could... I think for now even VS2015 is amazing to have.

[Mecanik]

I forgot to ask, and I do not want to create a separate "issue" for this...

How does this work with functions like "wsprintf", "fopen", etc ? Would it be okay to use it like so:

LI_FIND_CACHED(wsprintfA)

Because I have so many functions like this, would be great to use it.

[JustasMasiulis]

As long as they are exported - sure. ntdll has vsprintf, sprintf, memcpy etc

[Mecanik]

Thanks, that's great. I am just worried about what you stated:

LI_FIND[_DEF][_CACHED](function) Iterates trough all modules and their exports.

I mean, if it iterates though EVERY module loaded and their exports... that can affect performance pretty bad I guess.

[JustasMasiulis]

You can use the cached functions if you are ok with putting a variable in data section.

[Mecanik]

putting a variable in data section - what do you mean?

[JustasMasiulis]

The cached versions use a static variable so they do only 1 lookup. Because of that the variable will be placed into the data section inside your executable.

[Mecanik]

To be honest I have not even noticed that in my data section, is it ".gfids" ? I myself wouldn't mind if it's encrypted or something, because it favors speed.