DB Browser for SQLite 3.9.1 compatibility with Windows XP (32 bit) (SOLVED)

@h1618

Details for the issue

An attempt to open the installed DB Browser for SQLite v.3.9.1 in the Windows XP (32 bit) environment returns error "DB Browser for SQLite.exe is not a valid Win32 application"

Useful extra information

Since the original topic #893 "was locked and limited conversation to collaborators on 27 Feb", but there are still noob users like me and #986 around, that just wish to adopt DB Browser for SQLite 3.9.1 to their beloved Win32 XP machines, hereby I will provide you with easy to understand "entry-level" solutions to this issue.

@h1618

if you are able to operate a hexeditor, just changing offset 0x40 and 0x44 of the sqlitebrowser.exe executable from 0x0006 (Vista) to 0x0005 (XP) is all that's needed

Unfortunately I couldn't figure out how to perform or calculate location for those manipulations, so this link to the image file with the screenshot of hex-code comparison between unpatched (left) and patched (right) files should give you an idea of what exactly is it there to be changed and where it is located within a hex editor: http://www.hadrurus.com/andiutils/DB4S/SQLite3.9.1HexPatch.jpg

or

@karim

A quick solution is by editing the .exe file using editbin and change the subsystem right after building it.

I didn't want to seek and install all of Microsoft Visual Studio, so for this method you should go to: http://www.hadrurus.com/andiutils/DB4S/EditBinPack.rar and download:

EditBinPack.rar

Then extract all files contained in EditBinPack.rar archive to the folder with the installed DB Browser for SQLite (in Windows XP usually at C:\Program Files\DB Browser for SQLite) on your PC. Now [Start] > [Run] > {type} CMD > [OK] > {type} CD\ {Enter} > {type} CD PROGRAM FILES\DB BROWSER FOR SQLITE {Enter} and finally {type}:

EDITBIN DBBROW~1.EXE /SUBSYSTEM:WINDOWS,5.01 /OSVERSION:5.1 {Enter}

After that manipulation is done, check your "DB Browser for SQLite.exe" for runnability, and if all is OK, you're set to use program as usual.

At last, just like me, enjoy latest DB Browser for SQLite v.3.9.1 on your Windows XP!

P.S. I could provide here a link to the patched file itself, and this way it would be even easier to just substitute one file with another, but I am not sure whether I am allowed to do so here.

I'm opening this issue because:

DB4S is crashing
DB4S has a bug
DB4S needs a feature
DB4S has another problem

I'm using DB4S on:

Windows: (XP Prof SP3 version: 5.1)
Linux: ( distro: ___ )
Mac OS: ( version: ___ )
Other: ___

I'm using DB4S version:

3.9.1
3.9.0
Other: ___

I have also:

Tried out the nightly version: https://github.com/sqlitebrowser/sqlitebrowser#windows
Searched for an existing similar issue: https://github.com/sqlitebrowser/sqlitebrowser/issues?utf8=%E2%9C%93&q=is%3Aissue%20

If I could hug you, I would. Some valuable information there. I looked into manipulating the .exe file and various PE editors, but none really explained what to change.

I couldn't see your photo/screenshot though - your link just takes me to a page which says, "Only logged in users can see this profile". You can copy and paste the image here, or if you email it to me (db4s [at] chrisjlocke.co.uk) I can host it / paste it here.

Thanks again for posting a solution - useful for making the nightlies XP compatible - they are better versions than the v3.9.1 version (as a lot has changed since that release)

@chrisjlocke

Hey, @chrisjlocke! You are welcome! I felt very happy too, when both solutions worked. ) OK, I'll try attaching the image with the 1st solution to this comment. Let's see if it works. Once again:

Original file's hex-code is on the Left | Patched file's hex-code is on the Right.

(btw, if you would have time, please comment here whether it works for nightlies)

So is that always in the same place, or does it depend on how its been compiled?
The 'editbin' method you posted seems the easiest. I'll try on last nights nightly. I've an XP VM, so will try in that.
Thanks for posting the screenshot. 😸

