Kirjaudu

Uutiskirje

Rekisteröidy Sektoriin ja tilaa itsellesi joko aamuisin tai iltaisin ilmestyvä uutiskirje sähköpostiisi.

Perjantai, 1.3.2002

Windows XP SP1 tulee vasta vuoden jälkipuoliskolla

Microsoft ei julkaise Windows XP:lle Service Pack -nimellä tunnettavaa suurta korjauspakettia ennen kesää. Microsoftin Windows-tuotteiden tuotejohtaja Charmaine Gravning ilmoitti torstaina, että Windows XP:n ensimmäisen Service Packin (SP1) suunniteltu julkistusajankohta on vuoden jälkimmäisellä puolikkaalla.

Gravningin mukaan SP1 sisältää jo aiemmista Windows-versioista totuttuun tapaan kaikki Windows XP:lle julkaistut tietoturvakorjaukset ja muut ohjelmistopäivitykset. Näiden lisäksi SP1 sisältää kokonaan uusia ohjelmapäivityksiä, jollaisia ei aikaisempien Windows-versioiden Service Packeissa nähty. SP1 suorittaa käyttöjärjestelmälle myös mahdolliset antitrustioikeudenkäynnissä vaadittavat muutokset.

Lue juttu K2, 1.3.2002 11:13. Lähde: IDG

Muita aiheeseen liittyviä uutisia

Rekisteröidy ja kirjaudu sisään, jos haluat kommentoida.

Kommentit ( 37 uutta / 37 )
pistettä.
Näytä vain kommentit joilla on vähintään
bungle ei nyt ihan noinkaan
bungle, 1.3.2002 11:40:06		 Pisteet: +1
Näiden lisäksi SP1 sisältää kokonaan uusia ohjelmapäivityksiä, jollaisia ei aikaisempien Windows-versioiden Service Packeissa nähty
Windows NT 4.0 Service Pack 4 lisäsi myös uusia ominaisuuksia (kuten ilmeisesti valinnaisena tulleen Option Packin, sekä Data Access komponentit). Ja ilmeisesti muutakin. Tällöin asiasta nousi suuri kohu, sillä Windows ylläpitäjät eivät todellakaan kaipaa mitään piilossa asentuvia lisäominaisuuksia vaan ainoastaan niitä korjauksia. Jos lisäominaisuuksia tarvitaan, niin ne voidaan julkaista muutoin. Microsoft päätti, että se ei enää lisää uusia ominaisuuksia, vaan ainoastaa korjauksia SP:eihin, kunnes...

Epäilen, että tämä liittynee jollain lailla .NET fremeworkiin. Service Pack on yksi kätevä kanava ujuttaa .NET Framework kaikkiin Windows koneisiin, ja kun Java sieltä on jo poistettu, niin motiivi lienee selvä.
--
"See the animal in his cage that you built, are you sure what side you're on?" -- Trent Reznor
jemm Re: ei nyt ihan noinkaan
jemm, 1.3.2002 12:24:25		 Pisteet: +1
Epäilen, että tämä liittynee jollain lailla .NET fremeworkiin. Service Pack on yksi kätevä kanava ujuttaa .NET Framework kaikkiin Windows koneisiin, ja kun Java sieltä on jo poistettu, niin motiivi lienee selvä.
Se .NET Framework tulee joka tapauksessa olemaan ennemmin tai myöhemmin kaikilla. SP tai ei, niin pian kaikki Microsoftin sovellukset luultavasti edellyttävät, että se on asennettuna. Viimeistään seuraavassa Windowsissa se on sisäänrakennettuna (esim. .NET Serverissä on).

Se ei kyllä mielestäni ole huono asia loppukäyttäjillekään, sillä esim. turvallisuus on .NET-sovelluksilla ihan toista luokkaa Win32:een nähden. Esim. sähköpostivirukset yms eivät ole mahdollisia, ellei laita trusteja täysille. Oletusarvoisesti voidaan siis käynnistää turvallisin mielin .NET-sovellus suoraan web-sivun linkista, mutta jos se sovellus yrittää vaikka tiedostojärjestelmään, tulee .NET väliin, eikä päästä sovellusta resursseihin.

Toistaiseksi sanoisin kuitenkin Win32 API:n olevan .NETin suurin kilpailija ja nyt MS:llä on kova työ saada Windows-kehittäjiä .NET-alustalle.
Toki Microsoft yrittää Javastakin niitä houkutella mm. J#:lla, mutta esim. VB-kehittäjät lienevät suurempi haaste (lähinnä määränsä ja VB.NETin muutosten vuoksi).

Meni ehkä vähän offtopic, mutta myös täältä löytyy jotain tietoa XP SP1:n sisällöstä:
http://www.wininformant.com/Articles/Index.cfm?Art...
-Jemm
Re: ei nyt ihan noinkaan
Anonyymi kommentoija, 1.3.2002 12:43:06		 Pisteet: 0

Se .NET Framework tulee joka tapauksessa olemaan ennemmin tai myöhemmin kaikilla.
Windows- ja Macintosh-koneissa kyllä, mutta tuleeko myös Linux-käyttäjille?
jemm Re: ei nyt ihan noinkaan
jemm, 1.3.2002 13:14:55		 Pisteet: +1
Se .NET Framework tulee joka tapauksessa olemaan ennemmin tai myöhemmin kaikilla.
Windows- ja Macintosh-koneissa kyllä, mutta tuleeko myös Linux-käyttäjille?
No tässä tapauksessa viittasin "kaikilla" lähinnä Windows-käyttäjiin. Windowsin lisäksi muita varmoja alustat, joille .NET tulee (tai jo on) ovat:
-PocketPC
-XBox/HomeStation
-Windows Powered SmartDevices

Eli lähinnä muut Microsoft-alustat. Näissä tietty pienemmät luokkakirjastot, kuin PC-versiossa.

Saa sitten nähdä, mitä muitten valmistajien käyttisten/alustojen kanssa käy, jos mitään.
-Jemm
Re: ei nyt ihan noinkaan
Anonyymi kommentoija, 1.3.2002 17:09:27		 Pisteet: 0

Saa sitten nähdä, mitä muitten valmistajien käyttisten/alustojen kanssa käy, jos mitään.
Mulla on Mac OS X:llä ainakin joku .Net Passport-tunnari, jonka Microsoft Office v. X mulle tyrkytti ja ainakaan MSN Messenger-ohjelma ei toimi ilman sitä.

Onko se nyt sitten se .Net?
Re: ei nyt ihan noinkaan
Anonyymi kommentoija, 1.3.2002 17:16:07		 Pisteet: 0
Onko se nyt sitten se .Net?
Eikös .Net on ainoastaan Microsoftin keino päästä muutaman vuoden kuluttua väittämään, että netti on heidän kehittämä.
jemm .NET -termien selvennystä
jemm, 1.3.2002 17:50:03		 Pisteet: +2
Saa sitten nähdä, mitä muitten valmistajien käyttisten/alustojen kanssa käy, jos mitään.
Mulla on Mac OS X:llä ainakin joku .Net Passport-tunnari, jonka Microsoft Office v. X mulle tyrkytti ja ainakaan MSN Messenger-ohjelma ei toimi ilman sitä.
Onko se nyt sitten se .Net?
Passport on Web Serviceillä tarjottu autentikointipalvelu. Jos sovellusta kehittävä maksaa rahaa Microsoftille (heidän etu), niin tätä Passportia voi käyttää omassa sovelluksessaan/web palvelussaan.

Käyttäjän etu on se, että sen ei tarvitse taas opetella uutta tunnusta/salasanaa, vaan se voi käyttää sitä Passportin tunnaria.

Passportia hyödyntävän palvelun etu on valmis autentikointirajapinta ja käyttäjien helpompi houkuttelu rekisteröitymään, kun tunnus/salasana on sillä kuitenkin jo valmiina.

Lisäksi on erikseen .NET My Services (ent. Hailstorm), jossa on ideana se, että käyttäjä voi tallentaa linkkinsä, sähköpostinsa yms. profiilitietonsa keskitetylle palvelimelle, josta se voi sitten hakea tietoja kotoa, työpaikaltaan ja mobiililaitteistaan. Se käyttänee Passportia käyttäjän tunnistamiseen, mutta ne ovat kuitenkin erillisiä palveluita.

.NET Framework (josta keskustelu lähti) on puolestaan alusta, jonka päälle sovelluskehittäjät voivat tehdä mm. graafisia sovelluksia (WinForms), Web-sovelluksia, XML Web Serviceitä ja oikeastaan kaikenlaisia muitakin. Siihen saa ilmaisen SDK:n ja komentorivikääntäjät, joten se onnistuu vaikka Notepadilla ;) Jos sillä tekee palvelimelle softan, ei sitä runtimeä siis edellytetä loppukäyttäjältä, jos vaikka selaimesta käynnistää softan.

