What is the purpose of these strange strings that are automatically included inside my exe bytes?
I found these things at the strings section of my exe while opening it with an hexadecimal editor :
libgcj-16.dll._Jv_RegisterClasses... @.Mingw runtime failure:.. VirtualQuery failed for %d bytes at address %p.... Unknown pseudo relocation protocol version %d..... Unknown pseudo relocation bit size %d.....
It seem libgcj-16.dll is related to Java, so I don't understand why this have to be there as my soft do not use Java.
The results I have found seems related to when compiling MinGW...
Using "Dependency Walker 2.2" is likely saying me that there is no need for libgcj-16.dll inside my exe.
And not any *libgcj* file is present inside my hard drive.
It's also not clear why these MinGW related text are present, when these strings will be used/displayed?
I have tried to erase all these things with 0x00 and it seem that my tiny soft is always working.
So is there a compiler option to avoid removing these by hand? That can become tricky when the strings present in the soft grow. I'm ok to eventually keep the "GCC: (tdm-1) 5.1.0", but I don't want at all anything related to Java or unused DLL, and I prefer to remove useless text.
My main.c is just :
int main(void) { return 0; }
My building commands and result :
mingw32-gcc.exe -Os -c "C:\Dev\Win32\Empty\main.c" -o obj\Release\main.o
mingw32-g++.exe -o bin\Release\Empty.exe obj\Release\main.o -s
Output file is bin\Release\Empty.exe with size 8.50 KB
I compile with Code::Block (MinGW 5.1.0). About not any building option/property is present inside my project (Console or GUI change nothing, selected platform to only Windows too). Very thanks for your hints...
--- UPDATE ---
So I do not have any functional problem with my soft, it is mainly about aesthetic "problem" with the exe hex content, as said by M.M in comments. But it is also to understand why an empty soft like this one, have already some defined strings, whereas my main.c is empty and do nothing.
I'm asking me the purpose of these predefined strings, so at what they serve? If the answer is they serve nothing inside your soft and will never be displayed and you can even not get a pointer to them, so why the compiler include them in my exe and so create useless "hex noise"...
I suspect these strings can serve and be displayed, during the compilation. (or maybe for debugging purpose)
I also suspect that these strings are coming from some linked library, like the libmingw32.a (that I have just now discovered when my Empty.exe have popup me libgcc_s_dw2-1.dll is missing, after compiling it with mingw-w64, wow I need some extra dll with gcc now! It's new to me but I suspect that my previous codeblocks version was automatically statically linking these, so I have never spot that)
And it seems that "many" libraries will be automatically "linked", even if I do not supply any linking in my building command.
Here are the process steps that are done under the hood with mingw-w64 8.1.0 :
gcc.exe -Os -static-libgcc -static-libstdc++ -c main.c -o main.o
Call C:/i686-8.1.0-release-win32-dwarf-rt_v6-rev0/mingw32/bin/../libexec/gcc/i686-w64-mingw32/8.1.0/cc1.exe -quiet -iprefix C:/i686-8.1.0-release-win32-dwarf-rt_v6-rev0/mingw32/bin/../lib/gcc/i686-w64-mingw32/8.1.0/ -U_REENTRANT main.c -quiet -dumpbase main.c -mtune=generic -march=i686 -auxbase-strip main.o -Os -o C:\DOCUME~1\Admin\LOCALS~1\Temp\ccMK0Jka.s
Call C:/i686-8.1.0-release-win32-dwarf-rt_v6-rev0/mingw32/bin/../lib/gcc/i686-w64-mingw32/8.1.0/../../../../i686-w64-mingw32/bin/as.exe -o main.o C:\DOCUME~1\Admin\LOCALS~1\Temp\ccMK0Jka.s
g++.exe -static-libgcc -static-libstdc++ -o Empty.exe main.o -s
Call C:/i686-8.1.0-release-win32-dwarf-rt_v6-rev0/mingw32/bin/../libexec/gcc/i686-w64-mingw32/8.1.0/collect2.exe -plugin C:/i686-8.1.0-release-win32-dwarf-rt_v6-rev0/mingw32/bin/../libexec/gcc/i686-w64-mingw32/8.1.0/liblto_plugin-0.dll -plugin-opt=C:/i686-8.1.0-release-win32-dwarf-rt_v6-rev0/mingw32/bin/../libexec/gcc/i686-w64-mingw32/8.1.0/lto-wrapper.exe -plugin-opt=-fresolution=C:\DOCUME~1\Admin\LOCALS~1\Temp\ccIhpVxg.res -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-ladvapi32 -plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32 -plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-liconv -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt --sysroot=C:/mingw810/i686-810-win32-dwarf-rt_v6-rev0/mingw32 -m i386pe -Bdynamic -o Empty.exe -s C:/i686-8.1.0-release-win32-dwarf-rt_v6-rev0/mingw32/bin/../lib/gcc/i686-w64-mingw32/8.1.0/../../../../i686-w64-mingw32/lib/../lib/crt2.o C:/i686-8.1.0-release-win32-dwarf-rt_v6-rev0/mingw32/bin/../lib/gcc/i686-w64-mingw32/8.1.0/crtbegin.o -LC:/i686-8.1.0-release-win32-dwarf-rt_v6-rev0/mingw32/bin/../lib/gcc/i686-w64-mingw32/8.1.0 -LC:/i686-8.1.0-release-win32-dwarf-rt_v6-rev0/mingw32/bin/../lib/gcc -LC:/i686-8.1.0-release-win32-dwarf-rt_v6-rev0/mingw32/bin/../lib/gcc/i686-w64-mingw32/8.1.0/../../../../i686-w64-mingw32/lib/../lib -LC:/i686-8.1.0-release-win32-dwarf-rt_v6-rev0/mingw32/bin/../lib/gcc/i686-w64-mingw32/8.1.0/../../../../lib -LC:/i686-8.1.0-release-win32-dwarf-rt_v6-rev0/mingw32/bin/../lib/gcc/i686-w64-mingw32/8.1.0/../../../../i686-w64-mingw32/lib -LC:/i686-8.1.0-release-win32-dwarf-rt_v6-rev0/mingw32/bin/../lib/gcc/i686-w64-mingw32/8.1.0/../../.. main.o -Bstatic -lstdc++ -Bdynamic -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -liconv -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt C:/i686-8.1.0-release-win32-dwarf-rt_v6-rev0/mingw32/bin/../lib/gcc/i686-w64-mingw32/8.1.0/crtend.o
Another truncated call similar to the very long previous C:/i686-8.1.0-release-win32-dwarf-rt_v6-rev0/mingw32/bin/../lib/gcc/i686-w64-mingw32/8.1.0/../../../../i686-w64-mingw32/bin/ld.exe -plugin C:/...
Using the mingw-w64 5.4.0 and the libgcj-16.dll will come back, as in my old mingw 5.1.0, so it seems it is a normal thing and is not related to a safety problem. (finally libgcj-16.dll is just there as a strings, and not included as a true dll, "as I understand")
Finally I get much more "strange strings" inside my exe using the mingw-w64 8.1.0... (and the size of Empty.exe have grow from 8.50KB to 13.50KB, it's not the actual subject but I'm also looking at creating the most tiny possible size, but I prefer speed instead size)
Here are the new strange things present inside Empty.exe compiled by mingw-w64 8.1.0 :
libgcc_s_dw2-1.dll.__register_frame_info.__deregister_frame_info.... c@.@`@. .@...@...@..c@. €@.........Unknown error..._matherr(): %s in %s(%g, %g) (retval=%g)...Argument domain error (DOMAIN).Argument singularity (SIGN)..Overflow range error (OVERFLOW).The result is too small to be represented (UNDERFLOW)...Total loss of significance (TLOSS)..Partial loss of significance (PLOSS)....¤@@.Ã@@.à@@..A@.8A@.\A@.Mingw-w64 runtime failure:..Address %p has no image-section. VirtualQuery failed for %d bytes at address %p.... VirtualProtect failed with code 0x%x.. Unknown pseudo relocation protocol version %d..... Unknown pseudo relocation bit size %d.....GCC: (i686-win32-dwarf-rev0, Built by MinGW-W64 project) 8.1.0
I see that my question does not interest a lot, though it seems to me an important ask to better understand what our soft contain.
So I will accept any answer that give some insightful on these "strange things"...
My main ask is : When these strange/unknown strings auto included in my exe will be used?
