[BCB] Die nervigen Exporte in erzeugten Programmen

[Olli]

Erstmal danke an euch beide, fuer die Antworten.

Zitat von DMW:

Was das __CPPDebugHook-Symbol angeht, so kannst du es loswerden, indem du die Export-Definition in $(BCB)\Source\Rtl\Source\startup\c0nt.asm auskommentierst (auch die weiter unten in der Datei zu findende Referenzierung muß beseitigt werden) und die C++-RTL kompilierst. Daß die Übersetzung irgendwann mit einem Fehler abbricht, sollte nicht stören, da die Startup-Objektdateien zu diesem Zeitpunkt bereits übersetzt sind und Fehler lediglich in für den Debug-Modus kompilierten Dateien auftreten sollten, die den Code referenzieren. Allerdings solltest du eine Debug-Version der c0*.obj-Dateien behalten, die das Symbol exportieren. Eine Möglichkeit ist, die vorhandenen Dateien nach $(BCB)\Lib\Debug zu verschieben und die angepaßten Versionen in $(BCB)\Lib\Release unterzubringen, doch mußt du dann für Debug- und Release-Build die Projektoptionen entsprechend anpassen. (In C++Builder 2006 und höher gibt es dafür endlich die Build-Konfigurationen.) Ähnliches Vorgehen dürfte auch für _GetExceptDLLinfo möglich sein, jedoch habe ich das noch nicht getestet.

Danke erstmal fuer die Erklaerung. Somit scheint es zumindest keine wirklich vernuenftige Methode zu geben, wie man es in der Standardkonfiguration hinbekommt. Ich neige zu einem "Typisch Borland ..."

Zitat von DMW:

Die Initialize- und Finalize-Symbole für deine Units kannst du loswerden, wenn du #pragma package(smart_init) entfernst (alle Konsequenzen für die Initialisierung statischer Daten und für Packages sind in der Hilfe zu #pragma package dokumentiert). Symbole wie _MyForm, die davon herrühren, daß C++Builder standardmäßig eine globale Variable und Instanz für jedes Formular erzeugt, kannst du in den jeweiligen Headerdateien entfernen (die Zeile extern PACKAGE TMyForm *MyForm.

Das ist wunderbar, funzt dann aber logischerweise nur an einigen Stellen.

Zitat von DMW:

Ein QC-Eintrag zum Thema wäre hier zu finden.

Derjenige welcher den Bug gemeldet hat, wurde ja ziemlich abgebuegelt. Scheint, als haette der Entwickler von Borland noch nie was von Crackern gehoert. Die freuen sich ueber jeden Export mit Namen. Das ist defacto ein gutes Argument gegen BCB, immerhin hat Delphi nicht das Problem. Auch habe ich den Verdacht, dass allein durch die Exporte das Smartlinking beeintraechtigt wird, da logischerweise ein Export nicht wegoptimiert werden kann. Aber das ist nur ein Verdacht.

Zitat von DMW:

Vielleicht hilft es, in den Projektoptionen die Liste der Packages zu leeren oder zu optimieren.
Ansonsten: ist tatsächlich nirgendwo im Code ein #include "SHDocVw_OCX.h" oder ein #pragma link "SHDocVw_OCX" zurückgeblieben?

Also ich habe durch den gesamten Projektcode gegreppt: Nix. Dann habe ich sicherheitshalber nochmal die SoftGems-Komponenten und die madCollection gegreppt und da kam auch nix dergleichen raus (der eine Treffer fuer MSHTML in SoftGems ist in einer Demo). Interessanterweise ist das auch gerade die EXE, die nie was mit dem IE oder seinen Controls zu tun hatte. Bei einer anderen EXE des gleichen Softwareprojektes wuerde ich es als Ueberbleibsel abtun.