Ein Programm 2x öffnen obwohl es das nicht will?



  • Da hat CStoll recht, es ist möglich, daß Probleme auftreten, wenn Du das Programm zweimal öffnest. Sonst hätte der Autor das sicherlich nicht eingebaut.

    Eine Möglichkeit, es trotzdem zu versuchen, wäre ganz einfach, das Programm zu disassemblieren und die Stelle(n) zu suchen, an denen das Programm beendet wird. Dann brauchst Du nur schauen, welche Entscheidung dazu führt, und entfernst diese Operationen einfach aus dem Code heraus und testest danach nochmal.

    Das kann ganz simpel sein und nach 5 Minuten funktionieren, unter Umständen kannst Du da aber auch 'nen Tag oder noch länger dran sitzen. Mußt halt wissen wie wichtig Dir das ist 🙂



  • Hmm das hab ich mir schon gedacht. Den Programmcode hab ich natürlich nicht 😉
    Wenn ich wüsste das er es mit FindWindow macht dann könnte ich ihn ja Hookn oder nicht?
    disassemblieren wäre auch ne möglichkeit. Auch schon gemacht aber nicht wirklich in der Thematik.
    Hmm ... 🙂

    MfG schirrmie



  • Naja ich würde erstmal nicht rumraten mit welcher Funktion er nach seiner bisherigen Instanz sucht, sondern ich würde mir anschauen, wie unter Windows ein Programm beendet wird (weiß ich jetzt grad nicht, ob es da ein bestimmtes Muster gibt - aber wenn ja, ist das natürlich ein absolut wasserdichtes Vorgehen).

    Gibt das Programm eine Meldung aus, daß es nicht zweimal gestartet werden darf? Dann hast Du es natürlich besonders leicht 😉

    Eine andere Strategie wäre die Annahme, daß das Programm diese Überprüfung quasi als allererste Aktion durchführt, also einfach mal im Bereich des EntryPoints schauen, was da so passiert (z.B. auch ob Dateien geöffnet werden oder sowas).



  • Habe gerade mal nachgeschaut, allem Anschein nach werden Windows-Programme mit KERNEL32.ExitProcess beendet. Seltsamerweise ist dieser Aufruf immer mindestens 2x drin. Vielleicht hilft Dir das ja weiter, dürfte nicht allzu kompliziert sein wenn Du nicht grad extemst Pech hast 😉



  • Mal so eine Frage, Wo hast du das nachgeschaut und womit?

    schirrmie



  • Ich hab einfach eine ganz minimale Anwendung "programmiert" in C++ und kompiliert. Dann die EXE mit W32Dasm disassembliert und auf "Import Functions" geklickt, dort siehst Du sämtliche eingebundenen Funktionen, natürlich auch alle WinAPI-Funktionen. Und ExitProcess klang meiner Meinung nach am treffendsten 😉 danach googlen und Du findest alle weiteren Infos, wobei es in diesem Fall aber nicht mehr viel anderes gab (außer daß es noch eine Funktion namens TerminateProcess oder so gibt, und der Unterschied ist, daß DLLs nicht freigegeben werden).

    EDIT: Um welches Programm handelt es sich eigentlich in Deinem Fall?



  • Nimm dir lieber einen Debugger ala SoftICE (kommerziell), LinICE oder rr0d. Damit kannst du das Programm dann durchgehen. Dann schaust du dir den Verlauf an, wenn du das Programm normal startest und wenn du es ein zweites mal startest. Irgend ein Vergleich wird anders sein. Die stelle merkst du dir und mit einem Hexeditor NoPst du den Vergleich aus. Vola



  • Vielen dank für eure Antworten. Mit W32Dasm kenn ich mich ein bissel aus aber nicht wirklich groß. Von den anderen habe ich auch schon gehört, sollte ich mir mal angucken.
    Das Programm ist etwas speziell das wird man so nicht kennen und es ist auch garnicht mehr auf den Markt also schon älter aber an sich nichts besonderes.
    Werde mir das mal angucken.

    MfG schirrmie



  • Naja, in einer anderen Window Station müsste es sich ein 2. mal starten lassen.
    Bloss... wie bekommt man ne 2. Window Station ohne Terminal Services?



  • starte das programm in einem virtuellen system nochmal. dann gibts auch keinen ärger mit ressourcenkonflikten.


Anmelden zum Antworten