From - Fri Jun 25 18:31:23 2004 Path: news.fh-wedel.de!not-for-mail From: Benno Haupt Newsgroups: ptl.assembler,ptl.ia Subject: WICHTIG - IA4 Asm Aufg. 4 Hinweis Date: Thu, 10 Jun 2004 12:09:16 +0200 Organization: Fachhochschule Wedel Lines: 72 Message-ID: NNTP-Posting-Host: hu.fh-wedel.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Trace: mail.fh-wedel.de 1086862017 32098 213.39.232.147 (10 Jun 2004 10:06:57 GMT) X-Complaints-To: usenet@fh-wedel.de NNTP-Posting-Date: Thu, 10 Jun 2004 10:06:57 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en Xref: news.fh-wedel.de ptl.assembler:540 ptl.ia:1773 Hallo allerseits, trotz der schon unter Pascal schön sichtbaren bunten Bildschirme und der nur doch in dem Sinne eigentlich gegebenen Übersetzung nach Assembler wird Euch hier als Programmierer zur Lösung der Aufgabe ein Stein in den Weg gelegt, den wir bzw. ich nicht voraus gesehen habe... Auf das Problem sind einige von Euch noch an dem Dienstag nach dem Herangehen an die Lösung der Aufgabe gestossen und versetzte uns nicht nur in erstaunen, sondern führt den Assembler "Krieger" doch mal wieder hinunter bis in den tiefsten Wirwar der direkten Programmierung auf "Bit und Byte" Ebene... Ok, lange Rede, kurzer Sinn, worum geht's eigentlich?!? Eine der Eurigen Gruppe hat es in pionierartiger Leistung geschafft, dass gegebene Pascal Prog in Assembler samt der Unterprogramme zu codieren und mußte beim abschliessenden Testen feststellen, dass die gegebene Routine MYGETMEM leider so nicht funktioniert!!! Faktum ist, wie es mir zuvor auch innerhalb Pascal passiert ist, das kein konventioneller Speicher zum Reservieren für den virtuellen Screen nach Start der ASM Exe zur Verfügung stand, welches aufgrund der geringen Größe der Exe als eher unschlüssig erscheint... Ein Vergleich des Pascal Programmes bzw. dessen Ablauf und die Möglichkeit des Ausnutzens der $M Compiler Direktive brachte Birger und mich dann letztendlich zu dem Entschluß, dieses Problem kann einzig und allein an dem aus der Vorlesung her erwähnten EXE Header liegen... Und tatsächlich, beim Durchforsten der MASM Entwicklungsumgebung nach geeigneten Hinweisen zu dem Problem sind wir auf ein Tool namens EXEHDR gestossen, dessen Funktion nicht nur klares Licht in das Problem bringt, sondern dazu uns gleich auchnoch einen Lösungsansatz bietet... Aufruf des Tools EXEHDR vom Prompt her, gefolgt von dem Programmnamen zeigt uns einen Aufbau der Executable und ihrer Segmentierung, so wie es eben halt in solch einem Header abgelegt ist und wir bekamen so den Hinweis, daß anscheinend bei Microsoft die Philosophie gefahren wird, lieber alles als garnichts... Probiert es mal an dieser Stelle mit Eurer fertig gestelleten Exe zur Aufgabe selber aus und ihr werdet sehen, daß Progamm ist laut Header versucht, den ganzen konventionellen Speicher zu reservieren!!! Welch eine Schweinerei und Ironie an dieser Stelle, bleibt doch nichts mehr für DOS übrig, um selbig ein wenig Speicher anzufordern, den wir dann aus unserem Programm letztendlich nutzen können! Glücklicherweise bietet genanntes Tool nicht nur die Möglichkeit zur Einsicht, sondern zusätzlich Funktionen zur Änderung, in dem Sinne, mit der Option /MAX habt ihr die Möglichkeit, den vom Programm her gesehenen reservierten Speicher auf ein Minimum zu limitieren. Dazu erfolht ein Aufruf mit: EXEHDR [prgname] /max: 0x0???? zur Änderung, wobei die Fragezeichen einen heximalen Wert repräsentieren, den man zuvor aus der Info Anzeige von EXEHDR entnehmen kann. Einmal hiermit gepatcht und Euer Programm sollte dann in der Lage sein, genügend Speicher anzufordern und für sich via DOS zu reservieren... Viel Spaß gehabt beim Lesen?!? Dann noch weiterhin viel Spaß bei der Umsetzung, mfG // Benno