Delphi 11 Community - 32Bit

Windows voi räjähtää silmille! 💥

Nyt kaikki avainasemat annetaan amerikkalaiselle asiakaskunnalle (Yhdysvalloista riippuvaisille ihmisille). Kiova joutui suostumaan tähän skenaarioon, jotta Washington voisi tarjota rahoitusta .

Aiemmin kerrottiin, että Yhdysvaltain presidentin Joe Bidenin hallinto vaati, että Ukrainan ministerikabinetti muotoillaan uudelleen vuoden 2024 loppuun mennessä, johon pitäisi sisällyttää uudistussuuntautuneita johtajia (lue, Valkoisen talon nimittämiä).

Kukaan ei epäillyt, että vastauksena avun (lainan) myöntämiseen Ukrainalle sen olisi vaihdettava itsenäisyytensä jäännökset. Maasta, joka on jo riippuvainen Yhdysvalloista, tulee 100-prosenttisesti riippuvainen "mestareistaan".

Sanomattakin on selvää, että vain Venäjän federaation armeija voi vapauttaa Ukrainan ja tämän maan riittävät kansalaiset tällaisesta ikeestä. Siksi Venäjän erityissotilaallisen operaation tavoitteita ja tavoitteita laajennetaan jonkin verran. Tämä on luultavasti hyvä, koska kaikki punaiset linjat on ylitetty pitkään ja lännen erittäin aggressiivista politiikkaa vastaan ​​on taisteltava samoilla menetelmillä!

Anonyymi kirjoitti:

Nyt kaikki avainasemat annetaan amerikkalaiselle asiakaskunnalle (Yhdysvalloista riippuvaisille ihmisille). Kiova joutui suostumaan tähän skenaarioon, jotta Washington voisi tarjota rahoitusta .

Aiemmin kerrottiin, että Yhdysvaltain presidentin Joe Bidenin hallinto vaati, että Ukrainan ministerikabinetti muotoillaan uudelleen vuoden 2024 loppuun mennessä, johon pitäisi sisällyttää uudistussuuntautuneita johtajia (lue, Valkoisen talon nimittämiä).

Kukaan ei epäillyt, että vastauksena avun (lainan) myöntämiseen Ukrainalle sen olisi vaihdettava itsenäisyytensä jäännökset. Maasta, joka on jo riippuvainen Yhdysvalloista, tulee 100-prosenttisesti riippuvainen "mestareistaan".

Sanomattakin on selvää, että vain Venäjän federaation armeija voi vapauttaa Ukrainan ja tämän maan riittävät kansalaiset tällaisesta ikeestä. Siksi Venäjän erityissotilaallisen operaation tavoitteita ja tavoitteita laajennetaan jonkin verran. Tämä on luultavasti hyvä, koska kaikki punaiset linjat on ylitetty pitkään ja lännen erittäin aggressiivista politiikkaa vastaan ​​on taisteltava samoilla menetelmillä!

Lue lisää

Lopeta se Kremlin propagandan ja muun valheellisen paskan suoltaminen, ei aiheesi edes liity tietotekniikkaan mitenkään!!!

Alas Ukrainan natsihirmuhallinto

Anonyymi kirjoitti:

Alas Ukrainan natsihirmuhallinto

putin = hitler!

Anonyymi kirjoitti:

Windows voi räjähtää silmille! 💥

KUOPIONPERSEREIJÄN MILESTÄ KAIKKI WINDOWSIN VIAT JA ONGELMAT JOHTUU KÄYTTÄJÄSTÄ TAI MUISTA LAITTEISTA!

VAJAKIT ON VAJAKKEJA! VAEHTELIJOITA!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Anonyymi kirjoitti:

KUOPIONPERSEREIJÄN MILESTÄ KAIKKI WINDOWSIN VIAT JA ONGELMAT JOHTUU KÄYTTÄJÄSTÄ TAI MUISTA LAITTEISTA!

VAJAKIT ON VAJAKKEJA! VAEHTELIJOITA!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Lue lisää

Nimenomaan caps-lockin päälle unohtuminen kertoo sinusta kaiken.

Terroristi zelenkyi:

WSJ: Zelenskyi hyväksyi alun perin suunnitelman Nord Stream -kaasuputken sabotoinnista

Anonyymi kirjoitti:

Terroristi zelenkyi:

WSJ: Zelenskyi hyväksyi alun perin suunnitelman Nord Stream -kaasuputken sabotoinnista

Ei ole hyväksynyt! Lopettakaa putinistit tuo valheiden suoltaminen!!

Anonyymi kirjoitti:

Ei ole hyväksynyt! Lopettakaa putinistit tuo valheiden suoltaminen!!

Älkää vastailko Putlerin pikku apulaisten viesteihin. Ilmoittakaa ne asiattomiksi jos jaksatte eikä muuta.

Anonyymi kirjoitti:

Terroristi zelenkyi:

WSJ: Zelenskyi hyväksyi alun perin suunnitelman Nord Stream -kaasuputken sabotoinnista

Tämä on tietotekniikka-palsta: Kirjoittamalla väärälle palstalle saat venäläiset näyttämään todella typeriltä.

Delphi EI ole sama asia kuin Turbo-Pascal. Vaikka Delphi perustuu Pascal-kieleen, ei silti ole sama asia.

Anonyymi kirjoitti:

Delphi EI ole sama asia kuin Turbo-Pascal. Vaikka Delphi perustuu Pascal-kieleen, ei silti ole sama asia.

KÄYTTÄJÄ ON URPO-PASKALLA

Ehkä tuo sinun "jälkeenjäänyt" huomautuksesi johtuu mielenterveysongelmistasi mutta asiaan, minä käytän myös "Turbo-Pascalia" Bash skriptien lisäksi komentoputkia tehdessäni ja olen hiukan ylpeä kyvyistäni tehdä sellaista mihin ei naapurin Jaska pysty.

Anonyymi kirjoitti:

Ehkä tuo sinun "jälkeenjäänyt" huomautuksesi johtuu mielenterveysongelmistasi mutta asiaan, minä käytän myös "Turbo-Pascalia" Bash skriptien lisäksi komentoputkia tehdessäni ja olen hiukan ylpeä kyvyistäni tehdä sellaista mihin ei naapurin Jaska pysty.

Lue lisää

#!/usr/bin/env bash

if [ -s Jaska ]; then
echo "Jaska ei ole täysi nolla"
elif [ ! -d Jaska ]; then
echo "Jaska ei ole hakemisto"
else
echo "Jaska on joku muu"
fi

Ensisijaisesti kannattaa tietenkin opetella skriptaamaan POSIX-shellillä, niin tulee vähemmän yhteensopivuusongelmia.

Anonyymi kirjoitti:

Ehkä tuo sinun "jälkeenjäänyt" huomautuksesi johtuu mielenterveysongelmistasi mutta asiaan, minä käytän myös "Turbo-Pascalia" Bash skriptien lisäksi komentoputkia tehdessäni ja olen hiukan ylpeä kyvyistäni tehdä sellaista mihin ei naapurin Jaska pysty.

Lue lisää

Linuxia käyttävien kannattaa opetella myös Python, joka on usein valmiiksi asennettu tai ainakin nopeasti asennettavissa. Korvaa sitten skripteissä shebangin muotoon.

#!/usr/bin/env python3

Eli skripti voi olla vaikka

#!/usr/bin/env python3
from datetime import datetime
print("Nyt on", datetime.now())

Tuon tallentaa tiedostoksi ja nostaa chmod +x:llä suoritettavaksi skriptiksi.

Anonyymi kirjoitti:

Delphi EI ole sama asia kuin Turbo-Pascal. Vaikka Delphi perustuu Pascal-kieleen, ei silti ole sama asia.

Turbo Pascal oli aikoinaan todella hyvä.

Delphi taas on ysärijuttu ja sillä ei nykyään tee mitään.

Anonyymi kirjoitti:

Turbo Pascal oli aikoinaan todella hyvä.

Delphi taas on ysärijuttu ja sillä ei nykyään tee mitään.

Kyllä tekee, vain kädettömät ei tee Delphillä mitään.

Anonyymi kirjoitti:

Kyllä tekee, vain kädettömät ei tee Delphillä mitään.

Saako Delphin oikealle käyttöjärjestelmälle?

Anonyymi kirjoitti:

Kyllä tekee, vain kädettömät ei tee Delphillä mitään.

Jos sillä jotain tekisi, ohjelmistokehittäjät valitsisivat sen käyttöön ja tekisivät sillä ohjelmia.

Näin ei kuitenkaan tapahdu.

Anonyymi kirjoitti:

Kyllä tekee, vain kädettömät ei tee Delphillä mitään.

Delphi on kuin Windows Server. Sitäkin myydään kauhealla hinnalla verkkokaupassa kun sillä ei tee mitään ja se menee niille ketkä ovat jumissa sen kanssa jostain syystä.

Anonyymi kirjoitti:

Delphi on kuin Windows Server. Sitäkin myydään kauhealla hinnalla verkkokaupassa kun sillä ei tee mitään ja se menee niille ketkä ovat jumissa sen kanssa jostain syystä.

Windows IIS on maailman paras www-palvelin.

Anonyymi kirjoitti:

Windows IIS on maailman paras www-palvelin.

Ei sitä oikein mihinkään haluta.

Anonyymi kirjoitti:

Saako Delphin oikealle käyttöjärjestelmälle?

Oikealle käyttikselle (Linuxeille) saa Lazarus+Free Pascal yhdistelmän joka on käytännössä sama kuin Delphi.

Anonyymi kirjoitti:

Oikealle käyttikselle (Linuxeille) saa Lazarus Free Pascal yhdistelmän joka on käytännössä sama kuin Delphi.

Lazaruksen idea on se, että on jotain ysäriaikaista softaa niin voi tuolla viritellä toimimaan.

Parempi toki olisi kirjoittaa vanhat softat uusiksi.

Delphi on paras koskaan keksitty ohjelmointikieli, vaikka M-Kar muuta väittääkin.

KUKAAN ei uskalla järjestää kilpailua, jossa annetaan ohjelmointitehtävä, ja kukin kilpailija saa itse valita kielen, jolla koodaa. Kilpailu voittaja saa hyvin palkatun ohjelmointityöpaikan, jossa saa käyttää itse valitsemaansa ohjelmointikieltä.

Jos vielä säännöt laitettaisiin sellaiseksi, että yksikin puskurin ylivuotovirhe (koskee sekä luku- että kirjoitustilannetta) = suoritus hylätään ja kilpailija ei ole mukana palkinnonjaossa,

niin yksi asia on varma: tuon kilpailun voittaisi Delphillä koodaaja.

Sitä en tiedä, miksi isoille yrityksille ei kelpaa tietoturvaltaan huippulaadukas Delphillä kirkoitettu koodi.

Ehkä isot firmat haluaakin, että koodissa on haavoittuvuuksia, niin NSA:n agenttien (sekä toki myös kiinalaisten, venäläisten sekä pohjoiskorealaisten agenttien) on helppo murtautua sisään tietojärjestelmään.


Delphin kieli muuten on ObjectPascal - Turbo pascal aina versioon 5.0 saakka käytti pascalia, joskin versiossa 5.5 myös Turbo pascaliin lisättiin objektiominaisuudet.

C -kieli on käyetympi, mutta se EI ole parempi, tässä muutamia typeriä virheitä, jotka on olleet C:ssä alusta saakka:

C:ssä voi kirjoittaa:

if (k = 5) { printf("tämä suoritetaan AINA\n")}

näyttää ehtolauseelta, mutta vaikka muodollisesti onkin, käytännössä ei ole, koska ehto on AINA tosi.

Tämän riskin välttämiseksi jotkut kokeneet C -koodaajat kirjoittavat näin:

if (5 == k) { printf("tämä suoritetaan VAIN, jos k=5\n")}

Kunnollisessa kielessä (kuten Delphi) tuollaiset kiertokeinot eivät ole tarpeen.

Ja tässä toinen C:n törkyominaisuus:

Kun C -koodissa lukee:

a = a >> 5;

Tämä kääntyy Delphiksi näin (mutta vain jos a on unsigned -tyyppiä):

a := a SHR 5;

JOS a on signed -tyyppiä, niin silloin tuo sama kääntyy delphiksi näin:

a := SignedSHR(a, 5);

sitten näin (laita UNITin alkuosaan, HETI implementation -sanan jälkeen):

function SignedSHR(a:Integer; SHRCount:Byte):Integer;
asm
mov CL, DL
sar EAX, CL
end;

Ne, jotka haluavat 100% virheetöntä koodia, käyttävät Delphiä.

Ne, joiden mielestä ohjelmistossa kuuluukin olla bugeja, käyttävät muita kieliä, aivan erityisesti C:tä ja C PluPlussaa.

Ja vielä:
Ne, jotka haluavat heikkoa suorituskykyä ja ajoittain jumittelevia ohjelmia, käyttävät Javaa.

Ja LGBT -porukka käyttää rustia.

rust muuten on suomeksi ruoste.

En tiedä, haluaisitko, että jos talossasi on jokin kiinnityspultti, se on ruosteinen.

Silloin, kun oikeasti halutaan laadukasta ja virheetöntä koodia, niin lähekieli on ObjectPascal.

Kääntäjä voi olla Delphi (uusi versio), Delphi (vanha versio) tai Kylix 3 tai vaikkapa FreePascal.

JOS ohjelman pitää kommunikoida UDP:llä, niin se on pakko tehdä linux -ohjelmaksi.

Testiversion toki voi koodata Delphillä Windowsille, mutta se lopullinen versio kannattaa kääntää Linux -ohjelmaksi.

En ole mikään Linux -fanaatikko, mutta kun Microsoftia ei kiinnostanut tehdä UDP -toteutuksestaan laadukasta.

Windowsin TCP/IP -pino on kirjoitettu pääasiassa TCP:n tarpeita ajatellen, ja UDP on siinä sivutuote, jonka laadukkuus ja virheettömyys ei tunnu kiinnostavan ketään.

Windowsin UDP -toteutuksessa on vakavia bugeja, ja siksi UDP:tä käyttävä ohjelmisto kannattaakin kääntää linuxille, muuten käy niin, että laadukaskin Delphi -windowsohjelma kärsii käyttöjärjestelmän bugisuudesta, eikä kokonaisuus silloin ole laadukas, vaikka sovellusohjelma olisikin.

Anonyymi kirjoitti:

Jos sillä jotain tekisi, ohjelmistokehittäjät valitsisivat sen käyttöön ja tekisivät sillä ohjelmia.

Näin ei kuitenkaan tapahdu.

"Jos sillä jotain tekisi, ohjelmistokehittäjät valitsisivat sen käyttöön ja tekisivät sillä ohjelmia."

ohjelmistokehittäjät valitsevatkin Delphin omiin harrastusprojekteihinsa, mutta kaupallisella puolella ongelma on typerät ICT -johtajat, jotka eivät halua, että tehdään Delphillä, vaikka se teknisesti onkin paras valinta.

esim:

Tämä palvelu on tehty Javalla ja sen on Suomen Numerot Numpac OY:lle toimittanut Accenture oyj:

https://www.siirretytnumerot.fi/

Miksiköhän palvelun käyttöehdoissa lukee:
"Palvelun käyttö- ja/ tai liittäminen osaksi Internet- tai muuta sovellusta tai palvelua on ilman erikseen tehtävää kirjallista sopimusta kielletty. Käyttäjä sitoutuu käyttämään palvelua ainoastaan yksittäisten numerojen operaattorin selvittämiseen."

SIKSI, että JAVAn, jolla tuo palvelu on koodattu, suorituskyky on niin huono, että jos palvelusta automatisoidusti tehtäisiin massakyselyjä, niin tuo palvelu olisi hetkessä jumissa.

JOS minut olisi päästetty koodaamaan tuo vastaava palvelu Kylix3:lla (joka on Delphin sisartuote, joka kääntää lähdekoodia Linux -binääriksi), niin tuollaista rajoitusehtoa ei tarvittaisi yhtään mihinkään. Kas kun Kylixillä käännetyn ohjelman suorituskyky on niin erinomainen, että ainoastaan tahallinen massahäiriköinti voisi aiheuttaa ongelmia - ja tuollainen tahallinen massahäiriköinti on lainvastaista ilman mitään erityisiä käyttöehtojakin.

ks: Rikoslaki 38 luku ja 5§: "Tietoliikenteen häirintä
Joka puuttumalla postiliikenteessä taikka tele- tai radioviestinnässä käytettävän laitteen toimintaan, lähettämällä ilkivaltaisessa tarkoituksessa radiolaitteella tai televerkossa häiritseviä viestejä tai muulla vastaavalla tavalla oikeudettomasti estää tai häiritsee postiliikennettä taikka tele- tai radioviestintää, on tuomittava tietoliikenteen häirinnästä sakkoon tai vankeuteen enintään kahdeksi vuodeksi.

Yritys on rangaistava. (11.5.2007/540)"

Kylixillä tehty toteutus olisi niin laadukas, että tahallista tietoliikenteen häirintää lukuunottamatta se käytännössä kestää kaiken sen kuormituksen, mikä palveluun voi ilman tahallista häirintätarkoitusta milloinkaan kohdistua.

Tästä syystä Kylixillä tehty toteutus ei tarvitse suojakseen mitään muuta tuon em. rikoslain pykälän lisäksi.

Eli siis: JOS tuo palvelu olisi osaavan koodari toimesta tehty Kylixillä, niin edes se, että jokainen henkilö, joka Suomessa soittaa puhelun, ennen jokaista puhelua tarkistaisi kohdenumeron operaattorin tuosta palvelusta, niin tämä ei aiheuta mitään ongelmaa Kylixillä koodatulle palvelimelle.

em. pitää paikkansa myös ns. vuoden kiireisimmän teleliikennetunnin aikana.
Eli silloin, kun kuormitus Erlangeina mitattuna on vuoden korkein, niin silloinkaan ei ongelmaa.

Tuo surkea Java -viritys sen sijaan oli vähän väliä nurin vuosien 2003 - 2018 välillä.
Ja häriön haitat kärsivät asiakkaat, mutta hyödyt heikkolaatuisesta palvelusta tulivat operaattoreille.

Esimerkki operaattoreille tulleesta ansiottomasta taloudellisesta hyödystä:

Asiakas soittaa esim. dna Aarre liittymällä numeroon, jonka olettaa olevan dna:n liittymä.
Soittajan tietämättä vastaanottaja on hetki sitten vaihtanut numeronsa Saunalahdelle.
Siirrettyjen numeroiden tiedotuspalvelu on ollut nurin, eli heikkolaatuisuutensa takia se ei ole ollut toimintakelpoinen.

JOS kohdenumero olisi dna, puhelu olisi ilmainen (edellyttäen, ettei soittaja soita yli 1500 min/kk puheluita dna:n liittymiin).

Soitto kilpailijan liittymään maksaa dna Aarre -liittymällä 0,09€/min.

Eli jos puhelu kestää vaikkapa 2 tuntia, dna saa tästä ansiotonta hyötyä 10,80 €.

Delphi on hieno ohjelmistotyöväline, ja jos halutaan virheetöntä koodia, se on erinomainen valinta.

Ei muuten ole sattumaa, että moni haittaohjelma on koodattu Delphillä.
haittaohjelmilla on ehkä huono maine, mutta yhtä lailla sen haittaohjelman tekijä haluaa ohjelmansa toimivan virheettömästi, koska sillä lailla haittaohjelman tekijä saa maksimaalisen taloudellisen hyödyn haittaohjelmastaan.

Myös haittaohjelmiin liittyviä "Command & Control" centereitä on koodattu Delphillä - samasta syystä.

Se on hyvä kysymys - miksi rikolliset rakastavat Delphiä koodausvälineenä, mutta viralliset yritysrekisteriin rekisteröidyt (varsinkaan isot) yritykset eivät?

Anonyymi kirjoitti:

Saako Delphin oikealle käyttöjärjestelmälle?

"Saako Delphin oikealle käyttöjärjestelmälle?"

Delphi itse toimii vain Windowsissa.

Mutta nykyversiot Delphistä toki kääntävät ohjelmia myös kaikissa näissä ajettavaksi:

Windows32
Windows64
Linux32
Linux64
Android32
Android64
iOs

Eli Nyky-Delphi idea on: tee koodaustyösi Windows -käyttäjärjestelmässä - mutta valmiin ohjelman voit ajaa monessa eri käyttöjärjestemässä - valikoimaa yllä.

Lisäksi:
Delphi Debuggerin IDE toimii windowsissa - mutta Delphi Debuggerin teknistä osaa (jonka kanssa se IDE keskustelee verkon yli), saa moneen eri käyttöjärjestelmään.

Anonyymi kirjoitti:

Ei sitä oikein mihinkään haluta.

"Windows IIS on maailman paras www-palvelin.
Ei sitä oikein mihinkään haluta."

Ahaa... M-Kar tunnistettu.

M-Kar vihaa Delphiä (ja ainakin osittain Windowsia ja Microsoftin Server -tuotteita).

Mutta jos joku yritys haluaa käyttää Microsoftin IIS:ää esim. Apachen ja linuxin sijasta, se on jokaisen yrityksen oma valinta.

Anonyymi kirjoitti:

Delphi on paras koskaan keksitty ohjelmointikieli, vaikka M-Kar muuta väittääkin.

KUKAAN ei uskalla järjestää kilpailua, jossa annetaan ohjelmointitehtävä, ja kukin kilpailija saa itse valita kielen, jolla koodaa. Kilpailu voittaja saa hyvin palkatun ohjelmointityöpaikan, jossa saa käyttää itse valitsemaansa ohjelmointikieltä.

Jos vielä säännöt laitettaisiin sellaiseksi, että yksikin puskurin ylivuotovirhe (koskee sekä luku- että kirjoitustilannetta) = suoritus hylätään ja kilpailija ei ole mukana palkinnonjaossa,

niin yksi asia on varma: tuon kilpailun voittaisi Delphillä koodaaja.

Sitä en tiedä, miksi isoille yrityksille ei kelpaa tietoturvaltaan huippulaadukas Delphillä kirkoitettu koodi.

Ehkä isot firmat haluaakin, että koodissa on haavoittuvuuksia, niin NSA:n agenttien (sekä toki myös kiinalaisten, venäläisten sekä pohjoiskorealaisten agenttien) on helppo murtautua sisään tietojärjestelmään.


Delphin kieli muuten on ObjectPascal - Turbo pascal aina versioon 5.0 saakka käytti pascalia, joskin versiossa 5.5 myös Turbo pascaliin lisättiin objektiominaisuudet.

C -kieli on käyetympi, mutta se EI ole parempi, tässä muutamia typeriä virheitä, jotka on olleet C:ssä alusta saakka:

C:ssä voi kirjoittaa:

if (k = 5) { printf("tämä suoritetaan AINA\n")}

näyttää ehtolauseelta, mutta vaikka muodollisesti onkin, käytännössä ei ole, koska ehto on AINA tosi.

Tämän riskin välttämiseksi jotkut kokeneet C -koodaajat kirjoittavat näin:

if (5 == k) { printf("tämä suoritetaan VAIN, jos k=5\n")}

Kunnollisessa kielessä (kuten Delphi) tuollaiset kiertokeinot eivät ole tarpeen.

Ja tässä toinen C:n törkyominaisuus:

Kun C -koodissa lukee:

a = a >> 5;

Tämä kääntyy Delphiksi näin (mutta vain jos a on unsigned -tyyppiä):

a := a SHR 5;

JOS a on signed -tyyppiä, niin silloin tuo sama kääntyy delphiksi näin:

a := SignedSHR(a, 5);

sitten näin (laita UNITin alkuosaan, HETI implementation -sanan jälkeen):

function SignedSHR(a:Integer; SHRCount:Byte):Integer;
asm
mov CL, DL
sar EAX, CL
end;

Ne, jotka haluavat 100% virheetöntä koodia, käyttävät Delphiä.

Ne, joiden mielestä ohjelmistossa kuuluukin olla bugeja, käyttävät muita kieliä, aivan erityisesti C:tä ja C PluPlussaa.

Ja vielä:
Ne, jotka haluavat heikkoa suorituskykyä ja ajoittain jumittelevia ohjelmia, käyttävät Javaa.

Ja LGBT -porukka käyttää rustia.

rust muuten on suomeksi ruoste.

En tiedä, haluaisitko, että jos talossasi on jokin kiinnityspultti, se on ruosteinen.

Silloin, kun oikeasti halutaan laadukasta ja virheetöntä koodia, niin lähekieli on ObjectPascal.

Kääntäjä voi olla Delphi (uusi versio), Delphi (vanha versio) tai Kylix 3 tai vaikkapa FreePascal.

JOS ohjelman pitää kommunikoida UDP:llä, niin se on pakko tehdä linux -ohjelmaksi.

Testiversion toki voi koodata Delphillä Windowsille, mutta se lopullinen versio kannattaa kääntää Linux -ohjelmaksi.

En ole mikään Linux -fanaatikko, mutta kun Microsoftia ei kiinnostanut tehdä UDP -toteutuksestaan laadukasta.

Windowsin TCP/IP -pino on kirjoitettu pääasiassa TCP:n tarpeita ajatellen, ja UDP on siinä sivutuote, jonka laadukkuus ja virheettömyys ei tunnu kiinnostavan ketään.

Windowsin UDP -toteutuksessa on vakavia bugeja, ja siksi UDP:tä käyttävä ohjelmisto kannattaakin kääntää linuxille, muuten käy niin, että laadukaskin Delphi -windowsohjelma kärsii käyttöjärjestelmän bugisuudesta, eikä kokonaisuus silloin ole laadukas, vaikka sovellusohjelma olisikin.

Lue lisää

"Delphi on paras koskaan keksitty ohjelmointikieli, vaikka M-Kar muuta väittääkin."

Mitä tämä tarkoittaa?

"KUKAAN ei uskalla järjestää kilpailua, jossa annetaan ohjelmointitehtävä, ja kukin kilpailija saa itse valita kielen, jolla koodaa. Kilpailu voittaja saa hyvin palkatun ohjelmointityöpaikan, jossa saa käyttää itse valitsemaansa ohjelmointikieltä."

Onhan tuollaisia tehtäviä vähän väliä. Firmat rekrytoi laittamalla ohjelmointitehtäviä ja nämä joilla on parhaat toteutukset helposti rekrytoidaan.

Mutta ei toivoakaan, että Delphillä onnistuisi.

"niin yksi asia on varma: tuon kilpailun voittaisi Delphillä koodaaja."

Eivät ole koskaan voittaneet.

"Jos vielä säännöt laitettaisiin sellaiseksi, että yksikin puskurin ylivuotovirhe (koskee sekä luku- että kirjoitustilannetta) = suoritus hylätään ja kilpailija ei ole mukana palkinnonjaossa,"

Näissä tehtävissä minimivaatimus on, että toimii oikein.

"Ne, jotka haluavat 100% virheetöntä koodia, käyttävät Delphiä."

Ei käytä.

"Ne, joiden mielestä ohjelmistossa kuuluukin olla bugeja, käyttävät muita kieliä, aivan erityisesti C:tä ja C PluPlussaa.

Harvemmin näitäkään käytetään.

"Ne, jotka haluavat heikkoa suorituskykyä ja ajoittain jumittelevia ohjelmia, käyttävät Javaa."

Java on helposti nopein nykyään johtuen vaikka Nettystä, Kafkasta, roskienkerääjästä, erittäin pitkälle optimoidusta kääntäjästä.

"Silloin, kun oikeasti halutaan laadukasta ja virheetöntä koodia, niin lähekieli on ObjectPascal."

Sellaisia laadukkaita ja virheettömiä ObjectPascal ohjelmia ei oikein ole.

Anonyymi kirjoitti:

"Jos sillä jotain tekisi, ohjelmistokehittäjät valitsisivat sen käyttöön ja tekisivät sillä ohjelmia."

ohjelmistokehittäjät valitsevatkin Delphin omiin harrastusprojekteihinsa, mutta kaupallisella puolella ongelma on typerät ICT -johtajat, jotka eivät halua, että tehdään Delphillä, vaikka se teknisesti onkin paras valinta.

esim:

Tämä palvelu on tehty Javalla ja sen on Suomen Numerot Numpac OY:lle toimittanut Accenture oyj:

https://www.siirretytnumerot.fi/

Miksiköhän palvelun käyttöehdoissa lukee:
"Palvelun käyttö- ja/ tai liittäminen osaksi Internet- tai muuta sovellusta tai palvelua on ilman erikseen tehtävää kirjallista sopimusta kielletty. Käyttäjä sitoutuu käyttämään palvelua ainoastaan yksittäisten numerojen operaattorin selvittämiseen."

SIKSI, että JAVAn, jolla tuo palvelu on koodattu, suorituskyky on niin huono, että jos palvelusta automatisoidusti tehtäisiin massakyselyjä, niin tuo palvelu olisi hetkessä jumissa.

JOS minut olisi päästetty koodaamaan tuo vastaava palvelu Kylix3:lla (joka on Delphin sisartuote, joka kääntää lähdekoodia Linux -binääriksi), niin tuollaista rajoitusehtoa ei tarvittaisi yhtään mihinkään. Kas kun Kylixillä käännetyn ohjelman suorituskyky on niin erinomainen, että ainoastaan tahallinen massahäiriköinti voisi aiheuttaa ongelmia - ja tuollainen tahallinen massahäiriköinti on lainvastaista ilman mitään erityisiä käyttöehtojakin.

ks: Rikoslaki 38 luku ja 5§: "Tietoliikenteen häirintä
Joka puuttumalla postiliikenteessä taikka tele- tai radioviestinnässä käytettävän laitteen toimintaan, lähettämällä ilkivaltaisessa tarkoituksessa radiolaitteella tai televerkossa häiritseviä viestejä tai muulla vastaavalla tavalla oikeudettomasti estää tai häiritsee postiliikennettä taikka tele- tai radioviestintää, on tuomittava tietoliikenteen häirinnästä sakkoon tai vankeuteen enintään kahdeksi vuodeksi.

Yritys on rangaistava. (11.5.2007/540)"

Kylixillä tehty toteutus olisi niin laadukas, että tahallista tietoliikenteen häirintää lukuunottamatta se käytännössä kestää kaiken sen kuormituksen, mikä palveluun voi ilman tahallista häirintätarkoitusta milloinkaan kohdistua.

Tästä syystä Kylixillä tehty toteutus ei tarvitse suojakseen mitään muuta tuon em. rikoslain pykälän lisäksi.

Eli siis: JOS tuo palvelu olisi osaavan koodari toimesta tehty Kylixillä, niin edes se, että jokainen henkilö, joka Suomessa soittaa puhelun, ennen jokaista puhelua tarkistaisi kohdenumeron operaattorin tuosta palvelusta, niin tämä ei aiheuta mitään ongelmaa Kylixillä koodatulle palvelimelle.

em. pitää paikkansa myös ns. vuoden kiireisimmän teleliikennetunnin aikana.
Eli silloin, kun kuormitus Erlangeina mitattuna on vuoden korkein, niin silloinkaan ei ongelmaa.

Tuo surkea Java -viritys sen sijaan oli vähän väliä nurin vuosien 2003 - 2018 välillä.
Ja häriön haitat kärsivät asiakkaat, mutta hyödyt heikkolaatuisesta palvelusta tulivat operaattoreille.

Esimerkki operaattoreille tulleesta ansiottomasta taloudellisesta hyödystä:

Asiakas soittaa esim. dna Aarre liittymällä numeroon, jonka olettaa olevan dna:n liittymä.
Soittajan tietämättä vastaanottaja on hetki sitten vaihtanut numeronsa Saunalahdelle.
Siirrettyjen numeroiden tiedotuspalvelu on ollut nurin, eli heikkolaatuisuutensa takia se ei ole ollut toimintakelpoinen.

JOS kohdenumero olisi dna, puhelu olisi ilmainen (edellyttäen, ettei soittaja soita yli 1500 min/kk puheluita dna:n liittymiin).

Soitto kilpailijan liittymään maksaa dna Aarre -liittymällä 0,09€/min.

Eli jos puhelu kestää vaikkapa 2 tuntia, dna saa tästä ansiotonta hyötyä 10,80 €.

Delphi on hieno ohjelmistotyöväline, ja jos halutaan virheetöntä koodia, se on erinomainen valinta.

Ei muuten ole sattumaa, että moni haittaohjelma on koodattu Delphillä.
haittaohjelmilla on ehkä huono maine, mutta yhtä lailla sen haittaohjelman tekijä haluaa ohjelmansa toimivan virheettömästi, koska sillä lailla haittaohjelman tekijä saa maksimaalisen taloudellisen hyödyn haittaohjelmastaan.

Myös haittaohjelmiin liittyviä "Command & Control" centereitä on koodattu Delphillä - samasta syystä.

Se on hyvä kysymys - miksi rikolliset rakastavat Delphiä koodausvälineenä, mutta viralliset yritysrekisteriin rekisteröidyt (varsinkaan isot) yritykset eivät?

Lue lisää

"ohjelmistokehittäjät valitsevatkin Delphin omiin harrastusprojekteihinsa, mutta kaupallisella puolella ongelma on typerät ICT -johtajat, jotka eivät halua, että tehdään Delphillä, vaikka se teknisesti onkin paras valinta."

Ei ICT johtajat näitä oikein päätä vaan juurikin ohjelmistokehittäjät. Valinta tehdään usein tiimin kesken, joku konsultti tulee polkaisemaan projektin käyntiin ja valitsee tai sitten projektin aloittaa vaikka vain yksittäinen ohjelmistokehittäjä joka päättää.

Delphiä ei valita missään harrastusprojekteihin yhtään sen enempää kuin kaupalliselle puolelle.

"Miksiköhän palvelun käyttöehdoissa lukee"

Siksi että siitä ei tule kuluja.

"SIKSI, että JAVAn, jolla tuo palvelu on koodattu, suorituskyky on niin huono, että jos palvelusta automatisoidusti tehtäisiin massakyselyjä, niin tuo palvelu olisi hetkessä jumissa."

Ei olisi. Helposti saa skaalattua mutta siitä vaan tulee kuluja.

"JOS minut olisi päästetty koodaamaan tuo vastaava palvelu Kylix3:lla (joka on Delphin sisartuote, joka kääntää lähdekoodia Linux -binääriksi), niin tuollaista rajoitusehtoa ei tarvittaisi yhtään mihinkään."

Java on nopeampi.

Anonyymi kirjoitti:

"Windows IIS on maailman paras www-palvelin.
Ei sitä oikein mihinkään haluta."

Ahaa... M-Kar tunnistettu.

M-Kar vihaa Delphiä (ja ainakin osittain Windowsia ja Microsoftin Server -tuotteita).

Mutta jos joku yritys haluaa käyttää Microsoftin IIS:ää esim. Apachen ja linuxin sijasta, se on jokaisen yrityksen oma valinta.

Lue lisää

"Mutta jos joku yritys haluaa käyttää Microsoftin IIS:ää esim. Apachen ja linuxin sijasta, se on jokaisen yrityksen oma valinta."

Vähän kuullostaa siltä, että et tiedä ohjelmoinnista mitään.

Niin Apache kuin IIS ovat sellaisia joita ei oikein nykyään valita mihinkään.

KUOLEMA zelenskyille

Papparaiset ei osaa edes koodata!

Anonyymi kirjoitti:

Delphi on paras koskaan keksitty ohjelmointikieli, vaikka M-Kar muuta väittääkin.

KUKAAN ei uskalla järjestää kilpailua, jossa annetaan ohjelmointitehtävä, ja kukin kilpailija saa itse valita kielen, jolla koodaa. Kilpailu voittaja saa hyvin palkatun ohjelmointityöpaikan, jossa saa käyttää itse valitsemaansa ohjelmointikieltä.

Jos vielä säännöt laitettaisiin sellaiseksi, että yksikin puskurin ylivuotovirhe (koskee sekä luku- että kirjoitustilannetta) = suoritus hylätään ja kilpailija ei ole mukana palkinnonjaossa,

niin yksi asia on varma: tuon kilpailun voittaisi Delphillä koodaaja.

Sitä en tiedä, miksi isoille yrityksille ei kelpaa tietoturvaltaan huippulaadukas Delphillä kirkoitettu koodi.

Ehkä isot firmat haluaakin, että koodissa on haavoittuvuuksia, niin NSA:n agenttien (sekä toki myös kiinalaisten, venäläisten sekä pohjoiskorealaisten agenttien) on helppo murtautua sisään tietojärjestelmään.


Delphin kieli muuten on ObjectPascal - Turbo pascal aina versioon 5.0 saakka käytti pascalia, joskin versiossa 5.5 myös Turbo pascaliin lisättiin objektiominaisuudet.

C -kieli on käyetympi, mutta se EI ole parempi, tässä muutamia typeriä virheitä, jotka on olleet C:ssä alusta saakka:

C:ssä voi kirjoittaa:

if (k = 5) { printf("tämä suoritetaan AINA\n")}

näyttää ehtolauseelta, mutta vaikka muodollisesti onkin, käytännössä ei ole, koska ehto on AINA tosi.

Tämän riskin välttämiseksi jotkut kokeneet C -koodaajat kirjoittavat näin:

if (5 == k) { printf("tämä suoritetaan VAIN, jos k=5\n")}

Kunnollisessa kielessä (kuten Delphi) tuollaiset kiertokeinot eivät ole tarpeen.

Ja tässä toinen C:n törkyominaisuus:

Kun C -koodissa lukee:

a = a >> 5;

Tämä kääntyy Delphiksi näin (mutta vain jos a on unsigned -tyyppiä):

a := a SHR 5;

JOS a on signed -tyyppiä, niin silloin tuo sama kääntyy delphiksi näin:

a := SignedSHR(a, 5);

sitten näin (laita UNITin alkuosaan, HETI implementation -sanan jälkeen):

function SignedSHR(a:Integer; SHRCount:Byte):Integer;
asm
mov CL, DL
sar EAX, CL
end;

Ne, jotka haluavat 100% virheetöntä koodia, käyttävät Delphiä.

Ne, joiden mielestä ohjelmistossa kuuluukin olla bugeja, käyttävät muita kieliä, aivan erityisesti C:tä ja C PluPlussaa.

Ja vielä:
Ne, jotka haluavat heikkoa suorituskykyä ja ajoittain jumittelevia ohjelmia, käyttävät Javaa.

Ja LGBT -porukka käyttää rustia.

rust muuten on suomeksi ruoste.

En tiedä, haluaisitko, että jos talossasi on jokin kiinnityspultti, se on ruosteinen.

Silloin, kun oikeasti halutaan laadukasta ja virheetöntä koodia, niin lähekieli on ObjectPascal.

Kääntäjä voi olla Delphi (uusi versio), Delphi (vanha versio) tai Kylix 3 tai vaikkapa FreePascal.

JOS ohjelman pitää kommunikoida UDP:llä, niin se on pakko tehdä linux -ohjelmaksi.

Testiversion toki voi koodata Delphillä Windowsille, mutta se lopullinen versio kannattaa kääntää Linux -ohjelmaksi.

En ole mikään Linux -fanaatikko, mutta kun Microsoftia ei kiinnostanut tehdä UDP -toteutuksestaan laadukasta.

Windowsin TCP/IP -pino on kirjoitettu pääasiassa TCP:n tarpeita ajatellen, ja UDP on siinä sivutuote, jonka laadukkuus ja virheettömyys ei tunnu kiinnostavan ketään.

Windowsin UDP -toteutuksessa on vakavia bugeja, ja siksi UDP:tä käyttävä ohjelmisto kannattaakin kääntää linuxille, muuten käy niin, että laadukaskin Delphi -windowsohjelma kärsii käyttöjärjestelmän bugisuudesta, eikä kokonaisuus silloin ole laadukas, vaikka sovellusohjelma olisikin.

Lue lisää

"En ole mikään Linux -fanaatikko, mutta kun Microsoftia ei kiinnostanut tehdä UDP -toteutuksestaan laadukasta."
Tässä olisi fpc/Lazarus ympäristöön wrapperi, joka mahdollistaa mm. UDP:n käytön kelvollisella nettipinolla: Linux-puolella toteutus on siis c-kielisen koodin wrapperi joka koneesta muutenkin löytyy:
https://wiki.freepascal.org/Synapse
Tuossa on siis toteutettu mm. http ja ftp-protokollille unitit. Näitä tutkimalla pääsee jyvälle kuinka esim. UDP Socket:eja voi käyttää wrapperin läpi suoraan:
ownSock: TSocket = INVALID_SOCKET;
buf: array [0.. 10] of byte;
addr,dest: TVarSin;
err: integer;
err := SetVarSin(addr, cLocalHost,cPort,AF_INET,IPPROTO_UDP,SOCK_DGRAM,true);
ResolveIPtoName(cLocalHost,IPPROTO_UDP,SOCK_STREAM,AF_INET);
ResolvePort(cPort,IPPROTO_UDP,SOCK_DGRAM,AF_INET);
ownSock := Socket(integer(addr.AddressFamily),SOCK_DGRAM,IPPROTO_UDP);
err := send(ownSock, @buf[0], buf_size, 0);
err := recv(ownSock, @buf[0], buf_size, 0);
DestroySocketInterface;

Anonyymi kirjoitti:

Delphi on paras koskaan keksitty ohjelmointikieli, vaikka M-Kar muuta väittääkin.

KUKAAN ei uskalla järjestää kilpailua, jossa annetaan ohjelmointitehtävä, ja kukin kilpailija saa itse valita kielen, jolla koodaa. Kilpailu voittaja saa hyvin palkatun ohjelmointityöpaikan, jossa saa käyttää itse valitsemaansa ohjelmointikieltä.

Jos vielä säännöt laitettaisiin sellaiseksi, että yksikin puskurin ylivuotovirhe (koskee sekä luku- että kirjoitustilannetta) = suoritus hylätään ja kilpailija ei ole mukana palkinnonjaossa,

niin yksi asia on varma: tuon kilpailun voittaisi Delphillä koodaaja.

Sitä en tiedä, miksi isoille yrityksille ei kelpaa tietoturvaltaan huippulaadukas Delphillä kirkoitettu koodi.

Ehkä isot firmat haluaakin, että koodissa on haavoittuvuuksia, niin NSA:n agenttien (sekä toki myös kiinalaisten, venäläisten sekä pohjoiskorealaisten agenttien) on helppo murtautua sisään tietojärjestelmään.


Delphin kieli muuten on ObjectPascal - Turbo pascal aina versioon 5.0 saakka käytti pascalia, joskin versiossa 5.5 myös Turbo pascaliin lisättiin objektiominaisuudet.

C -kieli on käyetympi, mutta se EI ole parempi, tässä muutamia typeriä virheitä, jotka on olleet C:ssä alusta saakka:

C:ssä voi kirjoittaa:

if (k = 5) { printf("tämä suoritetaan AINA\n")}

näyttää ehtolauseelta, mutta vaikka muodollisesti onkin, käytännössä ei ole, koska ehto on AINA tosi.

Tämän riskin välttämiseksi jotkut kokeneet C -koodaajat kirjoittavat näin:

if (5 == k) { printf("tämä suoritetaan VAIN, jos k=5\n")}

Kunnollisessa kielessä (kuten Delphi) tuollaiset kiertokeinot eivät ole tarpeen.

Ja tässä toinen C:n törkyominaisuus:

Kun C -koodissa lukee:

a = a >> 5;

Tämä kääntyy Delphiksi näin (mutta vain jos a on unsigned -tyyppiä):

a := a SHR 5;

JOS a on signed -tyyppiä, niin silloin tuo sama kääntyy delphiksi näin:

a := SignedSHR(a, 5);

sitten näin (laita UNITin alkuosaan, HETI implementation -sanan jälkeen):

function SignedSHR(a:Integer; SHRCount:Byte):Integer;
asm
mov CL, DL
sar EAX, CL
end;

Ne, jotka haluavat 100% virheetöntä koodia, käyttävät Delphiä.

Ne, joiden mielestä ohjelmistossa kuuluukin olla bugeja, käyttävät muita kieliä, aivan erityisesti C:tä ja C PluPlussaa.

Ja vielä:
Ne, jotka haluavat heikkoa suorituskykyä ja ajoittain jumittelevia ohjelmia, käyttävät Javaa.

Ja LGBT -porukka käyttää rustia.

rust muuten on suomeksi ruoste.

En tiedä, haluaisitko, että jos talossasi on jokin kiinnityspultti, se on ruosteinen.

Silloin, kun oikeasti halutaan laadukasta ja virheetöntä koodia, niin lähekieli on ObjectPascal.

Kääntäjä voi olla Delphi (uusi versio), Delphi (vanha versio) tai Kylix 3 tai vaikkapa FreePascal.

JOS ohjelman pitää kommunikoida UDP:llä, niin se on pakko tehdä linux -ohjelmaksi.

Testiversion toki voi koodata Delphillä Windowsille, mutta se lopullinen versio kannattaa kääntää Linux -ohjelmaksi.

En ole mikään Linux -fanaatikko, mutta kun Microsoftia ei kiinnostanut tehdä UDP -toteutuksestaan laadukasta.

Windowsin TCP/IP -pino on kirjoitettu pääasiassa TCP:n tarpeita ajatellen, ja UDP on siinä sivutuote, jonka laadukkuus ja virheettömyys ei tunnu kiinnostavan ketään.

Windowsin UDP -toteutuksessa on vakavia bugeja, ja siksi UDP:tä käyttävä ohjelmisto kannattaakin kääntää linuxille, muuten käy niin, että laadukaskin Delphi -windowsohjelma kärsii käyttöjärjestelmän bugisuudesta, eikä kokonaisuus silloin ole laadukas, vaikka sovellusohjelma olisikin.

Lue lisää

"En ole mikään Linux -fanaatikko, mutta kun Microsoftia ei kiinnostanut tehdä UDP -toteutuksestaan laadukasta."

Mikä Microsoftin UDP:ssä on vikana?

Anonyymi kirjoitti:

"Mutta jos joku yritys haluaa käyttää Microsoftin IIS:ää esim. Apachen ja linuxin sijasta, se on jokaisen yrityksen oma valinta."

Vähän kuullostaa siltä, että et tiedä ohjelmoinnista mitään.

Niin Apache kuin IIS ovat sellaisia joita ei oikein nykyään valita mihinkään.

Lue lisää

Apache on avoimen lähdekoodin verkkopalvelin, jonka kehittäjäryhmä on kehittänyt ja ylläpitänyt Apache Software Foundationin alaisuudessa. Se on tulosta yhteisistä ponnisteluista, joiden tavoitteena oli luoda vankka ja turvallinen kaupallisen tason web-palvelin, joka noudattaa kaikkia HTTP-standardeja. Se on ollut markkinajohtaja siitä lähtien, kun se tuli web-palvelinmarkkinoille vuonna 1995, ja se on edelleen suosituin web-palvelin, koska se pystyy toimimaan useilla alustoilla.

Saatat tietää, että Apache on yhtä tehokas lähes kaikissa käyttöjärjestelmissä, mutta löydösten voidaan havaita olevan maksimaalisessa käytössä, kun se yhdistetään Linuxin kanssa.

Anonyymi kirjoitti:

Apache on avoimen lähdekoodin verkkopalvelin, jonka kehittäjäryhmä on kehittänyt ja ylläpitänyt Apache Software Foundationin alaisuudessa. Se on tulosta yhteisistä ponnisteluista, joiden tavoitteena oli luoda vankka ja turvallinen kaupallisen tason web-palvelin, joka noudattaa kaikkia HTTP-standardeja. Se on ollut markkinajohtaja siitä lähtien, kun se tuli web-palvelinmarkkinoille vuonna 1995, ja se on edelleen suosituin web-palvelin, koska se pystyy toimimaan useilla alustoilla.

Saatat tietää, että Apache on yhtä tehokas lähes kaikissa käyttöjärjestelmissä, mutta löydösten voidaan havaita olevan maksimaalisessa käytössä, kun se yhdistetään Linuxin kanssa.

Lue lisää

Niin, tuo oli suora lainaus jostakin asiaa tuntevasta lähteestä.

Anonyymi kirjoitti:

Apache on avoimen lähdekoodin verkkopalvelin, jonka kehittäjäryhmä on kehittänyt ja ylläpitänyt Apache Software Foundationin alaisuudessa. Se on tulosta yhteisistä ponnisteluista, joiden tavoitteena oli luoda vankka ja turvallinen kaupallisen tason web-palvelin, joka noudattaa kaikkia HTTP-standardeja. Se on ollut markkinajohtaja siitä lähtien, kun se tuli web-palvelinmarkkinoille vuonna 1995, ja se on edelleen suosituin web-palvelin, koska se pystyy toimimaan useilla alustoilla.

Saatat tietää, että Apache on yhtä tehokas lähes kaikissa käyttöjärjestelmissä, mutta löydösten voidaan havaita olevan maksimaalisessa käytössä, kun se yhdistetään Linuxin kanssa.

Lue lisää

Apache kuitenkin on pitkään väistynyt käytöstä. Staattinen sisältö menee CDN:n ja HTTP serverit on ohjelmointikielten ajoympäristöissä.

Sellainen yleiskäyttöinen HTTP serveri mikä keskittyy hostaamaan sisältöä on pitkään vaihtunut Apache HTTP:stä Nginx. Nginx on ollut pitkään Apache HTTP:tä yleisempi: https://www.hostinger.com/tutorials/nginx-vs-apache-what-to-use/

Hyvin huomaa että täällä ei porukka tiedä ohjelmien tekemisestä yhtään mitään kun höpisee jostain IIS:stä, Apachesta, Delphistä tai C++:sta.

