Anpassung von VC++6 Quelltexten in VC++2010-taugliche



  • Hallo,

    vermutlich gehört meine Frage in irgendeinen anderen Thread. Aber da es einerseits in diesem Forum keinen Anfängerbereich zu geben scheint und andererseits die Frage eindeutig in den Bereich WinAPI gehört, riskiere ich es einfach. Falls ich damit die Etikette verletzt haben sollte, bitte ich – im voraus dankend – um einen nachsichtigen Verweis an die richtige Stelle.

    Ich habe kürzlich zwei Einführungen – Dirk Louis "C++" und Jesse Libertys "Jetzt lerne ich C++" bis Kapitel 15 – durchgeackert und hatte so langsam das Gefühl, daß man sich jetzt auch so langsam dem Thema Windows-Programmierung zuwenden könnte. Wer lernt schon C++, um ständig nur Konsolenprogramme zu schreiben?

    Also habe ich mir zwei verschiedene Entwicklungsumgebungen – Visual C++ 2010 Express und Embarcaderos C++Builder XE4 – installiert, mir das Buch "Windows Programmierung" von Charles Petzold (5. Auflage) gekauft, und dachte, jetzt könnte es losgehen. Aber da war ich wohl etwas naiv.

    Als erstes habe in Visual C++ 2010 Express ein neues Win32-Projekt mit dem Namen "HelloMsg" erstellt und aus Petzolds Buch den Quelltext für das "allererste Windows" (S. 15) in das Quelltextfenster kopiert

    /*--------------------------------------------------------------
       HelloMsg.c -- Displays "Hello, Windows 98!" in a message box
                     (c) Charles Petzold, 1998
      --------------------------------------------------------------*/
    #include <windows.h>
    
    int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
                        PSTR szCmdLine, int iCmdShow)
    {
         MessageBox (NULL, TEXT ("Hello, Windows 98!"), TEXT ("HelloMsg"), 0) ;
         return 0 ;
    }
    

    und daraufhin auf auf Debuggen (bzw. F5) geklickt. Es erschien ein Fenster:

    "Dieses Projekt ist veraltet."
    HelloMsg - Debug Win32
    Erstellen?

    Ich klicke auf "Ja".

    Daraufhin erschien unter dem Quelltextbereich ein neuer Fensterteil "Ausgabe", der zuerst irgendetwas Undefinierbares verarbeitete und anschließend eine weitere Fehlermeldung ausgab:

    1>------ Erstellen gestartet: Projekt: HelloMsg, Konfiguration: Debug Win32 ------
    1> HelloMsg.cpp
    1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(147,5): error MSB6006: "CL.exe" wurde mit dem Code 2 beendet.
    1>d:\programmierung\c-programme\visual studio 2010 projekte\hellomsg\hellomsg\hellomsg.cpp(13): fatal error C1010: Unerwartetes Dateiende während der Suche nach dem vorkompilierten Header. Haben Sie möglicherweise vergessen, im Quellcode "#include "StdAfx.h"" einzufügen?
    ========== Erstellen: 0 erfolgreich, Fehler bei 1, 0 aktuell, 0 übersprungen ==========

    Was für ein #include "StdAfx.h"? Davon steht bei Petzold nichts. Und wieso #include "StdAfx.h" und nicht #include <StdAfx.h>?

    Gut, denke ich mir, fügst du noch die monierte Header-Datei ein, setze #include "StdAfx.h" unter die erste #include-Zeige und debugge wieder. Dasselbe Ergebnis – "Dieses Projekt ist veraltet." usw.

    Kann mir jemand erklären, was sich so weltbewegendes zwischen Visual C++ 6 (der von Petzold benutzten Programmversion) und Visual C++ 2010 getan hat, daß selbst derart simple Quelltexte nicht funktionieren?
    Beim C++Builder XE4 war es noch krasser. Dort scheint es überhaupt nicht mehr möglich zu sein, Win32-Projekte anzulegen, denn die einzigen angebotenen Projektvorlagen sind: "Anwendung für die Systemsteuerung", "Konsolenanwendung", "Package", "Dynamische Link-Bibliothek", "Service-Anwendung", "Statische Bibliothek", "VCL-Anwendung für Metropolis-UI" und "VCL-Formularanwendung". Außer "Konsolenanwendung" für mich alles böhmische Dörfer.

    Übrigens wird der obige Quelltext von Petzold auch in dem hier im Forum empfohlenen "Forger Win32 API Programming Tutorial" (http://www.winprog.org/tutorial/) 1:1 so angeboten, ohne daß die Seite den Eindruck macht, hoffnungslos veraltet zu sein ("Copyright © 1998-2013, Brook Miles ..."). Ich habe natürlich auch die FAQs durchstöbert und den hiesigen WinAPI-Thread nach "Message Box" u.a. naheliegenden Schlüsselwörter durchsucht, aber nichts Naheliegendes gefunden.

    Ich bitte höflich um Aufklärung, wie ich die Quelltexte aus Petzolds Buch abändern muß, um sie in Visual C++ 2010 oder im C++Builder nachvollziehen zu können. Oder, falls das hier den Rahmen sprengt, um Verweis auf einen Thread/eine Webseite, die über die notwendigen Anpassungen Auskunft gibt.

    Vielen Dank



  • Geh in die Projekteinstellungen, irgendwo gibt es die Option vorkompilierte Header zu deaktivieren, mach es und sei glücklich.



  • Hallo Nathan,

    falls Du mit "Projekteinstellungen … vorkompilierte Header zu deaktivieren"

    Menü Projekt | HelloMsg-Eigenschaften… | Konfigurationseigenschaften | C/C++ | Vorkompilierte Header | Vorkompilierte Header nicht verwenden

    gemeint haben solltest – das habe ich gemacht und es bringt gar nichts. Nach dem Debuggen kommt dieselbe Fehlermeldung

    "Dieses Projekt ist veraltet."
    HelloMsg - Debug Win32
    Erstellen?

    usw. Im übrigen ist das keine Antwort auf meine Frage, wie ich die Quelltexte aus Petzolds Buch abändern muß, um sie in Visual C++ 2010 oder im C++Builder nachvollziehen zu können.

    Trotzdem danke für Deine schnelle Antwort.



  • Konovaloff schrieb:

    Nach dem Debuggen kommt dieselbe Fehlermeldung

    "Dieses Projekt ist veraltet."
    HelloMsg - Debug Win32
    Erstellen?

    usw.

    Das, was du durch "usw." ersetzt hast, war der interessante Teil. "Dieses Projekt ist veraltet." ist keine Fehlermeldung, sondern nur der Hinweis, dass das erstellte Programm älter ist als die letzte Codeänderung.



  • Konovaloff schrieb:

    meine Frage, wie ich die Quelltexte aus Petzolds Buch abändern muß, um sie in Visual C++ 2010 oder im C++Builder nachvollziehen zu können.

    Gar nicht. Der Code ist schon in Ordnung. Du musst Visual Studio ordentlich einstellen. Wenn du uns die Fehlermeldung verrätst können wir dir bestimmt helfen.
    F5 bedeutet, dass du das Programm debuggen willst. Nun hast du aber den Code geändert und er fragt dich, ob du es neu kompilieren willst oder du die alte Version debuggen willst. Im Allgemeinen will man immer neu kompilieren und dann debuggen, dafür gibt es ein Häkchen neben dem "Ja/Nein", dass er immer neu kompilieren soll und dann kommt das Fenster nie wieder.
    Warum benutzt du nicht VS2013?



  • F5 bedeutet, dass du das Programm debuggen willst. Nun hast du aber den Code geändert …

    Ich bin zurückgekehrt zur unveränderten Version aus Petzolds Buch. Aber das "Projekt-veraltet-Fenster" taucht nach wie vor auf.

    … und er fragt dich, ob du es neu kompilieren willst oder du die alte Version debuggen willst.

    Ehrlich gesagt, ich weiß gar nicht, wonach mich VC++ fragt. Er sagt, "Dieses Projekt ist veraltet: HelloMsg - Debug Win32" und fragt: "Erstellen?" Erstellen – was? (Kann man hier im Forum eigentlich Screenshots posten?) Und das Prädikat "veraltet" (so verstehe ich es zumindest) bezieht sich doch nicht auf eine Projektversion -- sonst hätte es ja bei der allerersten Version diese Fehlermeldung nicht gegeben -- sondern auf Petzolds Quellkode.

    Im Allgemeinen will man immer neu kompilieren und dann debuggen, dafür gibt es ein Häkchen neben dem "Ja/Nein", dass er immer neu kompilieren soll und dann kommt das Fenster nie wieder.

    Ich weiß nicht, von welchem Häkchen Du sprichst. Mir ist in diesem Zusammenhang aufgefallen, daß es im Unterschied zu Louis' Buch (in dem VC++ 2010 verwendet wird und Bilder von der IDE enthalten sind) bei mir kein Menü "Erstellen" gibt. In meiner VC-Installation kommt nach dem Menü "Projekt" sofort das Menü "Debugger", weshalb ich auch auf "Debugging starten" gegangen bin. Es stellt sich also die Frage, wie man überhaupt den Compiler aus der IDE heraus startet. Einen entsprechenden Punkt habe ich auch in den anderen Menüs nicht gefunden.

    Das, was du durch "usw." ersetzt hast, war der interessante Teil. "Dieses Projekt ist veraltet." ist keine Fehlermeldung, sondern nur der Hinweis, dass das erstellte Programm älter ist als die letzte Codeänderung.

    Ich ging davon aus, daß die Fehlermeldung dieselbe ist, wie die von mir im Startbeitrag gepostete. Aber Du hast recht, die Fehlermeldung ist diesmal wirklich anders:

    1>------ Erstellen gestartet: Projekt: HelloMsg, Konfiguration: Debug Win32 ------
    1> HelloMsg.cpp
    1>LINK : fatal error LNK1123: Fehler bei der Konvertierung in COFF: Datei ist ungültig oder beschädigt.
    ========== Erstellen: 0 erfolgreich, Fehler bei 1, 0 aktuell, 0 übersprungen ==========

    > Warum benutzt du nicht VS2013?

    Ich habe ursprünglich sogar nach Visual C++ 6 gesucht, weil es die Version ist, die Petzold in seinem Buch benutzt, und ich diese ewigen Inkompatiblitäten schon zur Genüge kenne und sowas von leid bin. VC++ 6 habe ich im Netz aber auf die Schnelle nicht gefunden, so habe ich VC++ 2010 genommen, weil es die Version aus dem C++-Buch von Dirk Louis ist.

    Vielen Dank für Eure Hilfsbereitschaft



  • Konovaloff schrieb:

    1>LINK : fatal error LNK1123: Fehler bei der Konvertierung in COFF: Datei ist ungültig oder beschädigt.

    Service Pack 1 für VC++2010 installiert?



  • Hallo MFK,

    Service Pack 1 für VC++2010 installiert?

    Es war wohl schon installiert, weil das SP1-Exe-Paket mir nur zwei Optionen anbot: Deinstallation oder VC "auf ursprünglichen Status zurücksetzen". Ich habe letzteres angeklickt.

    Mal eine andere Frage. Ich habe zu Testzwecken mal Petzolds Quelltext durch den Embarcadero-Compiler gejagt, weil der bei den Konsolenquelltexten aus meinen Einführungsbüchern immer tadellos funktioniert hat. Das wäre, ehrlich gesagt, auch meine Lieblingsumgebung: Ganz auf die Visual-C++-IDE verzichten und nur mit UltraEdit und dem Compiler vom C++Builder XE4 arbeiten. Aber auch letzterer hatte etwas an Petzolds Quelltext auszusetzen:

    `D:\Programmierung\C-Programme>Embarcadero C++ 6.60 for Win64 Copyright (c) 2012-2013 Embarcadero Technologies, Inc.

    HelloMsg.c:

    Turbo Incremental Link64 6.50 Copyright (c) 1997-2013 Embarcadero Technologies, Inc.

    Error: Unresolved external 'main' referenced from D:\PROGRAMMIERUNG\C++ BUILDER XE4\LIB\WIN64\RELEASE\C0X64.O

    bcc64: error: Befehl linker mit Beendigungscode 2 fehlgeschlagen (mit -v können Sie den Aufruf anzeigen)`

    Kannst Du etwas mit dieser Fehlermeldung anfangen?

    Danke
    Walter



  • Konovaloff schrieb:

    F5 bedeutet, dass du das Programm debuggen willst. Nun hast du aber den Code geändert …

    Ich bin zurückgekehrt zur unveränderten Version aus Petzolds Buch. Aber das "Projekt-veraltet-Fenster" taucht nach wie vor auf.

    Natürlich. Du hast die Version ja wieder verändert. Es geht nicht um Veränderungen gegenüber der Buchversion sondern Veränderungen gegenüber deiner letzten erfolgreichen Kompilierung. Und solange du nicht erfolgreich kompiliert hast wird er jedes Mal sagen, dass das Projekt vor dem Debuggen (neu) kompiliert werden sollte.

    Konovaloff schrieb:

    … und er fragt dich, ob du es neu kompilieren willst oder du die alte Version debuggen willst.

    Ehrlich gesagt, ich weiß gar nicht, wonach mich VC++ fragt. Er sagt, "Dieses Projekt ist veraltet: HelloMsg - Debug Win32" und fragt: "Erstellen?" Erstellen – was?

    Das Projekt. Die .exe-Datei oder .dll oder was auch immer in deinem Projekt eingestellt ist. In deinem Fall halt ein ausführbares Programm.

    Konovaloff schrieb:

    (Kann man hier im Forum eigentlich Screenshots posten?)

    Nein. Du kannst das Bild irgendwo hochladen und den Link posten.

    Konovaloff schrieb:

    Und das Prädikat "veraltet" (so verstehe ich es zumindest) bezieht sich doch nicht auf eine Projektversion -- sonst hätte es ja bei der allerersten Version diese Fehlermeldung nicht gegeben -- sondern auf Petzolds Quellkode.

    Nene, Visual Studio hat keine Ahnung wer oder was Petzold ist, das versteht nur Quellcode. Und der Quellcode stimmt nicht mit der kompilierten Datei überein, daher die Meldung.

    Konovaloff schrieb:

    Im Allgemeinen will man immer neu kompilieren und dann debuggen, dafür gibt es ein Häkchen neben dem "Ja/Nein", dass er immer neu kompilieren soll und dann kommt das Fenster nie wieder.

    Ich weiß nicht, von welchem Häkchen Du sprichst.

    Dieses Häkchen, alternativ unter Tools->Options. (Ich habe nur die englische Version, weil man da mehr Erfolg hat wenn man die Ente nach Fehlermeldungen fragt).

    Konovaloff schrieb:

    Ich habe ursprünglich sogar nach Visual C++ 6 gesucht, weil es die Version ist, die Petzold in seinem Buch benutzt, und ich diese ewigen Inkompatiblitäten schon zur Genüge kenne und sowas von leid bin. VC++ 6 habe ich im Netz aber auf die Schnelle nicht gefunden, so habe ich VC++ 2010 genommen, weil es die Version aus dem C++-Buch von Dirk Louis ist.

    Überlege dir das nochmal. Altes verbugtes Visual Studio oder neues fehlerärmeres Visual Studio mit vielen Jahren Usability-Erfahrung. Aber VS2010 ist nicht schlecht, man braucht schon etwas Erfahrung bis man an dessen Mängel stößt.

    Konovaloff schrieb:

    `Error: Unresolved external 'main' referenced from D:\PROGRAMMIERUNG\C++ BUILDER XE4\LIB\WIN64\RELEASE\C0X64.O

    bcc64: error: Befehl linker mit Beendigungscode 2 fehlgeschlagen (mit -v können Sie den Aufruf anzeigen)`
    Kannst Du etwas mit dieser Fehlermeldung anfangen?

    In C/C++ braucht man eine main-Funktion. Die hat er bei dir nicht gefunden. Du kannst vielleicht dem Compiler sagen, dass der Einstiegspunkt WinMain und nicht main ist (In VS wüsste ich wie es geht). Alternativ schreibe halt eine main-Funktion. Zum Beispiel so:

    int main(){
        return WinMain(0, 0, 0, 0);
    }
    


  • Überlege dir das nochmal. Altes verbugtes Visual Studio oder neues fehlerärmeres Visual Studio mit vielen Jahren Usability-Erfahrung. Aber VS2010 ist nicht schlecht, man braucht schon etwas Erfahrung bis man an dessen Mängel stößt.

    Ich bin Deinem Rat gefolgt, habe VC++ 2010 de- und Visual Studio Express 2012 installiert. Auf diese Weise erreichen wir vielleicht auch einen sauberen Schnitt, sozusagen eine "jungfräuliche" Installation, die auch näher an Deinem Visual Studio ist. Visual Studio 2012 sieht aber irgendwie anders aus; deshalb beschreibe ich zum Nachvollziehen am besten jeden Schritt.

    Zuerst im Reiter "Startseite" auf Starten/Neues Projekt. Dann im Fenster "Neues Projekt" auf Installiert/Vorlagen/Visual C++ "Win32-Projekt" angeklickt und unter Name "HelloMsg" eingegeben (sowie natürlich Projekt-Ordner von C: auf 😨 geändert). OK.

    "Win32-Anwendungs-Assistent - HelloMsg" erscheint mit folgendem Text:
    Übersicht: Dies sind die aktuellen Projekteinstellungen:
    Windows-Anwendung. Klicken Sie auf Fertig stellen in einem beliebigen Fenster, um die aktuellen Einstellungen zu bestätigen. Nachdem Sie das Projekt erstellt haben, informieren Sie sich in der Datei "readme.txt" des Projekts über die Projektfeatures und die generierten Dateien. Weiter.

    Im darauffolgenden Fenster ist Option "Windows-Anwendung" ausgewählt und unter zusätzliche Optionen "Leeres Projekt" an- und "Security Development Lifecycle" ausgehakt. Seltsamerweise ist der Kasten "Vorkompilierte Header" angegraut, läßt sich also nicht ausschalten. Fertig Stellen.

    Rechts im Projektmappen-Explorer Kontextmenü von Quelldateien angeklickt, Hinzufügen/Neues Element…/C-Datei (.cpp), Name: HelloMsg.cpp. Hinzufügen.

    Es erscheint ein Reiter HelloMsg.cpp, also das Quellkode-Fenster (wie ich annehme). In dieses kopiere Petzolds Quelltext.

    Dann hatte ja irgendjemand geschrieben, ich soll die vorkompilierten Header deaktivieren. Projekt/HelloMsg-Eigenschaften…/Konfigurationseigenschaften/C, C++/Vorkompilierte Header "Vorkompilierte Header nicht verwenden". OK.

    Menü Erstellen/Kompilieren (Strg-F7), die Spannung steigt.

    Ein Wunder – keine Fehlermeldung:

    1>------ Erstellen gestartet: Projekt: Win32Project1, Konfiguration: Debug Win32 ------
    1> HelloMsg.cpp
    ========== Erstellen: 1 erfolgreich, 0 fehlerhaft, 0 aktuell, 0 übersprungen ==========

    Also irgendwo war wohl in der 2010er Version der Wurm drin. Wie bekomme ich das ganze jetzt zu einer ausführbaren Datei gelinkt? In meinem Projektordner gibt es nämlich keine exe-Datei.

    In C/C++ braucht man eine main-Funktion. Die hat er bei dir nicht gefunden. Du kannst vielleicht dem Compiler sagen, dass der Einstiegspunkt WinMain und nicht main ist (In VS wüsste ich wie es geht). Alternativ schreibe halt eine main-Funktion. Zum Beispiel so …

    Daß eine main-Funktion obligatorisch ist, weiß ich natürlich. Aber ich dachte, bei Nichtkonsolen- (WinApi-)Programmen würde diese durch die WinMain-Funktion erstetzt und der Compilier würde das automatisch erkennen. Ich häng hier mal die Optionsliste des Embarcadero-Compilers (bcc64.exe), d.h. den Konsolen-Hilfetext, an; vielleicht siehst Du ja eine Option, mit der man dem Compiler diese Umstellung klarmachen kann:

    Embarcadero C++ 6.60 for Win64 Copyright (c) 2012-2013 Embarcadero Technologies, Inc.
    OVERVIEW: bcc64 driver
    
    USAGE: bcc64 [options] <inputs>
    
    OPTIONS:
      -###                    Die für diese Compilierung auszuführenden Befehle drucken
      --analyze               Statischen Analysator ausführen
      --help                  Verfügbare Optionen anzeigen
      --migrate               Migrator ausführen
      --relocatable-pch       Relozierbaren vorcompilierten Header erzeugen
      --serialize-diagnostics <value>
                              Compiler-Diagnosen in eine Datei serialisieren
      -E                      Nur Präprozessor ausführen
      -ObjC++                 Quelleingabedateien als Objektive-C++-Eingaben behandeln
      -ObjC                   Quelleingabedateien als Objektive-C-Eingaben behandeln
    
      -Qunused-arguments      Keine Warnung für nicht verwendete Treiberargumente ausgeben
      -S                      Nur Vorverarbeitungs- und Compilierungsschritte ausführen
      -Wa,<arg>               Durch Komma getrennte Argumente in <Arg> an Assembler
                              übergeben
      -Wl,<arg>               Durch Komma getrennte Argumente in <Arg> an Linker übergeben
      -Wp,<arg>               Durch Komma getrennte Argumente in <Arg> an Präprozessor
                              übergeben
      -Xanalyzer <arg>        <Arg> an statischen Analysator übergeben
      -Xassembler <arg>       <Arg> an Assembler übergeben
      -Xclang <arg>           <Arg> an CLANG-Compiler übergeben
      -Xlinker <arg>          <Arg> an Linker übergeben
      -Xpreprocessor <arg>    <Arg> an Präprozessor übergeben
      -arcmt-migrate-emit-    ARC-Fehler ausgeben, auch wenn diese durch den Migrator
       errors                 behoben werden können
      -arcmt-migrate-report-  Pfad für den 'plist'-Bericht ausgeben
       output <value>
      -c                      Nur Vorverarbeitungs-, Compilierungs- und Assemblierungs-
                              schritte ausführen
      -emit-ast               CLANG-AST-Dateien für Quelleingaben ausgeben
      -emit-llvm              LLVM-Darstellung für Assembler- und Objektdateien verwenden
      -fcatch-undefined-      Laufzeitprüfungen für undefiniertes Verhalten erzeugen
       behavior
      -flimit-debug-info      Debug-Informationen begrenzen, die zum Verkleinern der
                              binären Debug-Datei erzeugt wurden
      -fno-limit-debug-info   Debug-Informationen nicht begrenzen, die zum Verkleinern der
                              binären Debug-Datei erzeugt wurden
      -ftrap-function=<value> Aufruf an bestimmte Funktion und keine 'trap'-Anweisung
                              ausgeben
      -gcc-toolchain <value>  GCC-Toolkette beim angegebenen Verzeichnis verwenden
      -n <directory>          Ausgabeverzeichnis für Zwischendateien angeben
      -objcmt-migrate-        Migration zu modernen ObjC-Literalen aktivieren
       literals
      -objcmt-migrate-        Migration zu moderner ObjC-Indizierung aktivieren
       subscripting
      -o <file>               Ausgabe in <Datei> schreiben
      -pipe                   Pipes wenn möglich zwischen Befehlen verwenden
      -print-file-name=<file> Vollständigen Bibliothekspfad für <Datei> drucken
      -print-libgcc-file-name Bibliothekspfad für "libgcc.a" drucken
      -print-prog-name=<name> Vollständigen Programmpfad von <Name> drucken
      -print-search-dirs      Pfade zum Suchen von Bibliotheken und Programmen drucken
      -q                      Compiler-Identifikationsbanner unterdrücken
      -rewrite-legacy-objc    Alten Objektive-C-Quellcode in C++ umschreiben
      -rewrite-objc           Objektive-C-Quellcode in C++ umschreiben
      -save-temps             Zwischenergebnisse der Compilierung drucken
      -target <value>         Code für das angegebene Ziel erzeugen
      -time                   Einzelne Befehle timen
      -t<value>               Ausführbare Borland-Zieldatei angeben
      -verify                 Ausgabe mittels Verifizierung überprüfen.
      -v                      Befehle zum Ausführen und Verwenden von ausführlichen
                              Ausgaben anzeigen
      -working-directory      Dateipfade, die relativ zum angegebenen Verzeichnis sind,
       <value>                auflösen
      -x <language>           Nachfolgende Eingabedateien so behandeln, als ob sie den Typ
                              <Sprache> hätten
    

    Danke



  • Konovaloff schrieb:

    Das wäre, ehrlich gesagt, auch meine Lieblingsumgebung: Ganz auf die Visual-C++-IDE verzichten und nur mit UltraEdit und dem Compiler vom C++Builder XE4 arbeiten.

    Das kannst Du auch mit dem Visual C++ machen:
    Editieren mit Ultraedit, dann unter Start/Programme/Visual Studio/Tools die VS Eingabeaufforderung (Konsole) starten, dort kannst mit cl einfach den Compiler starten.
    In Deinem konkreten Fall navigierst Du Dich dann in der Konsole in das Verzeichnis mit der hellomsg.c - Quelldatei und bildest das Programm mit der Anweisung:

    cl hellomsg.c /subsystem:windows user32.lib

    cl ist der Compileraufruf, dem folgt die Quelldatei, als nächstes eine Anweisung an den Linker, ein Windows-Programm und nicht ein Konsolenprogramm zu bauen, ersteres hat nämlich eine WinMain, letzteres eine main - Funktion, daran scheitert wohl auch Dein Versuch mit dem C++ Builder, als letztes noch die Anweisung für den Linker, die user32.lib einzubinden, in dieser ist nämlich der Objektcode für die MessageBox - Funktion.



  • Zu Deinem Embarcadero habe ich diese Seite hier gefunden:
    http://docwiki.embarcadero.com/RADStudio/XE3/en/ILINK64.EXE,_the_64-bit_Incremental_Linker

    Da steht unter anderem:

    /aa Builds a 64-bit Windows application.
    
    /ad Builds a 64-bit Windows device driver.
    
    /ap Builds a 64-bit Windows console application.
    

    Daraus schließe ich mal, dass Du Deinem Linker irgendwie die Option /aa übermitteln musst, wenn Du ein Windows-Programm und kein Konsolenprogramm linken willst.



  • Konovaloff schrieb:

    Im darauffolgenden Fenster ist Option "Windows-Anwendung" ausgewählt und unter zusätzliche Optionen "Leeres Projekt" an- und "Security Development Lifecycle" ausgehakt. Seltsamerweise ist der Kasten "Vorkompilierte Header" angegraut, läßt sich also nicht ausschalten.

    Das ist ok. Mit "Leeres Projekt" meint er wirklich leer, also auch keine vorkompilierten Header.

    Konovaloff schrieb:

    Wie bekomme ich das ganze jetzt zu einer ausführbaren Datei gelinkt? In meinem Projektordner gibt es nämlich keine exe-Datei.

    Das ist schon fertig gelinkt. Die .exe ist nicht im Projektordner, sondern in Projekt\Debug bzw Projekt\Release wenn du auf Release umstellst. Benutze F5, dann kompiliert er und startet das Programm im Debugger.



  • Hallo Belli,

    das Linken mit der Option /aa genügt offenbar nicht. Um auf Nummer sicher zu gehen, habe ich zuerst kompiliert ohne zu linken (bcc64 -c HelloMsg.c), um nur die Objekt-Datei zu bekommen. Das hat auch ohne Fehlermeldung funktioniert. Dann habe ich den Linker aufgerufen mit der entsprechenden Option: ilink64 -aa HelloMsg.o (/aa und -aa sind identisch). Es wird auch hier ohne Fehlermeldung eine exe-Datei erzeugt, zusammen mit einem Haufen anderer Dateien. Aber leider ist die exe-Datei nicht ausführbar, d.h. sie stürzt ab.

    Ich habe auch noch die Option ilink64 -Tpe ausprobiert. Da erscheint wenigstens ein Fensterrahmen, aber auch hier stürzt das Programm ab.

    Danke



  • Hallo npw, ich habe die exe-Datei gefunden und sie funktioniert auch einwandfrei. Wozu sind eigentlich die ganzen anderen Dateien (.suo, .sln, .sdf) gut? Kann man deren Generierung ggf. abstellen?



  • Konovaloff schrieb:

    Wozu sind eigentlich die ganzen anderen Dateien (.suo, .sln, .sdf) gut? Kann man deren Generierung ggf. abstellen?

    sln steht für Solution, also deine "Softwarelösung" (was auch immer das bedeutet). sdf ist glaube ich das Projekt in der Lösung und suo ... Keine Ahnung. Dazu gibt es noch Debuginformationen (pdb).
    Ich empfehle die Dateien Visual Studio zu lassen und nur zu sagen, dass er die .exe am Ende in ein anderes Verzeichnis tun soll. Das findest du unter Projekteigenschaften -> Linker -> Ausgabedatei (Übersetzungen sind wahrscheinlich falsch).



  • Hallo,

    nur um auch noch die letzte Frage komplett abzuschließen:

    Mal eine andere Frage. Ich habe zu Testzwecken mal Petzolds Quelltext durch den Embarcadero-Compiler gejagt, weil der bei den Konsolenquelltexten aus meinen Einführungsbüchern immer tadellos funktioniert hat. Das wäre, ehrlich gesagt, auch meine Lieblingsumgebung: Ganz auf die Visual-C++-IDE verzichten und nur mit UltraEdit und dem Compiler vom C++Builder XE4 arbeiten.

    Um traditionellen (Petzold benutzt Visual Studio 6) API-Kode mit dem 64-Bit-Compiler von Embarcadero C++ Builder XE4 zu kompilieren, muß die Option -tW gesetzt werden:

    bcc64 -tW HelloMsg.c

    Diese Option erzeugt lautet Konsolenhilfetext eine 'Borland target executable', wobei 'target' eine Windows-Anwendung ist (Parameter W ). Diese Lösung verdanke ich audacia aus dem Compiler- und IDE-Forum.

    Was allerdings der Unterschied zwischen einer 'Borland Windows executable' und einer '64-Bit-Windows-Anwendung' ( bcc64 -Xlinker -aa HelloMsg.c ) oder '64-Bit-Windows-Executable' ( bcc64 -Xlinker -Tpe HelloMsg.c ) ist, konnte mir auch im Compiler-Forum niemand erklären. Diese Feinheiten betreffen offenbar nur den 64-Bit-Compiler von Embarcadero; der 32-Bit-Compiler (bcc32.exe) ist weit weniger kryptisch.



  • Konovaloff schrieb:

    Um traditionellen (Petzold benutzt Visual Studio 6) API-Kode mit dem 64-Bit-Compiler von Embarcadero C++ Builder XE4 zu kompilieren, muß die Option -tW gesetzt werden:

    Diese Schlussfolgerung ist falsch. Du wirfst da zwei Dinge durcheinander, die nichts miteinander zu tun haben.

    Du musst diesen Schalter benutzen, wenn du eine Windows-Anwendung erstellen willst, wie beim 32-Bit-Compiler auch. Das hat nichts mit "traditionell" oder Visual Studio zu tun. Auch der Compiler von Visual Studio 6 hat dafür einen Kommandozeilenschalter, nur wird der durch die Wahl des Projekts automatisch gesetzt.



  • Hallo MFK,

    Diese Schlussfolgerung ist falsch. Du wirfst da zwei Dinge durcheinander, die nichts miteinander zu tun haben.

    Gut möglich, ich erhebe keinerlei Anspruch auf hundertprozentig korrekte Formulierungen in diesem Punkt. Ich habe es deshalb so ausgedrückt, weil im Internet von der Verwendung "traditionellen API-Kodes" in der C++Builder Entwicklungsumgebung die Rede ist (so z.B. hier: http://www.webproworld.com/webmaster-forum/threads/88722-A-walk-in-the-garden-part-3-Some-useful-C-hints), wobei unter "traditionell" offenbar einfach älterer API-Kode verstanden wird, den man in den neueren Versionen des C++ Builders ohne Anpassungen nicht mehr verwenden kann.

    Mir geht es primär darum, daß man die Beispiele in Petzolds Buch durch die Angabe dieser Option unverändert übernehmen und erfolgreich kompilieren und linken kann.

    Gleichwohl fordert Dein Hinweis eine andere Frage geradezu heraus. Es ist sowohl möglich, die Kompilierung vom Linken zu trennen und den Linker dann, wie Du sagst, anzuweisen, eine Windows-Anwendung zu erzeugen

    `bcc64 -c HelloMsg

    ilink64 -aa HelloMsg.o`

    als auch an den Linker direkt Optionen zu übermitteln:

    bcc64 -Xlinker -aa HelloMsg

    Alle diese von mir ausprobierten Varianten funktionieren aber nicht, im Gegensatz zur Compiler-Option -tW , von der es im Konsolenhilfetext heißt, sie würde ein Borland-Executable erzeugen. Es muß folglich einen Unterschied geben zwischen einem Borland-Executable und der ausführbaren Datei geben, die durch die Linker-Option -aa erzeugt wird (daneben gibt es noch die Linker-Option -Tpe , die sogar ganz explizit eine Win64-exe erzeugt, aber ebenfalls nicht funktioniert, siehe http://docwiki.embarcadero.com/RADStudio/XE4/de/ILINK64.EXE:_Der_inkrementelle_64-Bit-Linker). Da es Borland schon eine Weile nicht mehr gibt, war das für mich ein Grund mehr, von "traditionellem" Kode zu sprechen.



  • Vielleicht wäre es sinnvoller ein neues Buch zu kaufen statt auf Teufel komm raus zu versuchen uralten Code unverändert zu kompilieren.


Anmelden zum Antworten