I have managed to compile Litecoin 0.8.6 wallet without errors on closing but it has an awful windows 95 look. Why is that happening?
How? Depending on what versions of gcc, boost, openssl and bdb I use results can be anything from refusing to link, refusing to start up due to "wallet db error", or crashing on exit. Man, I hate Windows...
What makes you think it has anything to do with Windows?
I use Qt 4.8.5, gcc 4.4.0, boost 1.50, berkeley db 4.80, and openssl 1.0.1c currently, as I know these are used in several other working wallets, including a few Litecoin 0.8.6 forks that run perfectly.
I use Qt 4.8.4, gcc 4.6.2 (unobtanium now!), Boost 1.53, BerkeleyDB 4.8.30, OpenSSL 1.0.1c or 1.0.1e and levelDB 1.13 and build bitcoin with no problems. I can't speak to litecoin as I don't know when its sources "forked" off of bitcoin. It is important to know what version of bitcoin, and so what date, that an alternate crypto currency was born, as the tool versions that were used at the time would be most appropriate for that alt coin. As the alt coin "matures" one may update the tools, but they need to be updated in a "gradual" "coordinated" fashion. For example, one wouldn't - shouldn't use too much "newer" gccs as their "behavior" is known to "destabilize" "older" Qts for example.
Have you tired the tool combinations that fail somehow on Windows, and build the same alt coin (or bitcoin) on Linux (or MacOS) and test to see if they work there?
The main problem people have in building bitcoind & bitcoin-qt on Windows is that they aren't meticulous (enough) in following the recipe of nitrogenetics.
Of course, it helps if you are knowledgeable on Windows! Especially on command boxes (aka DOS windows). It helps greatly if you know how to use .bat files or .wsh files, that is, how to "do" batch programming. Also it helps if you are knowledgeable on how the Windows path environment is kept, controlled and manipulated. There are many copies of the path at any moment in Windows, you know!
There are subtle issues of pathnames with spaces in them, though that is less of an issue now than it was in the past. And also one must be aware of subtleties regarding "\" versus "/" in couching pathnames. None of these are difficult issues, it is just that the knowledge has been lost since there are no longer any definitive books on these subjects, and the general Windows user is no longer expected to know or wants to know, how to do these things. Remember that Windows 7 and 8 now make it even more difficult to "get your fingers in there and meddle around".
It helps if one knows the history of Windows and its DOS heritage. Without that knowledge you have to fumble around by analogy with whatever you know about Linux, Unix, MacOs, etc. and try to discern the "truth" of any subtle question by internet "research" and have the good judgement to know what is true, half-true or pure BS. Kind of a vicious circle (catch-22) in which the only way to get knowledge is to know enough already to be able to tell what is knowledge
So if you think the bitcoind (and Boost) code is pure and clean, try building it without the gcc -w argument! Let's not even talk about qmake, makefile.release/debug and bitcoin-qt, which doesn't have the -w argument and you know what it "spews forth"
What's interesting is that the compiler "warnings" about the bad C++ slang that is being used, as opposed to the preferred slang, i.e. the highly idiomatic, baroque (as Knuth calls it) nature of C++, can be controlled in MSVC++ and one can "see" more clearly what is "going on". The thought is that this should lead to more understanding, but so far, the answers given are swamped by the questions that now appear! Which is why you haven't heard from me (yet) on the Windows MSVC2005 version of bitcoind. I have a "debug" version of bitcoind 0.8.6 that "appears to" run correctly. And yes, Claire123 has a MSVC2012 version of bitcoind (& bitcoin-qt), but do our versions work correctly? Do we have 'release' versions? I am hoping to "GitHub" commit-pull request my MSVC "additions" to the bitcoind sources soon, but only when I feel that the code runs reliably.
All of this reminds me of the Zen quote for today:
The most dangerous thing in the world is to think you understand something.Ron