Nachrichten

41

Lowlevel-Coding / Re: Devices. aber wie?

« am: 25. August 2009, 21:30 »

Naja, so allgemein kann man dir da immernoch nicht helfen - wie nen Interface aussieht hängt nunmal doch _sehr_ stark an der Restlichen Systemarchitektur - Mikrokernel oder (modular?) monolithisch. In einem Mikrokernel wäre nen Treiberinterface z.b. meistens sehr unabhängig, da kann einfach der vorhandene Messaging- bzw RPC-Mechanismus genutzt werden. In nem Monolithen wäre die Bereitstellung von Interrupts wohl die praktikablere Variante, Callgates in der GDT sind natürlich auch möglich (ich wüsste aber nicht dass hier jemand diesen Weg gewählt hätte, dürfte imho auch mehr Aufwand sein - Adressverwaltung, statische GDT-Einträge laden und bei Codeänderung vllt. anpassen...).
Für weitere Auskünfte bitte etwas mehr Infos was du genau vorhast, und was als Grundstruktur vorhanden ist

42

OS-Design / Re: Process Emulation

« am: 22. August 2009, 19:36 »

Wenn du Programme für andere OS laufen lassen willst, schau dir an wie WINE (http://winehq.org/) das macht.

Wenn du auch Architekturgrenzen überwenden oder Befehle sperren willst, wäre ne Art JIT-Compiler eher der passende Weg - ist aber noch deutlich mehr Entwicklungsaufwand, und erfordert natürlich auch Bibliotheken um irgendwas zu machen

In beiden Fällen wäre eine Integration innen Kernel aber eher doof - bringt dir keinerlei Vorteile (jedenfalls keine die ich mir denken kann), nur mehr Risiken was Abstürze und Sicherheit anbelangt. Und auch wenns ne Anwendung ist, kanns ja ein Teil des Betriebssystems sein

43

Lowlevel-Coding / Re: Hilfe beim booten

« am: 15. August 2009, 21:23 »

Mit GRUB machst du das garnicht. Erkennen musst du das außerhalb, und dann entsprechend Einträge für GRUB in die menu.lst packen. Die Erkennung selber, ist nicht unbedingt klar - Linux-Systeme indem du ins FS schaust und nach ner Datei mit vmlinuz im Namen suchst (muss nicht funktionieren), Windows indem du Bootcode vergleichst. Aber sowas sollte eh nebensächlich sein, falls es dich wirklich interessiert, schau wie die Installer moderner Distributionen das machen.

44

tyndur / Re: Softwares fuer Tyndur schreiben

« am: 24. July 2009, 15:08 »

Die Systeme sind eigentlich relativ gleichwertig, der Unterschied besteht eher dadrin, das alles was im tyndur-repository ist auch wirklich so dazugehört und da sein sollte, wohingegen lbuilds für Portierungen gedacht ist. Natürlich kannst du aber auch via lbuilds entwickeln - imho nur umständlicher, wenn du nur unter tyndur testen willst, da du noch per Hand das Paket aufs Image kriegen musst (lässt sich umgehen, wenn es so angelegt ist dasses auch unter Linux läuft -> so ist help entstanden).
Das ewige neukompilieren ist übrigens garnicht soo schlimm, änder deinen Code und gib mal nur make test-qemu-hd ein. Er kompiliert nur geändertes wie es sich für make gehört, generiert keine neuen Makefiles wie bei einfachem make, und nen testlauf startet er dir auch direkt

45

Lowlevel-Coding / Re: Sektoren von Floppy Disk laden

« am: 05. July 2009, 23:12 »

per engl. Wikipedia (http://en.wikipedia.org/wiki/INT_13#INT_13h_AH.3D02h:_Read_Sectors_From_Drive) werden da nur 6 bit verwendet. Schonmal versucht einfach mehrmals den Code zu durchlaufen und eben bei höherem Sektor anzufangen?

46

Lowlevel-Coding / Re: Probleme RM VESA initialisierung

« am: 21. June 2009, 22:54 »

Wenn sowieso CDI eingebaut werden soll, würde ich vm86 stark empfehlen - ich experimentier momentan mit cdi-video für tyndur (momentan auf cirrus unter qemu beschränkt, nen normaler vesa-treiber wird aber auch noch gebastelt )

47

Lowlevel-Coding / Re: Probleme RM VESA initialisierung

« am: 21. June 2009, 22:46 »

Zur Korrektheit von -masm=dialect - Hab grad mal ins gcc-manual gesehen (http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options), soweit ich das verstehe kontrolliert die Option was für code der gcc ausgibt - nicht was mit dem vorhandenen Inline-ASM geschieht.

Weitere Empfehlungen,
a) Bitte nicht mit Grafik anfangen. Das wird nix.
b) Wenn schon Grafik so früh sein muss aber eh grub verwendet wird - man kann die vbe-modes schon via grub setzen lassen und inner Multiboot übergeben bekommen
c) um solche Sprünge möglichst zu vermeiden wurde vm86 entwickelt - verwenden, dann ersparst du dir auch die PM-Wiederaktivierung

