4. Frage zu NASM

Frage zu NASM

  • N

    Zustimmung. Es kann sicher nicht schaden, wenn du dich zuerst noch etwas mehr mit dem x86 vertraut machst, wenn auch im 16Bit RealMode, der ohne VM nun mal nicht in einem 64Bit-System laeuft.
    Falls du meinst, damit wirklich firm zu sein, d.h. z.B. zumindest 16Bit von 64Bit-Code unterscheiden kannst und weisst, was Systemaufrufe sind und wie sie in etwa funktionieren, kannst du dich vorsichtig an 64Bit-Programmierung in Windows herantasten. Zu diesem Zeitpunkt solltest du natuerlich auch schon mit den wichtigsten WinAPI-Funktionen und deren Verwendung in Assembler vertraut sein.
    NASM unterstuetzt uebrigens schon seit einigen Jahren auch 64Bit-Code und kann zum Erstellen von Windows-Anwendungen verwendet werden.

    0
  • F

    Nobuo T schrieb:

    NASM unterstuetzt uebrigens schon seit einigen Jahren auch 64Bit-Code und kann zum Erstellen von Windows-Anwendungen verwendet werden.

    Als Anweisung kann dafür [Bits xx] verwendet werden, um dass schon mal erwähnt zu haben. Aber schau dir alles erst mal in Ruhe an.

    0
  • N

    Naja ich möchte einfach mit Assembler in dem "Stil" weiterarbeit, also nix mit invoke und fester erzeugen und der kram.
    Es muss ja nicht unbedingt 64 bit code sein, 32 wäre auch ok. Es geht halt darum dass das Programm dann auf einem 64 bit system läuft

    Und das geht auch mit Nasm?
    Gibts da irgendwo ne beschreibung, weil immer wenn ich compile wirds ne 16 bit exe

    Danke

    0
  • N

    Das ist kein Problem und hat nichts damit zu tun, was fuer Anwendungen du letztendlich erstellst. Du musst weder den MASM, noch ueberhaupt irgendwelche Macros wie "invoke" benutzen.
    Wie gesagt kann NASM so ziemlich alles an Code von 16 bis 64Bit erzeugen, was auf x86 oder x64 laeuft.
    Eine detailliertere Beschreibung aller Wesentlichen Funktionen des NASM findest du in der NASM Docu, zu finden auf der NASM Homepage.

    Generell erzeugt der NASM selbst eigentlich nur entweder flat binaries oder Objekt-Dateien.
    Erstere sind nur nackte binaere OpCodes und Daten ohne irgendwelche Header. Laesst sich entweder fuer 16Bit DOS-Programme (.com-Dateien) oder OS-Entwicklung o.Ae. (dann auch mit 32 und 64Bit-Code) gebrauchen.
    Die Objekt-Dateien kannst du prinzipiell zu allem moeglichen Linken (mit einem Linker), auch zu 64Bit Exe-Dateien.

    Als kleinen Denkanstoss kann ich dir ein Beispiel fuer ein Win32 "Hallo Welt!" geben...

    %include "win32n.inc"

; externe Win32 WinAPI-Funktionen
EXTERN	ExitProcess
EXTERN	MessageBoxA

; code segment
segment .text
; auf 4Byte ausrichten
align 4
; 32Bit code erzeugen
USE32

; start als global deklarieren
global start
start:
	; UINT uType
	push	MB_OK | MB_ICONINFORMATION
	; LPCSTR lpCaption
	push	text1
	; LPCSTR text
	push	text0
	; HWND hWnd
	push	0
        ; MessageBox anzeigen
	call	MessageBoxA
	; error code
	push	0
        ; beenden
	call	ExitProcess

