We could also use transactional NTFS to avoid data corruption on unexpected system crashes, however, unfortunately, Microsoft corporation has deprecated it. From their website:

TxF was introduced with Windows Vista as a means to introduce atomic file transactions to Windows. It allows for Windows developers to have transactional atomicity for file operations in transactions with a single file, in transactions involving multiple files, and in transactions spanning multiple sources – such as the Registry (through TxR), and databases (such as SQL). While TxF is a powerful set of APIs, there has been extremely limited developer interest in this API platform since Windows Vista primarily due to its complexity and various nuances which developers need to consider as part of application development. As a result, Microsoft is considering deprecating TxF APIs in a future version of Windows to focus development and maintenance efforts on other features and APIs which have more value to a larger majority of customers. The next section describes sample alternative methods to achieve similar results as TxF would for several types of application scenarios.

We could use one of the following alternatives, as suggested by the Microsoft corporation:

Applications updating a single file with "document-like" data: Many applications which deal with "document-like" data tend to load the entire document into memory, operate on it, and then write it back out to save the changes. The needed atomicity here is that the changes either are completely applied or not applied at all, as an inconsistent state would render the file corrupt. A common approach is to write the document to a new file, then replace the original file with the new one. One method to do this is with the ReplaceFile API.
Applications managing a set of structured data: Many applications manage some set of proprietary data structures of varying types as a means to store data. A significant challenge for these applications is the process of maintaining the integrity of internal pointers/references if a failure occurs during an update operation. Creating the mechanism for this is indeed a "hard problem", and therefore most applications will rely on a true database server to manage their dataset.

Two suggestions to help manage structured data are:

Microsoft provides the Extensible Storage Engine (ESE) inbox in Windows to enable applications to perform transacted data update and retrieval operations. For more information on the Extensible Storage Engine (ESE), please see https://msdn.microsoft.com/library/gg269259.aspx.
For applications that require a more powerful, robust, and scalable database provider, it is recommended that customers consider using the Filestream feature available with Microsoft SQL Server. For more information on SQL Filestreams, please see https://technet.microsoft.com/library/bb933993.aspx.

I may be able to implement this, but be aware that I don't have a lot of experience in enterprise development

I may be able to implement this, but be aware that I don't have a lot of experience in enterprise development, so this might require some code and architecture review

I have seen roadblocks like this kill perfectly good projects. Please code directly in Prod.

I may be able to implement this, but be aware that I don't have a lot of experience in enterprise development, so this might require some code and architecture review

I have seen roadblocks like this kill perfectly good projects. Please code directly in Prod.

I don't have access to the production (uinverse) branch.

#694

It appears that c++ is simply too slow for our applications. It pains me to say that we will have to rethink this as a custom FPGA or if demand allows our own custom silicon. I have contacted TSMC: they have given me a 200 year lead time to get on their sub quantum node. ASML have been dragging their heels on making the lithography machine required and have given such asinine excuses "it is not physically possible".
I will keep you posted

• Steve from accounting

It appears that c++ is simply too slow for our applications.

This can't be true. C++ is a blasingly fast and (if used correctly) memory safe programming language.