Intel® Software Network

Is the C++ application a console application?  If not, then there is no console to write to.  This is no different in version 11 than in previous versions.

Thanks for the response, Steve.  We are creating a console in our MFC-based GUI, then the Fortran .dll is called.

Here is the C++ code containing the Fortran call:

// Create a console window, so BRASS can display the analysis progress.
BOOL bConsoleExists = AllocConsole();
if (bConsoleExists)
{
   // Set status bar text.
   CString sStatusBarText = "Executing BRASS-PIER(LRFD)...";
   StatusBarText += " DO NOT CLOSE THIS WINDOW OR THE BRASS GUI WILL CLOSE!";
   m_pWnd->SetStatusBarText(sStatusBarText);

   SetConsoleTitle(sStatusBarText);
   HANDLE hConsoleHandle = GetStdHandle(STD_INPUT_HANDLE);
   // Set the console mode so CTRL+C signals are not processed.
   DWORD dwMode = 0;
   SetConsoleMode(hConsoleHandle, dwMode);

   //Call to the FORTRAN analysis
   (*lpfnBRASS_PIER_LRFD)(cDatFileName, iDatFileLength, cOutFileName, iOutFileLength,
			   cExePath, iExePathLength);
			
    FreeConsole();

I noticed this morning that I get the same error for a project that hasn't been rebuilt using version 11.0 yet.  Is there something different in the way one of the Fortran libraries (libifcoremd.dll is mentioned, see the attached error message).

Thanks again.

Mark

// Create a console window, so BRASS can display the analysis progress.
BOOL bConsoleExists = AllocConsole();
if (bConsoleExists)
{
   // Set status bar text.
   CString sStatusBarText = "Executing BRASS-PIER(LRFD)...";
   StatusBarText += " DO NOT CLOSE THIS WINDOW OR THE BRASS GUI WILL CLOSE!";
   m_pWnd->SetStatusBarText(sStatusBarText);

   SetConsoleTitle(sStatusBarText);
   HANDLE hConsoleHandle = GetStdHandle(STD_INPUT_HANDLE);
   // Set the console mode so CTRL+C signals are not processed.
   DWORD dwMode = 0;
   SetConsoleMode(hConsoleHandle, dwMode);

   //Call to the FORTRAN analysis
   (*lpfnBRASS_PIER_LRFD)(cDatFileName, iDatFileLength, cOutFileName, iOutFileLength,
			   cExePath, iExePathLength);
			
    FreeConsole();

The C++ looks fine AFAICS. Show your Fortran code.

Gerry

I forgot, what happens when you allocate the console in the dll and have the c++ client load it?

Gerry 

Gerry, lots of stuff happens in Fortran without problem, but this statement leads to the error:

         write (*,2500)                   !add screen output
 2500    format ('Reading Input Data .',\)

I don't understand what you're asking regarding allocating the console in the dll.  Thanks for your help.

It seems like with previous versions of Fortran, the program writes to a particular console automatically.  Is it now necessary to pass in a handle or something?

The routine being called in Fortran looks like this:

      INCLUDE 'FLIB.FI'
      SUBROUTINE BRPIER(InputFile1,OutputFile1,exePath)
C     
	use DFPORT
	implicit none
	!DEC$ ATTRIBUTES DLLEXPORT :: BRPIER
	!DEC$ FIXEDFORMLINESIZE:132
      INCLUDE 'COMMT(lrfd).FOR'

      CHARACTER(LEN = *), INTENT(IN) :: InputFile1
      !DEC$ ATTRIBUTES REFERENCE :: InputFile1
      CHARACTER(LEN = *), INTENT(IN) :: OutputFile1
      !DEC$ ATTRIBUTES REFERENCE :: OutputFile1
      CHARACTER(LEN = *), INTENT(IN) :: exePath
      !DEC$ ATTRIBUTES REFERENCE :: exePath

OK, let me explain. As Steve remarked, with a C++ Windows client there's no console to write to as far as your dll is concerned. The fix (forget what you claim used to happen) is simple. Remove the allocation of the console from your C++ code and relocate it to the dll from where you'll allocate it. In the dll you'll have something like

use kernel32

logical ires

ires = AllocConsole

write(*,*) stuff

ires = FreeConsole

Gerry

That might or might not fix the problem.

As far as I can tell, the Fortran run-time library caches the handles for all opened streams (=files or consoles). For WRITE(*,*), the appropriate handle is the one returned by GetStdHandle(STD_OUTPUT_HANDLE). As MSDN says, "AllocConsole initializes standard input, standard output, and standard error handles for the new console. "

Now, the issue is at what point the Fortran RTL (libifortmd.dll) calls GetStdHandle for unit (*). In previous versions, if I recall correctly, that occured on first Fortran I/O statement (regardless if it was from/to console or from file). However, if Intel decided to move it to Dll initialization, it would be too early: basically, there's no console at startup, and (*) is associated with nothing. When you do an AllocConsole later, it's too late, because the output never gets associated with unit (*).

Note that I'm basically just speculating what's going on. You can get a definitive answer only by someone from Intel, with access to RTL code. If Gerry's suggestion fails, try calling FOR_RTL_INIT (see the docs) from C code after AllocConsole. Again, that might or might not fix the problem.

// Create a console window, so BRASS can display the analysis progress.
BOOL bConsoleExists = AllocConsole();

   //Call to the FORTRAN analysis
   (*lpfnBRASS_PIER_LRFD)(cDatFileName, iDatFileLength, cOutFileName, iOutFileLength,
			   cExePath, iExePathLength);
			
    FreeConsole();

Ah, I've just noticed that you (likely) bind the Fortran dll dynamically, through LoadLibrary. If my speculation above is correct, you can also try calling LoadLibrary after AllocConsole.

Yes, we are allocating the dll dynamically using LoadLibrary.  I tried moving AllocConsole before LoadLibrary, but I still get the same error.

      BOOL bConsoleExists = AllocConsole();
      hinst = LoadLibrary(ENGINE_DLL_NAME);

I also tried allocating the console in the Fortran .dll instead of the C++ - that does not work either.

Thanks for the suggestions.  Any other ideas?

Mark

      BOOL bConsoleExists = AllocConsole();
      hinst = LoadLibrary(ENGINE_DLL_NAME);

You can try linking against static Fortran run-time library... but I'm stabbing in the dark. Maybe I'll find some time to try it myself today.

What happens if you redirect the output to a file rather than console (CreateFile or _get_osfhandle, then SetStdHandle)?

No problems writing to any of several different output files.  Just the console error.  I haven't had a chance to look at this for a while, so I'll try starting from scratch with a simple project now.

I posted a sample to the forum a couple of weeks ago where incidentally a console is allocated from an IVF dll. This has always worked.

Attach a zip of a working sample here or to Premier Support where you demonstrate that it doesn't, otherwise you're just wasting everyone's time.

Gerry

Ok, I went through the wizard to create a new MFC project, got the basic multiple-document view project, and added a menu item to call my FORTRAN code.

I created a simple FORTRAN dll that just writes one line to the console.

I have uploaded .zip of the two projects.

I get the same error allocating the console in C++ or FORTRAN.  Hopefully I haven't left anything out.

I would appreciate it if someone can take a look at this.  Thanks.

Mark

Test.zip is the FORTRAN project, MFCTest.zip is the MFC project.

Your Zip is not visible as an attachment.  Go back into Add Files, click on your folder, click on your file and then click Add Attachment.

Both attachments are vc++ projects. Attach the Fortran (FYI, FORTRAN has gone the way of bell bottoms and disco) project.

Gerry

Well, if you can convince our clients to spend the money to rewrite all their old Fortran code, I'll be eternally grateful.  Until then, this is what we are stuck with.

I have attached my Fortran project.  If you try running with the smaller of the C++ projects, there is no error writing to the console.

A duplicate thread reports the same problem. I'm quite sure that if Premier Support had been made aware of it before this forum then Intel would fix the problem if warranted. No user here on this forum can do so.

Gerry

Gerry

I've submitted my projects and this error to Premier Support.

I think there is a good reason to check this forum first, Gerry.  Often there are new compiler settings or simple changes that can be solved here, and then the rest of the users can see the problem and solution with a quick search.

Indeed, we encourage you to use the forum first.

With 11.0.066/Vista, allocating a console is possible. What's not possible is writing to that console. This is a step backwards from 10.1.

Intel could have fixed this major flaw between the release of 11.0.061 and 11.0.066 all of which happened within the last couple of weeks. Does this forum  serve as a QA mechanism? It certainly appears that way. And no, I will not be submitting a working demo to Premier Support.

Gerry

We do look for possible problems in this forum and if we can reproduce them, submit them to development.  As for 066, the timeframe for getting fixes into that was very short.  It does not make it easier for us if we don't get an actual sample code but only a generic description.  Now that we have a sample I'll make sure developers know about it.

One would reasonably assume that this critical feature was checked before 11 left the stalls. Obviously not. "That the behavior changed between 10.1 and 11.0 is not good," as you remarked to the third report of this problem on this forum.
Let it be fixed.

Gerry

I can now reproduce this with a simple Fortran Windows application.  I doubt we have any tests that call AllocConsole, but we will now.  I'll report this regression to the developers and note its importance.  Thanks for all the clarification.

This is our issue DPD200110270.

Our developers found the cause of this bug and will fix it as soon as possible.  There is a curious workaround - in your Fortran code, use unit 0 instead of *.  This will continue to work even after the bug is fixed.  0 normally means "standard error".

Steve, thanks for your help.

Mark