Error writing to console

[Mark_Jablin]

I recently upgraded to Fortran 11.0 from 10.1, and I'm now running into an error in a .dll called from a C++ program.

The program crashes when the Fortran library tries a write(*,*) "anything".

The problem only occurs when the library is called from the C++ program. If I use my dummy Fortran executable to call the .dll there is no error.

I get the error whether I run the C++ program out of the debugger or run the release version.

Thanks in advance.

Mark

[Steven_L_Intel1]

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.

[Mark_Jablin]

Quoting - Steve Lionel (Intel)

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:

[cpp]// 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();[/cpp]

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

[g_f_thomas]

Quoting - jablin@bridgetech-laramie.com

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:

[cpp]// 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();[/cpp]

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

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

Gerry

[g_f_thomas]

Quoting - g.f.thomas

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

[Mark_Jablin]

Quoting - g.f.thomas

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:

[cpp]         write (*,2500)                   !add screen output
 2500    format ('Reading Input Data .',)[/cpp]

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:

[cpp]      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[/cpp]

[g_f_thomas]

Quoting - jablin@bridgetech-laramie.com

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++ codeandrelocateit tothe 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

[Jugoslav_Dujic]

Quoting - g.f.thomas

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++ codeandrelocateit tothe 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.

[Jugoslav_Dujic]

Quoting - jablin@bridgetech-laramie.com

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

[cpp]// 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();[/cpp]

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.

[Mark_Jablin]

Quoting - Jugoslav Dujic

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.

[cpp]      BOOL bConsoleExists = AllocConsole();
      hinst = LoadLibrary(ENGINE_DLL_NAME);[/cpp]

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

[Jugoslav_Dujic]

Quoting - jablin@bridgetech-laramie.com

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

[cpp]      BOOL bConsoleExists = AllocConsole();
      hinst = LoadLibrary(ENGINE_DLL_NAME);[/cpp]

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?

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)?

[Mark_Jablin]

Quoting - Jugoslav Dujic

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.

[g_f_thomas]

Quoting - jablin@bridgetech-laramie.com

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

I posted a sample to the forum a couple ofweeks agowhere incidentally a console is allocated froman IVF dll. This has always worked.

Attach a zip ofa working sample here or to PremierSupport where you demonstrate that itdoesn't, otherwise you're just wasting everyone's time.

Gerry

[Steven_L_Intel1]

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.

[g_f_thomas]

Quoting - jablin@bridgetech-laramie.com

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.

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

Gerry

[Mark_Jablin]

Quoting - g.f.thomas

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.

[g_f_thomas]

Quoting - jablin@bridgetech-laramie.com

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

[Mark_Jablin]

Quoting - g.f.thomas

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.

[Steven_L_Intel1]

Indeed, we encourage you to use the forum first.

[g_f_thomas]

Quoting - jablin@bridgetech-laramie.com

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.

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. Doesthis 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

[Steven_L_Intel1]

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.