Microsoft hoopt op acceptatie C# als ISO-standaard

In een poging het publieke imago van het bedrijf op te vijzelen, probeert Microsoft C# en de CLI (Common Language Infrastructure) geaccepteerd te krijgen als ISO-standaard. De European Computer Manufacturers Association, kortweg ECMA, ratificeerde de technologieën al in december 2001, bericht The Register. John Montgomery, manager binnen het .NET-project, geeft aan dat de acceptatie belangrijk is om het bedrijfsimago te verbeteren. Klanten kunnen er zeker van zijn dat C# en de CLI als ISO-standaard niet plotseling zullen wijzigen.

Wel rijzen er vragen op over de volgorde van acceptatie die Microsoft volgt: waarom is namelijk gekozen om C# en de CLI eerst aan de ECMA voor te leggen? De ECMA is een relatief kleine onbekende in de wereld van de standaardisatie. De International Standards Organization (ISO) is veel groter en heeft een wijder bereik. C# en de CLI zijn echter via de ECMA doorgespeeld aan de ISO, waardoor de producten een versneld acceptatie-traject kunnen doorlopen. Overigens is C# niet het eerste Microsoft-product dat het tot internationale standaard probeert te schoppen: Microsofts C++ ging C# al voor. Ook grote concurrent Sun heeft een poging gedaan één van haar producten tot standaard te laten verheffen:

Microsoft follows in the footsteps of Santa Clara, California-based rival Sun Microsystems Inc, which aborted its attempt to have Java ratified by ECMA and the ISO in 1999. Commenting on Sun's decision to pull out of the ISO process, a company spokesperson said the organization lacked the financial muscle to enforce compliance with any standard. Sun said submission of C Sharp and CLI to ISO would not promote innovation as Microsoft retains control of the underlying Windows platform.

Reacties (41)

[ErectionJackson]

Volgens mij is het niet alleen om het imago van het bedrijf op te vijzelen, maar vooral om C# geaccepteerd te laten worden door bijv. overheden. Verder is dit natuurlijk een duidelijk teken van hoe serieus Microsoft met het hele .NET verhaal omgaat.

[raptorix]

Klopt maar veel bedrijven hanteren gewoon de standaard dat ze alleen met ISO gecertificeerde producten werken, met name organisaties als overheden en grote financiele instellingen.

Daarnaast is de tactiek vrij slim, op C# valt voor MS toch niet zoveel te verdienen, dus waarom niet vrijgeven? Het is MS meer om de randsoftware (visual studio, etc ) te doen, daar verdient men haar geld mee, kortom een slimme en logische stap van MS.

[Verwijderd]

Ik denk niet dat het zozeer overheden zijn die het doelwit zijn... die gebruiken wel meer dingen die niet ISO zijn.. maakt ook niet uit. Wat MS will is een markt aanboren waar ze nog niet zitten, Industrie. Application specific integrated controllers, Embedded devices, single board controllers, computergestuurde assemblagelijnen... Why heck, Boeing 777....

Diversify 'cuz threatened in core sector?

[MacD]

Sorry, maar ISO-certificering heeft niks te maken met het 'vrijgeven' van je produkt.

[arjankoole]

hmmm..
dat zou betekenen dat MS dat zonder restrictie zou moeten doen. Wie kan het zich nog herinneren? Het SMB protocol dat werd vrijgegeven voor iedereen, behalve als je de specificaties van dat document ging gebruiken voor "Software under the GPL license"

als C# d'r door komt mogen ze dat soort ristricties niet inbouwen dunkt me.

BSD licenses heeft MS veel minder problemen mee, het is niet de eerste keer dat ze dergelijke sourcecode pakken.

[raptorix]

Wel degelijk:

Als de technologie door ISO tot een standaard wordt verheven dan zal Microsoft de code vrijgeven waardoor de programmeertaal ook voor andere platformen geschikt kan worden gemaakt. Volgens kenners is C# een directe concurrent van Sun's Java. Op dit moment heeft geen van de grote bedrijven, op Microsoft na, een C#-implementatie of ontwikkelomgeving aangekondigd.

[Verwijderd]

Dat is .NET, niet C#
Waarschijnlijk wordt dat Delphi.NET

[Verwijderd]

[reply-to: all of the above]
De ECMA heeft als regel dat iedereen gratis de standaarden kan downloaden, itt ISO, waar vaak fors betaald moet worden. Met het downloaden van standaarden van de ECMA verkrijg je het recht deze standaarden te implementeren, maar je mag ze niet doorontwikkelen onder dezelfde naam, dit om verwarring over verschillende versies te voorkomen. Verder functioneert ECMA net als ISO, in dat aan standaarden en drafts een werkgroep wordt toegekend bestaande uit mensen uit "de industrie": zo zitten in de werkgroep voor C# ook mensen van SUN en IBM.
Het geval wil nu dat Microsoft al C# en de CLR bij ECMA had neergelegd. Dat betekent dat een hoop bedrijven en andere geïnteresseerden de specificaties hebben gedownload. Daarom kan Rational Delphi.NET ontwikkelen, bijvoorbeeld, en kan HP bezig zijn om voor UNIX een runtime voor .NET te maken.
Het stukje commentaar van SUN slaat dus eigenlijk nergens op. Het onderliggende platform is alleen Windows als je de Windows .NET Runtime gebruikt, en die mag ook door concurrenten gemaakt worden in principe. Aangezien de gehele WIN32 API overboord gegooid is met .NET, kun je zelfs niet spreken van een home-team advantage. (Al zullen de .NET applicaties waarschijnlijk sneller werken onder de toekomstige versies van Windows omdat die gebouwd zijn op .NET, net als C-applicaties altijd sneller zijn dan JAVA applicaties omdat je voor JAVA een aparte runtime boven je OS moet draaien.) Microsoft zal alleen een voordeel hebben omdat ze al sinds 1992 bezig is met de ontwikkeling van het .NET gebeuren en Windows sneller zal beschikken over OS-level support dan Linux, UNIX, et cetera.
Wat echter wel heel belangrijk is, is dat deze zet de industrie kan overtuigen dat Microsoft echt serieus wil dat dit een standaard wordt. SUN met JAVA heeft immers vaker de taal en het platform aangeboden voor standaardisatie, maar het vervolgens weer teruggetrokken. Dat heeft verder niets te maken met "financial muscle", maar het niet eens zijn met wat de werkgroep wil doen met de standaardisatie. Microsoft geeft hier dus mee aan de standaardisatie door te zetten, wat in principe geen enkel OS nog in de weg zou mogen staan om runtimes te ontwikkelen voor dat OS en geen enkele taal om .NET te targeten.

[stylee]

Op dit moment heeft geen van de grote bedrijven, op Microsoft na, een C#-implementatie of ontwikkelomgeving aangekondigd.

Nee hoor bijvoorbeeld: http://www.tweakers.net/nieuws/23228/?highlight=borland

[Pantagruel]

Het doel van MS is natuurlijk om C# een ISO certificering te doen verkrijgen om zo zekerheid en vertrouwen te genieten van een erkende standaard.

NU MS zo 'veiligheids' gericht wil gaan werken (Palladium) is het natuurlijk erg fijn dat C# ISO nummertje nogwat gecertificeerd is/zal zijn. Hiermee geven ze aan dat een onafhankelijke organisatie hun C# taal als goed bevonden erkend en een zekere mate van standardisatie en veiligheid biedt.

Lees het niet fout, MS zal dus enkel claimen dat de C# taal OK is bevonden, wat de programmeurs ermee schrijven is niet noodzakelijk veilig. MS zal er ongetwijfeld voor hun eigen standpuint een gunstige draai aan geven.
Natuurlijk gaat MS de evt verkregen certificering gebruiken in reclame campagnes: 'Written/Compiled in an ISO certified language/environment' en vrolijk er opwijzen dat de andere C-derivaten NIET ISO gecertificeerd zijn en van alles en nog wat impliceren.

[carlo]

Kijk uit, een ISO-certificering is iets heel anders dan een ISO-standaard!!!

Een standaard legt alleen maar vast hoe een bepaald produkt of proces zou moeten werken. Het feit dat iets uiteindelijk wordt uitgeroepen tot een ISO-standaard zegt in principe helemaal niets over de kwaliteit van dat produkt of proces.

[Verwijderd]

ISO-certificering zegt ook niks over de kwaliteit. Het zegt alleen dat het product of proces voldoet aan een bepaalde standaard.
Het achterliggende idee is dat het volgen van de standaard zou moeten leiden tot een betere kwaliteit.

[Verwijderd]

Dat niet alleen, microsoft heeft dan ook nog eens een voorsprong op alle andere bedrijven? (als die er nog wel echt zijn) Als er op de puur technische kant gekeken word naar C# kan het misschien een officiele ISO programmeertaal worden. Maar als men gaat nadenken dat bijv. Java of perl niet ISO zijn dan verwacht ik ook dat C# niet goedgekeurd gaat worden.

[Verwijderd]

Hier ligt natuurlijk voor de ISO een enorme kans om aan te geven dat de handelswijze van Microsoft niet geaccepteerd wordt door een dergelijke organisatie.

Het argument van Sun is terecht:

Sun said submission of C Sharp and CLI to ISO would not promote innovation as Microsoft retains control of the underlying Windows platform.

De ISO zou er verstandig aan doen om een echt platform onafhankelijke taal tot ISO standaard te maken. Java bijvoorbeeld. Jammer dat Sun zich uit dat proces moest terugtrekken als gevolg van financiele malaise.

[Verwijderd]

Bekijk het ook eens van de andere - misschien iets positievere - kant.

Op zich zijn zowel C# alsmede CLI platform onafhankelijk; het zijn gewoon definities die een vooraf vastgesteld resultaat bewerkstelligen. Waarbij op dit moment alleen MS heeft bepaald a) wat de definitie is en b) wat het resultaat is. Het zou beter zijn voor een ISO standaard als meerdere partijen hun licht daarover zouden laten schijnen.

Op dit moment is MS welliswaar de enige die C# en CLI aanbiedt (op het Windows platform), maar als beide een ISO standaard worden is de weg natuurlijk vrij om C# en CLI op andere platformen te implementeren.

[borft]

Er is onder linux al redelijk wat werk gedaan aan een .NET omgeving... ik zie alleen niet in waarom .NET het wel zou gaan maken en java niet...

.NET komt eigenlijk ook neer op een platform onafhankelijke VM, met een extra laag, die instaat is om java programma's maar ook c# te draaien alsmede bijvoorbeeld oude cobol programma's.

Kortom, traag!!

[Verwijderd]

Om niet appelen en peren te vergelijken:
.NET is een framework, C# is een development language, CLI is een 'platform onafhankelijke' intermediate language waar in verschillende 3GL en 4GL ontwikkelde applicaties naar toe gecompileerd kunnen worden. Één JIT compiler (per platform) doet de rest; ongeacht de development language van de applicatie.

Java is een prima taal, maar moet je niet met CLI vergelijken en al helemaal niet met .NET.

Op zich heb je wel gelijk dat elke extra laag ook voor extra belasting op je systeem zorgt. Universeelheid heeft zijn prijs; Je wilt toch niet dat iedereen in assembler gaat hacken om max. performance te bewerkstelligen?

[Verwijderd]

Java is niet alleen een taal, maar een platform, en op het bytecode-niveau schelen Java en CLI niet zo gek veel.
Je zou kunnen zeggen dat MS Java als voorbeeld heeft genomen, en het een stap verder heeft gebracht.
Dit zorgt voor nog betere performance van de JIT.

En ja inderdaad, een JIT-compiler kan sneller zijn dan een statische compiler...
Het HP Dynamo project is erg interessant...
Hier liet men zien hoe een PA-RISC systeem, dat zichzelf 'emuleert', at runtime code kon optimaliseren, en zo tot 20% snelheidswinst kreeg op statisch gecompileerde (EN geoptimaliseerde) code.
Dit resultaat werd verkregen door de code te analyseren at runtime, en te recompilen/optimaliseren met informatie die tijdens compile-time nog niet bekend was (zoals de al genoemde loop-unrolling en function-inlining van bijvoorbeeld dynamisch gelinkte libraries).

In feite zou .NET de toekomst kunnen zijn. Als MS de JIT zover geoptimaliseerd krijgt, dat ie aantoonbaar sneller is dan de statische compilers, dan zullen veel mensen overstappen.

Andere voordelen van .NET zijn bijvoorbeeld de kleinere code (bytecode is kleiner dan x86-code, zeker als je de compiler at runtime loops laat unrollen ed), automatische garbage collection (geen memory leaks meer), en runtime boundschecking (geen buffer overflow exploits meer).

Ik zou willen zeggen: Watch this space!

[Verwijderd]

Er bestaat zoiets als een JIT (Just In Time) compiler. Deze compileert bij de eerste keer uitvoeren van de intermediate code native code voor bijv. een x86 architectuur. Voor Java bestaat dat ook. Zo krijg je maximale performance op jouw hardware.

[Verwijderd]

Toch even een kleine opmerking. Je kan ervoor kiezen om een programma bij de eerste maal te laten compilen en daarna steeds de native code te draaien. Standaard wordt het programma echter steeds JIT gecompileerd. Dit JIT compilen moet daarentegen niet steeds minder performant zijn dan pre-comiled code , want zo kan een JIT compiler tijdens de runtime situaties ontdekken die tijden precompiling niet mogelijk zijn. Bv functies die tijdens een loop worden opgeroepen, kan de JIT compiler inline gaan plaatsen ipv steeds een function call uit te voeren, indien een loop vaak wordt uitgevoerd, en het beschikbare geheugen dit toelaat...

[Verwijderd]

Alleen duurt het lang genoeg om een tas koffie leeg te drinken vooraleer je applicatie opgestart is, zeker als het om GUI-werk gaat (waar Java zowiezo niet erg geschikt voor is, maar toch vaak genoeg voor gebruikt wordt). Goede JIT (lees snelle) compilers zijn echt zeldzaam, zeker op win32 platformen.

[Verwijderd]

Dat is vooral omdat de JVM zelf nog geladen geinitialiseerd moet worden. Start een tweede Java applicatie op, en het gaat ineens stukken sneller.
.NET zal nauw geintegreerd worden met Windows, en daardoor een stuk sneller gaan werken dan Java.

Goede JIT (lees snelle) compilers zijn echt zeldzaam, zeker op win32 platformen.

Dat snap ik even niet, er zijn een hoop goede JITs voor Win32 te vinden. De MS VM is nog steeds erg rap, de Sun JIT is ook prima, en die van IBM is ook zeker niet slecht. Dan zijn er vast nog wel een aantal die ik niet geprobeerd heb... Maar ik heb in ieder geval betere ervaringen met Win32 dan met linux.
(Identiek dezelfde versie Sun JDK (1.4.0_1) draaide beter op identiek dezelfde PC onder Win32 dan onder Debian. Andere JVMs voor linux ken ik niet).

[Verwijderd]

.NET komt eigenlijk ook neer op een platform onafhankelijke VM, met een extra laag, die instaat is om java programma's maar ook c# te draaien alsmede bijvoorbeeld oude cobol programma's.

Kortom, traag!!

Er is een wereld van verschil in de manier waarop een Java programma door de JVM uitgevoerd wordt vs. .NET code door de CLR. En traag is het .NET framework absoluut niet. Zeker niet vergeleken met het Java framework.

Zie hieronder een aantal voorbeelden:

Pet Store (Java reference applicatie omgebouwd naar .NET)
http://www.gotdotnet.com/team/compare/petshopperf.aspx

Nile Application Benchmark Test:
http://www.gotdotnet.com/team/compare/nileperf.aspx

.NET vs. IBM Websphere 4.0
http://www.gotdotnet.com/team/compare/webspherebenchmark.aspx

[Verwijderd]

Het zou beter zijn voor een ISO standaard als meerdere partijen hun licht daarover zouden laten schijnen.

In principe is natuurlijk wat die certificiering inhoudt.

De reden dat Sun het financieel niet trok was waarschijnlijk omdat ze dan grote aanpassingen aan Java moesten gaan maken, om kleine dingen voor elkaar te krijgen...

[Verwijderd]

[flamemode]
MS wilt gewoon een eigen taal die door de wereld gebruikt wordt, daar vinden ze graag het wiel een tweede keer voor uit. Want, wat is er mis met Java? Het is niet van MS. Na de kritiek die ze kregen op J++ hebben ze het op C# gegooid. Want we moeten en zullen een MS taal gebruiken.
[/flamemode]

[cablepokerface]

Het gaat ook niet om het feit dat C# platform onafhankelijk is op dit moment. Het gaat erom dat het concept van C# platformonafhankelijk werkt.

[Left]

Ook grote concurrent Sun heeft een poging gedaan één van haar producten tot standaard te laten verheffen

Zo is het niet helemaal gegaan. Aanvankelijk heeft Sun Java ter ratificatie aangeboden aan de ISO. Maar later hebben ze zich bedacht, en toen hebben ze het hele proces stopgezet. Officieel werd daarvoor als reden gegeven dat Sun op deze manier invloed wilde kunnen blijven uitoefenen op de ontwikkeling van Java.
Maar onofficieel werd door sommigen gezegd dat Sun gewoon het eigendom van Java wilden houden omdat ze er later geld voor wilden kunnen gaan vragen, bijvoorbeeld voor licenties.

Ik denk dat C++ zeker een streepje voor krijgt t.o.v. Java als het ISO gecertificeerd wordt. Een bedrijf dat dan de keuze moet maken tussen overstappen naar Java of C++ kan dan kiezen voor een stukje zekerheid dat ze niet in de toekomst opeens licenties moeten gaan betalen.

[MSalters]

Even wat losse puntjes:

Standaardisatie via ECMA naar ISO is niet uniek, i18n binnen Europa gebeurt ook binnen ECMA en wordt daarna aan ISO aangeboden.

Dat MS actiever wordt binnen ISO is ook niet opeens nu met C#. Ook binnen de ISO C++ subcommittee is MS de laatste 1-2 jaar veel actiever geworden; zo hebben ze vorig jaar nog de najaarsmeeting naar Redmond gehaald.

Als C# eenmaal een ISO standaard is, is Microsoft de controle echt kwijt: Binnen ISO heeft elk actief land een stem. De VS stemt eerst per bedrijf, waar MS dus weer maar een stem heeft.

Het Nederlands Normalisatie Instituut heeft oof een programmeertaal commissie. Vrijwilligers die professioneel actief zijn met C# en CLR/.NET en die willen bijdragen aan deze standaarden zijn dan ook zeker welkom.

* 786562 msalters

[The Dutch Dude]

Na een beetje gegoogle begrijp ik dat C# een belangrijke taal voor het .Net gebeuren van MS is.
Ze hebben C veel keywords genomen, en er wat Java bij gegoten, en naar nog een aantal andere talen gekeken (zoals Delphi, wat niet verwonderlijk is, want de bedenker van Delphi zat in het ontwikkelteam).

Ik begrijp alleen niet wat er zo revolutionair aan moet zijn.

[Verwijderd]

Ter info:
Of het revolutionair is weet ik niet (oordeel zelf), maar C# is ontwikkeld met de gedachte dat C(++) ontwikkelaars graag sneller en eenvoudiger zouden willen ontwikkelen, zoals bijvoorbeeld Visual Basic programmeurs dat kunnen, zonder in te moeten leveren op flexibiliteit die je juist in C(++) hebt en veel minder in bijvoorbeeld VB.

Nu kun je natuurlijk zeggen, ga dan in Delphi, Java of weet ik wat ontwikkelen, maar ontwikkelaars werken graag vanuit de reeds opgebouwde kennis verder. Een taal (C#) die heel sterk lijkt op wat het was (C++) en waarin toch veel sneller kan worden gewerkt, is dus mooi meegenomen!

[Verwijderd]

C# wordt wel gemarket als originele taal, en geen C kloon of wat dan ook.

Kijkend naar de functionaliteit die C# biedt lijkt het overigens meer op Java dan op C (++).

[Verwijderd]

Overigens is C# niet het eerste Microsoft-product dat het tot internationale standaard probeert te schoppen: Microsofts C++ ging C# al voor.

Dat is niet waar hoor! C++ is niet bedacht door M$, maar door Bjarne Stroustrup, terwijl hij werkzaam was bij AT&T!!!
Zie: http://www.research.att.com/~bs/bio.html

edit: url was verkeerd afgebroken

[Marcelloz]

Ze hebben het ook over Microsoft C++, en niet C++. Dit is een standaard waar Microsoft C++ van afgeleid is ( he, het lijkt wel OO ) :-)

C++ is niets anders dan een OO-schil in C om C heen, en de implementatie daarvan kan verschillen. Bjorn S. was inderdaad de bedenker van C++ en hij krijgt ook gewoon de credit. Microsoft heeft C++ uitgebreid met zijn eigen dingen (zoals ze vaker doen), en probeert gewoon dit gestandaardiseerd te krijgen.

Maar zo te lezen is het microsoft nog niet gelukt om hun C++ te standaardiseren.

C# is uiteraard een compleet ander verhaal. Mooie taal, maar zonder een CLI standaard is standaardisatie nutteloos. Of je moet direct gaan compileren naar executable, maar daar is het niet voor bedoeld uiteraard.
Ik verwacht trouwens dat ze na c# de overige .Net talen ook zullen standaardiseren. Ik ben benieuwd!

[Verwijderd]

C++ is zeker geen C met een shell er om hoor.
Het is juist omgekeerd. C++ bevat veel C compatibeliteit. Maar in feite zijn het twee totaal verschillende talen hoor.
Ik gebruik hier de woorden van BS zelf: "Error handling kan enkel goed werken als je het in de taal inbouwd". C heeft geen error handling mechanisme. Als je dit thema alleen al eens grondig bekijkt dan zie je een wereld van verschil tussen beide talen. En dat is nog maar 1 thema.
Dat C++ in C is geschreven is een andere zaak.
Nu Mickysoft C# erwil doorpompen is enkel om Java een hack te zetten. Java is gepatendeerd door SUN.
Zelf zie ik niets in C#, ik blijf voorstander van native coding. Als ik dan toch platform independend wil gaan voor webaplicaties bv dan is JAVA de defacto standaard.

[Darkvater]

Volgens mij bedoelen ze de C++ van Microsoft Visual C++ die op enkele punten afwijkt van de ISO C++.


Damn, sommige ISO C++ programmas compileren niet eens onder MSVC++ terwijl het wel onder G++ doet

[Marcelloz]

Dit ligt aan de compiler van Microsoft. Geen enkele compiler ondersteunt 100% alle hoeken en gaten van de ISO standaard, trust me. Er zijn altijd wel constructies te bedenken die de compiler in de soep laten lopen. Meestal hele enge en niet veel gebruikte, dusseh denk ik dat het wel meevalt.

[MSalters]

Tsja, je loopt een heel klein beetje achter; EDG heeft inmiddels zo'n C++ compiler ( te koop via www.comeaucomputing.com ).
Het zegt op zich veel over de inspanning van MS dat EDG, een bedrijf van 3 man, eerder is.

[Verwijderd]

hetgeen ook afwijk van ANSI....

[Verwijderd]

Klanten kunnen er zeker van zijn dat (...) ISO-standaard niet plotseling zullen wijzigen

eeuh .. wat doe MS nu dan ???

[mOrPhie]

wat bedoeld wordt is dat er geen wijzigingen zullen plaatsvinden op C# en de CLI (en hun compilers), als deze tot ISO-standaard verheven worden.

MS doet dus niets.