Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Kommt drauf an, welche Laufzueumgebungen und Bibliotheken Du benutzt.
Willst Du z.B. 32 bit JAVA Programme unter einem 64 bit OS entwickeln, brauchst Du ein 32 bit JAVA SDK für den Compiler, die IDE ist wiederum egal...
Wir schreiben hier z.B. mit RAD (kommerzielle Eclipse Variante von IBM) 32 bit JEE Anwendungen unter Windows7 64 bit, die auf einem WAS unter AIX 64 bit mit 32 bit JRE zum Einsatz kommen...
7 oder 8? Sollte egal sein, kannst unnötigen Kram in Win8 deaktivieren, hast am Ende dann praktisch win7. Musst halt schauen ob es sich lohnt ein Paar Euro zu sparen (Systembuilder/OEM).
Das stimmt schon. Allerdings ist es bei den meisten Anwendungen ja egal ob du jetzt Zahlen bis 2³²-1 oder 2⁶⁴ -1 in einem int speichern kannst. Wenn du hohe Zahlen benötigst, dann verwendet man eh eine Bibliothek wie libgmp. Wenn du z.B. ein Protokoll entwickelst, bei dem die Felder gewisse Breiten haben, dann verwendet man z.B. uint32_t o.Ä. aus stdint.h. Bei denen ist nämlich garantiert, dass sie unabhängig von der Betriebssystemarchitektur immer 32 Bit breit sind.
Meiner Meinung nach würde ich unbedingt x64-kompatibel programmieren. Unter Windows scheint das ja glaube ich fast noch niemand zu machen. Unter Linux ist es eher die Ausnahme, dass Programme nur für i686 kompilierbar sind.
Welche Java-Version die du zum entwickeln nimmst, ist völlig irrelevant. Der Bytecode macht keinen Unterschied zwischen 64Bit und 32Bit, denn Java hat fixed size integers. Ein Int ist immer 32 Bit, ein Long immer 64Bit. Und beides läuft auch auf 32Bit und 64Bit Systemen.
Für Java ist das mal wirklich irrelevant.
stwe schrieb:
Meiner Meinung nach würde ich unbedingt x64-kompatibel programmieren.
Ich würde da eher empfehlen immer die intX_t Integertypen zu nehmen, denn dann ist es egal ob das Programm bzw. die Library auf einem 8 Bit Mikrocontroller oder auf einer 64 Bit CPU läuft. Der Code lässt sich für alle Systeme kompilieren und verhält sich auf allen gleich (mal von Compilerbugs abgesehen).
Und wer wirklich ein Performancejunkie ist und keine Overflows und ähnliches mit den Zahlen erzeugt, kann auch int_fastX_t verwenden, aber da muss man dann wirklich wieder extrem vorsichtig sein, dass die Fälle wirklich nie auftreten.
Welche Java-Version die du zum entwickeln nimmst, ist völlig irrelevant. Der Bytecode macht keinen Unterschied zwischen 64Bit und 32Bit, denn Java hat fixed size integers. Ein Int ist immer 32 Bit, ein Long immer 64Bit. Und beides läuft auch auf 32Bit und 64Bit Systemen.
Stimmt genau. Da ist nur die heap-size größer, mehr nicht.
Sobald aber native Bibliotheken ins Spiel kommen, sieht die Sache etwas anders aus - dort muss das JDK die richtige Version haben (sonst gibt es sowas wie einen UnsatisfiedLinkError beim Kompilieren) und die ausführende JVM später auch. Prominentes Beispiel ist Eclipse selbst mit dem nativen SWT und Co.
Mit Windows 8 hast du natürlich den Vorteil Software zu erstellen welche auch auf dem neuesten os von ms läuft. Mit neuen patches kommt dann ja wie ich gehört haben soll auch der Startknopf wieder. die Oberfläche ist wirklich etwas "gewöhnungsbedürftig", ms hat sich keinen gefallen getan das nicht einstellen zu können.
Na wenn du sie nicht testen kannst, bringt es dir auch nichts, diese dort zu entwickeln
Denn Metro-Anwendungen laufen eben nicht auf Win7, weil Win7 kein Metro hat.
Na und? Glaubst du, Softwareentwickler, die für Metro entwickeln wollen, geben erstmal Xtausend Euro aus, um die ganze Firma auf Windows 8 umzustellen?
Um die Software testen zu können, gibt es günstigere Möglichkeiten. Und auch ein Privatmann ist natürlich nicht gezwungen, teuer Geld für ein neues OS auszugeben.
Welche Möglichkeiten denn?
Und man muss ja nicht die ganze Firma auf Win 8 umstellen, es reichen die Entwickler. Aber ja, wenn ich für eine Plattform entwickel, dann muss ich auch dieser testen können! Nix mit emuliert durch irgendwas.
