It's written in C++ (multiplatform). Downloaded source, looked what includes were missing. Went looking for them, found them, dropped them in a directory that they could be found and included. Hit a snag when it complained about missing time function (or something like that) and didn't go look what I should add/include to be able to find the functions it didn't recognize.

What could it possible be including that would make it unbuildable on windows?

I can give a look, but it's a while since the last time I did C++. Give use error logs on a pastebin.
Moreover, C++ isn't equal of multi-platform in every case : it depends on APIs and libs used. Something fully build with win32, even in C++, will only work on Windows. Can be the same about full POSIX/BSD libs which can cause problems on Windows and so on.

It's not configured for Windows out of the box. You need to figure out how to modify makefiles and so on. Depending on the C++ compiler you use it can be different. And yes, POSIX is not compatible with Windows in general.

Your best bet to build LGOGDownloader on Windows is Cygwin or MinGW/MSYS because of the libraries that it uses.

I tried building LGOGDownloader for Windows using Cygwin couple of weeks ago.
At first it complained about the initialization of variables in the API class. This was easily fixed by patching it to use the older method of initializing variables.
However I hit a brick wall afterwards due to a bug with C++11 features in the version of gcc/g++ that Cygwin uses.

My Windows VM decided to die on me last week and I haven't bothered to do a re-install of it yet. I'll probably try compiling LGOGDownloader for Windows again in a few weeks when I have the time to setup everything for the VM.

No more so than old MSDOS and Windows games are broken in modern Windows too, and GOG updates them to be compatible with current Windows systems, and uses the DOS emulator to provide backward compatibility for some of them. There is no reason that similar backward compatibility strategies could not be used for old Linux games. To get old Loki games running would basically require creating a compat-glibc-x.yz package for the version of glibc that the game is built against, and perhaps a few other dependencies the game might need. Quite likely a lot of the games have the same dependencies so someone could even create a loki-games-compat meta package that depends on (requires) the complete set of known compat packages for the various Loki games. This isn't something the average gamer could likely do on their own, but then neither is manually setting up DOSbox, ScummVM or other things that GOG does to get old games to work on new versions of WIndows.

There are a few additional problems that could arise such as games using the X11 DGA extension and it possibly not being supported on a modern X server, but there are totally ways to provide compatibility for those type of things too for the most part. (I'm a former X11 hacker.) Another method is using wrapper libraries that translate old APIs no longer provided through a layer to something that is now supported. For example, it is likely possible to handle DGA in this fashion and some other legacy X server extensions that aren't supported any more. Since the source code for everything is readily available, as are historical binaries, it should be easier to provide such backward compatibility for old games even if it means using a virtual machine and installing a miniature legacy Linux OS into it just for running the game - much like DOSbox is used in Windows. It'd essentially be LinuxBOX. Another way is using a chroot jail with older legacy packages in there. Lots of options.

I only pointed this out because I feel that Linux is no different than Windows in respect to making ancient games work and new systems not being compatible thus requiring backward compatibility packages etc. be added to the system to get them to work.

On your other points, there are differences from distribution to distribution in which libraries are provided and the compatibility between them, window system support and other factors that do indeed make it more difficult for 3rd parties to provide a single build of their software that works on all Linux systems, and that is definitely one factor that causes companies to resist the platform sometimes. Ultimately though it's all about money, and when there is enough money perceived to be made by supporting Linux despite any shortcomings they may perceive it to have, they'll throw money at the problem and come up with something, whether it is universal support, support for a list of specific versions, or rolling their own custom Linux based solution such as Valve's SteamOS.

The problem is that the end user/gamer/customer just sees what they want to have happen - Linux support for example, and they do not really understand the true amount of effort on the part of the software developer to both port the code to the platform (which might be easy or might be challenging due to project specific decisions that pre-exist), and to provide adequate customer support for it for the plethora of customers out there all using widely divergent systems, many of them with custom home built packages and whatnot. It is a lot more complex of a problem than most people realize and it can mean a company has to have a large Linux support staff (both technical support and development, quality testing, etc.) compared to the number of units they sell on the platform compared to the Windows, Mac, Xbox, etc. platforms. That's not an insurmountable problem of course, but there has to be enough actual customer base willing to spend money to break through the threshhold where hiring that amount of employees to support it, QA test it on 10/20/30/50 Linux distributions can be viable. I don't think most companies are yet prepared to do that, but we're seeing some of them dip their toes in the water to see if they can find a way to tap into this part of the market in a way that is business-viable to them.

Valve is probably going to be the one company that cracks the code so to speak and figures out how to tap into the Linux market and hopefully find a profitable business model. Others are already waiting on the sidelines to try and do the same from what I read. I believe that Valve will be successful, will cause other companies to try to emulate their success, and eventually it will fan out from there. I believe that the results of Valve's efforts will help to standardize things to a degree and iron out some common problem areas. Possibly the creation of a game-centric thing like the LSB. the LSG ;o) (Linux Gaming Standard). Something like that would allow other platforms to add compatibility to that standard and give 3rd parties a common base to work from.

Eventually somewhere in that time matrix would be GOG coming to the platform too I think, but I think GOG really has their hands full right now growing their existing business on the existing platforms and while I could be wrong, I think GOG at the moment is likely to be more profitable by focusing on what they already do good - bringing more old games on board the existing platforms. It'll be easier for them to bring games to Linux when bigger companies with a lot more muscle and $$$ help to solve the platform related compatibility issues and generally improve the Linux gaming ecosphere. GOG can then coast in with their Linux strategy and where a market of games has proven viable already.

I'd rather see GOG wait and do this when they personally feel it is the right time than to rush into it and fail - like Loki and just about every other company has so far. Let Valve work out the tough bits, then ride their coat tails I say - much safer and much less costly research and development.

Windows NT and the Windows OSs that are the decendants of it (XP/Vista/7/8/Server 2xxx etc.) all have a POSIX compatibility layer. That layer is used by projects such as Cygwin, mingw etc. to bring UNIX APIs to Windows. It has its ups and downs but it is there and it does provide some compatibility. The reverse isn't true of course, Windows compatibility is not part of POSIX, but the equivalent in the other direction would be wine for binary apps, or winelib for building Windows apps to native executables. Neither is optimal compared to true native ports but then the same is true the other way around - using the POSIX APIs in Windows to port Linux software to Windows instead of doing true Windows ports.

Thank you again for looking at it. As I recall, I could find the libraries it used (rhash, json, unistd.h, tinyxml etc) but I had a time or something function not being found. I still think VS should be able to compile it, especially since VS2013 is a bit more strict with the C+11, but no idea if it's going to work.

Oh well, a weekend project it seems :)

