delphi 7

Mitä sillä tekee?

M-Kar kirjoitti:

Mitä sillä tekee?

Mitä vanhoilla tuotteilla yleensä tekee. Toiset vanhat tuotteet vain ovat arvokkaampia kuin toiset (jos ymmärtää sen merkityksen)

Delphi7 kirjoitti:

Mitä vanhoilla tuotteilla yleensä tekee. Toiset vanhat tuotteet vain ovat arvokkaampia kuin toiset (jos ymmärtää sen merkityksen)

Ei tee yhtään mitään kun parempiakin löytyy. Legacyohjelmien tekohengittämiseenkin löytyy Lazarus jos nyt vaan täytyy saada koodi jotenkin toimimaan ennen kuin sen uusii.

M-Kar kirjoitti:

Ei tee yhtään mitään kun parempiakin löytyy. Legacyohjelmien tekohengittämiseenkin löytyy Lazarus jos nyt vaan täytyy saada koodi jotenkin toimimaan ennen kuin sen uusii.

Delphi 7 on ilmestynyt elokuussa vuonna 2002 ja on täysin eri versio kuin Delphi XE 7.
Delphi 7 on myös eräänlaisessa kulttimaineessa (eli kyseinen Delphi versio pitää omistaa)

seiskat kirjoitti:

Delphi 7 on ilmestynyt elokuussa vuonna 2002 ja on täysin eri versio kuin Delphi XE 7.
Delphi 7 on myös eräänlaisessa kulttimaineessa (eli kyseinen Delphi versio pitää omistaa)

Lue lisää

Mutta kun sillä ei edelleenkään tee yhtään mitään. Ei ole mitään järkeä kääntää jotain Windows XP ohjelmia herran vuonna 2015. Ennemmin kääntää sen koodin nykyisillä työkaluilla.

M-Kar kirjoitti:

Mutta kun sillä ei edelleenkään tee yhtään mitään. Ei ole mitään järkeä kääntää jotain Windows XP ohjelmia herran vuonna 2015. Ennemmin kääntää sen koodin nykyisillä työkaluilla.

Lue lisää

Enpä usko, että teet millään muullakaan mitään.

D7 on täällä käytössä, eikä näköpiirissä mitään syytä päivittää. Kaikki toimii. Uudet Delphit ei anna mitään lisäarvoa, tuovat vain mukanaan ylimääräistä roskaa koneelle.

D7_toimii kirjoitti:

Enpä usko, että teet millään muullakaan mitään.

D7 on täällä käytössä, eikä näköpiirissä mitään syytä päivittää. Kaikki toimii. Uudet Delphit ei anna mitään lisäarvoa, tuovat vain mukanaan ylimääräistä roskaa koneelle.

Lue lisää

Teen toki nykypäivän työkaluilla nykypäivän järjestelmille.

Siinä Delphi 7:ssa on sellainen iso ongelma, että se kääntää vanhoille rajapinnoille sen koodin. Windows XP:ssä olevia Win32 API kutsuja on deprekoitu ja niitä poistetaan hyvää vauhtia. Tämä tarkoittaa sitä, että Delphi 7:lla käännetyt ohjelmat lakkaavat helposti pian toimimasta.

Siihen ei ole luottamista, että ne toimisi jatkossa vaikka ne softat toimivat Windows 10:n julkaisuhetkellä sillä esim. Windows 8 -> 8.1 poistettiin Win32 API legacyä ja Windows 10 on siirtymässä jatkuvasti päivittyvään malliin jossa niitä vanhoja juttuja poistetaan asteittain.

Delphi 7:lla tehdyt ohjelmat vaativat muuten ylimääräistä roskaa koneelle ja tietokoneen muistiin toimiakseen. Katsos kun se kääntää arkkitehtuuririippuvaista, 32-bittistä koodia ja ohjelmat lataavat ja käyttävät Wow64:sta toimiakseen.

Uudempien työkalujen lisäarvo on se, että niillä käännetyt ohjelmat eivät tarvitse ylimääräistä roskaa muistiin, ohjelmat toimivat pidempään ja on vähemmän muutostyötä tiedossa kun ne vanhat systeemit joka tapauksessa lakkaavat ennen pitkää toimimasta.

Sillä ei siis ole mitään väliä vaikka se toimisi nyt. Sitä suuremmalla syyllä kannattaa uusia ajoissa vielä kun se toimii eikä sitten kun se on rikki.

M-Kar kirjoitti:

Mutta kun sillä ei edelleenkään tee yhtään mitään. Ei ole mitään järkeä kääntää jotain Windows XP ohjelmia herran vuonna 2015. Ennemmin kääntää sen koodin nykyisillä työkaluilla.

Lue lisää

Delphi 7 on sellaisessa maineessa että se pitää omistaa (se ei välttämättä tarkoita että se olisi päivittäisessä käytössä ohjelmistotuotannossa)

M-Kar kirjoitti:

Teen toki nykypäivän työkaluilla nykypäivän järjestelmille.

