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

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.

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.

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.