Crypter

Ehemaliges Mitglied Erhaltene Danke: 1

Na dann wollen wir deinen Augen mal wieder was bieten:

[url=www.luckie-online.de...e]File-Crypter[/url]

JeanvanHees · Beiträge: 146 win 2000 D6 Pers

Also ich hab die vorherige versionen nicht ausprobiert aber bei mir passiert nichts wenn ich datei öffnen selectiere...

_________________
Cause even though I know things won't get any better, they can certainly never get much worse!

Ehemaliges Mitglied Erhaltene Danke: 1

Wie passiert nichts? Bei mir geht dann der Datei-öffnen Dialog auf. Was für ein OS?

JeanvanHees · Beiträge: 146 win 2000 D6 Pers

Windows NT

_________________
Cause even though I know things won't get any better, they can certainly never get much worse!

Ehemaliges Mitglied Erhaltene Danke: 1

Also getestet ist es unter WinME und Win2000 und da funktioniert es wunderbar. bei ME habe ich nur manchmal den Effekt, dass der Pfad manchmal nicht richtig angezeigt wird. das hat aber keinen Einfluß auf die Funktionsweise des Programmes - sollte zu mindest nicht.

O'rallY · Beiträge: 563

Ein kleiner Makel ist mir aufgefallen: Wenn man eine Datei Verschlüsselt, wird an den Dateiname *encoded angehängt. Soweit so gut. Doch wenn ich die Datei nun wieder entschlüssele hab ich eine Datei die z.B. so heißt: datei.txt.encoded.decoded
Es wär nicht schlecht wenn du sie dann einfach wieder *.txt nennen könntest.

Und auch nicht schlecht wäre eine Option, dass die Originaldatei nach dem Verschlüsseln gelöscht wird.

_________________
.oO'rallY
Linux is like a tipi: No gates, no windows and a gnu-eating apache inside...

Popov · Verfasst: Fr 11.04.03 09:10

@Luckie

Ich hab gestern ein kleinen Praxis-Test gemacht und deinen Crypter angewendet. Dabei sind mir paar Punkte aufgefallen:

Der Button "Datei öffnen" funktioniert nicht. Es öffnet sich kein Dialogfenster. Das ist mir aber schon bei einem anderen Programm von dir aufgefallen (DLLExports). Kann es sein, daß du schon XP Dialogfenster anwendest? Ich konnte mir mit D&D behelfen, aber es ist eben nicht das gleiche.

Das andere scheint heute zu funktionieren. Deshalb war das vorerst.

Übrigens, wolltest du die Dll nicht als Ressorce packen und erst beim bedarf entpacken?

_________________
Popov

Ehemaliges Mitglied Erhaltene Danke: 1

Wieder dein Windows98 oder?

Mist immer diese Versionskonflikte. ich werde mal kucken. Mit der AdressDB hattets du ja das gleiche Problem. ich werde das mal fixen.
Bei DLLExports habe ich es wieder zrück geändert weil es da unter 98 nicht ging. Sag mir mal du bei der AdressDB Probleme hast.

Die DLL ist in der Ressource drin. :wink:

Ehemaliges Mitglied Erhaltene Danke: 1

So beide Datei-Öffnen-Dialoge sind jetzt wie in der AdressDB. Probier mal bitte.

Ehemaliges Mitglied Erhaltene Danke: 1

Luckie hat folgendes geschrieben:

Wieder dein Windows98 oder?

Mist immer diese Versionskonflikte.

Es gibt keinen Versionskonflikt. Nicht, wenn du 100% sicher bist, dass deine Delphi-Version den erweiterten TOpenFilename-Typ beinhaltet.

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:

type
  tagOFNA = packed record
    lStructSize: DWORD;
    hWndOwner: HWND;
    hInstance: HINST;
    lpstrFilter: PAnsiChar;
    lpstrCustomFilter: PAnsiChar;
    nMaxCustFilter: DWORD;
    nFilterIndex: DWORD;
    lpstrFile: PAnsiChar;
    nMaxFile: DWORD;
    lpstrFileTitle: PAnsiChar;
    nMaxFileTitle: DWORD;
    lpstrInitialDir: PAnsiChar;
    lpstrTitle: PAnsiChar;
    Flags: DWORD;
    nFileOffset: Word;
    nFileExtension: Word;
    lpstrDefExt: PAnsiChar;
    lCustData: LPARAM;
    lpfnHook: function(Wnd: HWND; Msg: UINT; wParam: WPARAM; lParam: LPARAM): UINT stdcall;
    lpTemplateName: PAnsiChar;

    // NEU -->
    pvReserved: pointer;
    dwReserved: dword;
    FlagsEx: dword;
  end;