Siinä Delphi 7:ssa on sellainen iso ongelma, että se kääntää vanhoille rajapinnoille sen koodin. Windows XP:ssä olevia Win32 API kutsuja on deprekoitu ja niitä poistetaan hyvää vauhtia. Tämä tarkoittaa sitä, että Delphi 7:lla käännetyt ohjelmat lakkaavat helposti pian toimimasta.

Siihen ei ole luottamista, että ne toimisi jatkossa vaikka ne softat toimivat Windows 10:n julkaisuhetkellä sillä esim. Windows 8 -> 8.1 poistettiin Win32 API legacyä ja Windows 10 on siirtymässä jatkuvasti päivittyvään malliin jossa niitä vanhoja juttuja poistetaan asteittain.

Delphi 7:lla tehdyt ohjelmat vaativat muuten ylimääräistä roskaa koneelle ja tietokoneen muistiin toimiakseen. Katsos kun se kääntää arkkitehtuuririippuvaista, 32-bittistä koodia ja ohjelmat lataavat ja käyttävät Wow64:sta toimiakseen.

Uudempien työkalujen lisäarvo on se, että niillä käännetyt ohjelmat eivät tarvitse ylimääräistä roskaa muistiin, ohjelmat toimivat pidempään ja on vähemmän muutostyötä tiedossa kun ne vanhat systeemit joka tapauksessa lakkaavat ennen pitkää toimimasta.

Sillä ei siis ole mitään väliä vaikka se toimisi nyt. Sitä suuremmalla syyllä kannattaa uusia ajoissa vielä kun se toimii eikä sitten kun se on rikki.

Lue lisää

Teollisuudessa on myös monia sellaisia pc:tä jotka eivät ole verkossa ja on pyhitetty vain yhteen tehtävään (niiden käyttöjärjestelmää ei välttämättä päivitetä, kun ei ole tarvetta)

seis_.kat kirjoitti:

Teollisuudessa on myös monia sellaisia pc:tä jotka eivät ole verkossa ja on pyhitetty vain yhteen tehtävään (niiden käyttöjärjestelmää ei välttämättä päivitetä, kun ei ole tarvetta)

Lue lisää

Toki. Niihin on ostettu varaosia/tietokoneita, käyttöjärjestelmälisenssit mukaan lukien sekä myös laitteet/osat kehityspuolelle jotta laitteessa olevaa koodia voi ylläpitää.

Niidenkin tapauksessa on järkevää keskittyä tekemään migraatiota jotta se koodi kääntyy nykyisellä työkaluversiolla ja nykyisille/tuleville käyttöjärjestelmille koska ennen pitkään varaosat loppuvat. Ohjelmistojen saatavuuksiakin rajoitetaan.

Sitä paitsi, Delphi 7 kuuluu mukaan hintaan kun ostaa nykyisen version: http://www.embarcadero.com/products/delphi/previous-versions

Että ei siis mikään ongelma.

Loistava esimerkki legacykoodin ylläpidosta.

Delphi 7 :n jälkeinen Delphi oli net arkkitehtuurille (sen 1.0 versiolle tehty). MS teki pian sen jälkeen net 2.0 jossa ei enään toimineet version 1.0 ohjelmat ... (Mutta Delphi 7:lla tehdyt toimivat)...

write_once kirjoitti:

Delphi 7 :n jälkeinen Delphi oli net arkkitehtuurille (sen 1.0 versiolle tehty). MS teki pian sen jälkeen net 2.0 jossa ei enään toimineet version 1.0 ohjelmat ... (Mutta Delphi 7:lla tehdyt toimivat)...

Lue lisää

.NET 1.0 toimi Windows 98/NT4 .. Windows XP/2003. .NET 1.0 toimi .NET 2.0:n rinnalla Windows XP asennuksissa. .NET 2.0 ei siis hajottanut .NET 1.0 ohjelmia Windows XP asennuksissa.

.NET 2.0 toimii vielä Windows 8.1:llä ja odotettavasti myös Windows 10:llä.

Delphi 7:lla tehty koodi on arkkitehtuuririippuvaista ja käyttää deprekoituja Win32 API kutsuja. On siis mahdollista, että kaikki Delphi 7 ohjelmat lakkaavat toimimasta Windows 10:llä. ARM prosessorilla ne ei ainakaan toimi.

On myös hyvin todennäköistä, että Delphi 7:lla tehdyt ohjelmat ei skaalaudu 4K/8K tarkkuuksille vaan ulkoasu alkaa hajoilla DPI:n kasvaessa (en ole testannut).

Maailmassa on kaikkein eniten Win32 sovelluksia, joten Microsoft tulee varmistamaan niiden toimivuuden vielä pitkään tulevaisuuteen.

Käy helposti niin että M-Kar käyttämät ns. nykypäivän työkalut / järjestelmät (muut kuin Windows) vanhenee jo 5 vuodessa. Mutta D7 edelleen toimii.

Skaalautuvuus tuli esille omissa sovelluksissa jo vuosia sitten, mutta oli varsin helppo korjata.

