---

Jeg arbejder i en virksomhed, hvor vi i edb-afdelingen er to ansatte.
Vi er begge begejstret for Microsoft-platformen, som vi finder meget
produktiv. Om kort tid skal vi have strategimøde med ledelsen, hvor
overskriften er "hvad gør vi i fremtiden?".

Vi benytter MS-SQL, samt Office-pakken, der hos os er kraftigt
integreret i forhold til hinanden. Herudover har vi nogle hjemmesider
lavet i ASP.

Min kollega er begyndt at snige sig ind på ASP.Net, og jeg selv er ved
at vende snuden fra VB6 til VB.Net.

Men hvad er holdningen hos Jer, omkring .Net som fremtiden
(godt/skidt)? Hvilke alternativer bør overvejes, og ikke mindst:
hvorfor?

Vi har mange distribuerede løsninger i form af
VB/Access-applikationer, hvilket skal med i overvejelserne.

Jeg er ikke interesseret i ideologi og monopol-snak, vedr. emnet, men
primært "hvorfor/hvorfor ikke" .Net?


X-POST:
dk.edb.programmering.basic.visual-basic,dk.edb.programmering.java,dk.edb.programmering.perl

FUT: dk.edb.programmering.dotnet


mvh /Snedker
---
http://dbconsult.dk
Email: mortenatdbconsultdotdk

---

In dk.edb.programmering.perl Morten Snedker <mortenatdbconsultdotdk> wrote:
> X-POST:
> [snip]dk.edb.programmering.perl

Hvad havde det med Perl at gøre?

--
Rune B. Broberg
Feel free to GPG-encrypt email sent to me. Keyid: 0x67A4976D

---

On Fri, 13 Aug 2004 08:11:14 +0000 (UTC), "Rune B. Broberg"
<mihtjel@daimi.au.dk> wrote:

>In dk.edb.programmering.perl Morten Snedker <mortenatdbconsultdotdk> wrote:
>> X-POST:
>> [snip]dk.edb.programmering.perl
>
>Hvad havde det med Perl at gøre?

Ingenting - mit indlæg ramte delvist forkert. Beklager.

Mvh /Snedker
---
http://dbconsult.dk
Email: mortenatdbconsultdotdk

---

On Fri, 13 Aug 2004 08:11:14 +0000 (UTC), "Rune B. Broberg"
<mihtjel@daimi.au.dk> wrote:


>> [snip]dk.edb.programmering.perl
>
>Hvad havde det med Perl at gøre?

Ik' så meget. Mis-placeret indlæg. Beklager.

mvh /Snedker
---
http://dbconsult.dk
Email: mortenatdbconsultdotdk

---

For window's vedkommende kommer alt til at hedde .NET når longhorn udkommer
om få år. Indtil da vil Microsoft forsøge at få så mange som muligt til at
"øve" sig i at bruge .NET, sådan at når longhorn udkommer er der allerede
mange applikationer der kører over .NET. Det er Microsofts helt klare
strategi, og den bliver der helt sikker ikke lavet om på. Resten af verden
kører lidt på en blanding af forskellige strategier og løsninger, hvor java
på en måde er omdrejningspunkt. For mig at se har dette kludetæppe med
ufatteligt mange interesseparter et alvorligt problem i forhold til en
helstøbt og gennemtænkt strategi for en hel platform (Windows).

Indenfor open source har jeg en idé om at Novell har forstået denne
problemstilling, og derfor arbejdes der lystigt på at videreudvikle Mono der
er en komplet implementation af .NET framework (netop udkommet i version
1.0). Jeg tror tilmed at Novell går og tænker over at forsøge at integrere
Mono og Gnome (måske i en fork), således at open source verden kan
præsentere en ligeså konsistent og helstøbt løsning som Microsoft på et
tidspunkt efter longhorn er udkommet.

---

On Fri, 13 Aug 2004 12:06:55 +0200, "Thomas Thorsen [9000]"
<ttho02@kom.aau.dk> wrote:

>Indenfor open source har jeg en idé om at Novell har forstået denne
>problemstilling, og derfor arbejdes der lystigt på at videreudvikle Mono der
>er en komplet implementation af .NET framework

Mono er bare v1.0. Ikke komplet. Endnu Men jeg kan da kun hilse
ting som Mono velkomment.

--
Jacob

---

On Fri, 13 Aug 2004 12:06:55 +0200, "Thomas Thorsen [9000]"
<ttho02@kom.aau.dk> wrote:


>Indenfor open source har jeg en idé om at Novell har forstået denne
>problemstilling, og derfor arbejdes der lystigt på at videreudvikle Mono der
>er en komplet implementation af .NET framework (netop udkommet i version
>1.0). Jeg tror tilmed at Novell går og tænker over at forsøge at integrere
>Mono og Gnome (måske i en fork), således at open source verden kan
>præsentere en ligeså konsistent og helstøbt løsning som Microsoft på et
>tidspunkt efter longhorn er udkommet.

Skal det forstås således, at det Novell med tiden (om alt går vel) vil
tilbyde, er et værktøj til udvikling applikationer, og at dette
udviklingsværktøj vil basere sig på .NET framework?

Vil sourcekode fra et Mono-projekt kunne benyttes af ex. Visual Studio
..Net og vice versa?


mvh /Snedker
---
http://dbconsult.dk
Email: mortenatdbconsultdotdk

---

