Ursprünglicher Zweck von .NET

Die (oder zumindest eine) Hoffnung hinter .net war, einen Ersatz für die 
native Win32 API zu schaffen. Win32 datiert aus den Anfängen der 90'er 
und basiert auf dem 16 Bit API, das sich seit 1985 nicht wesentlich 
verändert hat. Diese Programmierschnittstelle ist die Basis, auf der 
alle Windows-Programme aufbauen. Einige Designentscheidungen waren nun 
nicht gerade glücklich und führten später zu gravierenden 
Sicherheitsproblemen im Internet-Zeitalter. Außerdem ist Win32 eine 
prozedurale, für C entwickelte Schnittstelle.

.net versprach Abhilfe. Man war nicht an seine Altlasten gebunden, 
konnte komplett von vorne anfangen, alles schön objektorientiert 
aufbauen, die Softwareentwicklung vereinfachen etc. pp.

Das Ergebnis ist bekannt.

fchk

Marc schrieb:
> Beides sind Frameworks, die zwischen der Applikation und dem
> Betriebssystem angesiedelt sind.

Naja, einen ganz wichtigen Punkt hast Du übersehen.

Java & .net führen die Programme auf virtuellen CPUs aus. Das heisst, 
der Compiler übersetzt nicht mehr direkt für die Hardware-CPU, sondern 
für eine virtuelle Maschine.
Die "Assembleranweisungen" der virtuellen Maschine werden dann zur 
Laufzeit auf der "echten" Hardware ausgeführt.

Der Vorteil liegt auf der Hand: Ausser dem kleinen Stück Code, dass die 
virtuelle Maschine auf der Ziel-CPU ausführt ist der gesamte .NET/Java 
Code komplett unabhängig von der darunterliegenden CPU.

Bei SUN (dem ursprünglichen Entwickler von Java) war (angeblich) der 
Hintergrund, dass man damals schon daran dachte Haushaltsgeräte besser 
miteinander kommunizieren zu lassen.

Bei MS (auch angeblich) der Wunsch sich etwas von Intel abzukoppeln, 
ohne alle Applikationen zu verlieren. Jede Software hätte ja mindestens 
neu kompiliert werden müssen, die entsprechenden Firmen hätten also den 
passenden Compiler gebraucht, sowie evtl. Zusatzlibs wie z.B. 
DB-Engines.
Das mögen Die aber leider gar nicht ;-) Da ist eine VM praktischer.

HtH & gn8
Andreas

Marc schrieb:
> Aber warum ist Java dann heute überall präsent und .NET nur auf
> Windows?

Weil MS bis vor kurzem alles bekämpft hat, was nicht Windows war - ich 
erinnere nur an den unseligen Browser-Krieg.

Man scheint aber langsam zur Vernunft zu kommen: .net ist mittlerweile 
in Open Source entlassen worden.

Uhu Uhuhu schrieb:
> Weil MS bis vor kurzem alles bekämpft hat, was nicht Windows war

Bis vor kurzem ???

Lange Geschichte, sehr kurze Version:

Der ursprüngliche Zweck von .NET war pures, reines Marketing. MS hat den 
Begriff zuerst in die Welt gesetzt ohne selber genau zu wissen was das 
ist. Da gab es von MS Broschüren und Zeitungsanzeigen, die waren so 
nichtssagend, die hätten auch komplett unbedruckt sein können. Es war 
einfach ein "Ding" von Microsoft, das "irgendwie gut" ist und "alles" 
kann. Weder MS, noch Programmierer, noch Kunden wussten am Anfang was 
.NET wirklich ist, bzw. sein sollte.

Erfunden wurde das "Ding", weil MS auf dem Desktop die Felle davon 
schwammen. MS wollte "irgendwas" haben, was die Zukunft darstellte. Man 
war zu spät mit dem Internet dran, im Browserkrieg sah es nach schweren 
Strafen aus und Java kam daher.

Java war damals (heute schon lange nicht mehr), eine Bedrohung für MS. 
Platformübergreifend - das war der Horror für MS. Betriebssysteme wie 
Windows waren plötzlich zweitrangig. MS tat dann sehr viel, um nicht zu 
sagen alles, um Java zu bekämpfen. Darunter gab es den Versuch eine 
spezielle Java-Version zu machen, mit der man wieder an Windows gebunden 
war (Microsoft hat dafür später $1,95 Milliarden USD als Strafe an Sun 
zahlen dürfen).

Java, und der Kampf gegen Java, gaben dann den Ausschlag, was MS zuerst 
unter dem Marketing-Begriff .NET implementierte. Im Prinzip ihr eigenes 
Java. Eine eigene virtuelle Maschine, ein eigenes Framework, eine 
eigenen Sprache (C#). Alles so ein bisschen wie Java, aber so gemacht, 
dass es faktisch nur auf Windows lief (theoretisch bruchstückhaft auch 
anderswo). Zusätzlich wurden die vorhandenen Sprachen für Windows auf 
.NET angepasst. Was so einige altgediente VB-Programmierer zum kotzen 
fanden.

Das war es dann auch schon mit .NET. Nachdem MS unter dem Begriff ihren 
eigenen Java-Ersatz geschaffen hatte blieb es dabei. Mehr wurde von 
diesem "Superding" nie implementiert, es blieb beim .NET Framework. Mehr 
musste MS auch nicht machen, denn Java auf dem Desktop war inzwischen, 
dank Microsoft und der Dummheit Suns, nicht mehr relevant.

Mehr konnte Microsoft auch nicht machen. Kein grundsätzlich neues 
Betriebssystem, besonders kein Networking-OS, kein neues Konzept wie man 
in Zukunft Software macht. Gerade hatte man über Jahre hinweg 
angekündigte Features von Longhorn immer wieder zusammenstreichen 
müssen, weil man sie nicht zum Laufen oder fertig bekam (Longhorn wurde 
dann der Scheißhaufen bekannt als Windows Vista), da blieb keine Luft 
für den großen .NET-Wurf.

Ja, das war reinstes Marketing, es gab so ein paar Ideen die so halbwegs 
konkret waren. Zum Beispiel wollte Microsoft so eine Art "zentrale 
Authentifikation" für das Internet bauen.

Der Java-Ersatz ist so ziemlich das einzige was übrig blieb, und in den 
Wahrnehmungsblasen einiger Leute ist das auch so richtig erfolgreich.

Microsoft hatte übrigens viele solcher Projekte. Die wurden alle nach 
wenigen Jahren, in der Regel kurz bevor die was Brauchbares 
hervorgebracht haben, eingestellt.

Typische Beispiele sind:

Windows for Pen Computing (eine Erweiterung für Windows 3.1 und 95 um 
Formulare mit Stiften ausfüllen zu können)

Objektorientierte Dateisysteme (das sollte immer in der nächsten oder 
übernächsten Version kommen... das letzte System für die die das 
angekündigt haben war Vista, ein paar Reste davon sollen sich noch in 
Office finden)

Personas in Windows NT (Windows NT sollte eigentlich in der Lage sein 
direkt Unix, OS/2 und Mac Programme auszuführen, die Technik dafür ist 
sogar drin, die entsprechenden Erweiterungen werden aber längst nicht 
mehr gepflegt)

OLE (Damit Du Objekte von einem Programm in ein anderes Programm 
einfügen kannst, das war der heiße geile Scheiß in den 1990gern und 
manche machen das auch heute noch. Corel Draw war damals als das 
Programm bekannt, das immer wegen OLE abstürzte. Heute verwendet man das 
noch gelegentlich in Microsoft Office, aber eigentlich sollte das mal 
ganz groß werden)

Wie bei jeder neuen Microsofttechnik haben sich halt einige Leute gleich 
drauf gestürzt, während andere das halt ignoriert haben. Durch 
Lerneffekte ist die Skepsis gegenüber solchen Dingen halt gestiegen, und 
der letzte Rest von .net den wir heute haben schlägt halt genau in die 
Kerbe eines ebenfalls relativ unsinnigen Projektes von Sun.

Andreas H. schrieb:
> Naja, einen ganz wichtigen Punkt hast Du übersehen.
>
> Java & .net führen die Programme auf virtuellen CPUs aus. Das heisst,
> der Compiler übersetzt nicht mehr direkt für die Hardware-CPU, sondern
> für eine virtuelle Maschine.
> Die "Assembleranweisungen" der virtuellen Maschine werden dann zur
> Laufzeit auf der "echten" Hardware ausgeführt.

Oh oh, das ist komplett falsch :-)
Die Programme werden nativ kompiliert. Nix virtuelle Maschine und so...

Andreas H. schrieb:
> Uhu Uhuhu schrieb:
>> Weil MS bis vor kurzem alles bekämpft hat, was nicht Windows war
>
> Bis vor kurzem ???

Momentan portiert Microsoft .NET auch für OS X und Linux.

alt geworden schrieb:
> Christian Berger schrieb:
> Dir ist aber (hoffentlich) schon klar, dass bei .NET heute nicht von
> einem "Rest" geredet werden kann, angesichts des massiven Ausbaus seit
> den Anfängen hier:

Naja, was das ist ist eine Runtime und die Entwicklungswerkzeuge dafür. 
Das sollte nur ein kleiner Teil der .net Strategie sein. Eigentlich 
sollte sich .net viel mehr im Internet abspielen, dort ist .net absolut 
irrelevant.

Das Microsoft dieses Problem in über 100 Megabytes löst spricht jetzt 
nicht wirklich für Microsoft. Und so oder so lösen die genau das 
Problem, das Java verspricht zu lösen, nur halt schlechter weil die 
Programme weniger portabler als native Win32 Programme sind.

Aber um zum OP zurück zu kommen, ursprünglich wollte Microsoft mit .net 
das Internet erobern, inzwischen ist es nur noch ein Framework.

Christian Berger schrieb:
> Eigentlich
> sollte sich .net viel mehr im Internet abspielen, dort ist .net absolut
> irrelevant.

^^ schon mal von ASP.NET gehört?

Ich weiß es ist etwas OT, aber nur mal so als Realitätsabgleich, wie es 
außerhalb der .net Welt aussieht:

Da schreibt man Programme zum Beispiel gegen POSIX. Diese Programme 
kompilieren dann, wenn man aufpasst, auf so ziemlich jeder Plattform 
ohne Anpassungen. Und wenn man doch mal Dinge braucht die 
unterschiedlich implementiert sind, zum Beispiel für Optimierungen, so 
nimmt man #ifdef Anweisungen für bedingte Kompilierung.

Oder man nimmt so was wie Lazarus. Da schreibt man seine GUI-Anwendung 
einmal. Formulare kann man bequem zusammenklicken oder in Code erstellen 
oder jede beliebige Mischung daraus. Kompilieren tut das dann ohne 
Änderungen mindestens auf Linux, MacOSX und Windows. Die Windowsversion 
läuft dann häufig sogar noch auf Windows 9x. Und in allen Fällen kommt 
halt eine Binärdatei mit 1-2 Megabytes raus, die man einfach ausführt. 
Keine Installation kein gar nichts. Auch keine besonderen Frameworks die 
man braucht.

Das ist inzwischen realer Stand der Technik bezüglich 
Plattformunabhängigkeit.

Boris P. schrieb:
> Oh oh, das ist komplett falsch :-)
> Die Programme werden nativ kompiliert. Nix virtuelle Maschine und so...

Mir scheint es ein Bisschen von beidem zu sein. Das Prinzip der 
Frameworks ist ähnlich dem von Java, mit Übersetzung der CLR (common 
language runtime) zur Laufzeit in den Maschinencode. Um aber die 
hässlichen Nebeneffekte davon zu vermeiden wird gerne auch bei 
Installation vorkompiliert. Merkt man auf langsamen Rechnern, wenn der 
dafür zuständige mscorsvw.exe aka "CLR Optimization Service" noch lange 
nach dem Update eines Framworks an der CPU knabbert.

A. K. schrieb:
> Mir scheint es ein Bisschen von beidem zu sein. Das Prinzip der
> Frameworks ist ähnlich dem von Java, mit Übersetzung der CLR (common
> language runtime) zur Laufzeit in den Maschinencode.

Jo, so ist es. Der Code wird eben erst zur Laufzeit, und nicht schon 
vorab kompiliert. Das hat aber doch nichts mit virtuellen Cores oder 
Maschinen zu tun.

Mittlerweile der Code aber immer häufiger schon vorkompiliert (Android 
ART, NGEN etc.).

Christian Berger schrieb:
> Oder man nimmt so was wie Lazarus. Da schreibt man seine GUI-Anwendung
> einmal. Formulare kann man bequem zusammenklicken oder in Code erstellen
> oder jede beliebige Mischung daraus. Kompilieren tut das dann ohne
> Änderungen mindestens auf Linux, MacOSX und Windows.

Das geht mit .NET auch. Ich entwickle am Mac, kopiere die .exe auf 
meinen Raspberry Pi und lasse sie dort laufen. Kein problem.
Ich kann sogar vieles von meinem Code auf nem Arduino Clon laufen lassen 
:-)

>Die (oder zumindest eine) Hoffnung hinter .net war, einen Ersatz für die
>native Win32 API zu schaffen.

mit dem Kuriosen Ergebnis, dass IMMER die Nativ API vorher kommt (kommen 
muss) und die .NET Programmierer warten mussten/müssen..

(z.b. die ganzen Erweiterungen für die Taskleiste, wie die Progressbar, 
Vorschaubild, "Aufgaben" usw.)

Boris P. schrieb:
> Jo, so ist es. Der Code wird eben erst zur Laufzeit, und nicht schon
> vorab kompiliert. Das hat aber doch nichts mit virtuellen Cores oder
> Maschinen zu tun.

Die Rolle des Zwischencodes in .NET entspricht ungefähr der des Java 
Bytecodes. Insofern ist das schon vergleichbar. Man kann mscorsvw.exe 
m.W. auch komplett entfernen. Dann ist der strukturelle Unterschied zu 
Java eher gering.

>Dann hilf halt mit es zu verbessern, anstatt hier herumzumeckern.

DAS Tonschlagargument für OpenSource...

Frank K. schrieb:
> Die (oder zumindest eine) Hoffnung hinter .net war, einen Ersatz für die
> native Win32 API zu schaffen.

Technisch ist dieser Ersatz ein auf der Win32-API aufsetzender Layer, 
d.h. alles, was in .Net veranstaltet wird, wird von der .Net-Runtime in 
Win32-API-Aufrufe umgesetzt.

Das Betriebssystemkonzept von Windows NT sieht zwar die Existenz 
verschiedener Subsysteme vor, die mit dem Betriebssystemkern 
kommunizieren, aber reale Umsetzungen davon war neben dem eher 
akademischen Posix-Subsystem eine Zeitlang noch ein OS/2-Subsystem -- 
und natürlich das nach wie vor existierende und jetzt einzige 
Win32-Subsystem.

.Net hingegen ist kein neues Subsystem, sondern nur eine 
Klassenbibliothek/Laufzeitumgebung, die im Win32-Subsystem läuft.

Boris P. schrieb:
> Andreas H. schrieb:
>> Naja, einen ganz wichtigen Punkt hast Du übersehen.
>>
>> Java & .net führen die Programme auf virtuellen CPUs aus. Das heisst,
>> der Compiler übersetzt nicht mehr direkt für die Hardware-CPU, sondern
>> für eine virtuelle Maschine.
>> Die "Assembleranweisungen" der virtuellen Maschine werden dann zur
>> Laufzeit auf der "echten" Hardware ausgeführt.
>
> Oh oh, das ist komplett falsch :-)
> Die Programme werden nativ kompiliert. Nix virtuelle Maschine und so...
>
Eigentlich schon. Bei Java erzeugt der Compiler Bytecode für die JVM, 
bei .NET halt CIL-Bytecode.

Natürlich kann man das auch gleich weiterverarbeiten, indem man dann auf 
die Hardware-CPU-Befehle geht (was aber wirklich ein eigener Schritt ist 
- sonst müsste man ja genau die "Ekelstellen" des Compilers ab ICode neu 
implementieren).
Dann geht aber die Portabilität flöten (was aber oft auch egal ist).

Das Prinzip ist insgesamt aber schon steinalt. Denke mal an UCSD-Pascal 
oder die WAM.

>> Uhu Uhuhu schrieb:
>>> Weil MS bis vor kurzem alles bekämpft hat, was nicht Windows war
>>
>> Bis vor kurzem ???
>
> Momentan portiert Microsoft .NET auch für OS X und Linux.
Strategic marketing ist nicht Deines, oder ? ;-)

/regards
Andreas

Andreas H. schrieb:
> Eigentlich schon. Bei Java erzeugt der Compiler Bytecode für die JVM,
> bei .NET halt CIL-Bytecode.

Was genau willst du damit sagen? Vesrtehe nicht so ganz, worauf du damit 
hinauswillst...

Andreas H. schrieb:
> Strategic marketing ist nicht Deines, oder ? ;-)

Hä? ^^

alt geworden schrieb:
> Für Linux wurde und wird MONO entwickelt. Das erfüllt den gleichen
> Zweck.

Schön wärs. Der ganze GUI-Krempel von .net läuft auf Mono nicht.

Andreas H. schrieb:
>>> Uhu Uhuhu schrieb:
>>>> Weil MS bis vor kurzem alles bekämpft hat, was nicht Windows war
>>>
>>> Bis vor kurzem ???
>>
>> Momentan portiert Microsoft .NET auch für OS X und Linux.
> Strategic marketing ist nicht Deines, oder ? ;-)
>
> /regards
> Andreas

Wenn du schon zitierst, dann bitte so, dass auch die Urheber der Zitate 
korrekt angegeben sind.

Das Zitat stammt nicht von mir.

Uhu Uhuhu schrieb:
> Wenn du schon zitierst, dann bitte so, dass auch die Urheber der Zitate
> korrekt angegeben sind.
>
> Das Zitat stammt nicht von mir.

Sorry, my fault. Da ist die Zeile
">Andreas H. schrieb:"
am Anfang verlorengegangen. War keine pöse Absicht :/

Grüße
Andreas

Boris P. schrieb:
> Andreas H. schrieb:
>> Eigentlich schon. Bei Java erzeugt der Compiler Bytecode für die JVM,
>> bei .NET halt CIL-Bytecode.
>
> Was genau willst du damit sagen? Vesrtehe nicht so ganz, worauf du damit
> hinauswillst...

Java & .NET arbeiten nicht nach dem "klassischen" Prinzip 
"Src-->AST-->ICode-->Asm-->Executable". Asm wäre hier schon Code 
(assembler), der auf der Zielhardware ausgeführt ausgeführt würde. (Der 
letzte Schritt ist hier das Linken).
Stattdessen compiliert man für eine nichtreale (virtuelle) Maschine, 
also "Src-->AST-->ICode-->VAsm". Der Loader (also das was das Programm 
nachher in den Speicher lädt) führt dann erst zur Laufzeit den Schritt 
VAsm-->Executable durch. Vorteil: Das Compilat (also bis incl. VAsm & 
Libs) ist CPU-Typ unabhängig.

Eine "Vereinfachung" dazu ist, dass man "VAsm-->Executable" direkt beim 
Compile anhängt (das ist dass, was Du beschreibst). Vorteil: Bessere 
Startzeit des Programms aber trotzdem nur ein Compileraufbau (bis VAsm), 
also wenig "Nervware", die bei neuer Zielhardware implementiert werden 
muss. Nur die "Low-level" Optimierungen (die heute nicht mehr trivial 
sind^^) muss man neu schreiben.

Natürlich ist das in der Praxis etwas verworrener. Ich habe hier z.B. 
das Linken komplett aussen vor gelassen. Aber ich hoffe, die Idee ist 
klar geworden.

/regards
Andreas

Christian Berger schrieb:
> Ja, das war reinstes Marketing, es gab so ein paar Ideen die so halbwegs
> konkret waren. Zum Beispiel wollte Microsoft so eine Art "zentrale
> Authentifikation" für das Internet bauen.

Wieso wollte? Siehe Passport heute Microsoft Account

> Der Java-Ersatz ist so ziemlich das einzige was übrig blieb,

Wenn es nur ein Java-Ersatz wäre, wäre es schon längst von der 
Bildfläche verschwunden.

> und in den Wahrnehmungsblasen einiger Leute ist das auch so richtig
> erfolgreich.

Die Wahrnehmungsblasen sind meist in der Umgebung der Kritiker...
Fast die gesamten Features von NGWS sind implementiert worden und bis 
heute im Einsatz... Von Passport heute Microsoft Account bis 
UI-Frameworks (damals Avalon, dann WPF und heute XAML Framework).

http://news.microsoft.com/2000/06/22/microsoft-unveils-vision-for-next-generation-internet/

> Typische Beispiele sind:
>
> Windows for Pen Computing (eine Erweiterung für Windows 3.1 und 95 um
> Formulare mit Stiften ausfüllen zu können)

Das war brauchbar, eingestellt wurde es auch nicht. Kam danach für 
Windows 95, dann als XP Tablet Edition und ist seit Vista Bestandteil 
des OS

> Objektorientierte Dateisysteme

Aka WinFS. Teile sind u.a. in MSSQL, ADO(.NET) gewandert. 
Objektorientiert war es eher nicht en.wikipedia.org/wiki/WinFS

> Personas in Windows NT

Das Unix-Subsystem gibt's immer noch, auch als SDK für Server 2012 und 
W8... http://www.microsoft.com/en-us/download/details.aspx?id=35512
Von einer Unterstützung von MacOS-Anwendungen ist mir nichts bekannt.

> OLE

Microsoft hat viel zu lange, das OS an die Fehler der Dritthersteller 
angepasst. Siehe z.B. http://blogs.msdn.com/b/oldnewthing/ (Raymond 
Chens Blog)
Zudem gibt es die Basis von OLE, COM immer noch, eingesetzt in der 
Windows Runtime. Ebenso existiert DCOM aka Network OLE immer noch.


Hannes Jaeger schrieb:
> Lange Geschichte, sehr kurze Version:
>
> Der ursprüngliche Zweck von .NET war pures, reines Marketing. MS hat den
> Begriff zuerst in die Welt gesetzt ohne selber genau zu wissen was das
> ist. Da gab es von MS Broschüren und Zeitungsanzeigen, die waren so
> nichtssagend, die hätten auch komplett unbedruckt sein können. Es war
> einfach ein "Ding" von Microsoft, das "irgendwie gut" ist und "alles"
> kann. Weder MS, noch Programmierer, noch Kunden wussten am Anfang was
> .NET wirklich ist, bzw. sein sollte.

Angekündigt auf der PDC 2000, Beta Ende 2000, RTM Anfang 2002

> Erfunden wurde das "Ding", weil MS auf dem Desktop die Felle davon
> schwammen.

Ende der 1990er/Anfang der 2000er? Klar... Da gab's noch keine iPhones, 
iMacs, Android-Phones und irrelevante Chromebooks etc. Apples 
Marktanteil war von teilweise ~10% auf 2% zusammengeschrumpft und die 
gesamten anderen Betriebssysteme auf dem Desktop schon längst 
bedeutungslos (auf dem Server konnte zu dieser Zeit allerdings Linux 
schon massiv Marktanteile gewinnen, lag da afair schon bei 25%)

http://arstechnica.com/features/2005/12/total-share/9/

Arc Net schrieb:
> Ende der 1990er/Anfang der 2000er?

Möglicherweise geraten da ein paar Events durcheinander. Als Java aufkam 
hatte Microsoft erhebliche Sorgen, dass dessen Portabilität ihnen das 
Wasser abgräbt, d.h. x86-PCs unter Windows als Clients durch beliebige 
Plattformen ersetzbar werden könnten. Microsofts Schnellschuss darauf 
war aber nicht .NET, sondern ActiveX.

>http://www.microsoft.com/en-us/download/details.aspx?id=35512

ist das nicht "depraced" und ab Win10 abgeschafft?

Arc Net schrieb:
> Christian Berger schrieb:
>> Ja, das war reinstes Marketing, es gab so ein paar Ideen die so halbwegs
>> konkret waren. Zum Beispiel wollte Microsoft so eine Art "zentrale
>> Authentifikation" für das Internet bauen.
>
> Wieso wollte? Siehe Passport heute Microsoft Account

Ahh OK, ich dachte das basiert jetzt auf offenen Standards. Und 
zugegeben hab ich das auch immer ignoriert.

>> Der Java-Ersatz ist so ziemlich das einzige was übrig blieb,
>
> Wenn es nur ein Java-Ersatz wäre, wäre es schon längst von der
> Bildfläche verschwunden.

Warum das?

> Die Wahrnehmungsblasen sind meist in der Umgebung der Kritiker...
> Fast die gesamten Features von NGWS sind implementiert worden und bis
> heute im Einsatz... Von Passport heute Microsoft Account bis
> UI-Frameworks (damals Avalon, dann WPF und heute XAML Framework).
> 
http://news.microsoft.com/2000/06/22/microsoft-unveils-vision-for-next-generation-internet/

Zugegeben ich hab noch nichts davon irgendwo eingesetzt gesehen. 
Welche Websites benutzen das denn?

>> Typische Beispiele sind:
>>
>> Windows for Pen Computing (eine Erweiterung für Windows 3.1 und 95 um
>> Formulare mit Stiften ausfüllen zu können)
>
> Das war brauchbar, eingestellt wurde es auch nicht. Kam danach für
> Windows 95, dann als XP Tablet Edition und ist seit Vista Bestandteil
> des OS

Nein, XP Tablet Edition war technisch anders. WfPC setzte Änderungen der 
Anwendungen voraus und unterstützte das direkte Eintragen von Text in 
Formularfelder. Inklusive Texterkennung.

>> Personas in Windows NT
>
> Das Unix-Subsystem gibt's immer noch, auch als SDK für Server 2012 und
> W8... http://www.microsoft.com/en-us/download/details.aspx?id=35512
> Von einer Unterstützung von MacOS-Anwendungen ist mir nichts bekannt.

Ja das Subsystem ist aber quasi tot. Von der MacOS-Unterstützung sind 
nur noch ein paar Reste in NTFS drin. MacOSX haben die gar nicht mehr 
angekündigt.

>> OLE
>
> Microsoft hat viel zu lange, das OS an die Fehler der Dritthersteller
> angepasst. Siehe z.B. http://blogs.msdn.com/b/oldnewthing/ (Raymond
> Chens Blog)
> Zudem gibt es die Basis von OLE, COM immer noch, eingesetzt in der
> Windows Runtime. Ebenso existiert DCOM aka Network OLE immer noch.

Klar, natürlich DCOM gibts noch, muss es auch geben da viele 
industrielle Steuerungssysteme auf diese "Zukunftstechnologie" setzen.

Du sprichst ein interessantes Problem an, und das ist, dass Microsoft ja 
den Missbrauch ihrer APIs mit unterstützen muss der Kompatibilität 
halber.

Das ist richtig, ignoriert aber einen sehr wichtigen Punkt. APIs müssen 
so gebaut sein, dass sie möglichst einfach zu nutzen sind. Und das hat 
Microsoft halt ignoriert. Die APIs waren schon immer kompliziert und 
löchrig dokumentiert. Das lag zum einen daran, dass man früher einfach 
nicht den Arbeitsspeicher hatte es ordentlich zu machen. Windows lief ja 
mal auch schon mit 4 Megabyte RAM. Zum anderen liegt es daran dass 
Microsoft unterschiedliche Paradigmen so halb zu implementiert hat. Das 
Fenstersystem ist zum Beispiel an Smalltalk orientiert, spätere 
Bibliotheken dazu wurden in C++ implementiert. Alles, aber auch wirklich 
alles, wird mit DLLs gelöst, was dazu führt dass Du plötzlich binäre 
Strukturen durch Deine API schleusen musst. Und diese Stukturen werden 
dann von 16 auf 32 auf 64 Bit erweitert... was schief geht.
Das wusste auch Microsoft damals schon besser.

Christian Berger schrieb:
> Ahh OK, ich dachte das basiert jetzt auf offenen Standards. Und
> zugegeben hab ich das auch immer ignoriert.

Ja und nein. MS ist Mitglied der OpenID und Passport/MS Account wohl 
auch ein OpenID-Provider (selbst noch nicht genutzt, daher nur ein Link 
http://www.golem.de/0810/63202.html)

>> Wenn es nur ein Java-Ersatz wäre, wäre es schon längst von der
>> Bildfläche verschwunden.
>
> Warum das?

Welches Framework mit ähnlichem Umfang von Mobile über Desktop bis (Web 
und Server mit entsprechender Herstellerunterstützung gab es denn?
Hätte MS einfach zugesehen, wäre Java u.U. wirklich zu einem Problem 
geworden.

>> Die Wahrnehmungsblasen sind meist in der Umgebung der Kritiker...
>> Fast die gesamten Features von NGWS sind implementiert worden und bis
>> heute im Einsatz... Von Passport heute Microsoft Account bis
>> UI-Frameworks (damals Avalon, dann WPF und heute XAML Framework).
>>
> 
http://news.microsoft.com/2000/06/22/microsoft-unveils-vision-for-next-generation-internet/
>
> Zugegeben ich hab noch nichts davon irgendwo eingesetzt gesehen.
> Welche Websites benutzen das denn?

Wieso Webseiten? WPF/XAML-Framework sind deklarative UI-Frameworks (XAML 
ist XML basiert). Das XAML-Framework ist die neuere Variante für die 
Windows Runtime.
Wenn's um ASP.Net geht: Stackoverflow.com, Microsoft.com, bing.com, 
godaddy.com, dell.com

>>> Personas in Windows NT
>>
>> Das Unix-Subsystem gibt's immer noch, auch als SDK für Server 2012 und
>> W8... http://www.microsoft.com/en-us/download/details.aspx?id=35512
>> Von einer Unterstützung von MacOS-Anwendungen ist mir nichts bekannt.
>
> Ja das Subsystem ist aber quasi tot. Von der MacOS-Unterstützung sind
> nur noch ein paar Reste in NTFS drin. MacOSX haben die gar nicht mehr
> angekündigt.

Für MacOS würde mich mal die Quelle interessieren.
Kann aber auch schlicht eine Verwechslung sein:
HPFS = IBM OS/2 HFS = Apple

> Du sprichst ein interessantes Problem an, und das ist, dass Microsoft ja
> den Missbrauch ihrer APIs mit unterstützen muss der Kompatibilität
> halber.
>
> Das ist richtig, ignoriert aber einen sehr wichtigen Punkt. APIs müssen
> so gebaut sein, dass sie möglichst einfach zu nutzen sind. Und das hat
> Microsoft halt ignoriert. Die APIs waren schon immer kompliziert und
> löchrig dokumentiert.

Das Argument halte ich für nicht sehr tragfähig. Ich habe hier 
Win32-Anwendungen (kein MFC etc.) aus den Anfängen der 90er. Die sehen 
heute zwar komisch aus, aber funktionieren.
Der Punkt ist (kenne das selbst aus ST, Amiga und Palm-Zeiten), dass 
einige Dinge, die gewünscht sind, nicht mit den vorgegebenen APIs 
umsetzbar sind ohne z.T. massiv zu tricksen oder das OS gleich ganz zu 
umgehen.
MS hat da imo zu lange den falschen Weg gewählt: Lieber keinen Kunden 
vergraulen und im OS z.T. Abfragen auf die laufenden Anwendungen 
einzubauen statt die APIs entweder zu dokumentieren oder dicht zu machen 
(kurze Fehlermeldung wenn ein Programm, da was "illegales" macht, hätte 
gereicht).

> Das lag zum einen daran, dass man früher einfach
> nicht den Arbeitsspeicher hatte es ordentlich zu machen. Windows lief ja
> mal auch schon mit 4 Megabyte RAM. Zum anderen liegt es daran dass
> Microsoft unterschiedliche Paradigmen so halb zu implementiert hat. Das
> Fenstersystem ist zum Beispiel an Smalltalk orientiert, spätere
> Bibliotheken dazu wurden in C++ implementiert. Alles, aber auch wirklich
> alles, wird mit DLLs gelöst, was dazu führt dass Du plötzlich binäre
> Strukturen durch Deine API schleusen musst. Und diese Stukturen werden
> dann von 16 auf 32 auf 64 Bit erweitert... was schief geht.
> Das wusste auch Microsoft damals schon besser.

Lässt sich z.T. nicht vermeiden... z.B. Zeiger. Zudem wäre zu der Zeit 
auch der Implementierungsaufwand/Speicherbedarf/Performanceoverhead nur 
sehr schwer zu rechtfertigen gewesen.


Jay schrieb:
> unzuverlässig

Wann das letzte Mal getestet?
http://www.mono-project.com/docs/about-mono/showcase/companies-using-mono/

> und von Patentforderungen bedroht. Die kürzlich erfolgte Codespende von
> Microsoft ändert daran auch nichts.

https://github.com/dotnet/corefx/blob/master/PATENTS.TXT

So langsam kann ich die z.T. hasserfüllten Hater von der FSF nicht mehr 
hören. So gut wie JEDE Software, egal was, ist direkt oder indirekt 
aufgrund der BESCHISSENEN Softwarepatente/Rechtslage bedroht.
Und zwar nicht durch MS. Hier wird's auch noch lustig werden, wenn TTIP 
durch ist.

Arc Net schrieb:

> Der Punkt ist (kenne das selbst aus ST, Amiga und Palm-Zeiten), dass
> einige Dinge, die gewünscht sind, nicht mit den vorgegebenen APIs
> umsetzbar sind ohne z.T. massiv zu tricksen oder das OS gleich ganz zu
> umgehen.
> MS hat da imo zu lange den falschen Weg gewählt: Lieber keinen Kunden
> vergraulen ...


Kunden?
MS war doch unter den ersten, die ihre eigenen APIs und sonstige 
MS-Standards missbraucht haben.
Kann mich noch gut erinnern, als ich das erste mal für Windows 
programmiert habe. Da kriegt man zum Compiler noch fette gedruckte 
Dokumentation dazu. Inklusive Styleguide, wie eine Windows-Applikation 
auszusehen hat und wie sie sich zu verhalten hat. Die ersten, die das 
komplett ignoriert haben, war MS selber.