M-Karin höpinät Delphi -ohjelmien toimivuudesta Windows 10:ssä voi pääosin jättää omaan arvoonsa.
Tänään kun selasin MSDN -sivustoa, tasan KAHDEN API -funktiokutsun kohdalla oli ihan Microsoftin julkaisemana tällainen maininta:
"Important This API is deprecated. New and existing software should start using **** SENSUROITU ****. Microsoft may remove this API in future releases."
(Minulla on omat syyni, miksi en halua mainita, mistä API -funktiosta on kyse).
Kun Delphi -ohjelmat tyypillisesti käyttävät jopa satoja eri API -funktioita, ja niistä kahden (joista kumpaakaan EI KÄYTETÄ kaikissa Delphi -ohjelmissa) kohdalla on tuo varoitus siitä, että Microsoft saattaa poistaa ko. funktion Win10:n myöhemmissä julkaisuversioissa, niin näinollen M-Karin höpinät aiheesta ovat täysin ylimitoitettuja.
Mitä itse aion tehdä?
Juuri sen, mitä MIcrosoftin olisi pitänyt tehdä jo KAUAN sitten, jos tosissaan aikoo ruveta mielestään vanhentuneita API -kutsuja poistamaan:
Laatia listan, jossa on KAIKKI Windows API (32-bit) funktiot, ja jokaisen kohdalla merkintä siitä, kuuluuko funktio poistettavien listalle vai ei kuulu.
On aivan käsittämättömän törkeää, ettei Microsoft ole jo kauan sitten julkaissut tuollaista listaa.
Toki M-Karkin on linkannut tänne jonkun "deprecated APIs " -listan, mutta se ei ole ihan sama asia.
Oikein on nimenomaan listata aakkosjärjestyksessä yksittäiset funktiot, ja jokaisen kohdalle tieto, onko MSDN:ssä varoitus ko. funktion poistamisesta vai ei ole.
Lopuksi aion tehdä kaikista Delphi -projekteistani (EXE ja DLL) listan, mitä API -funktioita ko. projekti käyttää, ja tehdä yhteernvedon, jossa kaikki projektit on tavallaan "laskettu yhteen" eli lista, jossa on kaikki ne API -funktiot, joita 1 tai useampi projektini käyttää.
Lopuksi ristiinajo tuon Microsoftin "poistolistan" kanssa, niin näkee, mikä on oikeasti vaarassa ja mikä ei.
Sinänsä muuten tämä ongelma EI koske mitenkään erityisesti Delphiä, vaan aivan sama koskee esim. Microsoft Visual C :lla tehtyjä ohjelmia.
Toki MS on voinut rakentaa oman MFC systeeminsä niin, että siinä ei käytetä poistolistalla olevia funktioita.
Tämä ei kuitenkaan sinänsä auta MS Visual C :n käyttäjiä mitenkään, sillä voihan C -ohjelmassakin käyttää myös suoraan API -funktiokutsuja, ei pelkästään MFC:n kautta.
Eli noiden poistolistalla olevien osalta ongelma koskee ihan tasapuolisesti kaikkiza ohjelmistokehitystyövälineitä.
Lisäksi olisi syytä myös selvittää: Niiden funtioiden osalta, joissa ko. poistovaroitus on, kauanko varoitus on siellä ollut?
Itse näin ko. varoituksen ensimmäistä kertaa hetki sitten, ja MSDN:ää on tullut selattua aika paljon!
Väittäisin, että M-Karin varoitukset siitä, että MS olisi jo vuosia sitten sanonut "älkää käyttäkö näitä funktioita" ovat täysin tuulesta temmattuja. Kyllä ne varoitukset ovat MSDN:n kutakin funktiota kuvailevalle sivulle laitettu vasta vuonna 2017.
Siis ennen tätä päivää en ole MSDN:ssä nähnyt tuollaista poistovaroitusta YHDENKÄÄN API -funktiokutsun kuvauksessa !
M-Karin höpinät Delphi-ohjelmien toimivuudesta W10
25
369
Vastaukset
- Kokemus-opettaa
Eikö niitä ulkoisia kirjastoja voi varastoida oman projektin kansioon. Silloihan kaikki external -viittaukset säilyttävät toimintansa, kun vain niiden riippuvuudet ovat myös ohjelman tavoittettavissa. Jos oikein muistan, lista riippuvuuksistahan näkyi *.DDL kirjaston alussa.
Minun on pakko kyllä myöntää että on jo liian paljon aikaa, kun olen viimmeksi, omassa tekeleessäni kutsunut ulkoisen *.DLL kirjaston funktiota oman ohjelman sisältä. - ex-delphisti
"EI koske mitenkään erityisesti Delphiä, vaan aivan sama koskee esim. Microsoft Visual C :lla tehtyjä ohjelmia."
Kieltämättä, töissä käytössä päivittäin SQLYog Windows 10 Enterprise käyttis, kovin näyttää Windows API koodattuna tuo koodi, tai siihen nojautuvan framen kautta. Joku kaunis torstai tämä softa vissiin lakkaa toimimasta :)
https://github.com/webyog/sqlyog-community/blob/master/src/WinMain.cpp- ex-delphisti
Tuli tuosa Lazaruksesta mieleen, että ei kait se mikään pakko winukan puolella ole välttämättä WinApiin nojautua ne LCL-komponentit, että kun aika jättää winapista, niin eikö siirto uudempaan rajapintaan onnistu? Ja muissa käyttiksissä muutenkaan mitään winapia ole käytössäkään.
ex-delphisti kirjoitti:
Tuli tuosa Lazaruksesta mieleen, että ei kait se mikään pakko winukan puolella ole välttämättä WinApiin nojautua ne LCL-komponentit, että kun aika jättää winapista, niin eikö siirto uudempaan rajapintaan onnistu? Ja muissa käyttiksissä muutenkaan mitään winapia ole käytössäkään.
FreePascal ei käännä .NET:lle, Windowsissa tällä hetkellä sillä ei ole mitään tulevaisuutta.
- Kysyjäkin2
M-Kar kirjoitti:
FreePascal ei käännä .NET:lle, Windowsissa tällä hetkellä sillä ei ole mitään tulevaisuutta.
(Tarkoittanet Lazaruksen LCL-kirjastoa). Mutta se kääntyy esim. QT:lle ja GTK:lle. Ovatko nämäkin tuhoon tuomittuja windowsissa?
Kysyjäkin2 kirjoitti:
(Tarkoittanet Lazaruksen LCL-kirjastoa). Mutta se kääntyy esim. QT:lle ja GTK:lle. Ovatko nämäkin tuhoon tuomittuja windowsissa?
GTK on kyllä. Tällä hetkellä Qt:llä menee paremmin kun tekivät siihen sen tulkattavan QML:n. QML pitäisi olla helposti siirrettävissä .NET:lle.
LCL tosin käyttää Qt:ssä niitä vanhoja C komponentteja joten LCL on kyllä väistämättä mätä Windowsissa.Kysyjäkin2 kirjoitti:
(Tarkoittanet Lazaruksen LCL-kirjastoa). Mutta se kääntyy esim. QT:lle ja GTK:lle. Ovatko nämäkin tuhoon tuomittuja windowsissa?
Jos nyt muuten ihan väistämättä haluaa Pascalilla haluaa tehdä ohjelmia niin Debian olisi tuohon varsin ideaalinen alusta, ei Windows.
Lazarus ei kyllä Pascalille koodia tehtäessä ole nyt varmaankaan se paskin IDE kuitenkaan mutta voisi olla ideaa unohtaa LCL ja tehdä REST rajapinta, ja sitten käyttöliittymä siihen sopivilla välineillä.- Kysyjäkin1
M-Kar kirjoitti:
GTK on kyllä. Tällä hetkellä Qt:llä menee paremmin kun tekivät siihen sen tulkattavan QML:n. QML pitäisi olla helposti siirrettävissä .NET:lle.
LCL tosin käyttää Qt:ssä niitä vanhoja C komponentteja joten LCL on kyllä väistämättä mätä Windowsissa.Jos QT ja GTK kirjastot kaatunevat windowsissa tulevaisuudessa miten sitten on Java? (Näköjään aika paljon windossi softaa kaatuu )
Kysyjäkin1 kirjoitti:
Jos QT ja GTK kirjastot kaatunevat windowsissa tulevaisuudessa miten sitten on Java? (Näköjään aika paljon windossi softaa kaatuu )
Ei silläkään ole tulevaisuutta.
Kaikki GUI ohjelmointi Javalla Android API poislukien on käytännössä täysin kuollutta jo nyt,
Siitä olisi hyvä läheä, että Windows 10:ssä ajetaan vain käyttöliittymäpuolta ja edustakoodia. Tallennus ja taustaprosessointi on sitten palvelimessa.
Käyttöliittymäkoodi tehdään tekniikalla joka toimii selaimessa, tai sitten Microsoftin natiivia WinRT:tä. Poikkeuskeisseihin on .NET 4.x framework koko laajuudessaan ja pelimoottoreita ja vastaavia middlewareja varten näyttäisi jäävän joku riisuttu 64-bittinen Windows API. Hyvän kuvan saa siitä kuinka riisuttu olisi kyseessä olisi se, että kaikki käyttöliittymäkoodi pitäisi toimia DirectX:n varassa,
Mitään olennaista Windows softaa ei mene. Melkein kaikki toimii Edgen kautta. Muista että ohjelmat yleisesti ottaen kirjoitetaan uusiksi aika ajoin.Kysyjäkin1 kirjoitti:
Jos QT ja GTK kirjastot kaatunevat windowsissa tulevaisuudessa miten sitten on Java? (Näköjään aika paljon windossi softaa kaatuu )
Ei silläkään ole tulevaisuutta.
Kaikki GUI ohjelmointi Javalla Android API poislukien on käytännössä täysin kuollutta jo nyt,
Siitä olisi hyvä läheä, että Windows 10:ssä ajetaan vain käyttöliittymäpuolta ja edustakoodia. Tallennus ja taustaprosessointi on sitten palvelimessa.
Käyttöliittymäkoodi tehdään tekniikalla joka toimii selaimessa, tai sitten Microsoftin natiivia WinRT:tä. Poikkeuskeisseihin on .NET 4.x framework koko laajuudessaan ja pelimoottoreita ja vastaavia middlewareja varten näyttäisi jäävän joku riisuttu 64-bittinen Windows API. Hyvän kuvan saa siitä kuinka riisuttu olisi kyseessä olisi se, että kaikki käyttöliittymäkoodi pitäisi toimia DirectX:n varassa,
Mitään olennaista Windows softaa ei mene. Melkein kaikki toimii Edgen kautta. Muista että ohjelmat yleisesti ottaen kirjoitetaan uusiksi aika ajoin.- Kysyjäkin12
M-Kar kirjoitti:
Ei silläkään ole tulevaisuutta.
Kaikki GUI ohjelmointi Javalla Android API poislukien on käytännössä täysin kuollutta jo nyt,
Siitä olisi hyvä läheä, että Windows 10:ssä ajetaan vain käyttöliittymäpuolta ja edustakoodia. Tallennus ja taustaprosessointi on sitten palvelimessa.
Käyttöliittymäkoodi tehdään tekniikalla joka toimii selaimessa, tai sitten Microsoftin natiivia WinRT:tä. Poikkeuskeisseihin on .NET 4.x framework koko laajuudessaan ja pelimoottoreita ja vastaavia middlewareja varten näyttäisi jäävän joku riisuttu 64-bittinen Windows API. Hyvän kuvan saa siitä kuinka riisuttu olisi kyseessä olisi se, että kaikki käyttöliittymäkoodi pitäisi toimia DirectX:n varassa,
Mitään olennaista Windows softaa ei mene. Melkein kaikki toimii Edgen kautta. Muista että ohjelmat yleisesti ottaen kirjoitetaan uusiksi aika ajoin.Jos suurin osa windowsissa toimivista ohjelmista kuolee niin mihin windowsia sitten enään oikein tarvitaan? Tarjollahan on esim. Macit, Androidit ja Linuxit.
Kysyjäkin12 kirjoitti:
Jos suurin osa windowsissa toimivista ohjelmista kuolee niin mihin windowsia sitten enään oikein tarvitaan? Tarjollahan on esim. Macit, Androidit ja Linuxit.
"Jos suurin osa windowsissa toimivista ohjelmista kuolee niin mihin windowsia sitten enään oikein tarvitaan?"
Suurin osa Windowsissa toimivista ohjelmista toimii selaimen kautta. Ei ne siis kuole. Vain jotkut vanhat sotkut voi kuolla.
Windows on tarkoitettu Microsoftin pilveen jatkeeksi. eli se käyttäliittymä Microsoftin palveluille kuten MS Office 365, Skype ja jne. Sekä sovelluksille joita jaetaan Windows storesta. Toki standardinmukaiset HTML5 sovellukset toimivat, eli Windows toimii myös muiden firmojen palveluille.
Ei ne ohjelmat mitä ihmiset käyttää mihinkään kuole vaan vanhentuneet jutut kirjoitetaan uusiksi kuten aina ennenkin. Valtava määrä vanhoja ohjelmia on uudelleenkirjoitettu aikoja sitten.- faktaa_taustalle
M-Kar kirjoitti:
"Jos suurin osa windowsissa toimivista ohjelmista kuolee niin mihin windowsia sitten enään oikein tarvitaan?"
Suurin osa Windowsissa toimivista ohjelmista toimii selaimen kautta. Ei ne siis kuole. Vain jotkut vanhat sotkut voi kuolla.
Windows on tarkoitettu Microsoftin pilveen jatkeeksi. eli se käyttäliittymä Microsoftin palveluille kuten MS Office 365, Skype ja jne. Sekä sovelluksille joita jaetaan Windows storesta. Toki standardinmukaiset HTML5 sovellukset toimivat, eli Windows toimii myös muiden firmojen palveluille.
Ei ne ohjelmat mitä ihmiset käyttää mihinkään kuole vaan vanhentuneet jutut kirjoitetaan uusiksi kuten aina ennenkin. Valtava määrä vanhoja ohjelmia on uudelleenkirjoitettu aikoja sitten.windowsin valtti on aina ollut suuri ohjelmatarjonta. Jos suurin osa sille kirjoitetuista ohjelmista kuolee niin sen käyttäjä määrä vähenee radikaalisesti ja sille käy niin kuin ms:n matkapuhelin liiketoiminnalle. Eli ihmiset siirtyy muihin käyttöjärjestelmiin kun niissä toimii silloin paljon enemmän ohjelmia kuin windows koneissa.
faktaa_taustalle kirjoitti:
windowsin valtti on aina ollut suuri ohjelmatarjonta. Jos suurin osa sille kirjoitetuista ohjelmista kuolee niin sen käyttäjä määrä vähenee radikaalisesti ja sille käy niin kuin ms:n matkapuhelin liiketoiminnalle. Eli ihmiset siirtyy muihin käyttöjärjestelmiin kun niissä toimii silloin paljon enemmän ohjelmia kuin windows koneissa.
"windowsin valtti on aina ollut suuri ohjelmatarjonta."
Olet väärässä. Lähes kaikki samat ohjelmat toimii joka paikassa koska se ohjelmatarjonta perustuu selaintekniikkaan.- delphikoodaaja
M-Kar kirjoitti:
Ei silläkään ole tulevaisuutta.
Kaikki GUI ohjelmointi Javalla Android API poislukien on käytännössä täysin kuollutta jo nyt,
Siitä olisi hyvä läheä, että Windows 10:ssä ajetaan vain käyttöliittymäpuolta ja edustakoodia. Tallennus ja taustaprosessointi on sitten palvelimessa.
Käyttöliittymäkoodi tehdään tekniikalla joka toimii selaimessa, tai sitten Microsoftin natiivia WinRT:tä. Poikkeuskeisseihin on .NET 4.x framework koko laajuudessaan ja pelimoottoreita ja vastaavia middlewareja varten näyttäisi jäävän joku riisuttu 64-bittinen Windows API. Hyvän kuvan saa siitä kuinka riisuttu olisi kyseessä olisi se, että kaikki käyttöliittymäkoodi pitäisi toimia DirectX:n varassa,
Mitään olennaista Windows softaa ei mene. Melkein kaikki toimii Edgen kautta. Muista että ohjelmat yleisesti ottaen kirjoitetaan uusiksi aika ajoin.M-Kar: "Siitä olisi hyvä läheä, että Windows 10:ssä ajetaan vain käyttöliittymäpuolta ja edustakoodia. Tallennus ja taustaprosessointi on sitten palvelimessa."
tuota....
Jos tosissasi tuollaista väität, unohdat yhden HYVIN tärkeän asian:
Ei se tietokoneen Web -selainkaan tyhjän päällä toimi.
Se osaa näyttää web -sivuja juuri siksi, että windows -käyttöjärjestelmä tarjoaa sellaiset API -kutsut, joilla web -selain voi näyttää sisältöä näytöllä, toistaa ääniä, reagoida näppäimistön ja hiiren käyttöön.
Ei Windowsin API:t mihinkään ole katoamassa (tai jos ovat, se web -selain lakkaa myös toimimasta).
Joten: Niin kauan, kun ne API:t on pakko tarjota, jotta web -selain pysyisi toimivana, myös muut ohjelmat voivat niitä samoja API -kutsuja käyttää.
Ainoa ero on se, että jos Delphi -ohjelma (joka käyttää Delphin omaa VCL:ää ja siten GDI:tä, EI siis GDI :aa) tarvitsee ehkä 1-2 Mt RAM -muistia, niin samantapainen käyttöliittymä HTML5:llä, CSS:llä ja JavaScriptillä toteutettuna tarvitsee muistia vähintään kaksinkertaisesti, paitsi, jos käyttöliittymäkokemuksesta halutaa oikeasti laadukas, vielä tätäkin enemmän.
Eli VCL:n korvaaminen web -teknologioilla nostaa huomattavasti koneen RAM -muistin tarvetta.
Jos ei fyysistä RAMia asenneta lisää, niin windows joutuu ottamaan swapfilen käyttöön, ja silloin ohjelman käyttö on pelkkää odottelua, kun windows joutuu siirtelemään valtavan määrän dataa edestakaisin swapfilen ja RAM -muistin välillä.
Debianko Pascal -tuotekehitykseen?
Noh:
Delphin debuggeri toimii kuin unelma (Delphi 7, tehty 2002).
Lazaruksen debuggeri on hankala käyttää, ja lisäksi epäluotettava.
Kaiken taustalla on jälleen kerran GPL -lisenssifanatismi, syöpä, joka huonontaa erityisesti Debianin, mutta myös ubuntun, ja muidenkin (kuten Red Hat) linux -jakeluiden laatua.
Miksi ja mitenkö?
SIKSI, että linux -jakeluissa debuggerit ovat usein vain GUI -käyttöliittymäkerroksia GDB:n päällä.
GDB on GPL -lisenssifanaatikkojen mielestä debuggeri.
Todellisuudessa GDB on varoittava esimerkki siitä, miten EI tehdä laadukasta debuggeria.
Olen miettinyt, pitäisikö itse koodata laadukas debuggeri linuxille.
Eli, käytännössä pitäisi tehdä 2 asiaa:
1) käyttöliittymää varten ohjelma
ja
2) API / ABI -palvelut tarjoava kirjasto, windowsissa tuo olisi DLL, linuxissa ilmeisesti esim:
debugservices.so
MUTTA: JOS tuollaisen debugservices.so -kirjaston koodaisin, montako vuotta eteenpäin se säilyisi kelvollisena ?
M-Kar tuntuu kuvittelevan, että suurin ongelma olisi FreePascalin / Lazaruksen epäyhteensopivat muutokset.
Tämä on täysin väärä käsitys !
JOS koodaisin tuon debugservices.so -kirjaston FreePascalilla (Lazarusta voi tässä käyttää koodaustyön IDE:nä, mutta eipä tuollainen kirjasto mitään GUI -käyttöliittymää tarjoa, vaan sen tarjoaa ko. kirjastoa käyttävä ohjelma),
niin väitän, että FreePascalin / Lazaruksen tulevat muutokset joko eivät lainkaan vaadi muutoksia kirjastoni lähdekoodiin, tai vaativat vain hyvin vähäisiä muutoksia.
Tässä suhteessa muuten FreePascal on:
Jonkun verran parempi kuin C
Huomattavasti parempi kuin "C ".
Isompi ongelma tulee siitä, jos ne vähäiset avut, mitä linux KERNEL tarjoaa debuggauksen tarpeisiin, muuttuvat eri KERNEL -versioiden mukana.
Tai entä, jos KERNEL ei lainkaan tarjoa jotain sellaista apua debuggauksen tarpeisiin, mikä windowsissa kuuluu ihan windows API:n perustoimintoihin, kuten esim:
ContinueDebugEvent
DebugActiveProcess
DebugBreak
FatalExit
FlushInstructionCache
GetThreadContext
GetThreadSelectorEntry
IsDebuggerPresent
OutputDebugString
ReadProcessMemory
SetDebugErrorLevel
SetThreadContext
WaitForDebugEvent
WriteProcessMemory
Jos jollekin näistä ei ole linux -vastinetta, kunnollisen debuggerin koodaus linuxille voi osoittautua vaikeaksi tai mahdottomaksi.
Lisävaivaa tuottaa linuxin sekava ja huonosti dokumentoitu ELF -formaatti.
No, ei windowsin PE:kään ihan selkeimpiä ole, mutta (suurella vaivalla) olen onnistunut kirjoittaamaan Delphillä koodia, joka lisää EXE tai DLL -tiedostoon uusia import:eja.
Esimerkiksi, jos otetaan vaikkapa firefox.exe:
Omalla Delphi -koodillani on mahdollista lisätä firefox.exeen esim. import kirjastosta MYFOXHLP.DLL funktionimi HelperStartUp().
Tämän jälkeen, kun muokatun firefox.exe:n käynnistää, latautuu samaan prosessiin myös
MYFOXHLP.DLL ja firefox kutsuu funktiota HelperStartUp() em. DLL -tiedostossa.
Mutta tuota PE .tiedoston suoraa binäärimuokkausta tehdessä, tuli huomattua, että Microsoftilla on joku koodannut C -kielellä ko. PE -tiedoston käsittelyn.
Delphi -koodaaja olisi luultavasti suunnitellut koko homman hieman toisin. delphikoodaaja kirjoitti:
M-Kar: "Siitä olisi hyvä läheä, että Windows 10:ssä ajetaan vain käyttöliittymäpuolta ja edustakoodia. Tallennus ja taustaprosessointi on sitten palvelimessa."
tuota....
Jos tosissasi tuollaista väität, unohdat yhden HYVIN tärkeän asian:
Ei se tietokoneen Web -selainkaan tyhjän päällä toimi.
Se osaa näyttää web -sivuja juuri siksi, että windows -käyttöjärjestelmä tarjoaa sellaiset API -kutsut, joilla web -selain voi näyttää sisältöä näytöllä, toistaa ääniä, reagoida näppäimistön ja hiiren käyttöön.
Ei Windowsin API:t mihinkään ole katoamassa (tai jos ovat, se web -selain lakkaa myös toimimasta).
Joten: Niin kauan, kun ne API:t on pakko tarjota, jotta web -selain pysyisi toimivana, myös muut ohjelmat voivat niitä samoja API -kutsuja käyttää.
Ainoa ero on se, että jos Delphi -ohjelma (joka käyttää Delphin omaa VCL:ää ja siten GDI:tä, EI siis GDI :aa) tarvitsee ehkä 1-2 Mt RAM -muistia, niin samantapainen käyttöliittymä HTML5:llä, CSS:llä ja JavaScriptillä toteutettuna tarvitsee muistia vähintään kaksinkertaisesti, paitsi, jos käyttöliittymäkokemuksesta halutaa oikeasti laadukas, vielä tätäkin enemmän.
Eli VCL:n korvaaminen web -teknologioilla nostaa huomattavasti koneen RAM -muistin tarvetta.
Jos ei fyysistä RAMia asenneta lisää, niin windows joutuu ottamaan swapfilen käyttöön, ja silloin ohjelman käyttö on pelkkää odottelua, kun windows joutuu siirtelemään valtavan määrän dataa edestakaisin swapfilen ja RAM -muistin välillä.
Debianko Pascal -tuotekehitykseen?
Noh:
Delphin debuggeri toimii kuin unelma (Delphi 7, tehty 2002).
Lazaruksen debuggeri on hankala käyttää, ja lisäksi epäluotettava.
Kaiken taustalla on jälleen kerran GPL -lisenssifanatismi, syöpä, joka huonontaa erityisesti Debianin, mutta myös ubuntun, ja muidenkin (kuten Red Hat) linux -jakeluiden laatua.
Miksi ja mitenkö?
SIKSI, että linux -jakeluissa debuggerit ovat usein vain GUI -käyttöliittymäkerroksia GDB:n päällä.
GDB on GPL -lisenssifanaatikkojen mielestä debuggeri.
Todellisuudessa GDB on varoittava esimerkki siitä, miten EI tehdä laadukasta debuggeria.
Olen miettinyt, pitäisikö itse koodata laadukas debuggeri linuxille.
Eli, käytännössä pitäisi tehdä 2 asiaa:
1) käyttöliittymää varten ohjelma
ja
2) API / ABI -palvelut tarjoava kirjasto, windowsissa tuo olisi DLL, linuxissa ilmeisesti esim:
debugservices.so
MUTTA: JOS tuollaisen debugservices.so -kirjaston koodaisin, montako vuotta eteenpäin se säilyisi kelvollisena ?
M-Kar tuntuu kuvittelevan, että suurin ongelma olisi FreePascalin / Lazaruksen epäyhteensopivat muutokset.
Tämä on täysin väärä käsitys !
JOS koodaisin tuon debugservices.so -kirjaston FreePascalilla (Lazarusta voi tässä käyttää koodaustyön IDE:nä, mutta eipä tuollainen kirjasto mitään GUI -käyttöliittymää tarjoa, vaan sen tarjoaa ko. kirjastoa käyttävä ohjelma),
niin väitän, että FreePascalin / Lazaruksen tulevat muutokset joko eivät lainkaan vaadi muutoksia kirjastoni lähdekoodiin, tai vaativat vain hyvin vähäisiä muutoksia.
Tässä suhteessa muuten FreePascal on:
Jonkun verran parempi kuin C
Huomattavasti parempi kuin "C ".
Isompi ongelma tulee siitä, jos ne vähäiset avut, mitä linux KERNEL tarjoaa debuggauksen tarpeisiin, muuttuvat eri KERNEL -versioiden mukana.
Tai entä, jos KERNEL ei lainkaan tarjoa jotain sellaista apua debuggauksen tarpeisiin, mikä windowsissa kuuluu ihan windows API:n perustoimintoihin, kuten esim:
ContinueDebugEvent
DebugActiveProcess
DebugBreak
FatalExit
FlushInstructionCache
GetThreadContext
GetThreadSelectorEntry
IsDebuggerPresent
OutputDebugString
ReadProcessMemory
SetDebugErrorLevel
SetThreadContext
WaitForDebugEvent
WriteProcessMemory
Jos jollekin näistä ei ole linux -vastinetta, kunnollisen debuggerin koodaus linuxille voi osoittautua vaikeaksi tai mahdottomaksi.
Lisävaivaa tuottaa linuxin sekava ja huonosti dokumentoitu ELF -formaatti.
No, ei windowsin PE:kään ihan selkeimpiä ole, mutta (suurella vaivalla) olen onnistunut kirjoittaamaan Delphillä koodia, joka lisää EXE tai DLL -tiedostoon uusia import:eja.
Esimerkiksi, jos otetaan vaikkapa firefox.exe:
Omalla Delphi -koodillani on mahdollista lisätä firefox.exeen esim. import kirjastosta MYFOXHLP.DLL funktionimi HelperStartUp().
Tämän jälkeen, kun muokatun firefox.exe:n käynnistää, latautuu samaan prosessiin myös
MYFOXHLP.DLL ja firefox kutsuu funktiota HelperStartUp() em. DLL -tiedostossa.
Mutta tuota PE .tiedoston suoraa binäärimuokkausta tehdessä, tuli huomattua, että Microsoftilla on joku koodannut C -kielellä ko. PE -tiedoston käsittelyn.
Delphi -koodaaja olisi luultavasti suunnitellut koko homman hieman toisin."Jos tosissasi tuollaista väität, unohdat yhden HYVIN tärkeän asian:
Ei se tietokoneen Web -selainkaan tyhjän päällä toimi.
Se osaa näyttää web -sivuja juuri siksi, että windows -käyttöjärjestelmä tarjoaa sellaiset API -kutsut, joilla web -selain voi näyttää sisältöä näytöllä, toistaa ääniä, reagoida näppäimistön ja hiiren käyttöön."
Se selain on se API, eli alusta sovelluksille. Ei tarvitse välttämättä mitään muuta kuin kernelin.
Jostain syystä käsität selaimen jonkinlaiseksi sovellukseksi kuten tekstinkäsittelyohjelman vaikka se selain on alusta. Se miten se on mitenkin tehty teknisesti ajanhetkellä X, on merkityksetöntä. Se voidaan ihan vapaasti laittaa suoraan kernelin päälle ja näin varmaan onkin jo osittain kun siellä on niitä hiekkalaatikointeja tehty. Kokoajan enemmän noita viilataan.
"Ainoa ero on se, että jos Delphi -ohjelma (joka käyttää Delphin omaa VCL:ää ja siten GDI:tä, EI siis GDI :aa) tarvitsee ehkä 1-2 Mt RAM -muistia, niin samantapainen käyttöliittymä HTML5:llä, CSS:llä ja JavaScriptillä toteutettuna tarvitsee muistia vähintään kaksinkertaisesti, paitsi, jos käyttöliittymäkokemuksesta halutaa oikeasti laadukas, vielä tätäkin enemmän."
Päätelaitteessa ajetaan useita käyttöliittymiä ja tosiasiassa Edgellä tehty käyttöliittymä vaatii vähemmän kun ei tarvitse joka sovellukselle asentaa jotain kirjastoja ja muita riippuvuuksia.
Esimerkiksi mikä tahansa 32-bittinen ohjelma rohmuaa muistia kun sitä varten tarvitsee ladata taaksepäinyhteensopivuussyistä 32-bittiset versiot samoista kirjastoista. Sitten lisäksi jotain GDI:tä, VCL:ää ja muita sotkuja ja joku ohjelma haluaa eri version Delphistä ja sitten joku Java ohjelma siellä ja joku Lazarus.
Nuo kaikki vie muistia mutta pelkkä Edge hoitaa kaikki standardijutut.
"Eli VCL:n korvaaminen web -teknologioilla nostaa huomattavasti koneen RAM -muistin tarvetta."
Päinvastoin. Kun poistaa kaikki 32-bittiset kurat, vanhat rajapintaversiot kuten Windows API, .NET 3.5, Javat ja muut sotkut niin muistin tarve vähenee rajusti. Tähän perustui Windows 8 RT että poistivat vanhat sotkut mitä taaksepäinyhteensopivuussyistä oli raahattu Windows 8 Pron mukana.
"Delphin debuggeri toimii kuin unelma (Delphi 7, tehty 2002)."
Toimii paskasti kun siinä on mm. jotain 32-bittisiä sotkuja kuluttamassa muistia. Ymmärrä että kaikki vanha kura mitä raahataan mukana taaksepäinyhteensopivuussyistä tarvitsee ladata muistiin että se toimii. Windows lisäksi on turvonnut kokoaika 2000->XP->Vista->8 ja kaikki 10 versiot jne. kun jokainen uusi versio raahaa mukanaan aiemmat Windowsit johon halutaan yhteensopivuutta säilyttää! Ainoa keino hillitä Windowsin tursuamista on siivota pois vanhempia sotkuja ja sieltä on jo siivottu paljon.
"MUTTA: JOS tuollaisen debugservices.so -kirjaston koodaisin, montako vuotta eteenpäin se säilyisi kelvollisena ?"
Sehän riippuu sinusta.
"Tässä suhteessa muuten FreePascal on:
Jonkun verran parempi kuin C
Huomattavasti parempi kuin "C "."
Väärässä olet. C:n ABI on standardoitu ja äärimmäisen vakaa.
C on kompleksinen kieli ja vaikka sillä on ABI, sitä on vaikea pitää vakaana. Kielen päivittyessä tulee ennemmin tai myöhemmin tarpeita rikkoa ABI:a. Microsoft ratkaissut tuota COM:lla jossa on sitä ABI:a pidetty samanlaisena ja toinen sitten on ne Visual C redistributablet. Vastaavanlaisia ABI jäädytyksiä on muuallakin.
"Isompi ongelma tulee siitä, jos ne vähäiset avut, mitä linux KERNEL tarjoaa debuggauksen tarpeisiin, muuttuvat eri KERNEL -versioiden mukana."
Kernel on tietysti vakaa koko käyttöjärjelmän elinkaaren ajan.
"Tai entä, jos KERNEL ei lainkaan tarjoa jotain sellaista apua debuggauksen tarpeisiin, mikä windowsissa kuuluu ihan windows API:n perustoimintoihin, kuten esim:"
Mutta tiesitkös sitä, että kuten vaikka Linux, niitä ei luvata pidettävän vakaana. Pysyvät vakaana kyseisen Windows version eliniän ajan ja VOIVAT toimia samalla tavalla seuraavassa mutta sitä ei luvata missään.
"kunnollisen debuggerin koodaus linuxille voi osoittautua vaikeaksi tai mahdottomaksi."
Minkäs takia Firefoxissa ollut 5v tosi hyvä debuggeri?
"Mutta tuota PE .tiedoston suoraa binäärimuokkausta tehdessä, tuli huomattua, että Microsoftilla on joku koodannut C -kielellä ko. PE -tiedoston käsittelyn."
Tietysti. C ollut standardi työkalu systeemiohjelmoinnissa 70-luvulta saakka ja Microsoft otti sen myös käyttöön ja siksi Windowsissa kaikki matalan tason koodi on kirjoitettu C:llä kuten muuallakin on. Windowsin kerneli, laiteajurit tiedostojärjestelmä, joku PE tiedosto ja vanha Windows API on C:tä. Muista että kaikki Pascal viritykset näyttää toimivan sen paljaaksi jätetyn vanhan Windows API:n varassa mitä nyt siivoillaan pois. Sehän jätettiin silloin 25v sitten paljaaksi sinne muita valmistajia varten vaikka kaikki koodi Windowsille Microsoftin työkaluilla tehtiin korkeamman tason välineillä kuten MFC tai Visual Basic.
"M-Karin höpinät Delphi -ohjelmien toimivuudesta Windows 10:ssä voi pääosin jättää omaan arvoonsa."
Kaikki Deplhi ohjelmat toimivat sen hetkisessä Windows 10 julkaisussa (muuttuu 2x vuodessa) kunhan ne on käännetty Delphi versiolla joka on edelleen tuen piirissä, ja kyseisessä Windows versiossa ei ole rajoitteita sille. Käytännössä Delphi uusitaan kerta vuoteen ja ohjelman toimivuus tarkistetaan joka Windowsilla.
"Kun Delphi -ohjelmat tyypillisesti käyttävät jopa satoja eri API -funktioita, ja niistä kahden (joista kumpaakaan EI KÄYTETÄ kaikissa Delphi -ohjelmissa) kohdalla on tuo varoitus siitä, että Microsoft saattaa poistaa ko. funktion Win10:n myöhemmissä julkaisuversioissa, niin näinollen M-Karin höpinät aiheesta ovat täysin ylimitoitettuja."
Yhdenkin funktion erilainen toiminta riittää rikkomaan ohjelman.
"Laatia listan, jossa on KAIKKI Windows API (32-bit) funktiot, ja jokaisen kohdalla merkintä siitä, kuuluuko funktio poistettavien listalle vai ei kuulu."
https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=vs.85).aspx#deprecated_or_legacy_apis
https://msdn.microsoft.com/en-us/library/windows/desktop/dd375436(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/jj635743(v=vs.85).aspx
"On aivan käsittämättömän törkeää, ettei Microsoft ole jo kauan sitten julkaissut tuollaista listaa."
Onhan se kauan sitten julkaissut ja tosiaankin Microsoft toimii kuten muutkin softafirmat: Eli heidän UUSIN rajapinta on se millä on pisimpään jatkuvuutta. Vanhat siivotaan pois ennemmin tai myöhemmin. Eli aina kun Microsoft tekee UUDEN rajapinnan tai uuden version vanhemmasta, omaa koodia päivitetään sen kanssa yhteensopivaksi. Aivan kuten aina ennenkin. Se on softakehittäjän vika jos jumiutuu vanhoihin.
Se että sattuu toimimaan vuosia on taaksepäin yhteensopivuutta mutta se on jotain harhakuvitelmaa että olisivat jotenkin muuttumattomia.
"Lopuksi ristiinajo tuon Microsoftin "poistolistan" kanssa, niin näkee, mikä on oikeasti vaarassa ja mikä ei."
Lähdetään nyt siitä faktasta, että Microsoft lupaa vanhoille Windows API rajapinnoille vakautta kyseisen Windowsjulkaisun ajan. Ennen jokainen Windows julkaisu oli 10v vakaa. Nykyisin 6kk. Sama rajapintakutsu voi siis olla samanlainen mutta voi vaikka toimia hieman eri tavalla eikä se välttämättä ilmene dokumentaatiosta koska muutos ei välttämättä ole tarkoituksellinen.
Vakautta löytyy kyllä sitten .NET:sta, ja Visual C redistributablesta vaikka Windows muuten muuttuisikin.
"Sinänsä muuten tämä ongelma EI koske mitenkään erityisesti Delphiä, vaan aivan sama koskee esim. Microsoft Visual C :lla tehtyjä ohjelmia.
Toki MS on voinut rakentaa oman MFC systeeminsä niin, että siinä ei käytetä poistolistalla olevia funktioita."
Näinpä onkin. Tai ennemminkin niin, että jos on poistolistalla oleva funktio niin se ei poistu niin kauan kuin kyseinen Visual C redistributable on tuettuna. Jokainen versio siitä on 10v.
"Eli noiden poistolistalla olevien osalta ongelma koskee ihan tasapuolisesti kaikkiza ohjelmistokehitystyövälineitä."
Ei koske. Microsoft lupaa 10v vakauden Visual C redistributable sekä .NET framework versioille. .NET:llä lisäksi taaksepäinyhteensopivuutta, että sitä rikotaan vain tietyissä versioissa. Tähän mennessä rikkoutuminen tehty 2.0 ja 4.0 versioissa.
Vanhat Windows API kutsut ovat varmasti vakaita kyseisen Windowsversion, eli vaikka nykyisen Windows 10 1709:n ajan ja kun tulee uusi niin voivat poistella kokonaan deprekoituja tai voi olla minimaalisia muutoksia mitkä voivat toki myös rikkoa, eli oma koodi pitää testata uudella Windowsilla.
Unohdat toki sen, että Windowsilla ajetaan enimmäkseen koodia joka toimii standardi tekniikalla, eli selaimen kautta. Tunnut jostain syystä jumiutuneen johonkin menneisyyden C tai Deplhi virityksiin. Poistettavat toiminnot ei koske Microsoftin WinRT, .NET 4 .x tai HTML5 sovelluksia! Pääsääntöisesti mikä tahansa yli 10v vanha on enemmän tai vähemmän poistolistalla. Eli jos nyt olisi se .NET 2.0 tai Visual C 2008 redistributablea vasten käännettynä niin toimii mutta ensi kesän jälkeen on hällä väliä.
"Väittäisin, että M-Karin varoitukset siitä, että MS olisi jo vuosia sitten sanonut "älkää käyttäkö näitä funktioita" ovat täysin tuulesta temmattuja. Kyllä ne varoitukset ovat MSDN:n kutakin funktiota kuvailevalle sivulle laitettu vasta vuonna 2017."
Kyllä noita deprekoituja viestejä ollut aina. Onhan sitä poistunut ennenkin toimintoja Windowsista. Esim 16-bit ohjelmat alkoi näivettyä järjestyksessä Windows 95 -> 2000 -> XP versioissa ja 64-bit Windows Vistalla poistui kokonaan.Ihan hyvä esimerkki tuosta vanhan korvaamisesta, että .NET tuli 15.5v sitten, että onkos tuo nyt ihme jos jotain vanhoja Windows API kutsuja välillä poistuu.
Yleisesti ottaen kukaan ei ole olettanut kyseessä olevan muuta kuin Windows API:n täysi korvaaminen mutta sitä tuskin oltu edes aikataulutettu Microsoftilla vielä Windows Vistan aikoihin.
Pian Windows 7:n julkaisun jälkeen kun tuli IE9, Microsoft kuulutti Windows 7:aa nimenomaan alustaksi HTML5 sovelluksille. Sitten pian tuli Windows 8 jossa oli uudet natiivisovellukset ja vanhat Windows API jutut oli selvästi pyritty eristämään uusista.
"Lisäksi olisi syytä myös selvittää: Niiden funtioiden osalta, joissa ko. poistovaroitus on, kauanko varoitus on siellä ollut?"
Noita alkoi tulla aika paljon Windows 8:n jälkeen. Siellä ollut joitakin 5v jo poistolistalla.- ex-delphisti
Tämä on vain minun mutua, mutta Microsoftin suurin valtti tällä hetkellä on iso ohjelmakirjasto Windowsille, etenkin se WINAPI, eli se että heidän ekosysteemillä on paljon ohjelmistoja ja etenkin ammattiohjelmistoja! En usko että he voi vain tappaa oman busineksensa tappamalla Winapin kokonaan pois! Se olisi Microsoftille itsemurha!
En sitä sano, WindowsAPI on vanha kuin taivas, mutta miksi tappaa toimivaa pois jos se on edelleen käypä systeemi!?- ex-delphisti
Windows = WindowsAPI! Jos muuta tulee, Windows on historiaa, näin se on ja tulee olemaan!
"Tämä on vain minun mutua, mutta Microsoftin suurin valtti tällä hetkellä on iso ohjelmakirjasto Windowsille"
Ei oikeastaan. Windowsille on hyvin vähän natiiveja ohjelmia koska Microsoft ei pärjännyt Applelle ja Googlelle mobiileimmissa vehkeissä vaan sillä on lähinnä desktopia.
Desktop sovellukset on suurimmaksi osaksi selaimella toimivia ja natiiveja ohjelmia on lähinnä köykäisemmissä vehkeissä kuten kännyköissä ja tableteissa.
Microsoftin suurin valtti onkin keskitetyssä hallinnassa ja siinä, että Googlen tapaan heidän ekosysteemistä löytyy melkein kaikki palvelut.
Joitakin natiiveja, vanhalla tekniikalla toimivia palveluja kuten se mitä Adobe ja Autodesk tarjoaa mutta se on yksi syy miksi ne on kuukausi- ja vuosimaksullisia kun niitä siirretään kaiken aikaa uudemmalle tekniikalle. Jos niitä ei päivitettäisi jatkuvasti niin pilaantuisi äkkiä kelvottomaksi.
"En usko että he voi vain tappaa oman busineksensa tappamalla Winapin kokonaan pois! Se olisi Microsoftille itsemurha!"
Korvaaja tuli 15.5v sitten, ja tappaminen alkoi 6v sitten. MFC tuli 25v sitten, että WinApilla ei varsinaisesti ole tehty mitään neljännesvuosisataan mutta MFC oli kyllä aika pitkälti rakennettu WindowsAPI:n varaan.
"En sitä sano, WindowsAPI on vanha kuin taivas, mutta miksi tappaa toimivaa pois jos se on edelleen käypä systeemi!?"
Vanhat Windows API kutsut ei esimerkiksi kelpaa käyttöliittymän tekemiseen kun ei saa skaalattua erilaisille näytöille. Siksi GDI ja GDI ovat molemmat deprekoituja. Windows API:n ohjelmoitavuus on kömpelöä ja surkeaa. Muista että Windows API:lla Hello Worldin tekeminen tarvitsi aluksi 100 riviä koodia! MFC tuli jo 25v sitten että ei sillä Windows API:lla ole tehnyt mitään. Kuka tahansa kuka haluaisi kehittää koodia Windows API:lle, alkaisi ensi töikseen rakentamaan jotain frameworkkia että saisi tehtyä yhtään mitään järkevästi.
Microsoft business on muuten aika pitkälti pilvipalveluissa kuten MS Office 365. Windows on Androidin tapaan juttu millä lähinnä suojataan sitä omaa bisnestä ja tarjotaan keinoja kammeta palveluja käyttöön sen kautta. Googlella Android on lähinnä menoerä mutta tärkeä Googlen bisneksen suojaamisssa koska Googlella menee vähän paremmin. Microsoftilla menee huonommin mutta sillä se Windows sentään vielä tuottaa jotain."Tämä on vain minun mutua, mutta Microsoftin suurin valtti tällä hetkellä on iso ohjelmakirjasto Windowsille"
Ei oikeastaan. Windowsille on hyvin vähän natiiveja ohjelmia koska Microsoft ei pärjännyt Applelle ja Googlelle mobiileimmissa vehkeissä vaan sillä on lähinnä desktopia.
Desktop sovellukset on suurimmaksi osaksi selaimella toimivia ja natiiveja ohjelmia on lähinnä köykäisemmissä vehkeissä kuten kännyköissä ja tableteissa.
Microsoftin suurin valtti onkin keskitetyssä hallinnassa ja siinä, että Googlen tapaan heidän ekosysteemistä löytyy melkein kaikki palvelut.
Joitakin natiiveja, vanhalla tekniikalla toimivia palveluja kuten se mitä Adobe ja Autodesk tarjoaa mutta se on yksi syy miksi ne on kuukausi- ja vuosimaksullisia kun niitä siirretään kaiken aikaa uudemmalle tekniikalle. Jos niitä ei päivitettäisi jatkuvasti niin pilaantuisi äkkiä kelvottomaksi.
"En usko että he voi vain tappaa oman busineksensa tappamalla Winapin kokonaan pois! Se olisi Microsoftille itsemurha!"
Korvaaja tuli 15.5v sitten, ja tappaminen alkoi 6v sitten. MFC tuli 25v sitten, että WinApilla ei varsinaisesti ole tehty mitään neljännesvuosisataan mutta MFC oli kyllä aika pitkälti rakennettu WindowsAPI:n varaan.
"En sitä sano, WindowsAPI on vanha kuin taivas, mutta miksi tappaa toimivaa pois jos se on edelleen käypä systeemi!?"
Vanhat Windows API kutsut ei esimerkiksi kelpaa käyttöliittymän tekemiseen kun ei saa skaalattua erilaisille näytöille. Siksi GDI ja GDI ovat molemmat deprekoituja. Windows API:n ohjelmoitavuus on kömpelöä ja surkeaa. Muista että Windows API:lla Hello Worldin tekeminen tarvitsi aluksi 100 riviä koodia! MFC tuli jo 25v sitten että ei sillä Windows API:lla ole tehnyt mitään. Kuka tahansa kuka haluaisi kehittää koodia Windows API:lle, alkaisi ensi töikseen rakentamaan jotain frameworkkia että saisi tehtyä yhtään mitään järkevästi.
Microsoft business on muuten aika pitkälti pilvipalveluissa kuten MS Office 365. Windows on Androidin tapaan juttu millä lähinnä suojataan sitä omaa bisnestä ja tarjotaan keinoja kammeta palveluja käyttöön sen kautta. Googlella Android on lähinnä menoerä mutta tärkeä Googlen bisneksen suojaamisssa koska Googlella menee vähän paremmin. Microsoftilla menee huonommin mutta sillä se Windows sentään vielä tuottaa jotain.
"Väittäisin, että M-Karin varoitukset siitä, että MS olisi jo vuosia sitten sanonut "älkää käyttäkö näitä funktioita" ovat täysin tuulesta temmattuja. Kyllä ne varoitukset ovat MSDN:n kutakin funktiota kuvailevalle sivulle laitettu vasta vuonna 2017."
Microsoft siivoaa!
https://en.wikipedia.org/wiki/List_of_features_removed_in_Windows_Vista
https://en.wikipedia.org/wiki/List_of_features_removed_in_Windows_7
https://en.wikipedia.org/wiki/List_of_features_removed_in_Windows_8
http://www.thewindowsclub.com/features-added-removed-windows-10-anniversary-update
https://support.microsoft.com/fi-fi/help/4034825/features-that-are-removed-or-deprecated-in-windows-10-fall-creators-up
Noihin voi lisätä 16-bittisten ohjelmien siivoamiset, muutama videokodekki mikä poistettiin, ja lisäksi on luvattu poistaa (ellei jo ole poistunut) Visual Basic 6 tuki ja ohjauspaneeli.
Täällä mainittu deprecated Windows API jutut ilmestyneet joiltakin osin jo Windows 8:n yhteydessä kun sitä siivotaan myös.
Oletus on että kaikki yli 10v ikäiset rajapintaversiot ovat menossa vasaran alle kuin myös 32-bit tuki. Ei siis mitään hätää 64-bit DirectX 10, Visual C 2008 redistributable tai vaikka .NET 2.0 koodilla. Ensi kesän jälkeen Visual C 2010 ja .NET 4.x on varmasti turvassa.
Onhan tuolla noita siirtymäaikoja, että kun uusi Windows tulee pari kertaa vuodessa niin edellisessä on mahdollista kitkutella vuosi. Suunta on kuitenkin hyvin selvä ollut viimeiset 6v.
Ketjusta on poistettu 0 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
- 1664616
Katso: Ohhoh! Miina Äkkijyrkkä sai käskyn lähteä pois Farmi-kuvauksista -Kommentoi asiaa: "En ole.."
Tämä oli shokkiyllätys. Oliko tässä kyse tosiaan siitä, että Äkkijyrkkä sanoi asioita suoraan vai mistä.... Tsemppiä, Mi1184207- 252770
Kyllä poisto toimii
Esitin illan suussa kysymyksen, joka koska palstalla riehuvaa häirikköä ja tiedustelin, eikö sitä saa julistettua pannaa281901"Joka miekkaan tarttuu, se siihen hukkuu"..
"Joka miekkaan tarttuu, se siihen hukkuu".. Näin puhui jo aikoinaan Jeesus, kun yksi hänen opetuslapsistaan löi miekalla231774Haluan jutella kanssasi Nainen
Olisiko jo aika tavata ja avata tunteemme...On niin paljon asioita joihin molemmat ehkä haluaisimme saada vastaukset...O151669Poliisiauto Omasp:n edessä parkissa
Poliisiauto oli parkissa monta tuntia Seinäjoen konttorin edessä tänään. Haettiinko joku tai jotain pankista tutkittavak221660Hermo mennyt sotealueeseen?
Nyt hammaslääkäriaika peruttiin neljännen kerran. Perumiset alkoi tammikuussa. Nyt uusi aika elokuulle!????941615Haluan tavata Sinut Rakkaani.
Olen valmis Kaikkeen kanssasi...Tulisitko vastaa Rakkaani...Olen todella valmistautunut tulevaan ja miettinyt tulevaisuu301573Onko mies niin,
että sinulle ei riitä yksi nainen? Minulle suhde tarkoittaa sitoutumista, tosin eihän se vankila saa olla kummallekaan.181521