Size of stack affect Windows dialog

[jansson]

Hi,

I have a problem calling the Windows function GetOpenFileName() from my program.
What hapens when I call it depends on the stack size I requested.

When I set the size of Linker->System->stack reserve size to

200 M it opens the dialog box and I can sellect a file after about 3 s. (Debug compiled)
300 M the call stals for a while, do not show a dialog box, but returns in about 7 s.
400 M call do not return, I waited at least 60s.

I attach my Win32, Quickwin Project showing this behavior.

I use this call in my OpenMP project and there I need to set a large stack to start/run my program.
Can somone enlighten me if this is a feature, a Windows bug of a compiler bug?
Or am I doing something wrong?

Is there a workaround for the large stack size needed to start my program?

My setup:
Core i7 , 4 GB memory
windows 7 64 bit.
vs2010
Compiling with Intel Visual Fortran Compiler XE 12.0.2.154 [IA-32]...

Regards,Magnus

EDIT:
If i just after GetOpenFileName insert
iret=CommDlgExtendedError()
I get iret=0 for 200M and iret=2 for 300M.
Futher I noticed that for 400M it do return after 140s with iret=2
googling I find at msdn.microsoft.com
--

CDERR_INITIALIZATION 0x0002

The common dialog box function failed during initialization. This error often occurs when sufficient memory is not available.

--

What units are used when setting stack size?

Could I be out of some special sort of windows memory?

[anthonyrichards]

Just to get things clear, you are creating a 32-bit Quickwin Windows application and running it on a 64-bit system?

Have you tried removing the GetOpenFileName call from the Program file that runs in a seperate thread from the Quickwin stuff and activating it from a menu call-back function to see if that works independently of stack size? I do not see the point of having it in the location you choose for it, as any filename selected has no where to go to.

[tropfen]

my system has 64bit.

yes this test dummy is in 32bit (most of the users of my programm have 32bit systems)

I have the same probleme working with win vista prof 32 bit

All i looking at , with this test dummy is, does the OpenFile dialog is opening or not.

Using the produced exe-file on a win xp system i have no problem at all

Frank

[anthonyrichards]

You are not alone - see this link:

http://social.msdn.microsoft.com/Forums/en-US/windowscompatibility/thread/370fe7a7-a9b0-4824-833a-4ed3f3a05504/

It finishes by saying

"This still is not fixed in Vista SP2, BUT it is fixed in Windows 7 RC!"

although your experience would appear to be the opposite.

I also note from here http://www.codeproject.com/KB/vista/VGFileDialogs.aspx#usingwithapis

that

"

Using the File Dialogs with Windows APIs

If an app calls the GetOpenFileName() or GetSaveFileName() API to show a file dialog, and does not customize the dialog at all, then Vista will show the new file dialog since there is no danger of breaking the app. The criteria that Vista uses to determine if the app customizes the dialog is whether there is a hook function address stored in the lpfnHook member of the OPENFILENAME struct, or a custom dialog template stored in the lpTemplateName member.

Since MFC and WTL use a hook function to provide notifications to the app, if you use either library's CFileDialog class, you will get the Windows 2000-style dialog. Therefore, to get the Vista-style dialog, you'll need to use the new COM interfaces that replace the GetOpenFileName() and GetSaveFileName() APIs.

"

SO perhaps you should dispense with the hook flag and procedure and try again.

Also check what version of comdlg32.dll is being loaded/required.

[tropfen]

Hello,

thanks a lot for providing the interesting links.

you are writing:
...SO perhaps you should dispense with the hook flag and procedure and try again.
Also check what version of comdlg32.dll is being loaded/required.

To be honest. I do not have any clue how to do it.

Any help will be appreciated.

----

But be the way. Why is this not reproducible be Intel (Steve). All I have is a normal (ok German) installation including all offline updates until February.

Thanks in advance

Frank

[Steven_L_Intel1]

My example did not use the hook procedure. You don't need the hook procedure.

[Steven_L_Intel1]

I can reproduce strange behavior on Windows 7 x64 with the 32-bit program and the 300000000 stack size. I have no idea why it happens, but that is a rather large stack. This happens even if I don't use the hook procedure (which as I say above you do not need.) I don't know what the problem is here, though what I can see is that the call to GetOpenFilename takes a lot of CPU for a while but does nothing and eventually returns.

[tropfen]

Hello Steve,

for a test dummy a stack size of 300MByte may be high. If you are working with climate model simulation results, data sets easily contain data with TeraByte. To visualize those data I need the full range of possible stack size.

Is this an IVF or a windows problem? Can this problem be solved?

Frank

[tropfen]

Hello Steve,

for a test dummy a stack size of 300MByte may be high. If you are working with climate model simulation results, data sets easily contain data with TeraByte. To visualize those data I need the full range of possible stack size.

Is this an IVF or a windows problem? Can this problem be solved?

Frank

[Steven_L_Intel1]

Definitely not an Intel problem. It may be a Win32 API issue but it's hard to tell. May I suggest that using /heap-arrays (and allocatable variables) is a better choice than a huge stack?

[Shabanloui]

Dear Steve,

I am using Intel Fortran Compiler for my application since 2010. I have the same Problem, as mentioned above in the post. It means, if I reserve a very low stack size, e.g. 100Mb, my program works. But If I increase the stack size, then the Programm started, but "GetOpenFileName" has allways Problem. It doesn't let to open the Open Window. Do you have any idea? It is very important for me. But all of my works, which I developed since 2010, depends on this issue!

Looking forward to hearing you!

Cheers,

Akbar

[Steven_L_Intel1]

Sorry, I have no more information than what is in this thread. You can try reducing the stack size and enable heap arrays (Fortran > Optimization > Heap Arrays > 0) and see if that helps.