Brauche Version-Info zum Visual Studio
-
Hallo, leuts
meine doofe Frage ist weil ich bisher mit dem Rad-Studio und auch mit dem Borland Cbuilder 6.0 meine C++ Projekte umgesetzt habe und ich gar keine anderen Compiler bisher benutzt hatte, nun einen Umstieg auf Visual Studio probieren möchte aus dem Grund weil mir das Rad-Studio einfach zu buggy ist.So die eigentliche Frage ist jetzt folgende - ich benötige die letzte Visual-Studio Version die mir es ermöglicht meine Projekte für Windows 2000 und Windows XP zu compilieren.
Hat da jemand ne Ahnung welche von den letzten Versionen von Visual Studio Version ich noch dafür benutzen kann ?
-
Für Win XP ist die letzte Version VS 2010 (bzw. mit einem SDK-Update auch VS 2012), für Windows 2000 höchstens VS 2008, s.a. Visual Studio: Version 2010 (sowie die Infos zu 2008 und 2012).
Ich habe jedoch auch noch folgende Artikel gefunden (ich hoffe, du verstehst englisch?):
Ist deine Anwendung denn eine reine Konsolenanwendung oder aber eine GUI-Anwendung, d.h. hast du die VCL benutzt? Diese kannst du dann nicht mehr benutzen und müßtest ein anderes GUI-Framework einsetzen (z.B. MFC oder noch besser gleich Qt, ImGui oder wxWidgets - aber auch mit denen müßtest du wohl auf ältere Versionen zurückgreifen).
-
@Th69 alles GUI Anwendungen - ich zieh mir mal bei Gelegenheit VS 2010 rein. Kanm man als Test-Version irgendwo herbekommen ? Kenn mich mit VS-Studio überhaupt nicht aus.
-
Offiziell wohl nur noch VS 2013: Visual Studio: Older Downloads, aber such mal nach "VS 2010 download" im Internet.
Was ist denn der Grund, warum du noch diese alten Windows-Versionen unterstützen möchtest?
Außerdem: Wenn dein bisheriger Code nicht strikt nach reinem C++ Standard-Code und UI-Code (VCL) unterteilt ist, dann wirst du wohl den meisten Code neu schreiben bzw. komplett überarbeiten müssen (andere Header sowie Entfernen aller auf Delphi beruhenden Funktionalitäten).
-
ja hab schon gesehen offiziell bei MS nur 2013
naja der Grund ist, das ich nen Kumpel habe der benutzt ein Windows 2000 und für den compiliere ich ein kleines Tool für sein W2K 32bit mit Rad-Studio 10.4. Er benutzt ein modifiziertes W2K, ein Japaner ist da fleißig dabei es zu modifizieren, was ich aber sagen kann ist, das die Prozedureinstiegs-Punkte sind auf jedenfall so wie bei XP-Integral in den DLLs. Deshalb reicht auch ein VS welches für XP compilieren kann, ich kann es nur nicht testen, weil ich selber solch ein W2K nicht habe, dafür aber XP was aber er wieder nicht hat.Deshalb der Umstieg
Da das Rad-Studio nun aber rumzickt bei bestimmten Aktionen was das FileSystem betrifft egal welche Version auch die 11.3 - kommt es vor das mir meine Projekt-Exe im RAD einfach abschmiert. Ich weiß es nicht ob es an der VHD liegt in die ich boote oder am Radstudio selber. Bei Shellexecute schmiert er einfach ab bei bestimmten Pfaden aber auch bei SHGetFileInfo um Icones aus Dateien zu holen bleibt er einfach hängen das Programm hält einfach an. Ändere ich nur den Laufwerksbuchstaben im Pfad von e:\ zum Beispiel nach a:\ läuft es. Das ganze Problem existiert aber nur direkt im Compiler - nicht außerhalb beim Start der Projekt-Exe. Und das Problem ist nun das ich nie weiß warum das Programm nicht läuft wenn ich es im Radstudio compiliere und dann mit F9 starte. Hab alles probiert auch neues Projekt Pfad als UnicodeString definiert und dann mit Shellexecute gestartet, zag die Projekt-exe schmiert einfach ab, nur 2 Zeilen Code und das Programm verabschiedet sich. So etwas kann ich nicht gebrauchen, deshalb wollte ich umsteigen oder zumindest erstmal probieren wie sich programmieren im VS anfühlt.Update zu RadStudio ab Version 11:
Ab Rad Studio 11 kann man über die Projekt-Einstellungen, Programme auch auf älteren Systemen lauffähig machen, es reicht also eine Version für alles.
Projekt->Optionen->C++-Linker->Ausgabe
Für XP dort dann einstellen: BS-Version: 5.1 , Untersystem-Version: 5.1
Getestet auf XP-Integral gab bisher noch keine Probleme.
-
Hast du Leerzeichen oder andere Sonderzeichen in deinen Projektpfaden?
-
@Th69 nee ist alles standard habe an den Pfaden nix geändert bzw. der Test ProjektOrdner ist ohne Leerzeichen oder Sonderzeichen. Aber im Moment lässt sich per Shellexecute gar nix mehr starten.
Ich mache mal die VHD neu und teste das ganze dann nochmal muss erst noch Daten sichern, irgendwas stimmt hier nicht aber so richtig nicht.
-
so scheinen alle Probleme verschwunden zu sein, nachdem die VHD wieder neu ist, mir ein Rätsel was da sich im laufe der Zeit eingeschlichen hat, als zum Schluss nix mehr ging also heute war das schon sehr merkwürdig.
Das war mein Testcode also nix aufregendes aber es führte ständig zum Absturz und gestartet wurde nix, zumindest nicht so lange es im Compiler gestartet wurde.
const _TCHAR *p=_T("E:\\progs\\TEST\\T-Ultimate.exe"); ShellExecute(GetDesktopWindow(), _T("open"), p,NULL,NULL, SW_SHOW); UnicodeString S="E:\\progs\\TEST\\T-Ultimate.exe"; ShellExecuteW(GetDesktopWindow(), L"open", S.c_str(),NULL,NULL, SW_SHOW);
und der Fehler das das Programm bei SHGetFileInfo mit bestimmten Pfaden angehalten hat ist auch verschwunden,
was aber alles noch viel komischer ist das ich über 2 VHDs mit RAD 11.3 und 10.4 die gleichen Fehler hatte, und die 10.4 noch die alte VHD ist. Das sind Dinge die ich mir nicht erären kann, außer das es tatsächlich sein kann das ich desöfteren Pfade mit Leerzeichen im Projektverzeichniss drin hatte.Naja und das VS 2010 habe ich auch gestetet in einem anderem System ist dann doch so nicht ganz mein Ding.
EDIT: der Fehler oder was auch immer das ist mit Shellexecute wirkt sich leider wieder aus, diesmal schmiert es nicht ab im Compiler dafür freezt es, packe ich das zu startende Programm mit selben Pfad woanders hin von C:\Program Files\Test\Test.exe nach a:\Program Files\Test\Test.exe läuft es ohne Probleme. Starte ich meine Project.exe außerhalb des Compilers läuft es normal und startet per Button die Test.exe egal wo es liegt, ich vermute das es an der VHD liegt das müsste ich dann eben ohne VHD mal testen.
-
So, ich bin dem Problem auf die schliche gekommen, es ist ja so das man keine wirkliche Ruhe findet egal was man macht, das Gehirn rattert den ganzen Tag lang und unterbewusst sucht man ständig nach der Problemursache, und dann fällt es einem auf einmal ein an was es liegen könnte. Und ja genau so war es dann auch.
Die Probleme mit dem Shellexecute blieben weiterhin bestehen, ich behaupte auch das es SHGetFileInfo in ähnlicher Weise betrifft.
Mit dem Shellexecute Befehl starte ich unter anderem meine eigenen kompilierten Programme die ich so in laufe meines Lebens geschrieben habe über eine kleine ToolBox so nenn ich mal mein letztes größeres Projekt an dem ich immer wieder mal arbeite.
Alle meine Programme packe ich mit dem "UPX 3.91w" und genau diese Programme verursachen dann beim Start über Shellexecute den Absturz des Projektes im Compiler. Außerhalb vom Compiler passiert das nicht und alles läuft scheinbar normal.
Also vermeide ich ab jetzt einfach nur "UPX 3.91w" gepackte Programme als Test-Objekte wenn ich mit RadStudio arbeite.
EDIT: Über RamDisk Laufwerke treten diese Probleme über den Compiler nicht auf,
HDs und SSD Laufwerke führen über den Compiler zur Freeze oder Absturz mit "UPX 3.91w" gepackten Programmen die per Shellexecute gestartet werden. Auch das Packen mit UPX 4.1.0 ändert nichts an dem bestehenden Problem.