Getting started on Windows

Hello,

I am developing mostly on Linux (at work) or a bit on macOS (at home). I need to port a bit a code on Windows, but I really don’t know where to start to get some dev environment. I have read a few topics here but there are so many options and so much information that I’m still a bit lost…

Criteria:

  • The simpler the better: a stand-alone editor (Notepad++ looks fine) and command line tools are OK, I don’t need (and even don’t want) an IDE at that point
  • I need to call some system routines, so it has to be native compilers (not WSL or Cygwin based)
  • it can be gcc/gfortran or the Intel compilers. Both if possible
  • preferably fpm with its dependencies
  • if possible a unix-like shell, just because I’m better used to them compared to cmd/powershell

To show how I feel lost on Windows, I’ve installed all of the Intel OneAPI stuff, but it doesn’t show up anywhere (start menu or I don’t know) and I don’t even know where it is actually installed… But I understand that Visual Studio is required to be able to use the Intel compilers?

Any help appreciated :slight_smile:

1 Like

@lkedward has developed:

I have used the Winteracter library for years, and it very easy to use to build Windows applications with Fortran. It supports a large number of compilers, among them Gfortran and Intel, but it is not free.
Link to home page: Winteracter - The Fortran GUI Toolset

1 Like

I would suggest using the MSYS2 distribution , a system similar to cygwin, but more “native” Windows.

Note: As far as I know, there is still no native Windows implementation of OpenCoArray, so using CoArray-Based Mutiprocessing on WIndows may be difficult/not possibility.

As noted by a reply by zoziha to this comment, it is possible to use OpenCoArrays with Intel MPI using Windows.

Several Editors gvim, emacs, qdevelop are also available within the MSYS2 environment.

3 Likes

Yes, MSYS2 is the easiest solution for Unix guys. Those notes could help you for installing gfortran, fpm and other classic tools: https://github.com/vmagnin/gtk-fortran/wiki/Installation#windows

And also WSL2, but I have not tried it yet, MSYS2 being sufficient for my needs.

1 Like

As a Fortran developer on Windows, I found the best coding experience with Visual Studio and the Intel Compiler. I am also programming a lot of C# so this is the closest environment I could get.
If you want to stick to gfortran then go for msys2. With vscode you should get something similar to what you are used to on Linux. I used that link for setting up my gfortran tool chain https://github.com/JHenneberg/Guide_VSCode-fortran

I work mainly on windows, right now the best combination for debugging is Microsoft Visual Studio + intel compilers, if you get the community edition of MVS2022 you’ll have everything you need for small projects

Then, I prefer Visual Studio code as my new defacto-goto-editor for basically anything, you’ll have a terminal integrated in the same environment, you can actually have multiple terminals open at once, powershell, command prompt, wsl, git bash, etc… that can be useful, the one thing missing is debugging with intel compilers, but there are solutions for gnu compilers with the Modern Fortran plugin.

2 Likes

Yes, that is truly unfortunate, but I might revisit it at some point. The VS Code C/C++ extension seems to be okay with debugging intel compilers’ code.

1 Like

My working practice is to install Microrosft Visual Studio Community Edition first - currently 2022. Here is a link. Download Visual Studio Tools - Install Free for Windows, Mac, Linux.

Then the Intel oneAPI toolkits, both base and hpc.

You can then access the Intel compiler from a command prompt or from within Visual Studio.

My preference is from a command prompt.

On the editor front Microsoft provide notepad. I normally install Notepad ++ and vim as well.

I normally pin the Intel command prompt to the task bar

If you want some more help I can provide some screen shots of how to do this.

Ian Chivers

1 Like

Since you have much teaching experience in Fortran, I wonder if you have created a summary of what a programmer needs to know about the Windows command line. Here are my thoughts:

The Windows directory separator is the backward slash "", unlike “/” for Unix. (Discourse seems not to render the backward slash :slight_smile: .)

The %path% variable determines where CMD looks for a command, and it is convenient to have a batch file that sets it. Intel Fortran 2021 provided setvars.bat and mpi\2021.6.0\env\vars.bat

Some basic commands are dir, cd, mkdir, rmdir, del, findstr (analogous to grep), attrib, copy, xcopy, rename.

For help on a Windows command use /?, for example dir /?

Windows allows directory and file names with spaces, but avoid this or you have to use quotes everywhere.

Windows file and directory names are case-insensitive, unlike Unix. When coding on Windows, be consistent with the cases of file names (names in the program or a data file should exactly match the names in the file system), so that future porting to Unix will be easier.

Windows CMD batch files should have a .bat or .cmd extension.

Windows executables should have a .exe extension. Gfortran by default produces an executable a.exe, and Intel creates foo.exe from main program foo.f90, although this can be changed with the -o option. Gfortran creates .o object files, while Intel uses the .obj extension.

Windows Terminal is relatively new and has more features than the CMD console.

Hi

you’ve covered most of what you need to know.

I avoid spaces as I move files between Windows and Linux
on a regular basis using tar.
Tar is available from the command line on both Windows and Linux.

On linux .o is a common file name for intermediate
files when compiling with several languages (C, C++, Fortran).

On windows it is .obj

Another file name extension is .mod, and that is used
on both Windows and Linux.

when working with several compilers (I use Nag, Intel, gfortran and Salford/Silverfrost on Windows and
Nag, Intel, gfortran, Sun/Oracle, nvidia and Cray on Linux) you need to be careful
with the .mod files as the mod files are not compatible between compilers.

I have a batch file under windows and a shell script under linux
that deletes all intermediate files, .mod files, and .out and .exe files to get a clean
compilation when moving between compilers.

I’m not sure what you mean about “native Windows implementation of OpenCoArray”, but MSYS2 can use OpenCoarray with the help of Intel OneAPI’s MPI. I’ve tried it and it works.

2 Likes

I use the MinGW-W64 build kindly provided by Releases · niXman/mingw-builds-binaries · GitHub. Just download the zip file, unzip, add to path, and gcc, gfortran and make (named mingw32-make, but you can rename) are readily available. gdb and g++ come along.

For the shell, I got used to cmd, in the end it’s not that bad. Wrapped in Windows Terminal, it’s even convenient. I occasionally also use MobaXterm, which provides a cool shell, but I find it difficult to switch between `/homeˋ and paths in the Windows Explorer.

Regarding the IDE, I’m still using Eclipse, because it’s easy to install (just unzip, as above), to add/remove projects, and some tools like git are nicely integrated. It’s very limited for Fortran though.

If you want a simple Fortran editor on Windows, take a look at Geany. Similar to Nopepad++ but is cross platform. I use it everyday.

1 Like

A few months ago, I put screen shots for windows installation here:

GitHub - Shahid718/Installation_guide: The repository demonstrates how to download and install the latest Intel Fortran release, gnuplot release, gcc release, Dislin release for Windows 10.

There’s no need to install both Base- and HPC toolkit. The standalone Intel Fortran Compiler is sufficient, and saves both time and disk space :slight_smile:

1 Like

Thanks to all of you for the suggestions. I’m currently travelling, but will try out as soon as I return.

1 Like

After installing and launching the standalone intel compiler

I get this error of VS installation location. But it is installed there.

What should I change here then?

The installer provides feedback on the visual studio integration, run it in repair mode, and see what it says.


i see the same