Anonyymi kirjoitti:

"Delphi on paras koskaan keksitty ohjelmointikieli, vaikka M-Kar muuta väittääkin."

Mitä tämä tarkoittaa?

"KUKAAN ei uskalla järjestää kilpailua, jossa annetaan ohjelmointitehtävä, ja kukin kilpailija saa itse valita kielen, jolla koodaa. Kilpailu voittaja saa hyvin palkatun ohjelmointityöpaikan, jossa saa käyttää itse valitsemaansa ohjelmointikieltä."

Onhan tuollaisia tehtäviä vähän väliä. Firmat rekrytoi laittamalla ohjelmointitehtäviä ja nämä joilla on parhaat toteutukset helposti rekrytoidaan.

Mutta ei toivoakaan, että Delphillä onnistuisi.

"niin yksi asia on varma: tuon kilpailun voittaisi Delphillä koodaaja."

Eivät ole koskaan voittaneet.

"Jos vielä säännöt laitettaisiin sellaiseksi, että yksikin puskurin ylivuotovirhe (koskee sekä luku- että kirjoitustilannetta) = suoritus hylätään ja kilpailija ei ole mukana palkinnonjaossa,"

Näissä tehtävissä minimivaatimus on, että toimii oikein.

"Ne, jotka haluavat 100% virheetöntä koodia, käyttävät Delphiä."

Ei käytä.

"Ne, joiden mielestä ohjelmistossa kuuluukin olla bugeja, käyttävät muita kieliä, aivan erityisesti C:tä ja C PluPlussaa.

Harvemmin näitäkään käytetään.

"Ne, jotka haluavat heikkoa suorituskykyä ja ajoittain jumittelevia ohjelmia, käyttävät Javaa."

Java on helposti nopein nykyään johtuen vaikka Nettystä, Kafkasta, roskienkerääjästä, erittäin pitkälle optimoidusta kääntäjästä.

"Silloin, kun oikeasti halutaan laadukasta ja virheetöntä koodia, niin lähekieli on ObjectPascal."

Sellaisia laadukkaita ja virheettömiä ObjectPascal ohjelmia ei oikein ole.

Lue lisää

M-Kar:lla on ollut aina kova pätemisen tarve, mitä vähemmän se asiasta tietää sitä enemmän se inttää ja olettaa asioita päin honkia.

Käyttää verkosta kopioimiaan termejä, joihin ei viitsi edes perehtyä jonka vuoksi syntyy huvittavia pätemis yrityksiä.

Samaa sekoilua myös englanninkielisistä lähteistä mutu tuntumalla ymmärrettyjen asioiden kanssa. Poimii asiansa tueksi englanninkielisen artikkelin joka on sisällöltään hänen väittämäänsä kumoava, eikä ressukka ymmärrä, vaan viittaa uudestaan ja uudestaan samaan lähteeseen hänen väittämäänsä tukevana.

Tässäkin perustelee asioita asiantuntevasti, muutama esimerkki sennevammasen vastauksista:

- Ei käytä.
- Harvemmin näitäkään käytetään.
- Eivät ole koskaan voittaneet.
- Mitä tämä tarkoittaa?

Anonyymi kirjoitti:

Kyllä tekee, vain kädettömät ei tee Delphillä mitään.

"Kyllä tekee, vain kädettömät ei tee Delphillä mitään."

Kerro mitä sillä tekee.

Anonyymi kirjoitti:

Delphi on paras koskaan keksitty ohjelmointikieli, vaikka M-Kar muuta väittääkin.

KUKAAN ei uskalla järjestää kilpailua, jossa annetaan ohjelmointitehtävä, ja kukin kilpailija saa itse valita kielen, jolla koodaa. Kilpailu voittaja saa hyvin palkatun ohjelmointityöpaikan, jossa saa käyttää itse valitsemaansa ohjelmointikieltä.

Jos vielä säännöt laitettaisiin sellaiseksi, että yksikin puskurin ylivuotovirhe (koskee sekä luku- että kirjoitustilannetta) = suoritus hylätään ja kilpailija ei ole mukana palkinnonjaossa,

niin yksi asia on varma: tuon kilpailun voittaisi Delphillä koodaaja.

Sitä en tiedä, miksi isoille yrityksille ei kelpaa tietoturvaltaan huippulaadukas Delphillä kirkoitettu koodi.

Ehkä isot firmat haluaakin, että koodissa on haavoittuvuuksia, niin NSA:n agenttien (sekä toki myös kiinalaisten, venäläisten sekä pohjoiskorealaisten agenttien) on helppo murtautua sisään tietojärjestelmään.


Delphin kieli muuten on ObjectPascal - Turbo pascal aina versioon 5.0 saakka käytti pascalia, joskin versiossa 5.5 myös Turbo pascaliin lisättiin objektiominaisuudet.

C -kieli on käyetympi, mutta se EI ole parempi, tässä muutamia typeriä virheitä, jotka on olleet C:ssä alusta saakka:

C:ssä voi kirjoittaa:

if (k = 5) { printf("tämä suoritetaan AINA\n")}

näyttää ehtolauseelta, mutta vaikka muodollisesti onkin, käytännössä ei ole, koska ehto on AINA tosi.

Tämän riskin välttämiseksi jotkut kokeneet C -koodaajat kirjoittavat näin:

if (5 == k) { printf("tämä suoritetaan VAIN, jos k=5\n")}

Kunnollisessa kielessä (kuten Delphi) tuollaiset kiertokeinot eivät ole tarpeen.

Ja tässä toinen C:n törkyominaisuus:

Kun C -koodissa lukee:

a = a >> 5;

Tämä kääntyy Delphiksi näin (mutta vain jos a on unsigned -tyyppiä):

a := a SHR 5;

JOS a on signed -tyyppiä, niin silloin tuo sama kääntyy delphiksi näin:

a := SignedSHR(a, 5);

sitten näin (laita UNITin alkuosaan, HETI implementation -sanan jälkeen):

function SignedSHR(a:Integer; SHRCount:Byte):Integer;
asm
mov CL, DL
sar EAX, CL
end;

Ne, jotka haluavat 100% virheetöntä koodia, käyttävät Delphiä.

Ne, joiden mielestä ohjelmistossa kuuluukin olla bugeja, käyttävät muita kieliä, aivan erityisesti C:tä ja C PluPlussaa.

Ja vielä:
Ne, jotka haluavat heikkoa suorituskykyä ja ajoittain jumittelevia ohjelmia, käyttävät Javaa.

Ja LGBT -porukka käyttää rustia.

rust muuten on suomeksi ruoste.

En tiedä, haluaisitko, että jos talossasi on jokin kiinnityspultti, se on ruosteinen.

Silloin, kun oikeasti halutaan laadukasta ja virheetöntä koodia, niin lähekieli on ObjectPascal.

Kääntäjä voi olla Delphi (uusi versio), Delphi (vanha versio) tai Kylix 3 tai vaikkapa FreePascal.

JOS ohjelman pitää kommunikoida UDP:llä, niin se on pakko tehdä linux -ohjelmaksi.

Testiversion toki voi koodata Delphillä Windowsille, mutta se lopullinen versio kannattaa kääntää Linux -ohjelmaksi.

En ole mikään Linux -fanaatikko, mutta kun Microsoftia ei kiinnostanut tehdä UDP -toteutuksestaan laadukasta.

Windowsin TCP/IP -pino on kirjoitettu pääasiassa TCP:n tarpeita ajatellen, ja UDP on siinä sivutuote, jonka laadukkuus ja virheettömyys ei tunnu kiinnostavan ketään.

Windowsin UDP -toteutuksessa on vakavia bugeja, ja siksi UDP:tä käyttävä ohjelmisto kannattaakin kääntää linuxille, muuten käy niin, että laadukaskin Delphi -windowsohjelma kärsii käyttöjärjestelmän bugisuudesta, eikä kokonaisuus silloin ole laadukas, vaikka sovellusohjelma olisikin.

Lue lisää

"Delphi on paras koskaan keksitty ohjelmointikieli, vaikka M-Kar muuta väittääkin."

Jos Delphi olisi hyvä, sitä myös käytettäisiin.

Anonyymi kirjoitti:

"Kyllä tekee, vain kädettömät ei tee Delphillä mitään."

Kerro mitä sillä tekee.

Sillä Delphillä ohjelmoidaan, tietenkin!

Anonyymi kirjoitti:

"Delphi on paras koskaan keksitty ohjelmointikieli, vaikka M-Kar muuta väittääkin."

Jos Delphi olisi hyvä, sitä myös käytettäisiin.

Jaaha, Karvahatun piti tulla anonyymina taas pätemään ja jauhamaan asiasta josta ei mitään ymmärrä!

Anonyymi kirjoitti:

Delphi on kuin Windows Server. Sitäkin myydään kauhealla hinnalla verkkokaupassa kun sillä ei tee mitään ja se menee niille ketkä ovat jumissa sen kanssa jostain syystä.

Tarvisin jakkaran jossa on reikä keskellä! halun koodata kauha ahterissa!

Anonyymi kirjoitti:

"Windows IIS on maailman paras www-palvelin.
Ei sitä oikein mihinkään haluta."

Ahaa... M-Kar tunnistettu.

M-Kar vihaa Delphiä (ja ainakin osittain Windowsia ja Microsoftin Server -tuotteita).

Mutta jos joku yritys haluaa käyttää Microsoftin IIS:ää esim. Apachen ja linuxin sijasta, se on jokaisen yrityksen oma valinta.

Lue lisää

Nyt on jännäkakka jakkarassa!

Mikkisoftan UDP-toteutus saattaa toimia, mutta sehän on luettavissa Synapse-paketin unittien koodeista mitä sen toimintaan saattaminen edellyttää: Ei ole ihan standardin mukainen rakenne ja aiheuttaa ongelmia toimimalla hiukan eri tavalla.

Anonyymi kirjoitti:

Oikealle käyttikselle (Linuxeille) saa Lazarus Free Pascal yhdistelmän joka on käytännössä sama kuin Delphi.

"Lazarus+Free Pascal yhdistelmän joka on käytännössä sama kuin Delphi"

EI OLE.

Koodia toki kirjoittaa FreePascalilla siinä kuin Delphilläkin, KUNHAN muistaa kirjoittaa jokaisen käännösyksikön alkuun nämä:

{$asmmode Intel}
{$mode Delphi}

MUTTA:

Lazarus käyttää debuggerinsa perustana luokattoman huonoa GDB:tä.

GDB EI ole debuggeri - se on varoitusesimerkki siitä, miten EI tehdä hyvää debuggeria.

Jos Linux Kernel -kehittäjät viitsisivät toteuttaa Linux Kerneliin saman debuggaukseen liittyvän toiminnallisuuden kuin Windowsissa on ollut jo ainakin Windows 95:stä ja Windows NT 4.0:sta alkaen, niin silloin olisi mahdollista tehdä laadukas debuggeri Linux -käyttöjärjestelmälle.

Tarkoitan siis näitä (ja muita samaan kokonaisuuteen kuuluvia) Windows API -funktioita:

SuspendThread
ResumeThread
GetThreadContext
SetThreadContext
IsDebuggerPresent
ReadProcessMemory
WriteProcessMemory
CreateRemoteThread

Toki: Kaikkia API -funktioita voidaan käyttää niin hyviin kuin pahoihinkin tarkoituksiin.

Jos tietoturvasta ollaan huolissaan, asian voisi toteuttaa näin (tämä vähentää väärinkäytön vaaraa):

Tehdään niin, että oletuksena yksikään yllämainituista funktioista ei toimi, vaan palauttaa virhekoodin, joka tarkoittaa: "Ei käyttöoikeutta Debug -toiminnallisuuteen".

Sitten lisätään vielä 1 funktio:

EnableDebugFunctionality()

Tuo funktio toimii, kun sitä kutsutaan root -oikeuksin, muussa tapauksessa sekin palauttaa tuon saman "Ei käyttöoikeutta Debug -toiminnallisuuteen" -virhekoodin.

Tällöin debuggeri (tai debuggerin apuohjelma) itse voidaan merkitä ns. setuid root -ohjelmaksi.
Kun debuggeri (tai debuggerin apuohjelma) käynnistetään, se kutsuu (vielä root -oikeuksin) tuota EnableDebugFunctionality() -funktiota, ja heti sen jälkeen pudottaa pois omat root -oikeutensa.
Näin ohjelma käyttää root -oikeuksiaan kerran ohjelmansuorituksen alussa, ja luopuu sitten root -oikeuksistaan.
Näin minimoidaan tarve root -oikeuksien käytölle (=hyvän tietoturvapolitiikan mukaista).

Tätä sopii kysyä: miksi Linux Kernel -kehittäjät eivät ole jo toteuttaneet tuota ?

Anonyymi kirjoitti:

"Delphi on paras koskaan keksitty ohjelmointikieli, vaikka M-Kar muuta väittääkin."

Mitä tämä tarkoittaa?

"KUKAAN ei uskalla järjestää kilpailua, jossa annetaan ohjelmointitehtävä, ja kukin kilpailija saa itse valita kielen, jolla koodaa. Kilpailu voittaja saa hyvin palkatun ohjelmointityöpaikan, jossa saa käyttää itse valitsemaansa ohjelmointikieltä."

Onhan tuollaisia tehtäviä vähän väliä. Firmat rekrytoi laittamalla ohjelmointitehtäviä ja nämä joilla on parhaat toteutukset helposti rekrytoidaan.

Mutta ei toivoakaan, että Delphillä onnistuisi.

"niin yksi asia on varma: tuon kilpailun voittaisi Delphillä koodaaja."

Eivät ole koskaan voittaneet.

"Jos vielä säännöt laitettaisiin sellaiseksi, että yksikin puskurin ylivuotovirhe (koskee sekä luku- että kirjoitustilannetta) = suoritus hylätään ja kilpailija ei ole mukana palkinnonjaossa,"

Näissä tehtävissä minimivaatimus on, että toimii oikein.

"Ne, jotka haluavat 100% virheetöntä koodia, käyttävät Delphiä."

Ei käytä.

"Ne, joiden mielestä ohjelmistossa kuuluukin olla bugeja, käyttävät muita kieliä, aivan erityisesti C:tä ja C PluPlussaa.

Harvemmin näitäkään käytetään.

"Ne, jotka haluavat heikkoa suorituskykyä ja ajoittain jumittelevia ohjelmia, käyttävät Javaa."

Java on helposti nopein nykyään johtuen vaikka Nettystä, Kafkasta, roskienkerääjästä, erittäin pitkälle optimoidusta kääntäjästä.

"Silloin, kun oikeasti halutaan laadukasta ja virheetöntä koodia, niin lähekieli on ObjectPascal."

Sellaisia laadukkaita ja virheettömiä ObjectPascal ohjelmia ei oikein ole.

Lue lisää

" Firmat rekrytoi laittamalla ohjelmointitehtäviä ja nämä joilla on parhaat toteutukset helposti rekrytoidaan."

Täyttä valhetta!

Kerran oli helsingin sanomissa työpaikkailmoitus, jossa luki "Solve and be rewarded".

Siinä oli hexadesimaalista PDU -koodia.

Ratkaisin PDU -koodin tekemälläni Delphi -ohjelmalla.
Kun yritykselle selvisi, että ratkaisu oli tehty Delphillä - niin en saanut luvattua palkkiota.
Yritys (Malibu Software) siis valehteli päin naamaa työpaikkailmoituksessaan.
Tapahtuneesta on jo vuosia aikaa.

Kertaakaan ei ole ollut sellaista ohjelmointikilpailua, jossa annetaan tehtävä, ja sen laadukkaasti ratkaisija saa hyväpalkkaisen työpaikan - ja ohjelmointikielen saa hakija valita itse.

Jos tuollaisia kilpailuja olisi, oma ennustukseni on, että sen voittaja jopa yli 90% tapauksista olisi se, joka koodaa Delphillä.

Valehtelevia IT -johtajia kyllä riittää.

Anonyymi kirjoitti:

"ohjelmistokehittäjät valitsevatkin Delphin omiin harrastusprojekteihinsa, mutta kaupallisella puolella ongelma on typerät ICT -johtajat, jotka eivät halua, että tehdään Delphillä, vaikka se teknisesti onkin paras valinta."

Ei ICT johtajat näitä oikein päätä vaan juurikin ohjelmistokehittäjät. Valinta tehdään usein tiimin kesken, joku konsultti tulee polkaisemaan projektin käyntiin ja valitsee tai sitten projektin aloittaa vaikka vain yksittäinen ohjelmistokehittäjä joka päättää.

Delphiä ei valita missään harrastusprojekteihin yhtään sen enempää kuin kaupalliselle puolelle.

"Miksiköhän palvelun käyttöehdoissa lukee"

Siksi että siitä ei tule kuluja.

"SIKSI, että JAVAn, jolla tuo palvelu on koodattu, suorituskyky on niin huono, että jos palvelusta automatisoidusti tehtäisiin massakyselyjä, niin tuo palvelu olisi hetkessä jumissa."

Ei olisi. Helposti saa skaalattua mutta siitä vaan tulee kuluja.

"JOS minut olisi päästetty koodaamaan tuo vastaava palvelu Kylix3:lla (joka on Delphin sisartuote, joka kääntää lähdekoodia Linux -binääriksi), niin tuollaista rajoitusehtoa ei tarvittaisi yhtään mihinkään."

Java on nopeampi.

Lue lisää

"Java on nopeampi."

Mutta tuo on VALHE. Eikä se muutu todeksi, toistatpa sitä miten monta kertaa hyvänsä.

Tosiasiassa: Jos minä olisin saanut koodata tuon siirretytnumerot.fi Kylix3:lla, niin palvelu vastaisi myös vuoden kiireisimmän tunnin isoon kyselymäärään ilman mitään ongelmia.

Mitään "skaalauksia" ei tarvita - ja kun niitä ei tarvita - ei tule myöskään mitään lisäkustannuksia.

AINOA mahdollinen lisäkulu on se, että palvelimena toimivan tietokoneen sähkönkulutus saattaa vuoden kiireisimmän tunnin aikana olla hieman isompi kuin se on muulloin - koska silloin CPU -kuorma saattaa olla koko tunnin lähes 100%, kun se muulloin on pääosan ajasta 0-1 %.

Sähkön hinnat ovat toki kohonneet siitä, mitä olivat vielä 2021, mutta en usko, että palvelimen lisääntynyt sähkönkulutus kiireisimmän tunnin aikana on kenellekään vakava ongelma.

Jos laitetaan rinnakkain Java -ohjelma ja Kylix3 -ohjelma, niin nopeudessa Kylix3 -ohjelma voittaa joka kerta.

Java:ssa on lisäksi muita ongelmia - kuten se, että kun muistinsiivousajo käynnistyy, niin sillä aikaa java -ohjelma ei tee mitään.

Ehkä tarkoitat "skaalauksella" kuormantasausta - eli sitä, että samaa palvelinkoodia ajetaan useammassa koneessa.

Tuollaisessa tiedotuspalvelussa tästä hyötyisi se, joka lähettää kysely sisään sitten, kun kone A on juuri aloittanut sen java -muistinsiivousajon - ja sekin vain sillä edellytyksellä, että kuormantasausta hoitava reititin on tietoinen siitä, että kone A on juuri nyt jumissa tuon muistinsiivousajon takia ja ohjaa kyselyt koneelle B.

JOS se kuormantasausta hoitava reititin ei ole tietoinen tuosta muistinsiivousajosta, se ohjaa typeränä edelleen kyselyitä koneelle A -joka on jumissa, eikä vastaa kyselyihin.

Ja se epäonninen, jonka kysely ohjautui koneelle A juuri ennen muistinsiivousajon alkua - niin häntä se kuormantasaus ei hyödytä yhtään mitään - ei, vaikka se reititin olisikin tietoinen ongelmasta.

JOS IT -alan johtajat käyttäisivät yhtään järkeään, JAVAa ei käytettäisi yhtään missään - juurikin siksi, että tuollainen muistinsiivousajo, joka pysäyttää koneen koko toiminnan, on aivan idioottimainen idea - siksi Delphi ja Kylix eivät tuollaista käytäkään.

Anonyymi kirjoitti:

"En ole mikään Linux -fanaatikko, mutta kun Microsoftia ei kiinnostanut tehdä UDP -toteutuksestaan laadukasta."

Mikä Microsoftin UDP:ssä on vikana?

"Mikä Microsoftin UDP:ssä on vikana"

etkö todella muka tiedä - vai teeskenteletkö vain tietämätöntä ?

Jos Windows PC:ssä laitat UDP socketin odottamaan yhteydenottoja (= UDP -paketteja) netistä, niin ensimmäinen sisääntuleva paketti ja vastauspaketti siihen toimivat aivan oikein.

MUTTA kun heti sen jälkeen tulee TOINEN tuleva UPD -paketti, niin siihen, kun vastaat, niin vastauspaketti ei menekää sinne, minne pitäisi (eli IP-osoitteeseen ja porttinumeroon, mistä tuo toinen UDP -paketti tulivat) vaan menee sinne samaan paikkaan minne ensimmäinenkin!

Tuo on BUGI Windowsin UDP -toteutuksessa.

Eli ensimmäisen kyselyn lähettäjä saa ensin vastauksen kyselyynsä - ja sitten toisen paketin, jota ei halua.

Ja toisen kyselyn lähettäjä ei saa vastauspakettia lainkaan (kun se vastaus menee väärään osoitteeseen).

En ole kokeillut linuxilla samaa, mutta olettaisin, ettei windowsin bugit vaikuta linuxiin mitään, joten mitä todennäköisimmin sama ohjelma käännettynä
Delphillä Windowsille = bugi

mutta käännettynä
Kylix3:lla Linuxille = ei bugia.

Tottakai tuo yllätti, mutta ilmeisesti Microsoftin pääpaino on ollut TCP:ssä, ja UDP -toteutus Windowsissa "on mitä on" - eli joissain asioissa jopa toimii -toisissa sitten ei.

Anonyymi kirjoitti:

" Firmat rekrytoi laittamalla ohjelmointitehtäviä ja nämä joilla on parhaat toteutukset helposti rekrytoidaan."

Täyttä valhetta!

Kerran oli helsingin sanomissa työpaikkailmoitus, jossa luki "Solve and be rewarded".

Siinä oli hexadesimaalista PDU -koodia.

Ratkaisin PDU -koodin tekemälläni Delphi -ohjelmalla.
Kun yritykselle selvisi, että ratkaisu oli tehty Delphillä - niin en saanut luvattua palkkiota.
Yritys (Malibu Software) siis valehteli päin naamaa työpaikkailmoituksessaan.
Tapahtuneesta on jo vuosia aikaa.

Kertaakaan ei ole ollut sellaista ohjelmointikilpailua, jossa annetaan tehtävä, ja sen laadukkaasti ratkaisija saa hyväpalkkaisen työpaikan - ja ohjelmointikielen saa hakija valita itse.

Jos tuollaisia kilpailuja olisi, oma ennustukseni on, että sen voittaja jopa yli 90% tapauksista olisi se, joka koodaa Delphillä.

Valehtelevia IT -johtajia kyllä riittää.

Lue lisää

"Kun yritykselle selvisi, että ratkaisu oli tehty Delphillä - niin en saanut luvattua palkkiota."

Kuten sanoin niin ovat kiinnostuneet parhaista toteutuksista.

"Kertaakaan ei ole ollut sellaista ohjelmointikilpailua, jossa annetaan tehtävä, ja sen laadukkaasti ratkaisija saa hyväpalkkaisen työpaikan - ja ohjelmointikielen saa hakija valita itse."

Siis kyllä näissä ohjelmointikieltä saa valita vapaasti mutta näitä kiinnostaa siistein toteutus ja jos sinne lähettää jonkun delphiräpellyksen niin miksi ihmeessä tätä arvostaisivat jos joku toinen toteuttaa vaikka Rustilla?

Tietenkin arvostavat enemmän aikaansa seuraavaa kehittäjää joka tehnyt siistin toteutuksen paremmalla kielellä. Turha sinne on mitään Delphiä, D-kieltä, BASIC:ia, Fortrania tms. tarjota mitä kukaan ei halua mihinkään.

Anonyymi kirjoitti:

Apache kuitenkin on pitkään väistynyt käytöstä. Staattinen sisältö menee CDN:n ja HTTP serverit on ohjelmointikielten ajoympäristöissä.

Sellainen yleiskäyttöinen HTTP serveri mikä keskittyy hostaamaan sisältöä on pitkään vaihtunut Apache HTTP:stä Nginx. Nginx on ollut pitkään Apache HTTP:tä yleisempi: https://www.hostinger.com/tutorials/nginx-vs-apache-what-to-use/

Hyvin huomaa että täällä ei porukka tiedä ohjelmien tekemisestä yhtään mitään kun höpisee jostain IIS:stä, Apachesta, Delphistä tai C :sta.

Lue lisää

