Kleines Tool für Frontsidebusberechnung

phil99

Semiprofi
Thread Starter
Mitglied seit
05.11.2004
Beiträge
1.407
Hallo
Ich habe mal ein kleines Tool programmiert, was einem schnell
die verschiedenen Multiplikator und Frontsidebusmöglichkeiten
ausrechnet für einen bestimmten Takt.
Gerne würde ich das Tool noch erweitern, bitte um Vorschläge.
Übrigens, das Programm ist in Visual Studio erstellt und funktioniert
nur mit .net Framework.

Zusätzlich berechnet das Tool noch den Takt für den Speicher,
der standardmässig 1:1 getakte ist, kann aber auch auf 5:6 oder 4:6
eingestellt werden.
 

Anhänge

  • Frontsidebus.zip
    7,2 KB · Aufrufe: 120
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ach was, ich mache eine Ausbildung zum Anwendungsentwickler und programmiere halt gerne.
Da ich mich auch für Hardware interessiere test ich halt mal,
ausserdem habe ich gerade angefangen mit Visual Studio, da bietet
sich sowas halt an.
 
pack doch mal alle deine tool in eine brauchbare sammlung und mach dann nen neuen thread und nicht für 5 mins vs rumklicken nen neuen Thread aufmachen
 
kontne das ncih ma starten kam son speicherfehler. dahcte im ersten moment auch an nen trojaner oder virus. find ich doof lol aber ich hoffe doch du hattets keine bösen absichten udn bei den adnren läufts ;)
 
"brauchbar" naja ich weiß ja net....
bei mir funzen beide nicht
auch wenn sie funzen würden, würde ich sie nicht benutzen
 
phil99 schrieb:
Hallo
Ich habe mal ein kleines Tool programmiert, was einem schnell
die verschiedenen Multiplikator und Frontsidebusmöglichkeiten
ausrechnet für einen bestimmten Takt.
Gerne würde ich das Tool noch erweitern, bitte um Vorschläge.
Übrigens, das Programm ist in Visual Studio erstellt und funktioniert
nur mit .net Framework.

Zusätzlich berechnet das Tool noch den Takt für den Speicher,
der standardmässig 1:1 getakte ist, kann aber auch auf 5:6 oder 4:6
eingestellt werden.
Du benutzt den .NET Framework für einen Sch**ss? Ich will Dich ja jetzt nicht anmachen oder so, aber das ist das Gleiche wie mit einem 42-Tonner einkaufen zu fahren.

Man kann das Gleiche in 2 Minuten in ANSI-C programmieren.

Man man man.

'cuda
 
aber das .net framework macht es wesentlich einfacher ;)
 
Also das halte ich nun wirklich für'n Gerücht...... :fresse:

'cuda
 
ne wirklich, ich kann kein ansi c okay, aber bei den tools liegt nahezu keine logik drin, das ist wirklich nur zusammenklicken (wobei es mit einer guten IDE in c sicher ähnlich gut geht)...

ausserdem kannst das tool so wirklich sehr klein publizieren... brauchst halt die ganzen libs net
 
Mit Ansi c, ich habe mich gerade mal informiert, da gibt es keine grafische
Benutzeroberfläche.
Sicher wäre das ganze in C++ Ressourcenschonender zu programmieren.
Man könnte sich auch auf API-32-aufrufe beschränken.
Zumindest die Leute bei mir im Betrieb wollen mit sog "Steinzeitprogrammierung"
nichts zu tun haben.
OOP ist die Zukunft
Klar macht es vieleicht kein Sinn für ein derart kleines Programm MB-weise DLLs
mit zu liefern, aber wir befinden uns auch nicht mehr in der Zeit der C64, wo
jedes Bit genutzt werden musste.
 
Ähm, OOP != .NET Framework...

Klar macht es vieleicht kein Sinn für ein derart kleines Programm MB-weise DLLs
mit zu liefern, aber wir befinden uns auch nicht mehr in der Zeit der C64, wo
jedes Bit genutzt werden musste.

Jö, hardwarenahe Programmierung? Für was denn?

'cuda
 
Das .net framework ist wie der name schon sagt, ein framework... unmengen von fertigen klassen auf die zugegriffen werden kann. Nicht mehr und nicht weniger.

hardwarenahe programmierung macht sicher sinn, aber immer und überall? Hier def. nicht!
 
Ja, natürlich bei sowas vielleicht nicht, aber bei den grösseren Sachen.

Er sagt ja pauschal:
.. aber wir befinden uns auch nicht mehr in der Zeit der C64, wo
jedes Bit genutzt werden musste.

'cuda
 
[QUOTE='cuda]Ähm, OOP != .NET Framework...



Jö, hardwarenahe Programmierung? Für was denn?

'cuda[/QUOTE]


Hab gerade mal die letzten Beiträge von Dir betrachtet.
Du bist ja immer nur am dissen und am Besserwissen.
Hast wohl keine schöne Kindheit gehabt ?
 
Ich mache weder das Eine noch das Andere,
ich sagte bereits:

Ich will Dich ja jetzt nicht anmachen oder so,

Wenn Du normales C++ benutzt, mit eigenen Klassen, klappt es auch. Und vor allem, was für extra DLLs brauchst Du für ein Programm?

'cuda
 
Ich programmier aber kein C++, nur Java und C# und VB6,
klar in VB6 wärs noch einfacher gegangen.
Für heute reichts mir jedenfalls, hab gerade mal versucht Mouseevents abzufangen,
die sind in der Form standardmässig gar nicht implementiert, da muss man ziemlich
tief in die Materie.
Für heute reichts mir jedenfalls.
Game Over
 
FAKENEWS 2008

EPIC Veröffentlich UT2008 mit neuer Engine.

Lange haben die UT Fans drauf gewartet, nun hat Epic Offiziel UT2008 gelauncht. Die neue Engine, verspricht CEO CHef von Epic, sei eine Grafische Engine die in Sachen Grafik kein bisschen besser als die UT 2007 Version sei. Jedoch sei man nun Zukunftsorintiert vorgegangen verspricht CEO Chef.

Man habe die Engine 5 mal Performancehungriger geschaffen durch das Einsetzen von Framework 2.34, dass benötigt wird. Man sagte das man weiterhin 75% der Programmierer feuern konnte. "Die Engine haben sich regelrecht zusammenklicken lassen" so der CEO Chef.

Aus einen Kommentar von CEO Chef sagte man nun das man endlich nicht mehr Steinzeitorintiert Programmiere. "Wir verschwenden nun Leistung im Überschuss, sowas ist Zukunftsorintiert" wurde nun Versprochen. "Unsere UT2008 Engine ist die Leistungshungrigste Engine die zur Zeit auf dem Markt ist". Keine Grafikkarte, ausser die Gestern veröffentlichte NVidia Grafikkarte, kann das Spiel in vollen Details darstellen. "Somit haben auch Gamer etwas für die Zukunft" versprach CEO Chef.

Ob es eine Absprache zwischen Epic und NVidia gab dazu wollte der CEO Chef keine Stellungnahme abgeben.

Im Zuge darauf teilte CEO Chef eine schlechte Nachricht mit. Die neue UT2008 Engine sei nur noch Windows Jüngern vorbehalten. Die Linux Abteilung wurde volkommen geschlossen.

Aus einem Zitat war zu entnehmen das die Linuxprogrammierer die Engine nochmals komplett neu programmierten mussten, da das Framework nicht für Linux verfügbar ist. Bei den ersten Beta Versionen zum Linux Client von UT2008 stellte sich jedoch heraus, das die Engine 625% Performanter lief als die aktuelle UT2008 Engine auf Windows Basis. Und man immerhin 125% schneller sein konnte als die UT2007 Engine. Weiterhin sagte CEO Chef das der Code schon in der Betaphase sehr stabil war, und fast keine BUGs mehr im Code vorhanden waren.

Das hätte der Wirtschaft geschadet so CEO Chef. Den wenn die Leute keine Patches benötigen, so würden viele Leute nicht mehr Geld bezahlen für ihre Steam Accounts, womit sie sich die neusten Patches gegen Geld herunterladen konnten.

Weiterhin befürchtete man das deshalb viele Leute auf Linux wechseln würden zum Spielen. Der CEO Chef sagte das man immerhin über die Patches einen Gesamtumsatz von bereits 30% erzielte. "Man müsse die Kunden langzeitig bezahlen lassen, und nicht nur einmalig bei dem Kauf der Software, sowas rentiere sich nicht", so CEO Chef.

Deshalb wurden alle Linux Mitarbeiter fristlos entlassen. Ob dies zusammenhängt mit dem Vertrag mit Microsoft der vor 2 Monaten besiegelt wurde, und unter Verschluss gehalten wird, ist bisher ungewiss.


Weitere News zum Thema:

- Sounddateien in UT2008 sind DRM geschützt. Automatische Geld abbuchung pro abgespielter Feuerschuß über Steam Accounts.
- Neuer Epic Patch zu UT2008 um 50% billiger bei Vorbestellung + Jahresvertrag zu UT2009.





Weitere Wichtige News im Kurzüberblick:
- Raubkopierer entdeckt. Wurde zur Todesstrafe verurteilt.
- Linux Benutzer zu 10 Jahren haft verurteilt: Er bezahlte keine Lizensgebühren auf das Softwarepatent zum Mausklick von Microsoft.
- Musik Und Filmundustrie klagt über schlechte Einnahmen: Nur 200% mehr Gewinn als im Vorjahr. Man Suche nach weiteren Schuldigen.
- EU rat beschließt Projekt "Gläsernen Bürger" für Wirksam: Demnächst einfach automatische Kontoabbuchung bei Patentverletzung.


Unwichtige News im Kurzüberblick:
- Kinderporno im internet um 350% gestiegen zum Vorjahr.
- Kinderprono Händler zahlt 2000€ Bußgeld.
- Programmierer wurde zu 10 Jahren haft verurteilt: Er verstoße gegen das Softwarepatent der "for" Schleife.


blub...
Schöne neue Zukunft...


P.S.:
Ist mir so Gestern spontan eingefallen, hab dann aber mehr geschrieben als ich wollte.
 
Zuletzt bearbeitet:
phil99 schrieb:
Hab gerade mal die letzten Beiträge von Dir betrachtet.
Du bist ja immer nur am dissen und am Besserwissen.
Hast wohl keine schöne Kindheit gehabt ?

Du sollst keine lebende Gottheit blöd anmachen...solltest mal den Zu Linux Bekeht Thread lesen...ab Seite 9 ^^
 
Naja, nicht nur leistungshungrige Spiele werden programmiert, sondern vorallem
ganz simple Programme für grosse Unternehmen, wo es nicht auf Leistung ankommt.
Und auch so, Assembler ist am schnellsten, aber bei grossen Projekten nicht mehr finanzierbar
und vorallem kommt jedem anständigen OOP die Kotze hoch, wenn er so was noch
machen muss.
Selbst das noch in Assembler programmierte Bios wird demnächst abgelöst.
C++ wird noch eine Weile überleben, da es erstens schon 100 % objektorientierten Code erlaubt und es zweitens ressoursenschonend arbeitend.
Übrigens ist Java auch nix anderes, Java verbietet hardwarenahe Programmierung,
das erledigt der Interpreter.
 
Mittlerweile leben wir in einer digitalen Welt wo wir nicht mehr auf die reine Größe der Programme achten müssen, da genügend Speicher vorhanden ist. Mit deutlicher Zunahe der Komplexität verändert sich aber das gesamte Programmiergefüge. Es geht nicht mehr darum nah an der Hardware, schnell oder platzsparend zu programmieren sondern im wesentlichen gut lesbar und strukturiert, da Weiterentwicklung und Wartung einen höheren Stellenwert genießen.

Was bringen 20.000 Zeilen Assemblercode die evtl. rasend schnell laufen und nur einen Bruchteil des Platzes beanspruchen, wenn die Programmierer 3 Wochen zum entziffern des Codes benötigen um neue Features zu implementieren ?

Auch wenn OOP den Ruf der "Klicki-Bunti" Programmierung besitzt bedeutet es etwas ganz anderes. Programmierung "im Großen" besteht nämlich nicht mehr in der Programmierung von irgendwelchen Schleifen oder Abfragen, sondern im wesentlichen in der System-Modellierung. Die reine Programmierung nimmt vielleicht 20-30% der Zeit und des Budgets für ein Projekt ein, der Rest wird für Konzept, Design und Modellbildung verbraten um die Komplexität des Gesamtprojektes im Auge zu behalten und vernünftig damit arbeiten zu können.

Ob OOP eine geeignete Lösung für solche kleinen Tools ist mag ich anzweifeln aber wenn der Autor es für die einfachste Möglichkeit hält ist es seine Entscheidung. Solange es läuft, who cares ;)