Visual Studio.NET on kehitysympäristö, jolla Microsoft yrittää kerätä rahaa ja sovelluskehittäjiä leiriinsä. Sitä ei siis välttämättä edellytetä .NET-sovellusten tekoon, mutta varmasti tuottavuuden nimissä se on monien firmojen valinta, kun toteutus/debuggaus yms on nopeampaa, kuin tekstieditorilla.
-Jemm
Re: ei nyt ihan noinkaan
samleh, 1.3.2002 14:12:21		 Pisteet: 0
Se ei kyllä mielestäni ole huono asia loppukäyttäjillekään, sillä esim. turvallisuus on .NET-sovelluksilla ihan toista luokkaa Win32:een nähden. Esim. sähköpostivirukset yms eivät ole mahdollisia, ellei laita trusteja täysille. Oletusarvoisesti voidaan siis käynnistää turvallisin mielin .NET-sovellus suoraan web-sivun linkista, mutta jos se sovellus yrittää vaikka tiedostojärjestelmään, tulee .NET väliin, eikä päästä sovellusta resursseihin.
Ja miten tämä vaikuttaa muka nykyisenkaltaisiin viruksiin? OE on edelleen yhtä reikäinen kuin ennen .NET'in asennusta.
--
just joo.
jemm Re: ei nyt ihan noinkaan
jemm, 1.3.2002 18:00:39		 Pisteet: +1
uokkaa Win32:een nähden. Esim. sähköpostivirukset yms eivät ole mahdollisia, ellei laita trusteja täysille. Oletusarvoisesti
Ja miten tämä vaikuttaa muka nykyisenkaltaisiin viruksiin? OE on edelleen yhtä reikäinen kuin ennen .NET'in asennusta.
Ei se tietenkään vanhoja vikoja paikkaa. :)

Sähköpostiviruksissa ei oikeastaan ollut ongelmana Outlook tai sen reikäisyys, vaan se, että liitetiedostoilla on samat oikeudet, kuin muillakin ohjelmilla. (Paitsi jotkut virukset kai hyödynsivät jotain turva-aukkoa, mikä mahdollisti liitteen automaattisen käynnistämisen).

Jos käyttäjä avasi liitteen ja suoritti sen, pystyi se softa käyttämään mitä vain resursseja, kuten Outlookin COM-rajapintaa, jonka avulla oli helppo lukea osoitteet osoitekirjasta ja lähettää mailit eteenpäin.

Liitteenä tuleva .NET softa ei sitä kuitenkaan voisi tehdä. Tosin mikään ei estä sovelluskehittäjää tekemästä Win32-softaa, joka voi temmeltää mielin määrin.
-Jemm
heko Re: ei nyt ihan noinkaan
heko, 1.3.2002 18:18:16		 Pisteet: +1
(Paitsi jotkut virukset kai hyödynsivät jotain turva-aukkoa, mikä mahdollisti liitteen automaattisen käynnistämisen).
Ts. outlookissa oli ja luultavasti on yhä virheitä. Useampiakin kuin yksi.

Get over it. Järjestelmän turvallisuutta voi kohentaa tekemällä kaikkea hienoa ja päheää, mutta turvajärjestelmä itsessään voi sisältää virheitä, joiden avulla tietoturvasta huolettomina ohjelmoitujen, tällaiseen järjestelmään luottavien ohjelmien laatu on aiempaakin helpommin väärinkäytettävissä. Loppujen lopuksi kyse on aina siitä, kuinka huolellinen ohjelmoija on ja kuinka bugista softa on.
--
Heikki http://www.heikkikorpela.fi heikki@heikkikorpela.fi
rosmo Re: ei nyt ihan noinkaan
rosmo, 4.3.2002 23:03:04		 Pisteet: 0
Get over it. Järjestelmän turvallisuutta voi kohentaa tekemällä kaikkea hienoa ja päheää, mutta turvajärjestelmä itsessään voi sisältää virheitä, joiden avulla tietoturvasta huolettomina ohjelmoitujen, tällaiseen järjestelmään luottavien ohjelmien laatu on aiempaakin helpommin väärinkäytettävissä.
Sandbox-implementaatiossa oleva tietoturva-aukko on kuitenkin helpompi korjata kuin sadassa softassa olevat reäit. Silti tietenkin loppukädessä on kyse koodaajan huolellisuudesta, mutta bugittomaksi softaa ei saa edes se "täydellinen ohjelmoija".
--
"I love deadlines, especially the whooshing sound they make as they go by."
jemm Re: ei nyt ihan noinkaan
jemm, 1.3.2002 19:12:42		 Pisteet: +1
(Paitsi jotkut virukset kai hyödynsivät jotain turva-aukkoa, mikä mahdollisti liitteen automaattisen käynnistämisen).
Ts. outlookissa oli ja luultavasti on yhä virheitä. Useampiakin kuin yksi.
Aivan, mutta ilman niitäkin ne virukset olisivat levinneet, sillä käyttäjät availivat niitä tiedostoliitteitä, jolloin ohjelmat käynnistyivät. Tämän jälkeen kyse ei ole Outlookin, vaan käyttiksen, Windowsin, ongelmista (=ohjelmilla lupa tehdä mitä vaan).

Get over it. Järjestelmän turvallisuutta voi kohentaa tekemällä kaikkea hienoa ja päheää, mutta turvajärjestelmä itsessään voi sisältää virheitä, joiden avulla tietoturvasta huolettomina
Jep, onhan tämä jo nähty useasti, enkä tietääkseni missään väittänytkään, että .NET tekee tietoturvan aukottomaksi. Ainostaan väitän, että .NETin arkkitehtuurissa tietoturva on huomioitu paremmin, kuin Windowsissa.

.NET aloitettiin käytännössä puhtaalta pöydältä, joten siinä on pystytty oppimaan Windowsissa olleista virheistä, jotka ovat oikeastaan niin matalalla tasolla, että oli helpompi tehdä oma alusta siihen päälle. Samoin tätä alustaa on helpompi levittää myös muualle, kuin Windowsiin (kuten mobiililaitteisiin).
-Jemm
bungle Re: ei nyt ihan noinkaan
bungle, 2.3.2002 20:00:10		 Pisteet: +1
.NET aloitettiin käytännössä puhtaalta pöydältä, joten siinä on pystytty oppimaan Windowsissa olleista virheistä, jotka ovat oikeastaan niin matalalla tasolla, että oli helpompi tehdä oma alusta siihen päälle.
MS:n tyylihän on ollut nykyisin se, että tungetaan paska kermakuorrutuksen alle.

Sitä paitsi .NET nojaa monellakin tapaa edelleen Windowsiin ja toimii ainoastaa wräpperinä. MTS/COM+ pyörii edelleen siellä. .NET wräppää myös Win32:sta. Uskon, että tiedostojärjestelmän turvallisuudessa nojataan NTFS:ään. .NET sovelluksien sisälle voidaan kirjoittaa unmanaged koodia, joka ajetaan .NETin runtimen ulkopuolella (lue mahd. tapa tehdä viruksia).

Samoin tätä alustaa on helpompi levittää myös muualle, kuin Windowsiin (kuten mobiililaitteisiin).
Eiköhän niissäkin mobiililaitteissa pyöri Windows tai sen lähisukulainen? Nokian kännykkään tuskin koskaan .NETiä tulee.
--
"See the animal in his cage that you built, are you sure what side you're on?" -- Trent Reznor
jemm Re: ei nyt ihan noinkaan
jemm, 2.3.2002 21:11:28		 Pisteet: +1
Sitä paitsi .NET nojaa monellakin tapaa edelleen Windowsiin ja toimii ainoastaa wräpperinä. MTS/COM+ pyörii edelleen siellä.
Aivan ja sehän onkin yksi .NETin piirteistä, että siinä voidaan myös hyödyntää alustan alla olevia palveluita tarvittaessa.

Tottakai haluan hyödyntää COM+:n tarjoamia palveluita, jos juuri sellaisia tarvitsen ja ne ovat saatavilla. Tietenkin siinä kärsii mahdollisesta siirrettävyydestä, mutta tilanteen mukaan. Itse nyt kuitenkin tähtään Win-alustalle muutenkin, joten mitä väliä.

COM+:aa voidaan käyttää transaktioihin, kuten ennenkin, mutta niitä voidaan myös määritellä kuten ennenkin tietokantapäässä (sql/tallennettu proseduuri) tai ado.netin tasolla. Eli COM+:aan ei aina kannata turvautua, varsinkin kun COM inter-op on hidasta (n. 30 kellojaksoa/pyyntö).

Myös SqlClient -adapteri (erittäin nopea tapa kytkeytyä SQL Serveriin) käyttää tietääkseni COM+:n palveluita.

NET wräppää myös Win32:sta.
Jos se haittaa, niin sitten ei käytä niitä namespaceja, jotka niihin turvautuu.

skon, että tiedostojärjestelmän turvallisuudessa nojataan NTFS:ään.
Viittasitko siihen esimerkkiini code access securityssä? Ei ainakaan siinä tapauksessa. Toki ACL:t yms huomioidaan sitten erikseen.

NET sovelluksien sisälle voidaan kirjoittaa unmanaged koodia, joka ajetaan .NETin runtimen ulkopuolella (lue mahd. tapa tehdä viruksia).
Ehkä. Nekin edellyttävät, että softa pyörii luotetussa kontekstissa. Ts. pointtereita yms hyödyntäville softille pitää erityisesti antaa oikeudet.

