Miksi Chromium OS pitää tehdä jollain Portagella? Miksi ei käytetä jotain normaalia helppoa tapaa?

"vain 64 -bittinen versio on ilmainen, 32-bittisestä versiosta pitää maksaa !"

Ei siitä mitään tarvitse maksaa. Olen käyttänyt OpenSSL:ää aikoinaan 32-bittisenä maksamatta.

"Kun suositellaan ActivePerliä, ja siitä 32 -bittisen version saa vain maksamalla!"

ActivePerl on vain jokin paketointi uusimmalle versiolle, ei sitä tarvitse kun voi käyttää sitä käyttöjärjestelmän vakio perliä millä se on muutenkin käännetty.

"Ilmeisesti OpenSSL:ää ei ole koodattu C:llä, vaan jollain käsittämättömällä pseudokielellä, jonka Perl -skripti muuntaa C-kielelle ja syöttää muunnoksen lopputuloksen C -kääntäjälle."

Vilkaisin lähdekoodeja. Ihan normaalilta C:ltä näytti mutta siellä on myös perlillä kirjoitettuja osia.

Siinähän ei ole mitään tavatonta, että ohjelmien teossa on käytetty useita kieliä.

Anonyymi kirjoitti:

"vain 64 -bittinen versio on ilmainen, 32-bittisestä versiosta pitää maksaa !"

Ei siitä mitään tarvitse maksaa. Olen käyttänyt OpenSSL:ää aikoinaan 32-bittisenä maksamatta.

"Kun suositellaan ActivePerliä, ja siitä 32 -bittisen version saa vain maksamalla!"

ActivePerl on vain jokin paketointi uusimmalle versiolle, ei sitä tarvitse kun voi käyttää sitä käyttöjärjestelmän vakio perliä millä se on muutenkin käännetty.

"Ilmeisesti OpenSSL:ää ei ole koodattu C:llä, vaan jollain käsittämättömällä pseudokielellä, jonka Perl -skripti muuntaa C-kielelle ja syöttää muunnoksen lopputuloksen C -kääntäjälle."

Vilkaisin lähdekoodeja. Ihan normaalilta C:ltä näytti mutta siellä on myös perlillä kirjoitettuja osia.

Siinähän ei ole mitään tavatonta, että ohjelmien teossa on käytetty useita kieliä.

Lue lisää

"ActivePerl on vain jokin paketointi uusimmalle versiolle, ei sitä tarvitse kun voi käyttää sitä käyttöjärjestelmän vakio perliä millä se on muutenkin käännetty."

Windowsissa EI OLE OLEMASSA mitään "käyttöjärjestelmän vakio perliä".

Kas kun Windowsissa ei ole PERLiä, ellei sitä siihen itse asenna.

JA tosiaan OpenSSL:n tekijät kehottavat käyttämään Activestate Perliä, ja siitä 64-bittinen versio on ilmainen, mutta 32 -bittisestä versiosta pitää maksaa, ei sitä ilmaiseksi saa.

Strawberry Perlistä saa ilmeisesti molemmat sekä 32- että 64 -bittiset versiot ilmaiseksi, mutta ilmeisesti OpenSSL:n Perl -pohjainen kääntämisjärjestelmä on tehty niin, ettei se toimi Strawberry Perlillä kunnolla / ollenkaan.

Joskus yritin, mutta sen jäljiltä .c -tiedostoissa on syntaktisesti kelvotonta C -kieltä muistuttavaa kieltä, joka ei kuitenkaan C -kääntäjälle kelpaa, vaan C -kääntäjä antaa kasan virheilmoituksia (mingw -gcc 32-bit versio).

Ilmeisesti OpenSSL varsinainen lähdekoodi on joko C -kieltä tai jotain sellaista kieltä, jonka tuo Perl -skriptin olisi tarkoitus muokata C -kääntäjälle kelpaavaan muotoon, mutta windowsissa 32-bit Strawberry Perliä käyttämällä lopputulos on se, ettei mingw-gcc hyväksy kääntöjärjestelmän sille syöttämää C -kieltä (tai jotakin C -kieltä muistuttavaa kieltä, jota kääntäjä ei kuitenkaan kelpuuta).

Juuri tuon takia inhoan noita kääntöjärjestelmiä kun niiden kanssa on, jos ei nyt aina, niin ainakin hyvin usein ongelmia.

Miksei voida tehdä näin:

kaanna.bat:

