64 bits Window binary compiled with VS 2013

Great job @alphabeta!!!
Can you share your build tutorial/patch?

Thank You @ steem-id.
Maybe on the next post.

Nice!!
I'm stuck on this error:

     1>..\..\..\libraries\net\node.cpp(4221): error C2143: syntax error : missing ')' before ','
     1>..\..\..\libraries\net\node.cpp(4221): error C2064: term does not evaluate to a function taking 0 arguments

Unable to debug because I'm not a programmer :(

Well done! I'm interested to know how you did too.

Thank you. Upvoted and resteemed. Guess I'll give it a try for a couple days and see how it does. Did you get any blocks in your 24 hour trial?

No block, it is not fast enough to compete with @rabbit & @supercomputing.

I am not a c++ programmer either.
I look at @bitcube's original source and modified accordingly.
On node cpp line 4221

changeg from: FC_CAPTURE_AND_LOG (())
         to:  FC_CAPTURE_AND_RETHROW() 

after that you will encounter few more issues, and more code modification before its able to compile.

Right. Before the hardfork, I was squeezing out a block every day or two. The target and queue length are a little bit higher now, though. If I don't get any blocks before Wednesday and the cost of steem stays low, I'll go back to mining indirectly through nicehash, using the method I described here. I've been getting about 5 steem per week that way.

Anyway, thanks again for doing this work and putting the binary out there.

I stop mining once @rabbit & @supercomputing taken over the miner queue.

I followed @bitcube's guide and look @ the change that he made on his commit.
https://github.com/btscube/steem/commit/f2392527a071b0b3b9064a8111468211aa14f18a
There are few more codes change needed on the new source for it to work with VS2013.

Would you mind sharing your VS2013 solution (.sln) You can DM me in steemit.chat (same name)

I will post the list of code change here later.
Because I do not have a Github or steem-chat account(did not sign up one).

Excellent job!

However, i need to ask, will you publish the source? Using miners and keys with closed source is kinda.. Hmmm..

Win executables are perfect for hiding things inside. I'm not saying you did, but it's a matter of time before people will ask or state you did.

Love this, following you!

Looks like that change is made by me, which is to address a node stuck issue. I'm not sure why it doesn't compile on vs though. Perhaps just need to add a whatever variable to the inner (()), for example make it FC_CAPTURE_AND_LOG( (_user_agent_string) ). Need testing.

//Update: after made above change, at least the project still compiles in Ubuntu. I have no VS env, so need your help to test out.

Thank you!
Maybe I will post the source later today when I have the time.
Save me the trouble posting all the code change on a post.

I will test it when I can.

Hi @abit,
I did a test with above code FC_CAPTURE_AND_LOG( (_user_agent_string) ), it compiled fine with VS2013. But after it fully syncs, it crashed, not sure why.
I would like to ask you a different question.
when I was compiling cli_wallet, I got error C2593: 'operator <' is ambiguous
which is caused by found using ADL on ip.hpp(60). F:\winsteem\steem\libraries\fc\include\fc/network/ip.hpp(60): could be 'bool fc::ip::operator <(const fc::ip::endpoint &,const fc::ip::endpoint &)' [found using argument-dependent lookup] while trying to match the argument list '(const fc::ip::address, const fc::ip::address)'.
I try to overload the operator by adding a line friend bool operator<(const address& a, const address& b);,
it gives me different error LNK2019 & 2020 unresolved externals. So I end up omitting line 60 from the ip.hpp file. then it compiles without issues.
The question for you is what is the best remedy for this error?

This post has been linked to from another place on Steem.

• Steem 0.14.2 Windows VS2013 Binary Now Available, Though CPU Mining is Already Pointless by @cryptos

Learn more about linkback bot v0.4. Upvote if you want the bot to continue posting linkbacks for your posts. Flag if otherwise.

Built by @ontofractal

I'm replying here due to reached maximum nested level. Sorry for the late reply.

after it fully syncs, it crashed, not sure why.

Crash every time after fully synced? Logs and/or core dump etc would be useful.

when I was compiling cli_wallet, I got error C2593: 'operator <' is ambiguous
which is caused by found using ADL on ip.hpp(60).

It seems that in the cli_wallet code somewhere there is a comparison between two address objects, but class address lack of a operator <. Try

• add a line friend bool operator<(const address& a, const address& b); to class address, and
• add an implementation to ip.cpp?

  bool operator<( const address& a, const address& b ) {
    return uint32_t(a) < uint32_t(b);
  }

Update2:
Thank you @abit. All the below code change compiled without error.

FC_CAPTURE_AND_LOG( (_user_agent_string) )

• add a line friend bool operator<(const address& a, const address& b); >to class address
• add an implementation to ip.cpp?
  bool operator<( const address& a, const address& b ) { return uint32_t(a) < uint32_t(b); }

Except the latest commit. It has 7 error:
4 reference to raw.hpp line 294:
c2668: fc::raw::unpack : ambiguous call to overload function
and 3 reference to variant.hpp line53:
c2668 fc::from_variant : abmiguous call to overload funciotn

I don't think it is related to the code change.

"raw.hpp line 294" and "variant.hpp line53" don't contain code in my repository. Would you please share us the whole error message, or just post in an new issue to your own github repository and post the link here? Thanks

Ok. I will try that later.

FYI, there's a mining patch from @penguins (penguin on golos) via @picokernel that improves mining performance. Unpatched PCs are only running with one effective core, no matter how many threads are configured.

@contentjunkie has distributed a compiled binary for windows, but for some reason that version doesn't seem to be working properly in my environment. I tried on 3 different PCs and can only get it to use 1 actual core, no matter how many threads I set in config.ini.

I saw that yesterday and compiled a binary with it. I did not see any hashing power improvement but it found a block for me just half hour ago.
I did not post on Github yet.