C++ constructor's - der Letzte macht das Liccht aus ?

[paule32.jk]

moin moin.

- als erstes hatte ich den Fehler 0xc00005 bekommen, was auf eine fehlende .dll zu schließen mag.
- dann hatte ich von RELEASE auf DEBUG gestellt
- der DEBUG Modus ergab, das die Funktion dtor_QChar sauber aufgerufen wurde, und danach die Funktion durchgereicht wurde

also:

Delphi-Quellcode:

destructor QChar.Destroy;
begin
  // wird im RELEASE Mode durchgereicht
  dtor_QChar(ptr_cc);
  // ab hier ist der RELEASE Mode auf einmal zu Ende ??
  ...
  inherited Destroy;
end;

im Gegensatz zu dem DEBUG Mode:

Delphi-Quellcode:

destructor QChar.Destroy;
begin
  // wird im DEBUG Mode durchgereicht
  dtor_QChar(ptr_cc);
  // ab hier wird dann normal weiter gewerkelt
  ...
  inherited Destroy;
end;

Es scheint mir, das RELEASE und DEBUG Mode sehr sehr unterschiedliche Dinge machen.
Aber das ist doch sehr nahe an Voodoo-Programming ??
was sollte so speziell am DEBUG Mode sein ?
das Instruction Set dürfte dabei doch nicht betroffen sein ?

[paule32.jk]

sodele.
Es scheint zu funktionieren.
Die Ausgabedatei im DEBUG Mode ist in etwa gleich groß der RELEASE Mode - mit der Ausnahme, das keine Meldung kommen wie 0xc007b oder 0xc0005.
Das einzige was ich in der DCE 12 IDE Eingestellt habe, ist der DEBUG Mode, aber jetzt kommts: ohne Debug-Informationen übersetzt.
Es sind also keine Debug-Informationen enthalten (jedenfalls ich kann keine finden).
Von daher verstehe ich nicht, das der RELEASE so viel Ärger macht.
Der DEBUG Mode ohne Debug-Informationen scheint ein anderes Format auszugeben als der RELEASE.
very voodoo...

Aber naja, es klappt jetzt erstmal das, was ich angestrebt habe.

[Rollo62]

Zitat von paule32.jk:

Der DEBUG Mode ohne Debug-Informationen scheint ein anderes Format auszugeben als der RELEASE.
very voodoo...

TL;DR;

Der DEBUG Modus bindet aber womöglich doch noch im Linker irgendwelche Debug-Libraries statisch mit ein,
welche im RELEASE dann andere sind.
Die Debug-Informationen beziehen sich ja erstmal nur auf die vom eigenen SourceCode kompilierte Files.

[paule32.jk]

das ja richtig.

Aber ich erhalte, wenn ich mit BPL Packages linke, fast die selben Image-Größen
- im RELEASE wie auch
- im DEBUG

und das sind für die gerade aktuelle Anwendung etwas über 320 KB an Daten.
- die DLL änderte sich ja nicht, wärend meiner Test's.
- die DLL und das 64-Bit DEBUG Image liegen im gleichen Verzeichnis, keine Probleme
- die DLL und das 64-Bit RELEASE Image liegen im gleichen Verzeichnis, Probleme

Die Probleme sind:
- 1 mal 0xc0007 oder:
- 1 mal 0xc0005

beides sind Windows NT (ich nehme mal an kernel32.dll) Sachen.
Daraus schließe ich, das DCE 12 nur im DEBUG Sinn macht, und wer Luxus haben möchte, dann die Version höher kaufen soll, um dann kleineren Content zu erhalten, mit dem RELEASE Mode.

Ist aber auch eine gute Strategie, um die Raubkopierer zu enttarnen:
- hört, hier haben wir ein Image Eurer Anwendung...
- schauen wir doch mal in den binary Salat, und suchen nach bestimmten Mustern, die nur die DEBUG hat
- zack, aus die Maus, Maus trapped.

Ich mein, das würde ich als großer Compiler-Anbieter ja auch so machen.
Aber das sich darüber so ausgeschwiegen wird, naja...
Sollen ja nicht Andere wissen.

Ich hatte vor kurzen ein ähnliches Thema.
Da ging es aber um den FPC.
Der hatte da so ein paar kleine Features eingebaut, womit die Erzeugung einer Eigener system unit recht umständlich ging, wenn man nicht im Besitz dieser kleinen compilerproc Informations-Dinger ist/war.
Das müssten die Entwickler aber auch schon wieder geändert haben, mit wiederum neuen Features.

[freimatz]

Zitat von paule32.jk:

Daraus schließe ich, das DCE 12 nur im DEBUG Sinn macht, und wer Luxus haben möchte, dann die Version höher kaufen soll, um dann kleineren Content zu erhalten, mit dem RELEASE Mode.

Ist aber auch eine gute Strategie, um die Raubkopierer zu enttarnen:
- hört, hier haben wir ein Image Eurer Anwendung...
- schauen wir doch mal in den binary Salat, und suchen nach bestimmten Mustern, die nur die DEBUG hat
- zack, aus die Maus, Maus trapped.

