Hallo Leute, ich habe mal wieder ein Problem beim Kunden. Serverumzug. Die alte Win3.1 Soft muss wieder auf den neuen Server und wie immer meckert das Proggi nach einer Freischaltung. Die Softwarefirma gibt es zwar noch aber wenn es um dieses Proggi geht, lassen die sich verleugnen und sind nicht erreichbar. Mails werden auch nicht beantwortet. Vom alten Server läuft sie noch, aber diesen wegen einem Proggi laufen lassen ist auch alles andere als sinnvoll. Ich habe hier mal einen Teil der INI Datei: [KEY] VVMWIN=2;45;9:<:<D? EUROUMST=2;465=>=::D= VVMWIN602=2849<77A?>>E LIDS=3 VVM-IP303=2;44=7>:?CB> VVM-IP1003=288=5<89:<C<@> VVM-IP1104=29577?;:<=A<=E VVM-IP0509=2956=<@A<;<<CA dazu noch eine PNG mit passenden Schlüssel / SN Kombinationen. Kann sich jemand einen Reim darauf machen, wie die Schlüssel berechnet werden könnten ? Danke
:
Bearbeitet durch User
Wiso entfernst du den Kopierschutz nicht einfach, oder lässt ihn von jemandem entfernen? Oder alternativ das Programm ersetzen, oder ein eigenes schreiben. Oder das Programm disassemblieren und selbst nachsehen. PS: https://xkcd.com/488/
Stephan H. schrieb: > Die Softwarefirma > gibt es zwar noch aber wenn es um dieses Proggi geht, lassen die sich > verleugnen und sind nicht erreichbar. Firmenanwalt fragen: Vieleicht Einschreiben mit Rückantwort und Androhung einer einstweiligen Verfügung. Entweder Freischaltcode oder Lösung wie die SW ohne Code läuft. Das sollte aber der Anwalt besser wissen was da sinnvoll ist. Stephan H. schrieb: > Vom alten Server läuft sie noch, aber diesen wegen einem > Proggi laufen lassen ist auch alles andere als sinnvoll. In einer VM laufen lassen.
Stephan H. schrieb: > Vom alten Server läuft sie noch, aber diesen wegen einem Proggi laufen > lassen ist auch alles andere als sinnvoll. Zieh das Ding in eine virtuelle Maschine um, und bereite Deinen Kunden darauf vor, das "Proggi" irgendwann nicht mehr zu nutzen.
VM is klar, die Stromkosten für den alten Server sind dem Kunden auch egal. Wäre halt nur schön wenn..... Vielleicht schaut ja hier einer rein und sagt.... jo sieht man doch. so und so dann durch 2*33 etc.pp. :-))
Hier mal ne Statistik wie häufig welches Zeichen vorkommt:
1 | Zeichen, Code, Häufigkeit |
2 | 2 50 7 |
3 | 3 51 1 |
4 | 4 52 5 |
5 | 5 53 5 |
6 | 6 54 2 |
7 | 7 55 5 |
8 | 8 56 4 |
9 | 9 57 5 |
10 | : 58 7 |
11 | ; 59 6 |
12 | < 60 12 |
13 | = 61 8 |
14 | > 62 6 |
15 | ? 63 4 |
16 | @ 64 2 |
17 | A 65 4 |
18 | B 66 1 |
19 | C 67 3 |
20 | D 68 2 |
21 | E 69 2 |
:
Bearbeitet durch User
oder halt das proggi auf eine aktuelle versi bringen (oder von einen anderen anbiti gönnen), so das es auf einer aktuellen soft läuft. windows 3.1? echt jetzt? andererseits ist das uralt proggi wahrscheinlich single threaded, und es sollte zu schaffen sein mit einem disassembler (z.b. SoftICE) entsprechende programmstellen auszunopen. alternativ nach einem keygen für proggi suchen :)
Hallo, es gibt keine aktuellere Version davon. Nicht mal die Datenkrake findet etwas dazu.Es gibt einen Nachfolger soweit ich weis. Allerdings will der Firmeninhaber, der seit 2 Jahren in Rente sein wollte, keinen 5-stelligen Betrag mehr ausgeben.
Dann wird der alte Server weiterlaufen müssen. Das kostet zwar Strom, und macht Krach, aber der Aufwand, das Softwarefossil irgendwohin umzuziehen und gar den "Key" zu knacken, steht in keinem Verhältnis zum Nutzen. Ihr solltet Euch nach einer alternativen Lösung für das umsehen, was die Software machen soll, und vor allem über Migration der Daten nachdenken. Denn wenn der alte Server die Grätsche machen sollte, steht Ihr vor einem ganz anderen Problem. Was macht denn die ungenannte Software so tolles und einzigartiges?
ist eigentlich nur ein Proggi für Aufträge/ Rechnung und Provisionen. 0815 also. Das Problem ist der Datenstamm und die weitere Nutzung dessen. Es gibt keine Doku zum Aufbau der DB und Tabellen. Wenn der Server hinüber geht, kommt er eben in eine VM. Den Namen des Proggis habe ich ja absichtlich nicht genannt, ist aber zu sehen für den der es kennt.
Stephan H. schrieb: > Es gibt keine Doku zum Aufbau der DB und Tabellen Ist die DB ein Proprietäres Programm, oder files mit unbekanntem Format? Dann könnte man das versuchen zu reverse engineeren. Falls es nur MySQL, Postgres, MSSQL, sqlite, oder sonst was übliches sein sollte, solte es recht simpel sein die Daten zu exportieren und woanders zu Importieren. Es währe viel einfacher, wenn man das Program hätte, da man es dann disassemblieren könnte. Oder die Files der Datenbank, falls Proprietär, oder die Tabellen descs, falls es eine Bekannte DBSoftware wäre. Dann könnte man die Daten vermutlich relativ einfach für alternative Software anpassen.Aber vermutlich sind das ja vertrauliche Daten... Ihr habt nicht zufällig ne leere DB mit Testdaten?
Ehrliche Antwort: Kauf euch irgendein! neues Programm, dass die Anforderungen erfüllt. zB etwas von Lexware oder SAGE. Dann setzt Ihr da jemanden ein paar Tage dran, der die Daten manuell migriert. Das ist in solchen Fällen der einzig praktikable Lösungsansatz.
mit Daten von Inkasso- Auskunftsunternehmen soll man nicht hausieren. Die DB sind ganz normale dbf Dateien. Wie gesagt der Inhaber will seit 2 Jahren schon weg sein, ohne die Leute auf die Straße zu setzen. Da kann ich verstehen auf unnötige Investitionen zu verzichten. Deswegen läuft das jetzt erstmal so weiter. Solange der alte Server läuft bleibt das eben so. Danach muss eben eine VM her.
Stephan H. schrieb: > Die DB sind ganz normale dbf Dateien Dann ist die Migration doch problemlos, sofern bei Ausfall des Servers noch eine Sicherung verfügbar ist(!!). Allerdings sollte man die vornehmen, bevor der letzte Programmierer gestorben ist, der sich noch mit DBase, Clipper, Fox usw. auskennt. Daniel A. schrieb: > Falls es nur MySQL, Postgres, MSSQL, sqlite Naja, die heutige Jugend... Georg
Georg schrieb: > Allerdings sollte man die vornehmen, bevor der letzte Programmierer > gestorben ist, der sich noch mit DBase, Clipper, Fox usw. auskennt. Ist nichtmal zwingend erforderlich, da die DBF-Tabellen von gängiger Software (mir würde da als Erstes, mit den niedrigsten Einstiegshürden, LibreOffice einfallen) problemlos weiterbearbeiten kann. Erst wenn die alten Automatismen nachgebaut werden sollen, wäre etwas Programmiererei angesagt. Und auch da ist die Auswahl gross. mfG
R. M. schrieb: > Ist nichtmal zwingend erforderlich, da die DBF-Tabellen von gängiger > Software (mir würde da als Erstes, mit den niedrigsten Einstiegshürden, > LibreOffice einfallen) problemlos weiterbearbeiten kann. Das setzt allerdings voraus, daß die Tabellen sinnvoll strukturiert sind, d.h. daß die Spaltennamen irgendwas mit dem Inhalt zu tun haben, und nicht zig Querverweise auf andere Tabellen verwendet werden. In so Softwarefossilien findet man ja manchmal die drolligsten Dinge, ich begegnete mal einer, in der es Tabellen namens "aa", "aaa" und "bb" gab. Das war wohl eine Lagerverwaltung, geschrieben von einem vergreisten Softwareakademiker (der den geistigen Vorruhestand schon vor Erscheinen von DBase III erreicht hatte).
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.