über .Net nörgeln

Knuddlbaer schrieb:

Wird eine Textdatei, die man Secret.exe nennt denn ausführbar ? Ist eine Secret.com die ich Secret.txt nenne denn eine Textdatei ?

Einspruch: "Polemik"

Knuddlbaer schrieb:

Du könntest ja eine Liste implementieren wollen, die Elemente vom Index -50 bis 49 hält

Ja und eine die was anderes benutzt. Dann hätte man korrekter Weise object als Indextyp nehmen sollen.

zwutz

Knuddlbaer schrieb:

Was erkenne ich an Secret.exe denn genau ? Was wenn ich Secret.exe und Secret.com in einem Verzeichnis habe ? Was sagt mir die Endung denn ?!

Wird eine Textdatei, die man Secret.exe nennt denn ausfuehrbar ? Ist eine Secret.com die ich Secret.txt nenne denn eine Textdatei?

Dateilisting unter Windows:

bar\
blubb.exe
foo.txt
command.com

unter Linux:

bar
blubb
foo
command

man erkennt sofort, welche Dateien welchen Zweck erfuellen... Man kann Endungen bestimmten Anwendungen zuordnen, mit der sie geoeffnet werden sollen (.cvs und .txt sind beides reine Textdateien, erstere wuerd' ich aber nie mit notepad und letztere nie mit Excel oeffnen) und ausserdem ist in Filelistings eine einfache Filterung nach gewuenschten Dateitypen moeglich.

Darueber hinaus sind Dateiendungen fuer den Betrieb vieler Anwendungen zwingend erforderlich (auch ein Compiler geht nach Dateiendungen)

Vorden

also irgendwann gabs mal die Diskussion um Dateiendungen schon
und afaik gabs da auch mal einen kleinen Glaubenskrieg von den vermeintlich "Großen" zu dem Thema
ich denk, da kann man sich jetz auch lange drüber streiten, ob eine Dateiendung sinnvoll ist oder nicht
Aber ich denke, dass das .NET-Framework ja noch ein wenig mehr zu bieten hat, als *.exe-Dateien in binärer Form (oder halb-binär).

zwutz schrieb:

Knuddlbaer schrieb:

Was erkenne ich an Secret.exe denn genau ? Was wenn ich Secret.exe und Secret.com in einem Verzeichnis habe ? Was sagt mir die Endung denn ?!

Wird eine Textdatei, die man Secret.exe nennt denn ausfuehrbar ? Ist eine Secret.com die ich Secret.txt nenne denn eine Textdatei?

Dateilisting unter Windows:
bar\
blubb.exe
foo.txt
command.com
unter Linux:
bar
blubb
foo
command
man erkennt sofort, welche Dateien welchen Zweck erfuellen... Man kann Endungen bestimmten Anwendungen zuordnen, mit der sie geoeffnet werden sollen (.cvs und .txt sind beides reine Textdateien, erstere wuerd' ich aber nie mit notepad und letztere nie mit Excel oeffnen) und ausserdem ist in Filelistings eine einfache Filterung nach gewuenschten Dateitypen moeglich.

Darueber hinaus sind Dateiendungen fuer den Betrieb vieler Anwendungen zwingend erforderlich (auch ein Compiler geht nach Dateiendungen)

du hast nicht verstanden, was knuddelbär gesagt hat

zwutz

typischtroll schrieb:

du hast nicht verstanden, was knuddelbaer gesagt hat

dann sag du es mir doch

Was man gerne hat:
Typen für Dateien, wegen der genannten Vorteile.

Was man nicht gerne hat:
Den Typ im Dateinamen kodiert.

Windows mach beides.
Linux keines (Flag für ausführbar zählt nicht)
Ein Dateisystem mit Datei typen als "Metadata" oder so ähnlich gibt es meines Wissens nicht (Warum eigentlich?)

Back to .Net Nörgeln

sothis_

zwutz schrieb:

typischtroll schrieb:

du hast nicht verstanden, was knuddelbaer gesagt hat

dann sag du es mir doch

das war kein troll. das war nur ich von einem anderen rechner. seit wann gibt dir die dateiendung garantie über den inhalt? ist schon toll das windows alles nach endung überprüft und entprechende programme nach doppelklick dann schön abstürzen weil der inhalt nicht zur dateienddung passt
unter unix-derivaten gibt es übrigens ein schönes tool names file. ein, zwei zeilen bashscript, und ich kann wesentlich verlässlicher dateien nach inhalt auflisten, als es mit diesen schwachsinnigen dateiendungen möglich ist.

Knuddlbaer

Man Dateiendungen wollte ich hier nicht diskutieren. Aber gut, kurzer Ausflug.

Unter Linux zeigst Du uns die einfache Auflistung eines Verzeichnisses. Dann verwende auch bitte unter Windows die einfache Version (/B)

C:\t\test>dir /b
datei
verzeichnis

Beim Verzeichnis gibt es - zumindest bei mir unter cmd - kein \

bar\
blubb.exe
foo.txt
command.com

Alles was ich da sehe: Eine Datei namens blubb.exe , foo.txt und command.com . Ob command.com nun ausführbar ist oder eine Textdatei ist, sieht man an diesem Listing nicht.

Mein guter alter Amiga A500 konnte auch Anwendungen Dateitypen zuordnen, ganz frei von Dateiendungen. Hierzu wurde einfach der Header der Datei analysiert und zugeordnet. Dateiendungen sind schlicht nicht zwingend erforderlich. (Kurzum: Wenig Rechenleistung, keine Dateiendungen, kein Veralbern von Anwendern in dem man einfach eine Datei umbenannte.)

Wie aber gesagt wurde, gab es diesen Glaubenskrieg bereits und hier möchte ich viel mehr Probleme mit dem Framework diskutieren , nicht alte Glaubenskriege ausgraben. Oder diesen bitte in einem neuen Thread anzetteln.

Collections, die als Positionsangabe ein object entgegen nehmen nennen sich z.B. Dictionary.

Würde für einen numerischen Index ein object verwendet, hättest Du massig Nachteile durch (un|%)boxing. Dies durch ein Interface erzwungen bedeutet massig Performanceverlust für alle folgenden Klassen.

Diese Ansicht stellt eine Möglichkeit dar, warum viele Collections einen int nehmen. Möglich wäre es auch, das die Entwickler zu faul waren uint zu schreiben weil int einfach sitzt. Die genauen Gründe kennen wohl nur die Designer.

Ja und eine die was anderes benutzt. Dann hätte man korrekter Weise object als Indextyp nehmen sollen.

Polemik ?

zwutz

auch von mir die letzte Antowrt zu dem Thema

bei command.com sieht man tatsaechlich nicht, ob es nun ausfuehrbar oder eine Textdatei ist (genausowenig wie bei command). Aber man sieht, dass wahrscheinlich versucht wird, sie auszufuehren.

Und die Moeglichkeit ueber die Dateiheader gibt es auch, aber das erfordert zumindest Leserechte um zu wissen, was mit der Datei geschieht... und natuerlich muss die Datei geoeffnet werden... bei einem Verzeichnis mit mehreren hundert Dateien alle erstmal zu oeffnen, nur um sie danach wieder auszufiltern erscheint mir aber ein wenig ineffizienter als ein reines Filtern nach .xxx am Ende des Dateinamens
Noch dazu haben Textdateien keinen Dateiheader, obwohl wie gesagt eine csv-Datei niemand mit einem Texteditor oeffnen will...

hustbaer

templäd schrieb:

Da das der Nörgel Thread ist geb ich auch mal was dazu.

Einer meiner wenigen Kritikpunkte an .Net (ab 2.0) ist der Indexoperator in den .Net Collections. Kann einfach nicht verstehen warum der einen signed parameter nimmt.

Btw. wieso ist die Syntax eigentlich so komisch oder kommt das nur mir so vor
class  Test
{
   public int this[uint id]
   {
      return ...;
   }
}

Der Grund ist AFAIK dass das Common Type System nicht vorschreibt dass eine Sprache unsigned Typen unterstützen muss.

Talla

EDIT: Mist zu lang zum schreiben gebraucht

Diese Ansicht stellt eine Möglichkeit dar, warum viele Collections einen int nehmen. Möglich wäre es auch, das die Entwickler zu faul waren uint zu schreiben weil int einfach sitzt. Die genauen Gründe kennen wohl nur die Designer.

*lol* Interessante Gedanken, aber stimmen leider nicht
Die wissen schon warum sie das gemacht haben.

Um die Menge an verfügbaren und zukünftigen .Net Sprachen unter einem Hut zu bringen, muss eine bestimmte Menge an Funktionalität vorgeschrieben werden, dass sprachübergreifend problemlos zusammengearbeitet werden kann. Dafür gibts die CLS (Common Language Specification). Was dort drin steht muss eine Sprache erfüllen um als .Net kompatibel zu gelten.

Unsigned Datentypen gehören nicht dazu! Deshalb darf in der Klassenbibliothek überhaupt nie irgendwo unsigned ... verwendet werden, da sonst nicht garantiert wäre dass die Klasse mit allen .Net Sprachen benutzt werden kann. Somit erledigt sich die Frage warum IList einen signed Integer verwendet und nicht ein unsigned.

Einem selber steht es natürlich frei auch Indexer mit anderen Datentypen zu implementieren, aber kompatibel zu allen Sprachen wird das nur bedingt.

Und für eine Liste mit numerischen Index object als Indextyp zu verwenden ist doch unsinnig. Wie Knuddelbaer sagt, da gibts Dictionaries die Schlüssel/Wert Paare speichern.

Danke für die Info!
CLS enthält keine unsigned typen !wichtig! werd ich mir merken.
Über die eigenartige Syntax zur Definition eine [] operators kann ich hinwegsehen.

Ansonsten scheint es mir so als gäbe es nicht so viel zu Nörgeln oder?
Ich überlege noch ein bißchen.

asc

Also über die Dateiendung zu nörgeln finde ich auch schon fehl am Platz, da die Technologie nun mal von der MS-Plattform ausgeht wo sie bislang immer Standard war. Zumindestens kann ich dies nicht .Net anlasten.

Ich bin jetzt nicht von .Net 100%ig überzeugt, muss aber dennoch sagen das mir viele Ansätze im .Net (gerade ab den .Net Framework 3.0; ins Besondere WPF, WCF...) sehr zusagen. Das Problem mit dem Monopolist sehe ich durchaus, aber ich bewerte eine Programmierumgebung mehr nach der Handhabung als nach dem Namen der dahinter steckt). Eine höhere Portabilität und Standardisierung fände ich auch gut, und ich hoffe das Mono weitgehend nachziehen kann (wobei ich nicht damit Rechne das z.B. WPF kurzfristig portiert wird - wobei dies mit OpenGL-Mitteln wohl auch machbar sein dürfte).

cu André

simon.gysi

Knuddlbaer schrieb:

Nun, die Kritik bezieht sich, wenn auch vllt. etwas überzogen, IMHO auf die Tatsache, das .Net sehr nahe an Windows gebaut ist. Sollte es doch Plattformübergreifend sein, findet man sehr viele parallelen zur WinAPI.

Vergessen sollte man hier jedoch nicht das Project Mono - was zwar die Möglichkeit eröffnet auf Windowsfremden Plattformen zu arbeiten aber die komplette Plattformunabhängigkeit (noch) nicht bieten kann.

Bei .NET war eines der Ziele Sprachunabhängigkeit, nicht die Platformunabhängigkeit.

Gruss Simon

Krux

zur Java JRE gabs auch andere Sprachen, wie zum beispiel Groovy. Aber produktiv arbeiten kann man damit schon, auch wenn es unter Linux dazu doch etwas einrichtungszeit benötigt, weil .NET eben nicht alles bietet, um Plattformunabhängig zu sein. Genannt habe ich die dinge schon, die Probleme verursachen, wie zum Beispiel dass sich .NET auf wildows DLLs stützt, die unter Linux einfach nicht verfügbar sind. Aber wenn es sich doch noch um DLLs handelt, die als lib.so unter Linux vorhanden sind, dann haben die einen anderen namen, was dazu führt, das sie ohne weiteres nicht gefunden werden. Vieles, was auf Windows sehr sauber aussieht, wird damit unter Linux zu einer unschönen Frickelei. Die Dateiendung .exe stört deshalb, weil ich unter linux gerne meine Mono programme eindeutig identifiziert haben möchte, damit ich sie in verbindung mit der mono plattform Bringen kann, das geht aber nicht, weil es auch noch Programm gibt, die die endung .exe haben, allerdings mit wine gestartet werden sollen. Ansonsten ist mir die Endung ziemlich egal, sie soll ihren Zweck als Typ-Identifizierung übernehmen, was sie hier allerdings nicht mehr kann.

Zur Diskussion, dass man eine Dateiendung einfach ändern kann, was dazu führt, dass die Dateien mit den falschen Anwendungen geöffnet werden. Sollte der Dateityp im Header Stehen, wer sollte einen Anwender daran hindern, den Header zu ändern? So kann man auf die gleichen Fehler kommen. Die beiden Arden den Typ einer Datei festzustellen sind somit gleichwertig. Die einzige sicherheitslücke ist es die dateiendungen ausblenden zu lassen, denn so sieht eine Wichtig.pdf.exe wie ein harmloses dokument aus, kann sich aber als ein gefährlicher Virus entpuppen. Aber wer stellt schon die Dateiendungen ab? Ich hoffe hiermit ist die Diskussion über Dateiendungen endgültig erledigt.

CMatt

asc schrieb:

wobei ich nicht damit Rechne das z.B. WPF kurzfristig portiert wird - wobei dies mit OpenGL-Mitteln wohl auch machbar sein dürfte).

Denkst du? Ich glaube das nicht das es noch allzu lange dauern kann bis ein paar 3D-Freaks sich Moonlight krallen, OpenGL darunter schieben und Schritt für Schritt die Fehlenden Sachen nachbauen. Jetzt da es WPF/E schon open source gibt ist die Schwelle nicht mehr so hoch als wenn gar nichts da ist bis auf etwas Doku im MSDN und das XAML-Schema

Krux

Sollte sich Silverlight durchsetzen, was wird dann aus Flash? und Newgrounds? Aber die Hardwareunterstützung sprich ja schon für Silverlight, das hat imho Flash noch nicht.

Ich hab mal gehört, Microsoft will sogar ein eigenes Microsoft PDF herausbringen will. Ich kann nur hoffen, dass sich das nicht durchsetzt, weil Monopole sind Scheiße. Und wer jetzt nur auf die Microsoft Plattform setzt, der ist später mitschuld, falls Microsoft diesen Status erreichen sollte.

Konrad Rudolph

Krux schrieb:

Sollte sich Silverlight durchsetzen, was wird dann aus Flash? und Newgrounds? Aber die Hardwareunterstützung sprich ja schon für Silverlight, das hat imho Flash noch nicht.

Viel wichtiger ist, dass sich Silverlight in erster Linie an Entwickler richtet und hier eine wesentltlich bessere Plattform als Flash/Flex bietet.

Ich hab mal gehört, Microsoft will sogar ein eigenes Microsoft PDF herausbringen will.

Gibt es schon: XPS.

Wobei ich es vom technologischen Standpunkt eigentlich interessanter finde, dass WPF auch Dokumentbeschreibung zulässt. Mal schaun, was daraus wird.

Ich kann nur hoffen, dass sich das nicht durchsetzt, weil Monopole sind Scheiße.

Ah und was ist PDF?

Krux

PDF ist sicher lange kein Adobe Monopol mehr, man braucht schon lange kein Adobe programm mehr, um PDF nutzen zu können, weder zum erstellen, noch zum lesen.

Was ich meine ist, Microsoft versuch doch seinen eigenen Blitzkrieg durchzuführen. Alles was schon auf dem Markt ist, und sich grade durchsetzt, davon klaut Microsoft die Idee, setzt den eigenen Namen drunter, und Punmt da unmengen an Kapital rein, damit es das Original vom markt schwemmt. Anstatt mit Adobe sich an einen Tisch zu setzen, um gemeinsam das PDF format zu verbessern, wird XPS herausgebracht. Nicht dass microsoft sich mit an die Java IDE hängt, um die zu verbessern, nein Microsoft will sie überrollen. Stellt euch mal vor, ihr wollt ein unternehmen gründen, und habt eine Idee, diese Wird umgesetzt, ist erfolgreich, und ihr expandiert. Dann bekommt Microsoft wind von dieser Idee, und kauft sie nicht auf, so wie das alle Unternehmen tun würden, nein sie bauen es nach, es wird mehr Geld reingesteckt, als man das selber je könnte, und auf dem Markt gebracht. Dann wird noch mal Groß die werbetrommel gerührt, und als die neue Große Microsoft Idee Verkauft, technisch perfekt umgesetzt. Alle anfangsschwierigkeiten, die das eigene Projekt noch hat, und grade ausgebügelt werden, sind Perfekt gelöst. Das ist es was mich eigentlich an .NET aufregt, technisch ist es sehr Gut umgesetzt, man kann kaum meckern, ausser, dass Microsoft wenig daran liegt, das ganze auch auf Plattformen laufbar zu machen, die nicht von Mircrosoft sind.

DEvent

Konrad Rudolph schrieb:

Ich kann nur hoffen, dass sich das nicht durchsetzt, weil Monopole sind Scheiße.

Ah und was ist PDF?

PDF ist seit 1. Juli 2008 offener Standard. Ausserdem stellte Adobe die Spezifikationen schon lange vorher zum kostelosen Download bereit.