Ich mein, das würde ich als großer Compiler-Anbieter ja auch so machen.
Aber das sich darüber so ausgeschwiegen wird, naja...
Sollen ja nicht Andere wissen.

Ich bin alles andere als gute auf EMB zu spechen, aber bitte behalten deine Verschwörungstheorien für Dich.

[jaenicke]

Das Problem ist meistens, dass irgendwo noch eine (kompilierte) Unit liegt, die statt der verwendet wird, die du vermutest.

Das lässt sich mit Everything von Voidtools leicht prüfen.

Das lässt sich auch leicht testen, indem du eine Fehlermeldung oder einen Fehler an der Stelle einbaust. Wenn der Fehler dann nicht auftritt, wird nicht der aktuelle Quelltext verwendet.

Und was deine Theorien angeht:
Bevor du so etwas äußerst, solltest du das ganze auch geprüft haben. Der generierte Code ist ja jederzeit einsehbar.

[himitsu]

Da kann man oft nur mit dem ProcessMonitor schauen, was von wo sich Delphi wirklich krallt.


Aber vielleicht hilft auch schon ( [F6] depend )
Projektoptionen > Erzeugen > Delphi-Compiler > Compileren > Weitere Optionen > Unit-Abhängigkeitsinformationen ausgeben
siehe die *.d im EXE/DLL-Ausgabeverzeichnis, bzw. für BPLs neben deren *.DCP

Dort steht dann drin, welche Packages (genauer welche *.DCP) genutzt wurden, falls mit Packages kompiliert,
bzw. auch welche *.PAS *.DCU direkt gelinkt wurden (ob vorkompiliert oder neu kompiliert, sieht man wohl nur am Änderungsdatum der DCU)

[paule32.jk]

ich finde EMB eine gute Sache !

mit anderen Produkten aus der (fast) selben Sparte bin ich total aufgelaufen.
Das war noch mit BORLAND und diverse Produkte.

Von denen ich mehr oder minder, Eigene Implementierungen im Laufe der Zeit programmiert habe
bzw. noch dabei bin - ist ja alles für Ein-Mann-Projekt(e) ein wenig anders, als wenn man sie
professionell in oder für einer Firma programmiert.

Mir ist damals nur aufgefallen, das vieles an die Wand gefahren wurde, nur das man das jeweilige
Produkt loswerden wollte.

Aber mit EMB und dessen Vorg#nger bin ich sehr zufrieden - aber wegen der Lisenz nicht mehr
produktiv einsetzen kann.
Früher war ich zugegeben auch ein Anwender in Holzbearbeitung...
Aber dadurch, dass ich einen kleinen Obolus in Form einer kleinen Spemnde zahle, bekomme ich dann
deutlich mehr Support und oder Features.
Soll heißen:
Damals habe ich die Programmierer der Programme nicht respektiert, und erst seit dem ich selbst
Programme entwickle habe ich erkannt, das dies sich nicht nur um das eigentliche Produkt handelt,
sondern, dass da auch andere Menschen oder auch Ich selbst davon abhängig sind...

Für das andere Programm, mit dem ich meine Hilfeprojekte schreibe, ist die Lisenz auch nur für ein
Jahr gültig. Gut, für das was man geboten bekommt lohnen sich für mich die 40 Euro auch dann, wenn
ich das Authoring Tool nicht jeden Tag einsetze...

Von daher kann ich nur jedem OpenSource/OpenSoftware Anwender raten, über eine kleine Spende nach-
zudenken.

Ich bin halt jemand, der testet gerne, bevor er kauft.
Manchmal geht das natürlich tiefer als ein Anwender für ein Produkt machen würde.
Ein Excel-Anwender wird nicht das Wissen haben wie ein Access-Anwender, wohlgleich beide Produkte
für Büro-Anwendungen genutzt werden können.

Bitte verzeiht mir, wenn ich dann so hartnäckig nachfrage...
Aber vielleicht ist ja der Eine oder Andere auch auf ähnliche Fragen gestoßen, die man hier sehr
schön diskutieren könnte, aber vielleicht aus firmenpolitischer Sichtweise nicht direkt was für
die Masse ausbreitbares ist...

Und das man ein kostenloses (nicht umsonst) Tool verwenden kann, mit dem man seine Programmier-
künste erlernen und ausbauen kann, um dann später in einer Eigenen oder Anderen Firma mit der
Erstellung von Programmen oder anderen Dienstleistungen beschäftigt zu sein, finde ich richtig
respektabel.

Ich würde sofort auf die Professional Edition wechseln, wenn ich dürfte bzw. könnte.
Aber mein jetziger Arbeitgeber hat mir Verboten, Geld in der IT bzw. im Internet zu machen.
Und wenn ich das machen würde, würde das dann von meinen jetzigen Status degradieren...

Danke für's Lesen