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.
mingw-gcc:n hitauden syy paljastui - availee olemattomia tiedostoja ... esim cc1.exe.exe
Anonyymi-ap
0
167
Vastaukset
Ketjusta on poistettu 0 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Ymmärrän paremmin kuin koskaan
Roikut kädessäni ja vedät puoleesi. Näen kuitenkin tämän kaiken lävitse ja kaikkien takia minun on tehtävä tämä. Päästän475106- 3261918
Nainen, se auttaisi jo paljon minua
tuskissani, jos tunnustaisit sinulla olevan tunteita, vaikka et haluaisikaan suhdetta. Olisi upeaa tietää, että olen sin1131828Anja ja Janne
Eli nämä kosulan manipellet sai raploojan tubetuksen loppumaan,sitten selitellään uusimmalla videolla ettei heillä ollut701507Tässä epämiellyttävä totuus
Sinä olet henkisesti sairas ja se on epämiellyttävä totuus jota välttelet ja jota et halua kuulla sanottavan. Sinä elät681457- 811204
Elämäni rakkaus
Miten hirveästi haluaisin olla lähelläsi, halata sinua ja kuiskata monta kertaa, että rakastan sinua. Hyvää yötä! Mieh321203- 361046
- 421025
Mikä sinussa on parasta
Olet sellainen ihana kokonaisuus, että en löydä huonoa juttua. Mutta siis parasta. Tarmokkuus, pitkäjänteisyys, kädet, ä21974