Ja jos vaikka tablettia on hankkimassa, niin tietenkin ottaa sellaisen jossa Intel prosessori.

D7_toimii kirjoitti:

Maailmassa on kaikkein eniten Win32 sovelluksia, joten Microsoft tulee varmistamaan niiden toimivuuden vielä pitkään tulevaisuuteen.

Käy helposti niin että M-Kar käyttämät ns. nykypäivän työkalut / järjestelmät (muut kuin Windows) vanhenee jo 5 vuodessa. Mutta D7 edelleen toimii.

Skaalautuvuus tuli esille omissa sovelluksissa jo vuosia sitten, mutta oli varsin helppo korjata.

Ja jos vaikka tablettia on hankkimassa, niin tietenkin ottaa sellaisen jossa Intel prosessori.

Lue lisää

Höpöhöpö. Selaintekniikkaa sovellukset on suurimmaksi osaksi. Win32 rajapintakutsuista on suuri osa deprekoitu ja niitä poistellaan: https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=vs.85).aspx#deprecated_or_legacy_apis

Itseasiassa Windows 8.1 pudotti jo sen vanhan tavan tarkistaa Windowsin version: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451(v=vs.85).aspx

Windows 2000:ssa tuli uudempi tapa mutta ohjelmat jotka on vanhempaa perua ja tarkistavat versiota, ovat alkaneet paukkua rikki. Mitenkäs käyttöliittymän piirto D7:ssa, että käyttääkö Direct2D:tä?

Lähtökohtaisesti paras varmuus pitkälle tulevaisuuteen on käyttää standardia tekniikkaa sovelluksessa, eli käytännössä HTML5:sta. Se on parhaiten futureproof. Vaihtoehtoisesti sitten tekniikka jolle nimenoman LUVATAAN jatkuvuus. LSB standardin mukaiset kirjastot ovat sellaisia ja samoin esim. Java. Oracle lupaa Javalle binääriyhteensopivuuden kolme julkaisua eteenpäin, eli nykyiselle Java 8:lle jos tekee softaa niin se toimii vielä Java 11 sellaisenaan ilman että tarvitsisi kääntää koodia uudestaan

Red Hat taas lupaa keskeisille kirjastoille myös samaa, että nykyiselle Red Hat Enterprise 7:lle saa tehtyä softaa mitkä toimii sellaisenaan Red Hat Enterprise 9:ssä, eli parikymmentä vuotta tulevaisuuteen ilman muutoksia.

Eli jos HTML5 ei kelpaa niin selvästi varmimpia on Qt, Java, GTK ja SDL. Ne on erittäin varmoja, sillä vaikka niiden ylläpidon joku lopettaisi vuosikymmenten kuluttua niin niihin saa edelleen lähdekoodit joten ne saa tarvittaessa itse käännettyä uusiksi.

Puhtaasti Microsoftin tekniikoilla mentäessä paras jatkuvuus on tietysti WinRT:llä. Seuraavaksi pisimpään toimii .NET 4.x softat.

M-Kar kirjoitti:

Höpöhöpö. Selaintekniikkaa sovellukset on suurimmaksi osaksi. Win32 rajapintakutsuista on suuri osa deprekoitu ja niitä poistellaan: https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=vs.85).aspx#deprecated_or_legacy_apis

Itseasiassa Windows 8.1 pudotti jo sen vanhan tavan tarkistaa Windowsin version: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451(v=vs.85).aspx

Windows 2000:ssa tuli uudempi tapa mutta ohjelmat jotka on vanhempaa perua ja tarkistavat versiota, ovat alkaneet paukkua rikki. Mitenkäs käyttöliittymän piirto D7:ssa, että käyttääkö Direct2D:tä?

Lähtökohtaisesti paras varmuus pitkälle tulevaisuuteen on käyttää standardia tekniikkaa sovelluksessa, eli käytännössä HTML5:sta. Se on parhaiten futureproof. Vaihtoehtoisesti sitten tekniikka jolle nimenoman LUVATAAN jatkuvuus. LSB standardin mukaiset kirjastot ovat sellaisia ja samoin esim. Java. Oracle lupaa Javalle binääriyhteensopivuuden kolme julkaisua eteenpäin, eli nykyiselle Java 8:lle jos tekee softaa niin se toimii vielä Java 11 sellaisenaan ilman että tarvitsisi kääntää koodia uudestaan

Red Hat taas lupaa keskeisille kirjastoille myös samaa, että nykyiselle Red Hat Enterprise 7:lle saa tehtyä softaa mitkä toimii sellaisenaan Red Hat Enterprise 9:ssä, eli parikymmentä vuotta tulevaisuuteen ilman muutoksia.

Eli jos HTML5 ei kelpaa niin selvästi varmimpia on Qt, Java, GTK ja SDL. Ne on erittäin varmoja, sillä vaikka niiden ylläpidon joku lopettaisi vuosikymmenten kuluttua niin niihin saa edelleen lähdekoodit joten ne saa tarvittaessa itse käännettyä uusiksi.