gcc -c moduli1.c
gcc -c moduli2.c
gcc -c moduli3.c
gcc -c moduli4.c
gcc -c paaohjelma.c
gcc -c libkirjasto.c
gcc moduli1.o moduli2.o moduli3.o moduli4.o paaohjelma.o -o ohjelma.exe
gcc -static -shared moduli1.o moduli2.o moduli3.o moduli4.o libkirjasto.o -o libkirjasto.dll

viimeisellä rivillä tuo -static on siksi, että silloin riittää, kun tuon DLL:n kopioi kohdekoneelle, eikä kohdekoneella tarvita muuta kuin se ohjelma, joka tuota libkirjasto.dll haluaa käyttää sekä se, minkä Microsoftin windowsin asennusohjelma tyhjälle koneelle asentaa, ei MITÄÄN muuta !

Ilman tuota -static -valitsinta ohjelmaa ei saa käyntiin, kun valittaa tuon libkirjasto.dll:n tarvitsemista lukuisista muista DLL:stä, joita ei kohdekoneella ole.

Tuollainen "kääntöjärjestelmä" olisi se paras.

Joo, perus windowsin cmd.exe ei toki ole paras tuollaisen BAT -tiedoston sellaisenaan ajamiseen, mutta perusperiaate on siinä selkein mahdollinen.

voisihan siellä olla:

kaanna_dummy.BAT

ja

kaanna_smart.BAT

joista tuo jälkimmäinen olisi muuten sama, mutta jokaisen gcc -komentorivin jälkeen olisi:

if ERRORLEVEL 2 goto VIRHE

ja jossain tuossa BAT -tiedostossa:

:VIRHE
echo Tapahtui käännösvirhe. Kääntämisketju lopetettu.
goto LOPPU

:LOPPU
rem viimeinen BAT -tiedoston rivi.

eli jotain tuon tapaista, eli muuten sama kuin aiempi, mutta jos gcc palauttaa virhekoodin, kääntäminen ja linkkaaminen seuraavien vaiheiden osalta lopetetaan.

Anonyymi kirjoitti:

"ActivePerl on vain jokin paketointi uusimmalle versiolle, ei sitä tarvitse kun voi käyttää sitä käyttöjärjestelmän vakio perliä millä se on muutenkin käännetty."

Windowsissa EI OLE OLEMASSA mitään "käyttöjärjestelmän vakio perliä".

Kas kun Windowsissa ei ole PERLiä, ellei sitä siihen itse asenna.

JA tosiaan OpenSSL:n tekijät kehottavat käyttämään Activestate Perliä, ja siitä 64-bittinen versio on ilmainen, mutta 32 -bittisestä versiosta pitää maksaa, ei sitä ilmaiseksi saa.

Strawberry Perlistä saa ilmeisesti molemmat sekä 32- että 64 -bittiset versiot ilmaiseksi, mutta ilmeisesti OpenSSL:n Perl -pohjainen kääntämisjärjestelmä on tehty niin, ettei se toimi Strawberry Perlillä kunnolla / ollenkaan.

Joskus yritin, mutta sen jäljiltä .c -tiedostoissa on syntaktisesti kelvotonta C -kieltä muistuttavaa kieltä, joka ei kuitenkaan C -kääntäjälle kelpaa, vaan C -kääntäjä antaa kasan virheilmoituksia (mingw -gcc 32-bit versio).

Ilmeisesti OpenSSL varsinainen lähdekoodi on joko C -kieltä tai jotain sellaista kieltä, jonka tuo Perl -skriptin olisi tarkoitus muokata C -kääntäjälle kelpaavaan muotoon, mutta windowsissa 32-bit Strawberry Perliä käyttämällä lopputulos on se, ettei mingw-gcc hyväksy kääntöjärjestelmän sille syöttämää C -kieltä (tai jotakin C -kieltä muistuttavaa kieltä, jota kääntäjä ei kuitenkaan kelpuuta).

Juuri tuon takia inhoan noita kääntöjärjestelmiä kun niiden kanssa on, jos ei nyt aina, niin ainakin hyvin usein ongelmia.

Miksei voida tehdä näin:

kaanna.bat:

gcc -c moduli1.c
gcc -c moduli2.c
gcc -c moduli3.c
gcc -c moduli4.c
gcc -c paaohjelma.c
gcc -c libkirjasto.c
gcc moduli1.o moduli2.o moduli3.o moduli4.o paaohjelma.o -o ohjelma.exe
gcc -static -shared moduli1.o moduli2.o moduli3.o moduli4.o libkirjasto.o -o libkirjasto.dll

viimeisellä rivillä tuo -static on siksi, että silloin riittää, kun tuon DLL:n kopioi kohdekoneelle, eikä kohdekoneella tarvita muuta kuin se ohjelma, joka tuota libkirjasto.dll haluaa käyttää sekä se, minkä Microsoftin windowsin asennusohjelma tyhjälle koneelle asentaa, ei MITÄÄN muuta !

Ilman tuota -static -valitsinta ohjelmaa ei saa käyntiin, kun valittaa tuon libkirjasto.dll:n tarvitsemista lukuisista muista DLL:stä, joita ei kohdekoneella ole.

Tuollainen "kääntöjärjestelmä" olisi se paras.

Joo, perus windowsin cmd.exe ei toki ole paras tuollaisen BAT -tiedoston sellaisenaan ajamiseen, mutta perusperiaate on siinä selkein mahdollinen.

voisihan siellä olla:

kaanna_dummy.BAT

ja

kaanna_smart.BAT

joista tuo jälkimmäinen olisi muuten sama, mutta jokaisen gcc -komentorivin jälkeen olisi:

if ERRORLEVEL 2 goto VIRHE

ja jossain tuossa BAT -tiedostossa:

:VIRHE
echo Tapahtui käännösvirhe. Kääntämisketju lopetettu.
goto LOPPU

:LOPPU
rem viimeinen BAT -tiedoston rivi.

eli jotain tuon tapaista, eli muuten sama kuin aiempi, mutta jos gcc palauttaa virhekoodin, kääntäminen ja linkkaaminen seuraavien vaiheiden osalta lopetetaan.

Lue lisää

"Windowsissa EI OLE OLEMASSA mitään "käyttöjärjestelmän vakio perliä"."

No älä käytä sitten sitä Windowsia.

Ei sitä OpenSSL:ää ole tarkoitettu muuhun kuin käyttöjärjestelmän peruspalikoihin ja Microsoft on ihan itse käännellyt ja integroinut SSL toiminnallisuuden valmiiksi että onnistuu SSL yhteys vaikka Edge selaimella tai .NET Corella. Jos haluaa itse käyttää ja muokata sitä jossain niin valitaan työkalut sen mukaan eikä mitään Windowsia, kun ei sitä Windowsia ole sellaiseen tarkoitettu.

"Juuri tuon takia inhoan noita kääntöjärjestelmiä kun niiden kanssa on, jos ei nyt aina, niin ainakin hyvin usein ongelmia."

Ei minulla vaan ole mitään ongelmia. Ihan normaalia parsimista mitä tehty tietokoneilla jotain 50 vuotta.

"ja jossain tuossa BAT -tiedostossa:"

Ei tietokoneohjelmia tehdessä käytetä mitään BAT -tiedostoja. Nehän ovat jotain DOS-aikaista kuraa.

POSIX standardi määrittelee shellin miten komentoja laitetaan, eli käytännössä Bourne shell -yhteensopiva komentotulkki pitää olla.

Sen lisäksi unohdat kääntämisestä sen, että kun kehitetään ohjelmaa niin ei nyt helvetissä haluta kääntää miljoonaa riviä koodia kun tekee vaikka pienen muutoksen. Make toimii niin, että se käännetään vain muuttuneet kohdat uudestaan niin kehittäminen on hurjasti nopeampaa. Make on aina tehty toimimaan POSIX -yhteensopivan komentotulkin kanssa, 70-luvulta saakka.

Ongelmasi taitaa olla se, että yrität käyttää Windowsia sellaiseen mihin Windowsia ei ole tarkoitettu. Windows on tarkoitettu sovellusten käyttöliittymiä varten ja siihen on sitä varten työkalut.

Anonyymi kirjoitti:

"Windowsissa EI OLE OLEMASSA mitään "käyttöjärjestelmän vakio perliä"."

No älä käytä sitten sitä Windowsia.

Ei sitä OpenSSL:ää ole tarkoitettu muuhun kuin käyttöjärjestelmän peruspalikoihin ja Microsoft on ihan itse käännellyt ja integroinut SSL toiminnallisuuden valmiiksi että onnistuu SSL yhteys vaikka Edge selaimella tai .NET Corella. Jos haluaa itse käyttää ja muokata sitä jossain niin valitaan työkalut sen mukaan eikä mitään Windowsia, kun ei sitä Windowsia ole sellaiseen tarkoitettu.

"Juuri tuon takia inhoan noita kääntöjärjestelmiä kun niiden kanssa on, jos ei nyt aina, niin ainakin hyvin usein ongelmia."

Ei minulla vaan ole mitään ongelmia. Ihan normaalia parsimista mitä tehty tietokoneilla jotain 50 vuotta.

