Windows x86, x86-64 builds

This is essentially a question for the other maintainers, but I saw no reason to have this discussion in private, so posting it to the public “Help” topic.

I don’t deal with the Windows builds/releases, so I regularly forget what the status quo is there and I’m surprised when I rediscover it. We currently have the following CI tasks for Windows:

  • 32-bit CMake debug
  • 32-bit CMake release
  • 64-bit CMake debug
  • 64-bit CMake release
  • 32-bit MSBuild debug
  • 32-bit MSBuild release

I have the following questions:

  • Why are there no 64-bit MSBuild tasks? I’m sure someone has explained this to me before, but I can’t remember why and can’t locate the relevant issue(s) with the explanation. If it’s explained on Gitlab, could someone drop a pointer to the relevant issue?
  • The mixture of debug and release ZIPs hosted on don’t seem consistent to me. Is this intentional? Here’s what I’m seeing:
    • development/windows/10/cmake/Debug/x64/graphviz-install-2.44.2~dev.20200821.1434-win64.exe
    • development/windows/10/cmake/Debug/x86/graphviz-install-2.44.2~dev.20200821.1434-win32.exe
    • development/windows/10/cmake/Release/x64/graphviz-install-2.44.2~dev.20200821.1434-win64.exe
    • development/windows/10/cmake/Release/x86/graphviz-install-2.44.2~dev.20200821.1434-win32.exe
    • development/windows/10/msbuild/Debug/x86/
    • development/windows/10/msbuild/Release/x86/
    • stable/windows/10/cmake/Release/Win32/graphviz-install-2.44.1-win32.exe
    • stable/windows/10/cmake/Release/x64/graphviz-install-2.44.1-win64.exe
    • stable/windows/10/msbuild/Debug/Win32/
    • stable/windows/10/msbuild/Release/Win32/graphviz-2.38-win32.msi
    • stable/windows/10/msbuild/Release/Win32/
    • stable/windows/10/msbuild/Release/Win32/

To get more specific with my second question above:

  • why are the 32-bit builds under “x86” for the development binaries but “Win32” for the stable binaries?
  • why are there 64-bit debug CMake development binaries but no 64-bit debug CMake stable binaries?
  • why are 2.44.1 and 2.38 available, but nothing in-between?

None of this is meant to be a complaint. I’m just trying to comprehend why this structure exists and whether it’s deliberate.

TL;DR No one knows how to build them. More info through and

I currently don’t understand this. It should be “Win32” also for development binaries. This is set by the $Env:platform environment variable in .gitlab-ci.yml. PowerShell however has the peculiarity that environment variable set in a child process also affects the parent process since $Env: is a drive which means that all bets are off :scream:. This needs to be further investigated.
EDIT: The reason is that Set up VCTools variables and import into PowerShell environment changes this environment variable to x86 (Search for platform in this log). This setup was introduced after the latest stable release in, hence the difference. I’ve written an issue about it.

We introduced them since the latest stable release in

We only host the latest stable release because we don’t have disk space for all of them. The 2.38 release was a manual mistake by me and I’ve now removed it. It and other old Windows releases are instead found at

1 Like

@smattr Make sure to read my answers on the forum, not in the email that you may have got. I mixed up the questions in my initial answers.

Thanks, Magnus. That explains a lot of my confusion.

Are we tracking the 64-bit build issue? The Gitlab issue you pointed to is closed, which makes me wonder if this has fallen off our radar.

Should we try to get these people to update?

It’s very well known and documented at New simplified installation procedure on Windows, but there’s no issue on it that I’m aware of.
I was under the impression that we didn’t want to put too much effort into the MSBuild version anyway and wanted to work as much as possible on the CMake version instead. From discussion in that GitHub issue is seems that MSBuild was a dead end anyway. Of course we could have an issue nevertheless, but I doubt it would ever get resolved.

I not so sure about that. We don’t have anything that is nearly as complete as version 2.38.

Get them to build it? Or do they just redistribute packages we gave them?
Mr. Learned Helplessness

I don’t understand how that would make any difference, but yes, I think that whoever supplied that package just wrapped ours. In general I think that’s how Chocolatey packages work, but perhaps someone else knows this better than me?

It looks like that Chocolatey package scans for updates automatically, but it fails to find 2.44.1 because it’s looking for an MSI and we’re hosting a ZIP:

The package has a number of other issues (e.g. pointer to old Github repo). Maybe we should submit a PR there.

1 Like

Actually they’re already attempting an update, so maybe we should intervene:

1 Like

Just returning to this now, and I realize this is not quite correct. The URL you’ve quoted has a range of releases up to 2.38. Where are the releases in-between 2.38 and 2.44.1? E.g. where is 2.42?

Something related but minor: I think we should remove the directory hierarchy users have to jump through to download the Windows installers. Let’s change the “Stable Windows install packages” link on to a heading with three bulleted items underneath linking to each installer:

I don’t think any users are interested in the directory hierarchy or the incomplete 32-bit CMake release build. What do you think?

Failing that we could just dump the current release in the archive folder,, along with everything else. This is basically what GNU does for all their tools already.

I meant 2.38 and older. We don’t save newer old releases any more.

The directory structure is what it is because I wanted to mimic the Linux releases as far as possible, but we can change that if you want. The CMake releases contain an .exe installer, while the MSBuilds don’t. I think most 32-bit users would prefer to use the CMake installer. That said, I’m okay with adding a bulleted list to the downloads page. I think many users need some guidance though. That’s why I wrote New simplified installation procedure on Windows.

There are considerations to be made due to that the server is an SELinux of which workings I’m totally ignorant. See @Ellson is the one to comment on this.

Ah OK, I was not aware of this. Does this have any impact on package managers like Chocolatey that pull the installer? Do Chocolatey users ever request installation of a version prior to the current?

I don’t object to the installation procedures, and thank you for writing such a thorough document on this. However, what I’m questioning is that the current “Stable Windows install packages” link goes to a directory four levels above the actual files. From your description above, there will only ever be four files below this root as we’re not preserving past releases. So a Windows user has to click four times to reach a leaf directory containing a single file and then a fifth time to download the file. Could we not just skip the hierarchy and link directly to the leaf files?

I’m not sure which Linux releases you’re referring to, as all the Linux links on that page seem to go to external distro pages.

In case I wasn’t clear, I meant preserve the same directory hierarchy in terms of where the files are stored, but just have links on the download page that go straight to the files.

That’s beyond my competence level.

Actually there are/will be six files under stable and another six under development since we started deploying also the CMake Debug builds after the latest release. I will update New simplified installation procedure on Windows to reflect this.

Absolutely. I’m in favor of that.

Ah, I see. I misread. I was referring to the actual directory structure which is similar for Linux and Windows.

1 Like

Thanks, I think this all makes sense to me.

Except for:

Why are we deploying both MSBuild and CMake installers? I understand where we the maintainers are at, but what decision is a user meant to make here? I.e. if I’m a user and I see a 32-bit debug MSBuild installer and a 32-bit debug CMake installer, how am I supposed to choose between them?

IMHO the build system chaos should not be exposed to users and we should simply be offering four installers:

  • 32-bit debug
  • 64-bit debug
  • 32-bit release
  • 64-bit release

The MSBuild builds are more complete in terms of functionality, but don’t come with an installer, contain no header files and perhaps have other shortcomings. I’ve seen issues where users install both of them on top of each other to compensate for this.

I don’t know. I feel like a user myself in that sense. If we knew the exact differences between them, mabye we could make better recommendations. I’m planning to do a more detailed investigation of this and present it in a way that will be useful for us when we try to make the CMake builds:

  1. More complete than the MSBuilds so we can stop building using MSBuild.
  2. As complete as version 2.38 so we can encourage downstream package managers to upgrade.

That seems reasonable from an outside perspective, but whichever 32-bit build we chose to expose will lack things that the one we don’t expose has.

Wow, this is some truly bizarre behavior that we’ve managed to train users into thinking is normal.

Should I shelve some of my other work and focus on aligning the two builds and/or fixing the CMake build? I did not fully grasp the scope of the dire situation Windows builds are in.

I’d certainly enjoy your company on the dark side. I’m pretty sick of Windows weirdness. ATM, I’ve left it though and rebooted in Linux mode trying to learn the code base by debugging I think you should finish what you are doing first. Personally I don’t like context switching too much. Also, even though the state of the Windows builds is not optimal, the lion part of users just want to run dot which is possible using any of them.

1 Like