Now with twice the bits

skyjake

<div id="bridgedd"> <div class="excerpt-title">This is a blog excerpt.  <a href="http://dengine.net/blog/2016/03/now-with-twice-the-bits/&quot; target="_blank">Read Full Article</a> </div> <br /> I took a short break from the UI work to perform an autobuilder upgrade. The biggest changes are that the autobuilder now produces a new 64-bit Windows MSI package (including Start menu shortcuts), and an RPM package built on Fedora Core 23 (also 64-bit). This means all platforms now have a 64-bit package and Windows additionally has the old 32-bit one as well.
Launchpad builds both 32 and 64 bit packages for Ubuntu. All new Launchpad builds will be done on 16.04.
The upgraded Windows autobuilder uses a newer compiler (VS 2015, Visual C++ 14) and the latest version of Qt (5.6). ... </div>

sonicdoommario

On all three Windows 7 64-bit machines in my house, the recent builds of Doomsday 2.0 produce an error when trying to launch Doomsday:

"The procedure entry point CreateFile2 could not be located in the dynamic link library KERNEL32.dll"

I tested on all three machines to make sure I didn't have a corrupt Windows install or something.

Are these kinds of messages common with the unstable 2.0 builds?

skyjake

sonicdoommario wrote:

Are these kinds of messages common with the unstable 2.0 builds?

No, these are not common. I suspect this is caused by the switch to a newer compiler and Windows SDK. It could be that the newest builds require Windows 8.1 at the moment. I'll double-check that it's using the correct Windows SDK that is compatible with Windows 7.

Gordon

i will test with win 10 and see how it works

Edit: it works so it must be a problem with the compiler not being configured to include all the stuff needed for win 7

skyjake

I checked the build config and Microsoft's documentation. The SDK that I'm using (8.1) is supposed to be backwards compatible with Windows 7, however it may require a bit of additional configuration. I'll tweak it a little and let's try again with the next build.

skyjake

Just tried 1913 and it is not working yet. I may still need to include additional files in the installation package, will look into it...

skyjake

Ok, build 1914 seems to be working. I tested the x64 version on a new installation of WIndows 7 Pro 64-bit.

The number of DLLs that have to be included in the bin\ folder is getting a bit ridiculous, but I prefer this to running an additional Visual Studio Redistributable installer on every install...

Vermil

It seems that Dday (64 bit at least) attempts to load the sdl dll's out of the first Steam version of Doom it encounters, leading to an alert stating it can't load said dll due to it not being a valid win32 application.

skyjake

Vermil wrote:

It seems that Dday (64 bit at least) attempts to load the sdl dll's out of the first Steam version of Doom it encounters, leading to an alert stating it can't load said dll due to it not being a valid win32 application.

Yeah, the bug is that Doomsday thinks that the SDL DLLs in the Steam folder could be plugins and tries to load them as such.

For the time being we can assume that plugins are only loaded from the "bin" folder in the Doomsday install location. I'll make this change for the next build(s).

GUN

skyjake wrote:

produces a new 64-bit Windows MSI package

Is there any way to get a ZIP instead? So the Installers actual not needed, test and verify different Versions would be much easier. Just run the other Versions in thier own folders.

skyjake

Yes it is possible to also offer a plain Zip package. I'm using CMake to generate these, so it's pretty trivial to do.

skyjake

GUN wrote:

Is there any way to get a ZIP instead? So the Installers actual not needed, test and verify different Versions would be much easier. Just run the other Versions in thier own folders.

Starting with build 1928, there are now Windows ZIP packages available on the Autobuilder pages (and SourceForge): http://files.dengine.net/builds/build1928/

Note that currently these ZIPs are "all in one" packages, meaning they also contain the headers and libraries needed for plugin development (the "include" and "lib" subfolders).