I am not sure whether during compilations data in the PE header is always written into exactly the same addresses, as yet I have no experience in this at all. But I think with basis given by the screenshot next time it would be easier to spot the location of wanted data (at least I would have an idea about what am I looking for). To the 'Hex' method I actually came from executing 'EditBin' method, and then replicated changes performed by editbin.exe manually in my hex editor. So I agree with you that 'EditBin' method looks more reliable and sounds like the correct one. As I've read further, it looks that there are differences in link.exe files and that newer generations of that file won't let editbin.exe to set a version prior to what was limited in its code by Microsoft, instead saying something like "LINK : warning LNK4241: invalid subsystem version 5.01". Again, I might be wrong. Anyways, the link to the three files I gave in method 2, do allow to write a program's OS compatibility to subsystem 5.01. The correspondent option would be:

editbin.exe "$(TargetPath)" /SUBSYSTEM:WINDOWS,5.01 /OSVERSION:5.1

Like I said before, I am totally noob in programming, though sometimes I manage to put some parts of puzzles together, and even in this comment I mostly rely on the information obtained from: https://supportxpdotcom.wordpress.com/2012/03/30/editbins-dirty-little-secret

Didn't work for me.

As an alternative idea for our nightly builds, this is (a copy of) the batch file we use for building the Windows ones:

https://gist.github.com/justinclift/11cc926f214e882c8162f97c53929c07

If someone can suggest a change to it which would add XP support, that'd be completely welcome. 😁

After changing '06 00 00' to '05 00 01' in the guts of the program, it threw up another error.

...and failed to run.

Edit: Minimum supported client: Vista.

https://msdn.microsoft.com/en-us/library/windows/desktop/dd318139(v=vs.85).aspx

@chrisjlocke

@chrisjlocke, I really don't know where did you get it and why did you use that command shown in your CMD prompt screenshot, i.e:

link "DB Browser for SQlite.exe" /subsystem:windows, 5.01 /osversion:5.1

as I've never suggested that. It is totally wrong! Though I must agree that my syntax explanation could be a bit complicated...

So next I'll post a series of screenshots, to make sure that you know exactly what to do (what I was doing), without extra strange symbols in my syntax. I won't even rename "DB Browser for SQLite.exe" for anything else, as I have suggested earlier, so that you see step-by-step exactly how it happens.

Original installation error notice:
Pack of 5 files for EditBin's smooth run, though I don't think that mspdb100.dll is necessary. All of these files have been copied to "DB Browser for SQLite" installation folder:
Step-by-step in CMD until successful patch. Watch attentively, all MY lines start with C:\:
Success story:

As for method 1 try these substitutions in hex instead, let's see if it works (works on mine flawlessly):

