I'm on Windows 7 Home Premium 32 bit, using i686-8.1.0-win32-dwarf-rt_v6-rev0. Just like tcurrent build, I had same problem with previous installed buil, a i686-7.2.0-win32-dwarf...
Below code results in NO call to main() (I have not examined whether main() is even linked in to the executable):
#include <stdio.h> #include <windows.h> // Sleep() int main(int argc, char **argv) { printf("abc"); // does nothing Sleep(3000); // does nothing return 0; }
With below modification however, main() IS called:
#include <stdio.h> #include <windows.h> // Sleep() int main(int argc, char **argv) { FILE *file_p = fopen("<path-to-whatever-even-non-existant>", "r"); printf("abc"); // prints "abc" Sleep(3000); // sleeps for 3 seconds return 0; }
For your info, Digital Mars compiled executable of first example runs as expected.
Hello
you misinterpreted that what you saw. Of couse the main-function is
called, and linked. Otherwise the binary couldn't be linked at all.
Exisitance of main() (or equivalent) is a strict requirement for a
executable.
The issue you see is t1he stream flushing. You print something to
stdio, Then you call system sleep. Finally exiting the application.
It could be pretty helpful to know how you invoke compilation of your
little program. I would assume you are using either direct, or
indirect the gui-variant. As for this indeed stdio (along with other
standard streams) isn't connected to your console, and therefore you
don't see anything. By opening a file you indirectly initialize those
streams.
Of couse it could be something else too, but to learn more we would
need more details about how you build executable (options used), what
msvcrt you are using, what distro, etc
Kai
Am Sa., 27. Okt. 2018 um 13:50 Uhr schrieb oinet oinet@users.sourceforge.net:
Related
Bugs: #765
A process needs to start at a certain position whose address is in the PE header. main() is then called (or jumped to) by that start routine. Anything can pontentially be happening. How would I know if linker isn't instructed to link in a "debug"/diagnostics main() that does it's own thing (whatever that may be), and then exits.
I'm using commandline: gcc -o _prog.exe main.c -Wall -Wl,--subsystem,console
That's what I throught initially (regarding the problem with output function being uninitialized streams), but then I decided to also call a (to be sure) non-clib function, in this case, a Win32 function. Indeed, that function (Sleep()) didn't do anything, suggesting one of multiple things two among which could be:
1) My main() is not called, because a custom main() (or a custom startup alltogether) is linked in whose purpose is what I wrote in my first paragraph.
2) Something to do with exceptions, causing silent exit due to clib not being initialized.
As I wrote in my original post, I use Windows 7 Home Premium 32-bit.
About msvcrt.dll below.
--- According to Windows 7 file properties ---
File version: 7.0.7601.17744
Product version: 7.0.7601.17744
--- According to Dependency Walker ---
File version: 7.0.7601.17744
Product version: 6.1.8638.17744
A quick test (load) in x64dbg (which I'm not much familiar with). Logs from x64dbg (actually x32dbg, the 32-bit version) below after each file has "executed".
--- _prog-fopen.exe ---
--- _prog-no-fopen.exe ---
So in the faulty executable's case, after ntdll.dll is loaded, and before kernel32.dll is loaded, process stops.
Last edit: oinet 2018-10-29
I just compiled the the example without fopen() in the latest (3 years old now) TDM-GCC which contains gcc/mingw-w64 version 5.1.0. The built executable runs as expected, no problem.