3.9.1 not running on XP due to PE32 os-version set to 6 (Vista)

[h1618]

Details for the issue

Tried to install the new DB Browser for SQLite on my win32 XP Prof. SP3 machine, but:

• refuses to load: no valid win32 application, uninstall, reinstall: no change
• load into debugger: windbg/ollydgb: cannot stat, no valid win32 ...

Useful extra information

• look on PE32 header, and find: optional PE32 has os-version major set to 6 = Vista (minor to 0)
• googled and found: VC2012 SP0 (not SP1) dropped XP support by setting os-version to 6

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

[h1618]

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]

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]

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]

and BTW:

XP has practically no users

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]

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]

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]

So what version runs on XP or what shall be done to run it on XP?

[justinclift]

From memory, the 3.8.0 and earlier all should:

    https://github.com/sqlitebrowser/sqlitebrowser/releases/tag/v3.8.0

[h1618]

@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]

@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]

@lulol Cool, that's good info. 😄

[lulol]

@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]

@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]

@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.

[justinclift]

@karim Yep, it's completely possible.

As a thought, since you seem to know a lot about this stuff... this is the batch file that runs automatically each night to create the windows builds:

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

It's using CMake to generate the MSVC project files, then builds them with devenv. Any idea if that /SUBSYSTEM switch would work for devenv? It kind of looks like it might (though I haven't tried it)

[karim]

@justinclift Unfortunately I don't have much experience with CMake.

devenv.exe (Visual Studio) works with .vcxproj XML project files, and will not accept that /SUBSYSTEM switch. It is a linker switch and should be added to CMake so it can generate a working .vcxproj file for devenv to use.

Try editing the CMakeList.txt and add the switch there, then look at the generated .vcxproj file. You should find something like..

<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
    <Link>
        <SubSystem>Windows</SubSystem>
        <MinimumRequiredVersion>5.01</MinimumRequiredVersion>
    </Link>
</ItemDefinitionGroup>

If you found <MinimumRequiredVersion>5.01</MinimumRequiredVersion> then it should work.

Another solution is by editing the source files. Something like..

#ifdef _MSC_VER
#    pragma comment(linker, "/subsystem:windows,5.01")
#endif

Finally, a quick solution is by editing the .exe file using editbin and change the subsystem right after building it. Something like..

editbin DB4S.exe /SUBSYSTEM:WINDOWS,5.01
editbin DB4S_x64.exe /SUBSYSTEM:WINDOWS,5.02 

NOTE: Windows XP 64-bit was introduced later than the 32-bit version so it got a different version.

[glawrence]

Personally I don't think the editbin solution is ideal. If something else changes in Qt or elsewhere and we actually drop XP support but then use this to "add it back" then we could be covering up a multitude of issues. So, we should do this with the linker really.

However I would vote for dropping XP support completely.

[chrisjlocke]

If details are given on one of the wiki pages how to 'fiddle' with a program to make it XP compatible, then its up to the user whether they can use those instructions or not. They're already 'dicing with death' using an old OS, so having a 'multitude of issues' will be the icing on the cake. I don't think its up to us to do that though... (and maintain software for non-maintained OS's)

[karim]

@glawrence editbin 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.

[justinclift]

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]

@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.

[justinclift]

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]

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]

@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]

@urmommaz You do realise this project is a volunteer based GUI for SQLite, not SQLite itself yeah? 😉

[vtronko]

@urmommaz then why don't you just use them instead?

[justinclift]

Due to idiotic further responses from @urmommaz, this Issue has been locked.

[justinclift]

@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]

Closing this issue as we updated our 3.9.1 release with Windows XP support a few weeks ago (14th May). 😄