Fix building with VS2015

[PrestoXen]

Been looking into getting VS2015 to work with it and ran into some minor roadblocks, I'll document them here for your amusement:

• [x] ::abs has multiple definitions for a single signature, changed to ::fabs (only usage was in a fabs wrapper anyway, todo: check if this breaks building on other OS?)
• [x] "timezone" var is removed from time.h, replaced with _timezone instead (which should also be backward compat?)
• [x] C++11 requires string literals to have a space in front if they're preceeded by something for some weird reason I can't remember, eg. printf("hi"LITERAL) would need to be printf("hi" LITERAL)
• [x] x86-Release links against LIBCTINY.LIB, which is based on VS2010's LIBC.lib and missing a few methods, sadly don't have the source for it, so need to remove that + nowatson.obj and link against LIBC.LIB again for it to link properly
• [x] x64 throws warnings which get treated as errors, platforms/windows/system.h is the culprit with a bunch of pragmas, strangely these warnings are never triggered on VS2010 (maybe didn't exist back then? this source also supports VS2012 natively)
• [ ] x64 builds seem to have an issue with 4chan of all places, literally every other site seems to work fine except 4chan. 32-bit builds don't have the issue, and x64 builds under VS2010 are fine too. Found a hack to fix it, but still need to find the proper cause.
• [ ] Debug x64 fails to build, something to do with too many sections? Didn't save the error log, will update once I try it again, would be nice to get this working since it could help with the above a lot.

[PrestoXen]

So I got a x64 VS2015 release build compiled, but for some strange reason it's not displaying 4chan correctly. Every other site works fine, but for 4chan it's like the CSS is failing to load. Switching to an x86 build lets it work, but as soon as I try the x64 build again it's broken. Very strange.

I'd wager that it was something to do with those warning-as-error pragmas I disabled, again even with them uncommented they were never triggered on VS2010 (which had a fully working x64 build), and I think they may have made these warnings be treated as errors for a reason:

// pointer truncation (64-bit unsafe) - Use when compiling for 64-bit to catch truncated pointers
//#pragma warning( error : 4311 )

// You attempted to assign a 32-bit value to a 64-bit type. For example, casting a 32-bit int or 32-bit long to a 64-bit pointer.
//#pragma warning( error : 4312 )

Instead of disabling the warnings-as-error, we need to figure out why the warnings are happening in the first place... ;_;

[PrestoXen]

Well I narrowed it down to the launcher exe causing the problems. If you use the official exe / VS2010 exe with a VS2015 Opera.dll it'll work 100% fine, instantly loading the browser with no CSS issues at all.

But using the VS2015 exe can make loading take almost a minute, and completely breaks 4chan for some reason.

Can't figure out how to fix it right now, I think it might involve the LIBCTINY mentioned above in some way, not sure how yet though.

[PrestoXen]

Alright, finally managed to make a quick-fix, don't really think it's a proper solution though.

Basically I just disabled relocations on the EXE, making the code sit at a fixed address. I think the Opera.dll code might still jump around, but the EXE will always load to the same place in memory now. Somehow this fixes the issue I've been having with 4chan, weird huh?

I'm running Win10 and I think that maybe VS2015 has some special features for securing apps running on it, my guess is one of those 'features' was breaking the styling code, but somehow turning off relocation disabled this 'feature', essentially dropping us back to 2012-era app security.

Well actually it's probably more like early 2000 era with relocations disabled, it's a pretty big part of ASLR and without it we lose that minor anti-exploit ability... I guess if you're using pirate versions of old browsers you're probably not the type to run into many exploits though.

Also you might be thinking, "but Xen, don't the VS2010 and official exes still use relocation?", and yes they do, but they weren't built with VS2015.

I reckon the VS2015 runtime probably co-ordinates with the Win10 OS to enable this security 'feature', but with relocations disabled it fails to enable it (with the side-effect of fixing our bug), but of course this is all speculation: the only thing I'm sure of is that disabling relocations fixed the 4chan bug for me. Finally! (I spent way too many hours on this..)

Like I said above though, I don't really consider this as a proper solution.. a proper solution would be to find the piece of code that's breaking due to this 'security feature' and fixing it so it doesn't break, instead of this hacky way around it, I'm not really knowledgeable enough to figure out exactly what's breaking though, maybe one day someone else will figure it out.

[vyvojar]

Like I said above though, I don't really consider this as a proper solution.. a proper solution would be to find the piece of code that's breaking due to this 'security feature' and fixing

Indeed this is really weird. Will look into this once I manage to piece a mingw build together.

Are the bases default 0x180000000(DLL) and 0x140000000(EXE), or does it use something custom? Sometimes x64 software links with bases below <32bit (eg carkana JIT might want to do so).

If you're keeping default bases, try to take the DLL base further apart from the EXE (eg /BASE:0x240000000) until it breaks. If you notice the delta is close to 2^31 or 2^32, some pointer math somewhere uses 32bit type where it shouldn't - 64bit ASLR typically throws the bases apart a lot, which would manifest as what you observed.

[PrestoXen]

Are the bases default 0x180000000(DLL) and 0x140000000(EXE), or does it use something custom? Sometimes x64 software links with bases below <32bit (eg carkana JIT might want to do so).

Yep those are correct, they're both defined to use those and the EXE definitely does when relocs are disabled, not sure if DLL does too though, might need relocs disabled on that also.

If you're keeping default bases, try to take the DLL base further apart from the EXE (eg /BASE:0x240000000) until it breaks.

Tried it and didn't seem to make a difference :( Also made sure DLL relocs were disabled too, and tried a bunch of different base addrs, didn't seem to break it at all...

I'm sure it is pointer math related though, like I said earlier there's a bunch of C4311/C4312 errors that get thrown under VS2015 which VS2010 didn't have any issue with. Luckily they're normally warnings so they were easy to work around disabling their warnings-as-errors pragma stuff, but it's still very weird how VS2010 didn't throw the same warnings, could be that VS2010 just didn't have them though.

EDIT: Actually I decided to take a peek at where it puts things with relocs on, and the DLL gets loaded at a crazy high 0x7FF9D9DE0000, with the EXE at 0x7FF7A6740000. Unfortunately turning relocs off and setting the DLL/EXE bases to those don't seem to affect it.

I get the feeling it could just be an address getting hard-coded at compile time, with the reloc data not updating that address after it loads the exe to a different address. Still weird since VS2010 seemed to do it fine.

[Zero3K]

Any news regarding this issue?