"ja jossain tuossa BAT -tiedostossa:"

Ei tietokoneohjelmia tehdessä käytetä mitään BAT -tiedostoja. Nehän ovat jotain DOS-aikaista kuraa.

POSIX standardi määrittelee shellin miten komentoja laitetaan, eli käytännössä Bourne shell -yhteensopiva komentotulkki pitää olla.

Sen lisäksi unohdat kääntämisestä sen, että kun kehitetään ohjelmaa niin ei nyt helvetissä haluta kääntää miljoonaa riviä koodia kun tekee vaikka pienen muutoksen. Make toimii niin, että se käännetään vain muuttuneet kohdat uudestaan niin kehittäminen on hurjasti nopeampaa. Make on aina tehty toimimaan POSIX -yhteensopivan komentotulkin kanssa, 70-luvulta saakka.

Ongelmasi taitaa olla se, että yrität käyttää Windowsia sellaiseen mihin Windowsia ei ole tarkoitettu. Windows on tarkoitettu sovellusten käyttöliittymiä varten ja siihen on sitä varten työkalut.

Lue lisää

Ja jos Edge ei riitä SSL yhteyksiä varten on sitä myös se Electron keksitty: https://www.electronjs.org/

Anonyymi kirjoitti:

"ActivePerl on vain jokin paketointi uusimmalle versiolle, ei sitä tarvitse kun voi käyttää sitä käyttöjärjestelmän vakio perliä millä se on muutenkin käännetty."

Windowsissa EI OLE OLEMASSA mitään "käyttöjärjestelmän vakio perliä".

Kas kun Windowsissa ei ole PERLiä, ellei sitä siihen itse asenna.

JA tosiaan OpenSSL:n tekijät kehottavat käyttämään Activestate Perliä, ja siitä 64-bittinen versio on ilmainen, mutta 32 -bittisestä versiosta pitää maksaa, ei sitä ilmaiseksi saa.

Strawberry Perlistä saa ilmeisesti molemmat sekä 32- että 64 -bittiset versiot ilmaiseksi, mutta ilmeisesti OpenSSL:n Perl -pohjainen kääntämisjärjestelmä on tehty niin, ettei se toimi Strawberry Perlillä kunnolla / ollenkaan.

Joskus yritin, mutta sen jäljiltä .c -tiedostoissa on syntaktisesti kelvotonta C -kieltä muistuttavaa kieltä, joka ei kuitenkaan C -kääntäjälle kelpaa, vaan C -kääntäjä antaa kasan virheilmoituksia (mingw -gcc 32-bit versio).

Ilmeisesti OpenSSL varsinainen lähdekoodi on joko C -kieltä tai jotain sellaista kieltä, jonka tuo Perl -skriptin olisi tarkoitus muokata C -kääntäjälle kelpaavaan muotoon, mutta windowsissa 32-bit Strawberry Perliä käyttämällä lopputulos on se, ettei mingw-gcc hyväksy kääntöjärjestelmän sille syöttämää C -kieltä (tai jotakin C -kieltä muistuttavaa kieltä, jota kääntäjä ei kuitenkaan kelpuuta).

Juuri tuon takia inhoan noita kääntöjärjestelmiä kun niiden kanssa on, jos ei nyt aina, niin ainakin hyvin usein ongelmia.

Miksei voida tehdä näin:

kaanna.bat:

gcc -c moduli1.c
gcc -c moduli2.c
gcc -c moduli3.c
gcc -c moduli4.c
gcc -c paaohjelma.c
gcc -c libkirjasto.c
gcc moduli1.o moduli2.o moduli3.o moduli4.o paaohjelma.o -o ohjelma.exe
gcc -static -shared moduli1.o moduli2.o moduli3.o moduli4.o libkirjasto.o -o libkirjasto.dll

viimeisellä rivillä tuo -static on siksi, että silloin riittää, kun tuon DLL:n kopioi kohdekoneelle, eikä kohdekoneella tarvita muuta kuin se ohjelma, joka tuota libkirjasto.dll haluaa käyttää sekä se, minkä Microsoftin windowsin asennusohjelma tyhjälle koneelle asentaa, ei MITÄÄN muuta !

Ilman tuota -static -valitsinta ohjelmaa ei saa käyntiin, kun valittaa tuon libkirjasto.dll:n tarvitsemista lukuisista muista DLL:stä, joita ei kohdekoneella ole.

Tuollainen "kääntöjärjestelmä" olisi se paras.

Joo, perus windowsin cmd.exe ei toki ole paras tuollaisen BAT -tiedoston sellaisenaan ajamiseen, mutta perusperiaate on siinä selkein mahdollinen.

voisihan siellä olla:

kaanna_dummy.BAT

ja

kaanna_smart.BAT

joista tuo jälkimmäinen olisi muuten sama, mutta jokaisen gcc -komentorivin jälkeen olisi:

if ERRORLEVEL 2 goto VIRHE

ja jossain tuossa BAT -tiedostossa:

:VIRHE
echo Tapahtui käännösvirhe. Kääntämisketju lopetettu.
goto LOPPU

:LOPPU
rem viimeinen BAT -tiedoston rivi.

eli jotain tuon tapaista, eli muuten sama kuin aiempi, mutta jos gcc palauttaa virhekoodin, kääntäminen ja linkkaaminen seuraavien vaiheiden osalta lopetetaan.

Lue lisää

Ongelmasi tuntuu olevan se että et tunnu käsittävän IT-alan standardeja.

Aivan keskeisiä standardit ovat
-merkistöstandardit (UTF-8, Unicode)
-verkkoprotokolla standardit (TCP/IP, SMTP, HTTP jne.)

Sitten kun puhutaan noista komentorivityökaluista, C-kielestä ja palvelimista niin sillä alueella standardointi on se POSIX. POSIX standardoinnista tuli myöhemmin LSB standardointi superset joka standardoi enemmän kirjastoja mutta kun viime vuosikymmenellä käyttöjärjestelmätason virtualisoi jyräsi niin tuli defacto standardiksi Linux, ja sen päällä olevissa virtuaalikoneissa sitten voi varsin vapaasti olla mitä tahansa kunhan ne ovat ulos päin verkkoprotokolla standardien mukaisia.

Virtuaalikoneessa oleva service on siis palvelintason ohjelmakomponentti.

Käyttöliittymäpuolella sitten on HTML, DOM, CSS ja Ecmascript standardit, ja serialisoinnissa sitten on JSON ja XML.

Ohjelmointikielillä on myös standardeja, tärkeimpänä Ecmascript, mutta muuten merkitsevät vähemmän. Standardointi auttaa siinä että on vakautta niissä työkaluissa.

Kun ymmärtää mitä IT-alalla on standardoitu, ymmärtää sen että Windowsissa ajetaan käyttöliittymiä ja se lähdekoodi ensisijaisesti on siinä Edgessä. Voi myös tehdä Electronilla sovelluksen jos se ei syystä tai toisesta riitä, tai sitten voi tehdä natiivisovelluksen. Natiivisovellus ei ihan ole niin yhteensopiva, menee helpommin rikki ja senkin pitäisi sitten käyttää näitä standardeja UTF-8, HTTP, SMTP, JSON, XML jne. muotoja.

Mitä ilmeisimmin yrität tehdä jotain väärin kun yrität kääntää OpenSSL:ää Windowsissa.

Yksittäisen modulin joutuu joka tapauksessa kääntämään yhdellä komennolla, jolloin säikeistys-ongelma ratkeaa itsestään, koska make voidaan komentaa käyttämään -j parametrilla(jobs) n kpl yhtäaikaista käännöstä. Riippuu käyttöjärjestelmästä onko nämä sitten säikeitä vai prosesseja. Tiedostojen riippuvuudet luovat automaattisesti sopivan hajautuspuun jolloin yleensä ottaen homma toimii ja stall-tilanteita ei synny. Käännösvaiheessa ajetaan useita säikeitä ja linkitys hoidetaan erillisenä yksisäikeisenä vaiheena, koska se on varsin nopea toimenpide.
Tuosta "perl-ohjelmoinnista" on sekä hyviä että huonoja kokemuksia. Esim. voidaan käyttää generaattoreita, joilla luodaan automaattisesti koodia matemaattisen mallin pohjalta. Ongelmia tulee vasta siinä vaiheessa, kun tuo perl-hässäkkä pitää portata uudelle alustalle, jolla ei ennestään ole käännöskirjastoja tarjolla ja toisaalta käännös vaati jotain kääntäjän erityisoptioita ollakseen tehokas. Esim. crc/tarkistussumman laskennan generointi säästää kyllä aikaa, mutta sen voi joutua koodaamaan silti uudestaan, jotta saisi yhdenmukaiset rajapinnat muuhun koodiin nähden.
Make on periaatteessa erittäin hyvä tapa kääntää ohjelmia, mutta sen tapa tuottaa c-kääntäjän käännöskomento on rajallisempi, kuin mitä esim. perl voi tarjota.