mboost-dp1
unknown
så fik richard grimes aligevel ret
Richard Grimes on .NET - February 1, 2005
Richard Grimes on .NET - February 1, 2005
Spørgsmålet er kun hvor hårdt longhorn flopper. Det virker som om microsoft står med vaporware på hånden. Men det kan måske være en godting, et produkt der virkeligt viser microsoft, at for at få folk til at opgradere, så skal der præsteres noget. Se på Apple f.eks. de smider en ny update ca. hver 18 måned, til fuld pris. Folk køber det, fordi der er noget nyt og spændende hvergang.
Det kunne Microsoft lære noget af.
Det kunne Microsoft lære noget af.
det er lidt mærkeligt det der står her, der står at det ikke er klart til at implementere os, men... der er jo ikke snakke om kernen, men userspace, og .net runtime'en er fint god nok til at blive brugt til userspace..
#7 ahva?
Managed code er "bare" kode der kører under .net's VM, og kan derfor styres mht. til adgang til resourcer. Dermed kan VM'en styre hvad du må og ikke må. Der er altså et lag uden om koden som overvåger hvad selve koden gør, modsat på nuværende måde hvor kode bare gør hvad det har lyst (næsten).
Managed code er "bare" kode der kører under .net's VM, og kan derfor styres mht. til adgang til resourcer. Dermed kan VM'en styre hvad du må og ikke må. Der er altså et lag uden om koden som overvåger hvad selve koden gør, modsat på nuværende måde hvor kode bare gør hvad det har lyst (næsten).
Longhorn er begyndt at lyde som Windows XP SP3/4?... ;)
Altså efterhånden med så få nyskabende ting med fra starten, at det nemt kunne inkluderes via en servicepack istedet for...
Humoristiske sjæle er også så småt begyndt, at kalde den for Shorthorn. Men hvor interessant / attraktiv den bliver / er vil jeg lade være op til folk selv at afgøre... ;)
Altså efterhånden med så få nyskabende ting med fra starten, at det nemt kunne inkluderes via en servicepack istedet for...
Humoristiske sjæle er også så småt begyndt, at kalde den for Shorthorn. Men hvor interessant / attraktiv den bliver / er vil jeg lade være op til folk selv at afgøre... ;)
#11
Vi skal jo ikke glemme at:
Windows NT (4.0)
Windows 2000 (5.0)
Windows XP (5.1)
Windows 2003 (5.2)
Windows Longhorn (6.0)
Tror næppe at Windows Longhorn kommer til at ligne Windows XP, sagen er om nogen vil bruge penge på at opgradere!
Men som WinBeta.org skriver: The 'Dirty Little Secret' About Longhorn så har de ret :)
Vi skal jo ikke glemme at:
Windows NT (4.0)
Windows 2000 (5.0)
Windows XP (5.1)
Windows 2003 (5.2)
Windows Longhorn (6.0)
Tror næppe at Windows Longhorn kommer til at ligne Windows XP, sagen er om nogen vil bruge penge på at opgradere!
Men som WinBeta.org skriver: The 'Dirty Little Secret' About Longhorn så har de ret :)
#8
Faktisk ikke rigtig. Managed code er ikke specifikt for MS .NET. Desuden kan du ikke definere det som noget der kører på en virtuel maskine. Du kan sagtens kode unmanaged code i .NET og det kører skam stadig på .NET VM.
Den største forskel på .NET managed code og almindelig kode er som #9 siger hvilket abstraktionslag der er mellem programøren og maskinen i form af memory management og sådan nogle ting.
#10
Nej ikke nødvendigvis. Både Java og .NET har managed code, og både Java og .NET har en VM (af en art... .NET er nu meget anderledes end Java på det punkt så det svider lidt at kalde det en VM) og de 2 ting hænger sammen, men i teorien er de ikke afhængige af hinanden.
Faktisk ikke rigtig. Managed code er ikke specifikt for MS .NET. Desuden kan du ikke definere det som noget der kører på en virtuel maskine. Du kan sagtens kode unmanaged code i .NET og det kører skam stadig på .NET VM.
Den største forskel på .NET managed code og almindelig kode er som #9 siger hvilket abstraktionslag der er mellem programøren og maskinen i form af memory management og sådan nogle ting.
#10
Nej ikke nødvendigvis. Både Java og .NET har managed code, og både Java og .NET har en VM (af en art... .NET er nu meget anderledes end Java på det punkt så det svider lidt at kalde det en VM) og de 2 ting hænger sammen, men i teorien er de ikke afhængige af hinanden.
Mon ikke stadig WinFX kommer til at erstatte Win32 API'et og .NET derfor stadig får en central rolle. Jeg vil da også tro at både Indigo og Avalon stadig udvikles op imod .NET, det ville virke underligt at lave så radikal en ændring på nuværende tidspunkt.
Spørgsmålet er hvad der helt præcist henvises til med "komponenter" i Longhorn og hvad der opfattes som værende "en del af core".
Spørgsmålet er hvad der helt præcist henvises til med "komponenter" i Longhorn og hvad der opfattes som værende "en del af core".
#13 Hvordan er Java og .NET så meget anderledes? De har begge en fortolker som sørger for at fortolke bytekode til det system det kører på, og meget af denne bytekode kan oversættes 1:1 mellem Java og .NET. Jeg er bare nysgerrig.
#11 At hæve versionsnummeret siger vel ikke så meget om hvor stor forskellen er på to systemer? Hvis MS havde haft lyst kunne de da sagtens have kaldt Win2k for 5.0 og WinXP for 6.0.
#11 At hæve versionsnummeret siger vel ikke så meget om hvor stor forskellen er på to systemer? Hvis MS havde haft lyst kunne de da sagtens have kaldt Win2k for 5.0 og WinXP for 6.0.
#3
Apple har også den fordel at de lavede tingene rigtigt fra starten af og OSX har haft lang tid til at modne i NextSTEP formen op igennem 90'erne. Derfor er det nemmere at udvide og skabe nye og stærke funktioner med.
Det var ved at gå galt for dem med MacOS7, 8 og 9, hvor de faktisk sad i samme situation med Copland, et nyt OS der skulle bryde de tidligere restriktioner, men aldrig kom nogen vegne, da det blev dømt for stort og svært at lave. De endte med at droppe det og udgive MacOS8 og 9, der lider af samme problemer som Windows: Langsommere og mere komplekst at arbejde med for hver version.
OSX er lige modsat.
Longhorn kunne have givet MS en kæmpe fordel, men ambitionerne ser ud til at vælte dette. Hvis de istedet havde givet sig til at starte forfra med et OS på linje med XP i 2000, med udgangspunkt i sikkerhed, havde skidt højt og flot på kompatibilitet (ja, risikabelt, men...) og havde brugt 3-4 år på det i stedet for XP SP2, så havde situationen nok været helt anderledes for MS idag.
Apple har også den fordel at de lavede tingene rigtigt fra starten af og OSX har haft lang tid til at modne i NextSTEP formen op igennem 90'erne. Derfor er det nemmere at udvide og skabe nye og stærke funktioner med.
Det var ved at gå galt for dem med MacOS7, 8 og 9, hvor de faktisk sad i samme situation med Copland, et nyt OS der skulle bryde de tidligere restriktioner, men aldrig kom nogen vegne, da det blev dømt for stort og svært at lave. De endte med at droppe det og udgive MacOS8 og 9, der lider af samme problemer som Windows: Langsommere og mere komplekst at arbejde med for hver version.
OSX er lige modsat.
Longhorn kunne have givet MS en kæmpe fordel, men ambitionerne ser ud til at vælte dette. Hvis de istedet havde givet sig til at starte forfra med et OS på linje med XP i 2000, med udgangspunkt i sikkerhed, havde skidt højt og flot på kompatibilitet (ja, risikabelt, men...) og havde brugt 3-4 år på det i stedet for XP SP2, så havde situationen nok været helt anderledes for MS idag.
de skal jo have solgt deres produkter, og indtil videre går der ihvertfald 2 år før vi ser den på gaden.. (ikke?) til den tid kan det jo godt være at winXP ikke er tilstrækkelig mere. Og de så lige pludselig trækker en kanin op af hatten.. en ting er ihvertfald sikkert, de har aldrig været dårlige til at sælge deres produkter.. så.. dødsdøm den nu ikke så hurtigt..
#15 Bortset fra, at så let går det ikke. Selve sproget adskiller sig. I .NET er DateTime og long f.eks. value/primitive typer mens i Java er Date og Long reference typer. I Java findes ingen statiske konstruktører eller pointere eller mulighed for at kalde Windows legacy kode.
Også API'et er så anderledes at det ikke umiddelbart lader sig gøre med mindre man er villig til selv at lave et Java kompatibelt library på .NET og omvendt. (Det er ingen villig til!)
Næppe, alt... jeg gentager ALT i Windows bruger det famiøse Win32/64 API og således komplementerer WinFX blot det gamle. Det havde været rart med nye rene implementationer men Windows er for stort og komplekst (og skal virke med eksisterende legacy kode) så vi må nok desværre berede os på en ordentlig lagkage af et OS.
Man kan forestille sig, at om ~5 års tid tager WinFX helt over, ligesom man så det med DOS i Win95 til nu hvor det er en simpel emulering.
Også API'et er så anderledes at det ikke umiddelbart lader sig gøre med mindre man er villig til selv at lave et Java kompatibelt library på .NET og omvendt. (Det er ingen villig til!)
Mon ikke stadig WinFX kommer til at erstatte Win32 API'et...
Næppe, alt... jeg gentager ALT i Windows bruger det famiøse Win32/64 API og således komplementerer WinFX blot det gamle. Det havde været rart med nye rene implementationer men Windows er for stort og komplekst (og skal virke med eksisterende legacy kode) så vi må nok desværre berede os på en ordentlig lagkage af et OS.
Man kan forestille sig, at om ~5 års tid tager WinFX helt over, ligesom man så det med DOS i Win95 til nu hvor det er en simpel emulering.
#17 Jeg tror nok at de skal få det solgt. Sådan noget som Windows sælger man ikke på teknisk indsægt eller teknisk overlegenhed. Det sælger man med linjer som "det sikreste Windows til dato" eller "nye multimedieudvidelse gør det nu muligt at [indsæt selv et eller andet]". Forstå mig nu ret, det resterende 95% af Windows-brugerene er ligeglade med WinFX, .NET og WinFS.
#15
Det er faktisk kun Java der har en fortolker indbygget i deres JVM. Og det er også kun Java der oversætter koden til bytecode, hvor .NET bliver oversat til et mellemsprog (IL) der minder lidt om en slags pseudo assembly kode. Mellemsproget er et rigtigt sprog, og det betyder også at det er meget let integrerbart. Du kan f.eks kode noget funktionalitet i c# eller vb.net, og den compilerede kode vil i teorien være den samme ligegyldig hvad hvad du valgte. (Naturligvis hvis man kan regne med at man bruger den samme kodestil) Du kunne vælge at kompilere den til en DLL-fil og så ville du i alle .NET sprog frit kunne kalde offentlige metoder i den compilerede kode. Det kan man ikke med Java, dels fordi java bytecode ikke er et rigtigt sprog.
Når koden er blevet compilet (Jave til bytecode, .NET til mellemsproget MSIL) kan det afvilkes hvis man har et runtime enviroment som Sun kalder det eller framework som MS kalder det. Her er der også forskel på hvordan det behandles. Det er jo her java fortolkeren kommer ind i billedet. Bytecode skal fortolkes og oversættes før det kan udføres. MSIL skal bare oversættes.
.NET kode er faktisk extremt hurtigt at afvikle i forhold til Java (selvom som #20 siger at der er sket meget siden Javas fødsel) men det bruger tilgengæld en hel del hukommelse.
Det er faktisk kun Java der har en fortolker indbygget i deres JVM. Og det er også kun Java der oversætter koden til bytecode, hvor .NET bliver oversat til et mellemsprog (IL) der minder lidt om en slags pseudo assembly kode. Mellemsproget er et rigtigt sprog, og det betyder også at det er meget let integrerbart. Du kan f.eks kode noget funktionalitet i c# eller vb.net, og den compilerede kode vil i teorien være den samme ligegyldig hvad hvad du valgte. (Naturligvis hvis man kan regne med at man bruger den samme kodestil) Du kunne vælge at kompilere den til en DLL-fil og så ville du i alle .NET sprog frit kunne kalde offentlige metoder i den compilerede kode. Det kan man ikke med Java, dels fordi java bytecode ikke er et rigtigt sprog.
Når koden er blevet compilet (Jave til bytecode, .NET til mellemsproget MSIL) kan det afvilkes hvis man har et runtime enviroment som Sun kalder det eller framework som MS kalder det. Her er der også forskel på hvordan det behandles. Det er jo her java fortolkeren kommer ind i billedet. Bytecode skal fortolkes og oversættes før det kan udføres. MSIL skal bare oversættes.
.NET kode er faktisk extremt hurtigt at afvikle i forhold til Java (selvom som #20 siger at der er sket meget siden Javas fødsel) men det bruger tilgengæld en hel del hukommelse.
Et system baseret på managed code kunne være lidt af et kup for MS, de kunne løse den største designfejl i Windows med et slag. I et MS styresystem kan alle processer der kører under samme bruger (mener kun det er samme bruger), manipulere hukommelsen for alle andre applikationer der kører som den bruger direkte. That's scary!
Det betyder reelt set at du kan have en applikation der sidder og overvåger hvad en anden applikation laver, og hijacke programmet når det når et vist status, eller manipulere forskellige ting. Hvis .Net kunne fixe det for MS, kunne det være sjovt for dem, for de kan ikke selv fixe det uden at fjerne bagudkompatibiliteten.
Det betyder reelt set at du kan have en applikation der sidder og overvåger hvad en anden applikation laver, og hijacke programmet når det når et vist status, eller manipulere forskellige ting. Hvis .Net kunne fixe det for MS, kunne det være sjovt for dem, for de kan ikke selv fixe det uden at fjerne bagudkompatibiliteten.
#22
Nej det passer sgu ikke. Det er i hvert fald det første jeg nognesinde har hørt om en sådan fejl, og jeg kan ikke forestille mig at jeg ikke ville have hørt om det.
Hvor har du læst det? Windows har faktisk i alle NT version haft beskyttede adresserum både i bruger og kerne mode, jeg kan ikke forestille mig at du har ret.
I DOS var der ikke denne distance men... nej jeg er sgu ret sikker på at du tar fejl.
Nej det passer sgu ikke. Det er i hvert fald det første jeg nognesinde har hørt om en sådan fejl, og jeg kan ikke forestille mig at jeg ikke ville have hørt om det.
Hvor har du læst det? Windows har faktisk i alle NT version haft beskyttede adresserum både i bruger og kerne mode, jeg kan ikke forestille mig at du har ret.
I DOS var der ikke denne distance men... nej jeg er sgu ret sikker på at du tar fejl.
#21 ??
MSIL er vel ikke decideret manskinkode eller er det?
Enten bruger fungere .net som en slags kompiler eller også kommer den med en fortolker.
Perl der normalt set er et fortolket sprog kompiler så vidt jeg ved tingene til maskinkode inden der sker noget som helst andet, er det sådan MS.Net virker eller?
SUN's java gør svjv begge dele altså den har en fortolker men den kompilere også tingene.
I teorien giver det lidt overhead men det betyder også at java teoretisk set vil kunne knuse tal meget bedre end .net, net
op fordi Sun Hotspot kan optimere maskinkoden på en måde MS.Net ikke kan tilade sig fordi den kun får et forsåg og at den har travlt!
En anden forskel er vel at java er en selvstendig platform der lever i sit eget miljø mens .Net er på en anden måde er den slags udvidelse til systemet.
Min fornemmelse ved at tage tid på java og .net baserede programmer er at java ikke er stort langsommere, men det er selvfølgeligt ikke sant med alle JRE'er.
MSIL er vel ikke decideret manskinkode eller er det?
Enten bruger fungere .net som en slags kompiler eller også kommer den med en fortolker.
Perl der normalt set er et fortolket sprog kompiler så vidt jeg ved tingene til maskinkode inden der sker noget som helst andet, er det sådan MS.Net virker eller?
SUN's java gør svjv begge dele altså den har en fortolker men den kompilere også tingene.
I teorien giver det lidt overhead men det betyder også at java teoretisk set vil kunne knuse tal meget bedre end .net, net
op fordi Sun Hotspot kan optimere maskinkoden på en måde MS.Net ikke kan tilade sig fordi den kun får et forsåg og at den har travlt!
En anden forskel er vel at java er en selvstendig platform der lever i sit eget miljø mens .Net er på en anden måde er den slags udvidelse til systemet.
Min fornemmelse ved at tage tid på java og .net baserede programmer er at java ikke er stort langsommere, men det er selvfølgeligt ikke sant med alle JRE'er.
#25
MSIL er "typestærkt objektorienteret assembler kode":
Når du skriver noget kode i .Net bliver det 1) kompileret til en Assembly som indeholder MSIL og noget metadata. Når koden så 2) skal eksekveres af en Runtime Host (såsom Windows, Mono, SQL2005, ...) bliver koden 3) oversat til Native Code (= CPU specifik maskinkode) og 4) eksekveret JIT.
Det er den såkaldte "Managed Execution Process" som Microsoft benytter.
Den store styrke, som jeg ser det, ved .Net er at de på forhånd har indset at de ikke kan lave det perfekt udviklingsmiljø i første hug. Derfor har MS indført Side-by-Side Execution som muliggør at kode komplieret til .Net v.1.0 og snakke med kode udviklet til .Net v.1.1. Derudover kan flere versioner af samme assembly eksistere samtidigt på samme Runtime Host, hvilket én gang for alle gør op med DLL-Hell...
Håber det var svar på din undren - ellers skriver du bare igen ;)
MSIL er "typestærkt objektorienteret assembler kode":
MSIL includes instructions for loading, storing, initializing, and calling methods on objects, as well as instructions for arithmetic and logical operations, control flow, direct memory access, exception handling, and other operations
Når du skriver noget kode i .Net bliver det 1) kompileret til en Assembly som indeholder MSIL og noget metadata. Når koden så 2) skal eksekveres af en Runtime Host (såsom Windows, Mono, SQL2005, ...) bliver koden 3) oversat til Native Code (= CPU specifik maskinkode) og 4) eksekveret JIT.
Det er den såkaldte "Managed Execution Process" som Microsoft benytter.
Den store styrke, som jeg ser det, ved .Net er at de på forhånd har indset at de ikke kan lave det perfekt udviklingsmiljø i første hug. Derfor har MS indført Side-by-Side Execution som muliggør at kode komplieret til .Net v.1.0 og snakke med kode udviklet til .Net v.1.1. Derudover kan flere versioner af samme assembly eksistere samtidigt på samme Runtime Host, hvilket én gang for alle gør op med DLL-Hell...
Håber det var svar på din undren - ellers skriver du bare igen ;)
#27 -
28. maj 2005 21:37
23 har ret, der er (selvfølgeligt) beskyttede adresserum mellem programmer.
Mht. 'managed kode', er det ikke en gammel nyhed at den virtuelle maskine har sin egen hukommelsesstyring? Det er vel netop en af grundene til at køre i virtuel maskine fremfor at oversætte koden til maskinsprog direkte.
Ikke at jeg har undersøgt det, men burde det ikke være logik at en virtuel platform har beskyttede adresserum programmerne imellem? Ellers er det jo livsfarligt at tilgå netbank vha. javaprogrammer.
Mht. 'managed kode', er det ikke en gammel nyhed at den virtuelle maskine har sin egen hukommelsesstyring? Det er vel netop en af grundene til at køre i virtuel maskine fremfor at oversætte koden til maskinsprog direkte.
Ikke at jeg har undersøgt det, men burde det ikke være logik at en virtuel platform har beskyttede adresserum programmerne imellem? Ellers er det jo livsfarligt at tilgå netbank vha. javaprogrammer.
#27
Ja beskyttede adresserum på den måde at du ikke bare kan bruge pointerearithemic el.lign. og derved ved et uheld komme ind i et andet programs hukommelsesrum. Men der er stadig operationer i win32 api'et der tillader dig at analysere og modificere hukommelsen på et program der kører på samme account.
Jeg skal ikke kunne sige om programmer på en eller anden måde kan flagge deres hukommelse så det er umuligt, men jeg ved muligheden findes, og den er bredt anvendt. Og igen, prøv at forklar hvordan en game trainer fungerer uden at kunne det.
Ja beskyttede adresserum på den måde at du ikke bare kan bruge pointerearithemic el.lign. og derved ved et uheld komme ind i et andet programs hukommelsesrum. Men der er stadig operationer i win32 api'et der tillader dig at analysere og modificere hukommelsen på et program der kører på samme account.
Jeg skal ikke kunne sige om programmer på en eller anden måde kan flagge deres hukommelse så det er umuligt, men jeg ved muligheden findes, og den er bredt anvendt. Og igen, prøv at forklar hvordan en game trainer fungerer uden at kunne det.
#29 -
28. maj 2005 22:08
28: Nu ved jeg ikke helt hvad en 'spil trainer' er, men hvis kernen tillader det, så må man alt. Hvis man er tilpas kløgtig kan man godt indlæse et kernemodul hvorigennem man kan peek'e og poke som i Commodore 64 dagene, eller laver sin egen tastaturlæser hvis man godt vil kende adgangskoder osv. Om Windows allerede har en sådan bagdør i deres api'er ved jeg ikke, men i så fald er det en noget giftig funktionalitet sikkerhedsmæssigt.
I Unix kan man selvfølgelig godt sætte interkommunikationskanaler op mellem programmerne; det er fuldt tilladt.
I Unix kan man selvfølgelig godt sætte interkommunikationskanaler op mellem programmerne; det er fuldt tilladt.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund