I've an 25 years old Fortran app running nicely under Windows 7 and Classic mode and complied and linked under Visual Studio 2010.
Now I make a new project under Visual Studio 2015 and it compiles and links nicely under Win32 but during running the follwing happens:
My PixelFormatDescriptor is the one I've always used under Windows 7
DATA pfd / T_PIXELFORMATDESCRIPTOR (
% 40, !sizeof(T_PIXELFORMATDESCRIPTOR),
% 0, 0, 0, 0, 0, 0,
% 0, 0,
% 0, 0, 0, 0, 0,
% 0, 0, 0) /
Anyone having the same problem or having a solution to it?
We'll need to see a complete program that shows a problem. Your DATA statement is unlikely to be the cause.
I suggest you start by comparing the contents of pfd when running on each system.
If the content differs, then look at the definition of T_PIXLE...
If the contents are the same, then consult the OpenGL+GDI documentation to see if there is a difference in API between Windows7 and Windows10.
Does the application built on/for Windows 7 run on Windows 10?
I just now tried copying a program compiled with ifort to my Windows 10 computer and after installing the ifort redistributables, it ran and displayed graphics. I observe that Microsoft documents PFD_SUPPORT_GDI and PFD_DOUBLEBUFFER as being incompatible. What happens if you just drop PFD_SUPPORT_GDI? Definitely you should print out the pfd you get from DescribePixelFormat after you call SetPixelFormat.
Further experimentation showed that when pfd%dwFlags went in as
t came out as
Both on Window 8.1 and Windows 10. So that PFD_SUPPORT_GDI may just do nothing anyway.
The flag PFD_SUPPORT_COMPOSITION seems to not being supported or recognized by my installation.
Intel® Parallel Studio XE 2017 Update 1 Composer Edition for Fortran Windows* Integration for Microsoft Visual Studio* 2015, Version 17.0.0040.14
The third position in the pfd struct in my nicely running W7 version is 1077 but in the W10 case is 549. When I try force this variable to be 1077 I still the same behaviour! ;-(
I tried setting the pfd to
549 = iany([PFD_DRAW_TO_WINDOW,PFD_SUPPORT_OPENGL,PFD_DOUBLEBUFFER,PFD_SWAP_EXCHANGE])
but it came out as 33317 as before. That PFD_SUPPORT_COMPOSITION just supports things like XOR animation I think, so the difference between what you've got and what I've got seems irrelevant, because I get graphics and you don't. I will provide the full before and after pfd in my case (Windows 8.1):
40 1 549 0 32 0 0 0 0 0 0 8 0 64 0 0 0 0 24 8 4 0 0 0 0 0 40 1 33317 0 32 8 16 8 8 8 0 8 24 64 16 16 16 16 24 8 4 0 0 0 0 0
I think the graphics card and drivers might make a difference. For me it is an NVIDIA GeForce 650 GTX on Windows 8.1 and the on-chip graphics on an Atom x5-Z8330 for Windows 10. When you get the black screen of death like this in OpenGL you might have to creep along checking whether every single command worked. Every time you try to output to a new canvas it seems like you have to go through such a procedure before the first pixel is rendered. Are you relying on the contents of the previous frame or starting from scratch? This might make a difference between PFD_SWAP_COPY and PFD_SWAP_EXCHANGE.
Now I've tryed your PixelFormatDescriptors without any change in the bahaviour on my Windows10 machine
My graphic card is a Nvidia Quadro K1200
Could it be some dll-files which are missing!??
What happened on your Windows 7 machine when you tried to set pfd%dwFlags to 549? Did it stick as 549, and did OpenGL render OK? What is the graphics card on your Windows 7 machine? Did the program work only on the one machine or on a variety of different machines? When you copy the executable you compiled on the Windows 7 machine to your Windows 10 machine, does it render successfully?
What happened on your Windows 7 machine when you tried to set pfd%dwFlags to 549? Did it stick as 549, and did OpenGL render OK?
What is the graphics card on your Windows 7 machine?
Did the program work only on the one machine or on a variety of different machines?
When you copy the executable you compiled on the Windows 7 machine to your Windows 10 machine, does it render successfully?
I've also downloaded the Intel Fortran OpenGL sample project Rings. After a compiling and linking it runs nicely on my new W10 machine both as a 32-bit and a 64-bit Debug or Release version. ;-)
But when i'm adding my 150 fixed format fortran files to the project OpenGL stops rendering the rotating rings. I've then only removed my WinMain and eventloop from my files and no further changes.That is I do not call any of my routines!
After that I remove all my use ifopngl statements and also all calls to any fgl-routines. That is as I understand it, I do not refer to OpenGL at all in my entire code!
During these changes I've made tests and I got a black screen without any rings but the eventloop in the rings project works because I can still stop the program by pushing q but randomly in some rare cases I got a nicely running program. But if I restart it immediately after it DO NOT run.Something seems to be badly initialized!? ;-()
These experiencies are from using a Win32 release version.
When I try 64-bit the original rings app runs but by only adding my code, without call any of my routine, it is not possible to start it anymore
It say the program is not a valid Win32 app before the Window appears and Visual Studio claims that a x64 version is active??!
Any link warnings? It may be that your code declares large static arrays, such as in COMMON, that are larger than 2GB in total. This will cause the "not a valid" error.
Of course Steve, You are right and of course my old app has a large blank common as close as possible to 231. When I reduce the size of this both the 32-bit and 64-bit W10 versions runs smoothly and also with nice OpenGL rendering!
So now I'm happy at least for a while!... ;-)
The difference in how interactive GDI graphics is draw on top of a OpenGL is still there compared to how nice this works under W7 and clasic mode. Is there a simple solution to this or do I have to rewrite all these interactive feedback graphics into OpenGL?
I've seen a W7 complied Trinitas program running under W10 and some expensive Geforce graphic card where such a mix of GDI and OpenGL still is possible and not a problem.?? ;-()
GDI is no longer hardware-accelerated, but instead rendered to system memory using the CPU. That rendering is later composed on a 3D surface in order to be shown on the desktop. The graphics hardware video driver is no longer involved in GDI rendering, which means that mixing GDI and accelerated 3D rendering in the same window is likely to produce corruption like stale or blanked 3D rendering, trails, etc. Using Microsoft's OpenGL software rendering (the first item in the four OpenGL implementations) will achieve GDI compatibility, but at the expense of rendering speed and lack of modern features. https://www.opengl.org/pipeline/article/vol003_7/
I think you are on a very sticky wicket trying to mix GDI and OPENGL......
I've still general problems with my Visual Studio 2015 and Window 10 version of my program. I'll try describe two different problems
I've now managed to run the program both in debug and release mode in 32-bit version. But when trying to solve a bit larger banded linear system of FE-equations of about 111000 unknowns an allocation statement fails as follows
INTEGER*4,ALLOCATABLE, SAVE :: rowIndex (:)
INTEGER*4,ALLOCATABLE, SAVE :: columns (:)
REAL*8, ALLOCATABLE, SAVE :: global_matrix (:)
LOGICAL ,ALLOCATABLE, SAVE :: MatrixIndex (:)
NO_STIFFNESS_COEFFICIENTS = 113100600
I got an Intel Visual fortran error
Forrtl: severe (41) insufficient virtual menory
This example runs smoothly on my Windows 7 system
The second problem I've is associated to the 64-bit version. In both debug and release mode it starts opening the window but it remains completely white and the program seem to continue running in the background waiting for mouse events etc. My BlankCommon is now very small...
It's not clear to me from your description whether your original program has ever run correctly on a 64-bit system. If this is the first time you have tried to make it work on such a system then it's expected that you will have some problems. The first warning sign is the use of INTEGER*4 declarations, because some INTEGER variables (mostly pointers and handles) are promoted to INTEGER*8 in the transition from 32 to 64 bits. Intel Fortran doesn't have a compiler switch like -Wconversion that gfortran has that would catch most of these usages, but you can track down the ones that require ifort extension by eliminating causes of warnings such as #6075.