Back to the main page.

Bug 3265 - support FT buffer on win64

Reported 2017-03-09 17:18:00 +0100
Modified 2017-05-19 14:47:09 +0200
Product: FieldTrip
Component: realtime
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P5 normal
Assigned to: Robert Oostenveld
Depends on:
See also:

Robert Oostenveld - 2017-03-09 17:18:32 +0100

Right now the build scripts for the realtime components are only for win32, not for win64. We should upgrade the development environment for windows and make sure that both win32 and win64 work. This probably involves, as we have previously worked with For mex files we have these guidelines[]=win64#compiling_mex_files For the realtime stuff there is also this documentation I think the main difficulty is with pthreads support. I recall (from 8 years back) that there was some confusion as to the support for win64. A quick google just now did not resolve that confusion. I suggest we just get working on it, one step at a time. Important to know are: - what is the exact OS platform. - what is the toolchain (GNU make, MSVC IDE) - what is the compiler - what are the crucial libraries The latter parts are relevant to know which dlls need to be redistributed to have an executable run on another (clean, not development) computer.

Robert Oostenveld - 2017-03-12 10:14:54 +0100

I got myself a windows laptop (windows 10, 64 bit) and installed mingw-w64 both in the 32 bit and 64 bit version. Subsequently I started recompiling libbuffer, and the test applications. Especially the platform.h and the compiler.h needed updates. I made a separate branch at It now compiles, but I still need to look into the dependencies.

Robert Oostenveld - 2017-03-12 10:51:45 +0100

(In reply to Robert Oostenveld from comment #1) The executables did run, but only in the corresponding (32 or 64 bit) mingw-w64 environment. Dependencywalker showed a dependency on libwinpthread-1.dll. That dll is a different one for either 32/64 bit environments. I would rather not have to redistribute it along, although it could go in the realtime/bin/win32 and realtime/bin/win64 folder. The solution described at to link them statically works, and now the execulables (both 32 and 64 bit) work when double-clicking from the windows explorer, i.e. outside of the mingw-w64 environment. Dependencywalker shows no dependency on the pthread dll any more.

Robert Oostenveld - 2017-03-12 19:04:33 +0100

I have validated the changes on OSX and made some fixes to the Makefiles and headers. The code is on Still to do are to update the Makefiles in src/utilities (except for buffer, which is ready) and in src/acquisition. The documentation on the wiki at should also be updated.

Robert Oostenveld - 2017-03-22 11:06:16 +0100

I have been cross-validating, making sure that the build process works on osx 32/64, linux 32/64 on intel, linux on ARM, windows 32/64 with mingw. I still have to complete the build process for windows 32/64 using cygwin. There is now also a 64 bit version of cygwin (did not exist when we wrote the initial code). The 32 and 64 bit version co-exist without problems on my temporary Windows10 64-bit laptop. Updating the cygwin build process for the buffer (src, cpp and test) posed no big problems. I'll continue with updating the Makefiles to deal with cygwin also for the utilities and for the acquisition software (i.e. the xxx2ft.exe applications). The changes can be followed on I expect to merge them in the master in a few days (i.e. few evenings).

Robert Oostenveld - 2017-03-23 22:51:13 +0100


Robert Oostenveld - 2017-03-23 22:55:37 +0100

I have merged all changes, further development will entail only small changes and compilation, and can be done on the master branch or on fresh/new feature branches.

el amri - 2017-05-19 14:47:09 +0200

Hi, My name is EL AMRI Badrayour. I am working on a project at the Neurosciences of Systems Institute of Marseille. I am using the Fieldtrip toolbox to make a neurofeedback system. I have encountered some problems using the buffer with the lab computer (windows 7 x64 on MATLAB R2017a). The system wasn't working due to a mex crash. I have found the problem and if it can help you in your work. You need to upgrade the TCP/UDP/IP toolbox mex files to Use 64-Bit API. There is no way I can share my changes here but there is the link explaining how to do it.