Codingcrew.de - Board

[Marwin]

Ich kann mir nicht vorstellen, dass das Problem mit Freigaben zusammenhängt. Diese Freigaben sind eher im Netzwerk zu verstehen.

INT 21h/3Bh erwartet den Pfad in DS:DX. Eventuell musst du sicherstellen, dass DS mit CS identisch ist. LEA übernimmt das meines Wissens nach nicht.

[crack]

Ich kann mir nicht vorstellen, dass das Problem mit Freigaben zusammenhängt. Diese Freigaben sind eher im Netzwerk zu verstehen.

INT 21h/3Bh erwartet den Pfad in DS:DX. Eventuell musst du sicherstellen, dass DS mit CS identisch ist. LEA übernimmt das meines Wissens nach nicht.

THX Marwin
...manchmal sieht man den Wald vor lauter Bäumen nicht ...

Ok, bei diesem Szenario sähe der zu verwendende Code dann ungefähr so aus:

Code: Alles auswählen


data segment word 'data'
MyPath db'c:\windows\system32',0

...

code segment public word 'code'

...
mov ax, seg MyPath
mov ds, ax
mov dx, offset MyPath
mov ah, 3bh
int 21h
...


So wäre der code für den A86 Assembler, aber auch andere Assembler kennen einen PseudoOpcode der das selbe wie 'seg' bewirkt. Ja, bei einem .com Programm sollten Codesegment DS und Datensegment DS identisch sein, oder zumindest sollte das Datensegment und das Codesegment innerhalb von 64kb liegen, oder anders formuliert der addressierbare Bereich für ein .com Programm kann 64kb nicht überschreiten.

[Darthshoot]

Oje :/ ich habe noch nie mit Segmenten gearbeitet. Wie schreibe ich das denn in mein Programm rein mit den Code und Data Segmenten?

[crack]

Hallo Marwin, Hallo Darthshoot,

Ich habe mir einmal den geposteten Code angepasst:

Code: Alles auswählen


data segment

CDirRoot db 'C:\WINDOWS\System32\',0
Files db '*.tmp',0

code segment
   org 100h


      mov ah, 0e
      mov dl, 2
      int 021
   mov ax, seg CDirRoot
   mov ds, ax
      mov ah, 03b
   mov dx, offset CDirRoot
   int 021

   mov ah, 041
   mov dx, offset Files
   xor cx, cx
   int 021
   mov ax, 04c00
   int 021



und mit dem A86 von Eric Isaacson Kompiliert und getestet. Es funktionierte nicht. Danach habe ich einen minimalen Fehlerabfang eingebaut um nur die Funktion ‚Laufwerk und Pfad wechseln’ zu testen:

Code: Alles auswählen



   org 100h


      mov ah, 0e
      mov dl, 2
      int 021

      mov ah, 03b
   mov dx, offset CDirRoot
   int 021
   jnc X2

   mov dx, offset alarm
   mov ah,9
   int 021
X2:


   mov ax, 04c00
   int 021

CDirRoot db 'c:\Windows\system32$'
Files db '*.tmp',0
alarm db 'Datei nicht gefunden!$'



Egal wie ich den Pfad des Ordners benannt habe und was ich als ‚Abschlusszeichen’ verwendet habe (0h oder ‚$’) immer das gleiche Ergebnis: ‚Datei nicht gefunden’ (das carry flag wurde gesetzt), ok, da ist guter Rat teuer… Die Win32SDK.HLP hat mich dann auf die richtige Spur gebracht: Es werden auch unter Win32 entsprechende Interrupt 21h Funktionen unterstützt und benutzt, aaaaber der Unterschied ist folgender die Ursprünglichen DOS Funktionen sind für das FAT16 Dateisystem gedacht, und unterstützen nicht das FAT32 oder das NTFS System.
Hier werden neue Int 21 benutzt wie zum Beispiel:
Int 21h Function 440Dh Minor Code 40h (FAT32)  SetDriveParameter
Ergo: man muss wohl oder übel diese neuen Int 21 Funktionen benutzen. Tja, so ist es … 

[Darthshoot]

Mit anderen Worten:

Es ist unmöglich per TASM 5.0 DOS auf C:\WINDOWS\System32 zu kommen?

EDIT: Kann man dann trotzdem auf die Files in System32 zugreifen? z.B. so:

Files db 'C:\WINDOWS\System32\*.tmp',0

Aber das geht nicht. Aber du sagtest ja, dass es irgendwie geht. Wie?

[Rainer]

die Systemverzeichnisse hole ich mir ...

invoke GetSystemDirectory, addr szBuffer, MAX_PATH

und wechsele in dieses Verzeichnis...

invoke SetCurrentDirectory, addr szBuffer

Gruß Rainer

[crack]

Ja, diese Win Api Calls sind für reine Win32 Programme wohl das effizienteste.