; Datensegment
segment .data
align 4
	text0 db "Hallo Welt!", 0
	text1 db "->Titel<-", 0

    Die "win32n.inc" enthaelt einen riesigen Haufen Konstantendefinitionen fuer Win32 (zB. auch MB_OK und MB_ICONINFORMATION) und ist IMHO allgemein ziemlich praktisch fuer die Win32-Programmierung mit NASM. Kannst du dir uA. auf meiner Homepage runterladen: http://BTM.homelinux.net

    Erstellen kannst du die exe dann zB. so:

    nasmw -d Win32 -O32 -f win32 w32hw.asm
golink /entry start /fo "hello world.exe" w32hw.obj kernel32.dll user32.dll

    ->in eine batch-Datei schreiben, Konsole, o.Ae.
    nasmw ist nasm als Windows-exe compiliert. Kann aber das selbe wie nasm.exe (DOS) oder die Linux binaries.
    golink ist IMHO ein ziemlich guter Linker - bekommst du hier.

    0
  • N

    Wow ! perfekt danke, genau das meinte ich. ich werds gleich mal testen
    vielen dank!

    0
  • N

    hmm hmm da kommt ne fehlermeldung dass der befehlt "nasmw" nicht bekannt ist.
    wenn ich es nur mit nasm versuche kommt " w32hw.asm:1: fata: unable to upen include file "win32n.inc" "

    muss ich die irgendwie "importieren" wie librarys bei c oder so?

    also nasm hab ich normal installiert, dann golink den selben ordner gezogen, und dort eine datei mit dem namen w32hw.asm mit deinem quelltext erzeugt, dann ne abt gemacht und die compiler befehle reinkopiert.

    Ich hab hier mal etwas verändert, bzw in dem "stil" programmiert wie ichs bisher gewohnt war, mit dem ziel eine 32 bit Datei zu erzeugen,aber nasm sagt mir,dass er in Zeile 16 eine "comma, colon or end of line expected".

    So siehts aus nachdem ich versucht hab deine datei abzuänderen dass sie meinen Code hat :

    ; Datensegment
segment .data
align 4
    text0 db 'Hallo Welt!','$'

; code segment
segment .text
; auf 4Byte ausrichten
align 4
; 32Bit code erzeugen
USE32

; start als global deklarieren
global start
start:
    mov dx, offset text0
	mov ah,9
	int 21h
	mov ah,4Ch
	int 21h

    Das ist die Orginal datei die ich versuche mit NASM als 32 bit laufen zu lassen:

    data segment

    Meldung db "Blabla von mir aus Hello World!$"
 ends

stack segment
    dw   128  dup(0)
 ends

code segment
    start:  
        mov ax, data
        mov ds, ax
        mov dx, offset Meldung
        mov ah,9
        int 21h 
        mov ah,4Ch
        int 21h
 ends
    end start

    Würde mich sehr freuen wenn du das mit möglichst wenig Änderungen umschreibst, so dass es NASM freundlich ist. Dann hätte ich wenigstens eine Datei im bekannten "Format" die tut und könnte mich analog vorarbeiten.

    danke schonmal 😃

    0
  • N

    Novio schrieb:

    hmm hmm da kommt ne fehlermeldung dass der befehlt "nasmw" nicht bekannt ist.

    Ist egal, wenn die exe von NASM bei dir "nasm.exe" heisst, ersetzt du halt nasmw durch nasm.

    Novio schrieb:

    " w32hw.asm:1: fata: unable to upen include file "win32n.inc" "

    muss ich die irgendwie "importieren" wie librarys bei c oder so?

    Zuerst mal musst du die Datei wie gesagt herunterladen, zB. von meiner hp in der Asm-Ecke. Dann packst du sie in das selbe Verzeichnis wie die w32hw.asm. Includiert wird schon in Zeile 1.

    Novio schrieb:

    Ich hab hier mal etwas verändert, bzw in dem "stil" programmiert wie ichs bisher gewohnt war, mit dem ziel eine 32 bit Datei zu erzeugen,aber nasm sagt mir,dass er in Zeile 16 eine "comma, colon or end of line expected".

    Du vermischst hier irgendwie zwei grundverschiedene Probleme...

    Zuerst sollte dir mal klar werden, dass dein gewohnter "Stil" vor allem Code fuer ein 16Bit DOS-Programm ist. Genau das wurde schon von Anfang an versucht, dir zu vermitteln.
    Diesen 16Bit-Code kannst du zwar mit ein paar Aenderungen und Gebastel auch in eine 32Bit-Form pressen (es gibt auch 32Bit DOS-Programme), aber das aendert nichts an der Tatsache, dass du dort ein Programm fabrizierst, das die DOS-API (int 21h) verwendet, also im Prinzip ein DOS-Programm.
    Wie das mit DOS-Programmen so ist, laufen die nur, wenn sie korrekt als DOS-Programm gelinkt sind und eben auf DOS. Dh. nativ nur auf einem PC, auf dem auch DOS installiert ist (dh. auch Windows bis Win98). Andernfalls musst du deine DOS-Programme eben in einer VM, bzw. Emulator starten (WinXP hatte noch eine VM fuer DOS direkt eingebaut).
    Mein Beispielcode dagegen nutzt unabhaengig davon, dass er 32Bittig ist, die WinAPI (die calls zu den extern deklarierten Funktionen), deshalb laesst sich daraus ein Programm erzeugen, das nativ in Windows laeuft, also ein Windows-Programm.

    Das Andere Problem sind Syntaxfehler, die der NASM beim Erstellen direkt bemaengelt. NASM kennt das Schluesselwort "offset" zB. im Gegensatz zum TASM nicht.

    Ich koennte also deinen Quellcode ohne grosse Aenderungen NASM-freundlich machen (Syntaxfehler beheben), so dass die Sache auch mit den Kommandozeilen, die ich zu meinem Beispielcode angegeben habe, ohne Fehlermeldungen erstellt wird... aber du kannst dir vielleicht vorstellen, dass es einfach nicht funktionieren kann, in einem Windows-Programm Systemaufrufe fuer DOS (oder Linux oder welches fremde OS auch immer) zu machen.
    Resultat waere einfach ein sofortiger Crash. -> wenig sinnvoll.

    Wie ich also bereits schrieb, waere es IMHO am sinnvollsten, wenn du zu aller erst die Grundlagen der Syntax fuer x86 Assembler mit einem Tutorial lernst. Dabei ist erstmal egal ob fuer 16 oder 32Bit, hauptsache du kannst die Programme wie im Tutorial beschrieben erstellen und irgendwie starten.
    Wenn du x86-Assembler im Prinzip verstanden hast, kannst du anfangen, dir verschiedene Assembler und die kleinen Besonderheiten ihrer Syntax anzuschauen, bzw. den Spass mit Intel- vs. AT&T-Syntax.

    Die andere Sache waere dann einen Ueberblick ueber die Prinzipien von System-APIs zu bekommen (DOS - int 21h, Windows - calls, usw.) und die verschiedenen Betriebsmodi des x86 (16/32Bit, RM/PM/64Bit, welches OS nutzt was, usw.).

    0
  • N

    Ahh okay verstehe, kannst du zufällig ein Buch oder Tutorial empfehlen?

    0
  • N

    Empfehlungen fuer Buecher und Tutorials findest du in den FAQ.

    0
  • F

    @Nobuo T

    Ich muss dass hier noch mal hoch holen. Ich habe gesehen, dass du explizit im Code Segment das Alignment auf 4 Byte setzt.
    So wie ich das bisher beobachtet habe, ignoriert NASM diese Anweisung und verwendet immer das Alignment der durch USEXX / [BITS XX] gesetzten Wortbreite.

    Wenn dass nicht so ist, würde mich das sehr interessieren. Hab's eben aber mal schnell getestet und keine Unterschiede ausfindig machen können. Die Adresse aligned er einfach anhand des Codes.

    z.B.

    [BITS 32]
org 101

global TestFunc
TestFunc:
xor eax, eax
ret

    Der Binär-Output enthält nun 3 Alignment Bytes.

    0
Anmelden zum Antworten