Hello Claire123,
Fantastic!
That is why I'm trying to offer an alternative build platform for Windows. The bitcoin source is the same. Not changed at all. Except with changes as above. It should (famous last words) be easier to pretty up a windows version in MSVC than in Qt. At least it seems so to me at this time. Qt is fine but it seems to have a lot of compatibility issues with its compiler, its libraries, etc.
Have you seen my thread on building BitcoinD and BitcoinQt using MSVC?
No I have not. But I will be going there as soon as I finish responding here!
Not really. I'm saying that on the Windows platform we should have more choices. And a working MSVC++ solution would be a start, allowing for alternate GUIs and daemons, and programs to talk to a normal full client daemon, etc.
I wonder if you could just turn the daemon into a DLL and then put a C# wrapper around it? I've discovered that doing a GUI in C# is way easier than Qt.
Yes, and MSVC++ can gui up and application in short order with those same VS drag and drop design tools, etc. For the fun of it, I just GUI'd up the Qt look and feel in design view and could make a pretty good imitation, FWIW in short order. Nothing behind it though.
Also, concerning the aborts when closing the application: when I was porting the latest bitcoin source (the unreleased latest from github) to MSVC about a month ago, I found a bug in their shutdown sequence that caused aborts. It was due the shutdown unwinding the bitdb object which needed to be explicity closed() first. The abort was happening in the boost string code and was difficult to track down.
I think you have found the bug I have been remarking upon since version 0.8.2 came out. Congratulations!
I will look at that too! I couldn't wait and went to read the first link. Wow! And I have news for you. I have an
addrman.h -
serialize.h solution that compiles!
The reason MSVC++ gets ill at addrman.h as you say:
Addrman.h was especially difficult and I ended up ... giving MSVC fits.
was not only those extra
(()); around the big
IMPLEMENT_SERIALIZE(...) macro in the
CAddrMan class, that implements
GetSerializeSize() Serialize() and Unserialize(), but also the extra complexity of the imbedded
std::map<int, int> mapUnkIds;!?
When the map<> is "levitated out" of the macro and placed in the
#define IMPLEMENT_SERIALIZE(statements) macro in
serialize.h the compiler hums!
My 0.8.5 MS'd sources compile fine. But my MSVC++ static library build of the google levelDB blockchain database driver, seems to violate its own rules and I error at
VerifyDB() at level 3, where serious levelDB "stuff" is happening. Level 2 it's off to the races, until it gets a few new blocks and it actually has to write something to the .sst files in the chainstate directory. I have tracked it down to (in levelDB source code terms) the
db/db_impl.cc code for DBImpl::Get(...) and possibly other methods' desire to do a
MaybeScheduleCompaction. The compaction deletes file(s) from the table of cached .sst files, somehow not notifying the rest of levelDB, and/or deleting them properly via
DeleteEntry()! Then when .sst file x is needed,
db/table_cache.cc method
TableCache::FindTable() doesn't find it in the table, and tries to open it, but it is open and Windows says no! So FindTable() errors.
I think it is my MSVC++ version of levelDB (1.13 version) that isn't "locking" out the rest of itself correctly, when it is compacting, though I can't prove it. When I compile out various
MaybeScheduleCompaction() I can get through
VerifyDB() at level 3, but when I get enough new blocks it still happens. The result is a "spoiled" .sst file and so the whole chainstate index file system is vetoed and one must
-reindex or bring a saved backup block testing blockchain to continue testing. Which is what I have been doing for about a week now
I am very curious, needless to say, how you have built your levelDB static .lib file! I used the
files given in a google discussion I found at:
https://groups.google.com/forum/#!topic/leveldb/VuECZMnsob4see message from
Edouard A dated 6/20/11 where there are three (magic) files:
port_win.h, port_win.cc and env_boost.ccThey almost did it for me! The
std:move() in
env_boost.cc LockFile(...) stops me dead with my MSVC++. I like the older ones that still can do a straight console app, a simple windows form (aka ol' dialog box app), doesn't have a broken (too much) intellisense, etc.
Anyway, I dug further and came upon this thread
https://groups.google.com/forum/#!msg/leveldb/MpLZkz7rcHk/b9B3Eka6jdQJ with the same
Edouard A dated 7/3/12. I used those files to create a levelDB113 static library project. I will look forward to seeing how you did it! See my message #322 on building the other static libraries. Hope this helps. I will Github some commits on a forked branch of 0.8.6 or 0.8.5 soon. But I would like to have a truly working version first.
Ron