Morten Snedker wrote:
> On Fri, 13 Aug 2004 12:06:55 +0200, "Thomas Thorsen [9000]"
> <ttho02@kom.aau.dk> wrote:
>
>
>> Indenfor open source har jeg en idé om at Novell har forstået denne
>> problemstilling, og derfor arbejdes der lystigt på at videreudvikle
>> Mono der er en komplet implementation af .NET framework (netop
>> udkommet i version
>> 1.0). Jeg tror tilmed at Novell går og tænker over at forsøge at
>> integrere Mono og Gnome (måske i en fork), således at open source
>> verden kan præsentere en ligeså konsistent og helstøbt løsning som
>> Microsoft på et tidspunkt efter longhorn er udkommet.
>
> Skal det forstås således, at det Novell med tiden (om alt går vel) vil
> tilbyde, er et værktøj til udvikling applikationer, og at dette
> udviklingsværktøj vil basere sig på .NET framework?

Det *er* en ækvivalent platform, med den samme funktionalitet. Med tiden vil
Novell måske integrerere mono så meget i gnome, at linux vil få et desktop
environment der kan matche Longhorn. Selvfølgelig er der også den mulighed
at der er nogen der finder en 3. vej.

> Vil sourcekode fra et Mono-projekt kunne benyttes af ex. Visual Studio
> .Net og vice versa?

Mono svarer til .NET Framework, men Visual Studio svarer til MonoDevelop,
som er et spinoff af SharpDevelop, der er et IDE til C# udvikling på .NET
Framework (Ligesom Visual Studio). MonoDevelop er et IDE til udvikling på
Mono.

Der er selvfølgelig import/eksport funktioner til projekter i de forskellige
IDE's, men selve sourcekoden (C# antaget) er standardiseret og vil direkte
kunne overføres, så længe den ikke er platform specifik (f.eks.
windows.forms). Det betyder f.eks. at hvis du har tegnet en form i Visual
Studio, så vil den ikke kunne bruges på Mono, men hvis du laver en klasse
der til komplekse tal i en .cs fil, så er der ingen problemer. Bruger du
derimod GTK# i stedet for windows.forms, så vil du kunne lave binære
programmer der uden genkompilering kan køre på både Windows og Linux.

---

>>
>>> Indenfor open source har jeg en idé om at Novell har forstået denne
>>> problemstilling, og derfor arbejdes der lystigt på at videreudvikle
>>> Mono der er en komplet implementation af .NET framework (netop
>>> udkommet i version
>>> 1.0). Jeg tror tilmed at Novell går og tænker over at forsøge at
>>> integrere Mono og Gnome (måske i en fork), således at open source
>>> verden kan præsentere en ligeså konsistent og helstøbt løsning som
>>> Microsoft på et tidspunkt efter longhorn er udkommet.
>>
>> Skal det forstås således, at det Novell med tiden (om alt går vel) vil
>> tilbyde, er et værktøj til udvikling applikationer, og at dette
>> udviklingsværktøj vil basere sig på .NET framework?
>
> Det *er* en ækvivalent platform, med den samme funktionalitet. Med tiden
> vil
> Novell måske integrerere mono så meget i gnome, at linux vil få et desktop
> environment der kan matche Longhorn. Selvfølgelig er der også den mulighed
> at der er nogen der finder en 3. vej.

Det er på ingen måde en ækvivalent platform.

Microsofts platform indeholder SQL Server, Exchange, IIS, Office serien,
Avalon UI i Longhorn, ... Mono er blot et eller to sprog, et class library,
en MSIL fortolker/compiler (som til gengæld kan køre på rigtigt mange
platforme) og ikke meget mere.

Hvis man skal lave seriøse .NET apps (og dette gælder i øvrigt også Java),
så bliver applikationen ret hurtigt afhængig at hele platformen.

Hele denne snak om Mono minder mig meget om snakken omkring Unix for mange
år siden. Alle programmer blev dengang skrevet i C. Vi havde et fint
funktionsbibliotek. Et velskrevet program som holdt sig indenfor platformen
kunne i teorien køre alle steder. Men så kom forskellige libraries til X
windows, forskellige databaser, etc. Og vupti, så kunne software kun køre på
den/de platforme det var designet til.

Mono er et sjovt forskningsprojekt, men bliver i mine øjne ikke andet.

- Per

---

Per Olsen wrote:

> Mono er et sjovt forskningsprojekt, men bliver i mine øjne ikke andet.

Mjah, mon ikke det kommer godt med på et tidspunkt. Der er jo da
adskillige database servere til Linux f.eks.

Der er dog ikke tvivl i mit sind om Mono vil altid halte bagefter i
forhold til .net. Mono er f.eks. kun lige akkurat kommet i 1.0, som
funktionsmæssigt mangler en del i forhold til .net 1.0, og Microsoft
har 2.0 lige på trapperne.

--
Thomas Due
Posted with XanaNews version 1.16.3.1

"If you can't convince them, confuse them."
-- Harry S. Truman

---

>> Mono er et sjovt forskningsprojekt, men bliver i mine øjne ikke andet.
>
> Mjah, mon ikke det kommer godt med på et tidspunkt. Der er jo da
> adskillige database servere til Linux f.eks.
>
> Der er dog ikke tvivl i mit sind om Mono vil altid halte bagefter i
> forhold til .net. Mono er f.eks. kun lige akkurat kommet i 1.0, som
> funktionsmæssigt mangler en del i forhold til .net 1.0, og Microsoft
> har 2.0 lige på trapperne.

Jo, men alle databaser er ikke ens (selv dem der er nogenlunde lige gode).
Der er forskellige måder at gøre forskellige ting på. Derfor ser du også i
dag at programmer der blot er lidt avancerede kun virker til relativt få
databaser (ganske ofte kun en). Og når nu .NET programmer bliver skrevet til
SQL Server (og Exchange og Avalon og ... og ... og ...) så bliver det ganske
svært at få dem til at køre på Mono (hvor disse produkter ikke er
tilgængelige).

Og så kunne man jo godt forestille sig at folk satte sig ned og lavede
software som udnyttede de databaser, mail, webservere, workflow, graktik
systemer som findes på Linux (og som også kører på Windows). Men hvorfor så
ikke gå hele vejen og bygge det som en Java applikation hvor det hele
sansynligvis vil fungere bedre.

- Per

---

Per Olsen wrote:

> Jo, men alle databaser er ikke ens (selv dem der er nogenlunde lige
> gode). Der er forskellige måder at gøre forskellige ting på. Derfor
> ser du også i dag at programmer der blot er lidt avancerede kun
> virker til relativt få databaser (ganske ofte kun en). Og når nu .NET
> programmer bliver skrevet til SQL Server (og Exchange og Avalon og
> ... og ... og ...) så bliver det ganske svært at få dem til at køre
> på Mono (hvor disse produkter ikke er tilgængelige).

Mjah, jo det er jo da rigtigt nok. Der må man jo foretage et valg som
udvikler.

1. Skal man sætte sig fuldstændig fast på
Longhorn/Avalon/Exchange/Yukon etc platforme og så finde sig i at
softwaren aldrig vil komme til at køre på andre platforme.

2. Skal man lægge "lidt" ekstra arbejde i det og lave en bibliotek af
funktioner og komponenter som understøtter flere platforme. Således at
nogle referencer bare skal skiftes ud, hvormed man kan understøtte
flere platform.

Det jeg mente er mest i retning af 2. Der er ingen tvivl om at det
kommer til at kræve noget mere arbejde, men med Mono og f.eks. DB2 vil
man kunne komme langt på f.eks. Linux ud over Windows XP/Windows
Longhorn.

Men det vil selvfølgelig kræve en hel del arbejde at stable en
acceptable platform på benene som kan konkurrere med Windows/SQL
Server/Exchange f.eks.

Nu skal du så ikke misforstå mig, jeg sidder selv i Windows og .net,
min erfaring med Linux kan ligge på et relativt lille sted. Men jeg
tror nu på at Mono har potentiale. Jeg tror til gengæld også på at der
går år, før det potentiale er fuldt udnyttet.

--
Thomas Due
Posted with XanaNews version 1.16.3.1

"One must have a good memory to be able to keep the promises one makes."
-- Friedrich Nietzsche

---

>> Jo, men alle databaser er ikke ens (selv dem der er nogenlunde lige
>> gode). Der er forskellige måder at gøre forskellige ting på. Derfor
>> ser du også i dag at programmer der blot er lidt avancerede kun
>> virker til relativt få databaser (ganske ofte kun en). Og når nu .NET
>> programmer bliver skrevet til SQL Server (og Exchange og Avalon og
>> ... og ... og ...) så bliver det ganske svært at få dem til at køre
>> på Mono (hvor disse produkter ikke er tilgængelige).
>
> Mjah, jo det er jo da rigtigt nok. Der må man jo foretage et valg som
> udvikler.
>
> 1. Skal man sætte sig fuldstændig fast på
> Longhorn/Avalon/Exchange/Yukon etc platforme og så finde sig i at
> softwaren aldrig vil komme til at køre på andre platforme.

Min erfaring (og den er snart 20 år lang) er at hvis man skal lave
konkurrencedygtige produkter så skal man udnytte rigtig mange dele af
platformen. Ellers vil der komme en konkurrent der gør det, hvis software
vil være endnu mere spændende.

Misforstå mig ikke, alt hvad man kan gøre for at software kan køre på flere
plaforme er godt, men multiplatform bør ikke komme på bekostning af
funktionalitet. Og det gør det meget nemt.

I 80'erne og 90'erne var der masser af libraries som kunne lave UI til
Windows 3.1, Windows XP, OS/2, Mac og X11. Dem der brugte disse libraries
fik UI ud af det, som var mindre spændende end andres produkter. Jeg har
endnu ikke set et eneste af den slags multiplatform produkter blive en
succes.

Dengang var det UI. I dag er det integration til e-mail, tekstbehandling,
OLAP, web-browser, etc. Man må vælge.

> 2. Skal man lægge "lidt" ekstra arbejde i det og lave en bibliotek af
> funktioner og komponenter som understøtter flere platforme. Således at
> nogle referencer bare skal skiftes ud, hvormed man kan understøtte
> flere platform.
>
> Det jeg mente er mest i retning af 2. Der er ingen tvivl om at det
> kommer til at kræve noget mere arbejde, men med Mono og f.eks. DB2 vil
> man kunne komme langt på f.eks. Linux ud over Windows XP/Windows
> Longhorn.
>
> Men det vil selvfølgelig kræve en hel del arbejde at stable en
> acceptable platform på benene som kan konkurrere med Windows/SQL
> Server/Exchange f.eks.

Det er vi helt enige om. Men det ændre ikke ved at det ikke må blive på
bekostning af udnyttelse af funktionalitet i platformen og så bliver det
svært at lave den slags. Min oplevelse gennem årene er at det er for dyrt.
Og når du har skrevet verdens bedste library til understøttelse af Word og
skal vælge mellem at bruge tid og penge på at lave det samme til Star Office
eller WordPerfect (eksisterer vist stadigvæk) eller at supportere næste
version af Word endnu bedre eller implementere en cool måde grafisk at vise
dine data eller ... eller ... eller ... tjaa, så bliver det mere
funktionalitet der vinder og ikke flere platforme (med mindre der står en
meget stor kunde og kræver det).

- Per

---

> 1. Skal man sætte sig fuldstændig fast på
> Longhorn/Avalon/Exchange/Yukon etc platforme og så finde sig i at
> softwaren aldrig vil komme til at køre på andre platforme.
> 2. Skal man lægge "lidt" ekstra arbejde i det og lave en bibliotek af
> funktioner og komponenter som understøtter flere platforme. Således at
> nogle referencer bare skal skiftes ud, hvormed man kan understøtte
> flere platform.

Den slags findes jo allerede. Tag et kig på GTK# og wx.NET:
http://wxnet.sourceforge.net/
Og lad dig ikke narre - selvom der står GUI Library, så omfatter det
ufatteligt mange andre ting - alt sammen cross platform, og tilmed lettere
at bruge end standardløsninger; uden ekstra arbejde!

Kig specielt under menupunkter "Why wx.NET", hvor man bl.a. kan finde
følgende:

"Without any extra work on your part, your application will run on Linux,
Mac OS X, and Windows using any of the following .NET runtimes: MS.NET,
Mono, or DotGNU Portable.NET."

---

On Tue, 17 Aug 2004 12:54:32 +0200, Per Olsen wrote:

[...]
> Og når nu .NET
> programmer bliver skrevet til SQL Server (og Exchange og Avalon og ...
> og ... og ...) så bliver det ganske svært at få dem til at køre på
> Mono (hvor disse produkter ikke er tilgængelige).

Ikke forstået. Så vidt jeg er orienteret:

1) Ikke alle MS.NET programmer skrives til MSSQL; så vidt jeg ved,
kan .NET-programmer sagtens tale med fx. PostgreSQL, Oracle
og DB2.

2) Mono kan sagtens tale med MSSQL; se
http://www.go-mono.com/ado-net.html

> Og så kunne man jo godt forestille sig at folk satte sig ned og lavede
> software som udnyttede de databaser, mail, webservere, workflow, graktik
> systemer som findes på Linux (og som også kører på Windows). Men
> hvorfor så ikke gå hele vejen og bygge det som en Java applikation
> hvor det hele sansynligvis vil fungere bedre.

Det er efter min mening en misforståelse at Java er førstevalget på
Linux.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

"Troels Arvin" wrote

>
> Ikke forstået. Så vidt jeg er orienteret:
>
> 1) Ikke alle MS.NET programmer skrives til MSSQL; så vidt jeg ved,
> kan .NET-programmer sagtens tale med fx. PostgreSQL, Oracle
> og DB2.

Jeps, men på .NET så findes der specielle class libraries til at connecte
til MSSQL
Jeg ved ikke hvor meget der giver i forhold en mere generisk OleDB eller
ODBC connection fx Oracle
Men SQL klasserne er langt det bedste at bruge mod MSSQL fra .NET
platformen

- Peter

---

>> Og når nu .NET
>> programmer bliver skrevet til SQL Server (og Exchange og Avalon og ...
>> og ... og ...) så bliver det ganske svært at få dem til at køre på
>> Mono (hvor disse produkter ikke er tilgængelige).
>
> Ikke forstået. Så vidt jeg er orienteret:
>
> 1) Ikke alle MS.NET programmer skrives til MSSQL; så vidt jeg ved,
> kan .NET-programmer sagtens tale med fx. PostgreSQL, Oracle
> og DB2.

1. Jeg snakkede ikke om hvad der var muligt. Jeg snakkede om hvad folk
gjorde. Og når nu SQL Server fungerer strålende sammen med Active Directory,
at management af SQL Server sker i samme miljø som resten af Windows
produkterne, at .NET data-access API'er til .NET/windows først skrives til
SQL Server og ... og ... og ..., så vil det i mine øjne være dumt at vælge
andet end SQL Server til et .NET projekt.

2. Ovenstående, med mindre der findes en intern IT politik om kune at bruge
produkt X. Men så sker der blot det at ens platform blot bliver .NET minus
SQL Sever plus produkt X. Ens produkt bliver stadigvæk noget der kun kører
på ens egen platform.

> 2) Mono kan sagtens tale med MSSQL; se
> http://www.go-mono.com/ado-net.html

Se ovenstående. Men i øvrigt mener jeg ikke at Linux (og dermed mono) kan
finde ud af Windows sikkerhedssystem og at kæden allerede der falder af (og
det er sikkert ikke det eneste sted), hvis man vil lave produkter passer ind
i Windows verdenen.

Og igen, hvorfor så vælge .NET?

>> Og så kunne man jo godt forestille sig at folk satte sig ned og lavede
>> software som udnyttede de databaser, mail, webservere, workflow, graktik
>> systemer som findes på Linux (og som også kører på Windows). Men
>> hvorfor så ikke gå hele vejen og bygge det som en Java applikation
>> hvor det hele sansynligvis vil fungere bedre.
>
> Det er efter min mening en misforståelse at Java er førstevalget på
> Linux.

Det er snart 10 år siden jeg lavede noget seriøst på Linux så jeg er ikke
expert. Men i mine øjne er der pt. ret få platforme til at lave størrere
systemer på:

- Microsoft .NET (incl. alle de platforme vi har snakket om)
- IBM Linux/Java
- Oracle Java (på whatever platform)
- BEA Java (på whatefer platform)

Selvom jeg har mange års erfaring med C/C++ så mener jeg den æra er slut nu.
Det kan simpelthelt ikke betale sig at lave andet end små moduler i andet
end Java/.NET.

- Per

---

"Per Olsen" wrote

> Selvom jeg har mange års erfaring med C/C++ så mener jeg den æra er slut
nu.
> Det kan simpelthelt ikke betale sig at lave andet end små moduler i andet
> end Java/.NET.
>
Hmm, det kommer vel an på produktet?

- Peter

---

>> Selvom jeg har mange års erfaring med C/C++ så mener jeg den æra er slut
>> nu.
>> Det kan simpelthelt ikke betale sig at lave andet end små moduler i andet
>> end Java/.NET.
>>
> Hmm, det kommer vel an på produktet?

Selvfølgeligt gør det det. Men i og med at de fleste udvikleres
produktivitet stiger kraftigt når de skifter til stærkt typede
"semifortolkede" sprog, så ser jeg ingen grund til ikke at gøre det. På
samme måde giver det mulighed for, med det samme program, at sprede sig over
flere CPU arkitekturer (fx. x386, Itanium og AMD 64-bit) - uden at skulle
teste sit produkt på alle sammen. Nogen ting, fx. device drivers (som er
hardware nære), embedede systemer (hvor system resourcer er vigtige) og
kernen af databaser (ca. 10K linier, hvor memory forbrug er vigtigt) skrives
stadig bedst i C/C++ ... men det er ikke mere end et par år siden jeg hørte
den sidste sige at disse ting kun kunne skrives effektivt i maskinkode, så
deres tid kommer nok også

Og apropos vores diskution af platform, så er det lidt skægt at CPU'en, som
i mange mange år har været det grundlæggende i alle platforme (Intel/MSDOS,
MIPS/Ultrix, PowerPC/AIX, Sparc/Solaris, etc.), nu med Java/.NET forsvinder
ud af platformen og blot bliver en standardiseret dims ligesom skærmen og
tastaturet.

- Per

---

"Per Olsen" wrote
>>
> > Hmm, det kommer vel an på produktet?
>
> Selvfølgeligt gør det det. Men i og med at de fleste udvikleres
> produktivitet stiger kraftigt når de skifter til stærkt typede
> "semifortolkede" sprog, så ser jeg ingen grund til ikke at gøre det.

Ok, men der findes dog stadig en stor (og stigende) produktgruppe der nyder
godt af C/C++ rent performancemæssigt
Hvor meget og avanceret grafik kan man tilgå fra c#?

- Peter

---

>> > Hmm, det kommer vel an på produktet?
>>
>> Selvfølgeligt gør det det. Men i og med at de fleste udvikleres
>> produktivitet stiger kraftigt når de skifter til stærkt typede
>> "semifortolkede" sprog, så ser jeg ingen grund til ikke at gøre det.
>
> Ok, men der findes dog stadig en stor (og stigende) produktgruppe der
> nyder
> godt af C/C++ rent performancemæssigt
> Hvor meget og avanceret grafik kan man tilgå fra c#?

Min erfaring siger mig at det er ret få linier kode i et stort system som er
performance kritiske. Man kan lave noget grafik i C# men jeg er ikke helt
klart på hvor meget og det er sådan set også ligegyldigt. For hvis der er
behov for at lave high perf kode i dit eksempel og C# ikke er nok, så kan
man lave sig en WinForms C++ control som laver alt det hårde arbejde. Sørg
nu bare for at være sikker på at behovet er der, for det skal jo helst stå
mål med prisen (jeg har set fin 2D grafik i C#, men tror ikke man kan lave
super 3D grafik direkte i C#). Husk i øvrigt på at nogle kald til .NET
klasse biblioteket i praksis ryger direkte i unmanaged kode, og at der
derfor ikke er grund til at skrive sin egen kode unmanaged. Hvis man kan få
fat i DirectX API'et mere eller mindre direkte fra C#, så kan man lave alt
det high perf grafik man kan ønske sig.

Der er masser af områder hvor performance i C#/MSIL ikke er nok til at man
kan lave det hele i C#/MSIL. Og i de tilfælde kan man lave nogle ganske få
unmanaged code assemblies som løser disse opgaver (eller i mange tilfælde:
købe færdiglavede komponenter der laver opgaven). Men det ændrer ikke ved at
resten af koden bør være managed.

På samme måde havde man i gamle dage nogle ganske få funktioner i C standard
librariet som typisk var skrevet assembler (string manipulations og memory
management). Men resten var i C. Efterhånden som årene gik, blev det hele
til C.

- Per

PS: Min erfaring siger mig at der hvor man har brug for unmanaged code er
følgende: 1. Når det skal være maskinnært og der endnu ikke findes C#/MSIL
wrappers til funktionen. 2. Når memory management er supervigtigt (som fx.
hvis man skal styre bufferen i en database engine).

---

"Per Olsen" wrote

> Min erfaring siger mig at det er ret få linier kode i et stort system som
er
> performance kritiske.

Kommer såmen an på hvad man beskæftiger sig med
Og hvilket klientel man henvender sig til

> Man kan lave noget grafik i C# men jeg er ikke helt klart på hvor meget
> og det er sådan set også ligegyldigt. For hvis der er behov for at lave
high
> perf kode i dit eksempel og C# ikke er nok, så kan
> man lave sig en WinForms C++ control som laver alt det hårde arbejde.

Hmm, gad vide om man kan det med fx Doom3, FarCry og fx HL2
Software er mange ting
Jeg har ikke set SDK'et til HL2 endnu men jeg regner da stærkt med at det er
C++

Eller tænk videoredigering, rendering, 3D modelling, CAD etc

- Peter

---

>> Min erfaring siger mig at det er ret få linier kode i et stort system som
>> er
>> performance kritiske.
>
> Kommer såmen an på hvad man beskæftiger sig med
> Og hvilket klientel man henvender sig til

Det skal der mere til at overbevise mig om.

>> Man kan lave noget grafik i C# men jeg er ikke helt klart på hvor meget
>> og det er sådan set også ligegyldigt. For hvis der er behov for at lave
>> high
>> perf kode i dit eksempel og C# ikke er nok, så kan
>> man lave sig en WinForms C++ control som laver alt det hårde arbejde.
>
> Hmm, gad vide om man kan det med fx Doom3, FarCry og fx HL2
> Software er mange ting
> Jeg har ikke set SDK'et til HL2 endnu men jeg regner da stærkt med at det
> er C++
>
> Eller tænk videoredigering, rendering, 3D modelling, CAD etc

Jeg laver ikke spil, men det betyder nok ikke så meget her. Det er ikke så
mange år siden at spil blev skrevet fra grunden hver gang og hvor alle skrev
deres egne drivere til diverse grafikkort. Så kom DirectX som fjernede det
meste af opgaven med at tegne grafik etc. Efterhånden har vi fået 3D engines
som laves centralt af et firma, og som så udnyttes af andre ... 3D enginen
skal givetvist skrives i C++ e.lign. men alt det uden om har jeg svært ved
at se hvorfor man ikke skulle lave i managed code. Og hvis spillet bare når
en hvis størrelse, så kan man sagtens nå forholdet 1:10 mellem unmanaged og
unmanaged code.

Videoredigering er et godt eksempel. Man kan skrive et enkelt video
redigerings program i C# hvis man bruger DirectX til I/O. Der er fx. flere
af de PVR (Personal Video Recorders) programmer der florerer på nettet, som
er skrevet i C#. Hvis man vil have avancerede filtre, så skal de sikkert
skrives i unmanaged code. I praksis skal der følgende til at optage TV på
harddisken:

1. Opret source "TV Tuner"
2. Opret destination "File"
3. Connect "TV Tuner".Video med "File".Video (bridge 1)
4. Connect "TV Tuner".Audio mod "File".Audio (bridge 2)
5. Syncroniser bridge 1 og bridge 2
6. Go

Video redigering er lidt i samme skuffe - man skal blot lægge stop points
ind og source bliver nok en fil, og destination bliver sikkert både et
område på skærmen, lydkortet og en fil.

CAD, raytracing, etc. er igen gode eksempler på at man kan lave en engine
som laver alt det hårde (og lur mig om disse ting ikke langsomt kommer ned i
DirectX), og så have en del setup/kontrol kode som styrer det.

Jeg ved at for 10 år siden var forholdet mellem "engine kode" (skrevet i
assembler) og kontrol kode (skrevet i C) i AutoCAD 1:100. For mindre
systemet er forholdet nok mindre, men jeg har svært ved at se det komme
under 1:10. Mine kilder siger mig også at i SQL Server bliver langt det
meste nye kode også skrevet i C# (og at de ville nå samme forhold - 1:100 -
hvis de skulle skrive SQL Server i dag).

Og, blot fordi et SDK er C++ så er der ingen grund til ikke at skrive sin
kode i C# ...

- Per

---

"Per Olsen" wrote

> > Kommer såmen an på hvad man beskæftiger sig med
> > Og hvilket klientel man henvender sig til
>
> Det skal der mere til at overbevise mig om.
>
Fx HL2 skulle efter sigende kunne afvikles på lowend maskiner

1.2 GHz Processor
256MB RAM
DirectX 7 graphics card
Windows 2000/XP/ME/98

Der er ikke megen grin ved at bruge en dekade på at udvikle et stykke
software og det så kun kan afvikles på maskiner af i morgen

- Peter

---

>> > Kommer såmen an på hvad man beskæftiger sig med
>> > Og hvilket klientel man henvender sig til
>>
>> Det skal der mere til at overbevise mig om.
>>
> Fx HL2 skulle efter sigende kunne afvikles på lowend maskiner
>
> 1.2 GHz Processor
> 256MB RAM
> DirectX 7 graphics card
> Windows 2000/XP/ME/98
>
> Der er ikke megen grin ved at bruge en dekade på at udvikle et stykke
> software og det så kun kan afvikles på maskiner af i morgen

Jo, men siger jo ingenting.

For det første siger det ikke noget om hvorvidt man kan opdele programmet i
ting der er tids og performance kritiske og ting der ikke er. Og min pointe
er at den sidste kategori typisk er meget størren end den første.

For det andet siger det ikke noget om hvorvidt dem der har skrevet HL2
faktisk har lavet sådan en opdeling.

- Per

PS: Jeg har ingen anelse om hvad HL2 er, men som tidligere sagt mener jeg
ikke det betyder noget.
PPS: Hvis HL2 kører ovenpå DirectX, så har man jo allerede lavet en sådan
opdeling - men derfor kunne der sagtens være flere.

---

On Tue, 17 Aug 2004 16:31:27 +0200, "Per Olsen" <private@local.dk>
wrote:

> Husk i øvrigt på at nogle kald til .NET
>klasse biblioteket i praksis ryger direkte i unmanaged kode

Hvad er managed/unmanaged kode?

mvh /Snedker
---
http://dbconsult.dk
Email: mortenatdbconsultdotdk

---

>> Husk i øvrigt på at nogle kald til .NET
>>klasse biblioteket i praksis ryger direkte i unmanaged kode
>
> Hvad er managed/unmanaged kode?

C#/VS.NET kode bliver kompileret til Microsoft Intermidiate Language (MSIL).
Det er matematisk muligt at undersøge hvorvidt MSIL kode opfører sig pænt,
herunder checke for sikkerhedsproblemer, uden at køre koden. Kode af den
type kalder Microsoft "managed code".

C/C++ compilere genererer maskinkode. Det er ikke muligt at checke om
maskinkode opfører sig pænt uden at køre koden (og selv da er det ikke 100%
muligt), og i praksis er det ikke rigtigt muligt at sige særligt meget om
koden. Microsoft kalder dette "unmanaged code".

I de sidste mange år har man løst problemerne omkring unmanaged code ved at
lave smarte CPU'er, men der er forskellige grunde til at dette ikke altid
har været den rigtigste løsning (bl.a. sikkerhed contra performance, se blot
på virus problemerne).

- Per

---

Per Olsen wrote:
>
> C/C++ compilere genererer maskinkode. Det er ikke muligt at checke om

Hov hov.. C++ kode, kan også kompileres som MSIL. Det smarte ved .NET
platformen, er jo li'som, "Alle sprog -> en platform" :)

Og nu vi snakker om performance Managed/unmanaged.. Faktisk er Quake II
porteret til Managed code..

http://www.codeproject.com/managedcpp/Quake2.asp

(Argh.. havde lovet mig selv ikke at blande mig i denne tråd!)

/B.happy

---

>> C/C++ compilere genererer maskinkode. Det er ikke muligt at checke om
>
> Hov hov.. C++ kode, kan også kompileres som MSIL. Det smarte ved .NET
> platformen, er jo li'som, "Alle sprog -> en platform" :)

I mine øjne har managed C++ lige så lidt at gøre med Bjarne Stroustrups C++
som Java har det. Microsoft her lavet en masse restriktioner som fjerner
alle fordelene. Så hellere skifte til C#.

Og mht. sprog, så er "Alle sprog -> en platform" kun et smart reklame
gimmick. Det tager lige lang tid at rykke fra VB6 til VB.NET som til C#.

Det svære ved at lære en platform er ikke programmeringssproget - min egen
erfaring siger at folk føler sig fortrolige ved et nyt sprog efter en dags
tid, med mindre det er et skifte i abstraktionsniveau (som fra strukturerer
til procedural kode, eller fra procedural til object orienteret, eller fra
imperativ til declarativ, ...). Det svære er det medfølgende bibliotek,
debuggeren, ... alle de omgivende ting. Her fejler .NET fordi det har
forsøgt at lure køkkenbords VB udviklere næsten ind i en C++ verden.
Desværre er det for svært for mange - dette ved jeg af erfaring. Der er
mange der er blevet ved VB6.

> Og nu vi snakker om performance Managed/unmanaged.. Faktisk er Quake II
> porteret til Managed code..
>
> http://www.codeproject.com/managedcpp/Quake2.asp

Sådan som jeg ser det, så er Quake 2 ikke porteret til managed code. Man har
compileret koden med managed extensions, sådan at den kan loades i en
managed verden. Og så har man bygget en smule ovenpå i managed code. Men lad
nu det ligge, det viser blot at man kan lave en "engine" i unmanaged code
(og i dette tilfælde kan vi i hvert i fald blive enige om at Open GL, som
Quake 2 bygger på, kan opfattes som en engine), som så styres af managed
code.

> (Argh.. havde lovet mig selv ikke at blande mig i denne tråd!)

Det kender jeg sgu godt

- Per

---

> Og mht. sprog, så er "Alle sprog -> en platform" kun et smart reklame
> gimmick. Det tager lige lang tid at rykke fra VB6 til VB.NET som til
> C#.

Jeg synes det er et ret genialt koncept. .NET handler jo i bund og grund om
den virtuelle maskine, der kan afvikle MSIL. Hvordan man kommer frem til
IL-koden kan så være på mange forskellige måder. Selvom det samme er
tilfældet med den JVM, så synes jeg at Sun har begået en fejl ved at
indoktrinere at JVM er uløseligt forbundet med Java-sproget, når nu man
*kan* kombinere mange udvikleres kompetencer indenfor forskellige sprog i
det samme projekt og distribuere det over mange forskellige platforme.

> Det svære ved at lære en platform er ikke programmeringssproget - min
> egen erfaring siger at folk føler sig fortrolige ved et nyt sprog
> efter en dags tid, med mindre det er et skifte i abstraktionsniveau
> (som fra strukturerer til procedural kode, eller fra procedural til
> object orienteret, eller fra imperativ til declarativ, ...). Det
> svære er det medfølgende bibliotek, debuggeren, ... alle de omgivende
> ting. Her fejler .NET fordi det har forsøgt at lure køkkenbords VB
> udviklere næsten ind i en C++ verden. Desværre er det for svært for
> mange - dette ved jeg af erfaring. Der er mange der er blevet ved VB6.

Jeg har selv programmeret i QBASIC, Visual Basic 3.0-6.0, C, Java, C++ og nu
mest C#, og af alle disse miljøer finder jeg at .NET (med C#) er det mest
attraktive og rige miljø, med ufattelig let adgang til en enorm mængde af
funktionalitet, som kan udvides - logisk inddelt i namespaces med rig
dokumentation. At dette er for svært for mange, skyldes ikke at der er noget
galt med platformen, men at de pågældende personer enten ikke kan eller vil
gøre noget ved det. Object-orienteret programmering er måske ikke alle folks
kop the i starten, men når man lærer det har jeg svært ved at se hvorfor man
skulle gå tilbage (så længde vi snakker user space GUI programmer - jeg er
elektronik-ingeniør og ved godt hvornår vi skal have assembler og C frem til
systemnær/embedded programmering.).

---

>> Og mht. sprog, så er "Alle sprog -> en platform" kun et smart reklame
>> gimmick. Det tager lige lang tid at rykke fra VB6 til VB.NET som til
>> C#.
>
> Jeg synes det er et ret genialt koncept. .NET handler jo i bund og grund
> om
> den virtuelle maskine, der kan afvikle MSIL. Hvordan man kommer frem til
> IL-koden kan så være på mange forskellige måder. Selvom det samme er
> tilfældet med den JVM, så synes jeg at Sun har begået en fejl ved at
> indoktrinere at JVM er uløseligt forbundet med Java-sproget, når nu man
> *kan* kombinere mange udvikleres kompetencer indenfor forskellige sprog i
> det samme projekt og distribuere det over mange forskellige platforme.

Enig. Desværre er det ikke helt nok.

>> Det svære ved at lære en platform er ikke programmeringssproget - min
>> egen erfaring siger at folk føler sig fortrolige ved et nyt sprog
>> efter en dags tid, med mindre det er et skifte i abstraktionsniveau
>> (som fra strukturerer til procedural kode, eller fra procedural til
>> object orienteret, eller fra imperativ til declarativ, ...). Det
>> svære er det medfølgende bibliotek, debuggeren, ... alle de omgivende
>> ting. Her fejler .NET fordi det har forsøgt at lure køkkenbords VB
>> udviklere næsten ind i en C++ verden. Desværre er det for svært for
>> mange - dette ved jeg af erfaring. Der er mange der er blevet ved VB6.
>
> Jeg har selv programmeret i QBASIC, Visual Basic 3.0-6.0, C, Java, C++ og
> nu
> mest C#, og af alle disse miljøer finder jeg at .NET (med C#) er det mest
> attraktive og rige miljø, med ufattelig let adgang til en enorm mængde af
> funktionalitet, som kan udvides - logisk inddelt i namespaces med rig
> dokumentation. At dette er for svært for mange, skyldes ikke at der er
> noget
> galt med platformen, men at de pågældende personer enten ikke kan eller
> vil
> gøre noget ved det. Object-orienteret programmering er måske ikke alle
> folks
> kop the i starten, men når man lærer det har jeg svært ved at se hvorfor
> man
> skulle gå tilbage (så længde vi snakker user space GUI programmer - jeg er
> elektronik-ingeniør og ved godt hvornår vi skal have assembler og C frem
> til
> systemnær/embedded programmering.).

Jo, men her begår du en fejl. Alle de mennesker som var lykkelige for
VB3-4-5-6 og syntes at det var verdens bedste udviklingsværktøj, de har det
svært med .NET i alle afskygninger. Der er ikke noget galt med dem - de
skulle blot ikke være luret ind i C#/C++ verdenen. Men Microsoft har jo
netop forsøgt at fortælle os at .NET platformen er "one size fits all", og
det passer jo ikke.

Det faktum at du har bevæget dig fra diverse VB afskygninger ind i
C++/Java/C# verdenen siger jo blot at hvis man vil og har evnerne, så kan
man. Men alle dem der blot skal lave noget relativt simpelt, de kan nemt
blive overvældet af VB.NET/C# og af det megastore klassebibliotek. I VB6 var
det hele meget mere enkelt (og mulighederne var også mindre, med mindre man
gik i gang med diverse hacks).

- Per

---

On Fri, 13 Aug 2004 09:04:13 +0200, Morten Snedker
<mortenatdbconsultdotdk> wrote:

>Jeg er ikke interesseret i ideologi og monopol-snak, vedr. emnet, men
>primært "hvorfor/hvorfor ikke" .Net?

Jeg kan ikke rigtigt komme på nogle "ikke" ting. Med mindre I har
specielle behov som at udvikle applikationer til en MIDP telefon,
eller lowlevel systemprogrammering osv.

Hvis jeres behov er web og alm. applikationer så ville jeg bare køre
løs.

Jeg kan til gengæld komme på et rigtig godt argument FOR:

Et sprog, tre platforme. Web, Pocket PC og Win32 applikationer. Det er
mine egne grunde til at gå .NET vejen. Hvorfor skulle jeg sætte mig
ind i 2-3 sprog, når jeg nu med et kan lave alt jeg har brug for ?

Men jeg er også bare en stakkels Microsoft ho... :P

--
Jacob

---

Fandt lige den her side - fyldt med gode grunde:

http://www.codeproject.com/dotnet/WhyDotNET.asp