Varför så många versioner av Microsoft.NET ?

[jesse]

Jag tycker att det däremot borde vara binär-kompatibelt *frammåt*
D.v.s att att en kompilerad och länkad applikation mot en äldre .NET
version även ska fungera mot nyare versioner. Alltså *utan* att behöva
ha den gamla versionen installerad (det var ju det som upplevs som ett
slöseri med utrymme).

Så är jag van vid att det fungerar i miljöer där man har tänkt till lite...

Det var väl så jag tänkte ungefär, när jag skrev bakåtkompatibelt...

[TomasL]

Kanske Mono kan lösa en del av denna .NET soppa?

Mono är ett haltande subset av de äldre .NET, dvs inte speciellt bra.

[TomasL]

Bakåt och framåtkompatibilitet (vilket egentligen är bakåtkompatibilitet) är av ondo, vilket vi sett i tidigare versioner av Windows.
MS har löst detta problem med parallella installationer av libbarna och motorerna, vilket innebär att man inte behöver bekymra sig i lika hög grad att olika program är kompatibla gentemot varandra.

För att få en gammal programvara kompatibel gentemot nyare libbar och motorer, måste ju dessa vara bakåtkompatibla, vilket skapar stora problem, tyvärr.

[jesse]

Men det måste väl betyda att det blir rejält segt om man kör 3-4 program med var sin version av framework? Då ska väl alla versionerna köras samtidigt vid sidan av varandra.... För jag har en känsla av att det är en ganska tungrodd miljö att köra i.
Inte konstigt om man behöver >4 GB RAM och flera parallella processorer om man ska få burken att snurra!

[TomasL]

Inte nödvändigtvis.
Beror ju naturligtvis på vilken typ av maskin man har.

[sodjan]

> För att få en gammal programvara kompatibel gentemot nyare libbar och motorer, måste
> ju dessa vara bakåtkompatibla, vilket skapar stora problem, tyvärr.

Det är naturligtvis igen generell sanning, så klart.
Med en miljö med lite kontroll över saker och ting, och där man har "tänkt till"
redan i förväg (t.ex planerat för kompatibilitet i framtida versioner och hur det ska
lösas i arkitekturen) så är problemet redan löst i förväg, så att säga.

Där jag jobbar mest (OpenVMS) är detta inget större problem. Vi har kod med moduler
kompilerade med vitt skillda versioner av kompilatorer (blandat COBOL, C och Fortran
med flera versioner av kompilatorer för alla) i samma EXE som körs på olika versioner av
operativsystem och olika versioner av runtime "sharables" för alla språk. Fungerar OK.
Det kan skilja över 10 år på release av de olika kompilatorerna. Vi kompilerar program
idag och länkar med obj-filer kompilerade med gamla kompilatorer på 90-talet.

Visst, egenteligen skulle vi behöva kompilera om rubbet med senaste kompilator,
men det finns inte tid till det (eller ett tvingande behov)...

[TomasL]

Naturligtvis inte.
Ett stort problemet är väl att många program är skrivna av inkompetenta programmerare som skiter i APIerna osv.
Det är ju naturligtvis en mycket stor skillnad mellan VMS och WIN/Linux mm, där LIB-problemet är mycket stort, speciellt i Linux, MS verkar ha fixat det nu med SideBySide och .net, i linux finns det tyvärr fortfarande kvar.
Jag gissar att VMS inte har ändrat sina APIer så mycket över åren, samt att kraven på grafik/spel mm inte är så stora, vilket förenklar det hela en smula.

Samtidigt så vill fler och fler kunna skriva program och traditionella C/C++ är för komplicerat för massan, vilket i sin tur, på gott och ont skapat C# mm och .Net

[sodjan]

> Jag gissar att VMS inte har ändrat sina APIer så mycket över åren,

Över ca 30 år.
Det gäller samma call-standard, system-services o.s.v som då. I princip.
Skillnaden är mellan lösningar som är "engineered" från grunden och de som
är hopplappade under resans gång med ständinga "compatibility breaks".
Det vill jag påstå gäller Win-miljön, samt Linux och i princip större delen av
open-source världen för övrigt.

> samt att kraven på grafik/spel mm inte är så stora,

Sant, det finns stöd för X11/Motif o.s.v, men väldigt få använder det.
Det är primärt en serverplattform. VMS workstations försvann för många
år sedan.

[jesse]

Jag känner igen debatten här från flera tidigare liknande trådar. Det är OT!
Håll er till ämnet eller starta en egen tråd om OpenVMS.

[sodjan]

Jag anser att det är rellevant att diskutera arkitekturer
och hur man kan lösa saker och ting i samband med t.ex
just det som diskuteras i denna tråd.

[jesse]

Nåja,,, forsätt om ni vill då. Men det började påminna om en av alla dessa åsiktskrig om vilken plattform som är bäst... och den diskussionen tar antagligen aldrig slut

[sodjan]

Det handlar inte om "bäst" utan om olika sätt att lösa saker och ting.
Att vidga vyerna utifrån sin egen lilla värld.

[stekern]

Över ca 30 år.
Det gäller samma call-standard, system-services o.s.v som då. I princip.
Skillnaden är mellan lösningar som är "engineered" från grunden och de som
är hopplappade under resans gång med ständinga "compatibility breaks".
Det vill jag påstå gäller Win-miljön, samt Linux och i princip större delen av
open-source världen för övrigt.

En anledning till att de kunnat hålla APIt stabilt över 30 år är väl att behoven
inte ändrats märkvärt på 30 år?
För "skrivbordsmarknaden" är ju situationen lite annan.

I Linux-kärnan har de ganska strikta regler emot API breaks,
i regel tillåts inte sådant utan APIn döms som "utgångna" tills inte någon använder dem längre.
Först då kan APIerna tas bort.

I övrigt är det väl lite att väga utveckling jämte bakåtkompabilitet,
givetvis skapar det besvär och i vissa fall är säkert en del beslut felaktiga.

[emwtur]

själva runtime miljön (CLR) har ändrats tre gånger !
1.0 2.0 4.0
däremellan har det kommit ett antal frameworks som bygger på sina resp runtime.
frameworks'en innehåller egentligen grunderna som man bygger sina program på , man kan inte ge programmerarna ny funktionalitet utan att göra en ny version av frameworken.
just nu är det väl en hel del som sitter med problemet att dom vill ha funktionalitet från framework 4 men funderar på vilken version av CLR som detta kommer att kräva och vilka OS som dom går att installera på.

röran är nog i slutändan mindre än det var innan med olika versioner av VC++ runtimes som måste installeras !

[Nerre]

Vi kompilerar program
idag och länkar med obj-filer kompilerade med gamla kompilatorer på 90-talet.

Men då länkar ni väl statiskt? D.v.s. länkar in de gamla libbarna i programmet?

Länkar man statiskt har man ju aldrig några problem, då är ju varje program helt fristående. Hela den här diskussionen handlar ju om dynamiska libbar, d.v.s. där flera program delar på dem.