Hi, ich bins jetzt beim kapitel hardware-nahe Programmierung unter DOS doch dafür brauche ich einen anderen Compiler: /* Hinweis: Es muss ein DOS-Compiler verwendet werden. * * (z.B. der GNU-Compiler fuer DOS auf der CD) */ Das Problem der auf der CD ist für ein 32bit Betriebsystem ich habe aber mittlerweile windows 7 64bit Pro und beim versuch zu installieren meldet er einen fehler (siehe screen). Ich habs gegoogelt und hab das hier gefunden http://gcc.gnu.org/ aber auf der Seite blick ich net durch alles so durcheinander und auch bei der suche GNU 64 bit hatte ich kein Glück . Also meine Frage weiß jemand wo man diesen Compiler für 64 bit windows 7 herbekommt und eine ausführliche Anleitung wie man es installiert und startet ich habe mit solchen compilern überhaupt keine Erfahrung hab bisher mit visual studio gearbeitet.
Angehängte Dateien:
-
screen.jpg
56 KB
die 64Bit version kann doch auch alle 32Bit programm starten, die Meldung auf den Screenshot schein ja auch von unzip kommen und nicht von Installer. Versuche doch mal die Datein anders zu entpacken.
Der Digital Mars Compiler kann Code für 16-Bit DOS erzeugen. Ist kostenlos verfügbar.
GCC ist ein Compiler für GNU/Linux, unter Windows spielt der im Sandkasten (Cygwin, MinGW). Wenn der Code für Windows-kompatible erzeugen soll, arbeitet der bestenfalls als Crosscompiler. Versuch mal nicht, den GCC nackt zu installieren, sondern ackere dich durch MinGW durch. <Sarkasmus> DOS ist tot, die Beerdigung war vor gut zehn Jahren! </Sarkasmus>
das letzte bild sagt doch alles, Windows7 (32 oder 64bit) kann keine 16Bit programme mehr ausführen. Dann wirst du wohl mit einem Cross-Compiler arbeiten müssen. Aber Wozu das ganze? Hardware nahe DOS Programmierung ist bestimmt schon seit 10 Jahren veraltet. Wenn es aber unbedingt sein muss, kannst du dir ja eine VM aufsetztn und dort drin DOS installieren dort läuft bestimmt auch der Compiler.
Also würdest du empfehlen das kapitel einfach zu überspringen? schade ich hatte mich auf das kapitel gefreut ich suche schon lange ein buch das Hardwarenahe programmierung unter C behandelt aber das war wohl wieder nix
Ich würde es nicht überspringen, sondern in gescheitem Umfeld machen. Installier dir auf eine Extrapartition oder einen USB-Stick BSD, also ein UNIX-System. Das läuft problemlos mit 64bit und du kannst deine hardwarenahe Programmierung durchziehen, ohne dich ständig mit dem Sicherheitsfirlefanz von Windows rumzuschlagen.
Man hört immer von den profs und auch sonst von Leuten das in der Industrie häufig unter C hardware programmiert wird kennt jemand bücher zu dem thema c hardwareprogrammierung
@Sven P. du willst also behaupten das ein Beispielprogramm für DOS mit Hardwarzugriff auf eine Linux läuft? Unter Hardwarezugriff verstehe ich z.b. den zugriff auf IO-Adressen und dieser geht weder unter linux, bsd oder Windows noch.
Peter schrieb: > @Sven P. > du willst also behaupten das ein Beispielprogramm für DOS mit > Hardwarzugriff auf eine Linux läuft? Ich weiß nicht, was DOS mit seinen Software-Interrupts und Registern anstellt, aber die Register im PC kann auch DOS nicht herumschieben. Auf 0x3BC liegt i.d.R. der erste Parallelport, das hat die x86-Architektur halt so an sich. Auch unter DOS. > Unter Hardwarezugriff verstehe ich z.b. den zugriff auf IO-Adressen und > dieser geht weder unter linux, bsd oder Windows noch. Der geht unter Linux und BSD ziemlich problemlos. Der geht auch unter Windows noch, wäre schlecht, wenns anders wäre. Allerdings ists unter Windows etwas anspruchsvoller, am Sicherheitskrams vorbeizukommen, wohingegen man unter BSD als root auch tatsächlich Vollzugriff hat. Alle Bits des ersten Parallelports setzen:
1 | ioperm(0x3BC, 3, 1); |
2 | outb(0xFF, 0x3BC); |
3 | ioperm(0x3BC, 3, 0); |
Fertig. Habe ich so heute noch in Gebrauch (2.6.24-19-generic auf i686).
Und woher soll soll das Dos-Buch etwas über den befehl ioperm wissen? Und das eine Anwenderprogramm zugriff auf einen IO-Port hat halte ich für sehr gefährlich. Das sollte doch dem Kernel und seinen Treiber vorbehalten werden. Auch unter Dos sind die IO-Adresse gleich geblieben. Und LPT1 war doch immer noch 0x378. Dazu kommen doch die Bios/Dos interrupts wie 0x1C für den zugriff auf dem Timer. Das geht vermutlich nicht unter linux. Aber für solche sachen gibt es ja DOS-Box darin läuft dann alles. (Unter Linux wie unter Windows)
weißt du vielleicht wo man solche bücher findet zum thema "hardware programmierung unter C"?
Peter schrieb: > Und woher soll soll das Dos-Buch etwas über den befehl ioperm wissen? Muss der Leser dann anpassen. outb() und inb() gibts auch unter DOS, nur bei outb() ist die Parameterreihenfolge vertauscht. > Und das eine Anwenderprogramm zugriff auf einen IO-Port hat halte ich > für sehr gefährlich. Wenn ich Administrator will, kriege ich auch Administrator. > Das sollte doch dem Kernel und seinen Treiber > vorbehalten werden. Auch unter Dos sind die IO-Adresse gleich geblieben. > Und LPT1 war doch immer noch 0x378. Ja. > Dazu kommen doch die Bios/Dos > interrupts wie 0x1C für den zugriff auf dem Timer. Das geht vermutlich > nicht unter linux. Wenn das ein x86-Register ist, geht das auch unter BSD. Die Frage ist, ob BSD sich bereits darum kümmert, oder nicht. > Aber für solche sachen gibt es ja DOS-Box darin läuft dann alles. (Unter > Linux wie unter Windows) Im Sandkasten, ja, man sieht halt ggf. nicht allzu viel von dem, was man tut.
Bob Hulu schrieb: > weißt du vielleicht wo man solche bücher findet zum thema "hardware > programmierung unter C"? Das hat nichts mit C zu tun, C ist hardwareunabhängig; was du suchst ist ein Buch über die x86-Architektur. Vielleicht darf ich dir empfehlen, 'hardwarenah' auf einem Mikrocontroller auszuprobieren, die sind meistens etwas überschaubarer, als x86, und man kann die Peripherieeinheiten auch gescheit nutzen und sieht, was man tut.
> > Dazu kommen doch die Bios/Dos > > interrupts wie 0x1C für den zugriff auf dem Timer. Das geht vermutlich > > nicht unter linux. > Wenn das ein x86-Register ist, geht das auch unter BSD. Die Frage ist, > ob BSD sich bereits darum kümmert, oder nicht. es geht nicht um register sonder auch um Interrupts. Diese wurden von DOS bzw vom BIOS bereitgestellt um verschiende dinge zu tun. (Netzwerk zugriff, direkt zugriff auf die Festplatte oder zum Reboot( INT19). Das müsste ja ein Linux ersteinmal Simulieren.
na gut da bin ich schon dabei ^^ ich habe schon im 4 sem microcontrollern unter C programmiert ein C167 von Infineon und ein Lehrgang von elektro hab ich schon hinter mir mit dem Atmel 8051er der zweite fängt bald an wahrscheinlich nächste woche und momentan mach ich mein praxissem da hab ich mit dem PIC16f877A zu tun allerdings muss ich den unter assembler programmieren. naja das kapitel wäre sowieso das letzte gewesen in dem buch. ich hab jetzt noch ein dickes c# buch und ein vhdl buch vor mir. für das vhdl habe ich aber auch ein evaluationsbaord von pollin gekauft und schon zusammengelötet. Aber kanns du mir dann bitte erklären was die leute immer meinen wenn sie sagen c wird sehr häufig zur hardwareprogrammierung benutzt meinen die etwa microcontroller?
Wenn das BIOS einen Interrupt raushaut, ist das halt so. Dann gibts den Interrupt, egal ob DOS oder BSD oder sonstwas, nur wird BSD den Interrupt schon selbst abfangen und was Gescheites damit anstellen. Da gibts nix zu simulieren. Bob Hulu schrieb: > na gut da bin ich schon dabei ^^ ich habe schon im 4 sem > microcontrollern unter C programmiert ein C167 von Infineon und ein > Lehrgang von elektro hab ich schon hinter mir mit dem Atmel 8051er der > zweite fängt bald an wahrscheinlich nächste woche und momentan mach ich > mein praxissem da hab ich mit dem PIC16f877A zu tun allerdings muss ich > den unter assembler programmieren. Dann scheiß auf x86 und überlass das den Kernel- und Treiberschreibern. Großartig anders läufts da auch nicht. Kann man sich dann mit auseinandersetzen, wenn mans tatsächlich muss. > Aber > kanns du mir dann bitte erklären was die leute immer meinen wenn sie > sagen c wird sehr häufig zur hardwareprogrammierung benutzt meinen die > etwa microcontroller? Nicht nur; C ist an sich hardwareunabhängig (C ist nackt, es hat keine einzige Funktion). Aber es machts ziemlich einfach, hardwarenah zu arbeiten. Versuch mal mit irgendnem .NET-Krams auf das Parallelportregister zuzugreifen -- zuerst wirft dir Windows seine Zugriffsrechtestöckchen zwischen die Beine, dann musste das 'managed' in 'Managed Code' umschiffen und so weiter. In C reicht der Dreizeiler oben.
ok coach :-) vielen dank für all die antworten . dieses buch hier ist mir auch ins auge gefallen kennt das jemand http://www.amazon.de/umfassende-Handbuch-Linux-Unix-Windows/dp/3898426432/ref=sr_1_12?ie=UTF8&s=books&qid=1261747693&sr=8-12 von den bewertungen her scheint es recht gut zu sein.
Sven P. schrieb: > Nicht nur; C ist an sich hardwareunabhängig (C ist nackt, es hat keine > einzige Funktion). Aber es machts ziemlich einfach, hardwarenah zu > arbeiten. Versuch mal mit irgendnem .NET-Krams auf das > Parallelportregister zuzugreifen -- zuerst wirft dir Windows seine > Zugriffsrechtestöckchen zwischen die Beine, dann musste das 'managed' in > 'Managed Code' umschiffen und so weiter. > > In C reicht der Dreizeiler oben. Mit .NET auch (sowohl bei .NET als auch mit reinem C braucht man mittlerweile entsprechende Treiber bzw. Libs). Den Rest erledigen zwei Zeilen pro Funktion (hier für inpout32.dll)
1 | [DllImport("inpout32.dll", EntryPoint = "Out32")] |
2 | public static extern void Out32(int adress, int val); |
3 | [DllImport("inpout32.dll", EntryPoint = "Inp32")] |
4 | public static extern int Inp32(int adress); |
Braucht man das auch auf einem x64-System, nimmt man z.B. WinRing0 (inkl. x64 und anderer Sachen http://openlibsys.org/). p.s. da mit Win7 Pro gearbeitet wird, könnte man auch den XP-Modus bzw. Virtual-PC zum Testen nehmen http://www.microsoft.com/windows/virtual-pc/download.aspx
> Autor: Bob Hulu (Firma: hinter den 7 bergen) (bob128) > Datum: 25.12.2009 13:34 > > Man hört immer von den profs und auch sonst von Leuten das in der > Industrie häufig unter C hardware programmiert wird kennt jemand bücher > zu dem thema c hardwareprogrammierung Hardwareprogrammierung muss man zusammen mit dem Betriebssystem betrachten. Für Linux kannst du hier einsteigen: Wie bekommt man (grundlegende) Hardware (Sensoren, IO, Motoren...) von Linux aus angesteuert? Jürgen Plate Linux Hardware Hackz Messen, Steuern und Sensorik mit Linux http://www.netzmafia.de/skripten/buecher/linuxhackz/index.html Wenn die Hardware komplexer wird (PCI, USB,...) ist dann die nächste Stufe, Treiber für die Hardware zu schreiben: Linux Device Drivers by Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman http://lwn.net/Kernel/LDD3/
@ Bob Hulu > dieses buch hier ist mir auch ins auge gefallen kennt das jemand Du kannst dir online selbst ein Bild des Buches machen: http://openbook.galileocomputing.de/c_von_a_bis_z/ Für die gedruckte Version spricht, dass man die auch bequem auf der Couch oder im Zug lesen kann. Und dass man gelbe Zettelchen reinpappen oder mit Bleistift Notizen einfügen kann.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.