"""
Apache kuitenkin on pitkään väistynyt käytöstä.
"""
TODISTA SE saatanan HÖNÖ jollakin tavoin.

"""
Staattinen sisältö menee CDN:n ja HTTP serverit on ohjelmointikielten ajoympäristöissä.
"""
Mitä helvettiä tämäkin tarkoittaa, etkö voi olla tarkempi kopioidessasi tekstiä verkkosivuilta, et selvästikkään itsekkään käsitä mitä kopioit.

"""
Hyvin huomaa että täällä ei porukka tiedä ohjelmien tekemisestä yhtään mitään kun höpisee jostain IIS:stä, Apachesta, Delphistä tai C++:sta.
"""
Apache HTTP Server on avoimeen lähdekoodiin perustuva HTTP-palvelinohjelma. Apachen HTTP-palvelin on Apache Software Foundationin tunnetuin tuote ja tällä hetkellä mailman käytetyin HTTP-palvelinohjelma.

IIS no jaa, en viitsi selvittää tilannetta, en tietoisesti ole sitä käyttänyt.

Delphi on Borlandin tekemä Object Pascal -kieleen perustuva graafinen ohjelmankehitysympäristö ja ohjelmointikieli. Delphi mahdollisti julkaisuvuonnaan 1995 ensimmäisenä visuaalisen Windows-lomakkeiden editoinnin yhdistettynä olio-ohjelmointiin. Olin moneen kertaan itseeni tyytyväinen kun tulin alusta asti tuurilla valinneeksi mailman nopeiman kääntäjä ympäristön ja olen edelleenkin sitä mieltä parempaa valintaa en olisi pystynyt tekemään.

C++ on ohjelmointikieli, joka kehitettiin 1980-luvulla C-kielestä lisäämällä siihen muun muassa olio-ohjelmointiin ja geneerisyyteen liittyviä ominaisuuksia. Vielä tänäänkin olen vakuuttunut ettei aika jonka pistin C++ kielen opiskeluun mennyt hukkaan, parempaa pohjaa ohjelmoinnin perusteisiin ei ole olemassa vieläkään.

Alaikäiset rakkulat eivät osaa nykyään arvostaa työpöytä sovelluksia koska heillä on MEIDÄN tekemät työkalut verkottua osaamatta edes kirjoittaa ja lukea. Nämä saatanan sittisontiaiset aukovat päätään tyhmyyttään siinä kohtaa missä pitäisi osoittaan kunnioitusta mailman jaloinmille ohjelmointi lähteille.

Anonyymi kirjoitti:

"Kyllä tekee, vain kädettömät ei tee Delphillä mitään."

Kerro mitä sillä tekee.

"Kerro mitä sillä tekee."

HÖNÖ etkö sinä osannut lukea; kädettömät ei tee Delphillä mitään.

Sinä olet kädetön ja et tee sillä mitään enkä minä jouda sinulle sitä opettamaan, se on elämän suuria valintoja, ei ohjelmoimaan opita alle 20 vuoden. Rakkulat sanoo osaavansa ohjelmoida jo siinä vaiheessa kun ne osaabat verkosta kopioida jonkun muun tekemän Hello World esimerkin, ei se mitään osaamista ole.

Anonyymi kirjoitti:

"Lazarus Free Pascal yhdistelmän joka on käytännössä sama kuin Delphi"

EI OLE.

Koodia toki kirjoittaa FreePascalilla siinä kuin Delphilläkin, KUNHAN muistaa kirjoittaa jokaisen käännösyksikön alkuun nämä:

{$asmmode Intel}
{$mode Delphi}

MUTTA:

Lazarus käyttää debuggerinsa perustana luokattoman huonoa GDB:tä.

GDB EI ole debuggeri - se on varoitusesimerkki siitä, miten EI tehdä hyvää debuggeria.

Jos Linux Kernel -kehittäjät viitsisivät toteuttaa Linux Kerneliin saman debuggaukseen liittyvän toiminnallisuuden kuin Windowsissa on ollut jo ainakin Windows 95:stä ja Windows NT 4.0:sta alkaen, niin silloin olisi mahdollista tehdä laadukas debuggeri Linux -käyttöjärjestelmälle.

Tarkoitan siis näitä (ja muita samaan kokonaisuuteen kuuluvia) Windows API -funktioita:

SuspendThread
ResumeThread
GetThreadContext
SetThreadContext
IsDebuggerPresent
ReadProcessMemory
WriteProcessMemory
CreateRemoteThread

Toki: Kaikkia API -funktioita voidaan käyttää niin hyviin kuin pahoihinkin tarkoituksiin.

Jos tietoturvasta ollaan huolissaan, asian voisi toteuttaa näin (tämä vähentää väärinkäytön vaaraa):

Tehdään niin, että oletuksena yksikään yllämainituista funktioista ei toimi, vaan palauttaa virhekoodin, joka tarkoittaa: "Ei käyttöoikeutta Debug -toiminnallisuuteen".

Sitten lisätään vielä 1 funktio:

EnableDebugFunctionality()

Tuo funktio toimii, kun sitä kutsutaan root -oikeuksin, muussa tapauksessa sekin palauttaa tuon saman "Ei käyttöoikeutta Debug -toiminnallisuuteen" -virhekoodin.

Tällöin debuggeri (tai debuggerin apuohjelma) itse voidaan merkitä ns. setuid root -ohjelmaksi.
Kun debuggeri (tai debuggerin apuohjelma) käynnistetään, se kutsuu (vielä root -oikeuksin) tuota EnableDebugFunctionality() -funktiota, ja heti sen jälkeen pudottaa pois omat root -oikeutensa.
Näin ohjelma käyttää root -oikeuksiaan kerran ohjelmansuorituksen alussa, ja luopuu sitten root -oikeuksistaan.
Näin minimoidaan tarve root -oikeuksien käytölle (=hyvän tietoturvapolitiikan mukaista).

Tätä sopii kysyä: miksi Linux Kernel -kehittäjät eivät ole jo toteuttaneet tuota ?

Lue lisää

"Koodia toki kirjoittaa FreePascalilla siinä kuin Delphilläkin, KUNHAN muistaa kirjoittaa jokaisen käännösyksikön alkuun nämä:

{$asmmode Intel}
{$mode Delphi}

------------------------

VALEHTELET, et siis tiennyt mitä nuo kääntäjän ohjeistus merkinnät tarkoittaa, no minäpä kerron;

{$asmmode Intel}
asm -lohkot kirjoitettu Intelin syntaksia käyttäen.

{$mode Delphi}
Tällä kääntäjän ohjeella viestitetään että lähdekoodi jäljittelee Delphi 4:n syntaksia mahdollisiman tarkasti. Tähän liittyy ainakin 8 eri rajoitusta muuttujien ja operaattoreiden käytössä.

Huomaa että nämä voidaan jättää koodista pois jos ne annetaa saateparametrina komentoriviltä.

Joten on sanomattakin selvää ettei sinun tuntemuksesi riitä DELPHIN arvosteluun joten lopeta se menee vain sekasin kaikki.

Anonyymi kirjoitti:

"Java on nopeampi."

Mutta tuo on VALHE. Eikä se muutu todeksi, toistatpa sitä miten monta kertaa hyvänsä.

Tosiasiassa: Jos minä olisin saanut koodata tuon siirretytnumerot.fi Kylix3:lla, niin palvelu vastaisi myös vuoden kiireisimmän tunnin isoon kyselymäärään ilman mitään ongelmia.

Mitään "skaalauksia" ei tarvita - ja kun niitä ei tarvita - ei tule myöskään mitään lisäkustannuksia.

AINOA mahdollinen lisäkulu on se, että palvelimena toimivan tietokoneen sähkönkulutus saattaa vuoden kiireisimmän tunnin aikana olla hieman isompi kuin se on muulloin - koska silloin CPU -kuorma saattaa olla koko tunnin lähes 100%, kun se muulloin on pääosan ajasta 0-1 %.

Sähkön hinnat ovat toki kohonneet siitä, mitä olivat vielä 2021, mutta en usko, että palvelimen lisääntynyt sähkönkulutus kiireisimmän tunnin aikana on kenellekään vakava ongelma.

Jos laitetaan rinnakkain Java -ohjelma ja Kylix3 -ohjelma, niin nopeudessa Kylix3 -ohjelma voittaa joka kerta.

Java:ssa on lisäksi muita ongelmia - kuten se, että kun muistinsiivousajo käynnistyy, niin sillä aikaa java -ohjelma ei tee mitään.

Ehkä tarkoitat "skaalauksella" kuormantasausta - eli sitä, että samaa palvelinkoodia ajetaan useammassa koneessa.

Tuollaisessa tiedotuspalvelussa tästä hyötyisi se, joka lähettää kysely sisään sitten, kun kone A on juuri aloittanut sen java -muistinsiivousajon - ja sekin vain sillä edellytyksellä, että kuormantasausta hoitava reititin on tietoinen siitä, että kone A on juuri nyt jumissa tuon muistinsiivousajon takia ja ohjaa kyselyt koneelle B.

JOS se kuormantasausta hoitava reititin ei ole tietoinen tuosta muistinsiivousajosta, se ohjaa typeränä edelleen kyselyitä koneelle A -joka on jumissa, eikä vastaa kyselyihin.

Ja se epäonninen, jonka kysely ohjautui koneelle A juuri ennen muistinsiivousajon alkua - niin häntä se kuormantasaus ei hyödytä yhtään mitään - ei, vaikka se reititin olisikin tietoinen ongelmasta.

JOS IT -alan johtajat käyttäisivät yhtään järkeään, JAVAa ei käytettäisi yhtään missään - juurikin siksi, että tuollainen muistinsiivousajo, joka pysäyttää koneen koko toiminnan, on aivan idioottimainen idea - siksi Delphi ja Kylix eivät tuollaista käytäkään.

Lue lisää

"Tosiasiassa: Jos minä olisin saanut koodata tuon siirretytnumerot.fi Kylix3:lla, niin palvelu vastaisi myös vuoden kiireisimmän tunnin isoon kyselymäärään ilman mitään ongelmia.

Mitään "skaalauksia" ei tarvita - ja kun niitä ei tarvita - ei tule myöskään mitään lisäkustannuksia."

On aika isoja ongelmia jos palvelin on rikki. Siksi kriittisempiä palveluja skaalataan horisontaalisesti vähintään kahdelle koneelle. Skaalautuvuutta tarvitaan silloinkin jos on hetkiä jolloin palvelua ei käytetä jolloin palvelimet voidaan sammuttaa kokonaan eivätkä tee mitään kuluja. Toki bootti vie aikaa jotain millisekunteja mutta tällaisissa tapauksissa valmiiksi etukäteen käännetty koodi GraalVM:llä ratkoo tuota asiaa, että pöyrähtää palvelin ylös nopeasti kun tulee kyselyjä.

"Jos laitetaan rinnakkain Java -ohjelma ja Kylix3 -ohjelma, niin nopeudessa Kylix3 -ohjelma voittaa joka kerta."

Varmaankin Hello Worldissa mutta normitilanteissa ei. Kylix3 on yli 20 vuotta vanha kurttaus ja joten Java kääntäjiä, ajoympäristöjä ja frameworkkeja on optimoitu vuosikymmeniä sen jälkeen joten muinaisjäänteillä ei ole toivoakaan päästä samalle tasolle kun niitä ei ole niin hyvin optimoitu.

"Java:ssa on lisäksi muita ongelmia - kuten se, että kun muistinsiivousajo käynnistyy, niin sillä aikaa java -ohjelma ei tee mitään."

Automaattinen muistinsiivous nopeuttaa silloin kun varataan ja vapautetaan paljon muistia. Tämä siis lisää suorituskykyä.

Muistinsiivous lasketaan millisekunneissa ja tuosta ei tarvitse välittää ellei ole jotain erityistarpeita deterministisyydelle.

Anonyymi kirjoitti:

"Mikä Microsoftin UDP:ssä on vikana"

etkö todella muka tiedä - vai teeskenteletkö vain tietämätöntä ?

Jos Windows PC:ssä laitat UDP socketin odottamaan yhteydenottoja (= UDP -paketteja) netistä, niin ensimmäinen sisääntuleva paketti ja vastauspaketti siihen toimivat aivan oikein.

MUTTA kun heti sen jälkeen tulee TOINEN tuleva UPD -paketti, niin siihen, kun vastaat, niin vastauspaketti ei menekää sinne, minne pitäisi (eli IP-osoitteeseen ja porttinumeroon, mistä tuo toinen UDP -paketti tulivat) vaan menee sinne samaan paikkaan minne ensimmäinenkin!

Tuo on BUGI Windowsin UDP -toteutuksessa.

Eli ensimmäisen kyselyn lähettäjä saa ensin vastauksen kyselyynsä - ja sitten toisen paketin, jota ei halua.

Ja toisen kyselyn lähettäjä ei saa vastauspakettia lainkaan (kun se vastaus menee väärään osoitteeseen).

En ole kokeillut linuxilla samaa, mutta olettaisin, ettei windowsin bugit vaikuta linuxiin mitään, joten mitä todennäköisimmin sama ohjelma käännettynä
Delphillä Windowsille = bugi

mutta käännettynä
Kylix3:lla Linuxille = ei bugia.

Tottakai tuo yllätti, mutta ilmeisesti Microsoftin pääpaino on ollut TCP:ssä, ja UDP -toteutus Windowsissa "on mitä on" - eli joissain asioissa jopa toimii -toisissa sitten ei.

Lue lisää

Googlettelin asiasta niin nähtävästi Microsoftilla on joku bugi UDP:n kanssa mutta en ole tuohon syventynyt.

Anonyymi kirjoitti:

" Firmat rekrytoi laittamalla ohjelmointitehtäviä ja nämä joilla on parhaat toteutukset helposti rekrytoidaan."

Täyttä valhetta!

Kerran oli helsingin sanomissa työpaikkailmoitus, jossa luki "Solve and be rewarded".

Siinä oli hexadesimaalista PDU -koodia.

Ratkaisin PDU -koodin tekemälläni Delphi -ohjelmalla.
Kun yritykselle selvisi, että ratkaisu oli tehty Delphillä - niin en saanut luvattua palkkiota.
Yritys (Malibu Software) siis valehteli päin naamaa työpaikkailmoituksessaan.
Tapahtuneesta on jo vuosia aikaa.

Kertaakaan ei ole ollut sellaista ohjelmointikilpailua, jossa annetaan tehtävä, ja sen laadukkaasti ratkaisija saa hyväpalkkaisen työpaikan - ja ohjelmointikielen saa hakija valita itse.

Jos tuollaisia kilpailuja olisi, oma ennustukseni on, että sen voittaja jopa yli 90% tapauksista olisi se, joka koodaa Delphillä.

Valehtelevia IT -johtajia kyllä riittää.

Lue lisää

"Kun yritykselle selvisi, että ratkaisu oli tehty Delphillä - niin en saanut luvattua palkkiota."

Ei tietenkään. Miksi valitsisivat jos joku toinen on tehnyt vaikka Rustilla, eli näkee että seuraa aikaansa. Jos tarjoaa jotain BASIC:ia, Delphiä, D-kieltä tai muuta vastaavaa mitä ei haluta mihinkään niin ei tietenkään pärjää.

Anonyymi kirjoitti:

"""
Apache kuitenkin on pitkään väistynyt käytöstä.
"""
TODISTA SE saatanan HÖNÖ jollakin tavoin.

"""
Staattinen sisältö menee CDN:n ja HTTP serverit on ohjelmointikielten ajoympäristöissä.
"""
Mitä helvettiä tämäkin tarkoittaa, etkö voi olla tarkempi kopioidessasi tekstiä verkkosivuilta, et selvästikkään itsekkään käsitä mitä kopioit.

"""
Hyvin huomaa että täällä ei porukka tiedä ohjelmien tekemisestä yhtään mitään kun höpisee jostain IIS:stä, Apachesta, Delphistä tai C :sta.
"""
Apache HTTP Server on avoimeen lähdekoodiin perustuva HTTP-palvelinohjelma. Apachen HTTP-palvelin on Apache Software Foundationin tunnetuin tuote ja tällä hetkellä mailman käytetyin HTTP-palvelinohjelma.

IIS no jaa, en viitsi selvittää tilannetta, en tietoisesti ole sitä käyttänyt.

Delphi on Borlandin tekemä Object Pascal -kieleen perustuva graafinen ohjelmankehitysympäristö ja ohjelmointikieli. Delphi mahdollisti julkaisuvuonnaan 1995 ensimmäisenä visuaalisen Windows-lomakkeiden editoinnin yhdistettynä olio-ohjelmointiin. Olin moneen kertaan itseeni tyytyväinen kun tulin alusta asti tuurilla valinneeksi mailman nopeiman kääntäjä ympäristön ja olen edelleenkin sitä mieltä parempaa valintaa en olisi pystynyt tekemään.

C on ohjelmointikieli, joka kehitettiin 1980-luvulla C-kielestä lisäämällä siihen muun muassa olio-ohjelmointiin ja geneerisyyteen liittyviä ominaisuuksia. Vielä tänäänkin olen vakuuttunut ettei aika jonka pistin C kielen opiskeluun mennyt hukkaan, parempaa pohjaa ohjelmoinnin perusteisiin ei ole olemassa vieläkään.

Alaikäiset rakkulat eivät osaa nykyään arvostaa työpöytä sovelluksia koska heillä on MEIDÄN tekemät työkalut verkottua osaamatta edes kirjoittaa ja lukea. Nämä saatanan sittisontiaiset aukovat päätään tyhmyyttään siinä kohtaa missä pitäisi osoittaan kunnioitusta mailman jaloinmille ohjelmointi lähteille.

Lue lisää

"TODISTA SE saatanan HÖNÖ jollakin tavoin."

https://www.netcraft.com/blog/january-2024-web-server-survey/

"Mitä helvettiä tämäkin tarkoittaa, etkö voi olla tarkempi kopioidessasi tekstiä verkkosivuilta, et selvästikkään itsekkään käsitä mitä kopioit."

En kopioinut mistään.

Nähtävästi et ole oikein ohjelmoinut kun useinkin HTTP serveri löytyy kielen standardikirjastoissa (Go, Rust jne.) tai frameworkista. Jos nyt vaikka Quarkusilla tekee softan niin siellä on pellin alla esimerkiksi Netty.

Anonyymi kirjoitti:

"Kerro mitä sillä tekee."

HÖNÖ etkö sinä osannut lukea; kädettömät ei tee Delphillä mitään.

Sinä olet kädetön ja et tee sillä mitään enkä minä jouda sinulle sitä opettamaan, se on elämän suuria valintoja, ei ohjelmoimaan opita alle 20 vuoden. Rakkulat sanoo osaavansa ohjelmoida jo siinä vaiheessa kun ne osaabat verkosta kopioida jonkun muun tekemän Hello World esimerkin, ei se mitään osaamista ole.

Lue lisää

"Sinä olet kädetön ja et tee sillä mitään enkä minä jouda sinulle sitä opettamaan"

Käytin Delphiä ensimmäisen kerran vuonna 1996. Oli se ysärillä ihan ok joissakin jutuissa mutta teknologia nyt on mennyt aika paljon eteenpäin.

"se on elämän suuria valintoja, ei ohjelmoimaan opita alle 20 vuoden."

Ei niin. Olenkin ohjelmoinut yli 30 vuotta.

"kädettömät ei tee Delphillä mitään"

Ei sillä oikeasti tee mitään. Jos se olisi hyvä niin sitä varmasti käyttäisi myös joku Netflix, Google, Facebook, Microsoft, IBM, Amazon, Apple, nVidia, Uber, Airbnb... Tai jotain laajasti käytettyjä palikoita kuten PostgreSQL, Redis, Ngixn jne. olisi tehty Delphillä.

Mutta kun ei, Delphiä ei oikeasti käytä mitkään merkittävät teknologiafirmat eikä se ole myöskään kykene tarjoamaan mitään sellaista että soveltuisi erikoistarpeisiin. Markkinoilta kuitenkin löytyy vaikka Sparkia, QNX:ää yms. joilla on omat erikoiskohteensa.

Delphillä kirjoitettuja ohjelmia kun tulee vastaan niin ovat jotain olleet järjestäen aina jotain ikivanhoja kurttauksia joita sitten kirjoitetaan uudestaan nykypäivän työkaluilla.

Anonyymi kirjoitti:

"Sinä olet kädetön ja et tee sillä mitään enkä minä jouda sinulle sitä opettamaan"

Käytin Delphiä ensimmäisen kerran vuonna 1996. Oli se ysärillä ihan ok joissakin jutuissa mutta teknologia nyt on mennyt aika paljon eteenpäin.

"se on elämän suuria valintoja, ei ohjelmoimaan opita alle 20 vuoden."

Ei niin. Olenkin ohjelmoinut yli 30 vuotta.

"kädettömät ei tee Delphillä mitään"

Ei sillä oikeasti tee mitään. Jos se olisi hyvä niin sitä varmasti käyttäisi myös joku Netflix, Google, Facebook, Microsoft, IBM, Amazon, Apple, nVidia, Uber, Airbnb... Tai jotain laajasti käytettyjä palikoita kuten PostgreSQL, Redis, Ngixn jne. olisi tehty Delphillä.

Mutta kun ei, Delphiä ei oikeasti käytä mitkään merkittävät teknologiafirmat eikä se ole myöskään kykene tarjoamaan mitään sellaista että soveltuisi erikoistarpeisiin. Markkinoilta kuitenkin löytyy vaikka Sparkia, QNX:ää yms. joilla on omat erikoiskohteensa.

Delphillä kirjoitettuja ohjelmia kun tulee vastaan niin ovat jotain olleet järjestäen aina jotain ikivanhoja kurttauksia joita sitten kirjoitetaan uudestaan nykypäivän työkaluilla.

Lue lisää

Mikä juttu tämä oikein on? Tullaan dissaaman muiden ohjelmointimieltymyksiä keskellä yötä - hirveä pätemisen tarve on pojalla!
Ei juurikaan kiinnosta mitä muut käyttävät ohjelmoimiseen - käytetään sitä mikä on opeteltu. Edelleenkin Delphillä on tuotettu niin paljon koodia maailmassa, että ylläpitohommia on tarjolla sitä osaaville.

Anonyymi kirjoitti:

Mikä juttu tämä oikein on? Tullaan dissaaman muiden ohjelmointimieltymyksiä keskellä yötä - hirveä pätemisen tarve on pojalla!
Ei juurikaan kiinnosta mitä muut käyttävät ohjelmoimiseen - käytetään sitä mikä on opeteltu. Edelleenkin Delphillä on tuotettu niin paljon koodia maailmassa, että ylläpitohommia on tarjolla sitä osaaville.

Lue lisää

Hah.. Tolppa-apinoiden logiikkaa.

Kerran vuosikymmeniä sitten opeteltu kiipeämään tolppaan puhelinkaapelien kanssa mutta sitten mobiiliverkot ja vanhoja kupareita rullattu pois ja tolppa-apinat sai keksiä muuta hommaa.

Ennen vanhaan aivan älytön määrä ihmisiä teki ylläpitoa liikennettä varten kun hevosia piti ruokkia, kengittää, kasvattaa, tehdä kuolaimia ja jne. Sitten tuli autot ja nuo jäivät tarpeettomiksi että saivat keksiä muuta hommaa.

Ohjelmistoalalla on kaiken aikaa opeteltu uutta ja kun merkittävää parannusta rautaan, infran arkkitehtuuriin tai standardeihin tulee niin asiat niin vanhat jutut menevät uudelleenkirjoitukseen tai sitten pilaantuvat kelvottomaksi.

"Edelleenkin Delphillä on tuotettu niin paljon koodia maailmassa, että ylläpitohommia on tarjolla sitä osaaville."

Niin on Coboliakin ja muuta muinaista roskaa mistä halutaan eroon, ei tosiaankaan tehdä yhtään lisää.

Tämä asia ei tunnu menevän ymmärrykseen että ketään ei kiinnosta mitä joku on opetellut vuosikymmeniä sitten ja se ei tee työkalua "parhaaksi" tai "muuta koodia virheettömäksi". Tuo on yksinkertaisesti valehtelua.

Sama kuin väittäisi, että hevonen on nopeampi kuin lentokone tai 28kbps modeemi siirtää tiedostoja nopeammin kuin valokuitu. Muinaistekniikkaa tuollainen Delphi on eikä vastaa yhtään tämän päivän käytäntöjä.

