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
4
481
Vastaukset
- Anonyymi
kas kummaa!
- Anonyymi
Onhan se Helvettiä sinänsä! Mutta jotkut ei tiedä paremmasta!
On se sellaista tuskaa! Ei sitä uskoisi mutta kun käyttää jotai toimivaa OS:ää niin silloin huomaa miten ongelmallinen Windows on!
Onhan se kamala, jatkuvasti hypii jotain silmille, ei vaan mainoksia vaan ihan Windowsin tai edgen tai jonkun ohjelman ohjesivuja tai muita.
Windows 8 jäälkeen W7 hidastettiin oikeen huolella ennen w10 ilmestymistä, jotta w10 ei näyttäisi niin raskaalta, W11 on samaa luokaa raskaudeltaan mutta muistinkulutukseltaan ihan omaa luokaansa. W11 on otetty "moniajo pois" että se tuntuisi kevyemmältä.
Teet jotai työtä joka ottaa aikaa ja ajattelet mm lukea netistä uutiset silläaikaa.
Paska. se työ on sammutettu siellä takana eikä etene mihinkään kun sivu ei ole aktiivinen.
W11 ei kykene tekeen kuin yhtä asiaa kerrallaan!
Microsoft keskeytti Windows 11 -päivityksen automaattisen jakelun – ”Saattaa heikentää pc:n suorituskykyä rajusti”
Samalla se aiheuttaa lämmöntuottoa kun Windowsista tulee jatkuvasti raskaampi.
Levyllekin se kirjoitaa taukoamatta vaikket tekisi sillä mitään. Ei siis ihme että SSD paukahtaa.
BT ja Wlan on edeleen Windowsin ongelmalistalla, tahmaamisessa ja katkomisessa.
Kuvansumennus vaan jatkaa ja 4 ytimen ongelmaa ei saada korjattua.
Lisäksi windows ei lue ja kirjoita yhtäaikaa, edes että kopioisi levyltä toiselle.
Linuxit tekee niin että toista luetaan ja toista kirjoitetaan yhtäaikaa.
Windows ensin lukee ja sitten kirjoittaa. Ja se on hidasta.
Windowsilla tahkoaminen on muutosvastarintaa,.
Sellasita!
- Anonyymi
Jos windowsin tiedostojärjestelmä on olemattomien tiedostojen kohdalla hidas, niin minkäs sille voi.
- Anonyymi
"Jos windowsin tiedostojärjestelmä on olemattomien tiedostojen kohdalla hidas, niin minkäs sille voi"
Kyse ei ole pelkästään esim. tekstitiedoston avaamisesta, vaan PROSESSIN luomisesta.
Ja tuo prosessin luominen on (suhteellisesti) hidasta.
Toki, jos yrittää suorittaa vaikkapa cc1.exe.exe, niin tuon luulisi olevan nopeaa, koska cc1.exe.exe -tiedostoa ei ole olemassa, ei olemattomalle EXE -tiedostolle tarvitse prosessiakaan luoda.
Mutta jos yritetään cc1.exe.bat tai cc1.exe.cmd, niin tuolle luodaan aina prosessi käyttäen cmd.exe - ja koska tuossa oikeasti luodaan prosessi, niin se ottaa aikansa.
prosessin luominen windowsissa on hitaampaa kuin linuxissa.
Sensijaan uuden säikeen luominen jo olemassaolevaan prosessiin windowsissa on erittäin nopeaa.
Linuxin kernelhän kärsii tässä tietynlaisesta myopiasta, eli linux kernelille prosessi ja säie on melkein sama asia (ainoa ero on siinä, että säie jakaa muistiavaruuden muiden saman prosessin säikeiden kanssa, mutta prosessi ei jaa muistiavaruuttaan).
Windowsissa säikeiden ja prosessien käsittely on täysin erilaista, eikä windowsissa ole tuollaista kummallista ongelmaa mikä linuxissa on.
Moni täällä kuvittelee, että linux = parempi kuin windows.
On tosiaan YKSI asia, missä linux on ihan oikeastikin parempi kuin windows, ja se on TCP/IP -pinon laadukkuus. Linuxissa on paremmin tehty TCP/IP -pino kuin windowsissa.
Oikeastaan kaikessa muussa nimenomaan windows on parempi kuin linux.
Aivan erityisesti muistinhallinta on asia, jonka Microsoft osaa erinomaisen hyvin.
Linuxissa taas koko muistinhallinta on surkea viritys.
Miksiköhän windowsissa ei tarvita OOM killeriä.
Windowsissa on asialliset muistinhallintafunktiot, kuten VirtualAlloc, VirtualFree, VirtualProtect jne.
Linuxissa teeskennellään, että C -kielen malloc() ja free() riitää kaikkeen.
No, tavallaan "riittää" mutta seuraukset ovat kaameat.
Linux kernel olettaa, että ohjelma käyttää vain pienen osan malloc():lla varaamastaan muistista.
JOS ohjelma varaa muistia PALJON käyttäen malloc() ja sitten ohjelma oikeasti käyttää kaiken malloc():lla varaamansa, linuxissa alkaa silloin OOM killer toimia.
Windowsissa osaava ohjelmoija ei tietenkään tee muistinhallintaa C -kielen malloc() ja free() -funktioilla, vaan käyttää VirtualAlloc, ja osaa käyttää oikein MEM_RESERVE ja MEM_COMMIT -lippuja.
Ketjusta on poistettu 1 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
- 1077773
Siekkilässä ajettu ihmisten yli- mitä tapahtui? Länsi-Savo ei ole uutisoinut asiata
Manneja, vaiko matuja?1126036- 835187
- 1394546
Alavuden sairaala
Säästääkö Alavuden sairaala sähkössä. Kävin Sunnuntaina vast. otolla. Odotushuone ja käytävä jolla lääkäri otti vastaan113230- 633014
- 582948
Törkeää toimintaa
Todella törkeitä kaheleita niitä on Ylivieskassakin. https://www.ess.fi/uutissuomalainen/8570818102454- 612437
Hei........
Pelkkä sun näkeminen saa mut hymyilemään pitkin iltaa. Oot niin 🤩😘 Edellinen poistettiin.562066