Also on my Windows XP SP3 I am able to switch languages inside DB Browser for SQLite v.3.9.1 with ease, and without any errors on restarts. (

I really don't know where did you get it and why did you use that command shown in your CMD prompt screenshot, as I've never suggested that. It is totally wrong!

Oh, I took it from your instructions. Oops. 😕

Mm, sorry, I cannot see a single instance of "editbin.exe" in your screenshot, I see word "link" instead. Well, it doesn't matter. I've supplied the more clear example of EditBin use, without any of that somewhat confusing syntax. Also, I think that one cannot run commands on long filenames in CMD environment, that is why I suggested to use short name at first. Short name for DB Browser for SQLite.exe would be DBBROW~1.EXE

Doh. Good point. Oops. 🔫

@andisys

@andisys Thanks, that's awesome. I'll update our release notes, as I just made the 3.10.0 release announcement official, but said XP doesn't work.

For that Permission Denied error... that's weird. I do seem to remember someone saying XP can have trouble connecting to things via https. Maybe it's something to do with that?

@andisys

@andisys Thanks for testing this. I couldn't test it cause I have only SP2 image and I had problems finding SP3 download. That little error is DB4S checking for a newer version on startup. You can disable "Automatic updates" in "Preferences" to get rid of it if it is annoying you.

@justinclift You are correct. This error has something to do with Win XP and HTTPS access. Some say it doesn't work. Others say the certificates that comes with it are all old and expired. Also explains the other error that @chrisjlocke got while testing too.

Version 3.10.0 installed, launched and ran fine on my WXP SP3. Now I am muting the thread, thank you. (though it is said to be a 'closed' thread - go figure!?

@justinclift

@justinclift @andisys @karim In a virtual machine with XP SP3 (with POSReady updates) I don't get any startup error and all seems to work fine even with the "Automatic updates" enabled. Maybe the POSReady updated the needed certificates?

On the other hand, it installs fine but fails at launch in a real machine with XP SP3 using an AthlonXP CPU (which lacks SSE2 support and that I guess is the problem, since a few now the default compilers options now seems to use SSE2 unless explicitely disabled)

This same version also seems to work fine in W7-64bit

@JoeErsatz

@JoeErsatz Thanks. 😄

@lulol Awesome. 😄 I'd heard it was possible to make a WinXP install look like the embedded POS version, and keep getting updates. Didn't realise it was such a simple 1 liner registry change.

Hmmm, with that lack of SSE2 support... reading the doc here, yep it has this:

Because the x86 compiler generates code that uses SSE2 instructions by default, you
must specify /arch:IA32 to disable generation of SSE and SSE2 instructions for x86
processors.

Wonder if it's useful for us to do the Win32 build using /arch:IA32? Should be pretty simple to test out, and it sounds like it could solve that particular problem.

@justinclift

@justinclift @karim May be /arch:SSE is enough since were already available in the Pentium III or AMD K7 from the W98SE ages?

Anyway if there is going to be a specific DBS4 XP version better to have it as vanilla as possible since probably someone still running XP is not going to need/expect high performance.

I guess that people using XP run it in a VM or old cpus so I think that is a good idea to have an extra Win32 build if maintaing it is going to be less of a hassle than the DBS4 XP version just not working since these errors are quite cryptic.

A note about the "simple" POSReay registry tweak, so far seems to work well but can be tricky if not done carefully. Anyone trying it need to be careful to get it right the first time since these registry keys are write-once and will survive a system restore. To undo the changes it's necessary to restore the registry files from backup or the full VM.

Yeah. Anyone using Win32 probably doesn't have demanding requirements, so we can have the Win32 build be as widely compatible as possible. No real need for a separate XP compatible thing again. 😄

Hmmm, actually getting this to happen though is looking like it's not so straightforward after all. 😦

Adding an /arch:SSE option to the "cl.exe" line was easy and didn't complain (just tried it), but we'll need to figure it out for CMake too, which does the make project build.

This looks relevant:

https://stackoverflow.com/questions/31091964/cmake-remove-archsse2-for-visual-studio-2013

That'll probably be the right direction to investigate with.

For SQLCipher support, we'll need to figure out where to add that arch option in the Makefile.msc.

Probably somewhere in here, but haven't tried it yet.

Not sure if I can really be bothered attacking this at the moment. Kind of feeling like getting away from the computer for a bit, but will see how it goes. 😄

Reading the CMake wiki, I wonder if won't be enough adding the compile options just somewhere in CMakeLists.txt along the other options. Shouldn't be propagated to both SQLCipher or SQLite?

Something like this for MSVC compiler:
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /arch:SSE")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /arch:SSE")

for other compilers:
set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} "-msse")
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} "-msse")

Unfortunately I can't try it. :(

Did the portable version of 3.10.1 fall through the cracks? Doesn't work on XP.

Oh well.

Ahhh yeah. From memory, the Portable version doesn't support XP. If you ping the PortableApps people, they might be able to fix that. 😄

On the other hand, it installs fine but fails at launch in a real machine with XP SP3 using an AthlonXP CPU (which lacks SSE2 support and that I guess is the problem, since a few now the default compilers options now seems to use SSE2 unless explicitely disabled)

Oh........... no wonder I can't get 3.9.1 or 3.10.x or any later QT 5.7 build to work. I was working on a Pentium III running Windows XP SP3 32-bit. I wish Windows XP SSE2 (P4 and later) was clarified up front. Would have saved me a lot of time. It errors out with two windows of "The application failed to initialize properly ...." Not very informative.

Guess I'll start digging through the older versions... maybe.