unistd.h is a contraction of "Unix standard". It's a base of standard Unix function which are doing…Unix syscalls. So I've serious doubt that you can do it works on Windows excepted with emulation layer or by replacing these parts by Windows parts.

Yes, I know. The one I'm using comes from . The only unistd.h function that seems to be called though is GetPass which should be easily switched. Not sure if [url=http://www.gnu.org/software/libc/manual/html_node/getpass.html]this getpass could be used instead, but I haven't yet started to look which additional libraries require more additional libraries.

Has there been any news since I last lost hope on page 34 and stopped bothering trying to convince GOG that doing this is a good idea?

No news, except this update from CD Projekt Red: http://www.sticktwiddlers.com/2013/10/23/cd-projekt-red-the-witcher-3-wild-hunt-qa/ Since they aren't rushing, GOG doesn't feel the pressure either.

Just some guy posting for a dozen pages with half-baked reasons that ultimately boiled down to one central theme of "it's too hard so it should never, ever be attempted".

I haven't seen a German craft that many empty, vain excuses over something since Nuremburg.

So while Valve, Deep Silver, Sega, Nvidia, AMD, and others are making the news, GOG is just sitting this one out? Meh.

I think GOG proved to be pretty conservative and slow, not rushing ahead of others. I'm not sure how they want to remain competitive this way, let alone take on Steam in direct competition, but let's see what they'll do next year, and what their 2 R&D projects of 2013 actually were. I hope it's not some Android games support or some other mobile hyped stuff.

The company won't have my money again till Linux support comes. It's that simple. I genuinely ended up giving the 0 A.D. campaign on Indiegogo my 500$ instead of using the money for a GOG giveaway. It's bizarre how the folks at GOG do not see that freedom in the form of no DRM among other things falls perfectly in line with what Linux users seek. While all these big companies are rushing to support Linux thanks to Valve, GOG is sitting in the back suckin its thumb. You can tell that even AMD is serious considering how its open source drivers are improving dramatically.

2014 is going to be a pretty busy year for Linux. Wayland will be ready for prime time (on mobile in Sailfish already now, on the desktop with Gnome and KDE making Wayland releases). SteamOS will probably boil up to the point of release as well. This will keep Linux gaming developers pretty busy. Not sure what will happen to Nvidia/AMD EGL drivers for Wayland, but all these are going to be rapid changes. While it's pointless to wait for another year until this all settles in, GOG might do that unfortunately, pulling out their old excuse about not being able to figure out how to provide support.

It seems that GOG and CD Projekt Red simply have some management lack of will or decisiveness to start supporting Linux. Other developers / distributors / publishers are willing to enter the new growing market, being the pioneers. CD Projekt Red and GOG want to follow a known road, rather than making a new one.