Windows 10 1511 includes both a 64-bit and 32-bit version of SQLite called:
C:\Windows\System32\winsqlite3.dll C:\Windows\SysWow64\winsqlite3.dll for the 64-bit and 32-bit versions respectively. The version of SQLite contained in these libraries is: 2015-02-25 13:29:11 9d6c1880fb75660bbabd693175579529785f8a6b SQLite version 3.8.8.3 2015-02-25 13:29:11 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent database. If I use that version of the amalgamation, I cannot seem to compile a working version of the client that will use it -- it crashes as soon as any command is issued. > -----Original Message----- > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- > bounces at mailinglists.sqlite.org] On Behalf Of Scott Robison > Sent: Saturday, 14 November, 2015 11:51 > To: SQLite mailing list > Subject: Re: [sqlite] "Shipping a New Mindset" - SQLite in Windows 10 > > On Fri, Nov 13, 2015 at 11:55 PM, Stephen Chrzanowski > <pontiac76 at gmail.com> > wrote: > > > Prior to release or otherwise, it feels that if MSoft were to have > skipped > > the registry and just used the GROUP->KEY=VALUE setup in INI files only, > > things would be much better as far as cleaning up viruses at LEAST, > > especially if you start locking down these files at the NTFS level. But > > then again, if they used an actual SQL system (Like their own) for > managing > > registry entries, things would be so much easier with a DELETE > statement. > > Individual programs could have their OWN "registry" file instead of crap > > ending up all over the place. Backing up an entire application would be > a > > snap as relevant entries pointing at specific DLLs would come with the > > application base or at least configured upon install...... Ohhh the > mind > > is wandering. > > > > Perhaps a bit off topic, but: > > At my day job, we write software for backup / disaster recovery of Windows > partitions, including virtual boot of previously physical environments. As > a result, we have to do a bit of registry manipulation. Our software > targets both Windows and Linux systems. > > When we need to manage a registry hive from Linux land, we use a LGPL > library called hivex. > > When we need to do that in Windows, historically we had to load an offline > registry hive into the running registry, make whatever changes were > needed, > then unload the file. > > I recently discovered a redistributable Microsoft DLL called "offreg" for > offline registry access. It avoids (in Windows) the need to attach an > offline hive to the online registry. > > For Windows applications that have a need for registry files, offreg.dll > (combined with hivex for cross platform compatibility) greatly simplify > registry maintenance. I wrote a wrapper around offreg.dll to make it > source > compatible with hivex (which we were already using) so that future > projects > wouldn't need quite so much "#ifdef WINDOWS" style code. > > If a windows app was bound and determined to use a registry style > datastore, offreg.dll could provide a lot of the benefits outlined above. > Still no SQL interface. > > Hmmm, maybe a VFS or virtual table for SQLite... > > -- > Scott Robison > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
