On Sun, 4/5/2026 5:51 AM, Jean-Pierre Coulon wrote:
Since the last Windows-10 update I obtain this window, when I start either one:
myexecutable.exe - Entry point not found
the procedure entry point _fmode_dll could not be located in the dynamic link library <myexecutable>
when I start one my g77-compiled executables, which have run OK for the last 10 years.
Am I the only one?
One thing I do in situations like this, is:
1) Get a copy of Process Monitor
https://learn.microsoft.com/en-us/sysinternals/downloads/procmon
2) Run the gFortran executable on the working setup,
while Procmon is in capture mode. This will show the
loading of DLLs from the environment, as the program
dependencies are loaded. From this, you can develop
a basic understanding of runtime things the program is using.
A filter of "Readfile()" as an Operation, plus a process name
of myexecutable.exe , can highlight the DLL loading going on.
3) Now, run the gFortran executable on the non-working setup,
and see how far into the dependency loading sequence it
gets, before it stops. While installing some Visual Studio thing
might be the actual solution, I can't tell you why that would be
necessary. It should have worked with what was on the system at
the time.
There are a couple versions of DependencyWalker that allow
listing dependencies.
Another way to do dependency analysis, is to upload the
EXE to virustotal.com and have it processed. The various
tabs in virustotal.com can show what the dependency list is
for the program. Doing this is subject to privacy concerns,
for example if you don't want the executable shared with
Google. Virustotal used to be a private site, but
Google bought it.
The usage of Process Monitor in this way, is a compromise.
It all depends on whether you can stomach the other methods
or not, in measuring dependencies.
*******
Windows changed the handling of DynDLLs. There were some older
programs (gnuwin32), that used dyndll calls to load their dependencies.
In the console, if a dependency was missing on an older OS,
there would be an explicit message indicating which file the
loader could not find.
On the newer OSes, this behavior is suppressed, and as users
we have to sit here and "guess" at what is missing. Using
Process Monitor, I can see the "File Not Found", then go into
my gnuwin32 supply of libs and fix that.
Summary: Nothing comes to mind, as to why your program suddenly broke.
Statically compiled programs should "need nothing" from the environment.
The implication, is that there is still some runtime
component your program needs. If the runtime was acquired via
the DynDLL mechanism, modern Windows doesn't behave
properly for those. It still successfully loads the item
when it is present, but it does not generate the error
message necessary to go off and find the missing file.
Paul
--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)