Tried 3.8.0, 3.7.0, 3.6.0 -- all no go with the same messages. Then gave up and decided to sick with SQLiteStudio 2.1.5.

@juanitogan

@juanitogan Did you try any of those in the nightlies tree?

The last working version I have installed after this in my ancient real machine running XP SP3 is a nightly version 3.9 with Qt 4.8.7 from 2016-10-01 that seems it's now missing from the nightlies archives.

Looking in the assets for v3.9.1, there is a specific XP build.
https://github.com/sqlitebrowser/sqlitebrowser/releases/download/v3.9.1/DB.Browser.for.SQLite-3.9.1v2-winXP.exe

Is that any good?

@lulol

@lulol Thank you for the link to #559. That is right on target. Looks like I stopped just short of finding an SSE1 build.

To somewhat answer the performance question there about SSE2, it is not likely anyone would have missed any SSE2 boost had they continued to compile to just SSE1 or lower. SSE grew out of 3DNow! and MMX and, thus, primarily boosts graphics-intensive programs (and other real-time massive number movers). I'm not an expert at SSE performance but my gut says most business apps don't need it. 7-zip, for example, still builds without SSE2 (but not sure what, exactly, but it runs on a P3). Even the latest IrfanView, somehow, still works on a P3. The current web browser mods for XP, however, tend to build for IA32, SSE, and SSE2 so you can grab what you need to squeeze every last drop out the graphics-heavy web.

But, that's all water under the bridge. I'm not here to ask anyone to go back and rebuild (which I could do on my own if I really had the need to). Like you said in your other post, I'm mostly here about messaging and letting others know that what is called XP compatible here is not fully XP compatible. The vague note they added before about old Windows OSs to the readme is no longer there. Regardless, this project could be more clear about where XP ends (3.5.1, I guess) and where XP SSE2 (P4 and later) ends (3.11.2, I'm guessing, due to that being the last version with Qt 5.7). Hence, why I was recording what does and doesn't work here -- in case someone thinks it is worth documenting in the readme and release notes and/or wants to open an issue for it.

Thank you, also, for the link to the nightlies archive. If I find time again, I might dig into it to find the last of the 3.11.x builds there to see if they were still building for SSE1 at that time. But I doubt I will. My need for examining/editing SQLite DBs on XP is pretty small and the other tool suffices fine (it's about having a no-budget laptop with built-in COM and LPT ports in this case). I was just in a mood to look for something a bit better at the time I dug into this.

Navigation Menu

Repository navigation

DB Browser for SQLite 3.9.1 compatibility with Windows XP (32 bit) (SOLVED) #1010

Details for the issue

Useful extra information

I'm opening this issue because:

I'm using DB4S on:

I'm using DB4S version:

I have also:

90 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

DB Browser for SQLite 3.9.1 compatibility with Windows XP (32 bit) (SOLVED) #1010

Description

Details for the issue

Useful extra information

I'm opening this issue because:

I'm using DB4S on:

I'm using DB4S version:

I have also:

Activity

chrisjlocke commented on May 11, 2017

andisys commented on May 11, 2017

chrisjlocke commented on May 11, 2017

andisys commented on May 11, 2017

chrisjlocke commented on May 11, 2017

justinclift commented on May 11, 2017

chrisjlocke commented on May 11, 2017

andisys commented on May 11, 2017

andisys commented on May 11, 2017

chrisjlocke commented on May 11, 2017

andisys commented on May 11, 2017

chrisjlocke commented on May 11, 2017

90 remaining items

justinclift commented on Aug 19, 2017

karim commented on Aug 20, 2017

JoeErsatz commented on Aug 20, 2017

lulol commented on Aug 20, 2017

justinclift commented on Aug 20, 2017

lulol commented on Aug 20, 2017

justinclift commented on Aug 20, 2017

lulol commented on Aug 20, 2017

digideth commented on May 1, 2018

justinclift commented on May 1, 2018

juanitogan commented on Dec 10, 2023

juanitogan commented on Dec 10, 2023

lulol commented on Dec 10, 2023

chrisjlocke commented on Dec 10, 2023

juanitogan commented on Dec 13, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions