Problem? Solved!

Problem at hand was displaying many images as hires textures in 3D scene. Current algorithm was using uncompressed 32-bit pixel format to render which led to the giant amount of RAM consumed for each - 2048 x 2048 x 32bit = 16 Mb. It was not the problem when image count was low (1 to 20) but after image count hit 100, application started to consume more than 2 Gb of RAM and on x86 it had become the source of very real "out of memory" error. The idea of solution was simple - use compressed textures. This way, there will be a ceiling for image count but it will be high enough to satisfy most of the needs. The main questions emerged was how to actually compress textures and which compression format should we choose? Due to engine used, we were limited to DXT1, DXT3 or DXT5 compression formats. Chose DXT1 as soon as it gives the best compression rate (8/1) and its limitations (1-bit alpha) are not critical for our application. The next question, actually how to comp

Problem: Active Directory Federation Services's FederationMetadata once failed to be published. Just out of the blue. Whether it was updates or anything but A is A. The usual URL like "https://adfs.server.com:443/FederationMetadata/2007-06/FederationMetadata.xml" was not working so any federated partner will fail to get any changes from local ADFS automatically. After brief search, the reason was found: the Access Control List for FederationMetadata/2007-06/ was removed, hence IIS was redirecting the request to the static file, and not to the adfs service endpoint: >> netsh http show urlacl     Reserved URL            : http://+:80/adfs/services/         User: NT SERVICE\adfssrv             Listen: Yes             Delegate: Yes             SDDL: D:(A;;GA;;;S-1-5-80-2246541699-21809830-3603976364-117610243-975697593)     Reserved URL            : https://+:443/adfs/services/         User: NT SERVICE\adfssrv             Listen: Yes             Deleg

Recently, I needed to implement rather big part of the software based on HTTP requests with C++ and WinAPI. As soon as the old-school blocking APIs are not the way to go in the 2014, I was choosing between COM-based WinHTTP and WinInet. I chose the latest because I read this  (there is a lot more "yes" there on the WinInet side;)) and I software was not a service. So here we go. C-style asynchronous API and OOP. Need to make a wrap, and good one - I will use it later almost everywhere! But how could I do it the best way in the world (I am currently aware of, of course;))? I decided to use the next schema: 1) Any class that needs to make an HTTP request, derives from "AsyncHttpRequest::Host" class 2) "AsyncHttpRequest::Host" class has the special static method making requests and special virtual method used as a callback 3) "AsyncHttpRequest::Host" also should take care of the request creating and destroying, i.e. memory management - to mak