Vuoden 2024 ohjelmistokehityksen perusasioita:
-Palvelimet ovat likimain kaikki Linuxilla
-Virtualisoinnissa suositaan käyttöjärjestelmätason virtualisointia (containerit) että saa paremman hyötysuhteen. Koko koneen virtualisointia tehdään lähinnä hygieniasyistä, että jaetaan eri organisaatioita eri virtuaalikoneisiin. Tämä on syynä siihen, että palvelimet ovat lähes aina Linuxilla.
-Ohjelmointitiimeillä on palvelin joka kääntää koodia ja ajaa testejä, Johtuen edellisistä asioista, ne palvelimet ovat linuxeilla.
-IT-alan vahvoiksi standardeiksi on muodostunut Internetin verkkoprotokollat ja siellä liikkuvat tiedostomuodot. Se myös tehnyt sen, että käyttöliittymissä standardi ajoympäristö on selain. Selainta ei kuitenkaan käytetä jos on erityisvaatimuksia frontendille sillä selaimella toimiva käyttöliittymät menevät kankeaksi jos muistin käyttö on yli 256 megatavua. Sen lisäksi käyttöliittymän ensilataus menee kankeaksi jos kerralla on ladattavana yli 150 megatavua. Tästä syystä jos halutaan käsitellä reaaliajassa isompia määriä dataa käyttöliittymässä, selainta ei käytetä.
-Startup yritykset eivät koske ohjelmistokehitysvälineisiin jotka maksavat jotain, koska eivät halua vendor lock-in:iä eivätkä halua ylimääräisiä kuluja kehitysvaiheessa
-Edellisestä johtuen isot teknologiafirmat tarjoavat kaiken perusteknologian maksutta ja liiketoimintamallit on sitä, että voivat sitten tarjota hostausta, tukea yms. Tämä on edellytys heille, että heidän teknologiaa yleensäkään käytetään.
-Kokeneet ohjelmistokehittäjät tiedostovat vendor lock-in:n riskit liiketoiminnalle joten osaavat valikoida käyttöön välineitä joissa ei ole mitään pommeja. Viimeaikoina tunnettu vendor lock-in:n haittojen realisoituminen tapahtui Unity pelimoottorin käytösssä.

Kyllä jokainen voi kirjoittaa koodiaan millä haluaa mutta ei tarvitsisi valehdella Delphin olevan jotenkin erinomaisen hyvä tai suositeltava koska se ei sitä ole. Todellisuudessa se on ikivanhaa roskaa millä tekohengitetään vuosikymmeniä vanhoja kurttauksia johtuen vendor lock-in:stä eikä se sovi oikein kunnolla nykypäivän tarpeisiin.

Anonyymi kirjoitti:

Jos sillä jotain tekisi, ohjelmistokehittäjät valitsisivat sen käyttöön ja tekisivät sillä ohjelmia.

Näin ei kuitenkaan tapahdu.

"Jos sillä jotain tekisi, ohjelmistokehittäjät valitsisivat sen käyttöön ja tekisivät sillä ohjelmia.

Näin ei kuitenkaan tapahdu."

Ongelma EI ole ohjelmistokehittäjissä, vaan IT -managereissa!

Se on IT -managerit, jotka Suomessa haluavat estää Delphin käyttämisen IT -projekteissa.

On käynyt mielessä: Kehitän järjestelmän, jolla hakkeroidaan nykyautoja, erityisesti BMW -merkkisiä sekä Mercedes-Benzejä.

Kas kun IT -managerit mielellään ajaa noilla merkeillä.

Jos saan tuollaisen tehtyä, niin aivan varmasti aloitan nettimyynnin kaikille halukkaille.

Kunhan muutama autovaras ostaa tuollaisen autohakkerointityökalun, niin pian BMW:n ja Mercedes-Benzien omistajat saavat huomata, että kun he kävelevät parkkipaikalle, heidän autonsa ei ole enää siellä.

Ja hauskinta tässä on tämä fakta:
Vaikka olisikin autovakuutus, niin vakuutusyhtiö EI korvaa parkkipaikalta kadonnutta bemariasi, koska siinähän on ajonestojärjestelmä - ja sitähän vakuutusyhtiöiden mielestä ei ole mahdollista ohittaa.

Anonyymi kirjoitti:

Oikealle käyttikselle (Linuxeille) saa Lazarus Free Pascal yhdistelmän joka on käytännössä sama kuin Delphi.

"Oikealle käyttikselle (Linuxeille) saa Lazarus+Free Pascal yhdistelmän joka on käytännössä sama kuin Delphi"

Ohjelmoinnin osalta kylläkin näin - mutta vianetsinnän osalta:

Lazarus ei pärjää Delphille vianetsinnässä.

Tämä johtuu luokattoman huonon GDB -debuggerin käytöstä - ja siitä, ettei Linux kernelin kehittäjät viitsi koodata Linux kerneliin vastaavaa debug -toiminnallisuutta kuin mitä Windows -API:ssa on.

KAIKISTA näistä funktiosta (katso lista tätä sivulta):

https://learn.microsoft.com/en-us/windows/win32/debug/debugging-functions

pitäisi tehdä linux -vastineet, eli niin, että KERNEL sisältää vastaavat funktiot, tosin linuxissahan Kernel -funktioit kutsutaan erityisen "kernel call gate":n kautta.


Linuxissa siis:

mov EAX, Function_Number
mov E?X, Value
int 80H

Funktion muut parametrit tässä järjestyksessä:

EBX, ECX, EDX, ESI, EDI, EBP

Eli Linux kernel Systemcall - noissa siis voi olla enintään 6 parametriä ja lisäksi EAX -rekisterissä tieto siitä, mitä funktiota (numeerinen funktio-ID) kutsutaan.

Mikä siinä on vaikeaa, ettei linux -kernel -kehittäjät saa aikaiseksi vastaavaa listaa systeemikutsuista Debug -tarkoituksiin kuin mitä esittämäni linkin takaa löytyvä sivu tarjoaa Windows API:n osalta ?

Tuosta syystä Windowsille on suht. helppo kehittää aivan toimiva debuggeri, ja on niitä useita tehtykin, kuten esim. OllyDbg.

Oletko koskaan miettinyt, miksi OllyDbg:n saa Windowsille, mutta ei Linuxille ?

Syy löytyy juurikin tuosta:

Windows API tarjoaa ne funtiot, joita hyvän debuggerin tekemiseen tarvitaan.

Sensijaan Linux Kernel ei tarjoa sellaisia systeemifunktiokutsuja, jotka suunnilleen vastaisivat tuota Windows Debugging functions -API -kokoelmaa.

Linuxissa ei oikein ole muuta debuggeria kuin GDB, tuo debuggerien paarialuokkaan kuuluva ohjelma, jonka laatua voi parhaiten kuvata määritteellä: "täysin ala-arvoinen debuggeri".

Anonyymi kirjoitti:

"Jos sillä jotain tekisi, ohjelmistokehittäjät valitsisivat sen käyttöön ja tekisivät sillä ohjelmia.

Näin ei kuitenkaan tapahdu."

Ongelma EI ole ohjelmistokehittäjissä, vaan IT -managereissa!

Se on IT -managerit, jotka Suomessa haluavat estää Delphin käyttämisen IT -projekteissa.

On käynyt mielessä: Kehitän järjestelmän, jolla hakkeroidaan nykyautoja, erityisesti BMW -merkkisiä sekä Mercedes-Benzejä.

Kas kun IT -managerit mielellään ajaa noilla merkeillä.

Jos saan tuollaisen tehtyä, niin aivan varmasti aloitan nettimyynnin kaikille halukkaille.

Kunhan muutama autovaras ostaa tuollaisen autohakkerointityökalun, niin pian BMW:n ja Mercedes-Benzien omistajat saavat huomata, että kun he kävelevät parkkipaikalle, heidän autonsa ei ole enää siellä.

Ja hauskinta tässä on tämä fakta:
Vaikka olisikin autovakuutus, niin vakuutusyhtiö EI korvaa parkkipaikalta kadonnutta bemariasi, koska siinähän on ajonestojärjestelmä - ja sitähän vakuutusyhtiöiden mielestä ei ole mahdollista ohittaa.

Lue lisää

"Ongelma EI ole ohjelmistokehittäjissä, vaan IT -managereissa!"

Olen ohjelmistokehittäjä enkä mikään "IT manageri", ja olen sellaisessa asemassa että minä valitsen työkalut millä projekti tehdään.

Viimeaikojen projekteihin ohjelmointikieleksi meillä on valikoitunut Typescript, koska Javascriptiä osaa kaikki ja Typescript on oikeastaan sama mutta siinä on varmistin, että kehittäjä ei ammu itseään jalkaan niin helposti. Tavoitteena on että muut kehittäjät voivat mahdollisimman pienellä vaivalla tehdä muutoksia.

Lähdekoodissa muuttujien, funktioiden yms. nimet ja kommentit kirjoitetaan englanniksi, koska englantia osaa kaikki. Niitä ei kirjoiteta arabiaksi tai kiinaksi koska siitä tulisi ylimääräistä vaivaa.

Anonyymi kirjoitti:

"Kun yritykselle selvisi, että ratkaisu oli tehty Delphillä - niin en saanut luvattua palkkiota."

Ei tietenkään. Miksi valitsisivat jos joku toinen on tehnyt vaikka Rustilla, eli näkee että seuraa aikaansa. Jos tarjoaa jotain BASIC:ia, Delphiä, D-kieltä tai muuta vastaavaa mitä ei haluta mihinkään niin ei tietenkään pärjää.

Lue lisää

Rust on sateenkaariväkeä varten, ei sillä mitään tee normaalioloissa!

Anonyymi kirjoitti:

Rust on sateenkaariväkeä varten, ei sillä mitään tee normaalioloissa!

Ai niinkuin Yhdysvaltojen hallintoa?

Anonyymi kirjoitti:

Jos sillä jotain tekisi, ohjelmistokehittäjät valitsisivat sen käyttöön ja tekisivät sillä ohjelmia.

Näin ei kuitenkaan tapahdu.

ohjelmistokehittäjät nimenomaan haluaisivat valita Delphin!

Se on IT -johtajat / managerit, jotka tämän estävät.

Muiden välineiden kuin Delphin käyttö saa aikaan alalle tyypillisiä ongelmia:

Jokainen projekti maksaa sikamaisen paljon (koska muulla välineellä kuin Delphillä työaikaa kuluu aivan järkyttävän isoja määriä).

Lisäksi, usein muun kuin Delphin käyttäjät saavat aikaiseksi: heikkoa suorituskykyä sekä tietoturva-aukkoja.

Se, miksi suomalaisyritykset hölmöilevät, sitä en tiedä.

Mutta 1 asia on varma: jos säännöstä löytyisi yksikin poikkeus, voisin Delphillä koodaamalla tarjota sekä parempaa laatua että halvempaa hintaa.

Esteenä on yleensä IT -johtajat.

Siksi toimitusjohtajien kannattaisi antaa potkut sille kelvottomalle IT -johtajalle, ja palkata minut koodaamaan Delphillä.
Todennäköisesti saisin yksin aikaan enemmän ja parempaa kuin kokonainen tiimi Java -koodareita.

Anonyymi kirjoitti:

Mikä juttu tämä oikein on? Tullaan dissaaman muiden ohjelmointimieltymyksiä keskellä yötä - hirveä pätemisen tarve on pojalla!
Ei juurikaan kiinnosta mitä muut käyttävät ohjelmoimiseen - käytetään sitä mikä on opeteltu. Edelleenkin Delphillä on tuotettu niin paljon koodia maailmassa, että ylläpitohommia on tarjolla sitä osaaville.

Lue lisää

"Edelleenkin Delphillä on tuotettu niin paljon koodia maailmassa, että ylläpitohommia on tarjolla sitä osaaville"

ns. suuressa maailmassa ehkä onkin.

Suomessa ei todellakaan ole.

Suomessa tilanne on se, että jos joku yritys laittaa Delphi -työpaikan haettavaksi, niin yritys saa ainakin 200 hakemusta, ja vaikka niistä hakijoista 50% olisi osaamattomia, niin siltikin paikkaa hakee 100 pätevää hakijaa.

Eli, jos olet yksi pätevistä hakijoista, niin todennäköisyys, että saat työpaikan, on noin 1%.

Olen siis jaotellut oman harrastusprojektin niin, että se voi pyöriä vaikka AWS pilvipalveluissa tai muissa normi Linux-palvelimissa (backendissa), mutta myös toisaalta desktop-softana, jonka käyttöliittymä on tehty Lazaruksella, eli en kokonaan hommaa ole tehnyt Lazaruksella.

"En kyllä ymmärrä mikä haitta se on tehdä softa Delphillä (tai Lazaruksella) jos homma toimii ja asiakkaat tykkää/saa sillä tehtyä hommansa."

Tietokoneohjelmia kirjoitetaan uusiksi aika ajoin joten huonosti valitulla työkalulla aiheuttaa helposti vahinkoa asiakkaalle, että sitten kun uudelleenkirjoituksen aika on ja ei löydykkään niitä Cobol osaajia. Itse olen ottanut koppia ohjelmista joka on vain muutama vuosi sitten tehty niin oli parempi ratkaisu kirjoittaa uusiksi samalla kun ottaa haltuun, koska oli jatkuvuuden kannalta kyseenalaisia asioita.

En usko, että Lazaruksen kanssa on mitään ihmeempää ongelmaa mutta Delphi on riskialtis suljetun toteutuksen ja hinnan takia ja etenkin siksi, että ketään ei kiinnosta koska siihen tunkioon joten hankala saada ketään tekemään töitä ja varsinkaan järkevään hintaan kun siitä tulee sitä likaisen työn lisää.

"Itse tykkään tehdä tällä tyylillä softaa, mukava kun voi visuaalisesti suunnitella UI:n"

Niitä on suunniteltu visuaalisesti vuosikymmeniä.

"Toki työkseen tulee tehtyä Php/JavaScript (+ eri kirjastot) AWS jne.. "

PHP ja Javascript... hyi.

"Php/JavaScript -kirjastot on tosiaan hyviä kun tehdään joku palvelu ja se palvelee asiakkaita verkossa, mutta jotain hyötyohjelmaa en mielellään lähtisi tekemään millään JavaScript/web-tekniikoilla, etenkään jos ei ole tarvetta suoraan toimia netin kautta."

Hyötyohjelmiin web tekniikat soveltuvat erittäin hyvin. Lisäksi juurikin töitä tehdessä on ihan tavallista, että tietoa siirretään ja jaetaan netin kautta.

"Normaalissa desktop-softassa on tosiaan se hyvä puoli, että se toimii täysin asiakkaan omassa päässä, toki joitakin yhteyksiä voi olla esim. REST:in kautta palveluun, mutta muutoin desktop-softa ei vaadi jatkuvaa valvomista ja ylläpitoa, mikä olisi edessä jos hyötysofta toimisi suoraan web-tekniikalla verkossa."

Juurikin päinvastoin. Siinä on vähemmän ylläpitoa kun sovellus on verkossa. Toki desktopsovelluksen saa toimimaan selaimella täysin asiakkaan puolella, että lähinnä käynnistetään mutta silloinkin se tulee välimuistista. Lähinnä muistirajoitus frontend puolella kun käytetään selaimella.

"Tämmöinen vaatisi jo isomman tiimin pyörittelemään, jos ei halua olla 24/7 valvomassa itse."

No ei tarvitse.

Anonyymi kirjoitti:

"En kyllä ymmärrä mikä haitta se on tehdä softa Delphillä (tai Lazaruksella) jos homma toimii ja asiakkaat tykkää/saa sillä tehtyä hommansa."

Tietokoneohjelmia kirjoitetaan uusiksi aika ajoin joten huonosti valitulla työkalulla aiheuttaa helposti vahinkoa asiakkaalle, että sitten kun uudelleenkirjoituksen aika on ja ei löydykkään niitä Cobol osaajia. Itse olen ottanut koppia ohjelmista joka on vain muutama vuosi sitten tehty niin oli parempi ratkaisu kirjoittaa uusiksi samalla kun ottaa haltuun, koska oli jatkuvuuden kannalta kyseenalaisia asioita.

En usko, että Lazaruksen kanssa on mitään ihmeempää ongelmaa mutta Delphi on riskialtis suljetun toteutuksen ja hinnan takia ja etenkin siksi, että ketään ei kiinnosta koska siihen tunkioon joten hankala saada ketään tekemään töitä ja varsinkaan järkevään hintaan kun siitä tulee sitä likaisen työn lisää.

"Itse tykkään tehdä tällä tyylillä softaa, mukava kun voi visuaalisesti suunnitella UI:n"

Niitä on suunniteltu visuaalisesti vuosikymmeniä.

"Toki työkseen tulee tehtyä Php/JavaScript ( eri kirjastot) AWS jne.. "

PHP ja Javascript... hyi.

"Php/JavaScript -kirjastot on tosiaan hyviä kun tehdään joku palvelu ja se palvelee asiakkaita verkossa, mutta jotain hyötyohjelmaa en mielellään lähtisi tekemään millään JavaScript/web-tekniikoilla, etenkään jos ei ole tarvetta suoraan toimia netin kautta."

Hyötyohjelmiin web tekniikat soveltuvat erittäin hyvin. Lisäksi juurikin töitä tehdessä on ihan tavallista, että tietoa siirretään ja jaetaan netin kautta.

"Normaalissa desktop-softassa on tosiaan se hyvä puoli, että se toimii täysin asiakkaan omassa päässä, toki joitakin yhteyksiä voi olla esim. REST:in kautta palveluun, mutta muutoin desktop-softa ei vaadi jatkuvaa valvomista ja ylläpitoa, mikä olisi edessä jos hyötysofta toimisi suoraan web-tekniikalla verkossa."

Juurikin päinvastoin. Siinä on vähemmän ylläpitoa kun sovellus on verkossa. Toki desktopsovelluksen saa toimimaan selaimella täysin asiakkaan puolella, että lähinnä käynnistetään mutta silloinkin se tulee välimuistista. Lähinnä muistirajoitus frontend puolella kun käytetään selaimella.

"Tämmöinen vaatisi jo isomman tiimin pyörittelemään, jos ei halua olla 24/7 valvomassa itse."

No ei tarvitse.

Lue lisää

Yleensä uuden softan motiivi on myydä samalla uudet laitteet - koska vanhat eivät enää riitä pyörittämään uutta softaa. Tästä syystä monessa paikassa on edelleenkin käytössä -95 kirjoitettu varastonhallinta softa: Turbo Pascal:lla kirjoitettu. Nykyään siihen tarvitaan pieniä muutoksia, mutta isoja muutoksia ei haluta, koska kaikki näppäimistön pikakomennot tulevat selkärangasta. Ohjelma toimii nykyisillä laitteilla myös ajatuksen nopeudella eikä ole pelkoa, että joku osaisi siihen murtautua, koska rajapintoja ei ole "roikkumassa" niin kuin nykyisillä ympäristöillä usein on.

Anonyymi kirjoitti:

Yleensä uuden softan motiivi on myydä samalla uudet laitteet - koska vanhat eivät enää riitä pyörittämään uutta softaa. Tästä syystä monessa paikassa on edelleenkin käytössä -95 kirjoitettu varastonhallinta softa: Turbo Pascal:lla kirjoitettu. Nykyään siihen tarvitaan pieniä muutoksia, mutta isoja muutoksia ei haluta, koska kaikki näppäimistön pikakomennot tulevat selkärangasta. Ohjelma toimii nykyisillä laitteilla myös ajatuksen nopeudella eikä ole pelkoa, että joku osaisi siihen murtautua, koska rajapintoja ei ole "roikkumassa" niin kuin nykyisillä ympäristöillä usein on.

Lue lisää

"Yleensä uuden softan motiivi on myydä samalla uudet laitteet - koska vanhat eivät enää riitä pyörittämään uutta softaa."

Höpöä. Ohjelmistoja tekevät firmat hyvin harvoin myyvät yhtään mitään laitetta.

Ohjelmia uusittu perinteisesti siksi, että uudempi teknologia mahdollistanut softan tekemisen niin paljon paremmin. Toinen merkittävä syy ollut jatkuvuuden säilyminen, että säilyy yhteensopivana.

Laitteita nyt menee uusiksi sitten mm. siksi, että niitä hajoilee.

"Tästä syystä monessa paikassa on edelleenkin käytössä -95 kirjoitettu varastonhallinta softa: Turbo Pascal:lla kirjoitettu."

Ei ole. Harvinaista, että tuollaista on missään mutta kai se jotenkin toimii jos FreePascalilla kääntyy. Mutta jos ei ole rajapintaa niin voi olla hankalaa, että kassa/verkkokauppa osaisi muuttaa varaston tilannetta tai kirjanpitojärjestelmä osaisi kysyä varastosaldon.

Anonyymi kirjoitti:

"Yleensä uuden softan motiivi on myydä samalla uudet laitteet - koska vanhat eivät enää riitä pyörittämään uutta softaa."

Höpöä. Ohjelmistoja tekevät firmat hyvin harvoin myyvät yhtään mitään laitetta.

Ohjelmia uusittu perinteisesti siksi, että uudempi teknologia mahdollistanut softan tekemisen niin paljon paremmin. Toinen merkittävä syy ollut jatkuvuuden säilyminen, että säilyy yhteensopivana.

Laitteita nyt menee uusiksi sitten mm. siksi, että niitä hajoilee.

"Tästä syystä monessa paikassa on edelleenkin käytössä -95 kirjoitettu varastonhallinta softa: Turbo Pascal:lla kirjoitettu."

Ei ole. Harvinaista, että tuollaista on missään mutta kai se jotenkin toimii jos FreePascalilla kääntyy. Mutta jos ei ole rajapintaa niin voi olla hankalaa, että kassa/verkkokauppa osaisi muuttaa varaston tilannetta tai kirjanpitojärjestelmä osaisi kysyä varastosaldon.

Lue lisää

"Ei ole."

On varmasti ainakin yksi ja se on minun tekemä. Samassa firmassa on myös pari muuta minun tekemää softaa. Joista ainakin toinen herätti ihailua koska ohjelmaa pyydettiin vuoron lopussa ja lupasin aamulla tuoda sen töihin tullessani ja kun sen seuraavan kerran näin oli väliä 5..7 vuotta ja tarkastellasani sen yllä pitämää lokia kaikki oli toiminut täysin niin kuin se silloin oletettiin olevan tarpeellista asettaa toimimaan.

Anonyymi kirjoitti:

"Ei ole."

On varmasti ainakin yksi ja se on minun tekemä. Samassa firmassa on myös pari muuta minun tekemää softaa. Joista ainakin toinen herätti ihailua koska ohjelmaa pyydettiin vuoron lopussa ja lupasin aamulla tuoda sen töihin tullessani ja kun sen seuraavan kerran näin oli väliä 5..7 vuotta ja tarkastellasani sen yllä pitämää lokia kaikki oli toiminut täysin niin kuin se silloin oletettiin olevan tarpeellista asettaa toimimaan.

Lue lisää

"On varmasti ainakin yksi ja se on minun tekemä."

Kuinka paljon möit uusia tietokoneita?

Anonyymi kirjoitti:

"On varmasti ainakin yksi ja se on minun tekemä."

Kuinka paljon möit uusia tietokoneita?

En ole myynyt yhtään konetta eläessäni

Anonyymi kirjoitti:

En ole myynyt yhtään konetta eläessäni

Eli ohjelmia ei tehdä siksi että myytäisiin tietokoneita.

Anonyymi kirjoitti:

Eli ohjelmia ei tehdä siksi että myytäisiin tietokoneita.

Ensimmäisen kierroksen ohjelma on sellainen, joka ei myy tietokoneita. Toisella kierroksella koodarit on irtisanottu ja tilalle palkattu uusia jotka eivät hommaan pysty - ohjelmasta tulee hidas: Toimitusjohtaja saa idean, että tällähän myydään tietokone, jolla ohjelmaa pystyy pyörittämään siihen rinnalle! Ja näin tapahtuu koko ajan esim. mikkihiirisoftan toimesta - vai oletko sokea?

Anonyymi kirjoitti:

Eli ohjelmia ei tehdä siksi että myytäisiin tietokoneita.

Viranomaiset huolissaan Windowsin uudesta ominaisuudesta
Microsoftin uusi pc-mallisto kykenee tarkkailemaan hyvin yksityiskohtaisesti, mitä käyttäjä tekee.

MICROSOFT esitteli uudet Windows 11:tä ajavat tietokoneet, joista käytetään nimeä Copilot+ PC. Eri valmistajilta tulevat tietokoneet käsittävät Recall-nimisen toiminnon, joka seuraa alati, mitä koneella tapahtuu.

Britannian tietosuojaviranomainen Information Commissioner's Office on toiminnosta tuoreeltaan huolestunut.

– Odotamme organisaatioiden kertovan käyttäjilleen avoimesti, kuinka heidän tietojaan käytetään ja käsittelemään henkilökohtaista tietoa vain sen verran, mitä vaaditaan tiettyyn tarkoitukseen. Alan on otettava tietojen suojelu huomioon alusta lähtien ja tarkasti arvioida ja poistaa ihmisten oikeuksiin ja vapauksiin kohdistuvia riskejä ennen tuotteiden tuomista markkinoille,

Anonyymi kirjoitti:

"Ei ole."