Die Tatsache dass man es mit einer anderen Sprache, einer anderen Herangehensweise oder auf einem anderen Planeten anders hätte machen können bedeutet ja nicht dass die hier vorgestellte Lösung minderwertig ist.
 
Optimieren sollte man trotzdem ;)

Btw weiß jemand wie ich mit meinem CPU 2000 Mhz erreichen kann?FSB auf 82 Mhz,Multi auf 24,50 und RAM auch auf 82...Ob der RAM das mitmacht? ;)
 
Das kein Optimierter Code mehr zustande kommt, und das Hardwarenahe Programmierung schwachsinnig ist, weil wir ja genug Speicher haben ist volkommenner schwachsinn.

Linux, Unix sowie auch Windows werden in C Programmiert. Nichtmal C++. genauso sieht es mit dem Apache aus der noch in C Programmiert wird.

Alleine die Aussage das C++ noch ein bisschen überlebt ist schon lächerlich. Denkst du die ganzen Programmen werden einfach durch andere Programmiersprachen ersetzt?

Das gebrabbel von OOP ist auch schwachsinn. Sicherlich kann OOP helfen Sachen leichter zu verstehen. Aber es gibt auch Möglichkeiten in C eine OOP zu Simulieren, es geht auch ohne.

Das Übrigens nicht in Assemler Programmiert wird, und dafür eine Hochsprache wie C genommen wird, liegt einfach an der Kompatibilität. Wenn man in Assembler Programmiert, Programmiert man auf einen CPU zugeschnitten.

