You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
3.9.1 not running on XP due to PE32 os-version set to 6 (Vista) #893
and BTW: patching offset 40/44 of the PE Header from 0006 to 0005 allows the program to run flawlessly, so it is no technical limitation, only a political - was this a deliberate decision?
Interesting. Yeah, I tried to compile our Windows binaries with XP support (using Visual Studio 2013, as per the instructions here), but in testing (quickly) it didn't load when launched.
So, seeing as XP has practically no users... I decided to not care. 😄
If there's an easy way to change things such that it works, I'm not personally against doing so.
I'm kind of surprised that XP can even download DB4S... apparently it's not able to connect to the GitHub HTTPS servers without installing other things first. (eg not impossible, but didn't sound likely)
When compiling for XP, I did choose the XP compatible setting... I think it was "v120_xp" instead. But, obviously didn't put enough time/effort into it.
You're welcome to make a mirror using an XP-friendly version if you want. The project is Open Source after all. 😄
@iRybin: as I said already in comment 2, 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 - it is not a technical reason, just a restrictive labeling that alienates XP users ...
@h1618@iRybinIf that helps, the nighly builds run fine on XP SP3, even on CPUs without SSE2. There is a note in the project front page to test them in case of trouble. 😄
@justinclift@h1618@iRybin Hmmm. Unfortunately seems that the new nigthly builds available don't work with XP SP3 anymore. 😭
The latest version that can confirm that works with XP SP3 is 2016-10-01, but is not available to download anymore.
In my case if I'm doing it right, patching the PE header in the binary as @h1618 suggest doesn't help: the program then loads but crashes immediately with an exception. 😕
@lulol Ahhh, that date range triggers a relevant memory. When we used to support building with Qt4, our Windows nightly build process was done on a Linux box, cross compiling to Windows.
When we change to Qt5-only, we set up a new build system for the Windows nightlies. That was around October. So it looks like the previous build process used to work for XP, whereas the new build process doesn't.
@h1618 If patching the PE header fixed the "not a valid Win32 application" error and allowed you to run DB4S without problems, then I believe the fix is very simple.
Microsoft dropped support for Windows XP on newer versions of Visual Studio by setting SystemVersion (offset 0x0040) in the PE header for all generated .exe to version 6 (Windows Vista) by the linker. MinGW on the other hand set this value to 4 (Windows 95/NT).
DB4S is built using MSVC (2013) without setting the minimum operating system to 5 (XP) so the .exe gets the default one 6 (Vista). I believe changing /SUBSYSTEM:WINDOWS (version not set, defaults to 6.00) to /SUBSYSTEM:WINDOWS,5.01 (for Windows XP, and 5.02 for Windows XP 64-bit) in CMakeLists.txt will make the .exe run on Windows XP without problems. This will just change the minimum operating system/subsystem version that are set by the linker. More information on MSDN.
@justinclift I think DB4S used to work on Windows XP when using the old build system because it was not using MSVC.
@glawrenceeditbin will not add/remove support for XP. It will just set the minimum operating system version in the PE header so the OS can load it. This is exactly what the linker will do after combining all the object codes into an executable.
It is perfectly fine to set it to a lower value too. The latest version of MinGW set it to 4 (Windows 95/NT), even if you are targeting newer OS like Windows 7 or higher. An application will not work of course if it cannot find the newer Win32 APIs.
Judging by @h1618 solution (patching the exe) that worked for him then I guess DB4S is not using any newer APIs higher than Windows XP, and I don't see a reason to drop XP support. In fact, building the same source and using the same build system but with a different compiler other than MSVC will make it work.
I know supporting and maintaining older OS versions is hard, if you have to write code like this a lot..
#if (_WIN32_WINNT >= 0x0601)
// Windows 7 or higher
#else// Windows XP and lower
#endif
But this is not the case here. It is just changing a couple of bytes in DB4S executable. Using the linker switch, #pragma in the source code, or editbin will accomplish that. To be honest, I think editbin is the best solution since almost everyone here wants to drop XP support.
How about making a new installer just for XP? So, after the build system make windows packages, it copies them, patch them using editbin then release as Windows XP only. Even better, make a new release for older versions of windows by using 4.00 (Windows 95/98/ME/2000/XP) instead of 5.01.
As long as DB4S is not using newer Windows APIs it should work fine on older versions, without making any changes to the source code. If DB4S started using newer APIs then you can immediately stop releasing the older versions package and drop support for it, but not before that I hope.
@chrisjlocke I don't use Windows XP and yes I know it is old but I also know it is still has a large user base. Microsoft tried to drop support (stop making exe that will run on XP) for it in VS 2012 and failed. They were forced, by the huge user base, to add support for it in VS 2012, 2013, 2015.
I use Windows 7 and I continue to use it even after Microsoft dropped support for it about a year ago and I think most of DB4S windows users are on Windows 7.
If you don't want to support older OS then be ready in 3 years to find a way to make DB4S work on Windows 7 when its extended support ends in 2020, and Microsoft raises the minimum operating system version to Windows 8/10 in MSVC.
Been thinking about this. It seems it'll be fairly simple (in the short to medium term) to keep DB4S working with XP. So, we might as well keep making XP compatible releases.
After all, we do support OS/2 still. 😀
When the underlying things we rely on (eg Qt, SQLCipher) stop working for XP, that'll probably be a reasonable point at which we can stop supporting XP.
One caveat - if it turns out we need to do tricky development stuff just to keep XP support working, that's also a case we might need to just drop it.
@justinclift I agree with you, and that's why I prefer the editbin way, since it doesn't mess with the project build system or source code, and no files need to be changed. You can add it in the batch file that create the windows builds, and make a new installer for legacy windows.
Anyway, no one can support XP forever while every project is dropping support for it. According to this comment in Qt blog, Qt 5.6 LTS is the latest version to support XP. So keep that in mind when upgrading Qt.
Ahhh, it might be a moot issue then. There's some stuff in Qt 5.8 which I'm hoping fixes an OSX network communication issue (not sure yet though). If it doesn't, then no worries we can stick with Qt 5.6. 😉
No support for XP? Too hard? Yeah, I hear ya. Too hard to use your product as well when there are so many other choices that do work...SQL Server, Oracle, MySQL, PostgreSQL, Redis, MongoDB. Wasn't too hard for them apparently ; )
@urmommaz - DB4S is open Source, so if its such an easy task to support XP, you're more than welcome to code away and give us pull requests. We can then merge those into the product.
We'll wait. 👍
Activity
h1618 commentedon Dec 4, 2016
and BTW: patching offset 40/44 of the PE Header from 0006 to 0005 allows the program to run flawlessly, so it is no technical limitation, only a political - was this a deliberate decision?
justinclift commentedon Dec 4, 2016
Interesting. Yeah, I tried to compile our Windows binaries with XP support (using Visual Studio 2013, as per the instructions here), but in testing (quickly) it didn't load when launched.
So, seeing as XP has practically no users... I decided to not care. 😄
If there's an easy way to change things such that it works, I'm not personally against doing so.
h1618 commentedon Dec 4, 2016
there is an easy way, see here:
https://msdn.microsoft.com/en-us/library/jj851139(v=vs.120).aspx
and if switching to VS 2015, there still is:
https://msdn.microsoft.com/en-us/library/jj851139(v=vs.140).aspx
it's just a setting ...
h1618 commentedon Dec 4, 2016
and BTW:
netmarketshare 11/2016: 8.63%, more than 8.1 and more than all MacOS together, and way more than Linux:
that's "practically no" for you?!?
justinclift commentedon Dec 4, 2016
Meh, it just seemed like too much effort. 😄
I'm kind of surprised that XP can even download DB4S... apparently it's not able to connect to the GitHub HTTPS servers without installing other things first. (eg not impossible, but didn't sound likely)
justinclift commentedon Dec 4, 2016
When compiling for XP, I did choose the XP compatible setting... I think it was "v120_xp" instead. But, obviously didn't put enough time/effort into it.
You're welcome to make a mirror using an XP-friendly version if you want. The project is Open Source after all. 😄
iRybin commentedon Jan 3, 2017
So what version runs on XP or what shall be done to run it on XP?
justinclift commentedon Jan 3, 2017
From memory, the 3.8.0 and earlier all should:
https://github.com/sqlitebrowser/sqlitebrowser/releases/tag/v3.8.0
h1618 commentedon Jan 3, 2017
@iRybin: as I said already in comment 2, 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 - it is not a technical reason, just a restrictive labeling that alienates XP users ...
lulol commentedon Jan 8, 2017
@h1618 @iRybin
If that helps, the nighly builds run fine on XP SP3, even on CPUs without SSE2. There is a note in the project front page to test them in case of trouble. 😄justinclift commentedon Jan 8, 2017
@lulol Cool, that's good info. 😄
lulol commentedon Jan 13, 2017
@justinclift @h1618 @iRybin Hmmm. Unfortunately seems that the new nigthly builds available don't work with XP SP3 anymore. 😭
The latest version that can confirm that works with XP SP3 is 2016-10-01, but is not available to download anymore.
In my case if I'm doing it right, patching the PE header in the binary as @h1618 suggest doesn't help: the program then loads but crashes immediately with an exception. 😕
justinclift commentedon Jan 13, 2017
@lulol Ahhh, that date range triggers a relevant memory. When we used to support building with Qt4, our Windows nightly build process was done on a Linux box, cross compiling to Windows.
When we change to Qt5-only, we set up a new build system for the Windows nightlies. That was around October. So it looks like the previous build process used to work for XP, whereas the new build process doesn't.
karim commentedon Jan 22, 2017
@h1618 If patching the PE header fixed the "not a valid Win32 application" error and allowed you to run DB4S without problems, then I believe the fix is very simple.
Microsoft dropped support for Windows XP on newer versions of Visual Studio by setting SystemVersion (offset 0x0040) in the PE header for all generated .exe to version 6 (Windows Vista) by the linker. MinGW on the other hand set this value to 4 (Windows 95/NT).
DB4S is built using MSVC (2013) without setting the minimum operating system to 5 (XP) so the .exe gets the default one 6 (Vista). I believe changing
/SUBSYSTEM:WINDOWS(version not set, defaults to 6.00) to/SUBSYSTEM:WINDOWS,5.01(for Windows XP, and 5.02 for Windows XP 64-bit) in CMakeLists.txt will make the .exe run on Windows XP without problems. This will just change the minimum operating system/subsystem version that are set by the linker. More information on MSDN.@justinclift I think DB4S used to work on Windows XP when using the old build system because it was not using MSVC.
4 remaining items
karim commentedon Jan 23, 2017
@glawrence
editbinwill not add/remove support for XP. It will just set the minimum operating system version in the PE header so the OS can load it. This is exactly what the linker will do after combining all the object codes into an executable.It is perfectly fine to set it to a lower value too. The latest version of MinGW set it to 4 (Windows 95/NT), even if you are targeting newer OS like Windows 7 or higher. An application will not work of course if it cannot find the newer Win32 APIs.
Judging by @h1618 solution (patching the exe) that worked for him then I guess DB4S is not using any newer APIs higher than Windows XP, and I don't see a reason to drop XP support. In fact, building the same source and using the same build system but with a different compiler other than MSVC will make it work.
I know supporting and maintaining older OS versions is hard, if you have to write code like this a lot..
But this is not the case here. It is just changing a couple of bytes in DB4S executable. Using the linker switch,
#pragmain the source code, oreditbinwill accomplish that. To be honest, I thinkeditbinis the best solution since almost everyone here wants to drop XP support.How about making a new installer just for XP? So, after the build system make windows packages, it copies them, patch them using
editbinthen release as Windows XP only. Even better, make a new release for older versions of windows by using 4.00 (Windows 95/98/ME/2000/XP) instead of 5.01.As long as DB4S is not using newer Windows APIs it should work fine on older versions, without making any changes to the source code. If DB4S started using newer APIs then you can immediately stop releasing the older versions package and drop support for it, but not before that I hope.
@chrisjlocke I don't use Windows XP and yes I know it is old but I also know it is still has a large user base. Microsoft tried to drop support (stop making exe that will run on XP) for it in VS 2012 and failed. They were forced, by the huge user base, to add support for it in VS 2012, 2013, 2015.
I use Windows 7 and I continue to use it even after Microsoft dropped support for it about a year ago and I think most of DB4S windows users are on Windows 7.
If you don't want to support older OS then be ready in 3 years to find a way to make DB4S work on Windows 7 when its extended support ends in 2020, and Microsoft raises the minimum operating system version to Windows 8/10 in MSVC.
justinclift commentedon Jan 24, 2017
Been thinking about this. It seems it'll be fairly simple (in the short to medium term) to keep DB4S working with XP. So, we might as well keep making XP compatible releases.
After all, we do support OS/2 still. 😀
When the underlying things we rely on (eg Qt, SQLCipher) stop working for XP, that'll probably be a reasonable point at which we can stop supporting XP.
One caveat - if it turns out we need to do tricky development stuff just to keep XP support working, that's also a case we might need to just drop it.
karim commentedon Jan 24, 2017
@justinclift I agree with you, and that's why I prefer the
editbinway, since it doesn't mess with the project build system or source code, and no files need to be changed. You can add it in the batch file that create the windows builds, and make a new installer for legacy windows.Anyway, no one can support XP forever while every project is dropping support for it. According to this comment in Qt blog, Qt 5.6 LTS is the latest version to support XP. So keep that in mind when upgrading Qt.
justinclift commentedon Jan 24, 2017
Ahhh, it might be a moot issue then. There's some stuff in Qt 5.8 which I'm hoping fixes an OSX network communication issue (not sure yet though). If it doesn't, then no worries we can stick with Qt 5.6. 😉
urmommaz commentedon Feb 25, 2017
No support for XP? Too hard? Yeah, I hear ya. Too hard to use your product as well when there are so many other choices that do work...SQL Server, Oracle, MySQL, PostgreSQL, Redis, MongoDB. Wasn't too hard for them apparently ; )
chrisjlocke commentedon Feb 25, 2017
@urmommaz - DB4S is open Source, so if its such an easy task to support XP, you're more than welcome to code away and give us pull requests. We can then merge those into the product.
We'll wait. 👍
justinclift commentedon Feb 25, 2017
@urmommaz You do realise this project is a volunteer based GUI for SQLite, not SQLite itself yeah? 😉
vtronko commentedon Feb 26, 2017
@urmommaz then why don't you just use them instead?
justinclift commentedon Feb 26, 2017
Due to idiotic further responses from @urmommaz, this Issue has been locked.
justinclift commentedon Mar 27, 2017
@h1618 Do you have the time and motivation to create an XP compatible build of our 3.9.1 release?
Some people are looking for a Win XP compatible build, so having something verified as working (I don't have XP) would be good for them. eg #986 😄
If you can make it, we can put it on our "nightlies" server() and point people at it when they ask. 😄
justinclift commentedon May 31, 2017
Closing this issue as we updated our 3.9.1 release with Windows XP support a few weeks ago (14th May). 😄