On varmasti ainakin yksi ja se on minun tekemä. Samassa firmassa on myös pari muuta minun tekemää softaa. Joista ainakin toinen herätti ihailua koska ohjelmaa pyydettiin vuoron lopussa ja lupasin aamulla tuoda sen töihin tullessani ja kun sen seuraavan kerran näin oli väliä 5..7 vuotta ja tarkastellasani sen yllä pitämää lokia kaikki oli toiminut täysin niin kuin se silloin oletettiin olevan tarpeellista asettaa toimimaan.

Lue lisää

En yhtään ihmettele.

Jos käytit joko Turbo Pascalia (verio 5.5 tai uudempi) tai Delphiä tai FreePascalia, kaikissa noissa käytetään Objectpascal -ohjelmointikieltä.

Ja jos olet pätevä koodaaja, niin en yhtään ihmettele: Objectpascalilla pienempiä ohjelmia voi tosiaan tehdä noinkin kiireisellä aikataululla, ja lopputulos voi silti olla laadukas.


M-Kar jaksaa jauhaa skeidaa (kuten aina), mutta:

tuo malliesimerkkini www.siirretytnumerot.fi

- jos minut olisi päästetty koodaamaan tuo Kylix3:lla, niin yksi ainoa PC -tyyppinen tietokone Linux -käyttöjärjestelmällä - ja tekemäni ohjelma olisi huolehtinut siitä, että jokainen kyselijä saa puhelinnumeron perusteella tiedon siitä, että minkä operaattorin liittymä ko. numero on - ja Kylix -ohjelmani Linuxissa olisi toiminut vuodesta toiseen ilman ensimmäistäkään sovellusohjelmassa olevaa virhettä.

JOS jokin vikatilanne olisi koskaan syntynyt, niin tässä todennäköisimmästä alkaen syitä, mikä voi mennä vikaan:

1) Tietokantapalvelin sekoaa niin, ettei se enää vastaa asianmukaisesti sovellusohjelman kyselyihin.

2) tietoliikennehäiriö (eli nettiyhteys katkennut)

3) Sähkökatkos

Tietokantapalvelimen sekoiluun paras keino: sovellusohjelma itse kertoo (IPC:n avulla) toiselle ohjelmalle (valvontaohjelma) joka on myös tehty Kylixillä:

Jos näin käy, tuo valvontaohjelma tekee seuraavaa:

1) tappaa numsi -palvelinohjelman

2) tappaa tietokantapalvelimen

3) käynnistää tietokantapalvelimen uudelleen (jos se on käyttöjärjestelmätasolla mahdollista silloin kohdat 2 & 3 voi yhdistää yhdeksi kombotoiminnoksi "uudelleenkäynnistä tietokantapalvelin")

4) käynnistää numsi -palvelinohjelman uudelleen

Ainakin Windows -koneessa olen itse havainnut, kun tietokantapalvelin menee sellaiseen jumiin, ettei se enää käsittele asianmukaisesti asiakasohjelman SQL -tietokantaoperaatioita. Eli joko ei anna haluttuja tuloksia tai menee niin jumiin, että SQL -tietokantaoperaation ajallinen kestoaika = ikuisuus, eli operaatio ei ikinä palaa kutsujalleen - jolloin sovellusohjelman SQL -kyselyä tekevä säie menee jumiin.

Yksisäikeisessä ohjelmassa siis koko ohjelma menee jumiin, mutta monisäikeisessä ohjelmassa voi olla toinen säie, joka valvoo tilannetta ja osaa reagoida virhetilanteeseen oikein.

Mutta jos SQL -operaatio ei palaa kutsujalleen koskaan, niin ei siinä oikein muuta voi kuin tappaa koko prosessi - samalla kannattaa tappaa ja uudelleenkäynnistää se tietokantapalvelin.

Kokemukseni jumiutuvasta tietokantapalvelimesta on nimenomaan Windows -käyttöjärjestelmästä. Minulla ei ole tietoa, voiko Linuxissa ajettava tietokantapalvelin (esim. PostgreSQL) tehdä saman.

Niille, jotka ihmettelevät: "Miksei MySQL tai MariaDB" - ainakin MySQL:n osalta syy on lisenssiehdot - MySQL on maailman piraattikopioiduin tietokantapalvelinohjelmisto!

Faktaa lisenssiehdoista:

MySQL -tietokantapalvelinohjelmistoa voit laillisesti käyttää, jos:

1) oma ohjelmasi, joka sitä MySQL -tietokantapalvelinohjelmistoa käyttää, on avointa lähdekoodia

TAI

2) jos olet maksanut lisenssimaksun MySQL -tietokantapalvelinohjelmiston käytöstä.

Sensijaan, jos oma ohjelmasi EI OLE avointa lähdekoodia, tällöin MySQL:n ilmaiseksi käytön mahdollistava lisenssi ei ole voimassa, koska lisenssiehtoja on tällöin rikottu!

Suljetun lähdekoodin ohjelmistoja käytettäessä MySQL:n käytöstä on maksettava lisenssimaksu - muu on piratismia !

Onko MariaDB:n lisenssiehdot samat kuin MySQL:n ?

Käsittääkseni MariaDB on jatkokehitetty MySQL:n pohjalta - ja jos näin on niin silloin ainoa keino vaihtaa toiseen lisenssiin olisi se, että alkuperäiset MySQL:n tekijänoikeuksien omistajat antaisivat lisenssiehtojen muutokseen suostumuksensa!

Ja jos (ja kuten oletan, KUN) eivät suostumustaan anna, niin siksi MariaDB:n lisenssiehdot ovat samat kuin MySQL:nkin.

PostgreSQL:n lisenssiehdot nimenomaan sallivat käytön myös silloin, kun on suljetun lähdekoodin ohjelmisto PostgreSQL:ää käyttämässä.

Jostain syystä moni ohittaa MySQL:n lisenssiehdot - mutta se että piratismi on yleistä, ei tee siitä laillista.

Anonyymi kirjoitti:

En yhtään ihmettele.

Jos käytit joko Turbo Pascalia (verio 5.5 tai uudempi) tai Delphiä tai FreePascalia, kaikissa noissa käytetään Objectpascal -ohjelmointikieltä.

Ja jos olet pätevä koodaaja, niin en yhtään ihmettele: Objectpascalilla pienempiä ohjelmia voi tosiaan tehdä noinkin kiireisellä aikataululla, ja lopputulos voi silti olla laadukas.


M-Kar jaksaa jauhaa skeidaa (kuten aina), mutta:

tuo malliesimerkkini www.siirretytnumerot.fi

- jos minut olisi päästetty koodaamaan tuo Kylix3:lla, niin yksi ainoa PC -tyyppinen tietokone Linux -käyttöjärjestelmällä - ja tekemäni ohjelma olisi huolehtinut siitä, että jokainen kyselijä saa puhelinnumeron perusteella tiedon siitä, että minkä operaattorin liittymä ko. numero on - ja Kylix -ohjelmani Linuxissa olisi toiminut vuodesta toiseen ilman ensimmäistäkään sovellusohjelmassa olevaa virhettä.

JOS jokin vikatilanne olisi koskaan syntynyt, niin tässä todennäköisimmästä alkaen syitä, mikä voi mennä vikaan:

1) Tietokantapalvelin sekoaa niin, ettei se enää vastaa asianmukaisesti sovellusohjelman kyselyihin.

2) tietoliikennehäiriö (eli nettiyhteys katkennut)

3) Sähkökatkos

Tietokantapalvelimen sekoiluun paras keino: sovellusohjelma itse kertoo (IPC:n avulla) toiselle ohjelmalle (valvontaohjelma) joka on myös tehty Kylixillä:

Jos näin käy, tuo valvontaohjelma tekee seuraavaa:

1) tappaa numsi -palvelinohjelman

2) tappaa tietokantapalvelimen

3) käynnistää tietokantapalvelimen uudelleen (jos se on käyttöjärjestelmätasolla mahdollista silloin kohdat 2 & 3 voi yhdistää yhdeksi kombotoiminnoksi "uudelleenkäynnistä tietokantapalvelin")

4) käynnistää numsi -palvelinohjelman uudelleen

Ainakin Windows -koneessa olen itse havainnut, kun tietokantapalvelin menee sellaiseen jumiin, ettei se enää käsittele asianmukaisesti asiakasohjelman SQL -tietokantaoperaatioita. Eli joko ei anna haluttuja tuloksia tai menee niin jumiin, että SQL -tietokantaoperaation ajallinen kestoaika = ikuisuus, eli operaatio ei ikinä palaa kutsujalleen - jolloin sovellusohjelman SQL -kyselyä tekevä säie menee jumiin.

Yksisäikeisessä ohjelmassa siis koko ohjelma menee jumiin, mutta monisäikeisessä ohjelmassa voi olla toinen säie, joka valvoo tilannetta ja osaa reagoida virhetilanteeseen oikein.

Mutta jos SQL -operaatio ei palaa kutsujalleen koskaan, niin ei siinä oikein muuta voi kuin tappaa koko prosessi - samalla kannattaa tappaa ja uudelleenkäynnistää se tietokantapalvelin.

Kokemukseni jumiutuvasta tietokantapalvelimesta on nimenomaan Windows -käyttöjärjestelmästä. Minulla ei ole tietoa, voiko Linuxissa ajettava tietokantapalvelin (esim. PostgreSQL) tehdä saman.

Niille, jotka ihmettelevät: "Miksei MySQL tai MariaDB" - ainakin MySQL:n osalta syy on lisenssiehdot - MySQL on maailman piraattikopioiduin tietokantapalvelinohjelmisto!

Faktaa lisenssiehdoista:

MySQL -tietokantapalvelinohjelmistoa voit laillisesti käyttää, jos:

1) oma ohjelmasi, joka sitä MySQL -tietokantapalvelinohjelmistoa käyttää, on avointa lähdekoodia

TAI

2) jos olet maksanut lisenssimaksun MySQL -tietokantapalvelinohjelmiston käytöstä.

Sensijaan, jos oma ohjelmasi EI OLE avointa lähdekoodia, tällöin MySQL:n ilmaiseksi käytön mahdollistava lisenssi ei ole voimassa, koska lisenssiehtoja on tällöin rikottu!

Suljetun lähdekoodin ohjelmistoja käytettäessä MySQL:n käytöstä on maksettava lisenssimaksu - muu on piratismia !

Onko MariaDB:n lisenssiehdot samat kuin MySQL:n ?

Käsittääkseni MariaDB on jatkokehitetty MySQL:n pohjalta - ja jos näin on niin silloin ainoa keino vaihtaa toiseen lisenssiin olisi se, että alkuperäiset MySQL:n tekijänoikeuksien omistajat antaisivat lisenssiehtojen muutokseen suostumuksensa!

Ja jos (ja kuten oletan, KUN) eivät suostumustaan anna, niin siksi MariaDB:n lisenssiehdot ovat samat kuin MySQL:nkin.

PostgreSQL:n lisenssiehdot nimenomaan sallivat käytön myös silloin, kun on suljetun lähdekoodin ohjelmisto PostgreSQL:ää käyttämässä.

Jostain syystä moni ohittaa MySQL:n lisenssiehdot - mutta se että piratismi on yleistä, ei tee siitä laillista.

Lue lisää

" jos minut olisi päästetty koodaamaan tuo Kylix3:lla, niin yksi ainoa PC -tyyppinen tietokone Linux -käyttöjärjestelmällä - ja tekemäni ohjelma olisi huolehtinut siitä, että jokainen kyselijä saa puhelinnumeron perusteella tiedon siitä, että minkä operaattorin liittymä ko. numero on - ja Kylix -ohjelmani Linuxissa olisi toiminut vuodesta toiseen ilman ensimmäistäkään sovellusohjelmassa olevaa virhettä."

Vaan kun ei olisi toiminut. Kylix ei pysynyt yhteensopivana.

"1) Tietokantapalvelin sekoaa niin, ettei se enää vastaa asianmukaisesti sovellusohjelman kyselyihin."

Harvinaista.

"2) tietoliikennehäiriö (eli nettiyhteys katkennut)"

Sitä varten niitä palvelimia on monta.

"3) Sähkökatkos"

Ei vaikuta. Varavoimat on keksitty.

"Ainakin Windows -koneessa olen itse havainnut"

Ei niitä Windowsissa ajella. Kaikki serverit Linuxilla ja toimivat ihan normaalisti häiriöttä vuodesta toiseen.

"Yksisäikeisessä ohjelmassa siis koko ohjelma menee jumiin, mutta monisäikeisessä ohjelmassa voi olla toinen säie, joka valvoo tilannetta ja osaa reagoida virhetilanteeseen oikein."

Vuosikymmeniä sitten ihan tavallista että näytetään käyttäjälle ilmoitus, että yrittää uudestaan hetken kuluttua (jos on vaikka ylikuormittunut), ja sitten vaan tekee kyselyn uudestaan. Kantapalvelimia sitten voi olla se toinenkin ruksuttamassa että kyselyt ohjautuu sinne sitten. Onhan noissa timeoutit sitten.

"Sensijaan, jos oma ohjelmasi EI OLE avointa lähdekoodia, tällöin MySQL:n ilmaiseksi käytön mahdollistava lisenssi ei ole voimassa, koska lisenssiehtoja on tällöin rikottu!"

MySQL:n käyttämä GPLv2 lisenssi tarkoittaa että koodi joka on linkitetty GPLv2 koodiin, pitää avata mikäli ohjelmaa jaetaan asiakkaalle.

Sitä voi silti käyttää itse jakamatta ohjelmaa mihinkään asiakkaalle. Eli yksinkertaisesti voi tehdä vaikka potilastietojärjestelmän jota myy SaaS palveluna. Mutta jos sairaala haluaa sen potilastietojärjestelmän vaikka turvallisuussyistä omaan verkkoon, kaikki palikat jotka on linkitetty GPLv2 koodiin tulisi jakaa asiakkaalle tai sitten pitää maksaa lisenssistä.

Anonyymi kirjoitti:

" jos minut olisi päästetty koodaamaan tuo Kylix3:lla, niin yksi ainoa PC -tyyppinen tietokone Linux -käyttöjärjestelmällä - ja tekemäni ohjelma olisi huolehtinut siitä, että jokainen kyselijä saa puhelinnumeron perusteella tiedon siitä, että minkä operaattorin liittymä ko. numero on - ja Kylix -ohjelmani Linuxissa olisi toiminut vuodesta toiseen ilman ensimmäistäkään sovellusohjelmassa olevaa virhettä."

Vaan kun ei olisi toiminut. Kylix ei pysynyt yhteensopivana.

"1) Tietokantapalvelin sekoaa niin, ettei se enää vastaa asianmukaisesti sovellusohjelman kyselyihin."

Harvinaista.

"2) tietoliikennehäiriö (eli nettiyhteys katkennut)"

Sitä varten niitä palvelimia on monta.

"3) Sähkökatkos"

Ei vaikuta. Varavoimat on keksitty.

"Ainakin Windows -koneessa olen itse havainnut"

Ei niitä Windowsissa ajella. Kaikki serverit Linuxilla ja toimivat ihan normaalisti häiriöttä vuodesta toiseen.

"Yksisäikeisessä ohjelmassa siis koko ohjelma menee jumiin, mutta monisäikeisessä ohjelmassa voi olla toinen säie, joka valvoo tilannetta ja osaa reagoida virhetilanteeseen oikein."

Vuosikymmeniä sitten ihan tavallista että näytetään käyttäjälle ilmoitus, että yrittää uudestaan hetken kuluttua (jos on vaikka ylikuormittunut), ja sitten vaan tekee kyselyn uudestaan. Kantapalvelimia sitten voi olla se toinenkin ruksuttamassa että kyselyt ohjautuu sinne sitten. Onhan noissa timeoutit sitten.

"Sensijaan, jos oma ohjelmasi EI OLE avointa lähdekoodia, tällöin MySQL:n ilmaiseksi käytön mahdollistava lisenssi ei ole voimassa, koska lisenssiehtoja on tällöin rikottu!"

MySQL:n käyttämä GPLv2 lisenssi tarkoittaa että koodi joka on linkitetty GPLv2 koodiin, pitää avata mikäli ohjelmaa jaetaan asiakkaalle.

Sitä voi silti käyttää itse jakamatta ohjelmaa mihinkään asiakkaalle. Eli yksinkertaisesti voi tehdä vaikka potilastietojärjestelmän jota myy SaaS palveluna. Mutta jos sairaala haluaa sen potilastietojärjestelmän vaikka turvallisuussyistä omaan verkkoon, kaikki palikat jotka on linkitetty GPLv2 koodiin tulisi jakaa asiakkaalle tai sitten pitää maksaa lisenssistä.

Lue lisää

M-kar valehtelee jälleen!

" Kylix -ohjelmani Linuxissa olisi toiminut vuodesta toiseen ilman ensimmäistäkään sovellusohjelmassa olevaa virhettä.

Vaan kun ei olisi toiminut. Kylix ei pysynyt yhteensopivana."

Vai, ettei SINUN mielestäsi Kylixillä käännetty OMA ohjelma pysynyt yhteensopivana ???

Jos Kylixillä käännettiin ohjelma linux -binääriksi vuonna 2003, niin se toimii nykylinuxeissakin erinomaisen hyvin.

Siis:

a) 32 -bittisessä versiossa linuxista

ja

b) Sellaisessa 64 -bittisessä versiossa linuxista, jossa myös 32 -bittiset sovellukset ovat edelleen tuettuja.

AINOA tilanne miksi yhteensopivuus rikkoutuisi, olisi se, jos olisi jokin syy päivittää uusimpaan 64 -bittiseen linux -versioon, ja tuo uusin 64 -bittinen linux -versio olisikin sellainen, johon ei sisälly eikä voi asentaa tukea 32 -bittisille sovelluksille.

Mutta JOS tällainen päivitys olisi pakko tehdä (99% tapauksista ei todellakaan ole pakko) niin silloin tietenkin käännettäisi se vanha kylix -ohjelmisto uudelleen esim. FreePascalin 64 -bittisellä linux -versiolla.

Niin kauan kun 32 -bittiset sovellukset ovat tuettuja, niin tuotakaan ei tarvitse tehdä.

M-Karin "osaaminen" todistettiin täten jälleen kerran olemattomaksi.

Oikeastaan ainoa asia. jossa 32 -bittisyydestä on luovuttu, on web -selaimet.
Joitakin web -selaimia ei enää saa 32 -bittisenä versiona.

Mutta jos esim. Debian päättäisi, että jatkossa 32-bittistä versiota Debianista ei enää julkaista, ja päättäisi samalla pudottaa 64 -bittisestä käyttöjärjestelmästä pois tuen 32 -bittisille sovelluksille, niin eiköhän esim. Red Hat linuxista saa edelleenkin sellaisen version, joka kykenee ajamaan myös 32 -bittisiä sovelluksia.

Näinollen tuokin uhka on ainakin toistaiseksi lähinnä teoreettinen


Mutta JOS tuo uhka (siis 32 -bittisen sovellustuen poistuminen) jonain päivänä olisi tosiasia, niin:

1) ei se olemassaolevasta käyttöjärjestelmästä itsekseen poistu, vaan se poistuu jos käyttöjärjestelmä päivitetään uudempaan.

JA

2) JOS jonain päivänä olisi tiedossa, että pian on pakko päivittää käyttöjärjestelmä sellaiseen versioon, joka ei 32 -bittisiä sovelluksia tue, niin silloin tietenkin käännetään se vanha Kylix -lähdekoodi uudelleen FreePascalin 64 -bittisellä linux -versiolla, ja vasta sen jälkeen päivitetään käyttöjärjestelmä.

Ei ole mitään syytä, miksei vanhaa Kylixillä tehtyä ohjelmaa voisi uudelleenkääntää FreePascalilla 64 -bittiseksi sovellukseksi - ja sen jälkeen ohjelmaa voi sitten ajaa 64 -bittisenä versiona.

Mutta kaikissa niissä linux -versioissa, joissa on edelleen tuki 32 -bittisille sovelluksille, niin vanha 32 -bittinen Kylixillä tehty ohjelma kyllä toimii edelleen moitteettomasti.

Yleensä ohjelmointikielestä ei pysty päättelemään onko se tarkoitus kääntää 32 vaiko 64 bittiseen ympäristöön. Koodi ei yksinkertaisesti ota tähän asiaan kantaa vaan kääntäjä ottaa. Riippuu täysin ongelmasta pystyykö sen ratkaisemaan riittävän nopeasti 32-bittisellä vai pitääkö prosessorin olla natiivisti 64 bittinen ennen kuin koodista tulee riittävän jouheaa.

Anonyymi kirjoitti:

Yleensä ohjelmointikielestä ei pysty päättelemään onko se tarkoitus kääntää 32 vaiko 64 bittiseen ympäristöön. Koodi ei yksinkertaisesti ota tähän asiaan kantaa vaan kääntäjä ottaa. Riippuu täysin ongelmasta pystyykö sen ratkaisemaan riittävän nopeasti 32-bittisellä vai pitääkö prosessorin olla natiivisti 64 bittinen ennen kuin koodista tulee riittävän jouheaa.

Lue lisää

Käyttöjärjestelmistä ei oikein ole enää 32-bittisiä asennusimageja. Joissakin vielä on tukea ajaa rinnalla 32-bittistä koodia mutta sekin on poistumassa.

Delphi 11 community on yksinkertaisesti roskaa.

Anonyymi kirjoitti:

Käyttöjärjestelmistä ei oikein ole enää 32-bittisiä asennusimageja. Joissakin vielä on tukea ajaa rinnalla 32-bittistä koodia mutta sekin on poistumassa.

Delphi 11 community on yksinkertaisesti roskaa.

Lue lisää

On nitä 32-bittisiäkin oikeita käyttiksiä vielä saatavilla, esim Debian ja Linux Mint DE eli Debian Edition.

Anonyymi kirjoitti:

On nitä 32-bittisiäkin oikeita käyttiksiä vielä saatavilla, esim Debian ja Linux Mint DE eli Debian Edition.

Debian on luopumassa 32-bittisistä asennuksista kun 32-bittisiä prossuja ei ole valmistettu aikoihin. Enste poistuu asennusimaget ja sitten poistavat 32-bittiset kirjastot että poistuu sovellusten yhteensopivuus. Varmaan jo Debian 13 on tällainen että asennusimaget/kerneli on 64-bit.

Anonyymi kirjoitti:

Debian on luopumassa 32-bittisistä asennuksista kun 32-bittisiä prossuja ei ole valmistettu aikoihin. Enste poistuu asennusimaget ja sitten poistavat 32-bittiset kirjastot että poistuu sovellusten yhteensopivuus. Varmaan jo Debian 13 on tällainen että asennusimaget/kerneli on 64-bit.

Lue lisää

Vastahan Debian julkaisi i386-yhteensopivan asennusimagensa! Joten mistä moiset väitteesi?

Anonyymi kirjoitti:

Vastahan Debian julkaisi i386-yhteensopivan asennusimagensa! Joten mistä moiset väitteesi?

Onhan tästä uutisoitu: https://www.theregister.com/2023/12/19/debian_to_drop_x86_32/

Anonyymi kirjoitti:

Onhan tästä uutisoitu: https://www.theregister.com/2023/12/19/debian_to_drop_x86_32/

Lue lisää

"Onhan tästä uutisoitu: https://www.theregister.com/2023/12/19/debian_to_drop_x86_32/"

niinpä on uutisoitu - mutta tuon kommentin kirjoittajalla on vaikeuksia luetun ymmärtämisessä!

Siis tuollahan nimenomaan todetaan, että vaikka uusissa Debian -versioissa jatkossa itse kernel on 64 -bittinen, niin sovellusohjelmien osalta tuki 32 -bittisille sovelluksille jatkuu.

"Jotenkin käsittämätöntä, että Freepascal + Lazarus -tiimi ei ole saanut aikaiseksi tämän ongelman korjaamista."

Mikä ihmeen Windows viesti? Miten tuo ongelma ilmenee Debianissa?

"Jotenkin käsittämätöntä, että Freepascal + Lazarus -tiimi ei ole saanut aikaiseksi tämän ongelman korjaamista."

Mistä tietää että jotain ongelmaa on olemassa? Jokin Windows viesti kuullostaa Windowsiin liittyvältä mutta Lazarus toimii alustariippumattomasti, joten siksi kysyn miten ongelma ilmenee Debianissa?

"Windowsin osalta voit myös kokeilla jotain muuta debuggeria, windowsillehan niitäkin löytyy, toisin kuin linuxille, sillä linuxiin ei oikein ole muuta kuin tuo surkea ja heikkolaatuinen gdb."

Höpöä. Erillaisia debuggereita löytyy monia eri kielille. Debuggeri ei myöskään ole missään nimessä pakollinen vaan sellaisia on myös tehty tarpeen mukaan.

