Delphi-PRAXiS
Seite 4 von 7   « Erste     234 56     Letzte »    

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   .net-Strategie von Microsoft (?) (https://www.delphipraxis.net/110134-net-strategie-von-microsoft.html)

Chemiker 13. Mär 2008 19:35

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

mkinzler 13. Mär 2008 19:40

Re: .net-Strategie von Microsoft (?)
 
Im Notfall kann man immer mit Hilfe von P/INVOKE, COM/INVOKE auf die native Ebene zugreifen.

Dax 13. Mär 2008 19:52

Re: .net-Strategie von Microsoft (?)
 
Zitat:

Zitat von Chemiker
wie ist die Zusammenarbeit zwischen .NET und Assembler.

Wie meinst du das.. Sowas wie Inline-Assembly in Delphi? Das gibt es nicht. Du kannst zwar deinen Code auch als ILasm schreiben, was gewissermassen auch Assembler ist - nur eben für eine virtuelle Maschine statt für eine reale. "Echten" Assemblercode musst du aber per P/Invoke einbinden.

Zitat:

Zitat von Chemiker
Gibt es Komponenten um eine serielle Schnittstelle anzusprechen?

Seit 2.0 ist sogar eine im Framework enthalten ;)

Zitat:

Zitat von mkinzler
Im Notfall kann man immer mit Hilfe von P/INVOKE, COM/INVOKE auf die native Ebene zugreifen.

Die genannten Techniken sind hässlich und zum Zeil fehleranfällig ;) Aber sie können auch extrem nützlich sein - viele DB-Provider setzen auf P/Invoke, und der Win32-Teil des Frameworks ist ohne P/I nicht vorstellbar.

Jelly 13. Mär 2008 20:03

Re: .net-Strategie von Microsoft (?)
 
Zitat:

Zitat von Chemiker
Wie kann man mit .NET eine SPS programmieren?

Das kann man sehr wohl. Ich hatte mal eine OPC Bibliothek, das ganze für .NET... Leider weiss ich nicht mehr wie die hiess, aber google mal nach OPC und .NET.

Macci 13. Mär 2008 20:04

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

bluesbear 13. Mär 2008 20:05

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:

mkinzler 13. Mär 2008 20:06

Re: .net-Strategie von Microsoft (?)
 
Zitat:

Was mir daran allerdings gar nicht gefällt ist, dass Pointer praktisch völlig fehlen
Braucht man auch nicht.

jfheins 13. Mär 2008 20:10

Re: .net-Strategie von Microsoft (?)
 
Zitat:

Zitat von mkinzler
Zitat:

Was mir daran allerdings gar nicht gefällt ist, dass Pointer praktisch völlig fehlen
Braucht man auch nicht.

Wenn du unbedingt Spaß (no Risk no Fun ^^) haben willst, kannste ja alle Variablen als System.Object (oder so ... die Grundklasse von allem halt ^^) deklarieren ;)

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 ;)

phXql 13. Mär 2008 20:11

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

bluesbear 13. Mär 2008 20:15

Re: .net-Strategie von Microsoft (?)
 
Zitat:

Zitat von mkinzler
Zitat:

Was mir daran allerdings gar nicht gefällt ist, dass Pointer praktisch völlig fehlen
Braucht man auch nicht.

Pointer sind antike Nervzwerge aus der Assembler-Zeit. Man kann damit umgehen. Schöner wäre es, sich um sowas keinen Kopp machen zu müssen.


Alle Zeitangaben in WEZ +1. Es ist jetzt 20:35 Uhr.
Seite 4 von 7   « Erste     234 56     Letzte »    

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