Samoin tätä alustaa on helpompi levittää myös muualle, kuin Windowsiin (kuten mobiililaitteisiin).
Eiköhän niissäkin mobiililaitteissa pyöri Windows tai sen lähisukulainen? Nokian kännykkään tuskin koskaan .NETiä tulee.
Jep. Eipä esim. Symbian tai J2ME:kään kaikkialla ole.
-Jemm
heko Re: ei nyt ihan noinkaan
heko, 1.3.2002 20:11:15		 Pisteet: +1
.NET aloitettiin käytännössä puhtaalta pöydältä, joten siinä on pystytty oppimaan Windowsissa olleista virheistä, jotka ovat oikeastaan niin matalalla tasolla, että oli helpompi tehdä oma alusta siihen päälle.
Näinkin voi käydä. Mutta on toinenkin vaihtoehto: historia opettaa, että vanhojen virheiden toistamisen sijaan voi tällaisessa tilanteessa keksiä myös uusia virheitä. Ei ole aina helppoa huomata kokonaan uutta järjestelmää tehdessään, missä kohtaa edellisessä nimenomaan vältti virheitä ja teki asioita fiksusti. Ei ole välttämättä edes helppoa sanoa, mikä virhe oli. Jälkiviisaus on ehkä helppoa, muttei suinkaan aina onnistunutta.

En kuvittele tuntevani Windowsia ja sen sisuksia riittävästi, jotta osaisin sanoa, onko täysin uusi design järkevää - varsinkaan, jos sitä pyörittää kuitenkin osin vanhan päällä. Aina se ei suinkaan ole: lukemattomat softakehitysprojektit ovat epäonnistuneet juuri siksi, että on ajateltu, että uudelleenkirjoitus on välttämätöntä ja jalostaa ohjelmiston automaattisesti paremmaksi. Vanhankin päälle voi rakentaa, sekä suunnittelussa ja toteutuksessa - ja se voi olla jopa yllättävän kivaa, vaikka uuden suunnan ottaminen voikin vaikuttaa ensi hätään mukavimmalta ja helpoimmalta. Esimerkiksi uudelleenkirjoituksella aluksi pahasti mokanneesta projektista vetäisin Mozillan - ja esimerkiksi projektista, joka on oppinut prosessimielessä tästä virheestään suunnattomasti, ottaisin samaisen Mozillan.
--
Heikki http://www.heikkikorpela.fi heikki@heikkikorpela.fi
bungle Re: ei nyt ihan noinkaan
bungle, 1.3.2002 14:20:03		 Pisteet: +1
Se .NET Framework tulee joka tapauksessa olemaan ennemmin tai myöhemmin kaikilla. SP tai ei, niin pian kaikki Microsoftin sovellukset luultavasti edellyttävät, että se on asennettuna.
Eikös juuri tämä selain hässäkkä johdu siitä. Microsoft levitti väkipakolla oman selaimensa kaikkiin Windowseihin ja samalla haittasi kilpailijoiden toimia.

Nyt he aikovat ujuttaa .NETin ja poistavat Javan windowsista. Eiköhän se jonkun verran hallaa aiheuta Java leiriin.

Se ei kyllä mielestäni ole huono asia loppukäyttäjillekään, sillä esim. turvallisuus on .NET-sovelluksilla ihan toista luokkaa Win32:een nähden.
Se jäänee nähtäväksi. Ei niitä .NET sovelluksia missään sandboxissa ajella.

Esim. sähköpostivirukset yms eivät ole mahdollisia, ellei laita trusteja täysille.
En usko, ennen kuin näen. Ja onhan jo ensimmäin .NET viruskin (vaiko onko niitä jo useampikin) löytynyt.

Oletusarvoisesti voidaan siis käynnistää turvallisin mielin .NET-sovellus suoraan web-sivun linkista, mutta jos se sovellus yrittää vaikka tiedostojärjestelmään, tulee .NET väliin, eikä päästä sovellusta resursseihin.
Onneksi Windows on muutoin niin turvallinen, että siihen väliin ei voi mikään muu ohjelma tulla.

Toistaiseksi sanoisin kuitenkin Win32 API:n olevan .NETin suurin kilpailija ja nyt MS:llä on kova työ saada Windows-kehittäjiä .NET-alustalle.
Win32 API? hmm... veikkaisin, että MFC taitaa olla lähempänä .NETiä tai sitten ATL, kuin Win32.

Toki Microsoft yrittää Javastakin niitä houkutella mm. J#:lla, mutta esim. VB-kehittäjät lienevät suurempi haaste (lähinnä määränsä ja VB.NETin muutosten vuoksi).
Kuten todettua. VB.NET on vain uusi syntaksi C#:lle. Samoin kaikki muutkin .NET syntaksit.
--
"See the animal in his cage that you built, are you sure what side you're on?" -- Trent Reznor
jemm Re: ei nyt ihan noinkaan
jemm, 1.3.2002 17:35:07		 Pisteet: +2
Eikös juuri tämä selain hässäkkä johdu siitä. Microsoft levitti väkipakolla oman selaimensa kaikkiin Windowseihin ja samalla haittasi kilpailijoiden toimia.
No tuossa on kai hieman laajemmasta kyse. Monet Microsoftin muut sovellukset käyttävät IE:n komponentteja, jolloin sen ymmärtää, miksi sen asennusta joskus esim. Officen yhteydessä edellytetään. Samoin esim. SQL Server edellyttää usein uusimpia MDAC-komponentteja, jotta ne voisivat käyttää ADO:n palveluita jne.

Vastaavasti, .NETin palveluita hyödyntävät sovellukset edellyttävät siten sen Frameworkin asennusta, sillä ilman sitä ne eivät toimi. Eipä Java-sovellustakaan voi levittää ilman, että loppukäyttäjän on asennettava jokin JVM, jos sitä ei ole jo tehnyt.

Nyt he aikovat ujuttaa .NETin ja poistavat Javan windowsista. Eiköhän se jonkun verran hallaa aiheuta Java leiriin.
Tuo poistaminen haitannee käytännössä lähinnä niitä, jotka käyttävät appletteja Web-sivuilla. CD:ltä asennettavat sovellukset osaavat asentaa JVM:n tarvittaessa ja palvelimissa se lienee valmiina. Kyllä sen Javan voi imuroida kuitenkin erikseen Windows Updatesta tai muulta valmistajalta.

Microsofthan lisäsi J++:ssa JVM:ään laajennuksia, joita käyttämällä pystyttiin hyödyntämään paremmin Windowsin palveluita (mm. GUI ja COM). Tästä Sun ei tykännyt, vaan tuli oikeuskiista, jossa kaikki muokkaus kiellettiin - jopa JVM:n pitäminen ajantasalla. Eipä siinä oikein muu auttanut, kuin kehittää oma alusta - .NET.

oppukäyttäjillekään, sillä esim. turvallisuus on .NET-sovelluksilla ihan toista luokkaa Win32:een nähden.
Se jäänee nähtäväksi. Ei niitä .NET sovelluksia missään sandboxissa ajella.
No miten sen nyt ottaa. Ei se turvallisuusmalli ehkä ihan samanlainen, kuin Javassa ole, mutta se on kuitenkin käyttöjärjestelmästä täysin erillinen, kokonaan alusta luotu malli. .NET sovelluksilla ei ole samoja oikeuksia, kuin natiiveilla Windows-sovelluksilla, eikä ne sovellukset siten pääse mihin tahansa resursseihin käsiksi. .NET tunnistaa, onko softa käynnistetty Webistä, lähiverkosta vai paikalliselta levyltä ja mm. sen mukaan antaa oikeuksia.

Win32 API, kovalevy, tietokantarajapinnat, Active Directory jne. ovat esimerkkejä resursseista, joihin ei noin vain pääse.

Esim. sähköpostivirukset yms eivät ole mahdollisia, ellei laita trusteja täysille.
En usko, ennen kuin näen.
No, itse testatasin, miten käynnistän tekemäni .NET-sovelluksen linkistä. Siinä tulee käynnistyessä sellainen "puhekupla", jossa sanotaan, että: "The application is running in partially trusted content. Some functionality in the application may be disabled due to security restrictions."

Sen jälkeen yritän painaa Save -painiketta, joka yrittää tehdä tekstitiedoston juureen, mutta .NET ilmoittaa, että eipä onnistu, ellen säädä turva-asetuksia/lisää sovellusta luotettujen listalle.

Http://www.gotdotnet.com :n takaa löytyvästä Terrarium -pelissä on ideana luoda pieniä .NET-sovelluksia, joita sitten välitetään toisille pelaajille peer-to-peer -mäisesti. Siinä ohjelmoijat tekevät pieniä sovelluksia, eläimiä, jotka syövät kasveja tai toisiaan. Parhaat algoritmit syövät huonot :P Vaikka kyse on ohjelmakoodista, ei ne kuitenkaan ole vaarallisia omalle koneelle, mikä on yksi tuon projektin tarkoitus.

a onhan jo ensimmäin .NET viruskin (vaiko onko niitä jo useampikin) löytynyt.
Ainakin tämä on:
http://www.europe.f-secure.com/v-descs/dotnet.shtm...

Mutta se ei tee muuta, kuin muokkaa valmista exe:ä (jotka nekin voi suojata mm. allekirjoituksin).

ivun linkista, mutta jos se sovellus yrittää vaikka tiedostojärjestelmään, tulee .NET väliin, eikä päästä sovellusta resursseihin. Onneksi Windows on muutoin niin turvallinen, että siihen väliin ei voi mikään muu ohjelma tulla.
Windowsilla/sen turvallisuudella ei siis ole mitään sanaa .NETin hallitsemassa ympäristössä. Tietenkään .NET ei ota kantaa natiiveihin Win32-sovelluksiin.

Toistaiseksi sanoisin kuitenkin Win32 API:n olevan .NETin suurin kilpailija ja nyt MS:llä on
Win32 API? hmm... veikkaisin, että MFC taitaa olla lähempänä .NETiä tai sitten ATL, kuin Win32.
MFC yms ovat kuitenkin vain lähinnä wrapperiluokkia APIiin, eivätkä esim. sisällä .NET-_alustan_ tarjoamia piirteitä (kuten turvallisuus, garbage collection yms).

Kuten todettua. VB.NET on vain uusi syntaksi C#:lle. Samoin kaikki muutkin .NET syntaksit.
Ei syntaksi C#:lle, vaan CLR:lle/MSILille. Kaikki syntaksit jakavat samat palvelut ja erot "kielien" välillä ovat tosiaan lähinnä kosmeettisia. Eipä tässä kai mitään uutta ole..?
-Jemm
lokori Re: ei nyt ihan noinkaan
lokori, 3.3.2002 16:08:19		 Pisteet: +1
Tuo poistaminen haitannee käytännössä lähinnä niitä, jotka käyttävät appletteja Web-sivuilla.
Appletit on edelleen ainoa jokseenkin järkevä tapa tehdä tiettyjä asioita.

Microsofthan lisäsi J++:ssa JVM:ään laajennuksia, joita käyttämällä pystyttiin hyödyntämään paremmin Windowsin palveluita (mm. GUI ja COM). Tästä Sun ei tykännyt, vaan tuli oikeuskiista, jossa kaikki muokkaus kiellettiin - jopa JVM:n pitäminen ajantasalla. Eipä siinä oikein muu auttanut, kuin kehittää oma alusta - .NET.
Pelkistäen, noinhan se meni.
Microsoft tosin taisi rikkoa java-standardia tietoisesti noita "laajennuksia" tekemällä, ja se osoittaa mielestä melko huonoa "urheilijahenkeä" jos pitää lähteä kepulikonsteilla kilpailijoita kampittamaan.

Nähdäkseni Microsoft yritti omia javan itselleen, mutta epäonnistui siinä. Eipä siinä sitten oikein muu auttanut kuin lähteä ihan rehellisesti kilpasille.

No miten sen nyt ottaa. Ei se turvallisuusmalli ehkä ihan samanlainen, kuin Javassa ole, mutta se on kuitenkin käyttöjärjestelmästä täysin erillinen, kokonaan alusta luotu malli.
Mutta onko se toimiva.

Win32 API, kovalevy, tietokantarajapinnat, Active Directory jne. ovat esimerkkejä resursseista, joihin ei noin vain pääse.
Joihin ei pitäisi päästä.
Olisi hyvin tavallista Microsoftille että niihinkin pääsisi jotain "oikotietä" pitkin kutsumalla sopivan nimisiä luokkia ja komponentteja.

Uskon tuohon turvallisuuteen vasta kun sen voi jotenkin todeta muualta kuin MS:n mainosmateriaalista.

Windowsilla/sen turvallisuudella ei siis ole mitään sanaa .NETin hallitsemassa ympäristössä. Tietenkään .NET ei ota kantaa natiiveihin Win32-sovelluksiin.
Windowsin turvallisuus == .NETin turvallisuus siinä mielessä, että hienoinkaan securitymalli ei auta jos toteutus on buginen tai nojaa bugiseen käyttöjärjestelmään.

Kuten todettua. VB.NET on vain uusi syntaksi C#:lle. Samoin kaikki muutkin .NET syntaksit.
Ei syntaksi C#:lle, vaan CLR:lle/MSILille. Kaikki syntaksit jakavat samat palvelut ja erot "kielien" välillä ovat tosiaan lähinnä kosmeettisia. Eipä tässä kai mitään uutta ole..?
Hmm olen lähinnä ihmetellyt että miten voi ajatella tekevänsä luotettavaa, toimivaa softaa jossa olisi useammalla eri ohjelmointikielellä tehtyjä palveluita / osia. Onhan C:n / C++:n ja Pascalinkin sekoittaminen ollut Borlandin kääntäjillä aikanaan mahdollista, mutta sitä ei suositeltu.

Tulee mieleen kielten erot tietotyypeissä, muistin varaamisessa, poikkeuskäsittelyssä yms. asioissa ja toisaalta suorituskykyongelmat jos perlikoodia kutsutaan c# koodista usein.

Onko ongelma ratkaistu niin että voi koodata about millä tahansa kielellä kunhan noudattaa tiettyjä tarkkoja sääntöjä siitä mitä saa tehdä ja mitä ei saa?
rosmo Re: ei nyt ihan noinkaan
rosmo, 4.3.2002 23:06:56		 Pisteet: 0
Uskon tuohon turvallisuuteen vasta kun sen voi jotenkin todeta muualta kuin MS:n mainosmateriaalista.
Pitäisiköhän täällä Sektorissa järjestää jokin vedonlyönti siitä, koska ensimmäinen iso tietoturva-aukko löytyy .NET:istä :-) Täytyy sanoa että sille ettei siitä mitään löydy joutuisin antamaan todella pienet kertoimet...
--
"I love deadlines, especially the whooshing sound they make as they go by."
jemm Re: ei nyt ihan noinkaan
jemm, 3.3.2002 17:43:54		 Pisteet: +1
Tuo poistaminen haitannee käytännössä lähinnä niitä, jotka käyttävät appletteja Web-
Appletit on edelleen ainoa jokseenkin järkevä tapa tehdä tiettyjä asioita.
Jep, mutta ainakin itse olen sitä mieltä, että palvelinpäässä se Java kuitenkin on vahvimmillaan, jolloin on usein samantekevää, mitä siellä client-koneella on (jos kyse on esim. web-sivuista). Tietty pelit, tsätit yms ovat asia erikseen.

No miten sen nyt ottaa. Ei se turvallisuusmalli ehkä ihan samanlainen, kuin Javassa ole, mutta se on kuitenkin käyttöjärjestelmästä täysin erillinen, kokonaan alusta luotu malli.
Mutta onko se toimiva.
Sen näyttää aika.. liian varhaista vastata, miten hyvin käytännössä pelaa, kun .NET ei ole vielä niin laajassa käytössä, että pahimmat puutteet/mahdolliset viat olisivat tulleet ilmi.

Win32 API, kovalevy, tietokantarajapinnat, Active Directory jne. ovat esimerkkejä resursseista, joihin ei noin vain pääse.
Joihin ei pitäisi päästä.
Olisi hyvin tavallista Microsoftille että niihinkin pääsisi jotain "oikotietä" pitkin kutsumalla sopivan nimisiä luokkia ja komponentteja.
Tottakai entisiin COM-rajapintoihin ja moniin muihin resursseihin pääsee tarvittaessa, olettaen että ohjelmalla on siihen oikeudet. Jos ei pääsisi esimerkiksi tietokantaan käsiksi jossain palvelinpään softassa, olisi sovellus melko köyhä ;)

Sen sijaan satunnaiset, netistä ladatut ohjelmat, tiedostoliitteet yms eivät tietenkään saa päästä niihin käsiksi, eikä oletusarvoisesti pääsekään (ellei sitten ilmene jotain bugeja/turva-aukkoja jne -disclaimeri).

Uskon tuohon turvallisuuteen vasta kun sen voi jotenkin todeta muualta kuin MS:n mainosmateriaalista.
Mitähän ne mainokset sanovat aiheesta.. en ole niitä nähnytkään. On niistä(kin) piirteistä paljon MS:n ulkopuolista kirjallisuutta, web-sivuja etc, joista voi vetää omat johtopäätöksensä.

Windowsin turvallisuus == .NETin turvallisuus siinä mielessä, että hienoinkaan securitymalli ei auta jos toteutus on buginen tai nojaa bugiseen käyttöjärjestelmään.
Jep, niitä voi olla ja varmasti jotain puutteita löytyykin näin uudesta alustasta. Tärkeää mielestäni on kuitenkin se, että siihen on kuitenkin selkeästi panostettu aikaisempaa paremmin.

Hmm olen lähinnä ihmetellyt että miten voi ajatella tekevänsä luotettavaa, toimivaa softaa jossa olisi useammalla eri ohjelmointikielellä tehtyjä palveluita / osia. Onhan C:n / C++:n ja Pascalinkin sekoittaminen ollut Borlandin kääntäjillä aikanaan mahdollista, mutta sitä ei suositeltu.
No tässä pitää taas ajatella realistisesti: ei järkevä firma anna toteuttaa sovellusta liian usealla kielellä. Jos joku käyttää esim. cobol.netiä ainoana talossa ja lähtee (tai potkitaan;) sitten muualle, niin kuka jatkaa koodin ylläpitoa?

Käytännössä arvelen, että monet kaupalliset valitsevat linjakseen vb.netin ja/tai c#:n. Harrastelijat sitten käyttävät näitä object pascalin, perlin yms .net -versioita, varsinkin jos ne ovat aikaisempien kokemusten kautta tutumpia syntaksiltaan.

Tulee mieleen kielten erot tietotyypeissä, muistin varaamisessa, poikkeuskäsittelyssä yms. asioissa ja toisaalta suorituskykyongelmat jos perlikoodia kutsutaan c# koodista usein.
.NET Frameworkissa tuo on hoidettu siten, että siinä on Common Language Specification (CLS) ja Common Type System (CTS). Näiden piirteitä noudattavat objektit ovat käytettävissä kaikista kielistä. Luokkia voi periyttää ristiin kielien välillä jne.

Esim. C#:n, Managed C++:n ja JScriptin int on itseasiassa alias System.Int32:sta. Samoin VB.NETin Integer viittaa samaan perustyyppiin.

Kielissä voi luonnollisesti olla myös omia laajennuksiaan, mutta jos niitä käyttää vain luokkien sisäisesti yms, ei niistä pitäisi olla siirrettävyyden kannalta harmia.

Onko ongelma ratkaistu niin että voi koodata about millä tahansa kielellä kunhan noudattaa tiettyjä tarkkoja sääntöjä siitä mitä saa tehdä ja mitä ei saa?
Aivan. Tai voi niitä sääntöjä jättää noudattamatta, mutta sitten voi tulla ongelmia joissakin tapauksissa. Ei niistä säännöistä välttämättä vahingossa lipsahda, sillä yleisimmät piirteet näyttäisivät melko hyvin olevan määrittelyssä.

Toki se tuo hieman lisävaivaa testaukseen yms, jos projekti halutaan toteuttaa näitä ehtoja ehdottomasti noudattaen tulevaa ajatellen, mutta sama se oli pitkälti COMissakin.
-Jemm
heko Re: ei nyt ihan noinkaan
heko, 5.3.2002 22:42:05		 Pisteet: 0

No tässä pitää taas ajatella realistisesti: ei järkevä firma anna toteuttaa sovellusta liian usealla kielellä. Jos joku käyttää esim. cobol.netiä ainoana talossa ja lähtee (tai potkitaan;) sitten muualle, niin kuka jatkaa koodin ylläpitoa?
Oivoi. Kunpa maailma toimisikin näin, minäkään en olisi koskaan joutunut kuulemaan että asiakas toivoisi muutoksia Cobolilla toteutettuun järjestelmäänsä. :-)

Tuolla logiikallahan esim. cobolin olisi pitänyt kadota pois jo kauan, kauan sitten, kun sen osaajat alkoivat radikaalisti harvenemaan suhteessa koko ammattikuntaan? Toisin kävi: Cobol-osaajista oli ainakin viimeksi lukemani mukaan kova pula, ja jokin taho yrittää jopa kehitellä Cobolista jotain uutta, "edistyneempää" versiota.

Tällainen ajatteluhan voi ihan oikeasti olla ohjelmoijan puolella jopa laskelmoitua: "kun järjestän ohjelman riittävän hyvin taakseni, kukaan ei uskalla potkia minua enää koskaan hiiteen". Tällaisia työntekijöitä on ainakin huhupuheiden mukaan jopa yllättävän paljon. Työn palkitsevuudesta ja urakehityksestä en sitten tiedä... :-)
--
Heikki http://www.heikkikorpela.fi heikki@heikkikorpela.fi
heko Re: ei nyt ihan noinkaan
heko, 5.3.2002 22:31:08		 Pisteet: 0

Hmm olen lähinnä ihmetellyt että miten voi ajatella tekevänsä luotettavaa, toimivaa softaa jossa olisi useammalla eri ohjelmointikielellä tehtyjä palveluita / osia.
Käytännössä suurin osa kielistä - esim. Java ja perl - on itse kirjoitettu suureksi osin tai kokonaan C:llä. (Tai modula3 assyllä! :-)

Lisäksi esimerkiksi perl-mokkuloista huikaisevan suuri osa käyttää XS-koodia (eli osa mokkulasta on kirjoitettu C:llä, jotta päästään käyttämään jotain C-rajapintaa perlillä), Javassa on JNI, jne. Vaikka nämä ovat jossain määrin ehkä eri asioita, niin joitain yhteläisyyksiä on. Monissa tärkeissä ohjelmissa - esim. Unix-kerneleissä ja OpenSSL:ssä - on laajennettu C:täkin käsin optimoidulla assemblyllä.

Language shootoutista muuten löytyy joitain ohjeita ihan alkuunpääsemiseksi, jos tällainen C:llä laajentaminen kiinnostaa:

http://www.bagley.org/~doug/shootout/compare/binex... (Java, Perl, Python, Ruby)
--
Heikki http://www.heikkikorpela.fi heikki@heikkikorpela.fi
bungle Re: ei nyt ihan noinkaan
bungle, 2.3.2002 19:33:07		 Pisteet: +1
Samoin esim. SQL Server edellyttää usein uusimpia MDAC-komponentteja, jotta ne voisivat käyttää ADO:n palveluita jne.
?

ADO on luokkakirjasto, joka wrappää OLEDB:tä, OLEDB:lle on sitten ajureita kantoihin, kuten SQL serveriin tai ODBC jne. Ts. ADO ei ole palvelu.

Eipä Java-sovellustakaan voi levittää ilman, että loppukäyttäjän on asennettava jokin JVM, jos sitä ei ole jo tehnyt.
Väärin. Java ohjelmia voidaan kääntää myös natiiviksi koodiksi.

Kyllä sen Javan voi imuroida kuitenkin erikseen
Niin... kyllähän sen IE:n kin voisi imuroida erikseen ja/tai kyllähän netscape ja muutkin voisivat asentua käyttiksen mukana jne.

Tästä Sun ei tykännyt, vaan tuli oikeuskiista, jossa kaikki muokkaus kiellettiin - jopa JVM:n pitäminen ajantasalla.
Sen siitä saa, kun alkaa soveltamaan.

Eipä siinä oikein muu auttanut, kuin kehittää oma alusta - .NET.
Aivan... ja MS:n tuntien Framework muuttuu versiosta toiseen niin radikaalilla tavalla, että mikään vanha MSIL sovellus ei enää futaa tms. Joo kerro minulle vaan lisää side-by-side executionista.

se on kuitenkin käyttöjärjestelmästä täysin erillinen
Niin vielä tällähetkellä. Eivätköhän ne sen vielä siihen jollain keinoin integroi.

Win32 API, kovalevy, tietokantarajapinnat, Active Directory jne. ovat esimerkkejä resursseista, joihin ei noin vain pääse.
Eivätkö juuri monet .NET kirjastot käytä suoraan Win32 API, eli wräppäävät sitä?

No, itse testatasin, miten käynnistän tekemäni .NET-sovelluksen linkistä. Siinä tulee käynnistyessä sellainen "puhekupla", jossa sanotaan, että: "The application is running in partially trusted content. Some functionality in the application may be disabled due to security restrictions."
Sitten tehdään vaan ensin virus joka modifioi .NETiä ja/tai sen turvallisuus asetuksia.

Onneksi Windows on muutoin niin turvallinen, että siihen väliin ei voi mikään muu ohjelma tulla. Windowsilla/sen turvallisuudella ei siis ole mitään sanaa .NETin hallitsemassa ympäristössä.
Lue yllä. Ts. todellakin on. Tuttu on varmasti myös sanonta, että "järjestelmä on yhtä turvallinen kuin sen heikoin lenkki", joten turha jauhaa bullshittiä.

Kuten todettua. VB.NET on vain uusi syntaksi C#:lle. Samoin kaikki muutkin .NET syntaksit.
Ei syntaksi C#:lle, vaan CLR:lle/MSILille.
Tämän tiesin, mutta silti mielestäni väitteeni on oikea tai vähintään oikean suuntainen. atso edes hieman tuota C# ja vertaa sitä MSIL:ään tai vaikka yleisesti .NETiin ja päättele, että mitä kieltä silmälläpitäen koko .NET on tehty? Tuskin nyt sentää väkisellä modifioidulle VB:lle ja tai muille vaan C#:lle.

Kaikki syntaksit jakavat samat palvelut ja erot "kielien" välillä ovat tosiaan lähinnä kosmeettisia.
Aivan. Ja se siitä kieliriippumattomuudesta.

Eipä tässä kai mitään uutta ole..?
Tottakai .NET on suuri harppaus Windows kehittäjille, mutta jos vertaa muihin ympäristöihin, niin nyt tulevat muutokset vaikuttavat monessa mielessä hieman vanhahtavilta.
--
"See the animal in his cage that you built, are you sure what side you're on?" -- Trent Reznor
jemm Re: ei nyt ihan noinkaan
jemm, 2.3.2002 20:44:46		 Pisteet: +1
äyttää ADO:n palveluita jne.
ADO on luokkakirjasto, joka wrappää OLEDB:tä, OLEDB:lle on sitten ajureita kantoihin, kuten SQL serveriin tai ODBC jne. Ts. ADO ei ole palvelu.
No kerro jotain, mitä en jo tietäisi. Turhaa saivartelua.

se on kuitenkin käyttöjärjestelmästä täysin erillinen
Niin vielä tällähetkellä. Eivätköhän ne sen vielä siihen jollain keinoin integroi.
Todennäköisesti Blackcombissa tms.

Eivätkö juuri monet .NET kirjastot käytä suoraan Win32 API, eli wräppäävät sitä?
Monet, vaan ei kaikki.

Ei syntaksi C#:lle, vaan CLR:lle/MSILille.
Tämän tiesin, mutta silti mielestäni väitteeni on oikea tai vähintään oikean suuntainen. atso edes hieman tuota C# ja vertaa sitä MSIL:ään tai vaikka yleisesti .NETiin ja päättele, että mitä kieltä silmälläpitäen koko .NET on tehty? Tuskin nyt sentää väkisellä modifioidulle VB:lle ja tai muille vaan C#:lle.
Tottakai C# on se ensisijainen kieli, jolla kaikki saadaan parhaiten irti .NETissä. Sillähän on suuri osa koko .NETiä toteutettu muutenkin (kuten ASP.NET kokonaan). Ei kuitenkaan ole monia asioita, joita ei voisi esimerkiksi VB.NETillä toteuttaa, mutta C#:lla voi (tietty xml documenting, unsafe -lohkot yms).