Ennemminkin pitäisi ihmetellä miten paska työkalu on käytössä sovellusohjelmointiin jos on mahdollista tehdä bugi mikä ilmenee jonkun bittisyyden mukaan. Laitearkkitehtuuri abstraktoitiin ensimmäisenä pois eikä siitä ole tarvinnut välittää.

"Ilmaisversio on tarkoitettu kotikokeilijoille ja harrastuskäyttöön, ja siihen riittää hyvin se 32 -bittinen kääntäjä, sillä 32 -bittisen sovelluksen suurin puute 64-bittiseen sovellukseen verrattuna on juurikin rajoitettu muistiavaruus."

Lazaruksella olen tehnyt omaa softaa, softa toimii lähinnä käyttöliittymänä kehittelemilleni DLL-tiedostoille, hyvin toimii ja mitään ongelmia Windows -viesteistä ei ole kyllä ollut. Eikös nuo Windows-viestit ole näitä Win32APIn viestejä (PostMessage ym), joiden käsittely tuo LCL käärii sisäänsä, ei niistä softan kehittäjä tarvi huolehtia ja mikä ongelma noissa on, jos on?

Muistia kyllä kuluu isojen aineistojen käsittelyssä, helposti yli 20 gigaakin.

Delphi on liian kallis nykyään. Joskus Borlandin aikana Delphi oli vielä kohtuuhintainen tuote, esim Delphi Pro -versio.

- ap

Anonyymi kirjoitti:

Lazaruksella olen tehnyt omaa softaa, softa toimii lähinnä käyttöliittymänä kehittelemilleni DLL-tiedostoille, hyvin toimii ja mitään ongelmia Windows -viesteistä ei ole kyllä ollut. Eikös nuo Windows-viestit ole näitä Win32APIn viestejä (PostMessage ym), joiden käsittely tuo LCL käärii sisäänsä, ei niistä softan kehittäjä tarvi huolehtia ja mikä ongelma noissa on, jos on?

Muistia kyllä kuluu isojen aineistojen käsittelyssä, helposti yli 20 gigaakin.

Delphi on liian kallis nykyään. Joskus Borlandin aikana Delphi oli vielä kohtuuhintainen tuote, esim Delphi Pro -versio.

- ap

Lue lisää

Delphi 7 oli viimeinen missä oli järkeä, edellyttäen että kyse se ostettiin softalle jota oli hierottu 90-luvun puolivälissä tms. Delphi 7:lla sitä voitiin ylläpitää sillä välin kun uudelleenkirjoitettiin paremmille välineille.

Täyttä valetta ja asian tuntemus puuttuu kirjoittajalta kokonaan mutta pahantahtoisuutta on sitäkin enemän.

Vuoren varmasti ei osaa ohjelmoida mitään, typerää lässyttämistä ei maksa vaivaa lähteä oikomaan.

Anonyymi kirjoitti:

Täyttä valetta ja asian tuntemus puuttuu kirjoittajalta kokonaan mutta pahantahtoisuutta on sitäkin enemän.

Vuoren varmasti ei osaa ohjelmoida mitään, typerää lässyttämistä ei maksa vaivaa lähteä oikomaan.

Lue lisää

Ei puutu asiantuntemusta. Delphi 8 ja 2005 olivat heikkolaatuisia. Se vaikutti suuresti siihen miksi Delphi 7:aa käytettiin niin pitkään.

Lisäksi Delphissä oli vakava ongelma että sillä tehdyt eivät toimineet muualla kuin Windowsissa. Se ei oikein ollut 2000-lukua enää.

Nykyään on menty vielä pidemmälle että nykyään loppukäyttäjät välttävät sovellusten asentamista kun siitä tulee tarpeeton välivaihe käyttöönottoon, joutuu mietimään sen turvallisuutta, päivitystä yms. roskaa.

Anonyymi kirjoitti:

Ei puutu asiantuntemusta. Delphi 8 ja 2005 olivat heikkolaatuisia. Se vaikutti suuresti siihen miksi Delphi 7:aa käytettiin niin pitkään.

Lisäksi Delphissä oli vakava ongelma että sillä tehdyt eivät toimineet muualla kuin Windowsissa. Se ei oikein ollut 2000-lukua enää.

Nykyään on menty vielä pidemmälle että nykyään loppukäyttäjät välttävät sovellusten asentamista kun siitä tulee tarpeeton välivaihe käyttöönottoon, joutuu mietimään sen turvallisuutta, päivitystä yms. roskaa.

Lue lisää

höpö höpö jA HUOMMENNA LISÖÖ.

Anonyymi kirjoitti:

Ei puutu asiantuntemusta. Delphi 8 ja 2005 olivat heikkolaatuisia. Se vaikutti suuresti siihen miksi Delphi 7:aa käytettiin niin pitkään.

Lisäksi Delphissä oli vakava ongelma että sillä tehdyt eivät toimineet muualla kuin Windowsissa. Se ei oikein ollut 2000-lukua enää.

Nykyään on menty vielä pidemmälle että nykyään loppukäyttäjät välttävät sovellusten asentamista kun siitä tulee tarpeeton välivaihe käyttöönottoon, joutuu mietimään sen turvallisuutta, päivitystä yms. roskaa.

Lue lisää

Kyllä ite koodailin työkseni 2006-2011 asti vielä Delphi 2006 Pro versiolla, tuota ennen harrastuksena Delphi 6 ja vanhemmilla, aloitin Delphi 2 versiolla kun sen sai joskus ilmaiseksi lehden mukana tulleella CD-levyllä :)

Hyvin kelpasi tuo softa asiakkaille.

Voin olla vanhanaikainen, mutta itse kuulun siihen sukupolveen joka haluaa omistaa ostamansa softan, nuo joka kk-maksulliset "vuokra" softat on arseesta, kuten Adoben softat on nykyään. Lisäksi Adoben tekee asiakkaan luomalla datalla mitä tahtoo omaksi hyödykseen, kuten käyttää tekoälyn opetuksessa, teet periaatteessa Adobelle ilmaista työtä kun vuokraat ja käytät niiden softia.

- ap

Anonyymi kirjoitti:

Kyllä ite koodailin työkseni 2006-2011 asti vielä Delphi 2006 Pro versiolla, tuota ennen harrastuksena Delphi 6 ja vanhemmilla, aloitin Delphi 2 versiolla kun sen sai joskus ilmaiseksi lehden mukana tulleella CD-levyllä :)

Hyvin kelpasi tuo softa asiakkaille.

Voin olla vanhanaikainen, mutta itse kuulun siihen sukupolveen joka haluaa omistaa ostamansa softan, nuo joka kk-maksulliset "vuokra" softat on arseesta, kuten Adoben softat on nykyään. Lisäksi Adoben tekee asiakkaan luomalla datalla mitä tahtoo omaksi hyödykseen, kuten käyttää tekoälyn opetuksessa, teet periaatteessa Adobelle ilmaista työtä kun vuokraat ja käytät niiden softia.

- ap

Lue lisää

2006-2011 oli paljon parempiakin vaihtoehtoja.

Mulla oli Delphi 1-3 millä puuhastelin GUI:ta, samoin käytin Visual Basicia GUI:n.

Molemmissa oli täysin sama perusvika, että kytketty Win32 API:n mikä oli mätä. Samasta syystä kaikki sen aikaiset Delphi ja Visual Basic ohjelmat ovat kuolleet ja kuopattu tai sitten niiden ylläpito on työlästä kun kehittäjät ylläpitää rinnalla useita versioita. Siksi en näihin jäänyt roikkumaan.

Siksi sanoin että Delphi 7 oli oikein hyvä siihen, että jos oli jotain 1994-1999 kehitettyä Delphi softaa (aikana jolloin se oli ihan kelpo väline sen aikasella tekniikalla) niin sillähän sitä sai sitten ylläpidettyä vielä vuosia.

Mutta vanhat Delphi ohjelmat alkoi repeillä jo Windows Vistalla kun vähän käänsi DPI:tä tai koitti ajaa Applella tai Ubuntulla niin ei toiminut.

Softan ei ole pakko olla vuokrasofta mutta se pitäisi sitten olla tehty standardien mukaan että säilyy toimivana ja koodi ylläpidettävänä ja siltä osin miten standardia ei ole, pitäisi vähintäänkin hyödyntää teknologiaa joka on nimenomaisesti mietitty niin että pysyy ehjänä kun laitteet vaihtuu. Selain on käyttöliittymässä ollut ylivertaisesti paras tässä kun nykyiselläkin selaimella toimii 90-luvun puolivälin hötömölöt ja jollekin vanhalle Windows XP:llekin voi tuottaa ohjelman jokseenkin täysin nykyaikaisesti.

Selaimen pitää kuitenkin tehdä kyselyjä ja mistä ladata näkymä DOM:n niin vakaimpana pysyy ihan se matalin taso ilman mitään kirjastoriippuvuuksia. Tätä varten sopivia kieliä on Rust ja Go (jäljelle jää laitearkkitehtuuririippuvuus), tai sitten vaan kääntää ohjelman Dockeriin, tai vie raudan mukana.

Anonyymi kirjoitti:

2006-2011 oli paljon parempiakin vaihtoehtoja.

Mulla oli Delphi 1-3 millä puuhastelin GUI:ta, samoin käytin Visual Basicia GUI:n.

Molemmissa oli täysin sama perusvika, että kytketty Win32 API:n mikä oli mätä. Samasta syystä kaikki sen aikaiset Delphi ja Visual Basic ohjelmat ovat kuolleet ja kuopattu tai sitten niiden ylläpito on työlästä kun kehittäjät ylläpitää rinnalla useita versioita. Siksi en näihin jäänyt roikkumaan.

Siksi sanoin että Delphi 7 oli oikein hyvä siihen, että jos oli jotain 1994-1999 kehitettyä Delphi softaa (aikana jolloin se oli ihan kelpo väline sen aikasella tekniikalla) niin sillähän sitä sai sitten ylläpidettyä vielä vuosia.

Mutta vanhat Delphi ohjelmat alkoi repeillä jo Windows Vistalla kun vähän käänsi DPI:tä tai koitti ajaa Applella tai Ubuntulla niin ei toiminut.

Softan ei ole pakko olla vuokrasofta mutta se pitäisi sitten olla tehty standardien mukaan että säilyy toimivana ja koodi ylläpidettävänä ja siltä osin miten standardia ei ole, pitäisi vähintäänkin hyödyntää teknologiaa joka on nimenomaisesti mietitty niin että pysyy ehjänä kun laitteet vaihtuu. Selain on käyttöliittymässä ollut ylivertaisesti paras tässä kun nykyiselläkin selaimella toimii 90-luvun puolivälin hötömölöt ja jollekin vanhalle Windows XP:llekin voi tuottaa ohjelman jokseenkin täysin nykyaikaisesti.

Selaimen pitää kuitenkin tehdä kyselyjä ja mistä ladata näkymä DOM:n niin vakaimpana pysyy ihan se matalin taso ilman mitään kirjastoriippuvuuksia. Tätä varten sopivia kieliä on Rust ja Go (jäljelle jää laitearkkitehtuuririippuvuus), tai sitten vaan kääntää ohjelman Dockeriin, tai vie raudan mukana.

Lue lisää

Kyllähän ainakin Lazarus/LCL hanskaa aika hyvin tuon UI:n, olen tehnyt Lazaruksella apuohjelman, jolla työhommissa voi tiketeille merkata kertyneet työajat, yhteenvedot ja muistiinpanot. Työläppäri on MacBook Pro M3 + 32" 6K -näyttö ja toimii ok (HiDPI), samoin Windowsille käännettynä ja tavallinen 27" 1440p näyttö.

Eka kertaa käänsin softan Lazaruksella myös Macille ja olin jopa yllättynyt miten helposti projekti kääntyi myös Windowsille.

Olen pyrkinyt aina mahdollisimman pitkälle käyttämään näitä peruskomponentteja, mitä LCL on tarjolla.

- ap

Anonyymi kirjoitti:

2006-2011 oli paljon parempiakin vaihtoehtoja.

Mulla oli Delphi 1-3 millä puuhastelin GUI:ta, samoin käytin Visual Basicia GUI:n.

Molemmissa oli täysin sama perusvika, että kytketty Win32 API:n mikä oli mätä. Samasta syystä kaikki sen aikaiset Delphi ja Visual Basic ohjelmat ovat kuolleet ja kuopattu tai sitten niiden ylläpito on työlästä kun kehittäjät ylläpitää rinnalla useita versioita. Siksi en näihin jäänyt roikkumaan.

Siksi sanoin että Delphi 7 oli oikein hyvä siihen, että jos oli jotain 1994-1999 kehitettyä Delphi softaa (aikana jolloin se oli ihan kelpo väline sen aikasella tekniikalla) niin sillähän sitä sai sitten ylläpidettyä vielä vuosia.

Mutta vanhat Delphi ohjelmat alkoi repeillä jo Windows Vistalla kun vähän käänsi DPI:tä tai koitti ajaa Applella tai Ubuntulla niin ei toiminut.

Softan ei ole pakko olla vuokrasofta mutta se pitäisi sitten olla tehty standardien mukaan että säilyy toimivana ja koodi ylläpidettävänä ja siltä osin miten standardia ei ole, pitäisi vähintäänkin hyödyntää teknologiaa joka on nimenomaisesti mietitty niin että pysyy ehjänä kun laitteet vaihtuu. Selain on käyttöliittymässä ollut ylivertaisesti paras tässä kun nykyiselläkin selaimella toimii 90-luvun puolivälin hötömölöt ja jollekin vanhalle Windows XP:llekin voi tuottaa ohjelman jokseenkin täysin nykyaikaisesti.

Selaimen pitää kuitenkin tehdä kyselyjä ja mistä ladata näkymä DOM:n niin vakaimpana pysyy ihan se matalin taso ilman mitään kirjastoriippuvuuksia. Tätä varten sopivia kieliä on Rust ja Go (jäljelle jää laitearkkitehtuuririippuvuus), tai sitten vaan kääntää ohjelman Dockeriin, tai vie raudan mukana.

Lue lisää

Rust on sateenkaariväen softaa, ei niitä normiväki tarvi!!

Anonyymi kirjoitti:

Kyllähän ainakin Lazarus/LCL hanskaa aika hyvin tuon UI:n, olen tehnyt Lazaruksella apuohjelman, jolla työhommissa voi tiketeille merkata kertyneet työajat, yhteenvedot ja muistiinpanot. Työläppäri on MacBook Pro M3 32" 6K -näyttö ja toimii ok (HiDPI), samoin Windowsille käännettynä ja tavallinen 27" 1440p näyttö.

Eka kertaa käänsin softan Lazaruksella myös Macille ja olin jopa yllättynyt miten helposti projekti kääntyi myös Windowsille.

Olen pyrkinyt aina mahdollisimman pitkälle käyttämään näitä peruskomponentteja, mitä LCL on tarjolla.

- ap

Lue lisää

Lazarus on kyllä hurjasti kätevämpi tässä kuin vanha Delphi ja ollut tarkoituskin tuon suunnittelussa, että on paremmin siirrettävissä.

Vähän kömplelöä kyllä silti kun tarvitsee erikseen kääntää eri käyttöjärjestelmille.

Anonyymi kirjoitti:

Lazarus on kyllä hurjasti kätevämpi tässä kuin vanha Delphi ja ollut tarkoituskin tuon suunnittelussa, että on paremmin siirrettävissä.

Vähän kömplelöä kyllä silti kun tarvitsee erikseen kääntää eri käyttöjärjestelmille.

Lue lisää

"Vähän kömplelöä kyllä silti kun tarvitsee erikseen kääntää eri käyttöjärjestelmille."

Ei minusta, ei tuo ole kova homma kääntää eri järjestelmille, Macille en ole vielä kokeillut miten dmg-paketti tehdään, mutta Windowsille esim. Inno Setup on ihan kätevä softa tehdä asennuspaketti.

Toinen miksi Lazaruksesta tykkään UI:n teossa, koska inhoan JavaScriptia, (TypeScripti on vähän parempi) ja esim näitä Bootstrap, React ym. kirjastojen käyttöä, saameri kun nuo on niin ankeita, mitä töissä joutunut joskus säätämään =D

Kotisivun tein 2019 Angularilla ja sekin on jo hajoillut vähän uusimmilla selaimilla, kun en ole kerennyt/jaksanut päivittää sivua.

Lazaruksella kun tekee Windowsille softan, niin melkein on taattu että se toimii vuosia eteenpäin, käytän harrastuksessa eism. Delphillä (viimeisin versio vuonna 2011) tehtyä softaa ja edelleen pelittää hyvin Windows 11 Pro:ssa

Anonyymi kirjoitti:

"Vähän kömplelöä kyllä silti kun tarvitsee erikseen kääntää eri käyttöjärjestelmille."

Ei minusta, ei tuo ole kova homma kääntää eri järjestelmille, Macille en ole vielä kokeillut miten dmg-paketti tehdään, mutta Windowsille esim. Inno Setup on ihan kätevä softa tehdä asennuspaketti.

Toinen miksi Lazaruksesta tykkään UI:n teossa, koska inhoan JavaScriptia, (TypeScripti on vähän parempi) ja esim näitä Bootstrap, React ym. kirjastojen käyttöä, saameri kun nuo on niin ankeita, mitä töissä joutunut joskus säätämään =D

Kotisivun tein 2019 Angularilla ja sekin on jo hajoillut vähän uusimmilla selaimilla, kun en ole kerennyt/jaksanut päivittää sivua.

Lazaruksella kun tekee Windowsille softan, niin melkein on taattu että se toimii vuosia eteenpäin, käytän harrastuksessa eism. Delphillä (viimeisin versio vuonna 2011) tehtyä softaa ja edelleen pelittää hyvin Windows 11 Pro:ssa

Lue lisää

On se nysvää kun niitä järjestelmiä on:
-Android
-Debian
-iOS
-macOS
-Ubuntu
-Windows

Ja ehkä myös Red Hat Enterprise, Suse Enterprise ja Solaris jos haluaa näitä puhtaasti työkäyttöön tehtyjä tukea. Ja sitten älytelevisiot kun niilläkin voi käyttää sovelluksia.

Ja eri versioita myös kun on 32-bit, 64-bit ja käyttöjärjestelmien nykyinen ja edellinen versio, koska muutokset käyttöjärjestelmäversioiden välillä voivat vaikuttaa yhteensopivuuteen.

"Toinen miksi Lazaruksesta tykkään UI:n teossa"

Todella kömpelöä tehdä responsiivinen UI mikä toimii känny, tablet, läppäri ja iso näyttö.

"koska inhoan JavaScriptia"

Javascript oli kauhea silloin jQuery aikoina ja silloin oli parasta vain välttää Javascriptiä rajoittamalla käyttö yksittäisiin vuorovaikutteisiin komponentteihin joilla vältettiin sivulatauksia. Single page sovellukset jQueryllä sai unohtaa. Tämä malli toimi itseasiassa hyvin pitkään, johonkin vuoteen 2017 asti koska käytössä oli niin paljon vanhoja hitaita tai rajoittuneita kännyköitä, että käyttöliittymän näkymä oli parasta ladata palvelimelta sivulatauksilla.

AngularJS tuli 2010 ja se sopi vain läppäreille ja isoille näytöille silloin 2010-2015. Tämän vika oli hitaus mutta se oli ensimmäinen väline mikä mahdollisti laajojen sovellusten tekemisen Javascriptillä. Pakotettu dependency injection, Javascript prototypet, käytännöt ja testit olivat keino pitää koodi ehjänä kun Javascript oli ankea kieli.

Tällä sai myös merkittäviä etuja käyttöliitymän teossa, ei niinkään Angularin ansiosta vaan media queryt ja SVG olivat todella käteviä. Se ei ollut pelkästään vektorigrafiikan piirto ja skaalaus vaan myös niiden animointi ja käsittely, pystyi tekemään vaikka kosketusnäytöllisen sovelluksen millä kosketetaan vektorielementtiä.

Nämä kaikki korvautui Reactilla ja välineillä joista poistui konfigurointi. Tämä oli ensimmäinen malli millä saa kaikki laitteet katettua järkevästi samalla koodilla kun oli nopea ja vanhat kännykät poistuivat käytöstä. React + Redux oli vuonna 2015 oli kätevin tapa tehdä UI:ta ja tuo malli on vain parantunut kun 2018 lähtien Typescript tyypitykset olleet joka paikassa, ja Reduxin tarve poistui 2019.

Vuonna 2022 testailin create-react-app:n varaan rakentamaani Typescript sovellusta kääntää huvikseni Windows XP:lle säätämällä tässä olevia vipuja että kääntää vanhemmalle Javascriptille/selaimen toiminnoille. Sovellus toimi moitteettomasti Firefox 52:ssa vuoden 2001 käyttöjärjestelmällä. Oli pakko testata tuo kun luovuin tuollaisesta taaksepäinyhteensopivuuden mahdollistamisesta koska vuonna 2021 jälkeen ei ole ollut tarvetta. Joka paikassa on selain päivitettynä ja se on oletuksena aina uusin joten "pellin alla" olevat kirjastot ovat melkoisen paljon köykäisempiä nykyään.

Minulla ei ole koskaan selain UI mennyt rikki ajan kanssa, olen kylläkin aina tarkka sen kanssa että koodi noudattaa täysin standardeja, laadunvalvonnassa on validaattorit kiinni ja käytän vain toimintoja jotka ovat vakiintuneet kaikkiin selaimiin. 90-luvun puolivälin HTML toimii nykyäänkin. Jos UI menisi rikki se todennäköisesti olisi aikoinaan tehty bugi.

Reactin vahvuus nykyään on ekosysteemi, että löytyy ne komponenttikirjastot joilla saa halutun näköiseksi. Jos haluaa Spotifyn näköisen sovelluksen niin ottaa sen Bootstrapin, jos haluaa Applen näköisen sovelluksen niin ottaa UIKit, jos haluaa Microsoftin näköisen sovelluksen nin ottaa FluentUI:n, Googlen näköisen sovelluksen saa Materialilla, HP:n näköisen Grommetilla ja jne.

Jos visuaalinen muotokieli on mietitty niin sille voi tehdä komponenttikirjaston eikä välttämättä tarvitse mitään Reactia käyttää. Minusta React on tuntunut kuitenkin viimeiset 3v aika vanhanaikaiselta, tarpeettoman kompleksiselta ja jämähtäneeltä. Sillä nyt vaan saa helpoiten UI:n halutulle muotokielelle kun sille on valmiit kirjastot.

Lazarukselle ei taida olla Googlen Material UI:ta jos sovellusta käytetään ensisijaisesti ympäristössä missä Googlen softat.

Anonyymi kirjoitti:

"Jotenkin käsittämätöntä, että Freepascal Lazarus -tiimi ei ole saanut aikaiseksi tämän ongelman korjaamista."

Mikä ihmeen Windows viesti? Miten tuo ongelma ilmenee Debianissa?

"Jotenkin käsittämätöntä, että Freepascal Lazarus -tiimi ei ole saanut aikaiseksi tämän ongelman korjaamista."

Mistä tietää että jotain ongelmaa on olemassa? Jokin Windows viesti kuullostaa Windowsiin liittyvältä mutta Lazarus toimii alustariippumattomasti, joten siksi kysyn miten ongelma ilmenee Debianissa?

"Windowsin osalta voit myös kokeilla jotain muuta debuggeria, windowsillehan niitäkin löytyy, toisin kuin linuxille, sillä linuxiin ei oikein ole muuta kuin tuo surkea ja heikkolaatuinen gdb."

Höpöä. Erillaisia debuggereita löytyy monia eri kielille. Debuggeri ei myöskään ole missään nimessä pakollinen vaan sellaisia on myös tehty tarpeen mukaan.

Ennemminkin pitäisi ihmetellä miten paska työkalu on käytössä sovellusohjelmointiin jos on mahdollista tehdä bugi mikä ilmenee jonkun bittisyyden mukaan. Laitearkkitehtuuri abstraktoitiin ensimmäisenä pois eikä siitä ole tarvinnut välittää.

"Ilmaisversio on tarkoitettu kotikokeilijoille ja harrastuskäyttöön, ja siihen riittää hyvin se 32 -bittinen kääntäjä, sillä 32 -bittisen sovelluksen suurin puute 64-bittiseen sovellukseen verrattuna on juurikin rajoitettu muistiavaruus."

Lue lisää

"Mikä ihmeen Windows viesti? Miten tuo ongelma ilmenee Debianissa?"

Windows -viesti on esim. WM_Timer

Ja käsittääkseni Lazarus määrittelee vastaavan Linuxille:

LM_Timer

Ainakaan Freepascal / Lazarus -yhdistelmässä ei toimi oikein nämä:

AllocateHWnd

DeallocateHWnd

Molemmat on Delphissä dokumnetoitu.

Jos haluat tehdä oman luokan, jossa on :

FWindowHandle : HWND;

niin Delphissä luokan konstruktotissa (yleensä Create):

FWindowHandle := AllocateHWnd(...);

