Using 3Dh causes the interrupt to return only "Acces Denied"

Question

Configuration:

MS-DOS 16 BIT (write to .asm file, then compile with TASM and TLINK)

Windows 7 x64

I made a simple program in the assembly, which should only open the file and write the text to it.
Here is the code for it:

assume cs:code, ds:data data segment fileName db "input.txt", 0 ; We assure it is an ASCIIZ(ero) file. toWrite db "Hello World!", "$" data ends code segment writeToFile: ; pentru functia 3Dh mov AH, 3Dh mov AL, 0h mov dx, offset fileName int 21h ret start_program: mov ax, data mov ds, ax CALL writeToFile mov ax, 4c00h int 21h code ends end start_program 

I used TurboDebugger to find out what would happen. Oddly enough, it always sets the AX value to 0005 value of Access Denied

Everything I could find on the Internet to search for ASSEMBLY access denied open file was about a DLL , and that didn't help.

I tried anything from restarting my program to opening dosbox "As an administrator." Unfortunately, nothing worked, and I have no ideas.
Which is also strange that my friend said that after activating his windows 10, everything works fine.

What is the reason for receiving only "access denied"? I mention that I was able to create, delete and close files, but I can not open them.

Answer 1

For correct operation, your writeToFile procedure must

• open a file with access mode that allows subsequent recording
• check CF returned by DOS to see if everything is ok.

I noticed that you are completing the text that you will write in this file with "$". Interestingly, did you know that the DOS function for writing a file works only with the specified length in CX , and not with any separator. You may have other good reasons for this "$" character -

 writeToFile: mov ax, 3D01h ; 01h=WriteAccess mov dx, offset fileName int 21h jc NOK mov bx, ax ; Handle mov dx, offset toWrite mov cx, 12 ; Length of "Hello World!" mov ah, 40h int 21h jc NOK cmp ax, cx jne NOK NOK: ret 

Where you place the NOK label, and everything you do depends entirely on how much effort you put into fixing the errors returned by DOS. Here, in this very simple program, you can simply return from call and end the program.