Digital Visual Fortran 6.0

[kwweber]

I need to upgrade to a visual fortran environment that will also work with my old programs developed with DVF 6.0. I used the Quickwin application function (and all of the related modules) frequently and I would like to know if the Intel Visuqal Fortran development environments are compatible with the old stuff thatI currently use.

[Steven_L_Intel1]

Generally, yes. Most applications just need a rebuild. Please read this article for more details. Feel free to ask here if you run into any issues.

[kwweber]

We will be moving over to 64 bit Windows 7 machines. Digital Visual Fortran 6.0 has served me well but it is the end of the road as I am sure that this will not function properly in this new environment. I need to obtain a version of Intel Visual Fortran (and the correct version of Microsoft Visual Studio) that will convert the old stuff (CVF 6.0). Please confirm what I need to provide programs that will function properly in this new environment. My current computer uses Windows XP (32 bit). Also, is it possible to load the latest version of Intel Visual Fortran into a 32 bit machine (using XP) and provide executable programs that will function on the Windows 7 (64 bit) units?

[TimP]

If you don't require C/C++, the VS Shell incorporated in ifort releases would give you all the facilities you had with DVF which have continued support. There have been posts here about preferred ways to provide Resource Editor support, in case you require that outside Visual Studio.
Current versions of ifort work with VS2005, 2008, and 2010, all needing Service Pack updates, in case you do need C/C++. There are remarks about future deprecation of VS2005, while 2010 supports additional new features in ifort 12.1.
By installing both the ia32 and Intel64 compilers, you are able to build both 32- and 64-bit .exe (even on XP32), both of which can run on Win7-x64.

[kwweber]

Thank you for this information. I am currently using an evaluation copy of IVF Composer XE for Windows. For the most part this looks pretty good. I am running into one glitch that is driving me crazy. I generate a formatted output file using direct access, fomatted data. I used to use the following to insert a blank line in the file:

open(35, file='c:\engprogs\rpt.dat', status='replace',form='formatted',recl=85,access='direct')

write(textout,*) ' '
write(35,90087, rec=mrec) textout

90087 format(a85)

Note: textout is a character string (textout*85)

The blank line appears to be ignored and is not present in the report. If I simply place a charcter such as '.' in the place of the ' ', the line is inserted but with the '.' at the beginning.

What is the cause of this?

[IanH]

Could you describe what you want in a little more detail? It is the terms "insert" and "blank line" that make me wonder - direct access files work on records. Do you want the line termination sequence (CR-LF) at the end of each record (are you going to be opening this report file in a text editor)? Perhaps you need to specify the /fpscomp:general option or alternatively explicitly put the line termination characters in the format. What other command line optons are you using for compilation?

[kwweber]

It simply will not write ablank character in the report. All leading blanks are ignored as well. If I simply wanted the record to read as ' Temperature is 0', the leading blanks that are in the character set before the capital T in Temperature are ignored and the out put is 'Temperature is 0'. It is basically ignoring all blank characters the preceed an actualnumber, letter or symbolin a character string. This makes no sense. It should treat the blank spaces within the quote marks as characters as well.

[IanH]

I don't see that behaviour here with a short test program, but that's probably because I don't correctly understand your scenario. Can you provide more information (ideally compilable and runnable source)?

In the following I've changed the record length to be 32 so that the resulting file displays nicely in the binary mode of the VS 2010 editor, which uses 16 columns.

[fortran]PROGRAM FormDirect
  IMPLICIT NONE  
  INTEGER, PARAMETER :: unit = 10
  CHARACTER(32) :: buffer
  !****
  OPEN( 10, FILE='test.txt', STATUS='REPLACE', FORM='FORMATTED', RECL=32, &
      ACCESS='DIRECT' )

  ! items directly in the io list of the write that writes to the file
  !                        12345678901234567890123456789012
  WRITE (10,"(A)", REC=1) 'Mary had a little lamb.'
  WRITE (10,"(I10)", REC=2) 123
  !                        12345678901234567890123456789012
  WRITE (10,"(A)", REC=3) '     The temperature is 40.'
  
  ! via an intermediate buffer that has the same length as RECL.
  ! (The format spec has the same width too).
  buffer = 'Mary had a little lamb.'
  WRITE (10,"(A32)", REC=4) buffer
  WRITE(buffer, "(I10)") 123
  WRITE (10,"(A32)", REC=5) buffer
  buffer = '     The temperature is 40.'
  WRITE (10,"(A32)", REC=6) buffer
  
  CLOSE(10)
    
END PROGRAM FormDirect
[/fortran]

[plain]>ifort /check:all /warn:all /stand:f03 /standard-semantics form-direct.f90
Intel Visual Fortran Compiler XE for applications running on IA-32, Version 12.1.1.258 Build 20111011
Copyright (C) 1985-2011 Intel Corporation.  All rights reserved.

Microsoft  Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:form-direct.exe
-subsystem:console
form-direct.obj[/plain]

The records start every even row in the following hex display. 20 is the code for a blank (ASCII space).




If you view this as a plain text file then it appears as one rather longish line, as there are no end-of-line markers (note the little blue line wrap glyphs at the end of the display lines). If you were using a text editor that put display line breaks in between words then it could appear that leading blanks were getting dropped, but that's just a display artefact.

[Wendy_Doerner__Intel]

I should note that the Microsoft Visual Studio Shell that we ship with our compiler does not convert CVF projects. To get that support you would need to buy one of the Microsoft Visual Studio versions (not Express Edition) we mention in the release notes or on this article that describes the required software.

------

Wendy

Attaching or including files in a post

[jeremy_h]

Noone can really guarantee that your code will work as-is, or that there won't be significant problems with your migration. In general, IVF does a very good job with old code, however the large system I worked with used features such as short-circuit evaluation, which is deliberately unsupported in IVF, and it used various other compiler-specific idioms that produced problems in IVF. We did not yet attempt a move to 64-bit executables although our 32-bit exe's run fine on 64-bit OS.

We had problems with our VC6 to VC9, also, and our VB6 was practically unusable under VB8. So there are things worse than old Fortran code.

You may be lucky, you may only have to run the migration wizard and everything works. However, you should not be surprised if it is a bit harder than this.