Aber dann brauchst du die Größen (OPENFILENAME_SIZE_VERSION_400) auch nicht selbst deklarieren, die sollte Delphi dann kennen. Der Fehler lässt sich ja auch recht einfach erklären: Die älteren Windows-Versionen können mit den letzten drei Parametern nichts anfangen. Benutzt du also den erweiterten Typen, dann musst du die Größe entsprechend reduzieren, damit das Betriebssystem nur die ihm bekannten Parameter benutzt:

markieren

Quelltext

1:
2:

OPENFILENAME_SIZE_VERSION_400A = sizeof(TOpenFileNameA) -
  sizeof(pointer) - (2 * sizeof(dword));

In dem Fall werden also der Pointer (4 Bytes) und die zwei DWORDs (8 Bytes) entfernt, und der Typ entspricht dem Original der CommDlg-Unit.

Dieser Originaltyp allerdings kennt die drei neuen Membervariablen nicht! Wendest du die Konstante OPENFILENAME_SIZE_VERSION_400 hier an, dann entfernst du (wahrscheinlich) "lCustData", "lpfnHook" und "lpTemplateName". (Unter der Voraussetzung, dass die drei genannten Membervariablen auch jeweils 4 Bytes belegen.) Der Typ stimmt also nicht mehr, weil die Größe falsch angegeben wurde, und darum passiert bspw. unter Windows 98 auch nichts.

Was nun den Crypter angeht: Wird die Zeile

markieren

Quelltext

1:	ofn.lStructSize := OPENFILENAME_SIZE_VERSION_400

durch

markieren

Quelltext

1:	ofn.lStructSize := sizeof(TOpenFileName);

ersetzt, tritt der Fehler auch nicht mehr auf.

Ehemaliges Mitglied Erhaltene Danke: 1

MathiasSimmack hat folgendes geschrieben:

Was nun den Crypter angeht: Wird die Zeile

markieren

Quelltext

1:	ofn.lStructSize := OPENFILENAME_SIZE_VERSION_400

durch

markieren

Quelltext

1:	ofn.lStructSize := sizeof(TOpenFileName);

ersetzt, tritt der Fehler auch nicht mehr auf.

So hatte ich es doch erst und dann hat er sich beschwert dass es nicht ginge. War übrigens bei der Export- und Improtfunktion meiner AdressDB genauso. Ich habe es dann extra geändert und dann meinte er es ginge.

Kann es daran liegen, dass du D5 hast und ich D6?

Aber das entscheidende ist doch jetzt: Geht dieser Code

markieren

Quelltext

1:	ofn.lStructSize := OPENFILENAME_SIZE_VERSION_400

unter Win98 ja oder nein. Bitte eien klare Antwort?

Ehemaliges Mitglied Erhaltene Danke: 1

Luckie hat folgendes geschrieben:

Kann es daran liegen, dass du D5 hast und ich D6?

Eigentlich nicht, weil erst D7, IMHO, die komplette neue Deklaration (s. oben) enthält. D6 dürfte auch nur den Originaltypen kennen. Aber da bin ich nicht 100% sicher. Diese Frage könntest du mit Hilfe der Code-Vervollständigung klären, wenn du keinen Zugriff auf die Units hast.

Als Beispiel: ich glaube, dass den Tutorials die Unit "CommDlg_Fragment.pas" beiliegt. Diese enthält den erweiterten TOpenFileName-Typen. Benutze ich diese Unit mit deinem FileCrypter, dann funktioniert es mit der Zuweisung:

markieren

Quelltext

1:	ofn.lStructSize := OPENFILENAME_SIZE_VERSION_400;

auch unter Win 98 problemlos. Aber das liegt, wie oben erklärt!, daran, dass hier der erweiterte Typ verwendet und größen-reduziert wird, so dass er dem Original aus der CommDlg entspricht. Und dann geht das nämlich auch.

Zitat:

Geht dieser Code

markieren

Quelltext

1:	ofn.lStructSize := OPENFILENAME_SIZE_VERSION_400

unter Win98 ja oder nein. Bitte eien klare Antwort?

Nein! Nicht bei mir! Und nicht, wenn du vom Quellcode sprichst. Der benutzt nämlich nur die Unit CommDlg. Und die enthält in meinem Fall (D5) nur den alten Typ von TOpenFileName. Das Problem habe ich ja erklärt: der wird jetzt um 12 Bytes gekürzt, und dadurch funktioniert es nicht mehr.

Interessant ist (wie bei DLLExports), dass die kompilierte Version von dir den Dialog anzeigt. Der Fehler beschränkt sich daher für mich nur auf den beiliegenden Quellcode. (Hast du dir eigentlich mal meine modifizierten Versionen von DLLExports angesehen, oder ist die Mail gar nicht angekommen?)

Wenn es bei dir unter Win 2000 so klappt:

markieren

Quelltext

1:	ofn.lStructSize := OPENFILENAME_SIZE_VERSION_400;

und du keine angepasste oder extra Unit mit dem erweiterten TOpenFileName verwendest, dann muss ich passen: Den Grund für das Funktionieren kann ich dir in dem Fall nicht nennen.