Puhtaasti Microsoftin tekniikoilla mentäessä paras jatkuvuus on tietysti WinRT:llä. Seuraavaksi pisimpään toimii .NET 4.x softat.

Lue lisää

Heh.. katsoin juuri että käytän yhtä Javalla tehtyä sovellusta joka on tehty Java 1.3:lle, eli vuoden 2000 Javalle ja se toimii edelleen ilman uudelleenkääntämistä tuossa yhdessä koneessa jossa oli Java 7. En ole Java 8:lla kokeillut.

Tuon linkin mukaan OpenGL on myös deprekoitu? Mutta eikös OpenGL rajapinta tule näyttiksen ajureissa vai olenko väärässä?

opengldep kirjoitti:

Tuon linkin mukaan OpenGL on myös deprekoitu? Mutta eikös OpenGL rajapinta tule näyttiksen ajureissa vai olenko väärässä?

Ei varmaan ole mitään väliä kun WinRT sovelluksissa sitä ei pysty hyödyntämään mitenkään. Windowsia ei ole tarkoitettu OpenGL:lle. WebGL kyllä toimii nyt ja jatkossa ja se vastaa OpenGL ES 2.0:aa.

M-Kar kirjoitti:

.NET 1.0 toimi Windows 98/NT4 .. Windows XP/2003. .NET 1.0 toimi .NET 2.0:n rinnalla Windows XP asennuksissa. .NET 2.0 ei siis hajottanut .NET 1.0 ohjelmia Windows XP asennuksissa.

.NET 2.0 toimii vielä Windows 8.1:llä ja odotettavasti myös Windows 10:llä.

Delphi 7:lla tehty koodi on arkkitehtuuririippuvaista ja käyttää deprekoituja Win32 API kutsuja. On siis mahdollista, että kaikki Delphi 7 ohjelmat lakkaavat toimimasta Windows 10:llä. ARM prosessorilla ne ei ainakaan toimi.

On myös hyvin todennäköistä, että Delphi 7:lla tehdyt ohjelmat ei skaalaudu 4K/8K tarkkuuksille vaan ulkoasu alkaa hajoilla DPI:n kasvaessa (en ole testannut).

Lue lisää

"On myös hyvin todennäköistä, että Delphi 7:lla tehdyt ohjelmat ei skaalaudu 4K/8K tarkkuuksille vaan ulkoasu alkaa hajoilla DPI:n kasvaessa (en ole testannut)."

oletuksena luultavasti näytönkäsittely tosiaan sekoaa.

Mutta tuo on kyllä korjattavissa.

Delphin VCL kun on avointa lähdekoodia, tosin tuo avoin lähdekoodi EI tarkoita samaa kuin miten FSF tuota termiä käyttää.

Eli siis Delphin VCL on avointa lähdekoodia niille, jotka omistavat laillisesti hankitun lisenssin Delphin käyttöön.
Lähdekoodi on toki tekijänoikeuslain suojaama, eli sitä ei voi laillisesti levittää esim. netissä.

Mutta kun se tulee Delphin mukana, niin kukaan ei estä korjaamasta vikoja, osaamista tuo tietenkin vaatii.

Mutta kun Delphi -osaamista on, niin helpompaa on korjat aDelphin VCL:n virheet kuin opetella esim sellaista hirviökieltä kuin C .

10 vuotta vanha C -ohjelma kun tuottaa gcc:llä vain kasan kryptisiä virheilmoituksia.

20 vuotta vanha Delphi -koodi sensijaan kääntyy uudellakin Delphillä. Tosin, jos noin vanhaa koodia kääntää Delphi 2009 tai uudemmilla, kannattaa tarkistaa, miten merkkijonoja on käytetty.

Delphi2009:ssä ja uudemmissa kun String on synonyymi sanalle UnicodeString.

Vanhemmissa Delpheissä (Delphi 2.0 ... Delphi 2007) String on synonyymi sanalle AnsiString.

Ainoastaan Delphi 1.0:ssa String on itseasiassa ShortString (max. pituus 255 merkkiä).

Jo Delphi 2.0:ssa tuli uutena tyyppinä AnsiString, jonka maksimipituus on teoriassa 2147483647 merkkiä, tosin muistin määrä ja käyttöjärjestelmäarkkitehtuuri käytännössä rajoittaa merkkijonon pituuden huomattavasti pienemmäksi.

Mkar_sekoilee_taas kirjoitti:

"On myös hyvin todennäköistä, että Delphi 7:lla tehdyt ohjelmat ei skaalaudu 4K/8K tarkkuuksille vaan ulkoasu alkaa hajoilla DPI:n kasvaessa (en ole testannut)."

oletuksena luultavasti näytönkäsittely tosiaan sekoaa.

Mutta tuo on kyllä korjattavissa.

Delphin VCL kun on avointa lähdekoodia, tosin tuo avoin lähdekoodi EI tarkoita samaa kuin miten FSF tuota termiä käyttää.

Eli siis Delphin VCL on avointa lähdekoodia niille, jotka omistavat laillisesti hankitun lisenssin Delphin käyttöön.
Lähdekoodi on toki tekijänoikeuslain suojaama, eli sitä ei voi laillisesti levittää esim. netissä.

Mutta kun se tulee Delphin mukana, niin kukaan ei estä korjaamasta vikoja, osaamista tuo tietenkin vaatii.

Mutta kun Delphi -osaamista on, niin helpompaa on korjat aDelphin VCL:n virheet kuin opetella esim sellaista hirviökieltä kuin C .

10 vuotta vanha C -ohjelma kun tuottaa gcc:llä vain kasan kryptisiä virheilmoituksia.

20 vuotta vanha Delphi -koodi sensijaan kääntyy uudellakin Delphillä. Tosin, jos noin vanhaa koodia kääntää Delphi 2009 tai uudemmilla, kannattaa tarkistaa, miten merkkijonoja on käytetty.

Delphi2009:ssä ja uudemmissa kun String on synonyymi sanalle UnicodeString.

Vanhemmissa Delpheissä (Delphi 2.0 ... Delphi 2007) String on synonyymi sanalle AnsiString.

Ainoastaan Delphi 1.0:ssa String on itseasiassa ShortString (max. pituus 255 merkkiä).

Jo Delphi 2.0:ssa tuli uutena tyyppinä AnsiString, jonka maksimipituus on teoriassa 2147483647 merkkiä, tosin muistin määrä ja käyttöjärjestelmäarkkitehtuuri käytännössä rajoittaa merkkijonon pituuden huomattavasti pienemmäksi.

Lue lisää

"Mutta tuo on kyllä korjattavissa."

Käytännössä ei kun melkein koko p4ska pitäisi tehdä uusiksi. Ensiksikin tarvitaan Pascal kääntäjä joka kääntää WinRT:lle ja VCL pitää kirjoittaa uusiksi niin, että käytetään WinRT:tä eikä Win32 API:a. VCL:ää pitää suurella todennäköisyydellä myös muuttaa erilaiseksi, että saa katkottua riippuvuudet Win32:n ikkuna/widget piirto-ominaisuuksiin. Tämähän ollut syynä miksi Borland epäonnistui Kylixi kanssa.

Tarkoittaa käytännössä sitä, että rikotaan myös ne Delphillä tehdyt ohjelmat niin, että pitää niitä kirjoittaa osittain uusiksi.

Vähemmän vaivaa siis kirjoittaa sovellus uusiksi paremmalla työkalulla.

"Mutta kun Delphi -osaamista on, niin helpompaa on korjat aDelphin VCL:n virheet kuin opetella esim sellaista hirviökieltä kuin C ."

C :ssa ei ole mitään hirviötä, mutta en nyt ymmärrä miten C liittyy tähän? Ihan kuin maailmassa ei olisi muita kieliä kuin joku obsoleetti Pascal ja nykypäivänä erikoistarkoituksiin tarkoitettu C .

Päätelaitteiden sovellusohjelmoinnissa esimerkiksi Typescript on yleensä sopivampi.

"10 vuotta vanha C -ohjelma kun tuottaa gcc:llä vain kasan kryptisiä virheilmoituksia."

Ja niistä se ensimmäinen kuplii myöhempiin ilmoituksiin, että pari ensimmäistä ilmoitusta kun käy läpi ja kääntää uusiksi niin sitten toimii.

Tai sitten laittaa kääntäjän valitsimeen aiemman standardiversion mutta tietysti ohjelmia kannattaa ylläpitää ja kääntää välillä uusiksi uudemmilla versioilla ja samalla siistii rakenteita käyttämällä kielen/frameworkin uusia ominaisuuksia, ja tällä tavalla vähentää omaa koodia.

C :lla tarvittavien koodirivien määrä on vähentynyt kaiken aikaa ja saa varmasti siistimpiä ohjelmia kuin mitä jollain 14v vanhalla Pascalilla. Eihän Pascaliin saa vieläkään Lambda lausekkeita. C :aa sen sijaan pystyy ohjelmoimaan paljon jo funktionaalisesti.

M-Kar kirjoitti:

"Mutta tuo on kyllä korjattavissa."

Käytännössä ei kun melkein koko p4ska pitäisi tehdä uusiksi. Ensiksikin tarvitaan Pascal kääntäjä joka kääntää WinRT:lle ja VCL pitää kirjoittaa uusiksi niin, että käytetään WinRT:tä eikä Win32 API:a. VCL:ää pitää suurella todennäköisyydellä myös muuttaa erilaiseksi, että saa katkottua riippuvuudet Win32:n ikkuna/widget piirto-ominaisuuksiin. Tämähän ollut syynä miksi Borland epäonnistui Kylixi kanssa.

Tarkoittaa käytännössä sitä, että rikotaan myös ne Delphillä tehdyt ohjelmat niin, että pitää niitä kirjoittaa osittain uusiksi.

Vähemmän vaivaa siis kirjoittaa sovellus uusiksi paremmalla työkalulla.

"Mutta kun Delphi -osaamista on, niin helpompaa on korjat aDelphin VCL:n virheet kuin opetella esim sellaista hirviökieltä kuin C ."

C :ssa ei ole mitään hirviötä, mutta en nyt ymmärrä miten C liittyy tähän? Ihan kuin maailmassa ei olisi muita kieliä kuin joku obsoleetti Pascal ja nykypäivänä erikoistarkoituksiin tarkoitettu C .

Päätelaitteiden sovellusohjelmoinnissa esimerkiksi Typescript on yleensä sopivampi.

"10 vuotta vanha C -ohjelma kun tuottaa gcc:llä vain kasan kryptisiä virheilmoituksia."

Ja niistä se ensimmäinen kuplii myöhempiin ilmoituksiin, että pari ensimmäistä ilmoitusta kun käy läpi ja kääntää uusiksi niin sitten toimii.

Tai sitten laittaa kääntäjän valitsimeen aiemman standardiversion mutta tietysti ohjelmia kannattaa ylläpitää ja kääntää välillä uusiksi uudemmilla versioilla ja samalla siistii rakenteita käyttämällä kielen/frameworkin uusia ominaisuuksia, ja tällä tavalla vähentää omaa koodia.

C :lla tarvittavien koodirivien määrä on vähentynyt kaiken aikaa ja saa varmasti siistimpiä ohjelmia kuin mitä jollain 14v vanhalla Pascalilla. Eihän Pascaliin saa vieläkään Lambda lausekkeita. C :aa sen sijaan pystyy ohjelmoimaan paljon jo funktionaalisesti.

Lue lisää

Kylix oli hyvä tuote jos kysyt sen käyttäjiltä. Mutta QT "mätäni" alta pois.

Mieti kuinka paljon uusia kieliä on tullut viimeisen vuoden aikana QT:tä hyödyntämään. Miksi niin vähän?

QTvanhen kirjoitti:

Kylix oli hyvä tuote jos kysyt sen käyttäjiltä. Mutta QT "mätäni" alta pois.

Mieti kuinka paljon uusia kieliä on tullut viimeisen vuoden aikana QT:tä hyödyntämään. Miksi niin vähän?

Lue lisää

"Kylix oli hyvä tuote jos kysyt sen käyttäjiltä. Mutta QT "mätäni" alta pois."

Nyt puhut p4skaa. Qt on aivan eri juttu kuin Kylix eikä se ole mihinkään mätääntynyt. Borland oli tehnyt virheet jo aikaisemmin VCL:n kanssa kun se oli niin tiukasti sitoutunut Win32:n ja se ei kyennyt sitä implementoimaan Kylixiin. Sen takia ne kyhäsi jonkun VCL:n kanssa yhteensopimattoman CLX virityksen Qt varaan. IDE taas ei edes oltu tehty sillä CLX virityksellä vaan se pyöri jonkun Winen varassa.

Täysi pa5ka siis. Sen sijaan Qt on edelleen hyvin ylläpidetty, Kylix sen sijaan on mätääntynyt ja siitä ei muutenkaan saatu tehtyä kuin muutama heikkolaatuinen julkaisu.

"Mieti kuinka paljon uusia kieliä on tullut viimeisen vuoden aikana QT:tä hyödyntämään. Miksi niin vähän?"

Kuinka paljon uusia kieliä on tullut hyödyntämään VCL:ää? Entäs CLX:ää?

Qt:tä on tarkoitus ohjelmoida QML:llä ja C :lla. Jos joku haluaa tehdä wrapperia niin tehkööt, täysin merkityksetöntä.

Ohjelmat eivät kulu käytössä. Ne mätänee.

Ei tuollaisilla mitään tee. Vanhat softat tietysti uusitaan. Ikivanhat Delphi 7:lla käännetyt ohjelmat voi kääntää uusiksi vaikka Lazaruksella tai uudemmalla Delphillä.

Lazarus taitaa kyllä olla turvallisempi koska toimii useammalla käyttöjärjestelmällä.

No mitä mieltä olet emulaattoreista ja sen tapaisista (windowsille). Otetaan esimerkiksi Wine?

phii kirjoitti:

No mitä mieltä olet emulaattoreista ja sen tapaisista (windowsille). Otetaan esimerkiksi Wine?

Ei järkeä kun voi yhtä hyvin kääntää sen lähdekoodin nykyisille järjestelmille.

Ei tietenkään arvosta kun parempaakin löytyy. Noista vanhoista kielistä Ada on esimerkiksi paljon parempi kuin Pascal.

M-Kar kirjoitti:

Ei tietenkään arvosta kun parempaakin löytyy. Noista vanhoista kielistä Ada on esimerkiksi paljon parempi kuin Pascal.

Delphin kieli ei ole pascal, vaan objectpascal.

Ja jos kirjoitan Delphi7:lla ohjelman tänään,varsin suurella todennäköisyydellä se toimii Windows -käyttöjärjestelmässä vielä 20 vuoden päästä.

Ei mitään järkeä vaihtaa kieltä - objectpascal hakkaa kielenä kaikki nämä: java, C, C , C#.

Ja WIN32api:a tuetaan vielä pitkään. Todennäköisesti Win32 api lakkaa toimimasta sitten, kun MS julkaisee 128 -bittisen windowsin.

Eli 64-bittisissä windowseissa voi ajaa 32-bittisiä windows-soveluksia.

M-karin höpinät voi siis jättää omaan arvoonsa - Delphi -ohjelmat tulevat toimimaan hyvin pitkään!

JOS ja kun MS joskus tosiaan julkaisee joskus 128 -bittisen windowsin, tuolloin Delphi7:lla tehdyt sovellukset täytyy kääntää uudelleen joko 64 tai 128 -bittisellä Delphin versiolla tai vaihtoehtoisesti Free Pascal Lazarus -yhdistelmällä.

WinRT:n käyttöön ei ole mitään syytä.

WIN32 api toimii niin kauan kuin 32 -bittisiä sovelluksia tuetaan.

Ja jos tuo tuki joskus poistuu, Delphistä on jo olemassa 64 -bittinen versio, jolloin käännetään ohjelmat sillä.

Kaikki Delphin VCL -komponentit luonnollisesti käyttävät Win64 api:a jos käännetään 64 -bittisellä Delphillä.

Miksi käyttää hankalakäyttöistä QT:ta, kun Delphin omat komponentit toimivat pitkälle tulevaisuuteen, joko 32 -tai 64 -bittisinä versioina?

delphi_rules kirjoitti:

Delphin kieli ei ole pascal, vaan objectpascal.

Ja jos kirjoitan Delphi7:lla ohjelman tänään,varsin suurella todennäköisyydellä se toimii Windows -käyttöjärjestelmässä vielä 20 vuoden päästä.

Ei mitään järkeä vaihtaa kieltä - objectpascal hakkaa kielenä kaikki nämä: java, C, C , C#.

Ja WIN32api:a tuetaan vielä pitkään. Todennäköisesti Win32 api lakkaa toimimasta sitten, kun MS julkaisee 128 -bittisen windowsin.

Eli 64-bittisissä windowseissa voi ajaa 32-bittisiä windows-soveluksia.

M-karin höpinät voi siis jättää omaan arvoonsa - Delphi -ohjelmat tulevat toimimaan hyvin pitkään!

JOS ja kun MS joskus tosiaan julkaisee joskus 128 -bittisen windowsin, tuolloin Delphi7:lla tehdyt sovellukset täytyy kääntää uudelleen joko 64 tai 128 -bittisellä Delphin versiolla tai vaihtoehtoisesti Free Pascal Lazarus -yhdistelmällä.

WinRT:n käyttöön ei ole mitään syytä.

WIN32 api toimii niin kauan kuin 32 -bittisiä sovelluksia tuetaan.

Ja jos tuo tuki joskus poistuu, Delphistä on jo olemassa 64 -bittinen versio, jolloin käännetään ohjelmat sillä.

Kaikki Delphin VCL -komponentit luonnollisesti käyttävät Win64 api:a jos käännetään 64 -bittisellä Delphillä.

Miksi käyttää hankalakäyttöistä QT:ta, kun Delphin omat komponentit toimivat pitkälle tulevaisuuteen, joko 32 -tai 64 -bittisinä versioina?

Lue lisää

"Ja jos kirjoitan Delphi7:lla ohjelman tänään,varsin suurella todennäköisyydellä se toimii Windows -käyttöjärjestelmässä vielä 20 vuoden päästä."

Ei tosiaankaan! Delphi 7 kääntää Win32 API:n päälle ja käyttää ikivanhoja rajapintakutsuja joita on deprekoitu: https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=vs.85).aspx#deprecated_or_legacy_apis

"Ja WIN32api:a tuetaan vielä pitkään."

Microsoft julkaissut jo Windowseja missä ei ole Win32 API:a, ja sen lisäksi Win32 API on arkkitehtuuririippuvainen ja Microsoft on viimeiset 14v liputtanut arkkitehtuuririippumattoman tekniikan (.NET) puolesta.

Nyt sitten on vuosikausia menty Windowstekniikassa siihen, että ollaan riippumattomia formfactorista. Sama sovellus siis toimii vaikka Xboxissa, tabletissa, pöytäkoneessa jne.

Et nähtävästi käsitä sitä, että Win32 on johdettu 80-luvun Win16 API:sta ja ollut ilmestyessään jo vanhentunut sillä tasolla, että varsinainen sovelluskehitys tehdään korkeamman tason rajapinnoilla, kuten MFC ja Visual Basic ennen .NET:iä.

Win32 API:sta voidaan pudotella toimintoja kun edelleen Microsoftin tukemissa korkeamman tason rajapinnoissa niitä enää tarvitse. Niitä toimintoja on jo pudotettu! Kyllä se Win32 API vielä on ainakin vajaa 10v mukana mutta sinä aikana ominaisuuksia mitä Visual C 2015 kehitys ei vaadi, voi helposti poistua. Nykyään Windows 10:ssä Microsoftin tarvitsee enää tukea Visual C 2005:sta ja uudempia mutta Windows XP:n Win32 API:n kutsut ja DirectX6 2D:n ja DirectX 7:n tarvitsemat kutsut on edelleen tallella. Windowsin päivittyessä 2-4x vuodessa uudemmaksi, voidaan noita tarpeettomiksi jääneitä kutsuja siivota pois.

Eli, vaikka Win32 API on olemassa, sieltä voidaan siivota vanhoja funktiota pois mitä uudemmat rajapinnat ei tarvitse ja se rikkoo myös jossain vaiheessa Delphi 7:lla käännetys sovellukset. Riskiryhmässä on aina kaikki yli 10v vanhoilla ohjelmointivälineillä Win32 API:a vasten käännetyt sovellukset, eli koskee myös Delphi 7:aa.

"Ei mitään järkeä vaihtaa kieltä - objectpascal hakkaa kielenä kaikki nämä: java, C, C , C#."

No ei hakkaa.
-C = standardoitu, defacto systeemitason ohjelmoinnissa
-C = standardoitu, lambda lausekkeet
-C# = standardoitu, lambda lausekkeet, arkkitehtuuririippumaton käännös
-Java = arkkitehtuuririippumaton, lambda lausekkeet

Sen lisäksi näitä kaikkia käytetään myös yleisesti eri teknologia firmoissa kuten Googlella, Microsoftilla, Applella, Red Hatilla, Canonicalilla jne. Sen lisäksi nämä kaikki paitsi ehkä C pois lukien, hoitaa homman vähemmillä koodiriveillä.

"Ja WIN32api:a tuetaan vielä pitkään. Todennäköisesti Win32 api lakkaa toimimasta sitten, kun MS julkaisee 128 -bittisen windowsin."

Win32 API lakkasi toimimasta jo Windows Phonella ja Windows 8 RT:llä. Windows 10:n kun asentaa Raspberryn tai Pineen niin ei toimi Delphi 7 sovellukset. Eikä toimi myöskään AMD:n ARM serveriprossuilla mikään x86 Windowssovellus.

Katsos kun et nähtävästi käsitä, että x86 ja x86-64 on väistyvää tekniikkaa myös ja kokoajan kutistuva osa laitteista ajaa mitään Windows XP aikaista Win32 API x86 koodia. Väistyy niin Windows, Win32 API:n vanhemmat kutsut kuin myös laitearkkitehtuuri.

"JOS ja kun MS joskus tosiaan julkaisee joskus 128 -bittisen windowsin, tuolloin Delphi7:lla tehdyt sovellukset täytyy kääntää uudelleen joko 64 tai 128 -bittisellä Delphin versiolla tai vaihtoehtoisesti Free Pascal Lazarus -yhdistelmällä."

Lazarus on ikävästi myös Win32/Win64 API loukossa ja ei sitten esim. skaalaudu ohjelmat kunnolla tarkemmille resoluutioille, että ennemminkin Delphi 7:sta oli aika siirtää Lazarukseen jotain 4v sitten ja samalla vähän säätää leiskaa niin, että on isompaa fonttia niin pystyy tekohengittämään vielä tarkemmilla näytöillä.

"WinRT:n käyttöön ei ole mitään syytä."

Sehän on se natiivi tapa tehdä Windowsille sovelluksia.

"WIN32 api toimii niin kauan kuin 32 -bittisiä sovelluksia tuetaan."

Se ei pysy samanlaisena vaan vanhoja juttuja pudotetaan siitä vähitellen ennen kuin se poistuu kokonaan. Sitten kun Microsoft julkaisee Visual C :n ilman 32-bit runtimea, tiedetään Win32 API:n poistuvan n. 10v aikana tästä edeltävän Visual Studion julkaisusta.

"Ja jos tuo tuki joskus poistuu, Delphistä on jo olemassa 64 -bittinen versio, jolloin käännetään ohjelmat sillä."

Olisi hyvä olla WinRT:lle kääntävä versio kun nuo vanhemmat rajapinnat putoaa. Delphi 7 esim. piirsi vielä jonkun GDI:n kautta juttuja.

"Miksi käyttää hankalakäyttöistä QT:ta, kun Delphin omat komponentit toimivat pitkälle tulevaisuuteen, joko 32 -tai 64 -bittisinä versioina?"

Qt on tunnetusti helppokäyttöisempi ja toimii varmemmin pitkälle tulevaisuuteen, koska arkkitehtuuririippuvuutta alettiin purkamaan viime vuosikymmenen puolella jo. Mitä enemmän oma koodi toimii niin, että tarvitsee palikoita joita käännetään jollekin laitearkkitehtuurille tai Win64:lle, sitä varmemmin toimii jatkossa. Delphin ja Lazaruksen ongelmana on arkkitehtuuririippuvuudet ja myös riippuvuus Win32/Win64:n.