mingw-gcc:n hitauden syy paljastui - availee olemattomia tiedostoja ... esim cc1.exe.exe

Oma ohjelmani, jonka tarkoitus oli hieman "vakoilla" mitä MinGw-gcc -kääntäjä Windowsissa tekee (siis lähinnä seurata, mitä tiedostoja se yrittää avata tai luoda, ja onnistuiko ko. yritys vai menikö pieleen)... Mutta tulos EI ollut aivan sitä mitä olisi odottanut ...

OpenFAILed 11324 0000351C /mingw/share/locale/fi_FI/LC_MESSAGES/gcc.mo
OpenFAILed 11324 0000351C /mingw/share/locale/fi/LC_MESSAGES/gcc.mo
Created 11324 0000351C C:\Users\HP\AppData\Local\Temp\ccPEkRHR.s
Opened 11324 0000351C CONOUT$
OpenFAILed 11324 0000351C z:\mingw\bin\..\libexec\gcc\mingw32\9.2.0\cc1.exe.com
OpenFAILed 11324 0000351C z:\mingw\bin\..\libexec\gcc\mingw32\9.2.0\cc1.exe.exe
OpenFAILed 11324 0000351C z:\mingw\bin\..\libexec\gcc\mingw32\9.2.0\cc1.exe.bat
OpenFAILed 11324 0000351C z:\mingw\bin\..\libexec\gcc\mingw32\9.2.0\cc1.exe.cmd
Opened 11324 0000351C z:\mingw\bin\..\libexec\gcc\mingw32\9.2.0\cc1.exe
Opened 11324 0000351C CONOUT$
OpenFAILed 11324 0000351C z:\mingw\bin\..\lib\gcc\mingw32\9.2.0\..\..\..\..\mingw32\bin\as.exe.com
OpenFAILed 11324 0000351C z:\mingw\bin\..\lib\gcc\mingw32\9.2.0\..\..\..\..\mingw32\bin\as.exe.exe
OpenFAILed 11324 0000351C z:\mingw\bin\..\lib\gcc\mingw32\9.2.0\..\..\..\..\mingw32\bin\as.exe.bat
OpenFAILed 11324 0000351C z:\mingw\bin\..\lib\gcc\mingw32\9.2.0\..\..\..\..\mingw32\bin\as.exe.cmd
Opened 11324 0000351C z:\mingw\bin\..\lib\gcc\mingw32\9.2.0\..\..\..\..\mingw32\bin\as.exe

Tuossa yllä on kullakin rivillä: 1. status (onnistuiko ko. toiminto)
2. ProcessID
3. ThreadID (Hex)
4. tiedostonimi, jota gcc.exe yritti luoda/avata.

Ei mikään ihme, että autoconf/automake -pohjainen kääntöjärjestelmä on windowsissa aivan järkyttävän hidas, tuo ylläoleva kun paljastaa syyn moiseen hitauteen.
tuo kääntöjärjestelmä kun luo varmaan sata yksinkertaista c -kielistä testiohjelmaa ja
kääntää tai yrittää kääntää nuo pienet testiohjelmat testatakseen, mitä toimintoja
C -kääntäjä (siis gcc.exe) tukee (OIKEIN!) ja mitä ei.
siis esim. "testing if C-Compiler works ... (testaa, hitaasti) ... YES.
testing if (joku lisäoptio, jota Mingw-gcc:n yhteydessä ei ole asennettu) ... (testaa, hitaasti) ... NO.

siinä, missä jokin muu ohjelma yksinkertaisesti ajaisi ohjelman cc1.exe, niin gcc.exe ensin epäonnistuneesti YRITTÄÄ ajaa kaikki nämä 4 tiedostoa:
1. cc1.exe.com
2. cc1.exe.exe
3. cc1.exe.bat
4. cc1.exe.cmd
ja vasta, kun kaikki nämä neljä yritystä on epäonnistunut, sitten se lopulta ajaa: cc1.exe - sen ainoan, joka noista vaihtoehdoista on oikein.

Ei mikään ihme, että tuo autoconffaus windowsissa on hidasta!

Ensinnäkin, uuden prosessin luonti on muutenkin windowsissa selvästi hitaampaa kuin linuxissa
(tosin, uuden säikeen luominen saatta toisaalta olla windowsissa nopeampaa kuin linuxissa)

Ja tuossa ensin luodaan/yriterään luoda 4 prosessia, jotka kaikki epäonnistuvat, ennen kuin lopulta luodaan se prosessi, mikä sitten onnistuu!

Riippuen, miten mingw on sisäisesti rakennettu (eli käyttääkö CreateProcess vai ShellExecute)
niin nuo ".com" ja ".exe" saattavat jäädä epäonnistuneiksi yrityksiksi luoda prosessia.

Mutta ".bat" ja ".cmd" -niissä luodaan aina prosessi "cmd.exe", mutta kun homma epäonnistuu,
niin "cmd.exe":lle annetaan parametriksi olemattoman .BAT tai .CMD -tiedoston nimi, jolloin
cmd.exe palauttaa kutsujalleen virhekoodin "File Not Found!".
Tämän automake/autoconf ilmeisesti testaa tyyliin "if errorlevel 1 goto Encountere_error".

Miksi avoimen lähdekoodin systeemeistä (kuten MinGw-gcc) löytyy noin huonoa/hidasta koodia ?

ja ihan sama toistuu myös as.exe:n kohdalla - myös siihen gcc.exe
yrittää kokeilla noita tarpeettomia ja virheellisiä com, exe, bat ja cmd -päätteitä.

(siis tyyliin as.exe.exe)
Olisi varmaan voinut testata ensin suoraan koodissa: JOS tiedostonimi jo muutenkin loppuu ".exe"
niin ei siihen pidä enää lisäillä muita suorituskelpoisia päätteitä tuon ".exe" perään,
koska silloin syntyy juurikin noita naurettavia "as.exe.exe" -tiedoston avausyrityksiä.

Oma ohjelmani siis toimii näin:

1. Muokkasin gcc.exe:ä binäärieditoimalla niin, että se kutsuu omatekoisen DLL:n osaksi prosessiaan,
ja tuo omatekoinen DLL patchaa Windows API -funktion CreateFileW (jota muuten myös CreateFileA kutsuu, muunnettuaan ensin Windows-1252 -koodauksella olevan tiedostonimen UTF-16LE -enkoodatuksi unicodeksi).

2. Tuo patchattu versio CreateFileW -funktiosta sitten kutsuu alkuperäistä CreateFileW -funktiota,
mutta raportoi toiselle ohjelmalle (joka näyttää asiat GUI -liittymässä näytöllä)
siitä, minkänimisen tiedoston gcc.exe yritti avata / luoda, sekä siitä, onnistuiko ko. yritys vai ei.

Tarkoitus oli, että jos annan vaikkapa komentoriviltä komennon:

gcc -c testi1.c

niin oletin, että tuo patchattu versio olisi listannut:

Opened testi.c
Opened testi.h

Created testi.o

.. mutta unohdin, että eihän gcc.exe oikeasti ole c-kääntäjä, vaan driveriohjelma, joka käynnistää varsinaisen c -kääntäjän cc1.exe sekä sille assemblerin/linkkerin