Ja, du hast ja recht, aber es soll ja auch kein hoch komplexer Kopierschutz werden, sondern serienreif sein (das heißt nicht für jedes Gerät angepasst werden), ohne Internet und ohne extra Hardware auskommen und soll ohne Passworteingabe entschlüsselt werden können. Dafür kann auf das System auch nur über einen Bus zugegriffen werden. Da bleiben einfach irgendwann nicht mehr viele Möglichkeiten
Und unter Linux könnte ich per Skript beim booten den Container entschlüsseln und Mounten.
Toaster_143 schrieb:
Kann auch sein dass ich von Codeblocks ein wenig verwöhnt bin xD
Du musst irgendwo bei den Projekt-Einstellungen und da dann bei den Linker-Flags die Bibliothek "ncurses" hinzufügen. Das sollte gehen.
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum ANSI C in das Forum Linux/Unix verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?
Dieses Posting wurde automatisch erzeugt.
semaphore sind systemweit verfügbar (unter windows sind das mutexe).
Sprich wenn ein programm beim beenden ein semaphore nicht löscht so ist dieser immer noch im system verfügbar.
Entweder dein Programm erkennt diesen Fall und löscht oder verwendet den semaphore weiter. Oder du löscht den semaphore über den befehl der in der Meldung steht.
Um die Id des semaphor herauszubekommen kannst du dir alle semaphore über den befehl ipcs -s anzeigen lassen.
So, nachdem ich die Sache gestern schon zum laufen bekommen habe, konnte ich heute sogar eine generalisierte Version zusammen hacken:
SOURCES = CreateSQL.cpp \
Data.cpp \
Document.cpp \
Helper.cpp \
ReadParaValueTable.cpp \
SearchNode.cpp \
pvtanalyzer.cpp
OBJECTS = $(SOURCES:.cpp=.o)
CPPFLAGS = -g -KPIC -mt -features=rtti -D_REENTRANT -DSAX_PARSER -library=iostream -features=namespace -I$(XERCES_HOME)/include -c
all:$(OBJECTS)
$(CC) $(PROGARGS) $(INCLUDE) -o program $(OBJECTS) $(LIBS)
clean:
rm -rf $(OBJECTS)
$(OBJECTS):
$(CC) $(CPPFLAGS) $(@:.o=.cpp) -L$(XERCES_HOME)/lib
#$(SOURCES):
# $(CC) $(CPPFLAGS) $@ -L$(XERCES_HOME)/lib
Eine Regel für SOURCE habe ich aber egal wie nicht hinbekommen.
Deshalb der $(@:.o=.cpp) Hack, welcher aus einer *.o Datei wieder eine *.cpp Datei macht.
Ich weiss jetzt nicht, ob das ein Fehler in der Makefile noch verhindert hat, oder Solaris8 hier zu blöd ist. Der Versuch bei all direkt auf SOURCES zu gehen statt OBJECTS schlägt auch fehl.
Naja, jetzt funktionierts, und für solaris8 hab ich endlich eine etwas einfacheres Makefile...
Die Lib die du unter Linux erstellt hast, kannst du unter Windows nicht nutzen. Die musst du schon unter Windows neu erstellen. Da ist cygwin wahrscheinlich die beste Lösung, da es dir auch eine Bash, Autoconf und Make zu verfügung stellt und du genauso vorgehen kannst wie unter Linux. Das ist allerdings noch keine Garantie dafür das es auch funktionieren wird.
Ah sowas dummes. Das mit den Semikolon hatte ich immer und immer wieder übersehen.
Vielen vielen Dank für deine Hilfe. Jetzt erzeugt das Programm auch die Ausgaben so wie ich es erwartet habe und das Programm terminiert nach der richtigen Zeit und die Ausgaben sind nicht deterministisch.
Moh schrieb:
Mein erster Gedanke war einfach, dass es durch die while Schleife eine 100%ige CPU Auslstung gibt, was ja aber gar nicht zutrifft, da die Schleife ja sofort inaktiv wird wenn das Programm aufgerufen wird... Oder irre ich mich da?
Stimmt. Sicherheitshalber würde ich ein sleep in die Schleife einfügen für den Fall, dass das Programm ganz großen Unsinn macht und sich sofort wieder beendet.
Im Vergleich zu z.B. Pipes. Da müssen die Daten ja aus dem Adressraum des einen Programms in den anderen kopiert werden. Das ist bei Shared-Memory nicht nötig.
Hallo,
wenn ich ein GLUT Projekt anlege, muss der Pfad zu GLUT angegeben werden.
Dazu verwende ich die globale Variable $(#glut):
base = /usr
include = /usr/include/GL
lib = /usr/lib
Wenn ich jetzt das Projekt anlegen möchte kommt eine Meldung:
"The patch you entered seems valid but the wizard can't locate the following GLUT's include file: glut.h."
Aber glut.h existiert, in /usr/include/GL. Warum kann glut.h nicht geöffnet werden?
Auf der Suche bin ich auf diese Threads gestoßen, die mir aber nicht weiterhelfen, da die Starter nicht genau erklährt haben, wie sie es gelößt haben.
http://www.c-plusplus.net/forum/viewtopic-var-t-is-254382.html
http://www.c-plusplus.net/forum/viewtopic-var-t-is-182460-and-view-is-previous.html
Du brauchst dazu fork und exec . Unter Linux wird keine neue Console erzeugt. Du kannst aber ein neues Consolen-Fenster ( != Console) öffnen und darin deinen Prozess starten. Du musst dann einen Terminal-Emulator starten und anweisen, dein Programm darin zu starten.
Diese Diskussion hat mir sehr geholfen, ich war auf der Suche nach einem Ersatz für GetTickCount auf Solaris.
Leider verwenden wir ein etwas ältliches Solaris und daher war clock_gettime keine Alternative (kennt weder CLOCK_MONOTONIC noch CLOCK_UPTIME).
Aber irgendwie bin ich über clock_gettime auf gethrtime gestossen. Das gibt es auch in RTLinux.
Und falls Neku es noch lesen sollte:
Es würde mich interessieren, was Neku sicher macht, dass die sleeps auf WIN exakter funktionieren.
Wenn es mit GetTickCount gemessen wurde, ist es kein Wunder dass WIN exakter erscheint. GetTickCount liefert zwar eine Zeit in Millisekunden, wird aber üblicherweise nur alle 10-16ms um 10-16 erhöht. Also die 2ms, die Linux laut Neku "idR" zu lange braucht, gehen auf WIN in der Messgenauigkeit unter (so mit GetTickCount gemessen wurde).
Frank Erdorf schrieb:
Hallo zusammen,
kennt ihr einen Nanosekunden Profiler für linux ?
Ja. Wir kennen so einen.
Frank Erdorf schrieb:
Hat jemand von euch Erfahrungen damit ?
Ja, jemand von uns hat Erfahrungen damit.
Frank Erdorf schrieb:
Geht es auch etwas konkreter ?
Ja, es geht sogar konkreter.
Um deine Frage sinnvoll zu beantworten, muß man eine ganz andere Frage beantworten. Wenn ich eine ganze Nacht durchprogrammiert habe, ist mein Hirn manchmal nicht mehr darauf eingestellt, herauszufinden, was die eigentliche Frage ist.
Du könntest außerdem mal an deinem Plenken arbeiten.
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Themen rund um den PC in das Forum Linux/Unix verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?
Dieses Posting wurde automatisch erzeugt.
"Wäre also SIGUSR1 die bessere Wahl?"
nein, du darfst in dem signal handler einfach nicht soviel machen.
Das signal kommt asynchron, im main thread rein,
vergleichbar mit einem interrupt.
Merke dir im signal handler (z.B. in einem bool),
daß du dich beenden sollst. Wegen meiner logge noch das Signal.
Dann musst du den signal handler (die Funktion) beenden indem du returnst.
Dein Programm muss das bool abfragen und sich dann beenden.
Hier sind dann auch alle cleanups möglich.
Hierzu kommen dann sofort sämtliche blockieren und wartenden Funktionen read, wait, select, ... mit Fehlercode zurück, typischerweise EINTR.
Dein Programm sollte sich am Ende der main Funktion mit einem return code beenden. exit solltest du erstmal nicht verwenden.
Wenn du das schaffst, hast du verstanden wie man Signale verarbeitet.
Viel Erfolg, Gruß Frank
