4. Programm für PrettyOS schreiben - Einsprungpunkt? makefile? .ld?

Programm für PrettyOS schreiben - Einsprungpunkt? makefile? .ld?

  • A

    Ändert man die Datei "hello.c" in Windows, lässt sich das Projekt auch nicht mehr kompilieren... scheinbar wird die HELLO.ELF gar nicht erst erstellt. Finde auch nichts dahingehend in der makefile.

    0
  • M

    Ich erzeug das Image sowieso manuell, daher war mir das nicht aufgefallen...

    0
  • E
    Mod

    hallo, rev. 84 liefert die erstellungswerkzeuge (build, makefile, tools, ...) in einem eigenen Unterordner mit. HELLO.ELF muss groß geschrieben werden, damit es in das FloppyImage eingebaut wird.

    0
  • E
    Mod

    Ich habe nu eine Funktion
    char* gets(char* s)
    in userlib.h/c eingefügt, aber es klappt leider noch nicht richtig im User-Programm.

    char* gets(char* s) ///TODO: leads to no success
{
    int i=0;
    char c;
    do
    {
        c = getch();
        putch(c);
        if(c==8)  // Backspace
        {
           if(i>0)
           {
              s[i]='\0';
           }
        }
        s[i] = c;
        i++;
    }
    while(c!=10); // Linefeed
    s[i]='\0';
    return s;
}

    Separat getestet ist alles ok damit.

    In der Multitasking-Umgebung von PrettyOS geraten allerdings die Tasks und die Zeichen durcheinander. 🙄

    0
  • A

    Hallo!

    Habe mir einfach mal ein Programm gebastelt, was einfach nur den Screen löscht. Das compilieren und testen funktioniert wunderbar, bis... naja, bis ich's übertrieben habe... Ich habe dabei das Programm mehrmals hintereinander aufgerufen. Irgendwann (was die Anzahl betrifft nicht reproduzierbar) kam dann ein General Protection Fault...

    Hat jemand eine Idee woran das liegen könnte?

    #include "userlib.h"

int main()
{
	unsigned long* vidmem = (unsigned long*) 0xb8000;
    unsigned long i=0;
    while(i<(40*25))
    {
        vidmem[i] = 0x07200720; // white on black, Space (0x20)
        ++i;
    };
	return 0;
}
    0
  • E
    Mod

    Das ist echt ein interessanter Punkt. So sieht bei mir momentan start.asm aus, das den Start und das Ende von main() der User-Test-Funktion im Verzecihnis user_test_c "umhüllt":

    ; start.asm

[BITS 32]
extern __bss_start
extern __end
extern _main
extern _exit
extern _test
global _start

_start:
    mov esp, 0x600000 ; stackpointer
    call _main	
	call _test
	call _exit	
	call _test

    ... und nach mehrfachem Ausführen gelingt es odch tatsächlich, auch das zweite test() auszuführen. Dann kommt es logischerweise zum Absturz, so wie das Programm aufgebaut ist ohne jmp $ oder hlt!

    Mal braucht es nur drei "hello", mal ca. 10:
    screenshot: http://www.henkessoft.de/OS_Dev/Bilder/Rev87_mit_gets.PNG

    Weiß jemand, wie das passieren kann? Hat ja wohl mit dem Multitasking zu schaffen?

    0
  • E
    Mod

    Nun sieht start.asm so aus:

    ; start.asm

[BITS 32]
extern __bss_start
extern __end
extern _main
extern _exit
extern _test
global _start

_start:
    mov esp, 0x500000 ; stackpointer
    call _main	

	call _exit	
	call _test
	jmp  $

    Man beachte den gegenüber der Shell (dort 0x600000) veränderten Stack-Pointer!

    0
  • E
    Mod

    Habe mir einfach mal ein Programm gebastelt, was einfach nur den Screen löscht.

    Jetzt - mit Rev. 89 - sollte das Programm laufen. Wir haben mehr als 25 Zeilen.

    0
  • A

    Perfekt! Nachdem ich das Programm mit dem veränderten Startpointer übersetzt habe, habe ich noch dem 34. Aufruf aufgegeben - das Programm und das OS läuft wie es sich gehört! 😃

    0
  • E
    Mod

    Perfekt! Nachdem ich das Programm mit dem veränderten Startpointer übersetzt habe, habe ich noch dem 34. Aufruf aufgegeben - das Programm und das OS läuft wie es sich gehört! 😃

    Na, endlich sind wir im bereich des positiven Feedback. Jetzt wird es ja auch interessant mit Multitasking/Scheduling und User-Programmen/syscalls/User-Lib.

    0
Anmelden zum Antworten