First set up your environment variables as described in [Directory Structure
Microsoft Windows](../set_up_build_environments.html#dirstruct).
Run the wxWidgets windows setup, wxMSW-X.X.X-Setup.exe. The project will
build with wxMSW-3.1.2, and will not build with earlier versions. Or just
unzip the file into the target directory, as the install does not in fact do
any useful configuration.
Build instructions are in `%WXWIN%\docs\msw\install.txt` The setup program
for wxWidgets should set the environment variable WXWIN correctly, but does
not do so. Manually set the WXWIN environment variable
When building in Visual Studio, have to retarget the solution to use the
current libraries, retarget to use x64, and change the code generation
default in every project versions from Multithreaded Dll to Multithreaded
(select all projects except the custom build project, then go to
properties/C++/code generation/Runtime). The DLL change has to be done
separately for release and debug builds, since Debug uses the MTd libraries,
and Release uses the MT libraries.
A Visual Studio project needs the library build by the wxWidget Visual Studio
project, an nmake project needs the library built by the wxWidget makefile.vs
If you build roWallet under nmake, using Visual Studio tools, you should
build your wxWidgets libraries using the using nmake – fmakefile.vc, not the
wxWidget Visual Studio project files.
If you build roWallet using the Visual Studio project, you should build your
wxWidgets libraries using Visual Studio and the wxWidgets Visual Studio
project files.
UDP sockets seem seriously under supported and undocumented in
wxWidgets, though theoretically present.
The [discussion](http://www.wxwidgets.org/search/?q=datagrams "wx Widgets Datagrams"),
however, makes up for the paucity of documentation.
wxWidgets somehow neglects to mention that you need to use the
different and entirely incompatible UDP specific system calls, `recvfrom()`
and `sendto()` and instead of `read()` and `write()`
If using C sockets, need to pull in completely different header files on
Unix than on Windows, including Winsock2 rather than Winsock on
windows, but these completely different header files pull in almost the
same routines that work in almost the same way.
```C
#ifdef _WIN64
#include<winsock2.h>
#else
#include<sys/socket.h>
#include<netinet/in.h>
#include<arpa/inet.h>
#include<sys/wait.h>
#include<netdb.h>
#endif
```
If using wxWidgets, need to build with
```c++
#define WXWIN_COMPATIBILITY_3_0 0
#define wxUSE_COMPILER_TLS 2
#define wxUSE_STD_CONTAINERS 1
#define wxUSE_IPV6 1
```
in `%WXWIN%\include\wx\msw\setup.h`
And for gnu builds, `./configure && make && make install`, have to
change them separately and again in configure. What `configure` actually
does is difficult to understand and predict, so I have put asserts in the code
to detect and complain about unsatisfactory settings.
```C++
#ifdef _WIN64
constexpr bool b_WINDOWS = true;
#else
constexpr bool b_WINDOWS = false;
#endif
static_assert( __cplusplus >= 201703l, "Out of date C syntax");
static_assert(wxUSE_IPV6 == 1, "IP6 unavailable in wxWidgets");
static_assert(WXWIN_COMPATIBILITY_3_0 == 0, "wxWidgets api out of date");
static_assert(wxUSE_COMPILER_TLS == (b_WINDOWS ? 2 : 1), "out of date workarounds in wxWidgets for windows bugs");
static_assert(wxUSE_STD_CONTAINERS_COMPATIBLY == 1, "interoperability between stl and wxWidgets broken");
static_assert(wxUSE_STD_CONTAINERS == 1, "wxWidgets api out of date");
```
The two wxWidgets libraries that you build can co-exist because stored in
different directories of `%WXWIN%`. Unfortunately the visual studio build
projects default to the multithreaded dll, which breaks every other library,
because multithreaded, rather than multithreaded dll, is the usual windows
default used by statically linked libraries. so each subproject in the
wxWidgets Visual Studio project has to be changed to link to multithreaded,
rather than multithreaded DLL. This is a bug, or at least an inconvenient
deviation from usual practice, in the current release of wxWidgets.
If built by a visual studio project, the wxWidgets build constructs a header
file in a build location for visual studio projects to use, if built by nmake
under visual studio tools, the build constructs a header file in another
build location for nmake projects to use.
```c++
#ifdef _DEBUG
#pragma comment(lib, "wxbase31ud.lib")
#else
#pragma comment(lib, "wxbase31u.lib")
#endif
```
You are going to have to setup the environment variables %GSL%, %SODIUM% and
%WXWIN% on your windows machines for my visual studio project files to work
and going to have to build libsodium and wxWidgets in Visual Studio.
## Moving a sample from the samples directory
To an unrelated directory tree.
Create an empty desktop project using Visual Studio Wizard. Change the build
type displayed at the top of Visual Studio from Debug X86 to Debug X64
In Solution Explorer (a palette-window of the VisualStudio-mainwindow), click
on the project name, then click on the properties icon, the little wrench,
and then in the left pane of the Property Pages dialog box, expand
Configuration Properties and select VC++ Directories. Additional include- or
lib-paths are specifyable there.
Set General/C++ Language Standard to ISO(S++17) Standard (std::c++17)
Add to the include paths (`properties/configuration properties/VC++
Directories/Include Directories`
```
$(GSL)\include
$(WXWIN)\include\msvc
$(WXWIN)\include
$(SODIUM)\src\libsodium\include
```
Add to the lib path (`properties/configuration properties/VC++
Directories/Library Directories`) the location of the wxWidgets libraries
```
$(WXWIN)\lib\vc_x64_lib\
$(SODIUM)\Build\Debug\x64
```
Set Linker/System to Windows (/SUBSYSTEM:WINDOWS). This is always set to
CONSOLE, for no sane reason, even if you tell it to create an empty windows
project.
Put unit test command line arguments (-dt) in Configuration/Debugging/Command
Arguments.
Add the header, source, and resource files. The C++ option will then become
available in properties. Be mindful that if you edit a wxWidgets \*.rc file
in Visual Studio, Visual Studio destroys it.
Set C/++/Code Generation/Runtime Library to Multi-threaded Debug(/MTd) in
place of multi threaded DLL. When you switch back and forth between release
and debug, this is apt to be set incorrectly, for reasons that are hard to
keep track of.
Set C++/Preprocessor to \_DEBUG, \_WINDOWS, in place of \_DEBUG, \_CONSOLE
for the Debug version, and \_NDEBUG, \_WINDOWS for the release version. If
you compile a release version without defining \_NDEBUG, a flood of mystery
linker error messages ensue, caused by the fact that I use \_NDEBUG to select
library version, which is an improvement on the previous Visual Studio
behavior, where Visual Studio cheerfully generated an executable that
mysteriously just died at runtime because of mismatched libraries.
These instructions lifted wholesale from:\
[Creating wxWidgets Programs with Visual Studio 2017](https://usingcpp.wordpress.com/2018/02/15/creating-wxwidgets-programs-with-visual-studio-2017-part-1/)\
[Hello World Example](https://docs.wxwidgets.org/stable/overview_helloworld.html)
When you add the sqlite3.c amalgamation, make sure to mark it as not using
precompiled headers before the first attempt to compile it, otherwise it
breaks horribly, (C++ format precompiled headers being incompatible with C
precompiled headers) and when you belatedly turn off the precompiled headers,
some data that Visual Studio has generated hangs around, so that turning off
the precompiled headers fails fix the problem.
Similarly, if you do a typo in the include paths. Remains stuck on the old
include paths even if you fix it. To do a real clean, close down visual
studio, delete the directories generated by visual studio, and *then* your
edits to the configuration will propagate properly
wxWidgets for visual studio should be [installed by the windows installer]
(https://www.wxwidgets.org/downloads/), then follow the instructions in
`%WXWIN%\docs\msw\install.md`, after adjusting the visual studio projectg
files to build with multithreaded, rather than multithreaded DLL, for to
avoid DLL hell, we are not building with Microsoft DLLs. Set Project to X64.
Visual Studio resource editor will destroy a resource file that is intended
for wxWidgets. WxWidgets resource files should only be edited in a text
editor.
The native Icon format of wxWidgets is xpm, which does not have built in
support for multiple icon sizes, multiple color resolutions, and partial
transparency. The greenfish icon editor works to convert any icon format to
any other, (though it forgets to include the const qualifier) but, sad to
say, native wxWidgets icons, xpm, are lowest common denominator, therefore,
crap. And xpm format is also crap, a crap representation of crap data, making
windows native bitmap format look good by comparison.
Most of the documentation for wxWidgets is the samples directory, which is
set up to build only in the samples directory. To move a project out of the
samples directory, and get it compiling in the environment you have set up
for your code in Visual Studio, copy the sample, and copy the resources its
needs into your target directory, then correct the sample, so that instead of
looking for resources relative to itself, in the wxWidgets directory, it
looks for its rc file and stuff in its new home directory. You will need the
resource files from the root of the samples, and possibly some files from
samples/images.
Due to a persistent bug in visual studio, probably need to delete the
generated project studio files so that the new values will take effect. Do
not touch \*.rc files with Visual Studio resource editor, or it will break
them.
## wxWidgets on Windows with Mingw
I never succeeded in doing this, so there are probably no end of gotchas of
which I am unaware.
1. [Run the wxWidgets windows setup, wxMSW-X.X.X-Setup.exe]
(https://github.com/wxWidgets/wxWidgets/releases/). The project will build
with wxMSW-3.1.2, and will not build with earlier versions
2. [Build wxWidgets]
(http://wiki.codeblocks.org/index.php/WxWindowsQuickRef). See also the
instructions in wxWidgets-X.X.X/docs/msw/install.txt, or
docs/msw-X.X.X/install.md. CodeBlocks on windows wants you to build in the
Compiled as a separate project under visual studio. Retarget the solution to use the current libraries, retarget to use x64, and change the code generation default (properties/C++/code For the your visual studio project to include the sodium.h file, have to define SODIUM_STATIC before including the header file when linking to the static sodium library.
```h
#define SODIUM_STATIC
#include<sodium.h>
#pragma comment(lib, "libsodium.lib")
```
To link to libsodium.lib have to add `$(SODIUM)\Build\Debug\x64` to Visual Studio/project properties/linker/General/Additional Library Directories, where SODIUM is the environment variable pointing to the root libsodium directory, and similarly for the Release version of your code `$(SODIUM)\Build\Release\x64`. Assembly code is disabled by default, need to re-enable it once unit test works with encrypted utd communication.
We need to eventually re-organize as a git subproject and autotools subproject, but, for the moment, it is a separate library project, hence the environment variable SODIUM.
Might be better to not use environment variables $(SODIUM) and to use Git submodules and autotools submodules instead, was wxWidgets does internally.
Set the libsodium project properties to DebugLib x64
Set the libsodium project properties/General/configuration type to static (should be static already if you have selected Debug Lib and ReleaseLib)
It provides all the crypto algorithms you need, including Argon2 for password stretching, and freedom from NSA. Neglects to include base 58 encoding. Wrote my own base 64 library, which differs from the standard base 64 library in being oriented to small items, addressing arbitrary bit fields rather than blocks of three bytes, in being url safe, and in mapping 0, o, and O to zero, and mapping 1, i, I, and l to one, to allow for human entry.
Going to need an algorithm for generating passphrases, but passphrases will be hashed and argoned,
# Instructions for Sqlite
Sqlite is not incorporated as an already built library, nor as a library at
all, but as source code.
When you add the sqlite3.c amalgamation, make sure to mark it as not using
precompiled headers before the first attempt to compile it, otherwise it
breaks horribly, (C++ format precompiled headers being incompatible with C
precompiled headers) and when you belatedly turn off the precompiled headers,
some data that Visual Studio has generated hangs around, so that turning off
the precompiled headers fails fix the problem.
Similarly, if you do a typo in the include paths. Remains stuck on the old
include paths even if you fix it. To do a real clean, close down visual
studio, delete the directories generated by visual studio, and *then* your
edits to the configuration will propagate properly
[SQLite](https://sqlite.org/index.html)
[Download](https://sqlite.org/download.html)
When creating the database, should turn WAL on:`PRAGMA journal_mode=WAL; PRAGMA synchronous=1;` but before distributing it, make sure the WAL file has been cleaned out with sqlite3_close().
Wal mode ensures that we never get a busy error from normal business, only under abnormal conditions, provided that only one thread in one process ever writes to the the database. Which means we do not face the hard problem of handling the busy error.
We have also chosen our threading model so that database connections and their associated compiled sql statements are thread local, but one database connection can be connected to many databases, and each database can have many database connections from many threads and many processes
Wal mode in the default settings means that writes are normally instantaneous, because they do not hit the disk, but every so often, on completing a transaction, four megabytes get written to disk (which saves a whole lot of read/writes to disk, replacing them with sequential writes without too many reads). So it is probably not a good idea to download large amounts of data from the internet on the UI thread, because every so often the write thread is going to do four megabyes of actual write to actual disk.
In Wal mode, recently “written” transaction data will be read from memory.
So it is a premature optimization to keep data in program memory, when the
same data is probably in Wal memory or in cache.
Because Wal writes are near instantaneous, multiple threads writing seldom
block each other – but if one thread is busy writing while the previous
thread is busy flushing four megabytes of actual data to disk, the Wal file
may grow excessively. According to the documentation, a write thread does the
flushing, but it looks to me that a background thread does the flushing.
But the UI thread will typically only be doing reads and writes every now and
then, so if one has only one continually writing thread, you don’t have to
use restart or full which means you very rarely get busy calls, so do not
have to handle them elegantly and efficiently.
I suspect that the wal file gets cleaned mighty fast, so before doing anything clever, measure.by running `PRAGMA wal_checkpoint` every minute or so, which returns a table of one row and three columns telling you how much stuff needs to be written when the checkpoint started, and how much was going to be written when it completed, leaving another thread working on actually writing it. (Two PRAGMA wal_checkpoints in rapid succession are apt to give the same answer) Also log how long the checkpoint took. If the second column is substantially larger than a thousand, and the third column is kind of small, you have a checkpoint problem. This problem is unlikely to happen, because the disk has a much bigger pipe than the network, so it looks to me that with the usual settings, wal and passive checkpointing, all the actual disk write IO is going to take place in a backround thread, because we are just not going to be disk bound on updates and writes. We may find ourselves disk bound on random access reads, but Wal, transactions, and checkpoints are not relevant to that problem.
```bash
del C:\Users\studi\AppData\Local\RoBlockchain\RoData3cx8bdx.sqlite
Name TEXT NOT NULL UNIQUE, – automatically creates index
PetName TEXT,
title TEXT
);
CREATE TABLE MasterSecret(
PublicKey BLOB PRIMARY KEY NOT NULL UNIQUE,
Secret BLOB,
Expires INTEGER NOT NULL,
FOREIGN KEY(PublicKey) REFERENCES w(PublicKey)
);
INSERT INTO w VALUES(X'deadbeef','Adam',NULL,NULL);
.dump
.output RoData3cx8bdx.sql
.dump
.exit
```
We are stashing everything in the user specific directory `wxStandardPaths::GetAppDocumentsDir()`
and the user specific database, which is wrong. Eventually we will need two databases, one global to all users on a particular machine, which you select when you install, and one for each particular user, that gets generated when the particular user first runs his wallet.
Further confusing matters, wxConfigBase settings are always per user on windows.
At the moment, only one database and one config object.
In our own code, we don’t need to issue `PRAGMA synchronous = 1; PRAGMA
foreign_keys = ON;` because we modify the sqlite3.c with the following:
I need to customize the sqlite3.c almalgamation with my own custom compile options as follows.
```C
//My custom compile options
#define SQLITE_DQS 0 //Doublequote names, single quote strings. This setting disables the double – quoted string literal misfeature.
#define SQLITE_THREADSAFE 2 //One thread, one database connection. Data structures such as compiled SQL are threadlocal. But sqlite3 is empowered to do its own multithreading. Many databases per database connection. Database connection and compiled sql statements are threadlocal. last_insert_rowid() is not subject to race conditions in this mode, returning the most recent rowid generated by the thread.
#define SQLITE_DEFAULT_MEMSTATUS 0 //Don’t track memory usage. Disables the ability of the program using sqlite3 to monitor its memory usage. This setting causes the sqlite3_status() interfaces that track memory usage to be disabled. This helps the sqlite3_malloc() routines run much faster, and since SQLite uses sqlite3_malloc() internally, this helps to make the entire library faster.
#define SQLITE_DEFAULT_WAL_SYNCHRONOUS 1 // in WAL mode, recent changes to the database might be rolled back by a power loss, but the database will not be corrupted. Furthermore, transaction commit is much faster in WAL mode using synchronous=NORMAL than with the default synchronous=FULL. For these reasons, it is recommended that the synchronous setting be changed from FULL to NORMAL when switching to WAL mode. This compile-time option will accomplish that.
#define SQLITE_DEFAULT_FOREIGN_KEYS 0 //Dont handle foreign key constraints. Programmer has to do it himself.
#define SQLITE_LIKE_DOESNT_MATCH_BLOBS 1 //Blobs are not strings. Historically, SQLite has allowed BLOB operands to the LIKE and GLOB operators. But having a BLOB as an operand of LIKE or GLOB complicates and slows the LIKE optimization. When this option is set, it means that the LIKE and GLOB operators always return FALSE if either operand is a BLOB. That simplifies the implementation of the LIKE optimization and allows queries that use the LIKE optimization to run faster.
#define SQLITE_MAX_EXPR_DEPTH 0 //Setting the maximum expression parse-tree depth to zero disables all checking of the expression parse-tree depth, which simplifies the code resulting in faster execution, and helps the parse tree to use less memory.
#define SQLITE_OMIT_DECLTYPE 1 // By omitting the (seldom-needed) ability to return the declared type of columns from the result set of query, prepared statements can be made to consume less memory.
#define SQLITE_USE_ALLOCA 1 //Make use of alloca() for dynamically allocating temporary stack space for use within a single function, on systems that support alloca(). Without this option, temporary space is allocated from the heap
#define SQLITE_OMIT_LOAD_EXTENSION 1
#define SQLITE_TEMP_STORE 3 //Temporary files are in memory
#define SQLITE_OMIT_AUTOINIT 1 //.The SQLite library needs to be initialized using a call to sqlite3_initialize() before certain interfaces are used.This initialization normally happens automatically the first time it is needed.However, with the SQLITE_OMIT_AUTOINIT option, the automatic initialization is omitted.This helps many API calls to run a little faster(since they do not have to check to see if initialization has already occurredand then run initialization if it has not previously been invoked) but it also means that the application must call sqlite3_initialize() manually.If SQLite is compiled with – DSQLITE_OMIT_AUTOINIT and a routine like sqlite3_malloc() or sqlite3_vfs_find() or sqlite3_open() is invoked without first calling sqlite3_initialize(), the likely result will be a segfault
//end my custom compile options*/
```
[To compile the standard sqlite3.exe tool](https://www.sqlite.org/howtocompile.html).
We don’t need to issue `PRAGMA journal_mode=WAL; PRAGMA schema.synchronous
= 1;` in our own code except if we create a new database, which our code will
typically not do, because our install will copy a working database.
In our code, we do need to issue `PRAGMA optimize;` on close.
Missing from their short summary of the C interface is:
```C
/*
** Return UTF-8 encoded English language explanation of the most recent
The general rule being that for any unexpected value of rc, any value other than `SQLITE_OK`, `SQLITE_ROW`, and `SQLITE_DONE`, display that message. `sqlite3_exec` wraps this, but we should probably not use `sqlite3_exec`.
SQlite’s pragma for identifying that something is the right application file format does not seem to work, or maybe it does work and there is some magic that I am not aware of. But this does not matter, because it only protects against Murphy, not Machiavelli, and we are going to need to guard against Machiavelli.
We need to make sure that compiled sql statements are only compiled after the database connection is live, and destroyed before the database is closed.
The order of construction and destruction within an object is
- First, and only for the constructor of the most derived class as described below, virtual base classes shall be initialized in the order they appear on a depth-first left-to-right traversal of the directed acyclic graph of base classes, where “left-to-right” is the order of appearance of the base class names in the derived class base-specifier-list.
- Then, direct base classes shall be initialized in declaration order as they appear in the base-specifier-list (regardless of the order of the mem-initializers).
- Then, non-static data members shall be initialized in the order they were declared in the class definition (again regardless of the order of the mem-initializers).
- Finally, the compound-statement of the constructor body is executed. \[ Note: the declaration order is mandated to ensure that base and member subobjects are destroyed in the reverse order of initialization.
Objects on the stack are destroyed in the reverse of the order that they were declared.
The gui object that enables the user to manipulate the contents of the database should contain the database connection, and the compiled sql objects that manipulate the database, declared in that order, so that they get destroyed in that reverse order, compiled sql being destroyed before the database connection is destroyed, and so that in order to create the gui to manipulate the database, we have to first construction a database connection. Since the creation could throw, and we need to handle the throw in the gui, we need a gui already constructed, which then attempts to construct more gui, and informs the user if the construction fails.
So the outer gui figures out a plausible database name, and then attempts to construct the inner gui whose constructor then attempts to open a database connection and make sure the database is in a good state, and throws if it cannot construct a good connection to a good database.
To protect against Machiavelli, peers have to by default check the early part of the block chain to make sure it has the correct hash, preferably in obfuscated and undocumented code, accessed through a define located in a rather random header file so that Machiavelli will have to audit my code, then supply his victims with the new code as well as the new database. Or just hard code the genesis block, though Machiavelli will have an easier time finding that one. Maybe both. Hard code the genesis block, and have obfuscated hard code for the early blocks.