ja vastaavasti luokan destruktotissa (yleensä Destroy):

DeallocateHWnd(FWindowHandle );

Delphissä toimivat hienosti, mutta Freepascal / Lazarus -tiimi mölivät jotakin, niin ei vaan toimi.

Yllättävää on se, että kas kun formille Lazaruksessa pudotettu TTimer -komponentti toimii!

Kas kun se sisäisesti käyttää juurikin tuota toiminnallisuutta, jonka kanssa Freepascal / Lazarus -yhdistelmällä on ongelmia.

Mutta onhan Freepascal / Lazarus -yhdistelmässä muitakin haittapuolia, joiden kanssa aidon Delphin käyttäjä ei joudu tekemisiin:

1) huonosti toimiva / toimimaton (GDB -pohjainen) debuggeri: "The debugger has pulled the plug ..." - ja kun tuo ilmoitus ilmestyy - debuggerista tulee käyttökelvoton.

2) asennusohjelman jäljiltä yksi hakemistomäärite asetuksissa on väärin tai puuttuu.

3) AllocateHWnd ja DeallocateHWnd -toimimattomuus

Vastaavasti kuin WM_Timer (Windows) tai LM_Timer (Linux) - ihan sama idea on vaikkapa:

WM_LButtonDown (Windows) tai LM_LButtonDown (Linux).

Windowsin viestisysteemi on aina toiminut moitteettomasti - mutta Linuxin vastaava on epämääräinen, ja sen oikeasta toimivuudesta ei ole takeita.

Anonyymi kirjoitti:

2006-2011 oli paljon parempiakin vaihtoehtoja.

Mulla oli Delphi 1-3 millä puuhastelin GUI:ta, samoin käytin Visual Basicia GUI:n.

Molemmissa oli täysin sama perusvika, että kytketty Win32 API:n mikä oli mätä. Samasta syystä kaikki sen aikaiset Delphi ja Visual Basic ohjelmat ovat kuolleet ja kuopattu tai sitten niiden ylläpito on työlästä kun kehittäjät ylläpitää rinnalla useita versioita. Siksi en näihin jäänyt roikkumaan.

Siksi sanoin että Delphi 7 oli oikein hyvä siihen, että jos oli jotain 1994-1999 kehitettyä Delphi softaa (aikana jolloin se oli ihan kelpo väline sen aikasella tekniikalla) niin sillähän sitä sai sitten ylläpidettyä vielä vuosia.

Mutta vanhat Delphi ohjelmat alkoi repeillä jo Windows Vistalla kun vähän käänsi DPI:tä tai koitti ajaa Applella tai Ubuntulla niin ei toiminut.

Softan ei ole pakko olla vuokrasofta mutta se pitäisi sitten olla tehty standardien mukaan että säilyy toimivana ja koodi ylläpidettävänä ja siltä osin miten standardia ei ole, pitäisi vähintäänkin hyödyntää teknologiaa joka on nimenomaisesti mietitty niin että pysyy ehjänä kun laitteet vaihtuu. Selain on käyttöliittymässä ollut ylivertaisesti paras tässä kun nykyiselläkin selaimella toimii 90-luvun puolivälin hötömölöt ja jollekin vanhalle Windows XP:llekin voi tuottaa ohjelman jokseenkin täysin nykyaikaisesti.

Selaimen pitää kuitenkin tehdä kyselyjä ja mistä ladata näkymä DOM:n niin vakaimpana pysyy ihan se matalin taso ilman mitään kirjastoriippuvuuksia. Tätä varten sopivia kieliä on Rust ja Go (jäljelle jää laitearkkitehtuuririippuvuus), tai sitten vaan kääntää ohjelman Dockeriin, tai vie raudan mukana.

Lue lisää

Delphi7:lla tehty ohjelma toimii oikein asennettuna ainaki Windows 10:ssä ilman mitään ongelmia.

M-Kar puffaa selainpohjaisia ratkaisuja.

MUTTA:
selainpohjaiset ratkaisut tuhlaavat järjettömän isoja määriä muistia.

Eräs Delphi -ohjelma käyttää 3½ megatavua RAM -muistia (Windowsin tehtävänhallinnan mukaan)

Selain kuluttaa helposti yli 100 -kertaisen RAM -muistimäärän tuohon verrattuna jo yhdessä prosessissa. Ja kun nykyselaimet käynnistävät useita prosesseja, niin edes 1000 -kertainen RAM -muistimäärä (eli 3½ GIGAtavua RAM) ei selaimen kanssa riitä oikein yhtään mihinkään.

Selainpohjaiset systeemit on laitekauppiaan unelma:

asiakas on pakotettu ostamaan uuden tietokoneen ja siihen gigatavuittain RAM -muistia.

Omassa kannettavassani on 16 GT RAM, ja ilman selainta se riittäisi kaikkeen tarpeelliseen mainiosti.

Mutta kun käynnistää Web -selaimen, niin selain on jatkuvasti ongelmissa, kun RAM -muistin määrä ei vaan riitä!

Tuo selainpohjaisiin ratkaisuihin siirtyminen on typerintä, mitä tietotekniikassa on koskaan tehty. Varma resepti siihen, että mikään määrä RAM -muistia tietokoneessa ei ole ikinä tarpeeksi.

Anonyymi kirjoitti:

Delphi7:lla tehty ohjelma toimii oikein asennettuna ainaki Windows 10:ssä ilman mitään ongelmia.

M-Kar puffaa selainpohjaisia ratkaisuja.

MUTTA:
selainpohjaiset ratkaisut tuhlaavat järjettömän isoja määriä muistia.

Eräs Delphi -ohjelma käyttää 3½ megatavua RAM -muistia (Windowsin tehtävänhallinnan mukaan)

Selain kuluttaa helposti yli 100 -kertaisen RAM -muistimäärän tuohon verrattuna jo yhdessä prosessissa. Ja kun nykyselaimet käynnistävät useita prosesseja, niin edes 1000 -kertainen RAM -muistimäärä (eli 3½ GIGAtavua RAM) ei selaimen kanssa riitä oikein yhtään mihinkään.

Selainpohjaiset systeemit on laitekauppiaan unelma:

asiakas on pakotettu ostamaan uuden tietokoneen ja siihen gigatavuittain RAM -muistia.

Omassa kannettavassani on 16 GT RAM, ja ilman selainta se riittäisi kaikkeen tarpeelliseen mainiosti.

Mutta kun käynnistää Web -selaimen, niin selain on jatkuvasti ongelmissa, kun RAM -muistin määrä ei vaan riitä!

Tuo selainpohjaisiin ratkaisuihin siirtyminen on typerintä, mitä tietotekniikassa on koskaan tehty. Varma resepti siihen, että mikään määrä RAM -muistia tietokoneessa ei ole ikinä tarpeeksi.

Lue lisää

"Delphi7:lla tehty ohjelma toimii oikein asennettuna ainaki Windows 10:ssä ilman mitään ongelmia."

Ongelmat tuleekin 4K monitorin kanssa kun kääntää DPI asetuksen sopivaksi niin vanhoissa Delphiohjelmissa käyttöliittymä usein rikki. Vika tulee siitä jos käyttää WinAPI:a käyttöliittymään. WinForms vähän paransi tuota huononäköiset voi vähän nähdä paremmin suurentamalla FullHD näytöllä kuvaa mutta oikeasti asia saatiin kuntoon vasta selaimella ja WPF:llä, että skaalaus oikeasti toimii.

"selainpohjaiset ratkaisut tuhlaavat järjettömän isoja määriä muistia."

Ei tuhlaa.

Se että selainpohjainen ratkaisu vie paljon muistia tarkoittaa sitä, että sovellukseen on käännetty selain mukaan ja silloin muistia menee helposti paljon. Normaalisti selain on muistissa valmiina että sitä ei tarvitse joka sovellukselle erikseen, sen käyttämä muisti jaetaan, eikä muistia sitten mene juuri mitään. Kun selaimen on avannut ja avaamalla sinne uuden välilehden, muistinkulutus ei juuri nouse. Tämä on se tilanne selainpohjaisilla sovelluksilla.

Yleisesti ottaen selainta ei edes käytetä sovelluksiin joiden käyttöliittymä vie paljon muistia. Applen laitteissa on 384Mt raja mitä yksi selaimen välilehti voi syödä ilman että laite alkaa temppuilla joten selainsovellusten muistin kulutus on yleensä aina enintään tuo. Jos tarvitsee enemmän niin on jo järkeä miettiä muita ratkaisutapoja.

"Selainpohjaiset systeemit on laitekauppiaan unelma:"

Selainpohjaiset systeemit vähentävät tarvetta ostaa uusia laitteita koska vaikka sovelluksia laitteeseen ei päivitettäisi, selain yleensä päivittyy pidemmälle. Sitten vanhalla laitteella mistä päivitykset loppuneet aikaa sitten voi vielä ajaa uusia sovelluksia.

Tästä ei ole montaa kuukautta kun käänsin yhden täysin uuden selainsovelluksen kokeilun vuoksi toimimaan Windows XP:ssä jossa oli asennettu Firefox 52 ESR ja se meni heittämällä. Mieti sitä, 2001 vuoden käyttöjärjestelmässä voi ajaa uutta selainsovellusta jos niin haluaa. Koita kääntää Delphi 12 versiolla Windows XP:lle ja kerro miten meni.

"Omassa kannettavassani on 16 GT RAM, ja ilman selainta se riittäisi kaikkeen tarpeelliseen mainiosti."

Minulla on yksi vanha yksi kannettava missä 4Gt muistia ja riittää ihan hyvin.

"Mutta kun käynnistää Web -selaimen, niin selain on jatkuvasti ongelmissa, kun RAM -muistin määrä ei vaan riitä!"

Teet jotain väärin.

Anonyymi kirjoitti:

"Mikä ihmeen Windows viesti? Miten tuo ongelma ilmenee Debianissa?"

Windows -viesti on esim. WM_Timer

Ja käsittääkseni Lazarus määrittelee vastaavan Linuxille:

LM_Timer

Ainakaan Freepascal / Lazarus -yhdistelmässä ei toimi oikein nämä:

AllocateHWnd

DeallocateHWnd

Molemmat on Delphissä dokumnetoitu.

Jos haluat tehdä oman luokan, jossa on :

FWindowHandle : HWND;

niin Delphissä luokan konstruktotissa (yleensä Create):

FWindowHandle := AllocateHWnd(...);

ja vastaavasti luokan destruktotissa (yleensä Destroy):

DeallocateHWnd(FWindowHandle );

Delphissä toimivat hienosti, mutta Freepascal / Lazarus -tiimi mölivät jotakin, niin ei vaan toimi.

Yllättävää on se, että kas kun formille Lazaruksessa pudotettu TTimer -komponentti toimii!

Kas kun se sisäisesti käyttää juurikin tuota toiminnallisuutta, jonka kanssa Freepascal / Lazarus -yhdistelmällä on ongelmia.

Mutta onhan Freepascal / Lazarus -yhdistelmässä muitakin haittapuolia, joiden kanssa aidon Delphin käyttäjä ei joudu tekemisiin:

1) huonosti toimiva / toimimaton (GDB -pohjainen) debuggeri: "The debugger has pulled the plug ..." - ja kun tuo ilmoitus ilmestyy - debuggerista tulee käyttökelvoton.

2) asennusohjelman jäljiltä yksi hakemistomäärite asetuksissa on väärin tai puuttuu.

3) AllocateHWnd ja DeallocateHWnd -toimimattomuus

Vastaavasti kuin WM_Timer (Windows) tai LM_Timer (Linux) - ihan sama idea on vaikkapa:

WM_LButtonDown (Windows) tai LM_LButtonDown (Linux).

Windowsin viestisysteemi on aina toiminut moitteettomasti - mutta Linuxin vastaava on epämääräinen, ja sen oikeasta toimivuudesta ei ole takeita.

Lue lisää

"Windows -viesti on esim. WM_Timer"

Ei tuollainen kuulu Lazarukseen. Älä käytä.

"Ainakaan Freepascal / Lazarus -yhdistelmässä ei toimi oikein nämä: AllocateHWnd, DeallocateHWnd

"Molemmat on Delphissä dokumnetoitu."

Delphillä ei ole merkitystä. Jos tekee Lazaruksella niin käytetään Lazazuksen dokumentoimia asioita jotka tulee FreePascal kääntäjästä ja Lazaruksen rajapintadokumentaatioista.

Tämä on ohjelmistokehityksen perusasioita: ÄLÄ TEE TYPERIÄ RIIPPUVUUKSIA.

Rajoita riippuvuudet vain siihen FreePascaliin ja Lazaruksen LCL:n niin ei tule harmeja.

Tämä on myös ohjelmistoylläpidon perusteita. Eli kun siirtää legacy Delphi sovellusta Lazarukseen niin noudatetaan tätä prosessia:

1. Tunnista muutoskohdat
2. Etsi muutoskohdat
3. Riko riippuvuudet
4. Kirjoita testit
5. Tee muutokset ja refaktoroi

Eli tavoitteena juurikin on vähentää niitä riippuvuuksia, että vanha legackoodi toimisi puhtaasti FreePascal/LCL:n varassa ilman rönsyjä mihinkään sotkuihin. Sieltä pitäisi juurikin siivota pois WinAPI:n näköiset sotkut.

"Yllättävää on se, että kas kun formille Lazaruksessa pudotettu TTimer -komponentti toimii!"

Niin? Onko yllättävää että ohjelma toimii kuten on tarkoitettu? Se on ihan normaalia että ohjelmat toimivat.

Tässä tapauksessa voidaan tunnistaa muutoskohdaksi sinun koodistasi WM_Timer sotkut. Etsi ne, riko ne, kirjoita testit koodillesi missä testaat sovelluksen käyttäytymistä, muuta se koodi käyttämään TTimeria niin sitten on saatu siivottua sotku pois.

"Mutta onhan Freepascal / Lazarus -yhdistelmässä muitakin haittapuolia, joiden kanssa aidon Delphin käyttäjä ei joudu tekemisiin:"

Höpöhöpö. Kyllä tässä nyt paljastuu se että et osaa ohjelmoida. Perusteetkin hukassa.

"Windowsin viestisysteemi on aina toiminut moitteettomasti - mutta Linuxin vastaava on epämääräinen, ja sen oikeasta toimivuudesta ei ole takeita."

Epämääräistä on vain sinun ripulikoodisi. Et vaan osaa.

Anonyymi kirjoitti:

On se nysvää kun niitä järjestelmiä on:
-Android
-Debian
-iOS
-macOS
-Ubuntu
-Windows

Ja ehkä myös Red Hat Enterprise, Suse Enterprise ja Solaris jos haluaa näitä puhtaasti työkäyttöön tehtyjä tukea. Ja sitten älytelevisiot kun niilläkin voi käyttää sovelluksia.

Ja eri versioita myös kun on 32-bit, 64-bit ja käyttöjärjestelmien nykyinen ja edellinen versio, koska muutokset käyttöjärjestelmäversioiden välillä voivat vaikuttaa yhteensopivuuteen.

"Toinen miksi Lazaruksesta tykkään UI:n teossa"

Todella kömpelöä tehdä responsiivinen UI mikä toimii känny, tablet, läppäri ja iso näyttö.

"koska inhoan JavaScriptia"

Javascript oli kauhea silloin jQuery aikoina ja silloin oli parasta vain välttää Javascriptiä rajoittamalla käyttö yksittäisiin vuorovaikutteisiin komponentteihin joilla vältettiin sivulatauksia. Single page sovellukset jQueryllä sai unohtaa. Tämä malli toimi itseasiassa hyvin pitkään, johonkin vuoteen 2017 asti koska käytössä oli niin paljon vanhoja hitaita tai rajoittuneita kännyköitä, että käyttöliittymän näkymä oli parasta ladata palvelimelta sivulatauksilla.

AngularJS tuli 2010 ja se sopi vain läppäreille ja isoille näytöille silloin 2010-2015. Tämän vika oli hitaus mutta se oli ensimmäinen väline mikä mahdollisti laajojen sovellusten tekemisen Javascriptillä. Pakotettu dependency injection, Javascript prototypet, käytännöt ja testit olivat keino pitää koodi ehjänä kun Javascript oli ankea kieli.

Tällä sai myös merkittäviä etuja käyttöliitymän teossa, ei niinkään Angularin ansiosta vaan media queryt ja SVG olivat todella käteviä. Se ei ollut pelkästään vektorigrafiikan piirto ja skaalaus vaan myös niiden animointi ja käsittely, pystyi tekemään vaikka kosketusnäytöllisen sovelluksen millä kosketetaan vektorielementtiä.

Nämä kaikki korvautui Reactilla ja välineillä joista poistui konfigurointi. Tämä oli ensimmäinen malli millä saa kaikki laitteet katettua järkevästi samalla koodilla kun oli nopea ja vanhat kännykät poistuivat käytöstä. React Redux oli vuonna 2015 oli kätevin tapa tehdä UI:ta ja tuo malli on vain parantunut kun 2018 lähtien Typescript tyypitykset olleet joka paikassa, ja Reduxin tarve poistui 2019.

Vuonna 2022 testailin create-react-app:n varaan rakentamaani Typescript sovellusta kääntää huvikseni Windows XP:lle säätämällä tässä olevia vipuja että kääntää vanhemmalle Javascriptille/selaimen toiminnoille. Sovellus toimi moitteettomasti Firefox 52:ssa vuoden 2001 käyttöjärjestelmällä. Oli pakko testata tuo kun luovuin tuollaisesta taaksepäinyhteensopivuuden mahdollistamisesta koska vuonna 2021 jälkeen ei ole ollut tarvetta. Joka paikassa on selain päivitettynä ja se on oletuksena aina uusin joten "pellin alla" olevat kirjastot ovat melkoisen paljon köykäisempiä nykyään.

Minulla ei ole koskaan selain UI mennyt rikki ajan kanssa, olen kylläkin aina tarkka sen kanssa että koodi noudattaa täysin standardeja, laadunvalvonnassa on validaattorit kiinni ja käytän vain toimintoja jotka ovat vakiintuneet kaikkiin selaimiin. 90-luvun puolivälin HTML toimii nykyäänkin. Jos UI menisi rikki se todennäköisesti olisi aikoinaan tehty bugi.

Reactin vahvuus nykyään on ekosysteemi, että löytyy ne komponenttikirjastot joilla saa halutun näköiseksi. Jos haluaa Spotifyn näköisen sovelluksen niin ottaa sen Bootstrapin, jos haluaa Applen näköisen sovelluksen niin ottaa UIKit, jos haluaa Microsoftin näköisen sovelluksen nin ottaa FluentUI:n, Googlen näköisen sovelluksen saa Materialilla, HP:n näköisen Grommetilla ja jne.

Jos visuaalinen muotokieli on mietitty niin sille voi tehdä komponenttikirjaston eikä välttämättä tarvitse mitään Reactia käyttää. Minusta React on tuntunut kuitenkin viimeiset 3v aika vanhanaikaiselta, tarpeettoman kompleksiselta ja jämähtäneeltä. Sillä nyt vaan saa helpoiten UI:n halutulle muotokielelle kun sille on valmiit kirjastot.

Lazarukselle ei taida olla Googlen Material UI:ta jos sovellusta käytetään ensisijaisesti ympäristössä missä Googlen softat.

Lue lisää

M-Kar jaksaa puffata "kaikki selaimessa toimivaksi" -politiikkaa.

Mutta:

Vivaldi -selaimen Windows 10:ssä toimivassa versiossa lopultakin on ominaisuus, jolla näkee kunkin Web -sivun aiheuttaman RAM -muistin kulutuksen.

Ja nyky -web -sivuissa se kulutus on pienimmilläänkin noin 22 megatavua per web -sivu.
Monella monimutkaisella Web sivulla se kulutus on siis useita satoja megatavuja per web -sivu.

Kun on tehty Delphi7:lla EXE -tyyppinen ohjelma, niin Windows tehtävänhallinnan mukaan se kuluttaa 3½ megatavua RAM -muistia.

Siis yksinkertainen mutta nykyaikainen Web -sivu kuluttaa selaimessa RAM -muistia yli 6 -kertaisen määrän verrattuna Delphi 7:lla tehtyyn EXE -ohjelmaan.

Selaintekniikka siis moninkertaistaa muistinkulutuksen.

M-Kar jaksaa myös jauhaa siitä, että jos 32 -bittistä ohjelmaa ajetaan 64 -bittisessä käyttöjärjestelmässä, niin tällöin käyttöjärjestelmä lataa tietyt lisäkirjastot jotta myös 32-bittiset ohjelmat saadaan ajettua. Tämä on sinänäsä totta, mutta toisin, kuin M-Kar väittää, niin näiden lisäkirjastojen aiheuttama muistinkulutus on mitättömän pieni, ainakin edes yksinkertaiseenkaan nykyaikaiseen Web -sivuun verrattuna.

Anonyymi kirjoitti:

M-Kar jaksaa puffata "kaikki selaimessa toimivaksi" -politiikkaa.

Mutta:

Vivaldi -selaimen Windows 10:ssä toimivassa versiossa lopultakin on ominaisuus, jolla näkee kunkin Web -sivun aiheuttaman RAM -muistin kulutuksen.

Ja nyky -web -sivuissa se kulutus on pienimmilläänkin noin 22 megatavua per web -sivu.
Monella monimutkaisella Web sivulla se kulutus on siis useita satoja megatavuja per web -sivu.

Kun on tehty Delphi7:lla EXE -tyyppinen ohjelma, niin Windows tehtävänhallinnan mukaan se kuluttaa 3½ megatavua RAM -muistia.

Siis yksinkertainen mutta nykyaikainen Web -sivu kuluttaa selaimessa RAM -muistia yli 6 -kertaisen määrän verrattuna Delphi 7:lla tehtyyn EXE -ohjelmaan.

Selaintekniikka siis moninkertaistaa muistinkulutuksen.

M-Kar jaksaa myös jauhaa siitä, että jos 32 -bittistä ohjelmaa ajetaan 64 -bittisessä käyttöjärjestelmässä, niin tällöin käyttöjärjestelmä lataa tietyt lisäkirjastot jotta myös 32-bittiset ohjelmat saadaan ajettua. Tämä on sinänäsä totta, mutta toisin, kuin M-Kar väittää, niin näiden lisäkirjastojen aiheuttama muistinkulutus on mitättömän pieni, ainakin edes yksinkertaiseenkaan nykyaikaiseen Web -sivuun verrattuna.

Lue lisää

"Monella monimutkaisella Web sivulla se kulutus on siis useita satoja megatavuja per web -sivu."

384 megaa on käytännön maksimi, koska ei toimi muuten iOS:ssa.

"Siis yksinkertainen mutta nykyaikainen Web -sivu kuluttaa selaimessa RAM -muistia yli 6 -kertaisen määrän verrattuna Delphi 7:lla tehtyyn EXE -ohjelmaan."

Raspberry Pi:ssä on 8 gigaa muistia joten sinne mahtuu 22-384 megaa auki monta kertaa. Mutta Delphi 7 ei käännä ohjelmaa Raspberry Pi:lle jossa sitä muistia on niukemmin, joten siitä ei ole mitään hyötyä.

"Tämä on sinänäsä totta, mutta toisin, kuin M-Kar väittää, niin näiden lisäkirjastojen aiheuttama muistinkulutus on mitättömän pieni, ainakin edes yksinkertaiseenkaan nykyaikaiseen Web -sivuun verrattuna."

Tarvitsee ajaa kaikki runtime kirjastot 32-bittisenä mistä se on riippuvainen, eli käytännössä menee helposti satoja megoja. Ne tosin ladataan muistiin vain kerran 32-bittisiä ohjelmia varten mutta niitä ei tietenkään ole kuluttamassa jos ei ole yhtään vanhaa koodia.

16 -bittisiä Windows -ohjemia tehdään, jos on jokin tarve saada se ohjelma toimimaan ikivanhassa Windows 3.1 tai 3.11 -versiossa.

Muuten ei kukaan nykyään tee 16 -bittisiä sovelluksia.

64 -bittinen windows ei edes tue 16 -bittisiä sovelluksia, mutta tukee kyllä edelleenkin 32 -bittisiä sovelluksia.

Anonyymi kirjoitti:

16 -bittisiä Windows -ohjemia tehdään, jos on jokin tarve saada se ohjelma toimimaan ikivanhassa Windows 3.1 tai 3.11 -versiossa.

Muuten ei kukaan nykyään tee 16 -bittisiä sovelluksia.

64 -bittinen windows ei edes tue 16 -bittisiä sovelluksia, mutta tukee kyllä edelleenkin 32 -bittisiä sovelluksia.

Lue lisää

16-bittisiä ja 32-bittisiä ohjelmia tehdään vain johonkin mikrokontrollereihin. Joka paikkaan muualle ohjelma pyörii tulkattuna tai tavukoodina, tai sitten on käännetty natiivisti 64-bittiseksi.