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

[MFK]

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?

[Konovaloff]

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

[nwp3]

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);
}

[Konovaloff]

Ü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

[Belli]

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.

[Belli]

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.

[nwp3]

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.

[Konovaloff]

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

[Konovaloff]

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?

[nwp3]

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).

[Konovaloff]

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.

[MFK]

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.

[Konovaloff]

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.

[nwp3]

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

[MFK]

Konovaloff schrieb:

Gleichwohl fordert Dein Hinweis eine andere Frage geradezu heraus.

Die Frage konnte ich zwar nicht finden. Aber ich nehme an, du möchtest wissen, warum es mit dem Compiler-Schalter geht, mit den Linker-Schaltern aber nicht.

Ich vermute, dass der 64-Bit-Compiler und der Linker einfach nicht besonders gut zusammenpassen. Soweit ich weiß, kommt der Linker von Embarcadero (oder einem Vorgänger), der neue Compiler basiert aber auf Clang.

Du machst dir da ziemlich viele Gedanken um das Verhalten zweier Tools, die möglicherweise nur notdürftig aufeinander abgestimmt wurden.

[Konovaloff]

Hallo nwp3,

welches "neue" Buch zur API-Programmierung würdest Du denn empfehlen, das im Hinblick auf Umfang und Detailliertheit mit dem Petzolds vergleichbar wäre? Ich bin für jeden guten Ratschlag dankbar.

[Konovaloff]

Hallo MFK,

die Frage war, was der Unterschied zwischen

a) einem "Borland executable" (erzeugt durch bcc64 -tW HelloMsg.c ),
b) einer 64-Bit-Windows-Anwendung, von der Du in Deiner Antwort gesprochen hast (erzeugt durch bcc64 -Xlinker -aa HelloMsg , siehe http://docwiki.embarcadero.com/RADStudio/XE4/de/ILINK64.EXE:_Der_inkrementelle_64-Bit-Linker) und
c) einer EXE-Datei für 64-Bit-Windows (erzeugt durch bcc64 -Xlinker -Tpe HelloMsg , siehe gleich URL) ist.

Nach meinen bisherigen laienhaften Vorstellungen erzeugen alle drei Optionen eine Windows-Anwendung, aber nur eine davon funktioniert (a).
Was die Frage angeht, ob der Compiler und der Linker gut zusammenpassen: Ich dachte bisher, daß der Compiler ( bcc64 ) den Linker automatisch aufruft, einfach weil ersterer

`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.`

auf den Bildschirm schreibt. Ich ging bisher davon aus, daß "Turbo Incremental Link64 6.50" nichts anderes ist, als ilink64 , den man auch separat aufrufen kann. Nur sofern das falsch ist, wäre es plausibel, von einem schlechten Zusammenpassen von Compiler und Linker auszugehen.

Das Problem ist, daß es einerseits zum 32-Bit-Compiler bcc32.exe eine recht ausführliche Dokumentation gibt, dieser aber Warnungen ausspuckt, die beim 64-Bit-Compiler nicht auftreten:

`Warnung W8057 HelloMsg.c 12: Parameter 'hInstance' wird nie verwendet in Funktion WinMain

Warnung W8057 HelloMsg.c 12: Parameter 'hPrevInstance' wird nie verwendet in Funktion WinMain

Warnung W8057 HelloMsg.c 12: Parameter 'szCmdLine' wird nie verwendet in Funktion WinMain

Warnung W8057 HelloMsg.c 12: Parameter 'iCmdShow' wird nie verwendet in Funktion WinMain`

und es andererseits nur recht spärliche Informationen zum 64-Bit-Compiler gibt. Daher weiß ich nicht, warum bestimmte Optionen (wie bcc64 -tW ) funktionieren und andere (wie bcc64 -Xlinker -Tpe ) nicht. Und ich würde das schon gern wissen.

[MFK]

Konovaloff schrieb:

Ich ging bisher davon aus, daß "Turbo Incremental Link64 6.50" nichts anderes ist, als ilink64 , den man auch separat aufrufen kann.

Der Linker ist ilink64. Aber der 64-Bit-Compiler ist keine Eigenentwicklung von Embarcadero, sondern ein angepasster Clang:

docwiki.embarcadero.com schrieb:

The C++ 64-bit Windows compiler (BCC64) is based on the open-source Clang compiler

Das ist auch der Grund, warum er komplett anders bedient wird als der 32-Bit-Compiler, andere Warnungen ausspuckt und andere Kommandozeilenpotionen hat.

Auf derselben Seite steht auch:

docwiki.embarcadero.com schrieb:

Note: Using BCC64 on the command line can have unexpected results.

Embarcadero hat den Compiler offenbar nur soweit angepasst, dass es aus ihrer IDE, die den Compiler mit ganz bestimmten Optionen aufruft, funktioniert. Alles andere kann eben schiefgehen. Es gibt da keine drei Arten von Anwendungen, von denen zwei nicht funktionieren. Du hast einfach nur Möglichkeiten entdeckt, Compiler und Linker so zu bedienen, dass dabei Müll herauskommt.

Verwende die Schalter, von denen du weißt, dass sie funktionieren, und gib Ruhe. Dein Beharren auf irgendeinem undokumentierten technischen Hintergrund, wenn es einfach nur Bugs sind, ist frustrierend.

[nwp3]

Konovaloff schrieb:

Hallo nwp3,

welches "neue" Buch zur API-Programmierung würdest Du denn empfehlen, das im Hinblick auf Umfang und Detailliertheit mit dem Petzolds vergleichbar wäre? Ich bin für jeden guten Ratschlag dankbar.

Ich kann dir leider kein gutes Buch empfehlen. Die WinAPI ist alt, der Code und die Bücher dafür sind alt. Wahrscheinlich gibt es gar kein Buch, dass die WinAPI in einer modernen Sprache lehrt.
Andererseits sehe ich auch kein Bedürfnis dafür. Ich habe theForger's Win32 API Programming Tutorial überflogen und das hat für grundlegende Dinge gereicht. Wenn ich mehr gebraucht habe habe ich immer irgendwie die entsprechenden Funktionen gefunden. Da du dank Petzolds Buch einen recht guten Überblick über die WinAPI haben solltest sollte ein einfaches Nachschlagen der Funktionen völlig ausreichen. Außerdem halte ich nichts davon Code zu kopieren den man nicht versteht. Um Petzolds Code zum Laufen zu kriegen würde ich die Funktionen nachschlagen und so benutzen wie es in der Dokumentation steht (wo möglicherweise steht dass die Funktion nicht mehr unterstützt wird und man stattdessen eine andere nehmen soll). Somit wirst du besseren Code als im Buch haben der im Prinzip dasselbe tut, den du verstehst und beliebig erweitern kannst.