Prüfsummen bei MS Installation



  • @biter
    Du redest wirr und schüttest alle Probleme in einen Topf.



  • Weil mir VS2019 Community oben von Schlangenmensch empfohlen wurde, und ich VS2019 und WLAN nur auf einem PC installiert habe ! Dann lassen wir das eben. Trotzdem Danke !



  • @Schlangenmensch sagte in Prüfsummen bei MS Installation:

    Probier es. Wenn sich eine Datei nicht schreiben lässt, wirst du es merken... aber Prüfsummen werden da beim Setup nicht überprüft. Warum auch, gerade wenn es von der CD kommt.

    Die meisten Installer verwenden komprimierte Dateien, auch wenn von CD installiert wird. Und beim Entpacken wird üblicherweise schon eine Prüfsumme geprüft. Ich hab auch schon manchmal eine dementsprechende Fehlermeldung von einem Installer bekommen dass die Setup Files hin sind. Ist lange her, aber doch, sowas gibt es durchaus. Und mich würde es wundern wenn diese Checks seit damals entfernt wurden. Ich würde sogar schätzen dass es mehr oder weniger standard ist.

    @DocShoe

    Wenn die CD zu alt und damit kaputt ist wird sie Lesefehler erzeugen.

    Bei aktuellen CD Laufwerken kann man wohl davon ausgehen dass diese die Yellowbook Fehlerkorrektur und -erkennung korrekt umsetzen. Ich hab aber auch schon Fälle gehabt wo ich - ohne Fehlermeldung - kaputte Daten von einer CD-ROM gelesen habe. Ist aber auch schon sehr sehr lange her. Damals gab es noch durchaus schrottige CD-ROM Laufwerke wo nicht nur bei der Mechanik gespart wurde - sondern auch bei der Elektronik/Firmware.



  • @hustbaer sagte in Prüfsummen bei MS Installation:

    Die meisten Installer verwenden komprimierte Dateien, auch wenn von CD installiert wird. Und beim Entpacken wird üblicherweise schon eine Prüfsumme geprüft.

    Grade mal bei Inno Setup (https://jrsoftware.org/ishelp/index.php?topic=filessection) nachgeguckt, Prüfsummern zu verifizieren ist zumindest da als default voreingestellt. Ich nehme also alles zurück und behaupte das Gegenteil.

    @biter sagte in Prüfsummen bei MS Installation:

    Und die Migration von VS2008 nach VS2019 schlug bei mir fehl. "Diese Projekte ( bei mir C++ MFC von VS2008 ) werden nicht unterstützt". Dann könnte es sein das eine Neuanmeldung von VS2019 nicht möglich ist, weil mein Konto gesperrt ist. Dann kann ich neue Projekte unter VS2019 nicht mehr auf den anderen PC's weiterentwickeln, weil es keine Abwärtskompatibilität gibt. Ich stelle keine grossen Ansprüche an eine IDE.

    Naja, ich hätte zumindest gerne einen aktuellen Compiler. Mir wäre es Wert, die Probleme zu beheben um halbwegs modernes C++ schreiben zu können.



  • Es ist die Frage, ob es einen grossen Aufwand macht, wenn ich mein C++ MFC von VS2008 nach VS2019 migriere. Bei einer jungfräulichen Test-Anlage von C++ MFC mit VS2019, habe ich gesehen dass die InitInstance Funktion, total anders aussieht wie bei VS2008. Vermutlich wäre das viel zu viel Arbeit. Dann habe ich auch gesehen, dass bei neueren Compilern oft nur kosmetische Dinge neu sind. Ob da eine switch-Anweisung sich kürzer schreiben lässt, ist mir selber eigentlich egal. Gut wenn alte Probleme behoben wurden sage ich nichts.



  • @biter Ich würde auf C++11 Features, wie u.a. Lambdas, auto, unqiue und shared pointer nicht verzichten wollen.



  • Die Features sind alle ganz toll, aber weil es keine Abwärtskompatibilität gibt, kommen sie für mich aus oben genannten Gründen nicht in Frage. 4 PC's auf vieren VS2008/2010 auf einem VS2019 und WLAN. Fällt 2019 aus, und dann ? Ich bin kein richtiger Informatiker, habe aus dem Grund kein Stimmrecht, gebe mich auch gern mit alten Dingen ab, aber VS2019 habe ich auch.



  • Hauptgrund für einen Umstieg wäre für mich in erster Linie erst einmal C++98 Konformität. Der VS 6.0 C++ Compiler ist berüchtigt für seine Eigenheiten.



  • Also, ich sehe schon, keine Chance für 6.0, ihr seid hier die besseren Spezialisten. Was ist mit VS2008/2010, wie siehts damit aus ? Neben C++ arbeite ich mit C# .NET. Da habe ich keine Migrations-Probleme, eine ganz tolle Sprache. 6.0 hätte eben keinen managed Code ....



  • Was ist mit VS2008/2010, wie siehts damit aus ?

    Wie sieht was damit aus?



  • Läuft der Compiler bei C++ MFC da korrekt, oder gibt es dort auch Eigenheiten wie bei VC++ 6.0 ? Gibt es bei VS 2019 auch nicht-managed Code ? C ?



  • Ich weiß nicht was Du für Vorstellungen vom programmieren hasst? Aber ganz ohne Einarbeiten und neues Hinzulernen wirst wahrscheinlich nicht auskommen. Du kannst Dir natürlich Deine eigene Blase schaffen, darin die Zeit zurückdrehen und auf irgendwas Windows 95 und VS 6.0 installieren (VM zum beispiel) ... und glücklich sein, allein. 🙂

    Aber nicht nur die compiler haben sich gändert, auch die Systeme, und gar die Menschen ..... sondern auch die Programmierer selber 🙂
    Ich würd VS 6.0 nicht mehr mit der Kneifzange anfassen wollen .... Ich fühl mich heutzutage schon gequält weil ich VS 2008 kompatibel sein muss, und InitInstance, CoInitializeEX und DECALRE_MESSAGE_MAP vermisse ich kein bisserl 🙂

    Mein Tipp, egal wer dich versucht grad wieder in die C++ Welt zu locken ...., sag Ihm das sich die Welt weiter gedreht hat, und das sein Code aus den 90ern Sch.... ist und recycelt ... err refactored gehört 🙂 Wenn dann bereit bist, was neues zu lernen und aufzusetzen, meide MFC, meide es, Projecte in Visual Studo zu maintainen, Solution/Projekt files gehören generiert ...



  • Deine Einwände verstehe ich, nur muss man halt manchmal alte Projekte pflegen, mit MFC usw. Und mein altes C++ MFC VS2008 Projekt konnte ich nicht auf VS2019 migrieren. Dass man VC++ 6.0 meidet ist mir schon klar. Sonst arbeite ich mit C# .NET, ganz tolle Sprache. Was hat denn der VC++ 6.0 Compiler für Eigenheiten ? Lange Zeit musste man den doch verwenden. Und 6 Service-Packs ...



  • Was ich vermissen würde, wenn ich ein old style Visual Studio 6.0 MFC Project pflegen müsste:

    • Fehlermeldungen, grad in Verbindung mit makros, waren sehr irreführend
    • Makros debuggen -> Aua, heutzutage benutzt man viel weniger makros
    • kein auto (in templates eine qual)
    • mangelnde Template unterstützung
    • keine Lambdas
    • krude Initialisierung
    • keine Build-Generatoren, jedes Detail vom Projekt in der gräßlichen Visual Studio Oberfläche zusammenzuklicken, über zig Seiten verteilt mit irreführenden Namen und übersetzungen (ok, ich hatte die deutsche version)
    • MFC ist ein Bullshit an Framework hatt mehr mit C als mit C++ zu tun. Kapselung und Abstraktion waren sehr sehr gering (gegenüber der winapi)
    • COM und DCOM eigentlich tolles konzept, sch... Schnittstellen (CComQIPtr .... )

    und Linux und Visual Studio + MFC waren/sind ne komplett verschiedene Welt ... Man musste quasi fast alles komplett 2mal machen, wenn irgendwas auf einer anderen Plattform machen will. Heutzutage programmiert man viel öfters gleich plattform neutral(er). Und die Computer haben mehr Leistung, mehr Raum für Komfort / Schnickschnack (ich hasse mittlerweilen das alte Windows/Visual Studio Farbschmema 🙂 Dark for the win ! )

    uvam.

    nur muss man halt manchmal alte Projekte pflegen

    Deine Post's klangen nicht so, das wer / was dich dazu unter Schmerzen treiben würde ... sondern es klang eher nach Gewohnheit.
    Aber ja, manchmal muss man auch (wieder) leiden, (hoffe du lässt es gut bezahlen)



  • So, jetzt beenden wir aber, es wurden alle Standpunkte ausführlich behandelt. Danke und Tschüss ...



  • @biter sagte in Prüfsummen bei MS Installation:

    Läuft der Compiler bei C++ MFC da korrekt

    Viel korrekter als bei VC6.

    oder gibt es dort auch Eigenheiten wie bei VC++ 6.0 ?

    Ja, bloss nicht ganz SO schlimm. Aber immer noch genug. Vor allem hast du bei VS 2008 quasi gar keinen Support für C++11 und bei VS 2010 nur sehr lückenhaften/fehlerhaften. Und C++11 ist schon sehr nett.

    Gibt es bei VS 2019 auch nicht-managed Code ? C ?

    Klar, gibt es beides. Es gibt sogar viel besseren C Support als in älteren VS Versionen - weil endlich mal C99 (fast) vollständig und korrekt unterstützt wird. Ein paar kleine Eigenheiten beim Präprozessor gibt es noch, aber das meiste funktioniert jetzt endlich wie es sollte.


    Was das Thema Login angeht: du kannt auch Visual Studio Code mit dem Visual Studio 2019 C++ Compiler verwenden. Der Compiler alleine verlangt kein Login - auch dann nicht wenn er als Teil einer Visual Studio 2019 Installation installiert wurde. Nachteil dabei ist halt dass du keine Wizards mehr hast und keine IDE um deine vcxproj/sln Files zu bearbeiten. Gibt aber alternative Build Systeme wie z.B. CMake. Deren Projektfiles sind etwas einfacher in einem Text-Editor zu bearbeiten als die von Visual Studio.

    Wobei: wenn du umsteigst, dann würde ich gleich Visual Studio 2022 empfehlen. Die Preview 1 funktioniert sehr gut/stabil, und wenn schon so einen grossen Versionssprung machen, dann gleich auf die neueste Version.



  • @RHBaum sagte in Prüfsummen bei MS Installation:

    COM und DCOM eigentlich tolles konzept, sch... Schnittstellen (CComQIPtr .... )

    Ich hab da immer _com_ptr verwendet. Ich meine das gab's sogar schon in VC6, ganz sicher ab spätestens VS 2005.



  • Ich habe bisher jedes MFC Projekt auf jede neue VS Version übernehmen können.

    @hustbaer ich benutze auch lieber CComPtr. Da bekomme ich HRESULTs und keine exceptions... mir ist hier die Kontrolle lieber.



  • @Martin-Richter
    Ja, Geschmackssache vermutlich. Ich mag die Exceptions, passt besser zum Rest des Error-Handlings in meinen Programmen. Und man kann man die ja auch fangen und dann fertig formatierte Message-Strings und/oder den HRESULT abfragen.

    Und wenn es mal ein erwarteter, "normaler" Fall sein sollte der mit _com_ptr zu einer Exception führen würde, dann kann man sich ja immer noch eine Hilfsfunktion schreiben die es "zu Fuss" macht und dann Fehler per Returncode kommuniziert.



  • @Martin-Richter exceptions... mir ist hier die Kontrolle lieber.

    haha ganz was neues 🙂 ^^


Log in to reply