Mal so btw, kommt man wirklich so einfach bis innen RM runter, oder was passiert da?

48

Lowlevel-Coding / Re: GRUB und Windows

« am: 12. June 2009, 12:38 »

Ganz genau, früher waren das mal nächtliche Builds der jeweils aktuellen Version. Name wurde seitdem nicht geändert, mittlerweile wird jede Revision gebaut, wenns keine Fehler gibt stehen die max. 15 min nach Commit zur Verfügung

Um die Subdomains kümmer ich mich gleich

Edit: Waren nur nen paar Ergänzungen. Steht alles unter Links im Tyndur-Artikel im Wiki

49

tyndur / Re: 0.3 - Ideen und Ziele

« am: 11. June 2009, 00:27 »

Zum Thema Portierung oder Neuschreiben von Spielen und so - nen Grafiktreiber ist aktuell bei mir im Umbau, manchmal kann er sogar primitiven rendern Falls sich das ganze jemand ansehen möchte, meine aktuelle Version ist noch nirgends (da es noch nicht wieder läuft seit ich angefangen hab die Kommandostreams umzubauen), aber grundsätzlich basiert das auf einer alten Patchreihe von mgottschlag und janosch, zu finden unter http://list.tyndur.org/pipermail/tyndur-devel/2008-October/thread.html (ab Patch [1/5] + cdi: Interface für Grafiktreiber).
Um das ganze mit ner aktuellen Version ans laufen zu kriegen, den vterm-Hack weglassen, inner userspace-lib in video_init den fopen() ausklammern, im cdi-video-teil get_command_buffer dahingehend anpassen das das nen vscreen erzeugt. Alternativ add_vscreen so wie es vterm machen würde in video_init aufrufen.
Wer also damit arbeiten möchte, kann dies gerne tun - die Userspace-Lib wird erstmal kompatibel bleiben, oder wenigstens kompatibel genug um weitere Portierungen minimal zu halten

50

OS-Design / Re: Doku tyndur

« am: 28. May 2009, 16:05 »

Trial & Error

Richtige Design-Dokus gibts bislang leider nicht. Wenn du was spezielles Wissen möchtest, schau einfach im IRC vorbei (oder frag hier, aber dann brauch das mit der Antwort womöglich länger ).

51

Offtopic / Re: Probleme mit CGI-Skript

« am: 09. September 2008, 17:30 »

Hm. Aus nem Browser heraus dürfte das schwierig bis unmöglich werden, da:
a) JavaScript neben Java, Silverlight und Flash (die man alle 3 nich verwenden will) die einzige Verarbeitungsmöglichkeit darstellt, aber
b) JavaScript sich die Daten für sowas nur über die AJAX/XmlHttpRequest-Schnittstelle holen kann, welche leider nur vonner gleichen Domain holt (Datendiebstahl, DoS-Attacken, ... etc. vorbeugen). Da du ja auf das .csv keinen Zugriff hast, geh ich mal davon aus das gleiche Domain entsprechend auch nicht drin ist.
--> Um Serverseitige Skripte kommst du wohl nicht herum.
Zum verarbeiten aus PHP heraus, das ist eigentlich ganz einfach. readfile("http://...."); liefert nen Array, jede Zeile der Seite als ein Arrayelement. Dannach wendest auf jedes Arrayelement nen explode($element,";") an, und bekommst nen weiteres array, jeden Wert des Datensatzes als ein Element. Die lassen sich natürlich leicht zusammenbringen, -> 2-Dimensionales Array. Weiterverarbeitung sollte dannach kein Problem mehr sein.
Oder halt alternativ doch nen Applet.... aber bitte bitte in Java, wenn sowas schon sein muss. Jeder  nicht-i386-Linuxer wird es dir danken (Flash läuft jedenfalls nur unter i386 gescheit, bis überhaupt. Gnash jetzt mal nicht mitgezählt)

52

Lowlevel-Coding / Re: SMP

« am: 23. August 2008, 10:56 »

Gegenbeispiel wäre wohl VMware, das macht SMP nur mit wenns der Host auch kann.

53

tyndur / Re: Wir suchen...

« am: 07. March 2008, 12:57 »

hängt mit dem Einsatz von dash statt bash als Standardshell zusammen, iirc. Versuch mal /bin/sh zu löschen und auf /bin/bash zu linken, dann sollte alles gehen.

54

tyndur / Re: Wir suchen...

« am: 25. February 2008, 16:01 »

Bisschen spät der Kommentar dazu, aber auch 64-bit Ubuntu geht, ohne gezielt nen crosscompiler gebaut zu haben. Wichtig sind dafür halt nur ein paar weitere Optionen, u.a. -fno-stack-protector. Sollte alles notwendige bereits im svn sein.

EDIT: Dafür machen andere Pakete ärger, mtools musst ich aus den quellen installieren damit make image funktioniert.

55

Das Wiki / Re: Sinkende Aktivität

« am: 18. February 2008, 22:46 »

Imho gibts noch was, wenn gefordert. Aber da prinzipell zu wenig Artikel für sowas aufkommen, und es sich mit dem Wiki nicht mehr lohnt... Unwahrscheinlich.

56

tyndur / Re: Wir suchen...

« am: 11. February 2008, 15:56 »

So, zu den LOST-Anwendungen, meld ich mich mal für das Hilfesystem.

57

Lowlevel-Coding / Re: APIs aber nicht über Interrupts

« am: 31. December 2007, 14:21 »

und IPC läuft meistens über feste bekannte Syscalls im Kernel, die halt Speicherbereiche entgegennehmen und anderen Prozessen irgendwie bekannt machen (bestimmte funktion aufrufen -> RPC, einfach an adresse X nen Buffer mit Nachrichten hinterlegen -> Polling...). Nötige Syscalls: Prozess finden (Name -> ID oder sowas), Nachrichtenübermittlung selbst, ggf. IPC-Handler-Routine setzen.

58

Lowlevel-Coding / Re: APIs aber nicht über Interrupts

« am: 31. December 2007, 14:18 »

IPC, oder die Variante die auch Windows verwendet. Binary enthält Liste "Die Funktionen brauch ich", OS setzt im RAM beim Programmstart dann Adressen ein. Funktionsaufruf über Pointer.

Zur weiteren Information zu Ansatz 2 kannst ja mal nach dll/PE und Import und Export-Tabellen suchen.

59

Offtopic / Re: OS dev Tree

« am: 24. November 2007, 13:10 »

Screenshots reichen zur bewertung nicht, stimmt. Ansonsten, gibt doch genügend zentrale Infos. Und mach dich bitte über die Bedeutung von "SDK" schlau. Mir fällt keine Variante ein wie man von SDK auf Dokumentation kommt. :/

60

Offtopic / Re: Suche Buch

« am: 24. November 2007, 12:53 »

sieht in DE genauso aus. und Österreich machte bei meiner letzten Informationstour auch keinen Unterschied....

ansonsten, rapidshare?