Das hat nichts mit schwer lesbar zu tun. Sondern einfach weil es heutzutage nciht angepasst ist, nurfür einen CPU Typ zu Rpogrammieren. Da wird lieber in C/C++ Programmiert, und der Code für die einzelnen CPUs übersetzt. Anstatt nochmals den kompletten Code zu ändern. Deswegen werden Hochsprachen benutzt.

Weiterhin kommt es immer noch darauf an das man möglichst effizent Programmiert. Komplexe Algorhytmen werden immer noch in Assembler geschrieben. Gerade bei der Spieleprogrammierung kommt es vor. Wo es auf jede Leistung ankommt.

Da ist es eben nicht so, dass man sagt ach wir haben ja genug Leistung, ruhig verschwenderisch Programmieren.

Das einzige wo sowas Funktioniert, sind solche kleine Tools wie hier. Oder denkst du etwa eine Datenbank wird so Programmiert das der Code lesbar ist? Klar wäre schön wenn es so wäre, ist es aber nicht. Dort geht es nur um leistung. Die einzelnen Hersteller Optimieren doch Ihre Datenbanken ohne Ende um jede Leistung herauszukitzeln.

Weiterhin sollte man den Horizont mal erweitern. Das mit dem viel Speicher trifft vielleicht noch auf einen PC zu, wie schaut es aber im Embedded Bereich aus? Denkst du auf einen Palm, PocketPC oder sonst wo kann man regelrechte mit Leistung um sich werfen? Da kommt es auf jede kleinste Optimierung an, und das man so wenig Speicher wie Möglich verbraucht.

Und der Embedded bereich geht auch etwas weiter hinaus als PocketPC und Palm. Überall wo ein Stück Software vorhanden ist. Denkst du für das Menü das dir dein Fernseher anzeigt wird Hauptsache Lesbar Programmiert? Und für die Menüanzeige benötigst du dann einen eingebauten 1Ghz Rechner, und min. 256MB Ram im TV, oder was?

Da kommt es drauf an so Hardwarenah wie nur Möglich zu Programmieren. Sei es nun im fahrstuhl oder sonst wo, wo Software benötigt wird. Das gilt auch für das Handy.

da es erstens schon 100 % objektorientierten Code erlaubt und es zweitens ressoursenschonend arbeitend.
Dazu möchte ich nur sagen. Die Ressourcen verwaltet der Programmierer, nicht die Programmiersprache. Wenn ich ein Programm schreibe das Ressourcendschonend Arbeitet muss ich Optimierten Code schreiben. Man kann aber in C++ auch ohne Probleme Code schreiben der Ressourcen ohne ende frißt.

Sowas tust du, indem du für Simple Programme z.B. das .NET Framework benutzt. ;)
 
Zuletzt bearbeitet:
Wenn ich das Programm mit VB6 geschrieben hätte, so müsste das Programm installiert werden und wäre mehrer MB gross, kein Scherz, selbst ein Hallo Welt Fenster war
bei mir mit Visual Studio6 3mb gross, wegen den ganzen Klassen.
Ausserdem kann es doch wirklich egal sein, wie ich ein Programm schreibe, in dem schon ein 30mhz CPU mehr als ausreichend ist.
Spezielle mathematische Algorythmen werden natürlich in Assembler geschrieben,
z.B. Primzahlenberechnungen, die oft jahrelang laufen, nur um die gleichen Berechnungnen durchzurühren.
Übrigens kosten Programmierer Geld und wer kann es sich leisten für jedes System eigene Programme zu entwerfen.
Siehe Java ist auch grottenlangsam, weil alles zur Laufzeit interpretiert wird und trotzdem die Zukunft.
C++ ist schon 100 % objektorientiert und für Spiele wahrscheinlich noch die nächsten
5 Jahre die Hauptprogrammiersprache.
Aber auch Spiele werden immer komplexer und teurer, auch hier werden längst Editoren eingesetzt für Leveldesign usw.
Auch Grafikkarten werden zunehmen auf OO und gut lesbaren Code umgestellt.
 
Am effizientesten wäre Visual C++ gewesen, dann wärs Proggy höchstens 100kb gross gewesen und als .exe auf jedem Win32 System lauffähig. Wobei es in Java auch edel gewesen wäre, die JRE hat man eher auf dem Rechner als das .net Framework.
 
Zuletzt bearbeitet:
Ist das .net Framework nicht standardmässig bei XP ?
Naja, ich weiss das Far Cry nach Neuinstallation des OS nicht mehr lief und einige dll gebraucht hat, die glaube ich auch vom .net Framework stammen.
Aber da inzwischen vieles in Visual Studio .net programmiert wird, sollte man es
schon haben.
In Java ist das so eine Sache, zumindest mit Eclipse ist die graphische Programmierung
aufwendig.
Wir haben das in der Schule mal gemacht mit SWT, da lernt man zwar einiges aber
man muss wirklich alles selbst machen.
Es gibt nicht die vorgefertigten Steuerelemente wie in Visual Studio.net.
 
phil99 schrieb:
Ist das .net Framework nicht standardmässig bei XP ?
Naja, ich weiss das Far Cry nach Neuinstallation des OS nicht mehr lief und einige dll gebraucht hat, die glaube ich auch vom .net Framework stammen.

nee, das .net muss man zusätzlich saugen und installieren, FarCry lief bei mir auch immer so :)

phil99 schrieb:
In Java ist das so eine Sache, zumindest mit Eclipse ist die graphische Programmierung
aufwendig. Wir haben das in der Schule mal gemacht mit SWT, da lernt man zwar einiges aber
man muss wirklich alles selbst machen. Es gibt nicht die vorgefertigten Steuerelemente wie in Visual Studio.net.

naja AWT ist mittlerweile deprecated, GUIs macht man heute meist mit Swing, geht eigt. recht komfortabel mit dem JBuilder, wie es mit Eclipse weiss ich net, aber Swing ist eigt. recht durchschaubar, auch ohne GUI Editor.
Klar so easy wie in Visual Studio is das in Java nicht, dafür finde ich Java aber als Sprache sehr elegant.
 
phil99 schrieb:
Ausserdem kann es doch wirklich egal sein, wie ich ein Programm schreibe, in dem schon ein 30mhz CPU mehr als ausreichend ist.
Und wenn das Programm auf ein 30Mhz CPU läuft, warum bekommst du es dann nicht hin, das es auf ein 30Mhz CPU läuft?

Übrigens kosten Programmierer Geld und wer kann es sich leisten für jedes System eigene Programme zu entwerfen.
Klar Kosten Programmierer Geld, und man kann es sich nicht leisten für jede Architektur komplett neuen Code zu schreiben. Deswegen werden auch Hochsprachen wie C oder C++ z.B. benutzt. Damit hast du auch die Möglichkeit Cross zu Compilieren. Bei VLC wird das z.B. gemacht. Die Windows Version wird unter Linux für Windows Compiliert.

Siehe Java ist auch grottenlangsam, weil alles zur Laufzeit interpretiert wird und trotzdem die Zukunft.
Ich frage mich ehrlich wo du deine Infos beziehst. Ich weiß nicht woher ich annehmen sollte das Java die Zukunft ist. Das einzige wo man Java gebrauchen kann ist in Routern oder in Switchen wo du ein Applet starten kannst zum Konfigurieren. Für was anderes finde ich Java komplett unbrauchbar. Und eo findet im normalen gebrauch Hauptsächlich Java Anwendungen statt? Man kann auch ohne Java zu Installieren sorglos durch diese Welt.