Ehemaliges Mitglied Erhaltene Danke: 1

PSDK (GetOpenFileName) hat folgendes geschrieben:

Windows NT 4.0: The OPENFILENAME structure includes additional members on more recent versions of Windows. However, this causes problems for applications on previous versions of Windows. To use the current header files for applications that must run on Windows NT 4.0, either use the #define "/D_WIN32_WINNT=0x0400" or use OPENFILENAME_SIZE_VERSION_400 for the lStructSize member of OPENFILENAME.

Obwohl hier nur von NT4 die Rede ist, gilt das auch für 95 und 98. Wie das bei ME ist, weiß ich nicht. Könnte ein mitlesender ME-Besitzer mal Luckies Quellcode kompilieren und ausprobieren? (Nicht die bereits von Luckie kompilierte Version! Die funktioniert bei mir auch.)

btw: Luckie, du müsstest mal deine Postings kontrollieren. Hier gibt´s einen oder zwei Links, die ins Leere führen (www.luckie-online.de/downloads/crypter.zip --> Error 404).

Ehemaliges Mitglied Erhaltene Danke: 1

Aaah, ich werde noch mal irre. Jetzt noch mal für den kleinen, arme, irren, Luckie zum Mitschreiben:
Was muß ich machen, damit es auch ohne die Fragement-Datei unter beiden OS läuft?

Ehemaliges Mitglied Erhaltene Danke: 1

Auf die Fragmentdatei CommDlg_Fragment verzichten und den alten Typ benutzen. Nach den Tests mit dem Standarddialoge-Beispiel aus den Tutorials funktioniert er auch unter ME, 2000 und XP.

Die Konstanten "OPENFILENAME_SIZE_VERSION_xxx" entfernst du aus dem Quelltext und benutzt stattdessen, wie gehabt,

markieren

Quelltext

1:	sizeof(TOpenFileName)

Wenn man es genau nimmt, hat von den drei neuen Membervariablen eigentlich nur FlagsEx einen Sinn. Die anderen beiden sind bisher reserviert und Null/nil.

Du könntest auch von mir eine mittlerweile bereinigte Version bekommen. :wink:

Allerdings habe ich auch die Sache mit der DLL in den Ressourcen entfernt. Das müsstest du evtl. ergänzen.

Ehemaliges Mitglied Erhaltene Danke: 1

Gut, danke. Das wollte ich doch nur wissen. Aber so hatte ich es doch, denke ich. Na egal. Jetzt wird es so gemacht und wer ein veraltetes OS von MS benutzt ist selber schuld. :roll:

Ehemaliges Mitglied Erhaltene Danke: 1

Luckie hat folgendes geschrieben:

Gut, danke.

Bitte. Gern geschehen.

Zitat:

Das wollte ich doch nur wissen. Aber so hatte ich es doch, denke ich.

Das mag sein. Aber dann hast du für die Veröffentlichung die Fragmentdatei aus dem Quellcode wieder entfernt. Dadurch kam es zu dem Fehler. Das ist sowieso der Punkt, den ich nicht so ganz verstehe.
Bei DLLExports hattest du schon geschrieben, der Quellcode wäre aktueller als die Exe. Wenn ich etwas samt Sourcen veröffentliche, dann kompiliere ich die fertige Version immer mit dem Quellcode, den ich veröffentlichen will. Auf die Weise gibt es keinerlei Unterschiede.

Musst mal deine Veröffentlichungspolitik überdenken. :wink:

Zitat:

Na egal. Jetzt wird es so gemacht und wer ein veraltetes OS von MS benutzt ist selber schuld. :roll:

Das hat mit dem OS nichts zu tun. ´s liegt nur am Programmierer, der uns seine Tools aufs Auge drücken will. :twisted:

Ehemaliges Mitglied Erhaltene Danke: 1

MathiasSimmack hat folgendes geschrieben:

Bei DLLExports hattest du schon geschrieben, der Quellcode wäre aktueller als die Exe.

Das war natürlich nicht erst gemeint du Dussel. :wink:

Ich kompiliere und bevor ich das Archiv erstelle wird die Exe aus dem Sourceverzeichnis eins nach oben verschoben und dann wird das Archiv erstellt.

Ehemaliges Mitglied Erhaltene Danke: 1

So DLLExports jetzt wiede rmit sizeof(TOpenfilename).

@Mathias: Jetzt liegt eine Batch dabei die mir alles abnimmt, kompilieren, in den richtigen Ordner verschiben, Archiv erstellen, umbenennen und in sfx-Archiv konvertieren. Ich suche nur nach einer Möglichkeit, die Batch mit Parametern aufrufen zu können

Popov · Verfasst: Mo 14.04.03 17:49

Achso, hab ich vergessen zu sagen. Jetzt funktioniert es

_________________
Popov

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme