OK, there are a couple of things at work here:
1. GOG is pretty good about storing everything relevant in the Windows Registry. You don't actually need to keep track of much. Which games are installed, where they are installed, how to launch them... you can get all that from the registry.
2. That contains the supportlink ID... the link title. Unfortunately, these are sometimes missing from old installers. For that, I'd keep things simple. A simple text file for each game id on my servers that contains the support link as a fallback.
3. You can also do stuff like searching, querying the available games and so on via the AJAX api supplied at http://www.gog.com/games/ajax . For example [url=http://www.gog.com/games/ajax?a=search&f={%22sort%22:%22added%22}&p=1]http://www.gog.com/games/ajax?a=search&f={%22sort%22:%22added%22}&p=1[/url] gives you a neat list of all games available (the p=# is the page number).
For example, I'm using the search right now as a fallback for games without a support id.
4. A few things are not available via the AJAX API. For example the cover art or this neat list of news items (you can however use the RSS feed, but the one on the page is just nicer). For that you can use the DOM API (remember, XULRunner is a browser at heart) to extract and display the relevant information (as I am currently doing for cover art and news items).
5. For everything else, there's SQLITE, which is hard-baked into XULRunner and works wonderfully for small, local databases. For example, I'm using it right now for a caching mechanism.

In my opinion one of the most under-appreciated tools around. WebKit is nice, but it's so much easier getting started with XULRunner. You just create a couple of config files, a XUL or HTML page and voilà: Your first alpha release is ready. And you can access all the Mozilla internal functions (which do stuff like file access, registry access and so on), as well as any other DLL via JS-CTypes. You want to manage memory manually? Fine, just import malloc and free. You want Joystick support? Well, you can try the COM interface, but I'd suggest simply loading the SDL DLL...
I actually want to make it a Javascript app. I think it's simply the most awesome language around, with a lot more flexibility than Java. C is great, but I actually like the DocumentObjectModel and well... accessing the DOM from C is always a pain.

About the database: SQLite is really more than enough. We're not talking about Gigabytes of data here :)

Mh, and the GOG API? Could be helpful to use it for getting missing information.
Well, RSS just stores just the latest news or gives a limited result.
SQLite is great for the project.

Sounds good, but isn't this all limited to Windows? DLL, COM and so on ... not really crossplatform
So the app will be just available for Windows?

Well, there is for example Jsoup for Java, which is a very mature HTML processing library. Also it is still a C app with Scripting (JavaScript)

Did you try htmlcxx which is also used for lgogdownloader by Sude? Mh, personally I would say Java is more flexible than JavaScript as a Java and JavaScript developer ;-)

Do you plan to release the sourcecode on Github?

Why do you want to use something else than XUlRunner?
We can get this running on all platforms:
https://github.com/neam/webapp-xul-wrapper
http://www.zotero.org/support/dev/client_coding/building_the_standalone_client

Hmm... is there an additional GOG API? Sorry, apparently I missed that

That's why I prefer the version available on the page, which is really, really easy to import.

Well, GOG is only available on Windows. Under Linux I could use WINEs registry, but let's be honest: There simply is no way to support a service that's only available on one platform cross-platform.

About XULRunner in general: The internal classes are platform-independent, as far as possible (like I said, you can't have cross-platform registry access), but of course if you call into C libraries, then you are limited by the inherit platform-dependence of binaries. If the library is available cross-platform, like SDL, you can use the same code.

Well, XULRunner is a C application too... so it pretty much comes out the same... it's just how you define C-application or Javascript-application. At some point you always end up with something low-level.

Haven't looked at it yet, but I seem to have some faint recollections. About Javascript:
I was talking only about the language, not the base-libraries.
Java has very restricted syntax, often with very strange workarounds to make it usable. Aside from the cursed RegEx literal (try writing a JS tokenizer... urgh), Javascript is very clean, with simple constructs. But these simple constructs can be re-used in practically every situation and you can make them do almost everything you want. There's a reason I like to compare Javascript to C. Simpler syntax, more flexibility.
It's not always what you need, because it's harder to analyze... but for writing, I'd prefer it to just about any language.

That would be one way... So far I haven't used GIT, but I think it's about time. But you can read the sourcecode directly inside the alpha download. It's in the chrome directory.
Found it! https://github.com/lhw/gogdownloader/wiki/API

Thanks for the pointer. Didn't event know it existed. Yes, I would definitely want to use this.

So... any suggestions regarding license? I usually prefer the Affero General Public License

Sure: https://github.com/DanielRuf/xgogdownloader/blob/master/src/Api.java#L84
Or did I misunderstand you?
I have also updated my latest comment about building XULRunner apps for different platforms at once.
GOG on one platform? Where does GOG store the information on a Mac?
Well, because of this there are great Java libraries. But this is unimportant as we want to use the XULRunner solution in the future? I do not know hoch much Java experience you have, but Java is one of the most used languages (Twitter, Google, Facebook, ...) ;-)
This would be very helpful as issues, commits, and pull requests are much easier when using Git or Github
I know, C is very annoying but if you are in, it is not so hard.

So, you are also looking for webdevelopers as they use mostly JavaScript?

I think OS portability to Linux and OS X should be a concern; while those operating systems are not officially supported that doesn't mean people don't use them. At least downloading and updating installers should work on all operating systems, allowing you to choose which installer you download. Not like Steam where you can't download Windows games when you're on OS X.

Actually, the more I think about it, maybe it would be better to have a separate GOGTools library that handles all the low-level logic and then the actual client is built using that library and tailored specifically for the OS in question. I can tell you for a fact that Mac users can spot anything not written in Cocoa, even if you emulate the look down to the pixel.

There's very little you can do cross-platform. As you say, the UI has to be native to the OS. Also looking for installed games has to be native. The only cross-platform thing is calling the GOG APIs.

Wait... I never said I wanted to use anything but XULRunner.

No, I really missed it. Happens from time to time when you don't expect something to exist :)

Whoops. Forgot about Macs. No idea how it works there... my guess is that we'd enumerate the application bundles directly, but I have ZERO experience on Macs. Nothing. I know them from a user's perspective and I really don't like the interface logic, but that's about all I know. So that would have to be something that somebody with an actual Mac does. Shouldn't be an issue though. I define an interface and somebody who wants it to run on a Mac adds a class that implements it. Done.

I know Java alright. Same as C... I could write it in either of them, but it would just be more work... that's all there is to it :)

Alright, I'll set up an account right away.

There really isn't that much aside from the interface that you could share between those programs. I'd say that all we can do is either giving the application its own look on all platforms, or ignore MacOS altogether :(


EDIT:
First Version is up on GitHub:
https://github.com/hansschmucker/GamesDesktop

downloaders are already available, like lgogdownloader and the upcoming xgogdownloader ;-)
I pan to release a version of xgogdownloader with GUI

But if I have understood correctly, GameDesktop should not be like Steam and should only show the installed games on the computer, no downloading or updating of installers if I know so far.
UI generally has not to be native, but in this case yes.
Also looking for installed games can be solved crossplatform (with the right libraries) ;-)

I don't think so. Take a look at the Model-View-Controller pattern:
http://en.wikipedia.org/wiki/Model–view–controller

The model would be written once and made cross-platform as a library, while the view and controller would be OS-specific. Someone writing a client for their toaster would just need to hook up to the view, where the heart of the application lies. That way someone could even write a text-based GOG client, if they really want.

Awesome, thanks. I will take a look at it =)

But the problem is, to support this pattern in XULRunner as the project will still use XULRunner
The view and UI is already crossplatform (XUL) or did you mean creating a fork and starting from zero with another solution than XULRunner?

I know the model, but try to apply it here: There really isn't much to do outside the view... and what is to do is platform-dependent! And the view isn't appropriate for MacOS. It really only makes any sense if we use the same view for MacOS as well, which probably wouldn't be accepted by users and therefore not worth the trouble.
Maybe at some point, but definitely not right away.

You mean because they want a view that looks native to them?
Nearly impossible. Why would they not accept it?

You think they would? I've got no idea, honestly. The mind of an average Apple user is a complete mystery to me ;)
You misunderstand the problem. The model is about as complex as the communication between such a model and the view would be. It's not hard. It's just a bit pointless in this specific case. In general, you're entirely correct, just in this case things are a little different.

I don't think it's pointless, such a "GOGTools" library could be used by various projects. We already have an unofficial Linux downloader, a Java port of said downloader and now a Windows client. I just think it would make sense to sit down and write this one part once rather than having everyone re-invent the wheel. Oh sure, you can look at someone else's code and adapt it to your needs, usually that's not that hard, the problem is that each of those implementations has to be maintained individually instead of just updating it once and everyone profits.

Yeah, it won't matter in this case, not in the next or the one after that, but in the big picture it's re-inventing the wheel each time.