Sekä C#:a, että VB.NETiä koodanneena voin sanoa, että niissä on eroa ja VB.NET on varmasti Visual Basicia koodanneelle tutumpaa, kuin C#. Ainakin itselläni VB.NET sujui heti johtuen omista taustoistani. C/C++ kokemusta minulla ei juurikaan ole, joten C#:n syntaksiset erot vaativat vielä totuttelua ja siksi on mielestäni perusteltua, että löytyy useampi keino päästä .NET Frameworkiin käsiksi.

Kyllä se vaikuttaa, miten muuttujat määritellään, käytetäänkö aaltosulkuja vain begin..end. Sen sijaan luokkakirjastojen yms palveluiden käyttö on suht. samanlaista.

Kaikki syntaksit jakavat samat palvelut ja erot "kielien" välillä ovat tosiaan lähinnä
Aivan. Ja se siitä kieliriippumattomuudesta.
Enpä ainakaan minä ole aidosti kieliriippumattomaksi sitä koskaan väittänyt. Tuskinpa monikaan vähänkään asiaan perehtynyt luulee, että "kielituki" merkitsee aitoa siirrettävyyttä natiivikääntäjien/.NETin välillä.

Eipä tässä kai mitään uutta ole..?
Tottakai .NET on suuri harppaus Windows kehittäjille, mutta jos vertaa muihin ympäristöihin, niin nyt tulevat muutokset vaikuttavat monessa mielessä hieman vanhahtavilta.
Jep, on siellä toki paljon vanhoja, hyväksi havaittuja juttujakin, joissa aikaisemmat tekniikat, kuten Java, ovat olleet edellä. Toisaalta, on siellä jotain sellaisiakin piirteitä, joita en ainakaan itse ole havainnut muualla.
-Jemm
heko Re: ei nyt ihan noinkaan
heko, 1.3.2002 18:11:24		 Pisteet: +1
Eipä Java-sovellustakaan voi levittää ilman, että loppukäyttäjän on asennettava jokin JVM, jos sitä ei ole jo tehnyt.
Onko JVM:istä eri implementaatioita?

Onko JVM:n koodi saatavilla verkosta?

Mille käyttöjärjestelmille löytyy JVM?

Saako joku muu kuin Sun, vaikkapa selainvalmistaja, paketoida JVM:n tuotteeseensa mukaan?

Microsofthan lisäsi J++:ssa JVM:ään laajennuksia, joita käyttämällä pystyttiin hyödyntämään paremmin Windowsin palveluita (mm. GUI ja COM). Tästä Sun ei tykännyt, vaan tuli oikeuskiista, jossa kaikki muokkaus kiellettiin - jopa JVM:n pitäminen ajantasalla. Eipä siinä oikein muu auttanut, kuin kehittää oma alusta - .NET.
"Parannuksia"? Miten olisi "yhteensopimattomuuksia"? Jos et ole itse sattunut törmäämään vielä Java-komponentteihin, jotka eivät toimi kuin Microsoftin JVM:llä, niin minä olen. Ne olisi vieläpä vallan hyvin voinut kirjoittaa tismalleen samalla toiminnallisuudella - ja kirjoitettiinkin - ihka oikealla Javalla, Java-speksin mukaan.

Miten "JVM:n pitäminen ajan tasalla" on kielletty?


Esim. sähköpostivirukset yms eivät ole mahdollisia, ellei laita trusteja täysille.
En usko, ennen kuin näen.
No, itse testatasin, miten käynnistän tekemäni .NET-sovelluksen linkistä. Siinä tulee käynnistyessä sellainen "puhekupla", jossa sanotaan, että: "The application is running in partially trusted content. Some functionality in the application may be disabled due to security restrictions."
Kuvittelenko vain vai puuttuuko tästä jokin linkki välistä? Tarkoittaako tämä, että jos minä en onnistu ensimmäisellä yrityksellä tekemään jotain, ko. asian tekeminen on mahdotonta? Logiikkasi toimisi lähinnä niinpäin, että väittäisit, että ei ole mahdotonta murtautua johonkin, ja sitten esittäisit, miten se murtautuminen tapahtuu.


Http://www.gotdotnet.com :n takaa löytyvästä Terrarium -pelissä on ideana luoda pieniä .NET-sovelluksia, joita sitten välitetään toisille pelaajille peer-to-peer -mäisesti. Siinä ohjelmoijat tekevät pieniä sovelluksia, eläimiä, jotka syövät kasveja tai toisiaan. Parhaat algoritmit syövät huonot :P
Nyt sattuu päähän. Auau.
--
Heikki http://www.heikkikorpela.fi heikki@heikkikorpela.fi
jemm Re: ei nyt ihan noinkaan
jemm, 1.3.2002 19:01:21		 Pisteet: +1
Eipä Java-sovellustakaan voi levittää ilman, että loppukäyttäjän on asennettava jokin JVM, jos sitä ei ole jo tehnyt.
Onko JVM:istä eri implementaatioita?
etc.
Tarkoitukseni oli vain korostaa sitä, että molemmilla alustoilla tehdyt sovellukset edellyttävät, että kirjastot yms. on asennettu.

Javalla/JVM:llä on ilman muuta listaamasi edut, enkä niitä kiistänytkään. En siis yritä yhtään täällä vähätellä Javaa, jolle minusta on myös paikkansa ja hyvä valinta, kun portattavuus etc on tärkeää.

Microsofthan lisäsi J++:ssa JVM:ään laajennuksia, joita käyttämällä pystyttiin hyödyntämään paremmin Windowsin palveluita
"Parannuksia"? Miten olisi "yhteensopimattomuuksia"?
Sanoin "laajennuksia", mikä ei ota kantaa siihen, onko se hyvä vai huono asia.

os et ole itse sattunut törmäämään vielä Java-komponentteihin, jotka eivät toimi kuin Microsoftin JVM:llä, niin minä olen. Ne olisi vieläpä vallan
En ole törmännyt, kun en ole niinkään käyttänyt, mutta tiedän, että sellaisia tehdään. Minusta se on sovelluskehittäjän ajattelemattomuutta, jos käyttää niitä laajennuksia hyödyntäviä luokkia, jos tavoitteena on siirrettävyys, kuten komponenteilla usein on.

Miten "JVM:n pitäminen ajan tasalla" on kielletty?
Ups.. unohda tuo. Siis: Java-oikeuskiistan jälkeen Microsoft ei ymmärrättevästi saanut kehittää J++:aa siihen suuntaan, kuin halusi, vaan heitti sen nurkkaan. Oikeus määräsi, että MS:n pitää pitää JVM ajan tasalla, JNI:tä yms noudatellen.

No, itse testatasin, miten käynnistän tekemäni .NET-sovelluksen linkistä. Siinä tulee käynnistyessä sellainen "puhekupla", jossa sanotaan, että: "The application is running in
Kuvittelenko vain vai puuttuuko tästä jokin linkki välistä? Tarkoittaako tämä, että jos minä en onnistu ensimmäisellä yrityksellä tekemään jotain, ko. asian tekeminen on mahdotonta? Logiikkasi toimisi lähinnä niinpäin, että väittäisit, että ei ole mahdotonta murtautua johonkin, ja sitten esittäisit, miten se murtautuminen tapahtuu.
En pyrkinyt osoittamaan sitä murtamattomaksi/turva-aukottomaksi, vaan lähinnä katsomaan, miten se resurssien suojaus toimii käytännössä.

Jos olisin tehnyt sen ohjelman VB:llä tai Delphillä, olisi ohjelmalla ollut valta tehdä mitä vaan, sillä IE:ssä/Win32:ssa ei ole juuri mitään keinoa tämän estämiseksi.

Toinen juttu on se, että löytyykö .NETistä turva-aukkoja/bugeja, joilla sen sisäänrakennetut turvaominaisuudet voi kiertää. Todennäköisesti noin uudesta alustasta sellaisia tulee vielä löytymäänkin, mutta ainakin .NETin turvallisuusarkkitehtuuri(kin) on alusta asti tehty huomioimaan erillaiset tilanteet paremmin, kuin Windowsissa aiemmin. (Enkä taaskaan sano, että se olisi jotain uutta. Useissa muissa käyttiksissä, kuten unixissa, on osattu huomioida Internetin yms uhkat paremmin alunpitäen).
-Jemm
heko Re: ei nyt ihan noinkaan
heko, 1.3.2002 20:03:08		 Pisteet: +2
Minusta se on sovelluskehittäjän ajattelemattomuutta, jos käyttää niitä laajennuksia hyödyntäviä luokkia, jos tavoitteena on siirrettävyys, kuten komponenteilla usein on.
Tapauksesta, joka eniten haittasi omaa työtäni, on jo hieman aikaa, joten muistini voi pettää, mutta tuolloin kyseessä oli käsittääkseni nimenomaan Microsoftin IDEllä tehty tuote. Minä ainakin siitä sain sellaisen vaikutelman, että Microsoft pyrki manipuloimaan tilannetta niin, että muut JVM:t eivät ole Java-bytekoodien kanssa yhteensopivia.

Miten Windows-spesifisiä komponentteja sitten _voisi_ käyttää hyväkseen Javassa ilman, että se sotisi Javan spesifikaatiota, yhtä sen tärkeimmistä ominaisuuksista ja sen kehitysideologiaa vastaan?

En pyrkinyt osoittamaan sitä murtamattomaksi/turva-aukottomaksi, vaan lähinnä katsomaan, miten se resurssien suojaus toimii käytännössä.
Ymmärsin kyllä. Tällaisesta testailusta on minusta silti aimo hyppy kategorisiin johtopäätöksiin.

(Enkä taaskaan sano, että se olisi jotain uutta. Useissa muissa käyttiksissä, kuten unixissa, on osattu huomioida Internetin yms uhkat paremmin alunpitäen).
Ei suinkaan alunpitäen. Unixia oli jo kehitetty kotvan aikaa, 60-luvun lopulta - ja se oli kirjoitettu kokonaan uusiksi toisella kielellä -, kun ensimmäinen internettiä (tai oikeammin arpanettiä) hyödyntävä unix-versio 70-luvun lopulla julkaistiin. (Ensimmäinen julkinen unix-versio oli 70-luvun alussa.) Samoihin aikoihin unixista irtautuivat jo eri kehityshaarat. Arpanettiä alettiin kehittää samoin 60-luvun lopulla, kokonaan unixista riippumatta, muutaman tutkimus- ja koulutusinstituutin välille.

Internet ei siis ollut mitenkään erityisen varhaisessa vaiheessa Unixissa mukana, eikä internetin alkuaikoina ylipäätään ajateltu, että verkko tulisi olemaan niin suuri ja turvaton kuin myöhemmin kävi ilmi.

Unixilla on ollut paljon vaikutusta internetin kehitykseen ja toisinpäin, kyllä, mutta unixin ensimmäisiä versioita suunniteltaessa ei juuri ajateltu verkkoa.

Unixia tehtiin tietysti alusta alkaen järjestelmäksi, joka suorittaa monia tehtäviä ja palvelee monia käyttäjiä yhtä aikaa, ja jo puhtaasti järjestelmän stabiliteetin kannalta katsottiin tarpeelliseksi erotella käyttäjiä ja prosesseja omiin lokeroihinsa.
--
Heikki http://www.heikkikorpela.fi heikki@heikkikorpela.fi
jemm Re: ei nyt ihan noinkaan
jemm, 1.3.2002 20:43:06		 Pisteet: +1
Minä ainakin siitä sain sellaisen vaikutelman, että Microsoft pyrki manipuloimaan tilannetta niin, että muut JVM:t eivät ole Java-bytekoodien kanssa yhteensopivia.
Saattoi Microsoftilla hyvinkin olla sellainenkin tarkoitus, en tiedä. Toisaalta he myönsivät, että Java on hyvä ja helppo kieli oppia ja se olisi soveltunut hyvin myös esimerkiksi COM-komponenttien tekoon. Nämä eivät tietenkään juuri toisilla alustoilla toimi, mutta eipä kaikki projektit aina siirrettävyyteen tähtääkään.

Sen kyllä ymmärsin itsekin, ettei välttämättä ollut kehittäjille ihan selkeää, milloin syntyi Windowsiin sidottua koodia ja milloin siitä sai siirrettävää. Luultavasti Microsoft halusi ensisijaisesti hyödyntää Javan syntaksia (vrt. C#:n samankaltaisuudet) ja siten myös pitää Javan syntaksiin tykästyneitä myös Windows-puolella.

Miten Windows-spesifisiä komponentteja sitten _voisi_ käyttää hyväkseen Javassa ilman, että se sotisi Javan spesifikaatiota, yhtä sen tärkeimmistä ominaisuuksista ja sen kehitysideologiaa vastaan?
Eipä varmaan mitenkään, jos ideologia on se lähtökohta. Monesti on vain sellaisia projekteja (esim. räätälöityjä), joissa sovelluksella on vain yksi kohdeympäristö tai asiakkaalla on määrätty alusta, jolloin on samantekevää, saako sovellusta kaikkialle.

Tällöin ei periaatteessa ole väliä, vaikka tämän alustan mahdollisia palveluita hyödynnettäisiinkin, sillä ei sitä softaa muualle kuitenkaan levitettäisi.

En pyrkinyt osoittamaan sitä murtamattomaksi/turva-aukottomaksi, vaan lähinnä katsomaan, miten se resurssien suojaus toimii käytännössä.
Ymmärsin kyllä. Tällaisesta testailusta on minusta silti aimo hyppy kategorisiin johtopäätöksiin.
Ok, oli minulla aika jyrkkä tuomio sanoa sähköpostivirusten suhteen "mahdotonta", kun nyt uudelleen luin oman tekstini. :)

Korjaan: se ole yhtä helppoa, kuin nykyään, kun .NET yleistyy (siihen menee vielä vuosia). Nyt kuka vaan script kiddie pystyy tekemään softan, joka hyödyntää com-rajapintoja (tai muita resursseja), sillä Windowsissa ei ole juuri mitään turvamekanismia sen estämiseksi (COM+:ssa sentään on jotain, mut silti).

.NETillä se ei ole yhtä helppoa - ainakaan vielä, mutta siinäkin saattaa olla jotain kiertoreittejä/turva-aukkoja, jolla se onnistuu. Sen näkee sitten, kun tulee ensimmäiset päivitykset .NETille :)

Veikkaanpa yhdeksi, tulevaksi ongelmakohdaksi, että jotkut eivät osaa hyödyntää Web Servicejä turvallisesti, vaan julkistavat niillä vahingossa liiketoimintalogiikkaansa kaikkien saataville. Yksi attribuutti väärään kohtaan koodia ja metodista tulee julkinen...

Oliskohan tuossa nyt riittävän varovainen näkökanta ;)

Unixilla on ollut paljon vaikutusta internetin kehitykseen ja toisinpäin, kyllä, mutta unixin ensimmäisiä versioita suunniteltaessa ei juuri ajateltu verkkoa.
No ei ehkä niin varhain, mutta selkeästi riittävän aikaisin, sillä matoja yms. ei ole ollut yhtä paljoa :)
-Jemm
heko Re: ei nyt ihan noinkaan
heko, 1.3.2002 22:55:15		 Pisteet: +2
Nämä eivät tietenkään juuri toisilla alustoilla toimi, mutta eipä kaikki projektit aina siirrettävyyteen tähtääkään.
Ongelmanahan on se, että usein projektin tuotoksia käytetään muissa ympärístöissä kuin mihin niitä on alunperin suunniteltu. Jos Microsoft tuntuu tylsältä esimerkiltä tässä, niin sen paikalle voi vapaasti laittaa vaikkapa Oraclen ja Javan paikalle SQL92:n. (Okei, Java istuu Sunin takana kaikesta huolimatta jossain määrin, toisin kuin SQL92 jonkun valmistajan.)

Ja sitten, kun softa pitäisi ottaa käyttöön toisessa ympäristössä, joudutaan toteamaan, että softan porttaus Solarikselle, Linuxille tai HPUXille vaatisikin lisätyötä. Mutta jos voisi saada tähän tarkoitukseen Windows-palvelimen.. ja niin pois päin.

Luultavasti Microsoft halusi ensisijaisesti hyödyntää Javan syntaksia (vrt. C#:n samankaltaisuudet) ja siten myös pitää Javan syntaksiin tykästyneitä myös Windows-puolella.
Jos Javan syntaksi oli olennainen asia, mitä haluttiin, miksi toteuttaa JVM? Ei JVM:n (varsinkaan sellaisen JVM:n, jossa on kohtuullisen hyvää voodoo-magiaa garbage collectissa ja säikeiden käsittelyssä) tekeminen nyt niin kauhean yksinkertaista ole, verrattuna siihen, että kirjoittaa natiivikääntäjän, joka hallitsee saman syntaksin.

Tällöin ei periaatteessa ole väliä, vaikka tämän alustan mahdollisia palveluita hyödynnettäisiinkin, sillä ei sitä softaa muualle kuitenkaan levitettäisi.
Hyvin usein wishful thinking.

Tarvitseeko tämä maailma tosiaan lisää roskiin kertatoteutuksen jälkeen heitettävää koodia? Lainatakseni erään entisen työtoverini sarkastista toteamusta tämäntapaisesta ideologiasta: "miksi tehdä kerralla kunnolla kun voi aina tehdä uudestaankin?"

Korjaan: se ole yhtä helppoa, kuin nykyään, kun .NET yleistyy (siihen menee vielä vuosia).
Puhutko nyt muuten .NETistä implementaationa vai designina? Onhan niitä GNU:nkin kehittelemiä .NET:iä toteuttamaan pyrkiviä implementaatioitakin kehittellä ja osin valmiinakin (mm. valmiita C#-kääntäjiä löytyy). ( http://www.dotgnu.org , http://www.go-mono.com ; Gnomen keksijä de Icaza .NET:istä: http://www.oreillynet.com/lpt/a/dotnet/2001/07/09/... )

No ei ehkä niin varhain, mutta selkeästi riittävän aikaisin, sillä matoja yms. ei ole ollut yhtä paljoa :)
Siihen on vaikuttanut varmasti montakin asiaa: luulisin, että ainakin sellaiset kuin järjestelmän suunnitteleminen lähtökohtaisesti monikäyttäjäympäristöön (vaikkei välttämättä alunperin internetiin), lähdekoodin saatavuus, ja "käyttäjäystävällisyyttä hinnalla millä hyvänsä"-ratkaisujen välttäminen.
--
Heikki http://www.heikkikorpela.fi heikki@heikkikorpela.fi
Re: ei nyt ihan noinkaan
Anonyymi kommentoija, 2.3.2002 12:56:40		 Pisteet: 0
Ongelmanahan on se, että usein projektin tuotoksia käytetään muissa ympärístöissä kuin mihin niitä on alunperin suunniteltu.
Mitäs mieltä olette Revolutionista portattavuuden kannalta? Vaikuttaa ainakin kiinnostavalta, näin ei-koodajan silmin.

"Revolution is a state-of-the-art rapid application development environment. Using Revolution, you can deliver powerful, fully-featured applications on all major platforms - quickly, easily, and royalty-free."

http://www.runrev.com/revolution/info/index.html
heko Re: ei nyt ihan noinkaan
heko, 5.3.2002 22:21:50		 Pisteet: 0

Mitäs mieltä olette Revolutionista portattavuuden kannalta? Vaikuttaa ainakin kiinnostavalta, näin ei-koodajan silmin.
Suhteellisesti varmaan parempi kuin moni muu, mutta ei ole open source, istuu yhden firman takana, implementaatioita on kaikesta huolimatta rajallinen määrä, ja kehityskieli vaikutti todella kömpelöltä ja yksipuoliselta.
--
Heikki http://www.heikkikorpela.fi heikki@heikkikorpela.fi
jemm Re: ei nyt ihan noinkaan
jemm, 1.3.2002 23:43:50		 Pisteet: +1
Luultavasti Microsoft halusi ensisijaisesti hyödyntää Javan syntaksia (vrt. C#:n samankaltaisuudet) ja siten myös pitää Javan
Jos Javan syntaksi oli olennainen asia, mitä haluttiin, miksi toteuttaa JVM? Ei JVM:n (varsinkaan sellaisen JVM:n, jossa on kohtuullisen hyvää voodoo-magiaa garbage
Niinpä. Eipä minulla oikeastaan ole mitään faktoja siitä, mitkä Microsoftin aidot intressit olivat Javan suhteen - pelkkää arvailua. Toki on selvää, ettei välit ole lämpimät suuntaan tai toiseen (MS & Sun)...

Tällöin ei periaatteessa ole väliä, vaikka tämän alustan mahdollisia palveluita hyödynnettäisiinkin, sillä ei sitä softaa muualle kuitenkaan levitettäisi.
Hyvin usein wishful thinking.
Tarvitseeko tämä maailma tosiaan lisää roskiin kertatoteutuksen jälkeen heitettävää koodia?
Niinpä, mutta sitä syntyy, kun annetaan tiukat aikataulut, tingitään suunnittelusta ja sitten parsitaan kasaan jokin systeemi ja toivotaan että hommat pelaa jne.

Itsenikin piti tutustumismielessä laatia asp.netillä uudet, suht. simppelit kotisivut, mutta eikös vain se johtanut siihen, että ensin minun pitää luoda kunnon sivunhallinta-arkkitehtuuri hyödyntäen olio-ominaisuuksia, jotta voin helpommin hallita sisältöä ja jatkossa tehdä muita sivuja nopeammin. ;)

Korjaan: se ole yhtä helppoa, kuin nykyään, kun .NET yleistyy (siihen menee vielä vuosia).
Puhutko nyt muuten .NETistä implementaationa vai designina?
Lähinnä viittasin siihen, että kestää pitkään, ennenkuin enemmistöllä on jokin .NET-alusta, mutta siksi se tuleekin palvelinpuolella/web-sovelluksissa yleistymään nopeammin suhteessa työpöytäsoftiin.

nhan niitä GNU:nkin
kehittelemiä .NET:iä toteuttamaan pyrkiviä implementaatioitakin kehittellä

Juu, tiedän.. se on ihan positiivista.

a "käyttäjäystävällisyyttä hinnalla millä hyvänsä"->ratkaisujen välttäminen.
Tuollaisia kyllä näkee liian harvoin, kun miettii, miten monta todella käyttäjäystävillästä ohjelmaa edes on...

Hmm.. tää keskustelu on kyllä haarautunut, kyllä todella alkuperäisen aiheen ohi jo :) Onneksi huhutaan, että tänne on pian tulossa hyvä keskustelufoorumi ;)
-Jemm
Re: ei nyt ihan noinkaan
mxmattil, 2.3.2002 11:48:15		 Pisteet: +1
Microsofthan lisäsi J++:ssa JVM:ään laajennuksia, joita käyttämällä pystyttiin hyödyntämään paremmin Windowsin palveluita (mm. GUI ja COM).
COM = common object model, microsoft-alustasidonnainen, suljettu komponenttimalli

Miksi ihmeessä java joka on rakennettu avoimien standardien ja alustariippumattomuuden periaatteita käyttäen pitäisi sitoa yhden suuren valmistajan alustaan? Tätähän microsoft ajoi ujuttamalla noita alustasidonnaisia asioita omaan "java" ympäristöönsä.

GUI = graphical user interface, graafinen käytöliittymä
Javalla on voinut aina tehdä graafisia käyttöliittymiä. Microsoft-alustaakin kokeilleena voin kertoa että esim. MFC:hen verrattuna javan mallit ovat paljon selkeämpiä ja noudattavat pateneja paljon järkevämmin kuin MFC.

ästä Sun ei tykännyt, vaan tuli oikeuskiista, jossa kaikki muokkaus kiellettiin - jopa JVM:n pitäminen ajantasalla. Eipä siinä oikein muu auttanut, kuin kehittää oma alusta - .NET.
Pitää muistaa että Microsoft ei ole suinkaan ainoa Sunin ulkopuolinen java-ympäristöjen valmistaja, esim. IBM valmistaa myös java-ympäristöjä ja heillä ei ole ollut ikinä mitään ongelmia sunin kanssa.

Microsoftilla oli täysi oikeus ja jopa vastuu pitää virtuaalikoneensa ajan tasalla eli uusimpien java-versioiden standardien mukaisena. Microsft ei suinkaan edes yrittänyt pitää virtuaalikonettaan uusimpien standardien mukaisena vaan yritti ujuttaa mukaan alusta- ja ohjelmointiympäristöön sidonnaisia koukkuja. Tämä on Micorosftille täysin tyypillistä toimintaa jossa vahvan aseman saanut kilpailija yritetään tuhota joko lakiteknisin keinoin esim. patentein tai koukuttamalla tietty ohjelma kiinni windowsiin siten että muilla ympäristöillä ei voida ajaa samaa ohjelmaa. Sen jälkeen aletaan sekoittaa standardeja (isoimpana esimerkkinä explorer ja verkko, activeX komponentit, HTML-liitokset jotka toimivat vain windowsissa). Tästä strategistahan on vuotanut micorosftin sisäisiä memoja julkisuuteen. Memot käsittelevät mm. ajatusta verkkostandardien patentoimista microsoftille ja niiden sekoittamista siten että vain microsoft pysyisi niissä perässä. Viitteitä memoihin en enää muista, mediassa käsiteltiin noita kohtuullsien aktiivisesti siloin kun ne vuotivat.
http://www.dvd.to - DVD hakukone
Re: ei nyt ihan noinkaan
mxmattil, 2.3.2002 11:49:33		 Pisteet: 0
Javalla on voinut aina tehdä graafisia käyttöliittymiä. Microsoft-alustaakin kokeilleena voin kertoa että esim. MFC:hen verrattuna javan mallit ovat paljon selkeämpiä ja noudattavat pateneja paljon järkevämmin kuin MFC.
Kirjoitusvirhe, piti sanoa "noudattavat patterneja"
http://www.dvd.to - DVD hakukone
Ei ennen nähty?
Avk, 1.3.2002 11:36:05		 Pisteet: 0
äiden lisäksi SP1 sisältää kokonaan uusia ohjelmapäivityksiä, jollaisia ei aikaisempien Windows-versioiden Service Packeissa nähty
Mielenkiintoista, mitähän tuo tarkoittaa? Uusin DX, MSN messenger ja Mediasoitin ängetty mukaan?
Re: Ei ennen nähty?
K2, 1.3.2002 11:47:21		 Pisteet: +1
Mielenkiintoista, mitähän tuo tarkoittaa? Uusin DX, MSN messenger ja Mediasoitin ängetty mukaan?
IDG:n pohjalta postattuani löysin hetimiten paremman ja tarkemman version uutisesta CNETistä:

http://news.com.com/2100-1040-848447.html

"Windows XP Service Pack 1 will also deliver support for technologies that could allow PC makers to extend computers beyond more staid desktop and notebook designs. Service Pack 1 will introduce support for Mira "smart" display devices, the Tablet PC and the multimedia-oriented Freestyle graphical interface. "
Blob Re: Ei ennen nähty?
Blob, 1.3.2002 11:50:22		 Pisteet: 0

Mielenkiintoista, mitähän tuo tarkoittaa? Uusin DX, MSN messenger ja Mediasoitin ängetty mukaan?
No tuon lähteen mukaan siinä suljettaisiin tuon antitrust-oikeudenkäynnin takia muutama API ja päivitetään muutenkin koko roska (tietoturvapäivitykset ja natiivit ohjelmat). Minulla on aina ollut mielikuva että ainakin nuo NT4/2000 Service Packit sisältävät pelkästään pelkästään tietoturvakorjauksia eikä se päivitä ohjelmia tai muuten muuta järjestelmää. Ilmeisesti pitää korjata tätäkin käsitystä. Ja tod. näk. joku löytää tuosta taas jonkun RSA:n oman palikan tai vastaavan ja uusia salaliittoteorioita alkaa ilmestyä :)