SR71B Δημοσ. 12 Δεκεμβρίου 2011 Δημοσ. 12 Δεκεμβρίου 2011 I had a dream ..... Ενα λειτουργικο συστημα single-user, single-task σαν το αρχαιο (πια) DOS .... αλλα .... με 32-bit αρχιτεκτονικη. To ξερω, το ξερω .... αφου υπαρχει το Linux , γιατι να παμε πισω στο DOS ? Ισως, γιατι μονο αυτο ειχα την τυχη να μαθω καλα και να παιδευτω. Ισως γιατι του αξιζε καλυτερη μοιρα απο το να παραμεινει (και να σαπισει) στα 16-bit !!! Oπως και να χει, ηθελα να μοιραστω αυτο το ονειρο που εχω εδω και 20 χρονια .... μαζι σας. Ενα Disk-Operating-System που να ξεκινα βλεπωντας μονο επεξεργαστη και μνημη. Ολα τα αλλα (μα ΟΛΑ ΤΑ ΑΛΛΑ) θα ηταν περιφερειακα. Ακομα και το πληκτρολογιο ! Θα μπορουσε δηλαδη να ξεκινησει ΧΩΡΙΣ πληκτρολογιο (IRQ 1) και ΧΩΡΙΣ καρτα γραφικων (IRQ 10) !!!!! Τι θα εκανε μονο με επεξεργαστη και μνημη ? Για τον χρηστη (εμας) τιποτα ! Αλλα για διαγνωστικους ελεγχους ... τα παντα ! Θα εσβηνε το συστημα και θα ξεραμε οτι η μητρικη, η μνημη, η ο επεξεργαστης ειναι για πεταμα (και δεν θα ξεκιναγαμε αντιστροφα, απο τα περιφερειακα). θα ειχε 32 interrupts. Τον ελεγχο θα ειχε παλι ο επεξεργαστης αλλα ΔΕΝ θα τσακωνε δυο περιφερειακα να χρησιμοποιουν το ιδιο interrupt. Ουτε το ρολοι θα ειχε ενα ολοκληρο interrupt, ουτε το IRQ 9 θα ηταν γεφυρα με το IRQ 2 αφαιρωντας δυο υπερπολυτιμα interrupts. Oυτε αφιερωμενα interrupts μονο για οθονη (IRQ 10) η για PS/2 ποντικι (IRQ 12) η για floppy (ΙRQ 6) η για σειρα- ϊκη θυρα (IRQ 3,4). Οποια συσκευη καλουσε ΠΡΩΤΗ θα επαιρνε εξ'ολοκληρου το αμεσως επομενο διαθεσιμο interrupt. Ολοκληρη η μνημη, πανω απο το 1 megabyte, ΔΕΝ θα ηταν σε protected mode. Αλλα σε real mode (χωρις διπλους/τριπλους ελεγχους για το ποιο προγραμμα χρησιμοποιει μια διευθυνση). Εαν ο προγραμματιστης δεν ηξερε ποιες διευθυν- σεις χρησιμοποιουνταν θα εκανε request και το λειτουργικο θα απεκλειε αυτες που χρησιμοποιουνταν (απο εφαρμογες). Εννοειται, οτι ΟΛΟΚΛΗΡΗ η μνημη μεχρι τα 4 Gigabyte (2^32 bits) θα ηταν χωρισμενη σε pages των οποιων το μεγεθος θα εδινε ο χρηστης ! Το μικροτερο 4 Byte, το μεγαλυτερο 2 Gbyte. Και η προσβαση απο τον επεξεργαστη σε διαυλο των 32-bit ..... FIXED ! Ουτε Segments ουτε Offsets και χλαπατσιμπαλλα. Να μην μπορεις να κανεις εναν πινακα μεγαλυτερο απο 65535 bytes και να κοπανιεσαι με δεικτες κλπ. Το BIOS, δεν θα εμπαινε μπαστακας στην διευθυνση F000:0000 ! Aλλα οπου το εστελνε το λειτουργικο (η ο προγραμματιστης). Το λειτουργικο θα διαβαζε ΕΚ ΝΕΟΥ την νεα διευθυνση του BIOS και αναλογως θα κανονιζε την λειτουργια του ! Το ιδιο και το BIOS της καρτας γραφικων (C000) η του controller δισκου, της καρτας ηχου, κλπ, κλπ. Ο-Χ-Ι να απομονωνονται 384 K με το ετσι θελω. Χρησιμοποιουνται δεν χρησιμοποιουνται ! Τα firmware, ΟΛΑ, θα πηγαιναν στην αρχη της DRAM. Και ΜΕΤΑ .... ολα τα αλλα, λειτουργικο και εφαρμογες. Τακτοποιημενα εξ,αρχης ! Οχι ... κορναρισματα και καραμπολες ! Οι θυρες επεκτασης θα ηταν οσες αντεχε η μητρικη (και η τροφοδοσια της). Οχι να μπορει να δωσει 8 θυρες (η μητρικη) και το λειτουργικο να βλεπει ΜΟΝΟ 4 (αντε 6, στην καλυτερη περιπτωση). Ολες οι θυρες θα ηταν στο ευρος διαυλου του επεξεργαστη. Ουτε μισες, ουτε διπλασιες. Ολες 32-bit. Η συχνοτητα τους θα οριζονταν απο το περιφερειακο που ηταν καρφωμενο. Μπορει να ηταν παραπανω απο την συχνοτητα της CPU αλλα θα επεφτε στην συχνοτητα της CPU μολις εβγαινε προς την μητρικη. Απο ενα απλο clock multiplier/divider ! Ετσι, η επεξεργασια ΜΕΣΑ στην καρτα επεκτασης θα ηταν ΑΥΤΗ που θα επιθυμουσε ο κατασκευαστης (VGA, IDE/SCSI, Mouse, Joystick, Sound, κλπ. κλπ). OXI να μπορει η καρτα και ο επεξεργαστης να την φρεναρει μεσα στο γηπεδο της !!! Καθε σκληρος δισκος θα ειχε ΜΕΤΑΒΛΗΤΟ cluster, που θα αποφασιζε το λειτουργικο μολις γινοταν το πρωτο setup. Ουτε μεγαλυτερο απο 4Κ ουτε μικροτερο απο 4Κ. Oτι διαβασει στην γεωμετρια του δισκου στο BIOS, το λειτουργικο ! Εαν δει εναν πολυ μεγαλο δισκο, θα τον σπασει σε μεγαλα κομματια, ενα δει εναν μεσαιο σε μικρα και εναν μικρο σε ακομα μικροτερα (αν και δεν ξερω ποιο θα ηταν το βελτιστο μεγεθος ανα περιπτωση). Λαχταρω να γραψω τοσα πολλα, για την εποχη που με παιδεψε τοσο πολυ αλλα και μου ανοιξε τα ματια γυρω απο αυτο που λεμε ... PC ! Ομως θα θελα ... να μιλησετε εσεις ! Οι, καπως παλιοτεροι .... που γνωριζετε οτι, εκεινη την Ιουρασικη περιοδο μπορει να ΜΗΝ ειχαμε ταχυτητα αλλα σιγουρα ΕΙΧΑΜΕ ελεγχο ... (και να μην απαντησετε .... ευχαριστω για τον χωρο που μου διαθεσατε !)
Directx Δημοσ. 12 Δεκεμβρίου 2011 Δημοσ. 12 Δεκεμβρίου 2011 Κοίταξε, μετά το MS-DOS 6.22 (ας μην μιλήσω για το DR-DOS) υπήρξαν αρκετοί που έλπιζαν ότι η MS θα προσέφερε ένα 32bit DOS (Native EMS/XMS, δίχως HIMEM.SYS/Memmaker κλπ ), τον καιρό εκείνο ήθελαν αυτό να είναι το 7.0, τελικά ο κόσμος είχε ήδη κάνει την επιλογή του με τα Windows 3.1 και 3.11 for Networks οπότε όλα αυτά τελείωσαν θεαματικά με την έλευση των Windows 95, σε επιχειρισιακό περιβάλλον η MS είχε ήδη αποφασίσει την προώθηση των NT διαβλέποντας την δυναμική είσοδο των GUI παντού και έτσι η υπόθεση έλαβε άδοξο τέλος -ήταν εκτός κλήματος.
migf1 Δημοσ. 12 Δεκεμβρίου 2011 Δημοσ. 12 Δεκεμβρίου 2011 http://freedos-32.sourceforge.net/ Και δείτε οπωσδήποτε και το LEAN file-system (που θα χρησιμοποιεί το FreeDOS 32).
SR71B Δημοσ. 13 Δεκεμβρίου 2011 Μέλος Δημοσ. 13 Δεκεμβρίου 2011 Καταρχην, να ευχαριστησω που υπηρξαν δυο ατομα διαβασαν το ποστακι μου. Περιμενα να παει ... απατο. Migf1 Διαβασα το λινκ, και μπορω να πω οτι εντυπωσιαστηκα. Ειχα ακουσει για το FreeDOS αλλα υπεθετα οτι ηταν ενας ακομα κλωνος για DOS. Βεβαια ... θα κρατησω μικρο καλαθι. Πρωτον, διοτι οταν πηγα να χρησιμοποιησω κωδικα σε protected mode, μεσα απο ενα προγραματακι σε Borland Pascal, και μαλιστα σε μνημη DPMI (Int 21) το προγραμματακι ετρεχε ΤΟΥΛΑΧΙΣΤΟΝ στην μιση ταχυτητα. Moνο σε Real mode, η μνημη αποδιδει ολοκληρη την ταχυτητα της (οχι οτι η σημερινη μνημη δεν τρεχει αρκετα γρηγορα, αλλα, λεμε ...), Δευτερον, οταν αποφασιζεις να μεταφερεις τον πινακα διακοπων (interrupt context) μεσα στον επεξεργαστη (thread context) μπορει να κερδιζεις σε ταχυτητα αλλα χανεις σε ... σταθεροτητα. Ορισμενα πραγματα (οπως ο σκληρος δισκος η η καρτα γραφικων) υπακουουν ΤΕΛΕΙΑ σε interrupts και ΗΜΙΤΕΛΩΣ σε αμεσες κλησεις της CPU μεσα απο εναν "διαφορετικο" πινακα διακοπων (λεγε με, thread priority). Αλλα, ας μην ειμαι αφοριστικος .... ισως κατι καλυτερο ξερουν αυτοι που χτιζουν το FreeDOS (σιγουρα ξερουν). Δεν μου αρεσε που το FAT ειναι φορτωμενο με LongFileNames. Οποιος χρησιμοποιει DOS ξερει οτι δουλευει στην Σπαρτη οχι στην Αθηνα. Μου αρεσε το LEAN απο την αποψη οτι υποστηριζει μεγαλες κατατμησεις και πολυ μεγαλα αρχεια αλλα γραφουν καπου "Any design choices have gone in the direction of the greatest simplicity rather than performance". Mα γιατι ? Η απλοτητα συνηθως συνοδευεται απο ταχυτητα και η πολυ- πλοκοτητα απο αργοπορια. Τι να εννοει αραγε ο "ποιητης" ? Απορησα εκει που διαβασα οτι το FAT32, εν ετει 2011, ειναι .... ΑΚΟΜΑ πατενταρισμενο ! DirectX Τα DOS των Win9x ηταν υποβοηθητικα DOS. Oσοι δουλευαν DOS, απο πιο πριν, το γνωριζαν αυτο. Μονο τα WfW 3.11 θεωρουσαν οτι ο χρηστης μπορει να δουλεψει χωρις παραθυρα. Απο κει και μετα .... ολα εγιναν παραθυρα. Η κονσολα εντολων ηταν υπο διωγμο (υπαρχουν, ακομα και σημερα, ορισμενα πραγματα που γινονται πολυ γρηγοροτερα με εντολες απο οτι με copy-paste !) Οπως και να χει, τα παραθυρα ΕΙΝΑΙ βημα μπροστα (περιμενες να πω το αντιθετο , ε ?) ΟΜΩΣ, η γραμμη εντολων ειναι αναντικαταστατη για ΠΛΗΡΗ ΕΛΕΓΧΟ μιας συγκεκριμενης εργασιας (οπως το φορτωμα οδηγων ΜΕΤΑ την φορτωση του λειτουργικου) η την συγγραφη ενος προγραμματος σε γλωσσα προγραμματισμου που ΔΕΝ παλευει με το ποσα παραθυρα ειναι ανοιχτα (γιατι εχει μονο ενα παραθυρο, μονο μια διεργασια και μονο εναν επεξεργαστη !!!) Ακομα και η κονσολα εντολων των NT, στην αρχη, δεν ειχε ΚΑΝ το diskpart !!!! Το μονο εργαλειο που βλεπει και διαχειριζεται partitions εκτος παραθυρων (και το κανει και πολυ καλα). Γιατι ? Για να μην συνηθιζει ο καταναλωτης να εχει ΕΛΕΓΧΟ του λειτουργικου σε νευραλγικα σημεια του. Δεν μιλαω για το τελευταιο DOS 8.00 (των Millenium) που δεν σε αφηνε να μπουταρεις στον δισκο χωρις να μπεις πρωτα στα Windows. O διωγμος του Διοκλητιανου !
migf1 Δημοσ. 13 Δεκεμβρίου 2011 Δημοσ. 13 Δεκεμβρίου 2011 Έχω την εντύπωση πως το FreeDOS-32 γράφεται from scratch και όχι ως extension του FreeDOS, αλλά δεν είμαι σίγουρος (είμαι σχεδόν σίγουρος). Οπότε αισιοδοξούμε ΥΓ. Αν έχεις πρόσβαση σε Linux/Unix και δεν το έχεις δοκιμάσει, δοκίμασε το tc-shell (tcsh)... μακράν το καλύτερο shell που έχει πέσει ποτέ στα χέρια μου (υπάρχει κι ένα port για Windows, αλλά δυστυχώς είναι κουτσουρεμένο).
Directx Δημοσ. 13 Δεκεμβρίου 2011 Δημοσ. 13 Δεκεμβρίου 2011 (επεξεργασμένο) DirectX Τα DOS των Win9x ηταν υποβοηθητικα DOS. Oσοι δουλευαν DOS, απο πιο πριν, το γνωριζαν αυτο. Μονο τα WfW 3.11 θεωρουσαν οτι ο χρηστης μπορει να δουλεψει χωρις παραθυρα. Μα δεν διαφωνώ απλά υπενθυμίζω ότι πριν παμε στα 95 οι παλιοί DOSαδες περίμεναν ότι ύστερα από την έκδοση 6 θα ακολουθούσε η 7 με πλήρη υποστήριξη 32bit όπως υποθέτω ότι θυμάσαι από τις φήμες των περιοδικών εκείνης της εποχής. Αλλά τελικά αυτό δεν συνέβη ποτέ καθώς ακολούθησαν τα 95 βάζοντας ταφόπλακα στο DOS. Αυτό έγραψα, δεν είπα πουθενά ότι το 7 που προσέφεραν κατ ευφημισμό τα 95 ήταν τίποτε το σοβαρό, ένα απλό 6 με lfn και αρκετά tweaks για να τρέχει ομαλά παράλληλα με τα 95 ήταν. Όσον αφορά τα 3.11, λειτουργούσαν ως μάσκα του DOS και φυσικά δεν είχαν αυθύπαρκτο μηχανισμό διαχείρισης αρχείων σε χαμηλό επίπεδο, όπως όλα τα 16αρια Windows, η αναφορά μου αφορούσε το γεγονός ότι πρόκειται για προϊόντα ορόσημα τα οποία αποτέλεσαν την χαριστική βολή στο γέρικο DOS. Απο κει και μετα .... ολα εγιναν παραθυρα. Η κονσολα εντολων ηταν υπο διωγμο (υπαρχουν, ακομα και σημερα, ορισμενα πραγματα που γινονται πολυ γρηγοροτερα με εντολες απο οτι με copy-paste !) Οπως και να χει, τα παραθυρα ΕΙΝΑΙ βημα μπροστα (περιμενες να πω το αντιθετο , ε ?) ΟΜΩΣ, η γραμμη εντολων ειναι αναντικαταστατη για ΠΛΗΡΗ ΕΛΕΓΧΟ μιας συγκεκριμενης εργασιας (οπως το φορτωμα οδηγων ΜΕΤΑ την φορτωση του λειτουργικου) Φυσικά υπάρχουν πράγματα που γίνονται απλούστερα με την κονσόλα για αυτό εξακολουθεί να προσφέρεται, δεν είναι θέμα έλεγχου όμως (έτσι όπως το θέτεις εσύ –καταλαβαίνω το πνεύμα σου) αλλά θέμα ευχρηστίας καθώς υπάρχουν πολλά που επίσης γίνονται δυσκολότερα ή καθόλου μαζί της. Βλέπεις όμως, σε άλλο κοινό απευθύνονταν τα PC την δεκαετία του 80 και σε άλλο του 90 και του 2000 κλπ και εδώ είναι το κλειδί το ζητήματος. Θυμάσαι νομίζω ότι το πρώτο σε χρήση πρόγραμμα επί DOS ήταν το Norton Commander! Ήδη από τότε ποίος καθόταν να ασχοληθεί με την κονσόλα για καθημερινές εργασίες; Όχι ότι δεν συνέβαινε αλλά για ουσιαστική χρήση όλοι πηγαίναμε σε NC και στους κλώνους του, από τότε είχε δείξει που πήγαινε η αγορά και γιατί διώχθηκε η Κονσόλα. Τώρα για το πότε φορτώνει ένας οδηγός κλπ, ε.. μεταξύ μας και επί DOS μας ένοιαζε μόνο όταν προσπαθούσαμε να γλιτώσουμε μερικά KB από τα 640KB (πολύ λιγότερα στην πραγματικότητα) για να πάρει μπρος το παιχνίδι ή εφαρμογή που χρειαζόμασταν και να καταφέρει να φορτώσει είτε το ίδιο είτε τουλάχιστον ο DOS Extender του και να δει τα υπόλοιπα MB μας (αρχικά 2 και ύστερα συνήθως 4 ), εκεί αλλάζαμε τα φώτα ειδικά στο CONFIG.SYS με Multiboot options, DEVICEHIGH, κατάσταση που δεν έλεγες σε καμία περίπτωση ιδανική. Γενικά τα γνωρίζεις όλα αυτά. η την συγγραφη ενος προγραμματος σε γλωσσα προγραμματισμου που ΔΕΝ παλευει με το ποσα παραθυρα ειναι ανοιχτα (γιατι εχει μονο ενα παραθυρο, μονο μια διεργασια και μονο εναν επεξεργαστη !!!) Αυτό είναι θέμα γλώσσας, πακέτου προγραμματισμού κλπ, αφού γνωρίζεις Turbo Pascal μπορείς να πας άνετα σε Delphi σήμερα, θα κάνεις όμως τον κόπο να μάθεις Message/Event Driven & GUI programming, δεν γίνετε διαφορετικά (ο επεξεργαστής πάντως δεν θα παραπονεθεί).. Ακομα και η κονσολα εντολων των NT, στην αρχη, δεν ειχε ΚΑΝ το diskpart !!!! Το μονο εργαλειο που βλεπει και διαχειριζεται partitions εκτος παραθυρων (και το κανει και πολυ καλα). Γιατι ? Για να μην συνηθιζει ο καταναλωτης να εχει ΕΛΕΓΧΟ του λειτουργικου σε νευραλγικα σημεια του[..] Δεν θα έλεγα ότι το Disk Partitioning είναι μια διαδικασία για όλους τους καταναλωτές. Δεν ήταν ούτε επί εποχής DOS, θυμήσου πόσοι αναγνώστες περιοδικών στέλνανε γράμματα ζητώντας αγωνιωδώς βοήθεια όταν κατέστρεφαν τα partition τους (ή φόρμαραν κατά λάθος, λάθος δίσκο κλπ) και έχαναν τα δεδομένα τους από τέτοιες δουλειές και πόσα άρθρα κυκλοφορούσαν για να τους τις εξηγήσουν κλπ. Στο τέλος οι άνθρωποι κουραζόντουσαν και έψαχναν κανέναν φίλο "κομπιουτερά" για να τους κάνει την δουλειά. Βλέπεις κάποια πράματα δεν είναι για τον "μέσο χρήστη" (πολύ δε περισσότερο η επέμβαση σε νευραλγικά σημεία του Λ.Σ.) ούτε τότε ούτε τώρα. Ύστερα και τότε και τώρα, οι περισσότεροι δεν ήθελαν και δεν θέλουν να "συνηθίσουν" ή πιο σωστά να μάθουν περισσότερα από όσα χρειάζονται για την δουλειά τους με το μηχάνημα. Όποιος "θέλει" αλλά και "μπορεί" όμως (αυτό το ξεχνάμε συνήθως) μαθαίνει, αυτό είναι διαχρονικό αξίωμα! Επεξ/σία 13 Δεκεμβρίου 2011 από Directx
SR71B Δημοσ. 13 Δεκεμβρίου 2011 Μέλος Δημοσ. 13 Δεκεμβρίου 2011 MigF1 Πραγματικα αισιοδοξουμε ! Μακαρι να τελεσφορησει η προσπαθεια ... και "να μπει με το δεξι" ! DirectX Οτι εγραψα ηταν μομφη (και πικρα) απεναντι στην Microsoft. Συγνωμη, εαν φανηκε κατι αλλο. Δεν ηταν προθεση μου ! Tα CONFIG.SYS (και τα MemMaker και ιστοριες για αγριους) ΟΝΤΩΣ ηταν απιστευτες ταλαιπωριες. Ομως, οταν κατορθωνες να αποκτησεις ελεγχο δεν υπηρχε αλλη περιεργη διεργασια να τρεχει στο παρασκηνιο, αφου παρασκηνιο δεν υπηρχε (paging, multi-tasking, multi-threading, και 20 DLL μονο για τον Kernel). Εαν κουραστηκα με το DOS , ΕΧΩ ΠΑΡΑΙΤΗΘΕΙ ΜΕ ΤΑ WINDOWS !!! Αυτο κατι λεει .... (και δεν ειμαι ανθρωπος που τα παραταει ευκολα ) Δεν εμεινα στην Turbo Pascal, οταν μπηκα στα Windows. Υπαρχει ενας κλωνος Pascal ονοματι Free Pascal που μεταφραζει πολυ σωστα TurboPascal Code. Ομως ... ΕΧΕΙ και τα ψεγαδια του ! Ενα προγραμματακι μου που σχεδιαζε ενα mandelbrot fractal τρεχει δυο φορες πιο αργα σε Free Pascal. Οταν εβγαλα την PutPixel απο τον κωδικα, εγινε δυο φορες πιο γρηγορο. Που σημαινει οτι δεν φταιει το execution time του επεξεργαστη αλλα η μεταφραση της PutPixel απο το GDI των Windows (για DirectX, ουτε λογος να γινεται !). Συμπερασμα .... ΜΟΝΟ ενα ΑΥΤΟΝΟΜΟ λειτουργικο μπορει να φερει την ταχυτητα και αξιοπιστια του κωδικα μου. Οπως το FreeDOS-32 που επισημανε ο Migf1 ! Κατα τα αλλα, ο Norton Commander ηταν ενα shell που προσφερε το αυτονοητο : δυο παραθυρα για να βλεπεις ΠΟΥ βρισκεται ενα αρχειο και ΠΟΥ θελεις να το πας. Δεν μπορω να καταλαβω γιατι ο Windows Explorer επρεπε να εχει ΕΝΑ παραθυρο (με μια δενδρικη κατανομη αριστερα του). Αυταποδεικτα, ΔΕΝ σχεδιαστηκε για αντιγραφη αρχειων αλλα για ... casual browsing ! Τωρα χρησιμοποιω τον Total Commander που εχει τουλαχιστον δυο παραθυρα αλλα .... ποιος ηταν ο ΠΡΩΤΟΔΙΔΑΞΑΣ !!! Το partitioning ΟΝΤΩΣ δεν ηταν για τον ευκαιριακο χρηστη. Ομως, εκεινες τις εποχες, πριν το 1996, το λειτουργικο σε εβαζε σε μια φιλοσοφια σκεψης που, ναι μεν ηταν εξαιρετικα κρυπτογραφικη και σπαρτιατικη αλλα, απεδιδε καρπους σε ΕΛΕΓΧΟ. ΠΛΗΡΗ ΕΛΕΓΧΟ. Aντε να κανεις format σημερα χωρις Setup CD ... Την εποχη εκεινη, ηταν τρια βηματα : Debug g=c800:5 (low-level) Fdisk /MBR (με το καταλληλο partitioning) και Format C: /U /S Κρυπτογραφικα ? Σιγουρα ! Δυσκολα ? Σιγουροτατα ! ΑΛΛΑ ... ΑΥΤΑ ΗΤΑΝ. Tρια βηματα ... οποιος ειχε χρονο και ορεξη μπορουσε να γινει κυριαρχος του PC του. Και οχι συνιδιοκτητης με το τμημα marketing της Microsoft. Aς μην μιλησω, τι ΡΙΣΚΟ ειναι να κανεις BIOS update μεσα απο Windows .... και το διαφημιζουν ως safe procedure ολες οι εταιριες μητρικων (να τραβας τα μαλλια σου, δηλαδη). Ας το κανουν, ενω εκεινη την στιγμη να κανει paging καποιο ξεχασμενο DLL απο την μνημη στον δισκο !!! (οτι γραφω, ΔΕΝ ειναι για να σε βαλω σε θεση αμυνας .... πικρα ειναι !)
migf1 Δημοσ. 13 Δεκεμβρίου 2011 Δημοσ. 13 Δεκεμβρίου 2011 ... Δεν εμεινα στην Turbo Pascal, οταν μπηκα στα Windows. Υπαρχει ενας κλωνος Pascal ονοματι Free Pascal που μεταφραζει πολυ σωστα TurboPascal Code. Ομως ... ΕΧΕΙ και τα ψεγαδια του ! Ενα προγραμματακι μου που σχεδιαζε ενα mandelbrot fractal τρεχει δυο φορες πιο αργα σε Free Pascal. Οταν εβγαλα την PutPixel απο τον κωδικα, εγινε δυο φορες πιο γρηγορο. Που σημαινει οτι δεν φταιει το execution time του επεξεργαστη αλλα η μεταφραση της PutPixel απο το GDI των Windows (για DirectX, ουτε λογος να γινεται !). ... Υποθέτω είσαι ήδη εξοικειωμένος με τα optimization flags της Free Pascal: http://freepascal.or...g/progse49.html. Ρίξε όμως και μια ματιά εδώ: http://wiki.freepasc...ct_pixel_access (σε περίπτωση που δεν το ξέρεις ήδη δηλαδή)... και για μετρήσεις εδώ: http://wiki.freepascal.org/Profiling (το οποίο υποθέτω το γνωρίζεις ήδη).
Directx Δημοσ. 13 Δεκεμβρίου 2011 Δημοσ. 13 Δεκεμβρίου 2011 Δεν εμεινα στην Turbo Pascal, οταν μπηκα στα Windows. Υπαρχει ενας κλωνος Pascal ονοματι Free Pascal που μεταφραζει πολυ σωστα TurboPascal Code. Ομως ... ΕΧΕΙ και τα ψεγαδια του ! Ενα προγραμματακι μου που σχεδιαζε ενα mandelbrot fractal τρεχει δυο φορες πιο αργα σε Free Pascal. Οταν εβγαλα την PutPixel απο τον κωδικα, εγινε δυο φορες πιο γρηγορο. Που σημαινει οτι δεν φταιει το execution time του επεξεργαστη αλλα η μεταφραση της PutPixel απο το GDI των Windows (για DirectX, ουτε λογος να γινεται !). Συμπερασμα .... ΜΟΝΟ ενα ΑΥΤΟΝΟΜΟ λειτουργικο μπορει να φερει την ταχυτητα και αξιοπιστια του κωδικα μου. Οπως το FreeDOS-32 που επισημανε ο Migf1 ! Λοιπόν αυτό το πρόβλημα υπάρχει και σε C++ Builder (είναι η εκδοχή της Delphi σε C++) όταν δοκιμάζεις να επεξεργαστείς τα pixels της εικόνας μέσο του TCanvas->Pixels[][] (σα να λέμε Get/PutPixel) με αποτέλεσμα η ταχύτητα να πέφτει ραγδαία, μια λύση σε αυτό είναι η απευθείας πρόσβαση στα δεδομένα του Bitmap. Σε C++ Builder & Delphi αυτό γίνεται μέσο του ScanLine property πια αλλά είναι πιο περίπλοκο από τα Get/PutPixel ή το TCanvas->Pixels[][] (δες αν έχει κάτι ανάλογο η FreePASCAL). *Δυστυχώς το GDI δεν σχεδιάστηκε για ταχύτατα γραφικά αλλά για γραφικά εφαρμογών και ομογενοποίηση της εκτύπωσης είτε στην οθόνη είτε στον εκτυπωτή ή σε οποιαδήποτε άλλη συμβατή συσκευή. Κατα τα αλλα, ο Norton Commander ηταν ενα shell που προσφερε το αυτονοητο : δυο παραθυρα για να βλεπεις ΠΟΥ βρισκεται ενα αρχειο και ΠΟΥ θελεις να το πας. Δεν μπορω να καταλαβω γιατι ο Windows Explorer επρεπε να εχει ΕΝΑ παραθυρο (με μια δενδρικη κατανομη αριστερα του). Αυταποδεικτα, ΔΕΝ σχεδιαστηκε για αντιγραφη αρχειων αλλα για ... casual browsing ! Τωρα χρησιμοποιω τον Total Commander που εχει τουλαχιστον δυο παραθυρα αλλα .... ποιος ηταν ο ΠΡΩΤΟΔΙΔΑΞΑΣ !!! Το Total Commander το χρησιμοποιεί χρόνια τώρα ένας φίλος μου καθώς δεν χωνεύει καθόλου τον File Explorer, εμένα ο Explorer με ξένισε αρχικά καθώς είχα συνηθίσει την διαχείριση αρχείων σε στυλ NC (OFM) αλλά μετά το συνήθισα. Ουσιαστικά ο File Explorer θυμίζει πολύ το "DOS SHELL" και τον File Manager των 3.1(&11). Πάντως πριν καιρό σκεφτόμουν να γράψω ένα NC clone σε C#, αλλά ύστερα κάπου έχασα το ενδιαφέρον μου (αφού υπάρχει ο TC), πάντως μιας και το έφερε η κουβέντα ιδού: http://www.youtube.com/watch?v=1hPXUXkcsNg Δεν είναι ούτε καν alpha, δουλεύει μόνο η πλοήγηση στο FS και εν μέρει το Command Line Prompt, δεν έχουμε πλήκτρα & μενού, οπότε.. Μπορεί κάποια μέρα να το συνεχίσω. . . Υ.Γ. Για τους φίλου μας που δεν πρόλαβαν τα OFM, ας δουν εδώ.
migf1 Δημοσ. 13 Δεκεμβρίου 2011 Δημοσ. 13 Δεκεμβρίου 2011 Λοιπόν αυτό το πρόβλημα υπάρχει και σε C++ Builder (είναι η εκδοχή της Delphi σε C++) όταν δοκιμάζεις να επεξεργαστείς τα pixels της εικόνας μέσο του TCanvas->Pixels[][] (σα να λέμε Get/PutPixel) με αποτέλεσμα η ταχύτητα να πέφτει ραγδαία, μια λύση σε αυτό είναι η απευθείας πρόσβαση στα δεδομένα του Bitmap. Σε C++ Builder & Delphi αυτό γίνεται μέσο του ScanLine property πια αλλά είναι πιο περίπλοκο από τα Get/PutPixel ή το TCanvas->Pixels[][] (δες αν έχει κάτι ανάλογο η FreePASCAL). ... Νομίζω είναι το link που του παρέθεσα παραπάνω ΥΓ. Αν το shell είναι powerful (που το DOS ποτέ δεν ήταν, το PowerShell πολύ καλύτερο) ούτε καν OFM δεν χρειάζεται κανείς
Directx Δημοσ. 13 Δεκεμβρίου 2011 Δημοσ. 13 Δεκεμβρίου 2011 Νομίζω είναι το link που του παρέθεσα παραπάνω Yeap! Επικεντρώθηκα στην απάντηση που μου έδωσε ο φίλος SR71B οπότε δεν το είδα ΥΓ. Αν το shell είναι powerful (που το DOS ποτέ δεν ήταν, το PowerShell πολύ καλύτερο) ούτε καν OFM δεν χρειάζεται κανείς Σκληροπυρηνικός!!
migf1 Δημοσ. 13 Δεκεμβρίου 2011 Δημοσ. 13 Δεκεμβρίου 2011 ... Σκληροπυρηνικός!! Εντάξει, όλα χρειάζονται Υπάρχουν υπέρ και κατά και στα μεν και στα δε. Απλώς το command-line είναι πολύ υποτιμημένο, όπως πολύ καλά γνωρίζεις είμαι σίγουρος κι εσύ. Ένα πρόχειρο παράδειγμα που μου έρχεται είναι debugging με gdb χωρίς γραφικό front-end, παρά μόνο για τον κώδικα... συνήθως τελειώνεις το debugging ταχύτερα από το αν το έκανες με GUI
Directx Δημοσ. 13 Δεκεμβρίου 2011 Δημοσ. 13 Δεκεμβρίου 2011 [..]Ένα πρόχειρο παράδειγμα που μου έρχεται είναι debugging με gdb χωρίς γραφικό front-end, παρά μόνο για τον κώδικα... συνήθως τελειώνεις το debugging ταχύτερα από το αν το έκανες με GUI Χμ.. προσωπικά πάντα προτιμούσα τους GUI debuggers (έστω και σε text-mode) από την εποχή ακόμα του αρχαίου MS-CodeView.. ..βεβαίως γούστα είναι αυτά, οπότε κάθε άποψη σεβαστή.
SR71B Δημοσ. 13 Δεκεμβρίου 2011 Μέλος Δημοσ. 13 Δεκεμβρίου 2011 ΟΧΙ, Migf1 ... δεν γνωριζα ολα αυτα τα optimization flags. ΣΕ ΕΥΧΑΡΙΣΤΩ τα δεοντα, ομως ! Την Free Pascal, την χρησιμοποιω ευκαιριακα. Εχω ενα καθαρο DOS PC (Pentium 166 MMX, Matrox Millennium PCI, 64 MB DRAM και Conner 420 MB) ΜΟΝΟ για την Turbo Pascal !!! Αλλα, βαριεμαι να το βγαζω και να το βαζω στο ραφι του, καθε φορα που με πιανει νοσταλγια (και παραγωγικη διαθεση) οποτε ανατρεχω στον κλωνο (Free Pascal) μεσα απο DOSbox. Iσως εαν απεφευγα το DOSbox, η ταχυτητα στην PutPixel να ανεβαινε κατιτις, ποιος ξερει .... Το μονο που πειραζα ηταν το target για τον επεξεργαστη μου (αφου ειναι ο παλιος 32-bit AMD Athlon XP 3200). Απο κει και περα, ολα οσα διαβασα στα link ειναι πολυ ελπιδοφορα ΑΛΛΑ .... θα μπορεσω να εχω την ταχυτητα της Turbo Pascal σε καθαρο DOS .... ??? Ειδα και εκτενη χρηση συνολων (sets) για bitmap drawing. Απο την μικρη μου εμπειρια ΟΤΙΔΗΠΟΤΕ χειριζεται sets υποτριπλασιαζει την ταχυτητα του (ολοι αυτοι οι δεικτες και οι αναφορες σε αλλα κομματια μνημης ριχνουν την ταχυτητα ανυποφορα κατω). Εχω μια ρουτινα για Pixel drawing απο το ηρωικο περιοδικο Pixel (το θυμαστε ?) η οποια, ναι μεν ειναι γρηγορη (ακομα και σε 8088) αλλα ειναι μονο για 256Κ VGA (δηλαδη, 800 x 600 x 16 χρωματα). Αμα θελετε την παραθετω onpost .... αλλα προειδοποιω .... ειναι σε assembly ! DirectX Καταρχην, τι ειναι OFM ? (εξαιρετικο το demo απο το NC clone σου ! πως χειριζεσαι τα LFN ?) Δευτερον, ΔΕΝ γνωριζω C++ .... !!! Oυτε, εξ'όψεως ! Μονο τις αγκυλες ξερω τι κανουν ! Ειναι λιγο ακαταλαβιστικα ολα αυτα περι TCanvas και απευθειας προσβαση σε bitmap. Η μνημη της καρτας γραφικων ειναι, ετσι και αλλιως, ενα Bitmap. Ετσι δεν ειναι ? Γιατι να χρησιμοποιησω ενα mask αφου η καρτα ειναι ενα array απο bytes (η words) ? Εχω μαθει να γραφω ΑΠΕΥΘΕΙΑΣ στην περιοχη A000:0000 και να παιζω με τους δεικτες SI και DI στα ports 03CE και 03CF ωστε να παιξω με τα χρωματα της VGA (16 χρωματα μονο). Mε ΕΞΑΙΡΕΤΙΚΑ μεγαλη δυσκολια κατορθωσα να φτιαξω μια PutPixel που να δουλευει σε VESA 1280 x 1024 x 256 χρωματα. Που στα κομματια να ξερα οτι η μνημη μιας VGA δεν ειναι χωρισμενη μονο σε bitplanes (χρωματων) αλλα και banks (που δεν μπορουσαν να ξεπερασουν τα 64K) ? Τωρα, ολα αυτα ειναι προιστορια, γιατι η μνημη ειναι flat για τους συγχρονους επιταχυντες. Πανε και γραφουν/διαβαζουν οπου θελουν, χωρις ΔΙΟΔΙΑ ! Ομως .... οι σημερινοι επιταχυντες ειναι δεκα ταξεις μεγεθους σε ευφυια απο τους παλιους VGA controllers. Τι να συγκρινουμε ? Αστο καλυτερα ..... Δεν ηξερα οτι το GDI αναλαμβανε και κλησεις στον εκτυπωτη ! Αυτο νομιζα οτι το εκανε το LPT.VXD. Αλλα να μην το παιζω ξερολας ! Δεν ξερω. Συγχαρητηρια για το NC clone σου, και παλι. Σε τι text mode τρεχει ? Εχω την εντυπωση οτι ειναι 80 x 30 ... και οχι 80 x 25 ! Που παει το tab εκει που πατας συνεχεια tab δεξια ? Το εχασα λιγο !
Προτεινόμενες αναρτήσεις
Δημιουργήστε ένα λογαριασμό ή συνδεθείτε για να σχολιάσετε
Πρέπει να είστε μέλος για να αφήσετε σχόλιο
Δημιουργία λογαριασμού
Εγγραφείτε με νέο λογαριασμό στην κοινότητα μας. Είναι πανεύκολο!
Δημιουργία νέου λογαριασμούΣύνδεση
Έχετε ήδη λογαριασμό; Συνδεθείτε εδώ.
Συνδεθείτε τώρα