C++ ist schon 100 % objektorientiert und für Spiele wahrscheinlich noch die nächsten
5 Jahre die Hauptprogrammiersprache.
Auch da frage ich mich woher du deine Infos hast. ;) Wie kommst du überhaupt darauf das C/C++ eine aussterbende Sprache ist, und allerhöchstens noch in den nächsten 5 Jahren eine Verwendung für Computerspiele hat?

Wie ich schon sagte gibt es genug wichtige Projekte. Linux/Unix/Windows/Apache und noch zig andere Sachen die mittels C/C++ Programmiert wurden. Denkst du ehrlich das innerhlab der nächsten 5 Jahren einfach so mal eben die Programmiersprache gewechselt wird, womit das OS Programmiert wurde? Sowie alle Anwendungen auch die darauf Basieren? Die meisten Applikationen die du findest sind mit C/C++ Programmiert wurden.

Aber auch Spiele werden immer komplexer und teurer, auch hier werden längst Editoren eingesetzt für Leveldesign usw.
Ein Leveleditor hat wenig mit der Engine zu tun. Mit einem Leveleditor entwerfe ich MAPs, Karten für das Spiel. Das Spiel selber, ist so gut wie immer in C++ geschrieben. Mit dem Leveleditor entwickelst du keine Spiele, und damit schreibst du auch keine Engine. Von daher Frage ich mich was Leveleditoren etc. mit einer Programmierung zu tun haben?

Und für das Entwickeln von Sound werden Soundprogramme benutzt. Und? Was hat das jetzt mit der Programmierung oder mit irgendeiner OOP zu tun?

Weiterhin frage ich mich warum Hersteller überhaupt die Programmiersprache wechseln sollten? Bis vor kurzem war es sogar noch so gewesen das es das DirectX sogar ausschließlich für C++ gab. Weiterhin sind auch alle möglichen Tools auf C++ ausgelegt.

Eine Firma die bisher immer mit C++ Ihre Spiele Programmiert hat, und OOP so betreiben wie du es für richtig hälst, warum sollten die jemals eine andere Sprache wählen?

Die haben doch schon Klassen, Funktionen und Engines geschrieben und alles in C++. Warum diese nicht mehr benutzen und eine andere Sprache einsetzen? Welche Vorteile sollte es bringen?


Auch Grafikkarten werden zunehmen auf OO und gut lesbaren Code umgestellt.
Definiere mal wie Grafikkarten auf OOP umgestellt werden? Was soll den da genau pasieren?

Und für gut lesbaren Code muss man auch keine Programmiersprache wechseln. Bezweifle aber das irgendeine Firma die wege macht und vom Optimieren weg geht, und besser lesbaren Code schreibt.

Das einzige was zählt ist Leistung. Nicht umsonst siehst du NVidia und ATI bei Ihren Treiber am Betrügen ohne Ende. Denkst du etwa die haben die Meinung von Heute auf Morgen geändert, und sagen "nö, scheiß was auf schnelligkeit, wir schreiben Code der für uns besser leßbar ist."?

Ich frage mich wirklich woher du solche Informationen hast.


---


Naja, ich weiss das Far Cry nach Neuinstallation des OS nicht mehr lief und einige dll gebraucht
Bei mir ging Far Cry auch ohne .NET Framework. gab es das .NET Framework überhaupt schon zum Herunterladen, als Far Cry überhaupt rausgekommen ist?

Aber da inzwischen vieles in Visual Studio .net programmiert wird, sollte man es
schon haben.
z.B.?
Kenne bisher keine so vielen Programme die das .NET Framework benötigen.

Auser so kleine Tools wie hier, von Programmiereinsteiger. Ansonsten benötigt noch MCE 2004/5 das .NET Framework. Mehr kenne ich nicht.


Klar so easy wie in Visual Studio is das in Java nicht, dafür finde ich Java aber als Sprache sehr elegant.
Naja Meine Persönliche Meinung dazu:

Auser etwas anderes als Java Viren über den Browser einzuschleißen habe ich Java noch nie in mein Leben benötigt. Deswegen ist bei mir auch Java Standartmäßig deaktiviert. Java wartet wohl immer noch auf seine große Chance überhaupt mal benutzt zu werden.
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh