From what I've seen of the project, the current LevelDB reduced ram branch could be pretty functional in 32 bit Windows, including XP

Sounds good. I will build the lib with ASIO and perform tests with and without. If it turns out to be significant in speed and/or portability, I will keep it.

Quick Update:

OpenAL isn't open source anymore. It's mainly maintained under a proprietary license for Windows only. There is a fork of the original implementation that's somehow maintained but I've decided to move on to PortAudio, an open source cross platform audio library.

PortAudio comes with built in ASIO support, which is a low latency cross platform audio driver under a proprietary license. However the SDK and drivers are free to download and use, and the license is free of fees and royalties. They essentially only ask to be mentioned and have their logo added to product boxes and websites.

If that's not ok, I'll dump ASIO. However I think it would allow easier cross platform deployment to have a unified driver. Waiting on your input.

5-10% would pay for the packet headers and CRC overheads, I'd be fine with that. Snappy is overly way too easy to implement to just pass on that.

Regarding bit rate, I just setup a second PC in my room. Expect some results in a week or 2, depending on my schedule.

It's entirely possible to secure the channel however. My primary intention was to compress the data to be sent and uncompress it on the other side, since the bottleneck is channel bandwidth rather than CPU cycles, however, it could be used without compression and a SSL handshake kind of setup to secure the channel. That would be kinda slow however.

2 wires may not be necessary in some cases. I can reassign audio sockets on my sound card and this has been the case since quite a while with the advent of Realtek sound cards integrated to mobos. This is no priority of mine but I definitely intent to look into it.

It would allow for 2 ways simplex data transactions over a single line, and I think it will be feasible with most audio hardware. From my experience with MCUs, pins that are connected to the PWM output or the DAC can also be used as ADC, even on ancient 8 bit MCUs. It's only a matter of driver at this point. It would require some system calls which will result in portability nightmares but it's a viable long term goal.

I don't think the over the air data link is unfeasible, however it would be yet another nightmare to setup and way too much work when one can simply plug in a double ended wire across a couple PCs. All portable devices I've seen (tablets, smart phones, mp3 players, even portable gaming consoles) have an audio input and output port, so this approach fits long term, wide range portability as well. That and over the air would be considerably slower. I think people would prefer to take the 2 minutes it takes to plug a couple wires with an extra 5 minutes of transfers over instant setup and 30 minutes worth of audio torture.

Let me get this clear, is this bounty for an open air audio data channel or a wired one? I only intent to develop one that works by plugging both computers sound cards to each over with a couple of double ended wires

If the 25 BTC is still standing, I'd like to take a shot at this. I'm considering building a lib from the grounds up in C++ with OpenAL.

You can't install msvc11 on WinXP, you need .NET Framework 4.0, which is only compatible with Windows 6.0 (Vista) and above. I have built the LevelDB port using the WinXP tool, but haven't tested it. There are instructions for WinXP deployment with the port I sent you.

Finished building armory with latest version of LevelDB on msvc11. There are code files and instruction files to pass on, as well as some implementation specifics to discuss, maybe we should proceed in private messages so as to not bloat this thread any further.

I've just successfully compiled my own take at LevelDB on MSVC. I need to bench it, test the x64 build and write a guide so that you can upgrade the project with newer versions as they come.

It's late now and I won't be around on Saturday nor for the best part of Sunday. Expect delivery at best on Sunday night.

I'm glad to hear the Windows build went through properly.

Regarding the speed issue and LevelDB: I suspect it's due to the implementation of atomic types and routines used in leveldbwin. That project is made for msvc 9 and 10, which don't support atomics and as such rely on full memory barriers and software mutexes, which are considerably slower than atomics. LevelDB is natively a C11 POSIX library.

I am going to try building the port folder on msvc11, with native atomics support. As I said before, I suspect compiling this part is all it'll take to get any version of LevelDB to build properly.

Regarding py2exe: I have no experience with Python, however Windows development is all about DLL compartmentalization, i.e. maintaining the armory core and the Python GUI part separately. I didn't get the impression that this is what SWIG does. I'd assume if there was a way to simply link the Python code to DLL binaries, it would considerably simplify the py2exe part, by limited its scope to the GUI code and an exporting header of sorts. Then again I may be totally out of my league and talking out of my a**.

Possibly. I never do that, I just link the include folder.

That's odd, i had to link atl.lib to it. Regardless, as long as it's built, the rest is irrelevant.

Ok my bad the global include folder registering through msvc GUI seems to be limited to pay versions. Have to do it through the registry.

Windows Search is based on preindexation performed by a back-end service. New folders may not be parsed right away in the temporary db.

You have to indicate both header and lib folder to msvc unless you install a pay version. You can register these folders globally in msvc options rather than just link them to each of your projects. Not sure how it's done is vc11 express. Ima look it up

C:\WinDDK\7600.16385.1\inc\atl71 -> this is my include folder for all header files
C:\WinDDK\7600.16385.1\lib\ATL\i386 -> this is where the libs are. I picked i386 cause leveldbwin only support x86. However x64 binaries and libs are available if you wanna try a x64 compile.


I'm curious about your install folder, namely its build version (mine is 7600.16385.1 as you can see)

Edit: I'm redownloading the wdk iso to check the installation process. Did you perform a custom or full install? There's only one option needed to install ATL binaries and headers

Regarding LevelDB, I haven't looked at the source too much, however it seems evident that all the system resource and OS talking LevelDB requires is performed by a separate piece of code, confined to the "port" folder of LDB's source. Of what I've seen, it handles threading, atomicity, file access, getting the environment, setting variables and, I suspect, whatever else there is to do on that front. My intuition on this is that as long as you get a proper compile of "port", all the code inside the leveldb/leveldb folder (the db related classes) will compile without errors.

It is true that I don't like leveldbwin's approach, using ATL and  MS's interlocked memory functions to provide environment and atomicity. Ideally you'd like to compile a dll on MS systems, and support x64, so a in house compilation seems like a better long term option. LevelDB uses pthreads, which is easy to compile on msvc, as well as atomics, which vc11 supports natively. I think it won't be too hard to get a proper build going for Windows. I'll be around if you need assistance with that.

As for the bounty, this is my address: 1KPsKCA1VrGdnKqQgrSKZ5M2sEZRP1oUFX

Thank you for contributing to my hookers 'n blow fund =)

Gratz on the investor, I hope armory will grow into an even better wallet software. I personally hope you'll implement a mod/add-on system to allow side devs to bing in their own small contribution.

I ended up helping at the very moment my help wasn't required anymore. Story of my life =P.

I have successfully compiled the ramreduceleveldb branch on vc11 x86 (msvs2012 express). The method outlined can be reproduced on vc9/10 (msvs 2008/2010) with no extra changes to either projects (leveldbwin and armoryengine_msvs2005). Keep in mind that to since the compile relies on a library compilation of leveldbwin, you need to compile armory with the same compiler as you used for leveldb. (Don't go around building leveldb with vc9 and then linking it to an armory project built with vc11)

Note: this is a compile of armoryengine_msvs2005 project only, not the SWIG to python part, which is trivial in this case from what I understand of the project (i don't know squat about python and swig). The compile is untested, I simply went as far as yielding a ArmoryEngine_MSVS2005.dll (no main declared in this branch)

Step #1: leveldb

Grab leveldbwin from the google project page: https://code.google.com/p/leveldbwin/

1) Pick the project of your liking in the build folder (msvc9 or msvc10). I used msvc10 and converted the project to msvc11 since this is my compiler.

1.a) To compile you need ATL. If you're using an express version of msvc, you'll have to install WinDDK 7.1 (Driver Development Kit): http://www.microsoft.com/en-us/download/details.aspx?id=11800. Make sure you grab 7.1 and not 8.0 or WinSDK as those do not support ATL anymore. Skip this step if you have a pay version of msvs.

2) In the configuration manager, pick Release (for the static lib compilation). Don't bother compiling test, you don't need it. I used snappy for compilation, so no defines to drop at this point.

3) Right click each project (leveldb and snappy), go to "Config properties -> C/C++ -> Code generation". Make sure Runtime Library is set as Multi Threader (/MT). This defines whether the C librairies used to compile are statically or dynamically linked. My understanding of this project is that you'd rather not distribute msvc runtime binaries so stick to static compile.

4) Rebuild the project, pick up leveldb.lib in ./_exports/Release and shove it where you want to have it for the armory compile (either make a new folder for it or directly link to it from the project)

Step #2: Armory

Here is the list of all the modifications I did to the code and the project to get it to compile:


Note: I first tried to dynamically link leveldb to armory, but it failed to export leveldb::DestroyDB properly. The issue disappeared with the static link so I stuck to that for now. On top of that leveldbwin has no x64 build setup, so I'll consider making my own compile of leveldb to allow for dynamic linking and x64 releases.

There are about 100 warnings, 90% of them are related to possible data loss due to assignment without type casting. The rest seems to be msvc complaining about unsafe routines. Both cases are irrelevant.