Whenever I proposed to update to Boost 1.49 for the Win-build I got the answer no that is not importand enough ... see #1023, which even hardens the URI handling.

Dunno, maybe gavin didn't quite understand the phrasing there. To be clear, this simply encourages using a path of boost_1_49_0 instead of boost_1_47_0 when building with a MinGW makefile, if you add your own -I/-L you can still gladly use any boost version you want. It also upgrades gitian build to use 1.49 and patches boost according to a request for testing that a boost developer made at https://svn.boost.org/trac/boost/ticket/5392#comment:29 and that has not gotten any negative confirmations and works as far as I've tested it.

I'm with you and I have used boost 1.49 with this mentioned lines enabled for a long time now. I think my pull would perfectly fit on top of what you are doing here, but it seems no one even tried to look at it in detail :-/.

I think this feature is big enough it needs a test plan (see https://secure.bettermeans.com/projects/4180/wiki/Raw_Transaction_RPC_Test_Plan for an example of what I'm thinking). Also, since it opens up potential security holes, writing a tool to throw "fuzzed" input at it and verifying that nothing bad happens would make me happy.

To test:

1. launch Bitcoin-Qt with a bitcoin: URI to make sure it opens URIs provided at initial start.
   Result should be opening directly to the send dialog with the content of the provided URI.
2. while [ true ]; do ./release/bitcoin-qt.exe bitcoin:1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c; done
   Ensure only one URI is added per second to the send dialog (note that any more sent to Bitcoin will result in an error locking datadir as the new client attempts to load normally, this is an unavoidable result of the IPC mechanism), Bitcoin-Qt isn't using an unreasonable amount of CPU, and switching to the send dialog and scrolling to the bottom each time a new URI is added.
3. With the listening bitcoin-Qt running, kill Windows without shutting it down, start again and ensure that the same results.
4. Click the Send button and with the Send Dialog box up, attempt to open new URIs. Those URIs should be ignored until the send has finished.

To Fuzz with printable characters and URIs up to size 300: (note that anything larger than 256 will attempt to launch Bitcoin and give an error that it cannot obtain a datadir lock).
while [ true ]; do ./release/bitcoin-qt.exe bitcoin:tr -dc "[:print:]" < /dev/urandom | head -c $[ $RANDOM % 300 ]; sleep 1; done
To Fuzz with control characters and URIs up to size 300: (note that anything larger than 256 will attempt to launch Bitcoin and give an error that it cannot obtain a datadir lock).
while [ true ]; do ./release/bitcoin-qt.exe bitcoin:tr -dc "[:cntrl:]" < /dev/urandom | head -c $[ $RANDOM % 300 ]; sleep 1; done

It would be nice to get URL support back in once and for all. If that means requiring boost 1.49 on windows that's fine with me. But it's too bad it still needs the monkey patch to be stable :/ Won't the upstream boost developers integrate it?

Anything larger than 256 will attempt to launch bitcoin

Is that desired behavior? I'd prefer showing an error message about a too-long URL, then quitting. Maybe for a later pull.

@laanwj I consider this pull as a base for further updates to the URI handling code, even if not all parts of my re-work pull #1023 are considered good or mergable, I'm fine with a cherry picking or splitting them. But I think this pull needs to get in ASAP and if we need a patched boost 1.49 on Windows that's ok.

I agree with merging this ASAP.

Feels like a deja-vu, but can we detect the patched boost 1.49 somehow, compile time? It would be nice if it failed if one tried to build on windows with URL support without the patched boost. Otherwise, someone building bitcoin manually on windows might run into the mysterious crashes again.

@laanwj I guess we need no detection for the Windows users, we just need an official dependency package, which includes the used version of Boost and its libs.

Agreed, but not everyone will be using that, if you build from source you could insist to build everything from source. It's easy to miss.

Why not #if !defined(BOOST_INTERPROCESS_HAS_WINDOWS_KERNEL_BOOTTIME) || !defined(BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME) and throw an error. It should be insinde an #ifdef WIN32, too or use defined(WIN32) as addition argument.

In terms of erroring if we dont detect BOOST_... flags specified, Id really prefer not to. I dont want to follow boost and remove the checks if boost upgrades and complicate them with complicated boost version checks. Anyone who is building bitcoin for Windows should be reading and creating executables by closely following the gitian commands. Especially note that we add the mthreads/-fexceptions flags in the qt gitian descriptor, not in Bitcoin itself.

-mthreads/-fexceptions doesn't apply to people building on windows. It's a cross-compile specific issue.

Another idea (better than failing) would be to make URL support a build option in bitcoin-qt.pro, which is disabled by default on Windows. Then document it as "Enable this only with a patched Boost >=1.49 (link to patch), otherwise you may experience random crashes at startup".

And AFAIK, most people who compile bitcoin for windows do cross compile. I know several people recently have been on #bitcoin-dev asking how to build it, and ended up giving up and cross compiling in an Ubuntu VM.

At least I build it native on Windows ;).

Added a
#if defined(WIN32) && (!defined(BOOST_INTERPROCESS_HAS_WINDOWS_KERNEL_BOOTTIME) || !defined(BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME) || BOOST_VERSION < 104900)
#warning

That's a good thing, even if it does not look very nice ;).

I don't think looking nice is important in any way here. It is a complex logical expression because we need a complex logical expression.

ACK

I think it is important that this functionality gets added soon. I haven't checked or tested the code though.