![]() |
Re: .net-Strategie von Microsoft (?)
Hallo,
hier sind ja die erfahrende .NET Programmierer. Deshalb mal einige Fragen, wie ist die Zusammenarbeit zwischen .NET und Assembler. Gibt es Komponenten um eine serielle Schnittstelle anzusprechen? Wie kann man mit .NET eine SPS programmieren? Bis bald Chemiker |
Re: .net-Strategie von Microsoft (?)
Im Notfall kann man immer mit Hilfe von P/INVOKE, COM/INVOKE auf die native Ebene zugreifen.
|
Re: .net-Strategie von Microsoft (?)
Zitat:
Zitat:
Zitat:
|
Re: .net-Strategie von Microsoft (?)
Zitat:
|
Re: .net-Strategie von Microsoft (?)
.NET ist eine Konkurrenz zu Java. Als Microsoft damals J++ herausbrachte, war das so beliebt, dass Sun Microsoft promt verklagte, weil die mit J++ entwickelten Java-Anwendungen zu windowsähnlich waren. Microsoft musste daraufhin ihr J++ mit sovielen Warnmeldungen spicken, dass es für die User unattraktiv wurde. Deswegen entschloss man sich bei MS dann eine eigene platformunabhängige Virtualisierungsumgebung zu erschaffen, und das Ergebnis davon ist .NET. Solche Anwendungen können dann z.B. mit Visual C# geschrieben werden. Was mir daran allerdings gar nicht gefällt ist, dass Pointer praktisch völlig fehlen. Deswegen bleibe ich bei Delphi und C++.
Viele Grüße, Macci |
Re: .net-Strategie von Microsoft (?)
Hallo Chemiker,
ich habe das Gefühl das ist irgendwie die falsche Frage. Wie soll ich das erklären? Ich versuche das mal konkred krass vereinfacht. Also ganz am Anfang gab es Assembler. Damit sagt man dem Prozessor, was der tun soll. alle Ports usw. bekannt. (Ich hatte mir damals eine Seagate Festplatte an meinen Atari ST gebaut. Ja, ich kann löten). Ok, das war OT. Dann kam C, damit man nicht mehr mit Registern und Speicheradressen rummachen musste. Dann kamen die Hochsprachen, manche davon objektorientiert, und ich lasse sowas wie LISP oder PROLOG mal bewußt außen vor. Es wurde mit der Zeit immer abstrakter. Man hat sich lösen können von Prozessoren und Registern, das konnte man einem Compiler überlassen. Die logische Fortsetzung davon ist, sich von Betriebssystemen zu abstrahieren. Bytecodesysteme wie .NET schaffen das. Oder Java. Nur bei .NET abstrahiert man sich nicht vom Hersteller des Betriebssystems <g>. Microsoft unterstützt Mono, habe ich in diesem Thread gelesen. Ja wie sehr haben die die Zügel in der Hand. <eg> Das ist heute eine schwierige Zeit. Man kann schwer absehen, wo der Hase hin läuft. Java oder .NET? Vom Konzept her ist das klar: Wenn es eine Entwicklungsumgebung und Programmiersprache geben sollte, mit der man Betriebssystemübergreifend brauchbare Programme schreiben kann - ich würde das benutzen. Da geht die Zukunft hin. Wenn ich es könnte bzw. wüsste, oder genug Zeit für die Einarbeitung hätte. Habe ich nicht. Ich Schuster bleibe bei meinen Leisten, und tu das, was ich kann. :mrgreen: |
Re: .net-Strategie von Microsoft (?)
Zitat:
|
Re: .net-Strategie von Microsoft (?)
Zitat:
Ansonsten ist ja eh alles Objekt, du wirst also nur selten in die Verlegenheit kommen "Ich nehm mal nen Pointer damit ich nicht mehr das ganze gedöns durch die Gegend schiebe" - und Call by Reference gibt es ja nach wie vor ;) |
Re: .net-Strategie von Microsoft (?)
Das is schon sehr gut so dass diese Pointer fehlen.
Und man kann mit .NET problemlos Programme schreiben, die unter Windows und Linux laufen. Das neuste Mono unterstützt sogar zu 98% WinForms, d.h. man muss nichmal WxWidgets, GTK etc verwenden. Grüße, phXql |
Re: .net-Strategie von Microsoft (?)
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:35 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz