Very interesting scenario, though I find it difficult to think of a realistic setup at all without more information. How big is the colony?
If it's something of an off-shore platform out there, that would likely make the colony rather small, and I would expect the crew on the spaceships to also rotate the crew on the colony.
So basically the decision to go work on the colony is a 10-20 year contract in "your time", but a ~ 30-40 year contract in "real time".
If it's a major settlement, I would expect their primary objective is to establish self-sufficiency, and after the first century or so these trade missions will probably mostly be about luxury items or scientific exchange that would impact production on the colony during the decade after the ship arrives. (Depending on whether several ships arrive during the 24 years, or if there is just one or a few ships that go back and fourth).
There is also the question of political stability in the solar system. Are there still economic problems?
I suspect some competition for a chance to jump 24 years into the future whenever there's some form of unrest. If scientific achievements are still happening at the rate they are now, this would likely be extremely appealing even in good conditions for a lot of people, especially if they could go with their families.
I think those semaphores are just copied from the multi-threaded multi-queue example, and aren't actually required when acquiring the image and presenting on the same thread and/or the same queue, even without any Wait, if I understand things correctly.
AcquireImage is supposed to block until an image is available or return an error or timeout, and present is supposed to be added to the end of the queue. Queues must be externally synchronized, so the only reason to use a semaphore on AcquireImage is if another thread is about to start submitting command buffers for drawing to the image before AcquireImage returns. (This also makes AcquireImage returning the index of the next buffer redundant, as it must already be known if another thread is already building the command buffer for the frame using that image before it is returned as available).
The semaphore on Present makes sense if the present is submitted to a different queue than is drawing the graphics, even in single-threaded apps, as the last actual drawing command must finish executing on its queue before the image is presented on the other queue, but if submitting the Present on the same queue it is redundant, threaded or not (though threading on one queue might not make much sense.. unless submitting a present to the queue is actually expected to be a slow operation and the main thread wants to start processing the next frame or something without using the queue).
I tried it out and it works reasonably well, though feels beta. VSync in particular doesn't work at all when I use the SDK, but if I load the functions from the Nvidia driver directly I can't turn it off (no immediate mode reported and ignored if used anyway). Haven't been able to find how they manage to turn it off from the SDK sources...
Also the SDK crashes whenever I enable the debug validation.. though if I enable the individual layers but leave out the threading validation layer it seems to work and I get debug output.
Haven't found anything about fullscreen mode. I'm reasonably sure when I first tried a fullscreen top-level window I saw a distinct automatic modeswitch like OpenGL does.. but today it stays in "fullscreen windowed".
Only B8G8R8A8 modes reported for me.. no 30-bit backbuffers in the current Nvidia driver apparently.
Documentation feels somewhat lacking. In particular the swap chain parts, where the various examples do things different ways and none quite make sense. When I do get VSync the blocking seems to be in QueuePresent.. whereas I would expect it to just queue up the present and the wait to be in AcquireImage. Perhaps we're supposed to always present on a separate thread or something... I get the delay in present even if I wait for the queue and device to become idle before I call it so it definitely seems to be a wait for the actual VBlank. EDIT: Actually not entirely sure on that, not used enough to this yet to be sure I do things the right way.
Debug validation seems to work, apart from the crash and again problems with the swap-chain. Docs specifically says I need to transition the image between present mode and color attachment, but ignoring that and transitioning it to whatever insane layout I choose at random doesn't give any warnings and works happily.
Didn't get far past the setup yet so everything else may still be great
However, that will only really allow you to use quite old OpenGL functionality without some extra work, as the newer version functions aren't readily available in opengl32.lib. The default library only provides version 1.1 or something like that (even when the context version is 4.5).
To load more functions you need to request their function pointers from WGL while your GL context is current, for example to use the glCompileShader function:
The function pointer will match a function in the NVidia or AMD driver for example, not in the system OpenGL DLL.
This is a bit tedious, and if you want to do it manually the best way is probably to download glcorearb.h from opengl.org and write a script that goes through it and loads all the functions into some appropriate wrapper or global pointers or something.
It can take care of checking all extensions etc. for you and help make sure everything is loaded properly and detect when it isn't. This is especially useful when loading extensions that may be available only on some drivers. If you make sure the context version is 4.x and you load only core functionality matching that version it's just about loading all the function pointers.
On Android there's Renderscript that is specifically made for things like image filters that might work. In general you should be able to do a lot of stuff in GLSL shaders. I would investigate that possibility as it could save you a lot of work and improve performance.
Another way is to capture messages in the main loop when returned from GetMessage/PeekMessage.
One thing I see is that you should probably not always return DefWindowProc at the end, but let 'MessageHandler' decide. Though I'm not entirely clear on what your message handler does, do you pass everything to it or where do you decide what "converted winapi parameters" are?