brauche SCHNELL feedback bitte !! (läuft mein Programm unter Windwos?)

okay, also ich kann loslegen

die frage ist, was das "fast" nun ist..

ich meine ich kenne mich wirklich NULL mit windows sachen aus...

und ich kann ja nicht anfangen euch am schluss mein komlpettes programm zu posten...

aber ich mache mal alles fertig, und geb euch dann die wichtigen infos.
nun, die da wären ? :xmas2:

die inkludierten headerdateien? es wäre cool, wenn du mir sagst, was relevant ist dafür.

ich hab jetzt z.B. auch schon eingebaut an verschiedenen stellen:

execlp("clear","clear",NULL);

ist denn "clear" überhaupt ein kommando, das die MS-eingabeaufforderung kennt?
oder würde das gar nich funzen?
danke

das execlp, das du benutzt, ist z.b. keine ansi-funktion (ich glaub' das ist posix oder gar linux-proprietär). nur bei standard-funktionen ( http://www.utas.edu.au/infosys/info/documentation/C/CStdLib.html )
kannst du dir sicher sein, dass sie unter allen systemen funzen.

btw, windoofs-compiler haben ein eingebautes #define (WIN32), das man zu bedingter compilierung nutzen kann

....
#ifdef WIN32
CreateProcess(...); // winapi-funktion
#else
execlp(...) // linux-äquivalent
#endif
...

supertux

ansi-freak schrieb:

das execlp, das du benutzt, ist z.b. keine ansi-funktion (ich glaub' das ist posix oder gar linux-proprietär).

execlp ist im POSIX.1-2001 enthalten, also Unix spezifisch.

hdi-loggedout schrieb:

ist denn "clear" überhaupt ein kommando, das die MS-eingabeaufforderung kennt?
oder würde das gar nich funzen?
danke

clear ist kein Kommando sondern ein Programm, meistens in /usr/bin/clear, welches mit der ncurses Bibliothek kommt.

okay also und was kann ich jetzt genau tun, damit mein programm auch unter windows läuft?

wodruch ersetze ich den execlp-aufruf, damit er bei windows entsprechendes macht?

ich kenn mich wikrlich null aus, und @ansi-freak ich muss auch sagen, ich hab keine ahnung was ich mit deinem code anfangen soll :p

wo kommt der denn hin?

Don06

Wenn es um das Loschen des Inhalts der Konsole geht:

void clearConsole()
{
#   ifdef WIN32
    System("cls");
#   else
    execlp("clear" ,"clear", NULL);
#   endif
}

Dann kannst du im Code einfach immer clearConsole benutzen.
Falls clear was anderes ist, sorry ich hab von Unix keinen Plan.

Gruß
Don06

hdi

okay und der windows-aufruf kehrt zurück?
also ich meine z.B. bei UNIX muss man ja forken bevor man execlp aufruft, weil der prozess nicht zurückkehrt.

aber unter windows würde das so laufen? einfach nur:

System("cls");

?

hdi schrieb:

also ich meine z.B. bei UNIX muss man ja forken bevor man execlp aufruft, weil der prozess nicht zurückkehrt.

sowas dummes wie 'forken' ist unter windows nicht nötig.

supertux

mistgabel-fan schrieb:

hdi schrieb:

also ich meine z.B. bei UNIX muss man ja forken bevor man execlp aufruft, weil der prozess nicht zurückkehrt.

sowas dummes wie 'forken' ist unter windows nicht nötig.

Unsinn!

Die exec Familie ersetzt im aktuellen Prozess den Programmcode im Speicher mit dem Programmcode des mit exec* aufgerufenen Programms. Deswegen "kehrt" exec nicht zurück, weil der Prozess sofort ein anderer wird.

Wenn man will, dass ein Programm ausgeführt wird, dann musst zuerst einen neuen Prozess erzeugt werden (wie in Windows mit CreateProcess) und das geschieht mit der man: fork(2) Funktion. Das Kindprozess kann man dann mit execlp "überschreiben" lassen und somit laufen beide Prozesse.

@hdi:
du kannst keine universelle Binary erstellen, du sowhl unter Windows als auch unter einem POSIX System läuft. Du musst also eine Binary für Windows und eine füre GNU/Linux erstellen.

Damit man nicht 2 Sourcetrees zu pflegen braucht, benutzt den Preprozessor wie ansi-freak bzw. Don06 gepostet haben, wobei am besten wäre folgendes

void clearConsole()
{
#ifdef WIN32
    System("cls");
#else
    pid_t child;
    child = fork();
    if(child < 0) return;

    if(child == 0)
    { /* Child */
      execlp("clear" ,"clear", NULL);
      exit(1);
    }
    waitpid(child, NULL, 0);
#endif
}

Der Nachteil ist, dass wenn das Systemziel 'clear' nicht hat oder 'clear' nicht im PATH gefunden wird, dann wird nichts ausgeführt. Es gibt allerdings eine Standard Lösung dafür, nämlich mit ANSI Escape Sequenzen. Dafür muss aber der Terminal ANSI Escape Sequenzen unterstützen. Mittlerweile findet man unter Unix Systeme nur solche Terminale, bei Windows nur wenn ansi.sys geladen wird, bei DOS bis Windows ME durch config.sys. Das sah so aus:

DEVICEHIGH=C:\Windows\COMMAND\ANSI.SYS

Wie man es heute bei Windows NT >4 geht, keine Ahnung.

Jedenfalls kannst du sowas machen:

void clearConsole()
{
  printf("\033[2j");
  fflush(stdout);
}

//edit:

Siehe http://en.wikipedia.org/wiki/ANSI.SYS und http://en.wikipedia.org/wiki/ANSI_escape_code

Wenn ich es richtig lesen, muss man bei Windows NT folgendes tun:

1. c:\windows\system32\config.nt erzeugen/editieren
2. DEVICE=%SystemRoot%\system32\ANSI.SYS eintragen
3. Restart

supertux schrieb:

mistgabel-fan schrieb:

hdi schrieb:

also ich meine z.B. bei UNIX muss man ja forken bevor man execlp aufruft, weil der prozess nicht zurückkehrt.

sowas dummes wie 'forken' ist unter windows nicht nötig.

Unsinn!

kein unsinn. unter windoze wird einfach ein neuer prozess gestartet. der 'erzeuger' bleibt davon unberührt und kann ganz normal weiterlaufen.

supertux

Mein Unsinn betrifft die Aussage des "dummen" Forkes.

Es gibt gute Gründe dafür, dass man fork benutzt. Es hat seine Vorteile als auch seine Nachteile. Ich schreib keine Windows System Programme, ich kenne mich nicht mit den Windows Techniken aus. Das von dir erwähnte Verhalten hat ebenfalls Vorteile als auch Nachteile.

supertux schrieb:

Wenn ich es richtig lesen, muss man bei Windows NT folgendes tun:
1. c:\windows\system32\config.nt erzeugen/editieren
2. DEVICE=%SystemRoot%\system32\ANSI.SYS eintragen
3. Restart

an dem systemeinstellungen herumzupfuschen hat den nachteil, dass es nur auf systemen funktioniert, die auch derart verändert wurden. besser so wie hier: http://www.sourcesnippets.com/c-windows-console-output.html

supertux schrieb:

Es gibt gute Gründe dafür, dass man fork benutzt. Es hat seine Vorteile als auch seine Nachteile.

welche vorteile denn?

supertux

dass du z.b. entscheiden kannst, wann, wie und ob ein neuer Prozess erzeugt wird.

supertux schrieb:

dass du z.b. entscheiden kannst, wann, wie und ob ein neuer Prozess erzeugt wird.

huh? wann, wie und ob hast du mit CreateProcess auch, allerdings ohne dieses unnötig komplizierte handling eines unixartigen-forks.

okay, also ich denke ich werde demnächst mit meinem programm fertig sein.

könnt ihr mir bitte sagen, wie genau ich das dann zu einem programm mach, dass man in windows ausführen kann?

ich kenn mich abgesehen von programmier-befehlen in linux nämlich null aus und weiss nicht, was und wie man etwas anstellt mit einem kompilierten programm, ausser es mit "./programm" auszuführen :xmas2:

hdiloggedout schrieb:

könnt ihr mir bitte sagen, wie genau ich das dann zu einem programm mach, dass man in windows ausführen kann?

durch 'nen compiler/linker jagen und dann - starten.
das ist unter linux nicht anders. als C-entwicklungskit unter windows empfehle ich das: http://www.christian-heffner.de/index.php?page=download&lang=en
(hat alle wichtigen .h und libraries, um executables unter win zu erstellen).

supertux

winapi-fan schrieb:

supertux schrieb:

dass du z.b. entscheiden kannst, wann, wie und ob ein neuer Prozess erzeugt wird.

huh? wann, wie und ob hast du mit CreateProcess auch, allerdings ohne dieses unnötig komplizierte handling eines unixartigen-forks.

kann es sein, dass wir Birnen mit Äpfeln vergleichen? Ich kenne CreateProcess nicht und was ich davon in der MSDN gefunden habe, deutet für mich darauf hin, immer ein neues Programm im security context (was auch das ist) ausgeführt wird. Was ist, wenn ich nur den aktuellen Prozess duplizieren will?

@hdi: liest du überhaupt, was man für dich gepostet hat?

supertux schrieb:

deutet für mich darauf hin, immer ein neues Programm im security context (was auch das ist) ausgeführt wird.

ja, so ist es. der 'security descriptor' ist im prinzip eine struktur, in der alles steht, was ein prozess darf und was nicht. der gestartete prozess 'erbt' im normalfall den SD des aufrufers.

supertux schrieb:

Was ist, wenn ich nur den aktuellen Prozess duplizieren will?

was meinst du mit duplizieren? wenn sich ein programm selbst nochmal startet? das geht so:

// programm.exe
int main()
{
  CreateProcess ("programm.exe", ...);  // gleicher name wie der aufrufer
}

oh man leute, bitte macht n andres topic auf.

das hat doch echt nix mehr mit dem hier zu tun

also jetzt ging das alles zu schnell, viele posts usw ich versteh grad nicht was ich tun kann/soll.

Also wie muss ich jetzt das "clear" machen, damit es richtig geht unter windows?

und sonst muss ich also nichts mehr machen?

einfach den compiler auf dem win-system installieren und ausführen, so wie ich das bei mir auch immer mach?
sonst nix?

hdi

Update:

Okay ich habe das jetzt mal mit diesem PelleC compiler versucht..

also eine funktion geht schon mal gar nicht, egal die brauch ich nicht unbedingt.

aber das clearen des screen funzt nicht:

void clearScreen(void){

#ifdef WIN32
    System("cls");
#endif
}

er compiled zwar, ich kann alles starten und es auch benutzen, aber er macht halt einfach nix immer wenn clearScreen() aufgerufen wird.
Er ignoriert es quasi..

Und @compiler-freak:

Wie is'n das mit dem Compilen mit PelleC?
Ich hatte Win32-Konsolenanwendung gewählt, aber wenn ich das Programm starte kann es keine Umlaute anzeigen? Die MS-DOS-Eingabeaufforderung kann das doch normalerweise schon...?